Análisis y Diseño de Sistemas

Estructurado Moderno
ADSEM

Texto Preparado por Oscar A. Núñez Madrid

Para los Alumnos del CFT Simón Bolívar
Marzo - 2006
Santiago - Chile
 Análisis y Diseño de Sistemas

1. Introducción

La información es inherente a la existencia de las personas y de las sociedades. Permite conocer la realidad,
interactuar con el medio físico, apoyar la toma de decisiones y evaluar las acciones de individuos y de grupos. El
aprovechamiento de la información propicia la mejoría de los niveles de bienestar y permite aumentar la productividad y
competitividad de las naciones.

El mundo de hoy, está inmerso en una nueva revolución tecnológica basada en la informática, que encuentra su
principal impulso en el acceso expedito y en la capacidad de procesamiento de información sobre prácticamente todos
los temas y sectores de la actividad humana. La nueva revolución tecnológica ha contribuido a que culturas y sociedades
se transformen aceleradamente tanto económica, como social y políticamente, con el objetivo fundamental de alcanzar
con plenitud sus potencialidades.

Debemos tomar conciencia que la informática tiene un carácter estratégico. Sus aplicaciones ya han afectado
prácticamente todas las actividades humanas, modificando las estructuras de producción y comercialización, la
organización de instituciones, la generación de nuevas tecnologías y la difusión de conocimientos, así como la
prestación de servicios. A todo ello se están sumando transformaciones igualmente importantes en el ámbito social,
básicamente en la forma en que se llevan a cabo innumerables actividades cotidianas y personales.

En la actualidad, la información, obtenida en forma completa y oportuna dentro de cualquier tipo de

organización, constituye un elemento esencial que garantiza la gestión eficaz de los recursos de la misma, así como la
calidad de los servicios que presta y la adecuación constante al entorno que lo rodea. A medida que se difunde con gran
rapidez el uso de las Computadoras dentro de una Organización, surgen muchas inquietudes acerca de la forma de
usarlas para mejorar la productividad y objetivos de la Organización.

En Chile la mayoría de las instituciones y empresas carecen de una política de informática adecuada,
constituyendo así una de las características negativas del desarrollo de sistemas informáticos. Frente a la importancia de
la información, dentro de una organización y el incremento del uso del computador y la carencia de una política de
informática adecuada, se ve por conveniente emitir metodologías orientadas al desarrollo de Sistemas de Información,
en tal sentido, la literatura técnica propone una serie de metodologías orientada a las Fases de Análisis y Diseño de
Sistemas de Información, la cual constituye el cuerpo del presente libro

La filosofía implícita en la Metodología, es que el Análisis y Diseño de Sistemas es un Proceso en el que se

aplican muchas técnicas orientadas a mejorar el negocio mediante la implantación o el cambio de los sistemas de
información existentes. La Metodología propuesta, tiene sus fundamentos en la Teoría General de Sistemas (TGS), y
debe de considerarse como herramienta y guía para asegurar su efectividad.

En muchas organizaciones los Sistemas de Información se encuentran en la fase de expansión y todavía no se

ha establecido una metodología efectiva de Planificación de los mismos. En estos casos no ser posible implantar
directamente una metodología activa de generación de Planes Estratégicos de Empresas y de Sistemas de Información
simultáneamente al carecer la organización de la cultura organizativa correspondiente. En esta circunstancia hay que
llegar al método activo por vía evolutiva mediante la implantación de una metodología pasiva en una primera fase que
ayude a la creación de una cultura necesaria (el término pasivo hace mención que solamente requiere el conocimiento de
las estrategias que la institución desee llevar a cabo independientemente del proceso que se haya seguido para llegar a
ellas) es difícil de implantar si no existe los siguiente consideraciones:

1. Una cultura corporativa en la Institución que sea sensible al uso del potencial de las tecnologías de la
información.

2. El conocimiento por parte del Centro Informático, de los objetivos y estrategias corporativas de la
Institución, en términos que permita buscar un alineamiento del plan de sistemas con las estrategias de la
institución (método pasivo).

Sin embargo, cabe la posibilidad de desarrollar una integración o planificación en paralelo de ambas estrategias
(estrategias empresariales y en tecnologías de Información), Siendo el objetivo básico de cualquier procedimiento
sistemático de planificación paralela (estrategias - TI/SI) es el aprendizaje organizado asociado a la utilización de tal
procedimiento. Incorporar el pensamiento estratégico y desarrollar la sensibilidad acerca de las posibilidades de la TI/SI
a todos los niveles directivos de la organización es extraordinariamente importante para asegurar la continuidad efectiva

2
 Análisis y Diseño de Sistemas

del procedimiento en cuestión. En consecuencia, es responsabilidad de la Alta Dirección procurar que existan las
condiciones para que éste aprendizaje pueda desarrollarse efectivamente.

El Plan de Sistemas de Información, responde a la necesidad de lograr que el tratamiento de la información

(considerado en términos de disponibilidad), ayude al cumplimiento de los objetivos generales definidos para cualquier
Unidad organizativa de la Institución. Con esta perspectiva, los planes de sistemas de encuadran dentro del marco más
general de la Planificación Estratégica, como el fin de concretarse a corto y medio plazo de ésta. Así, la Planificación
Estratégica tiene como finalidad principal, definir los objetivos a largo plazo de una organización, en cuanto a:

• Servicios futuros a prestar.

• Perspectivas de crecimiento y previsiones de evolución, entre otros. Así mismo, trata de estimar las
necesidades de información en función de dichos objetivos. Para ello se considera tanto la situación de dicha
organización frente a su entorno, como la visión de los responsables de la misma.

La Planificación de Sistemas se puede considerar como la realización táctica de los objetivos estratégicos ya
definidos para la Planificación Estratégica, los cuales tiene por característica:

• Definición precisa de los Sistemas de Información identificados.

• Una planificación ajustada para la Implantación de dichos sistemas, considerando prioridades y recursos
necesarios.

Dentro de cualquier tipo de organización, el disponer de información completa, confiable en el momento

oportuno, constituye un elemento esencial para garantizar la gestión 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 administración adecuada de la información, que se planifiquen, desarrollen y mantengan sistemas de información
eficientes, es decir, sistemas que produzcan en términos de calidad, cantidad y oportunidad la información que ayude o
facilite el cumplimiento de los objetivos y funciones de la organización. A medida que crece el volumen de la
información a manejar en la administración, aumenta la necesidad de disponer de una Tecnología de la Información que
soporte dinámica 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 políticas en informática, y de
metodologías modernas de desarrollo de sistemas, pudiéndose resumir tal situación de la siguiente forma:

• Desarrollo de Sistemas de Información sin responder a un Planeamiento de Sistemas de información.

• Escasa o nula documentación de los sistemas, lo que dificulta la tarea de desarrollo, implantación y
especialmente la de mantenimiento.

• Escaso número de estándares de Desarrollo de Sistemas.

• Se justifica, por tanto, la implantación de una Metodología de Desarrollo de Sistemas en las organizaciones,
en las que se define un conjunto de métodos, actividades, técnicas y herramientas que faciliten la
construcción de Sistemas de Información con el fin de:

o Satisfacer las necesidades de los departamentos y/o reas usuarias implicadas.

o Generar la documentación asociada, la cual comprende instrucciones de operación, documentación

del mantenimiento, explotación, entre otros.

o Elaborar sistemas eficientes en términos de calidad, que produzcan información oportuna y

confiable para la adecuada toma de decisiones.

Debido a la importancia que reviste contar con metodologías para el desarrollo de sistemas, se ha considerado
conveniente proponer una metodología para la elaboración de las Fases de Análisis y Diseño de Sistemas, el cual es la
consecución del conocimiento empírico.

3
 Análisis y Diseño de Sistemas

La metodología tiene por objeto establecer las directrices a las que debe ajustarse la elaboración del Análisis de
Sistemas en los distintos organismos, empresas y/o gobierno. Así mismo, es importante señalar que la Metodología se
encuentra dividida en los siguientes capítulos:

Capítulo 2: Generalidades

Capítulo 3: Definición del Proyecto de Sistemas

Capítulo 4: Análisis, Determinación y Especificación de Requerimientos

Capítulo 5: Análisis Estructurado

Capítulo 6: Diseño

Capítulo 7: Programación

Capítulo 8: Prueba

Capítulo 9: Implantación

Capítulo 10: Mantención

4
 Análisis y Diseño de Sistemas

2. Generalidades del Análisis de Sistemas de Información.

2.1. El Enfoque Sistémico

El concepto de sistema arranca del problema de las partes y el todo, ya discutido en la antigüedad por Hesíodo
(siglo VIII a.C.) y Platón (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 interés del trabajo interdisciplinario y la existencia de analogías
(isomorfismos) en el funcionamiento de sistemas biológicos y automáticos. Este estudio tomaría carta de naturaleza
cuando, en los años cincuenta, L. Von Bertalanffy propone su Teoría General de Sistemas.

La aparición del enfoque de sistemas tiene su origen en la incapacidad manifiesta de la ciencia para tratar
problemas complejos. El método científico, basado en reduccionismo, repetitividad y refutación, fracasa ante fenómenos
muy complejos por varios motivos:

• El número de variables interactuantes es mayor del que el científico 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
número de factores humanos, económicos, tecnológicos y naturales fuertemente interconectados. En este caso la
dificultad se multiplica por la imposibilidad de llevar a cabo experimentos y por la propia intervención del hombre como
sujeto y como objeto (racional y libre) de la investigación.

La mayor parte de los problemas con los que tratan las ciencias sociales son de gestión: organización,
planificación, control, resolución de problemas, toma de decisiones,... En nuestros días estos problemas aparecen por
todas partes: en la administración, la industria, la economía, la defensa, la sanidad, etc.

Así, el enfoque de sistemas aparece para abordar el problema de la complejidad a través de una forma de
pensamiento basada en la totalidad y sus propiedades que complementa el reduccionismo científico.

Véase una excelente presentación de las ideas de sistemas en "Systems Thinking, Systems Practice" (P.
Checkland, Wiley, 1999).

Lord Rutherford pronunció la frase que refleja más claramente el éxito del método científico reduccionista
durante el primer tercio de este siglo: "Hay Física y hay coleccionismo de sellos". El objetivo último era explicar
cualquier fenómeno natural en términos de la Física.

Fueron los biólogos quienes se vieron en primer lugar en la necesidad de pensar en términos de totalidades. El
estudio de los seres vivos exigía considerar a éstos como una jerarquía organizada en niveles, cada uno más 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 interacción, y no de los componentes individuales.

En los años cuarenta comienza un vivo interés 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 analogías (más
bien isomorfismos) en la estructura y comportamiento de sistemas de naturaleza muy distinta (sistemas biológicos,
mecánicos, eléctricos, etc.) Así es como Wiener y Bigelow descubren la ubicuidad de los procesos de realimentación, 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 Cibernética, cuyo objeto es el estudio de los fenómenos de comunicación
y control, tanto en seres vivos como en máquinas.

5
 Análisis y Diseño de Sistemas

Un concepto previo al de comunicación es el de información. Los trabajos en este campo de Wiener y

especialmente de Shannon llevaron a establecer una teoría estadística de la información.

En esta misma década, Von Bertalanffy proponía los fundamentos de una Teoría de Sistemas Generales y en
1954 se crea la Sociedad para la Investigación 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 teóricos adecuados en aquellos campos donde faltaran.

3. Reducir en lo posible la duplicación de esfuerzo teórico en campos distintos.

4. Promover la unidad de la ciencia, mejorando la comunicación entre los especialistas.

El objetivo último de Von Bertalanffy, el desarrollo y difusión de una única meta-teoría de sistemas
formalizada matemáticamente, no ha llegado a cumplirse. En su lugar, de lo que podemos hablar es de un enfoque de
sistemas o un pensamiento sistémico que se basa en la utilización del concepto de sistema como un todo irreducible.

2.1.1. Qué es un Sistema

Mostramos a continuación la definición de Sistema propuesta por varios autores.

L. Von Bertalanffy (1968):

"Un sistema es un conjunto de unidades en interrelación."

Ferdinand de Saussure (1931):

"Sistema es una totalidad organizada, hecha de elementos solidarios que no pueden ser definidos más
que los unos con relación a los otros en función de su lugar en esa totalidad."

Mario Bunge (1979):

Sistema Σ es una terna ordenada [C(Σ), E(Σ), S(Σ)] en la que:

• C(Σ) (composición de Σ) representa el conjunto de partes de Σ.

• E(Σ) (entorno o medio ambiente de Σ es el conjunto de aquellos elementos que, sin pertenecer a
C(Σ), actúan sobre sus componentes o están sometidos a su influencia.

• S(Σ) (estructura de Σ) es el conjunto de relaciones y vínculos 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 número de objetivos, y los pesos asignados a cada uno de
ellos pueden variar ampliamente de un sistema a otro. Un sistema ejecuta una función imposible de
realizar por una cualquiera de las partes individuales. La complejidad de la combinación está
implícita."

6
 Análisis y Diseño de Sistemas

Estándar X3.12-1970 (ANSI), Estándar 2382/V, VI (ISO) Vocabulary for Information Processing:

"Sistema es una colección organizada de hombres, máquinas y métodos necesaria para cumplir un
objetivo específico."

Resumiendo, de las definiciones se pueden extraer unos aspectos fundamentales del concepto Sistema:

• La existencia de elementos diversos e interconectados.

• El carácter de unidad global del conjunto.

• La existencia de objetivos asociados al mismo.

• La integración del conjunto en un entorno.

2.1.2. Las Ciencias de la Complejidad

El enfoque de sistemas ha dado lugar a estudios teóricos y aplicados. Entre los primeros se encuadran algunos
de los citados anteriormente: la Cibernética y la Teoría de Sistemas Generales, de los Sistemas Dinámicos, de los
Sistemas Auto-organizativos, de la Información y de las Jerarquías. Todos ellos se pueden englobar bajo la
denominación genérica de Ciencias de los Sistemas.

Los estudios aplicados son por su parte aquellos que emplean el enfoque sistémico para la resolución de
problemas, y entre ellos se encuentran la Ingeniería de Sistemas, la Gestión de Sistemas, la Investigación Operativa o la
Dinámica de Sistemas.

En los últimos tiempos se está extendiendo el uso del término 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 características:

• 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 (interconexión entre componentes) y su importancia en el

comportamiento de los sistemas. Esta estructura puede conllevar aspectos de paralelismo o
circularidad (realimentación).

• Destacan el carácter 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
información, comunicación u organización. Los conceptos de complejidad e incertidumbre suelen ser
básicos.

• Suelen tratar con sistemas abiertos, aquellos que intercambian materia, energía o información con el
entorno. En este contexto son especialmente importantes la interacción 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.

7
 Análisis y Diseño de Sistemas

2.1.2.1. Ingeniería de Sistemas

La primera referencia que describe ampliamente el procedimiento de la Ingeniería de Sistemas fue publicada
en 1950 por Melvin J. Kelly, entonces director de los laboratorios de la Bell Telephone, subsidiaria de investigación y
desarrollo de la AT&T. Esta compañía jugó un papel importante en el nacimiento de la Ingeniería de Sistemas por tres
razones: la acuciante complejidad que planteaba el desarrollo de redes telefónicas, su tradición de investigación
relativamente liberal y su salud financiera. Así, en 1943 se fusionaban los departamentos de Ingeniería de Conmutación
e Ingeniería de Transmisión bajo la denominación de Ingeniería de Sistemas. A juicio de Arthur D. Hall, "la función de
Ingeniería de Sistemas se había practicado durante muchos años, pero su reconocimiento como entidad organizativa
generó mayor interés y recursos en la organización". En 1950 se creaba un primer curso de postgrado sobre el tema en el
M.I.T. y sería el propio Hall el primer autor de un tratado completo sobre el tema..

Para Hall, la Ingeniería de Sistemas es una tecnología por la que el conocimiento de investigación se traslada a
aplicaciones que satisfacen necesidades humanas mediante una secuencia de planes, proyectos y programas de
proyectos. Hall definiría asimismo un marco para las tareas de esta nueva tecnología, una matriz tridimensional de
actividades en la que los ejes representaban respectivamente:

• La dimensión temporal: son las fases características del trabajo de sistemas, desde la idea inicial hasta
la retirada del sistema.

• La dimensión lógica: son los pasos que se llevan a cabo en cada una de las fases anteriores, desde la
definición del problema hasta la planificación de acciones.

• La dimensión del conocimiento: se refiere al conocimiento especializado de las diversas profesiones y

disciplinas. (Esta dimensión, ortogonal a las anteriores, no ha sido incluida en la tabla a efectos de una
mayor claridad.)

Para Wymore, el objeto de la Ingeniería de Sistemas es el "análisis y diseño de sistemas hombre-máquina,

complejos y de gran tamaño", 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 definición muy general en el IEEE Standard Dictionary of Electrical and Electronic Terms:

"Ingeniería de Sistemas es la aplicación de las ciencias matemáticas y físicas para desarrollar sistemas que
utilicen económicamente los materiales y fuerzas de la naturaleza para el beneficio de la humanidad."

Una definición especialmente completa (y que data de 1974) nos la ofrece un estándar militar de las fuerzas
aéreas estadounidenses sobre gestión de la ingeniería.

"Ingeniería de Sistemas es la aplicación de esfuerzos científicos y de ingeniería para:

(1) transformar una necesidad de operación en una descripción de parámetros de rendimiento del sistema y una
configuración del sistema a través del uso de un proceso iterativo de definición, síntesis, análisis, diseño, prueba y
evaluación;

(2) integrar parámetros técnicos relacionados para asegurar la compatibilidad de todos los interfaces de
programa y funcionales de manera que optimice la definición y diseño del sistema total;

(3) integrar factores de fiabilidad, mantenibilidad, seguridad, supervivencia, humanos y otros en el esfuerzo de
ingeniería total a fin de cumplir los objetivos de coste, planificación y rendimiento técnico.

Como vemos, en la literatura se pueden encontrar tantas definiciones del término como autores se han ocupado
del tema. A pesar de ello, podemos dar otra basada en las ideas de Hall, Wymore y M'Pherson:

Ingeniería de Sistemas es un conjunto de metodologías para la resolución de problemas mediante el análisis,

diseño y gestión de sistemas.

8
 Análisis y Diseño de Sistemas

Como era de esperar por el amplio espectro de sus intereses, la Ingeniería de Sistemas no puede apoyarse en
una metodología monolítica. Cada una de las metodologías 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. Análisis de Sistemas

El Análisis de Sistemas trata básicamente de determinar los objetivos y límites del sistema objeto de análisis,
caracterizar su estructura y funcionamiento, marcar las directrices que permitan alcanzar los objetivos propuestos y
evaluar sus consecuencias. Dependiendo de los objetivos del análisis podemos encontrarnos ante dos problemáticas
distintas:

• Análisis de un sistema ya existente para comprender, mejorar, ajustar yo predecir su comportamiento.

• Análisis como paso previo al diseño de un nuevo sistema-producto.

En cualquier caso, podemos agrupar más formalmente las tareas que constituyen el análisis en una serie de
etapas que se suceden de forma iterativa hasta validar el proceso completo:

• Conceptualización: Consiste en obtener una visión de muy alto nivel del sistema, identificando sus
elementos básicos y las relaciones de éstos entre sí y con el entorno.

• Análisis 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.

• Análisis 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 físicas, ambientales, de mantenimiento, de personal, de

seguridad, etc.

o 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:

• Económicos, reflejados en un presupuesto.

• Temporales, que suponen unos plazos a cumplir.

• Humanos.

• Metodológicos, que conllevan la utilización de técnicas determinadas.

• Materiales, como espacio, herramientas disponibles, etc.

• Construcción de modelos: Una de las formas más habituales y convenientes de analizar un sistema
consiste en construir un prototipo (un modelo en definitiva) del mismo.

• Validación del análisis: A fin de comprobar que el análisis efectuado es correcto y evitar en su caso la
posible propagación de errores a la fase de diseño, es imprescindible proceder a la validación del
mismo. Para ello hay que comprobar los extremos siguientes:

• El análisis debe ser consistente y completo.

9
 Análisis y Diseño de Sistemas

• Si el análisis se plantea como un paso previo para realizar un diseño, habrá que comprobar
además que los objetivos propuestos son correctos y realizables.

Una ventaja fundamental que presenta la construcción de prototipos desde el punto de vista de la validación
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 análisis.

2.1.2.3. Diseño de Sistemas

El diseño de sistemas se ocupa de desarrollar las directrices propuestas durante el análisis en términos de
aquella configuración que tenga más 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 diseño de un sistema
complejo se suele realizar de forma descendente:

• Diseño de alto nivel (o descomposición del sistema a diseñar en subsistemas menos complejos).

• Diseño e implementación de cada uno de los subsistemas:

o Especificación consistente y completa del subsistema de acuerdo con los objetivos

establecidos en el análisis.

o Desarrollo según la especificación.

o Prueba.

• Integración de todos los subsistemas.

• Validación del diseño.

Dentro del proceso de diseño de sistemas hay que tener en cuenta los efectos que pueda producir la
introducción del nuevo sistema sobre el entorno en el que deba funcionar, adecuando los criterios de diseño a las
características del mismo. En este contexto está adquiriendo una importancia creciente la adaptación de todo sistema-
producto a las capacidades de las personas que van a utilizarlo, de forma que su operación sea sencilla, cómoda, efectiva
y eficiente. De estas cuestiones se ocupa una disciplina, la ergonomía, que tiene por objeto la optimización de los
entornos hombre-máquina. Si bien en un principio estaba centrada en los aspectos antropométricos de la relación
hombre-máquina, en la actualidad ha pasado a intervenir con fuerza en todos los procesos cognitivos (análisis,
interpretación, decisión, comunicación y representación del conocimiento). Así, con respecto al diseño de herramientas
software, la ergonomía tiene mucho que decir en cuestiones relacionadas con la disposición de informaciones en
pantalla, profundidad de menús, formato de iconos, nombres de comandos, control de cursores, tiempos de respuesta,
manejo de errores, estructuras de datos, utilización de lenguaje natural, etc.

2.1.2.4. Gestión de Sistemas

La Gestión de Sistemas se ocupa de integrar, planificar y controlar los aspectos técnicos, humanos,
organizativos, comerciales y sociales del proceso completo (desde el análisis y el diseño hasta la vida operativa del
sistema). Los objetivos principales de la Gestión de Sistemas suelen ser:

• Planificar y controlar el proceso completo de análisis, diseño y operación del sistema dentro del
presupuesto, plazo, calidad y restantes condiciones convenidas.

• Controlar la validez de los criterios de diseño.

• Controlar la adecuación del producto del diseño a los requisitos establecidos en el análisis.

10
 Análisis y Diseño de Sistemas

• Planificar y desarrollar las necesidades de mantenimiento.

• Planificar y desarrollar las necesidades de formación del personal que va a operar el sistema.

• Planificar la supervisión del funcionamiento del sistema.

En grandes proyectos de ingeniería, y dentro del ámbito de la gestión, 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 Información.

La edad de los sistemas -la edad de la síntesis –Sistemas abiertos –Cibernética –Sistemas homeostáticos –
Reglas de decisión –Retroalimentación de información –Control automático –Diseño de sistemas –Sistemas de
información a la gerencia.

Éstas y otras frases semejantes forman parte del dialecto y vocabulario de la nueva ciencia de los sistemas de
información a la administración, misma que ofrece grandes promesas para enfrentarse al enorme crecimiento del
tamaño, complejidad y diversidad de las operaciones de la organización moderna. Ese incremento de la complejidad y
del tamaño, que caracteriza la moderna organización en gran escala, ha hecho que las funciones administrativas de
planeamiento, organización y control sean más difíciles de ejecutar, aunque cada vez más 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 más de cien años -desde la
Revolución Industrial- la administración se ha considerado como un arte que ha progresado mediante la adquisición 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 tendrán que enfrentarse. Sin embargo,
los gerentes de nuestra época necesitan más 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 más estructurado para la toma de
decisiones.

El enfoque de sistemas proporciona el proceso para reconciliar las complejidades de la -empresa moderna. Los
sistemas de información: 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 información a la
gerencia suministran a los gerentes, técnicas y modernos métodos para el planeamiento, la organización, la integración y
el control de sus operaciones en una forma, más efectiva.

2.2.1. Concepto de sistema, características que lo definen y su enfoque.

En el sentido más amplio, un sistema es un conjunto de componentes que interaccionan entre sí para lograr un
objetivo común. Nuestra sociedad está rodeada de sistemas. Por ejemplo, cualquier persona experimenta sensaciones
físicas gracias a un complejo sistema nervioso formado por el cerebro, la medula espinal, los nervios y las células
sensoriales especializadas que se encuentran debajo de la piel; estos elementos funcionan en conjunto para hacer que el
sujeto experimente sensaciones de frío, calor, comezón, etc. Las personas se comunican con el lenguaje, que es un
sistema muy desarrollado formador por palabras y símbolos que tiene significado para el que habla y para quienes lo
escuchan. Asimismo, las personas viven en un sistema económico en el que se intercambian bienes y servicios por otros
de valor comparable y en el que, al menos en teoría, los participantes obtienen un beneficio en el intercambio.

Una organización es un sistema. Sus componentes mercadotecnia, manufactura, ventas investigación,

embarques, contabilidad y personal trabajan juntos para crear utilidades que beneficien tanto a los empleados como a los
accionistas de la compañía. 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, facturación y auditoria entre otras.

11
 Análisis y Diseño de Sistemas

Todo sistema organizacional depende, en mayor o menor medida, de una entidad abstracta denominada sistema
de información. 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 comunicación interna entre los diferentes componentes de la organización y líneas
telefónicas hasta sistemas de cómputo que generan reportes periódicos para varios usuarios. Los sistemas de información
proporcionan servicio a todos los demás sistemas de una organización y enlazan todos sus componentes en forma tal que
éstos trabajen con eficiencia para alcanzar el mismo objetivo.

Características que lo definen.

La finalidad de un sistema es la razón de su existencia. Existe un sistema legislativo, por ejemplo, para estudiar
los problemas que enfrentan los ciudadanos y aprobar la legislación que los resuelva. El sistema de encendido de un
automóvil tiene el claro propósito de quemar el combustible para crear la energía que emplean los demás sistemas del
automóvil.

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 interactúan con su medio ambiente
(reciben entradas y producen salidas) se denominan sistemas abiertos. En contraste, aquellos que no interactúan con su
medio ambiente se conocen como sistemas cerrados. Todos los sistemas actuales son abiertos. Es así como los sistemas
cerrados existen sólo como un concepto, aunque muy importante como se verá más 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 desempeño tolerables. Por ejemplo, las
personas trabajan mejor cuando su temperatura es de 37 grados centígrados. Quizá una desviación de 37 a 37.5 grados
no afecte en mucho su desempeño aunque, en algunos casos, la diferencia puede ser notable. Una mayor desviación, sin
embargo, tal como una fiebre de 39.5 grados, desencadena un cambio drástico en las funciones corporales. El sistema
deja de funcionar y permanece inactivo hasta que se corrija su condición. Si esta condición se prolonga demasiado, los
resultados pueden ser fatales para el sistema.

Este ejemplo muestra además la importancia del control en los sistemas de todo tipo. Todos, los sistemas tienen
niveles aceptables de desempeño, denominados estándares y contra los que se comparan los niveles de desempeño
actuales. Siempre deben anotarse las actividades que se encuentran muy por encima o por debajo de los estándares para
poder efectuar los ajustes necesarios. La información proporcionada al comparar los resultados con los estándares junto
con el proceso de reportar las diferencias a los elementos de control recibe el nombre de retroalimentación.

Para resumir, los sistemas emplean un modelo de control básico consistente en:

1. Un estándar para lograr un desempeño aceptable

2. Un método para medir el desempeño actual

3. Un método para comparar el desempeño actual contra el estándar

4. Un método de retroalimentación

Los sistemas que pueden ajustar sus actividades para mantener niveles aceptables, continúan funcionando.
Aquellos que no lo hacen, tarde o temprano dejan de trabajar.

El concepto de interacción con el medio ambiente, que es lo que caracteriza a los sistemas abiertos, es esencial
para el control. Recibir y evaluar la retroalimentación, 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 gráficas de ventas bajas son la
retroalimentación 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 desempeño, volver al camino y recobrar las esperanzas.

En contraste, los sistemas cerrados sostienen su nivel de operación siempre y cuando posean información de
control adecuada y no necesiten nada de su medio ambiente. Dado que esta condición no puede sostenerse por mucho

12
 Análisis y Diseño de Sistemas

tiempo, la realidad es que no existen sistemas cerrados, El concepto, sin embargo, es importante porque ilustrar un
objetivo en el diseño de sistemas: construir sistemas que necesiten la menor intervención del medio externo para
mantener un desempeño aceptable. Por consiguiente, la autorregulación y el propio ajuste son objetivos de diseño en
todos los ambientes de sistemas.

Los componentes que forman un sistema pueden ser a su vez más pequeños; 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 automóvil tiene sistemas de combustión, eléctricos y de control de emisiones. En
general, en situaciones de sistemas, es común tener varios niveles de sistemas interactuando entre sí.

Enfoque de sistemas.

Esencialmente, el enfoque de sistemas para la administración se diseña para utilizar el análisis científico, en las
organizaciones complejas: a) para desarrollar y administrar los sistemas de operación (por ejemplo, flujos de dinero o
sistemas de fuerza humana), y b) para diseñar sistemas de información para la toma de decisiones. Es evidente el
eslabonamiento entre esos dos procesos: el objetivo del diseño de sistemas de información consiste en ayudar a la toma
de decisiones relacionadas con la administración de los Sistemas de operación.

Un concepto fundamental del enfoque de sistemas para la organización y la administración es la relación

recíproca de las partes o subsistemas de la organización. El enfoque comienza con una serie de objetivos y se dedica al
diseño, del todo, a diferencia del diseño, de los componentes o subsistemas. La característica sinérgica del enfoque de
sistemas es muy importante. Los sistemas de organización e información se diseñan para lograr la sinergia, la acción
simultánea de las partes separadas, aunque recíprocamente 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 fútbol son mayores que el que pueda lograr once jugadores individuales que actúen sin esfuerzo integrado.
La analogía con una organización 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 función de ventas se ejecutaba sin una
consideración adecuada de la de manufactura. El control de producción no se coordinaba con el planeamiento financiero
o de personal y el sistema clásico de información a la gerencia consistía de la tabla de cuentas. El sistema de
contabilidad tradicional se ocupaba principalmente de suministrar información 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 relación recíproca 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 organización con el resto, de la compañía. Otras causas son una organización impropia, un mal
planeamiento o la falta de integración de los componentes de la organización mediante el enfoque de sistemas. El
enfoque en el diseño del todo, a diferencia del de los componentes y subsistemas -una premisa fundamental del enfoque
de cisternas se demuestra en la figura siguiente. La línea gruesa continua índica las relaciones de autoridad y la
estructura jerárquica de la organización clásica. La principal preocupación la constituyen las relaciones formales de la
autoridad y la cadena de mando, no las relaciones recíprocas de las partes. Las líneas de puntos muestran la misma
estructura de la organización, con las rutas unidas en un sistema, mediante el flujo de información y el enfoque de
sistemas para la organización y la administración.

13
 Análisis y Diseño de Sistemas

La figura no debe hacer que el lector llegue a la conclusión de que la distinción entre el enfoque "clásico" y el
de "sistemas" sea clara y absoluta. En realidad, el enfoque clásico siempre ha tenido en cuenta el intercambio de rutina
de información a través de la cadena de mando. Las copias de las órdenes de ventas se han enviado a los departamentos
de crédito, planes de producción, embarques y cuentas por cobrar. Los presupuestos se han hecho con vista a lo futuro y
han incluido las partes separadas de la organización. Sin embargo, aunque proporcionan cierto grado de integración y de
coordinación, esos mecanismos no, fueron sinérgicos 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 solución de problemas incluye 1) una filosofía de enfoque, y 2) un método de
diseño de sistemas para la solución de problemas. La filosofía 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 situación desde todos los puntos de vista", preguntándonos:

• ¿Cuántos 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 después de que se definan?

Como el enfoque de sistemas se dedica al diseño, del todo, se ocupa de las relaciones antes de perfeccionar los
componentes. Para explicar este punto consideremos el "ardiente" expendio de carnes al carbón. De acuerdo con el
antiguo enfoque de componentes, la administración trataba de hacer lo siguiente:

14
 Análisis y Diseño de Sistemas

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 recolección del dinero.

Así, pues, las instalaciones de cocina podrían ser excelentes, pero serían muy inconvenientes e ineficientes para
dar servicio a los clientes. El proceso de servicio podría 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 podría 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 revisión de todo el sistema la gerencia decidió que los clientes
deberían ordenar primero sus alimentos fríos y luego los calientes, ambos en un mostrador de cafetería. Mientras la
carne se prepara al gusto, los clientes pagan la cuenta y se les da un recibo numerado. Llevan los alimentos fríos a la
zona del comedor y recogen sus platillos calientes cuando se les llama por número. Con ese diseño, de sistema se logra
la eficiencia del sistema total de producción a bajo costo para la clientela. Hay que notar el intercambio entre el manejo
material de los alimentos por el restaurante y la economía para el cliente. Además, el método de toma de pedidos, cobro
del consumo y cocinado queda estrechamente integrado en el sistema.

Es imposible dar instrucciones exactas para el diseño 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 guía. El diseñador de
sistemas desarrolla el arte de enfrentarse a los problemas de un sistema, en gran parte mediante la experiencia, y sus
métodos pueden variar desde un sencillo razonamiento de sentido común hasta las técnicas más refina-das de la
investigación de operaciones. Básicamente, sin embargo, el enfoque de sistemas es una aplicación sistemática del
intelecto, de las técnicas y de los instrumentos a fin de lograr la integración de los componentes para un fin especificado.

2.2.2. Concepto y función de un sistema de información.

En la práctica se dispone de una gran variedad de, sistemas de información que soportan los aspectos
administrativos y de control de las organizaciones: por ejemplo, en una fábrica se tendrían los siguientes sistemas
principales:

Función Sistema

Almacén. Control de inventarlos.

Producción. Planeación y control de la producción.

Compras. Proceso de órdenes y seguimiento de las compras.

Ventas Facturación y control de créditos.

Contabilidad. Registro de afectaciones contables y emisión de informes.

Personal. Nóminas y administración 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 organización. Estos sistemas pueden pasar por un flujo
que permita su procesamiento electrónico y con ello tratar de satisfacer las necesidades de información de la
organización. Cabe hacer notar que estos sistemas normalmente están relacionados unos con otros; las salidas de un
sistema pueden ser transacciones de entrada de otro sistema y durante el diseño de sistemas es de vital importancia
identificar estas relaciones.

15
 Análisis y Diseño de Sistemas

Los sistemas, según su naturaleza, se clasifican en los grupos siguientes:

• Determinísticos.

• Probabilísticas.

• Abiertos.

• Cerrados.

Hasta cierto punto la clasificación no tiene mayor importancia, pero es imperativo que dentro de los sistemas
exista la dinámica 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 sociológicos,
técnicos, económicos o legales, que modifican las políticas y funciones de las organizaciones.

El proceso de diseño de los sistemas de información comprende tanto el diseño de uno nuevo como el rediseño
de un sistema que se encuentre en operación. Un nuevo sistema se requiere cuando la organización inicia sus
operaciones o cuando una nueva división solicita por primera vez el proceso de datos de un cierto sistema. Los sistemas
en operación normalmente necesitan ser rediseñados o modificados parcialmente en forma periódica para asegurar que
estén acordes con lo actual y no con los requerimientos históricos. Una organización se puede clasificar como un sistema
total, y sus subsistemas son:

• Subsistema administrativo.

• Subsistema operativo.

• Subsistema de información.

Éstos deben interrelacionarse para lograr las metas y objetivos de la organización.

El subsistema de información tiene una función muy importante dentro de la organización:

16
 Análisis y Diseño de Sistemas

1. Debe proporcionar información 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
información sobre las operaciones que día con día tiene que realizar la organización.

3. Debe comparar los resultados reales con los planeados y proporcionar información que ayude a
corregir las desviaciones incurridas.

Tradicionalmente los sistemas computacionales de información se han desarrollado bajo metodologías distintas,
producto de la experiencia del personal especialista; sin embargo, en los últimos años ha nacido una serie de nuevas
disciplinas (tecnología de información, ingeniería de software, etc.) que tienen como finalidad proporcionar una
metodología formal e ingenieril para desarrollar sistemas computacionales de información de manera eficiente y
efectiva.

2.2.3. Tipos de sistemas de información.

Aunque muchas compañías y organizaciones están 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
mayoría de los sistemas de información (ya sean manuales o basados en computadoras) continúan en las categorías que
veremos a continuación. Ordinariamente la obtención y diseminación de la información es el problema más difícil de la
compañía. La información es voluminosa, esparcida, y a menudo difícil de obtener. Si los gerentes quedan envueltos en
el papeleo, no tendrán tiempo para llevar a cabo la valoración, el planeamiento o la toma de decisiones. Su trabajo será
una constante búsqueda de información para manejar las diversas crisis que se presenten, además del flujo normal del
trabajo.

Con el transcurso del tiempo las empresas típicas han desarrollado los sistemas principales de información que
muestra la tabla 1-1, para proporcionar información de planeamiento, de operación y de control para los tomadores de
decisiones de toda la organización. Esos sistemas principales son los siguientes:

1. financiero,

2. de producción 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, interactúan y reúnen los subsistemas de la
organización con el medio de la información. También hay que notar que aunque esos sistemas principales sirven para
integrar las funciones básicas de planeamiento, operación y control, la mayor parte de los mismos se diseñan y utilizan
primordialmente para una o dos de esas funciones.

17
 Análisis y Diseño de Sistemas

SISTEMAS Y SUBSISTEMAS PRINCIPALES DE INFORMACIÓN

SISTEMA USOS PRINCIPALES
SUBSISTEMA Planeamiento Operación Control
FINANZAS
Presupuestación de efectivo x x
Presupuestación de capital x x
Contabilidad de costos x x
Planeamiento de utilidades x x x
Contabilidad de responsabilidad x x x
Contabilidad de costeabilidad x x
PRODUCCIÓN/OPERACIONES
Planeamiento de producción x x x
Inventario, x x x
Compras x x x
Distribución x x x
MERCADOTECNIA
Planeamiento de ventas x
Ventas y facturación x
Análisis de ventas x x
Control de crédito x
Investigaciones de mercado x
PERSONAL
Registros de personal x
Nómina x
Empleo x
Colocación x
Adiestramiento x
Mantenimiento y materiales x
CONTROL DE PROYECTOS
PERT/CPM, costo, tiempo, etcétera x x x
OTRAS INVESTIGACIONES
Y DESARROLLOS x
Planeamiento, estratégico x x
Simulación x

2.3. Importancia de los sistemas de información en la toma de decisiones

La toma de decisiones es un término reservado para la acción de elegir entre varias alternativas. La toma de
decisiones es un proceso de pensamiento que ocupa toda la actividad que tiene por finalidad la solución de problemas.

Todo aspecto que refleja el esfuerzo humano involucra actividades con un propósito en las que deben resolverse
los problemas y tomar decisiones. La toma de decisiones puede verse como un procedimiento, un ciclo que contiene
varios círculos.

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 información son de vital importancia en cualquier tipo de información 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 información necesaria en el preciso momento y con la mayor
eficiencia posible, ayuda a que la empresa crezca y se desarrolle.

18
 Análisis y Diseño de Sistemas

2.3.1. Teoría de la Información

Es la teoría relacionada con las leyes matemáticas que rige la transmisión y el procesamiento de información, es
decir, la teoría de la información se ocupa de la medición de la información y de su forma de representarla, y de la
capacidad de los sistemas de comunicación para transmitir y procesar información.

La codificación se refiere tanto a la transformación de imagen o voz en señales eléctricas, como al cifrado de
mensajes para asegurar su privacidad.

Esta teoría de la información, fue desarrollada por 1948, por el ingeniero Claude E. Shannon. La necesidad de
una base teórica para la tecnología de la comunicación, surgió del aumento de la complejidad y de la masificación de las
vías de comunicación (teléfono, radio, redes). La teoría de la información abarca todas las formas de transmisión y
almacenamiento de información, como la televisión, en la grabación de imágenes.

El término información, se refiere a los mensajes transmitidos: voz o música transmitida por radio o teléfono,
imágenes transmitidas por televisión, información digital, en sistemas y redes de computadoras.

La teoría de la información ha sido aplicada en diferentes campos como la cibernética, la lingüística, sicología,
etc.

2.3.2. Por que necesitan información las empresas

Las organizaciones operan en un mundo de desaciertos e intervención gubernamental, de políticas

impredecibles a nivel monetario, fiscal, impositivo y regulador; de ciclos de negocios y recesiones; de cambios abruptos
en las políticas comerciales; de competencia doméstica 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 diferenciación de productos y servicios de una creciente productividad.

Claramente, la información 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 tecnología informática 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
más fuerte. Debe quedar claro que las computadoras, la tecnología informática y la información 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 organización, las compañías que producen la información de la más alta calidad,
permanecerán como las más fuertes competidoras del ramo. Por otra parte, si una compañía no puede mejorar su
información, quedará a la zaga de aquellas que si pueden.

2.4. Conceptos y Análisis.

Es un conjunto o disposición 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
lógico en la unión de las partes. Un método, plan o procedimiento de clasificación para hacer algo. Esto se lleva a cabo
teniendo en cuenta ciertos principios:

• Debe presentarse y entenderse el dominio de la información de un problema.

• Defina las funciones que debe realizar el Software.

19
 Análisis y Diseño de Sistemas

• Represente el comportamiento del software a consecuencias de acontecimientos externos.

• Divida en forma jerárquica los modelos que representan la información, funciones y comportamiento.

El proceso debe partir desde la información esencial hasta el detalle de la Implementación.

La función del Análisis 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 documentación que hacen
efectiva la logística metodología o controles de requerimientos del Programa.

2. Hardware, dispositivos electrónicos y electromecánicos, que proporcionan capacidad de cálculos y

funciones rápidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.),
que proporcionan una función externa dentro de los Sistemas.

3. Personal, son los operadores o usuarios directos de las herramientas del Sistema.

4. Base de Datos, una gran colección de informaciones organizadas y enlazadas al Sistema a las que se
accede por medio del Software.

5. Documentación, Manuales, formularios, y otra información descriptiva que detalla o da instrucciones

sobre el empleo y operación del Programa.

6. Procedimientos, o pasos que definen el uso específico de cada uno de los elementos o componentes
del Sistema y las reglas de su manejo y mantenimiento.

Un Análisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en mente:

• Identifique las necesidades del Cliente.

• Evalúe que conceptos tiene el cliente del sistema para establecer su viabilidad.

• Realice un Análisis Técnico y económico.

• Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema.

• Establezca las restricciones de presupuestos y planificación temporal.

• Cree una definición del sistema que forme el fundamento de todo el trabajo de Ingeniería.

Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del Hardware y el Software, así
como de la Ingeniería humana (Manejo y Administración de personal), y administración de base de datos.

2.5. Objetivos del Análisis.

2.5.1. Identificación de Necesidades.

Es el primer paso del análisis del sistema, en este proceso en Analista se reúne con el cliente y/o usuario (un
representante institucional, departamental o cliente particular), e identifican las metas globales, se analizan las

20
 Análisis y Diseño de Sistemas

perspectivas del cliente, sus necesidades y requerimientos, sobre la planificación temporal y presupuestal, líneas de
mercadeo y otros puntos que puedan ayudar a la identificación y desarrollo del proyecto.

• Reconocimiento del problema.

• Evaluación y Síntesis.

• Modelado.

• Especificación.

• Revisión.

Antes de su reunión con el analista, el cliente prepara un documento conceptual del proyecto, aunque es
recomendable que este se elabore durante la comunicación Cliente – analista, ya que de hacerlo el cliente solo de todas
maneras tendría que ser modificado, durante la identificación de las necesidades.

2.6. Metodologías y Herramientas para el Análisis y Diseño de Sistemas.

El desarrollo de sistemas pequeños, 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 propagación de cambios en el
sistema. Sin embargo, si el sistema es grande y en su desarrollo participan varios grupos de personas desarrollando una
tarea específica, hay que tener en cuenta no solo la comunicación con el usuario sino también la interrelación entre los
distintos grupos de trabajo.

Algunos de los problemas comunes que los desarrolladores encuentran en la construcción de software de cierta
complejidad son los siguientes:

• El dominio de aplicación no es conocido.

• La comunicación con el usuario.

• La comunicación con el grupo de desarrollo.

• La carencia de buena documentación.

Por esta razón, es necesario seguir una serie de pasos sistemáticos para que los diferentes grupos de desarrollo
posean una buena comunicación. Estos pasos son brindados por los modelos de ciclo de vida, los cuales están
constituidos por diferentes etapas, por ejemplo:

Especificación de requerimientos: Se realizan entrevistas con el usuario identificando los requerimientos y

necesidades del usuario.

Análisis: Modela los requerimientos del usuario.

Diseño: Se modela la solución del sistema, teniendo en cuenta el ambiente de implementación a utilizar, por
ejemplo, si el sistema es centralizado o distribuido, la base de datos a utilizar, lenguaje de programación, performance
deseada, etc.

Implementación: Dado el lenguaje de programación 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
 Análisis y Diseño de Sistemas

Mantenimiento: Es la etapa más difícil de desarrollo del sistema, actualiza y modifica el sistema si surgen
nuevos requerimientos.

Existen varios métodos 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 había que terminar
la primera, produciendo un gran problema si algún cambio era requerido. La etapa de Mantenimiento consumía el 80%
del costo de producción.

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 básicamente las mismas etapas, pero varían en:

• los métodos y herramientas utilizadas en cada actividad

• los controles requeridos, paralelismo en las actividades

• las salidas de cada etapa

22
 Análisis y Diseño de Sistemas

No es aconsejable elegir un modelo y seguirlo al detalle sino que se debe adaptar a las características 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 ingeniería de software ha sido desarrollado para cubrir las mejores características
tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el
análisis de riesgo. El modelo representado mediante la espiral de la figura 2.3, define cuatro actividades principales:

1. Planificación: determinación de objetivos, alternativas y restricciones.

2. Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos.

3. Ingeniería: desarrollo del producto del "siguiente nivel",

4. Evaluación del cliente: Valorización de los resultados de la ingeniería.

Fig. 2.3.: Modelo Espiral

23
 Análisis y Diseño de Sistemas

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 análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede
usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al
cliente.

El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la
base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle
alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir".

Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se
construyen sucesivas versiones del software, cada vez más completa y, al final, al propio sistema operacional.

El paradigma del modelo en espiral para la ingeniería de software es actualmente el enfoque más realista para el
desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software,
permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creación
de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla
aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.

2.6.3. Modelo Prototipo.

Este modelo se describe de la siguiente manera: Una alternativa de enfoque para la definición de los
requerimientos consiste en capturar un conjunto inicial de necesidades e implementarlas rápidamente con la intención
declarada de expandirlas y refinarlas iterativamente al ir aumentando la compresión que del sistema tienen los usuarios y
quien lo desarrolla. La definición del sistema se realiza el descubrimiento evolutivo y gradual y no atrevas de la
previsión omnisciente... Este tipo de enfoque se llama "de prototipos". También se le conoce como modelado del
sistema o desarrollo heurístico. Ofrece una alternativa atractiva y practicable a los métodos de especificación para tratar
mejor la incertidumbre, la ambigüedad y la volubilidad de los proyectos reales.

Dentro del enfoque de prototipos se pretende que el modelo sea operante, es decir, una colección 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 programación de cuarta generación

• Un lenguaje de consultas no guiado por procedimientos

• Medios poderosos de administración 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
determinación de sí el proyecto es un buen candidato para un enfoque de prototipos. Los buenos candidatos son aquellos
que tienen las siguientes características:

• 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 sólo se
pueden determinar sus requerimientos mediante un proceso de tanteo, o ensayo y error.

24
 Análisis y Diseño de Sistemas

• Se tiene la intención de que el sistema sea en línea y con operación total por la pantalla, en
contraposición con los sistemas de edición, actualización y reportes operados por lote.

• El sistema no requiere la especificación de grandes cantidades de detalles algorítmicos, 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 diseño. Con el cual se tiene la intención de que se modelen los
requerimientos del usuario.

2.6.4. Metodología ASML (A System Modeling Language)

ASML es una metodología de desarrollo estructurado de sistemas que cubre todo el ciclo de vida de desarrollo.
Esta metodología integra las principales ideas del Análisis Estructurado y el Diseño Estructurado en un marco
conceptual único y consistente.

Si bien la definición original de la metodología puede reconocerse en los libros de Ward y MacMenamim, le
cabe una mejor definición al ser interpretada como: la conjunción del Análisis Estructurado Moderno y el Diseño
Estructurado, con extensiones para el modelado de sistemas de tiempo real.

Estructura de la Metodología

ASML es una metodología que integra todas las ideas involucradas en el análisis y diseño estructurado.
Conjuga las técnicas y herramientas de modelado usadas en el Análisis EstructuradoModerno y en el Diseño
Estructurado dentro de una organización que destaca los diferentes modelos necesarios para: obtener una buena
comprensión del problema, y diseñar una solución de buena calidad (mantenible, adaptable, etc.). Separa el modelado de
un sistema en una jerarquía de modelos necesarios para comprender diferentes propiedades del mismo. Dicha jerarquía
de modelos se presenta en la Fig. 2.5.

25
 Análisis y Diseño de Sistemas

Fig. 2.5.: Jerarquía de Modelos

El Modelo del Sistema está dividido en dos modelos generales:

• El Modelo Esencial: Representa la etapa de Análisis Estructurado. Construcción de un modelo libre de

detalles tecnológicos.

• El Modelo de Implementación: Representa la etapa de Diseño Estructurado. Instanciación de un

Modelo Esencial con una tecnología dada.

1. El Modelo Esencial

Puede ser considerado como la aplicación de la metodología de Análisis Estructurado Moderno de Yourdon. La
idea fundamental con la que el modelo esencial es concebido es la de Tecnología Perfecta en la cual no hay restricciones
de cantidad de memoria, tamaño del disco o velocidad del procesador. Dos modelos componen el modelo esencial:

• El Modelo del Ambiente: Declaración de los objetivos. Creación de un Diagrama de Contexto y de

una Lista de Eventos, describe los estímulos que recibe el sistema y las respuestas generadas por los
estímulos. Definición del Diccionario de Datos inicial. Tabla de Estímulo-Respuesta.

• El Modelo de Comportamiento: Creación 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, también, modelar el
comportamiento externo del sistema con DTE, árboles de pantallas o menúes, etc. La creación
simultánea del modelo de datos, modelo funcional y modelo de interfaz o comportamiento externo,
ayuda en la validación y completitud del modelo esencial (descubriendo, por ejemplo, eventos no
considerados).

26
 Análisis y Diseño de Sistemas

Todos los criterios de modelado y, principalmente de validación, descriptos en la metodología de Análisis

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 Implementación

A partir de esta etapa, el modelo esencial es instanciado en una tecnología dada. Se debe considerar ahora, las
imperfecciones de la tecnología y determinar: la cantidad de procesadores necesarios, las cualidades de estos
procesadores, el tamaño de disco necesario de acuerdo al volumen de la información a ser almacenada, etc. Luego se
diseña la solución sobre la base de esas restricciones tecnológicas.

La creación del modelo de implementación se fundamenta en la creación de tres modelos, uno de ellos en forma
independiente (el modelo del usuario o de la interfaz hombre-máquina) y los otros dos en forma encadenada en un
proceso incremental de refinamiento e incorporación de detalles:

• El Modelo del Usuario: La interfaz hombre-máquina es modelada en todos sus detalles, estilo (árboles
de menús, lenguajes de comandos, manipulación directa, etc.), lay-out y formato de pantallas, formato
de informes y listados, diseño de pantallas para el ingreso de datos y presentación de resultados, estilo
de mensajes de error, secuencialidad, etc. La creación de este modelo es independiente del resto de los
modelos que conforman el de implementación, y puede ser desarrollado en paralelo. Las interfaces
deben ser diseñadas 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 inflexión entre la etapa de análisis y la etapa de diseño. El modelo de

implementación del usuario especifica un conjunto de restricciones que el usuario deseará
imponer al grupo de desarrollo y condicionarán al diseñador.

Define la interfaz hombre-máquina que es modelada en todos sus detalles, estilo (árboles
de menúes, lenguajes de comandos, manipulación directa, etc.), lay-out y formato de pantallas,
formato de informes y listados, diseño de pantallas para el ingreso de datos y presentación de
resultados, estilo de mensajes de error, secuencialidad, etc. La creación de este modelo es
independiente del resto de los modelos que conforman el de implementación, y puede ser
desarrollado en paralelo. Las interfaces deben ser diseñadas para cada uno de los procesadores (del
modelo de procesadores) y para cada una de las tareas (del modelo de tareas).

Los aspectos más importantes que se especifican en el modelo de implementación del

usuario son:

o Delimitación de la frontera de automatización: distribución del modelo esencial entre

personas y máquinas: 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 automatización. El usuario puede fijar entre las
siguientes alternativas

Al usuario no le interesa donde está la frontera de automatización, dejando librado

al diseñador la decisión de establecerla.

El usuario escoge un sistema totalmente automatizado

El usuario escoge un sistema totalmente manual

o Detalle de la interacción humano-máquina: especifica todos los aspectos del diseño de la

interfaz entre el sistema y el entorno. Los aspectos mas importantes a considerar en este
punto son:

Elección de dispositivos de E/S

27
 Análisis y Diseño de Sistemas

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 línea, navegaciones de

pantalla

Métodos de codificación a utilizar para el ingreso de datos

o Actividades de apoyo manual que se podrían requerir: actividades ‘no esenciales’ que
deben agregarse al sistema por no disponerse de una tecnología perfecta e ideal. Pueden
representarse como burbujas adicionales en el modelo esencial. Los casos típicos son:

Controles de posibles fallas humanas/técnicas (ingreso de datos al sistema,

realización de cálculos, dispositivos de almacenamiento, salida de datos del
sistema)

Operación del sistema en producción

o Restricciones operativas que el usuario desea imponer al sistema: son restricciones que
afectarán la configuración de hw, sistema operativo, telecomunicaciones, lenguaje de
programación. Los aspectos típicos son:

Volumen de los datos

Tiempo de respuesta en sistemas On-line

Restricciones políticas sobre modalidades de implantación

Restricciones ambientales

Restricciones de seguridad y confiabilidad (mtbf, mttr)

Restricciones de seguridad (controles de acceso al sistema)

o Agregado de procesos de arranque y apagado del sistema.

• El Modelo de Distribución: Describe todas las decisiones relativas a la arquitectura de hardware

(modelo de procesadores) y a la estructuración 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 tecnología. 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 comunicación entre ellos. Implica la asignación 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 resolución gráfica) y cuantitativos (por
ejemplo: velocidad del procesador, volumen de información almacenada, etc.) para seleccionar los
procesadores, sistemas operativos, software y hardware de red, etc. Las distorsiones agregadas
corresponden a la partición del DFD, ERD, DTE en procesadores, refinamiento de procesos y
entidades o depósitos de datos (para asociar parte en un procesador y parte en otro) y a la
incorporación de procesos para el control de la comunicación entre procesadores (siempre que la
tecnología no solucione el problema de manera transparente).

28
 Análisis y Diseño de Sistemas

Según la cantidad de procesadores utilizados y las formas de comunicación entre ellos se

tienen distintas configuraciones.

Tipos de configuración típicas:

o Centralizada (host based)

o Descentralizada

o Mixta

o Distribuida

o 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 deberán duplicarse, y mantenerse copias actualizadas
en cada procesador.

Mixta: Puede darse una combinación de los casos anteriores. Es común la

existencia de un sistema central que consolida toda la información de la organización y
que en diferentes unidades operativas que no este conectadas a dicho procesador central
existan sistemas satélites que implementan algunos procesos con almacenes con datos
locales.

Distribuida: Se asignan partes del modelo esencial a diferentes procesadores los

cuales están 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 más genérico de distribución cliente-servidor distribuye el modelo del sistema
en tres niveles: presentación, lógica del negocio, y acceso a base de datos. Los dos
esquemas cliente-servidor más utilizados en la actualidad son:

C/S 2 niveles: Servidor de B.D. / Aplicación-Presentación en Estación de

Trabajo C/S 3 niveles: Servidor de B.D. / Servidor de Aplicación / Presentación en
Est.Trab.

Tipos de configuración de comunicación entre procesadores:

o Conexión directa entre procesadores (canal / red local / otros)

o Enlace de telecomunicaciones entre procesadores

o Enlace indirecto: los datos son transferidos de un procesador a otro vía algún
medio de almacenamiento (cinta, cd, diskette, etc.)

Factores que influyen en la configuración de procesadores:

29
 Análisis y Diseño de Sistemas

o Costo

o Eficiencia

o Seguridad (procesadores y datos en lugares seguros)

o Confiabilidad (separar los procesos en varios procesadores, procesos

redundantes) - Restricciones políticas y operacionales.

• El Modelo de Tareas: Los modelos resultantes de la creación del modelo de procesadores son
estudiados por separado (un procesador por vez), para determinar tareas diferentes (que serán
programas diferentes de manera tal que se pueden ejecutar concurrentemente o no). La distorsión
agregada en esta etapa representa la subdivisión 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 (comunicación solamente a través de depósitos de datos), etc. Además, es
probable que sea necesario agregar procesos de control de concurrencia y sincronización para el
acceso a recursos compartidos (como por ejemplo los depósitos 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 típicamente en Interactivas, Batch, y en Tiempo Real.

Para la mayoría de los sistemas administrativos es importante determinar que partes del modelo
esencial se asignaran a tareas interactivas y cuales a tareas batch.

La comunicación entre tareas normalmente es provista vía 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 diseñada mediante la aplicación de
las técnicas y estrategias descriptas por el Diseño Estructurado (por ejemplo: Análisis de
Transformaciones y Transacciones) y mejorada con la aplicación de criterios de calidad (por ejemplo:
Cohesión, Acoplamiento, etc.).

30
 Análisis y Diseño de Sistemas

Fig. 2.6.: Secuencia de Creación de Modelos

2.7. Métodos de desarrollo de Software.

Los métodos de desarrollo de software pueden dividirse en dos grupos: función/dato y orientados a objetos.

Orientado a Función/Dato.

Aquellos métodos en los cuales las funciones y/o los datos son tratados como entidades independientes. Estos
sistemas resultan difíciles 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 difíciles de leer y modificar. Si se desea hacer alguna modificación
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 términos de una estructura. La especificación de
requerimientos se hace en lenguaje común, se especifica la funcionalidad que debe tener el sistema y no en cómo se
deben estructurar los datos.

Orientado a Objetos: Son aquellos métodos en los cuales datos y funciones están altamente relacionados. El
énfasis está centrado en la abstracción de datos. Se piensa en forma natural, los objetos son mapeados a entidades del
mundo real. Los programas son fácilmente mantenibles y extensibles por medio de la construcción de subclases.

31
 Análisis y Diseño de Sistemas

3. Definición del Proyecto de Sistemas.

3.1. Razones para iniciar proyectos de Sistemas de Información

La siguiente tabla muestra las causas por las cuales las organizaciones toman la decisión estratégica de bordar
proyectos sobre sistemas de información en función de los parámetros mejorables de ésta.

Capacidad.

• Mayor velocidad de procesamiento

• Incremento en el volumen

• Recuperación más rápida de la información

Control.

• Mayor exactitud

• Mejora de la consistencia

Comunicación.

• Mejoras en la comunicación

• Integración de áreas de la empresa

Costos.

• Monitorización de costos

• Reducción 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 información necesaria para su posterior realización.

32
 Análisis y Diseño de Sistemas

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 Organización, debe contener la
información mínima, a fin de poder ser estudiada por el comité. Esta información a contener es:

• ¿Cuál es el problema?

• Detalles del problema

• Importancia del problema

• ¿Cuál es la solución aportada por el usuario?

• ¿En qué medida será de ayuda un sistema de información?

• ¿Qué otras personas conocen el problema y se puede contactar?

3.2.2. 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 Organización.

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 interacción con otros departamentos.

Los directivos plantean proyectos globales a toda la Organización, normalmente multidepartamentales con un
periodo de desarrollo más amplio, y normalmente asociado a políticas 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 tecnología 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 Organización.

3.3. Planificación de un proyecto de sistemas.

3.3.1. ¿Que es un proyecto de Sistema o Software?

Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades,
una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de
incertidumbre.

33
 Análisis y Diseño de Sistemas

Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en
cuenta los recursos, costos y planificación.

El tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones. A medida
que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software.

La disponibilidad de información histórica es otro elemento que determina el riesgo de la estimación.

3.3.2. Objetivos de la Planificación del Proyecto.

Es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y
planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto
de software, y deberían actualizarse regularmente medida que progresa el proyecto.

El Objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a

estimaciones razonables.

3.3.3. Ámbito del Software.

Es la primera actividad de llevada a cabo durante la planificación del proyecto de Software.

En esta etapa se deben evaluar la función y el rendimiento que se asignaron al Software durante la Ingeniería
del Sistema para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos

Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del
ámbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimación.

El ámbito se define como un prerrequisito para la estimación y existen algunos elementos que se debe tomar en
cuenta como es: la obtención de la información necesaria para el software. Para esto el analista y el cliente se reúnen
sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de interés para su desarrollo.

3.3.4. Recursos:

La segunda tarea de la planificación del desarrollo de Software es la estimación de los recursos requeridos para
acometer el esfuerzo de desarrollo de Software, esto simula a una pirámide donde las Herramientas (hardware y
Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la
pirámide se encuentran los Componentes reutilizables.

Y en la parte mas alta de la pirámide se encuentra el recurso primario, las personas (el recurso humano).

Cada recurso queda especificado mediante cuatro características:

• Descripción del Recurso

• Informes de disponibilidad

• Fecha cronológica en la que se requiere el recurso

• Tiempo durante el que será aplicado el recurso

34
 Análisis y Diseño de Sistemas

3.3.4.1. Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado
después de hacer una estimación del esfuerzo de desarrollo (por ejemplo personas mes o personas años), y seleccionar
la posición dentro de la organización y la especialidad que desempeñara cada profesional.

3.3.4.2. Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilización, esto es la creación
y la reutilización de bloques de construcción de Software.

3.3.4.3. Recursos de entorno.

El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniería 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 Ingeniería del Software, un planificador de proyectos debe
determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estén
disponibles.

3.3.5. Estimación de costos del Proyecto de Software.

En el principio el costo del Software constituía un pequeño porcentaje del costo total de los sistemas basados en
Computadoras. Hoy en día el Software es el elemento más caro de la mayoría de los sistemas informáticos.

Un gran error en la estimación del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la
estimación del costo y del esfuerzo del software nunca será una ciencia exacta, son demasiadas las variables: humanas,
técnicas, de entorno, políticas, 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 estimación para más adelante (obviamente podemos realizar una estimación al cien por
ciento fiable después de haber terminado el proyecto.

• Base las estimaciones en proyectos similares ya terminados.

• Utilice técnicas de descomposición relativamente sencillas para generar las estimaciones de costos y
esfuerzo del proyecto.

• Desarrolle un modelo empírico para él cálculo de costos y esfuerzos del Software.

Desde el punto de vista ideal, se deben aplicar conjuntamente las técnicas indicadas usando cada una de ellas
como comprobación de las otras.

Antes de hacer una estimación, el planificador del proyecto debe comprender el ámbito del software a construir
y generar una estimación de su tamaño.

35
 Análisis y Diseño de Sistemas

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 materialización sin tener pérdidas económicas y frustración profesional. La viabilidad y el análisis de
riesgos están 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 interés:

• Factibilidad Operacional

• Factibilidad Técnica

• Factibilidad Legal

• Factibilidad Financiera y Económica

El estudio de factibilidad lo lleva a cabo un equipo de personas (una o dos) que están familiarizados con
técnicas de sistemas de información, normalmente es gente experta en los procesos de Análisis y Diseño de Sistemas.
Hay tres aspectos relacionados:

Factibilidad Operacional

Las preguntas formuladas para este apartado serán:

• ¿Trabajará el sistema cuando esté terminado e instalado?

• ¿Existen barreras importantes para la implantación?

• ¿Existe apoyo por parte de los usuarios y la administración?

• ¿Los métodos que actualmente se emplean en la Organización son aceptados por los usuarios?

• ¿Han participado los usuarios en la planeación y desarrollo del proyecto?

Factibilidad Técnica

Los aspectos técnicos a considerar, son:

• ¿Existe o se puede adquirir la tecnología precisa para realizar el proyecto?

• ¿El equipo propuesto tiene la capacidad técnica para soportar todos los datos del sistema?

• ¿Puede crecer con facilidad el sistema?

• ¿Existen garantías técnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de los datos?

• Se implementarán 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
 Análisis y Diseño de Sistemas

• ¿La construcción de todo sistema esta determinado por políticas predefinidas?

• ¿El software de construcción posee el licenciamiento para tal efecto?

• ¿Quiénes participan en el desarrollo, conocen las características de la propiedad del producto de

software?

Factibilidad Financiera y Económica

Los aspectos financieros y económicos a considerar, son:

• El costo de llevar a cabo la investigación completo de sistemas

• El costo del hardware y software para la aplicación que se está considerando

• Beneficios en la forma de reducción de costos o de menores errores costosos

• El costo, si el proyecto no se lleva a cabo

3.3.5.2. Análisis Económico.

El análisis económico o análisis costo-beneficio proporciona a la gerencia una visión de los costos y riesgos
asociados con alternativas de inversión. Para los sistemas de información automatizados que requieren de la adquisición
de equipo de cómputo, es necesario evaluar la conveniencia económica de adquirirlos ya que cumplen con las
características que definen a una decisión de inversión:

• Involucra sumas importantes de dinero

• Se comprometen erogaciones futuras de fondos.

• Los resultados continúan sobre un período largo de tiempo

• Usualmente la decisión es irreversible.

• Depende de pronósticos.

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 erogarán durante la vida del mismo y que deberán ser comparados con los
beneficios esperados del proyecto. A los primeros se les conoce como costos de desarrollo o inversión inicial y a los
segundos, como costos de operación.

Para evaluar un proyecto de inversión, se deben comparar los costos con los beneficios asociados a los mismos.
A continuación se muestran algunos ejemplos de costos y beneficios que pueden presentarse en la adquisición de equipo
de cómputo:

Costos de desarrollo:
• Personal: analistas, programadores, operadores, administrativos
• Equipo: costo, instalación, pruebas, conversión
• Software: costo, instalación, mantenimiento
• Materiales: publicaciones (documentación), formas, papelería, discos, tinta
• Otros: capacitación, Luz, renta, etc.

37
 Análisis y Diseño de Sistemas

Costos de operación:
• Personal: operador, capturista, soporte técnico
• Hardware: mantenimiento
• Software: mantenimiento
• Materiales: papel, formas, discos
• Otros: auditoria, renta
Beneficios:
• Reducción en costos
• Reducción de errores
• Mayor velocidad
• Mayor flexibilidad
• Mejora en la planeación y en el control

Las decisiones de inversión se pueden clasificar de acuerdo a la relación que puede presentarse entre proyectos
en:

1. Independientes. Cuando la decisión de llevarlos a cabo no afecta a otros proyectos.

2. Mutuamente excluyentes. Cuando la aceptación del proyecto excluye a otro proyecto en estudio (existe
restricción de capital).

3. Complementarios. Cuando la aceptación de un proyecto incluye la aceptación de otro que lo

complementa.

El objetivo primordial de la evaluación de proyectos es la determinación de la alternativa de inversión más

adecuada en función de la maximización de utilidades, y para alcanzarlo, es recomendable desarrollar previamente las
siguientes tres fases.

1. Estimar la inversión neta o inicial representada por la integración 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 operación).

3. Evaluar la conveniencia del proyecto de acuerdo con la comparación de la inversión neta y los flujos
de efectivo a través del uso de los métodos de evaluación existentes para ello.

3.3.6. Inversión Neta o Inicial.

Para el cálculo de la inversión inicial, se pueden considerar los siguientes conceptos con la adquisición del
activo:

1. Precio del nuevo activo

2. Costo de instalación

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 pérdida fiscal que se genera por la venta de activos antiguos (reemplazo)

38
 Análisis y Diseño de Sistemas

3.3.7. Métodos de Evaluación de Proyectos.

Una vez conocidas la inversión 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 métodos más usuales con sus principales inconvenientes y
características: Payback, Valor Actual Neto (VAN) y Tasa interna de Rendimiento (TIR).

Payback o Período de Recuperación.

Este método calcula el número de años necesarios para recuperar la inversión inicial, su interés radica
solamente en el tiempo necesario para recuperarla, por tanto su criterio de decisión ante alternativas mutuamente
excluyentes será elegir el proyecto que recupere la inversión inicial en el menor tiempo.

Para calcular el payback, cuando los flujos de efectivo son iguales:

Payback = Inversión inicial / Flujo de efectivo anual

Ejemplo: se tiene un proyecto con inversión inicial de $ 20.000 que se espera produzca rendimientos anuales de
$ 4.000 (flujos de efectivos). ¿Cuál sería su período de recuperación o payback?

Payback = 20.000 / 4.000 = 5 años

Cuando los flujos netos de efectivo no son iguales, el payback se calcula acumulándolos hasta que la suma sea
igual al desembolso inicial.

Ejemplo: se tiene una propuesta de inversión que requiere de una salida inicial de $ 10,000 los rendimientos
esperados para la misma son los siguientes:
Año Flujo de Efectivo
1 $ 2.000
2 $ 4.000
3 $ 3.000
4 $ 3.000
5 $ 1.000
Si se acumulan los flujos de efectivo del año 1, 2 y 3, se tendría 2000+4000+3000 = 9000 por lo tanto para
recuperar la salida inicial, es necesario considerar $ 1000 a recuperar en el año 4. Para calcular el período de tiempo
proporcional del año 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 días). En este caso se hará uso de meses
y el planteamiento es: si $ 3000 corresponden a 12 meses, ¿a cuántos meses corresponden $ 1000?

3000  12

1000  x

(1000 * 12) / 3000 = 4 meses

Esto quiere decir que el período de recuperación o payback del proyecto es de 3 años y cuatro meses. Otra
manera de calcular el residual del año, es en base a la proporción de los $ 1000 que hacen falta a considerar del año 4,
esto es, 1000/3000=0.33 o 1/3 del año que representan los 4 meses.

Las principales ventajas y desventajas del payback son las siguientes:

Ventajas

• Es simple

39
 Análisis y Diseño de Sistemas

Desventajas

• No considera el valor del dinero en el tiempo.

• No considera flujos de efectivo después del payback

Valor Actual Neto (VAN)

El método 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 inversión inicial.

Cuando el valor presente neto es positivo, el proyecto es viable ya que cubre la inversión y genera beneficios
adicionales. Cuando el valor presente neto es negativo, el proyecto debe rechazarse ya que los beneficios esperados no
cubren la inversión inicial. Para seleccionar entre proyectos mutuamente excluyentes el criterio es elegir el de mayor
valor presente neto.

Entonces, el criterio de decisión es el siguiente:

Si VAN > 0 el proyecto se acepta (es positivo)

Si VAN < 0 el proyecto se rechaza (es negativo)

Este método, elimina la desventaja de los dos anteriores en relación con el valor del dinero en el tiempo, pero su
cálculo requiere de tiempo y comprensión de este concepto además de una tasa de descuento para realizar los cálculos.

La fórmula que permite calcularlo es la siguiente:

 n Rj 
VAN =  ∑  − I0
(
 j =1 1 + i )
j
) 


donde:

Rj = flujos de efectivo (beneficios – costos, del período j)

t = períodos de tiempo que van desde 1 hasta n

i = tasa de rendimiento esperada

I0 = inversión inicial

Para ejemplificar el valor del dinero en el tiempo, considérese que se tiene efectivo por $ 400 y se invierte en el
banco a una tasa del 10% anual, al final del primer año el efectivo se habrá incrementado en $40 que representa el
rendimiento anual que se ofrece al inversionista por depositar su dinero en la institución bancaria. Si esta nueva suma de
$ 440 se deja por otro año más, entonces al final del segundo año se obtendrá un rendimiento de $ 44 que conjuntamente
con los $ 440 darán un total de $484.

40
 Análisis y Diseño de Sistemas

Lo anterior significa que si una persona quisiera recuperar dentro de dos años la cantidad de $ 484, necesita
tener en el presente $ 400 e invertirlos a una tasa de interés compuesto del 10%.

Para facilitar el cálculo del valor presente, existen tablas en los libros financieros o en los libros de matemáticas
financieras que presentan el resultado de aplicar la fórmula anterior como un factor para una tasa y un período de tiempo
específico.

Ejemplo: se tienen dos proyectos de inversión el A y el B:

PROYECTO A
Año Flujo neto Factor 10% Valor presente de los flujos
1 500 0,9091 90,91
2 400 0,8264 165,28
3 300 0,7513 225,39
4 100 0,6830 273,2
Suma del valor actual de los flujos + 1078,80
Inversión Inicial 1000
Valor Actual Neto (VAN) + 78,80

PROYECTO B
Año Flujo neto Factor 10% Valor presente de los flujos
1 100 0,9091 90,91
2 200 0,8264 165,28
3 300 0,7513 225,39
4 400 0,6830 273,2
5 500 0,6209 310,45
6 600 0,5645 338,70
Suma del valor actual de los flujos + 1403,93
Inversión Inicial 1000
Valor Actual Neto (VAN) + 403,93

Si los proyectos son independientes, ambos son factibles de realizarse desde el punto de vista económico
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 método son las siguientes:

Ventajas

• Considera el valor del dinero en el tiempo.

• Considera todos los flujos de efectivo.

• Considera la contribución esperada en términos absolutos.

41
 Análisis y Diseño de Sistemas

Desventajas

• Dificultad de cálculo

• Requiere de una tasa de interés para realizar el cálculo.

Ejercicio:

La compañía Margar tiene en estudio la adquisición de un sistema de cómputo que le servirá para controlar su
línea de productos. El costo de instalación del sistema es de $700.000 en el año 0 y de $1.000.000 en el año 1 por
mantenimiento. Se esperan ahorros en mano de obra y materiales de $250,000 en el año 2, $300,000 en el año 3,
$350,000 en el año 4 y $400,000 cada año posterior hasta el año 10 que es el tiempo de vida estimado para el sistema.

a) ¿Cuál es el período de recuperación del proyecto?

b) ¿Cuál es la tasa promedio de retorno del proyecto?

c) Si la tasa de rendimiento requerida es de 15%, ¿Cuál es el valor actual neto del proyecto? ¿Es aceptable?

b) ¿Cuál sería la situación con el VAN si la tasa requerida fuera del 10%?

Tasa interna de rendimiento (TIR)

La tasa interna de rendimiento (TIR) es un método 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 fórmula que permite representar al método es la siguiente:

 n Rj 
TIR =  ∑  − I0 = 0
(
 j =1 1 + i )
j
) 

donde:

Rj = flujos de efectivo (beneficios – costos, del período j)

t = períodos de tiempo que van desde 1 hasta n

i = tasa de rendimiento esperada

I0 = inversión 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 inversión inicial. Para
seleccionar entre proyectos mutuamente excluyentes el criterio es elegir el de mayor TIR.

El cálculo 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
 Análisis y Diseño de Sistemas

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 gráficamente relacionando el valor presente neto de un
proyecto con diferentes tasas de interés:

Como puede observarse, a medida que las tasas requeridas de interés 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 método son:

Ventajas

• Considera el valor del dinero en el tiempo

• Considera todos los flujos de efectivo

• No requiere de una tasa de descuento

Desventajas

• Muy difícil de calcular

3.4. Planificación de las actividades.

En la planificación 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 número como en funcionalidad y valor, cosa que no suele
suceder en el mundo real.

Un buen punto de partida para la planificación y control de actividades de un proyecto, es dividirlo, desde el
punto de vista administrativo, en las actividades del ciclo de vida clásico de desarrollo de sistemas de información.

En cuanto a las tareas en que se divide el proyecto, es importante considerar la relación entre ellas:

• Tareas Independientes: posibilidad de realizarse en paralelo con otras tareas (no estás condicionadas)

• Tareas Dependientes: condicionadas a otras.

43
 Análisis y Diseño de Sistemas

• Secuenciales: deben guardar un orden de ejecución. Dependen de un o varias anteriores.

• Solapadas: en principio, independientes, pero se consideran así cuando no se pueden iniciar

simultáneamente. Se trata de una independencia relativa

La secuencia de tareas y, por lo tanto de trabajo, viene condicionado por tres tipos de restricciones: lógicas,
estratégicas y de recursos.

Estimación de Tiempos.

Una vez identificadas las tareas, hay que asignarles un tiempo de ejecución. En general, resulta práctico
planificar en base a días (jornadas laborales completas) y convertirlo a horas cuando se precise esta medida de tiempo.
No resulta práctico planificar con menos detalle que días de trabajo, en todo caso, convendrá agrupar tareas para
considerar, al menos, un día en la planificación.

Técnicas Gráficas para Itinerarios y Control.

El plan de trabajo debe ser elaborado y expresado mediante técnicas que, además de suponer una ayuda en la
planificación misma, aseguren su coherencia y la comprensión rápida y eficaz por parte de quienes deban conocerlo y
controlarlo.

Existen dos técnicas de definición de itinerarios, las cuales se pueden considerar clásicas, que son la base de la
mayoría de los mecanismos de definición de planes de trabajo y control: la técnica PERT y los gráficos GANTT.

3.4.1. PERT (Proyect Evaluation and Review Technique)

Técnica de evaluación y revisión de programas. La gráfica PERT, tiene gran valor cuando se planifica y diseña
el sistema. Cuando se termina la gráfica de relaciones, se puede determinar la ruta crítica. La gráfica se basa en círculos
que representan acontecimientos y líneas que muestran actividades (puede haber ficticias con tiempos ceros). También
muestra la interdependencia de las tareas y ayuda a responder:

¿Qué actividades deben preceder o se deben completar antes del inicio de una actividad específica?

¿Qué otras actividades se pueden llevar a cabo en tanto una actividad específica se encuentra en proceso?

¿Qué actividades no se pueden iniciar hasta después de terminar una actividad específica?

Para desarrollar la red PERT primero se deben determinar las tareas y los tiempos relacionados con cada
actividad. A continuación, se debe identificar la secuencia de realización de las actividades. Esto es: ¿Qué actividades se
pueden realizar al mismo tiempo?, ¿Cuáles deben preceder a otras? y ¿cuáles deben ir después de otras?

Ejemplo:

A Alejandro Limón se le ha asignado la tarea de preparar el reporte anual de la compañía. Alejandro ha

identificado 7 actividades, sus antecedentes y el tiempo necesario para realizarlas.
Actividad Antecedente Tiempo semanas
A. Tener preparados los estados financieros --- 4
B. Escribir los artículos de los estados financieros --- 6
C. Auditar los estados financieros A 3
D. Organizar el reporte anual C, B 2
E. Obtener la aprobación del presidente C, B 3
F. Imprimir el reporte D 5
G. Distribuir el reporte F, E 8

44
 Análisis y Diseño de Sistemas

A continuación se muestra el diagrama PERT y CPM para que Alejandro cumpla con su función de una mejor
manera.

En el ejercicio, la ruta crítica 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 Gráficas de Gantt.

Es una tabla de doble entrada que asocia tiempo y actividades y muestra en la intersección de las líneas con las
columnas, la duración de cada actividad. De todas las técnicas de planificación, la más conocida y utilizada es, sin duda,
el diagrama de GANTT, que recibe el nombre de su inventor.

45
 Análisis y Diseño de Sistemas

Esta representación básica admite variaciones sin cambiar su estructura, tal como representar, con otro tipo de
línea, fases o conjunto de tareas y luego detallar las tareas o subtareas, que quedarán dentro de los márgenes de la fila de
conjunto.

Como puede verse, la carta Gantt presenta en gran medida el mismo tipo de información que el diagrama Pert;
su principal diferencia es el hecho de que muestra gráficamente la duración de una actividad, mientras el diagrama Pert
no lo hace.

Dado que es una representación un tanto más tabular del proyecto, a menudo puede usarse para representar una
gran cantidad de información en una forma relativamente compacta.

46
 Análisis y Diseño de Sistemas

3.5. Análisis Económico y Técnico.

El análisis económico incluye lo que llamamos, el análisis de costos – beneficios, significa una valoración de la
inversión económica comparado con los beneficios que se obtendrán en la comercialización y utilidad del producto o
sistema.

En el Análisis Técnico, el Analista evalúa los principios técnicos del Sistema y al mismo tiempo recoge
información adicional sobre el rendimiento, fiabilidad, características de mantenimiento y productividad.

Los resultados obtenidos del análisis técnico 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 selección y revisión de proyectos

Se generan muchas solicitudes para el desarrollo de sistemas de las que las Organizaciones pueden emprender,
obliga a un proceso de selección y priorización.

Uno de los métodos más 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 evalúan las
propuestas. Para la toma de decisión en firme necesitan mayor información que la contenida en la propuesta, por lo que
deciden realizar un estudio preliminar.

Comité de Sistemas de Información

El comité formado por profesionales del departamento de sistemas de información. Este comité aprueba o
rechaza proyectos y fija las propiedades y también indica qué proyectos son más importantes, dándoles atención
inmediata. Esta composición 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 diseñadores. Pero puede ocurrir que varios
departamentos pequeños que trabajan de forma independiente para alcanzar la misma meta pueden estar, de manera
inconsciente, desperdiciando recursos y perdiendo la oportunidad para coordinar la planificación de un sistema de
información, compartido e integrado que podría beneficiar a toda la empresa.

Aprobación 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 organización, para ser atendidos lo más rápido posible, según los recursos
de la organización.

Dentro de los beneficios que el sistema podría brindar tenemos:

• Obtención de información no disponible actualmente

• Elaboración más oportuna de la información

47
 Análisis y Diseño de Sistemas

• Mejoras en las operaciones de la organización

• Posibilidades de efectuar cálculos o estimaciones que actualmente no es posible

• Reducción de costo

• Obtención de una posición competitiva dentro del mercado

• Mejoras en la toma de decisiones.

• Mejoras en la imagen, atención, seguridad, etc.

48
 Análisis y Diseño de Sistemas

4.- Análisis, Determinación y Especificación de Requerimientos

4.1.- Análisis de Requerimientos

La tarea de análisis de los requerimientos es un proceso de descubrimiento y refinamiento de la información. El

contexto del programa establecido previamente es refinado en detalle.

Tópicos:

• función y comportamiento de los programas

• interfaz con diferentes partes del sistema

• técnicas de revisión

Actores del proceso: Cliente (s), Analista, Equipo de desarrollo

Tareas del análisis:

1. Reconocimiento del problema se realiza mediante entrevistas con el cliente para reconocer elementos
básicos del sistema a desarrollar

2. Evaluación del problema y síntesis de la solución se refiere a la evaluación de flujo y estructura de la

información, refinamiento en detalle de todas las funciones del programa, y finalmente elaboración de
una o más alternativas de solución del problema.

3. Especificación es un documento que se elabora para ser revisado y aprobado para el cliente

4. Revisión son los criterios de validación del programa terminado

Analista de sistemas, diseñador jefe de proyecto, programador/analista etc., deben tener

• Habilidad para comprender los aspectos abstractos, reorganizarlos en divisiones lógicas y sintetizar
"soluciones" basadas en cada división

• 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
 Análisis y Diseño de Sistemas

Áreas de problemas:

Ya que análisis de requerimientos es una actividad intensiva de comunicación, siempre existe ruido (mala
interpretación, omisión). Conforme crece el tamaño del problema, crece también la complejidad de la tarea de análisis.
Cada nuevo elemento puede tener efecto sobre otros elementos. Problemas:

• pobre comunicación, que hace difícil la adquisición de la información

• técnicas y herramientas inadecuadas que producen especificaciones inadecuadas e imprecisas

• tendencia a acortar el análisis de requerimientos, conduciendo a un análisis inestable

• un fallo en considerar alternativas antes de especificar el software

La tarea de análisis de requisitos es un proceso de descubrimiento, refinamiento, modelado y especificación. Se

refina en detalle en detalle el ámbito del software, inicialmente establecida por el ingeniero de sistemas y refinada
durante la planificación temporal del proyecto. Se crean los modelos de los requisitos de datos, flujo de información 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 análisis y especificación de los requisitos. El
cliente intenta reformular su concepto a veces confuso de función del software y rendimiento en detalles concretos. El
desarrollador actúa como un interrogador, como consultor y como la persona que resuelve el problema.

El análisis y la especificación de los requisitos puede parecer una tarea relativamente sencilla, pero las
apariencias engañan. El contenido de comunicación es muy denso. Abundan ocasiones para las malas interpretaciones o
falta de la información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software
puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo “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 análisis de requisitos permite al ingeniero de sistemas especificar la función y el rendimiento, indica la

interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

La primera reunión 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 llevarán a un
entendimiento básico de problema, que solución busca, la naturaleza de la solución 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 podría preguntar:

• ¿Quién esta detrás de la solicitud de este trabajo?

• ¿Quién utilizará la solución?

• ¿Cuál será el beneficio económico del éxito de una solución?

• ¿Hay alguna otra alternativa para la solución 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 solución.

• ¿Cómo caracterizaría un buen resultado generado por una solución?

• ¿A qué tipo de problemas va dirigida la solución?

• ¿Puede mostrarme (o describirme) el entorno en que se utilizará la solución?

• ¿Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la
solución?

50
 Análisis y Diseño de Sistemas

Y el último conjunto de preguntas esta enfocado en la eficacia de la reunión:

• ¿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 más que pueda proporcionar información adicional?

• ¿Hay algo más que debería preguntarle?

Estas preguntas (y otras) ayudarán a romper el hielo e iniciar la comunicación tan importante para el éxito del
análisis.

Después de esta entrevista inicial se procede a tener entrevistas regulares con diferentes personas dentro de la
organización para obtener la información más fidedigna sobre la organización, resolviendo los posibles conflictos de
información, preparando cada una de estas reuniones y haciendo especificación las cuales deben ser autorizados por el
cliente antes de pasar a la fase de diseño.

4.2. Determinación de requerimientos

Determinar requerimientos consiste en estudiar un sistema para conocer como trabaja y donde es necesario
efectuar mejoras.

Un requerimiento es una característica que debe incluirse en el nuevo sistema. Esta puede ser la inclusión de
determinada forma para capturar o procesar datos, producir información, 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 situación.

El primer paso del analista es comprender la situación actual.

4.2.1. Actividades de la determinación de Requerimientos

• Anticipación de Requerimientos

Prever las características del sistema con base en la experiencia previa. Esto puede llevar al analista a
investigar áreas y aspectos que de otra forma no serían tomados en cuenta.

La experiencia permite anticipar requerimientos para el nuevo sistema.

• Investigación de Requerimientos

Estudio y documentación del sistema actual utilizando para ello técnicas para hallar hechos, análisis de
flujos de datos y análisis de decisión.

Es la actividad más importante.

51
 Análisis y Diseño de Sistemas

• Especificación de Requerimientos

Análisis 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. Investigación de Requerimientos.

Los analistas estructuran su investigación en base a 4 preguntas:

1. ¿Cuál es el proceso básico 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 realización?

4.3.1. ¿Cuál es el proceso básico de la empresa? Las siguientes preguntas se utilizan para adquirir la
comprensión necesaria:

• ¿Cuál 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?

• ¿Cuánto tiempo tardan en efectuarlos?

• ¿Con cuanta frecuencia lo hacen?

• ¿Quienes emplean la información resultante?

4.3.2. ¿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 nómina se repite mensualmente o semanalmente pero el pago de
impuestos es anualmente.

La manera más fácil de obtener esta información es identificar el objetivo de la actividad, es decir, cuál es la
causa de la actividad.

El volumen de los procesos puede aumentar el tiempo de realización de las actividades, es decir la cantidad
total de pasos que puede constar una actividad puede generar problemas aún ocurriendo con poca frecuencia.

52
 Análisis y Diseño de Sistemas

4.3.4. ¿Qué controles utiliza para su realización?

La falta o debilidad de los controles es un descubrimiento importante en cualquier investigación del sistema.

El analista debe examinar los métodos de control preguntando:

• ¿Quién se encarga de comparar lo realizado con los estándares?

• ¿Cómo se detectan los errores?

• ¿Cómo se corrigen los errores?

Respuestas concisas a estas preguntas proporcionan un conocimiento amplio de una actividad en particular y
muestra también su objetivo. Pero analista no se detiene ahí, todavía no existe información para comprender en su
totalidad la actividad; más bien lo que se tiene son los antecedentes que permiten a los analistas formular preguntas más
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 información:

• nombre de la entidad

• nombre los campos

• descripción

• fuente y sensibilidad (= seguridad)

• valor o importancia de los datos

• relaciones de los campos y entidades

• Criterio de retención y almacenamiento.

53
 Análisis y Diseño de Sistemas

4.3.5. Preguntas clásicas para una determinación de requerimientos:

Preguntas generales:

• ¿Cuántos empleados laboran para la organización en el área(s) que se pretende desarrollar el sistema?;
o sea, ¿cuántos tienen relación directa con el proyecto que se está investigando?

• ¿Cuáles son las personas claves en el sistema? ¿Por qué son importantes?

• ¿Existen obstáculos o influencias de tipo político que afectan la eficiencia del sistema?

• ¿Existen manuales de procedimientos, políticas o lineamientos de desempeño 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 métodos para evadir el sistema?, ¿Por qué se presentan?

• ¿Qué áreas necesitan un control específico?

• ¿Qué criterios se emplean para medir y evaluar el desempeño?

Por otra parte:

• ¿Existen actividades que considere podrían mejorarse?, ¿De qué manera?

• ¿Tiene alguna idea de actividades que podrían implementarse para mejorar el rendimiento del sistema
en general?

Determinación de procesos:

• ¿Cuáles son las principales actividades que se realizan en la organización y que tienen relación con el
proceso que se está modelando?

Descripción de cada proceso identificado

• ¿Qué es lo que da inicio a la actividad?

• ¿Cuál es el objetivo de la misma?

• ¿Cuánto tiempo se tarda en realizarla?

• ¿Qué retrasos ocurren o pueden ocurrir?

• ¿Qué métodos se emplean para medir y evaluar el desempeño de esta actividad?

• ¿Se toman precauciones específicas de seguridad para la protección 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, ¿Cuál es el volumen de información que aquí
se procesa?

• ¿Qué pasos, sub-procesos, o funciones constituyen la actividad? (describir la actividad paso a paso)

• ¿Existe algún tipo de control desarrollado en el proceso en cuestión?

54
 Análisis y Diseño de Sistemas

Determinación de datos (flujos y contenido de los flujos) - hacer la pregunta por cada proceso o actividad
identificada -

• ¿De dónde proviene la información que se utiliza en esta actividad? (fuentes)

• ¿Cuáles son específicamente 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? (documentación

involucrada)

• ¿Qué información se genera en esta actividad? (producto de la actividad)

El resultado identificado anteriormente producto de los datos que se procesan ¿Hacia qué o quién van
dirigidos?–persona o entidad- (destinos)

• ¿Con qué finalidad la utilizan?

• ¿Cuáles datos se conservan o almacenan en este proceso? Y ¿en qué forma quedan almacenados?

• ¿Existe información que se genera pero que no es utilizada nunca por nadie? (partes extrañas)

Para cada dato identificado:

• ¿Qué formato posee cada dato que interviene en esta actividad?

• ¿Para qué es usado?

• ¿Se interpone algún tipo de seguridad para la verificación de la veracidad del dato en mención?

• ¿Qué tan importante es dicho dato?

• ¿Por cuánto 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, además de las
anteriores, formular otras preguntas para determinar los requerimientos de las decisiones, un esbozo de las mismas bien
podría ser:

• ¿Qué información se usa para tomar la decisión?

• ¿Cuál es la fuente de esa información? ¿Qué sistemas transnacionales producen los datos utilizados en
el proceso de decisión? ¿Qué otros datos son necesarios y no es posible obtener del procesamiento de
transacciones? ¿Qué datos se originan en fuentes externas a la organización?

• ¿Cómo se deben procesar los datos para producir la información necesaria?

• ¿Cómo debe presentarse la información?

Una vez que se tenga recopilado el conjunto de hechos que se generan con relación al sistema que estamos
modelando, es posible dar una especificación de requerimientos, mediante como se dijo un análisis de los datos
obtenidos durante la recopilación de hechos. Es después de esto entonces, que se puede ya dar un conjunto de
requerimientos que nos servirán para modelar el sistema mediante un DFD y del que surge el diagrama E-R

55
 Análisis y Diseño de Sistemas

4.3.1. Método de trabajo para la recopilación de información

La recopilación de información, especialmente en un sistema grande y complejo, puede ser una tarea ardua. La
información 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 búsqueda 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 información

Una de las actividades más importantes para los participantes en desarrollo de sistemas de información
automatizados es la obtención de información que permita comprender el esquema de trabajo en donde se encuentra el
sistema, por lo que, es necesario identificar dónde y cómo es posible obtenerla. El dónde, 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 través de los cuales es posible recopilarla.

Las fuentes de información se pueden clasificar en internas y externas, las primeras, se encuentran disponibles
dentro de la organización y las segundas, se refieren a las fuentes de información que pueden ser localizadas fuera de la
misma.

Fuentes de información internas

Información verdaderamente útil en el desarrollo de sistemas de información automatizados, se encuentra en las

siguientes fuentes:

Sistema Actual.

El sistema actual es la fuente más importante de información para los involucrados en el desarrollo de los
sistemas de información automatizados. A pesar del costo y tiempo requeridos para obtener información acerca de su
funcionamiento, presenta las siguientes ventajas:

1. Conocerlo, permite al analista definir si el sistema es correcto, si solamente requiere de pequeñas

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 diseño.

3. Se conocen a profundidad, los recursos humanos, materiales y de equipo con los cuales es posible
implementar el nuevo sistema. Además de la formación intelectual del elemento humano (Know how)).

4. En la fase de implementación facilita las pruebas ya que el analista sabe cómo eran las cosas.

5. Permite comparar el nuevo sistema con el anterior, establecer sus similitudes y de con conocimiento,
evitar la reacción negativa al cambio.

Personas.

El recurso humano relacionado directamente con el sistema es el más 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 organización que puedan relacionarse con el nuevo sistema, proporcionan
información sobre las características de los estándares de diseño que el sistema deberá adoptar, así también pueden
aportar información valiosa en la fase de análisis para conocer las políticas institucionales respecto a hardware, software
y recursos humanos.

56
 Análisis y Diseño de Sistemas

Documentos y archivos.

En todas las organizaciones, existen por escrito elementos que pueden permitir al analista establecer el diseño
del nuevo sistema en un marco acorde con el funcionamiento de la organización. Estos elementos pueden ser
reglamentaciones, políticas, estructura organizacional, procedimientos, descripción de funciones, etc. todos ellos
generalmente se encuentran en forma de manuales o reglamentos, los cuales es conveniente solicitar para su análisis
desde la fase inicial del desarrollo de sistemas.

Los archivos integran documentalmente toda la información que se maneja en un área de trabajo. El analista de
sistemas, debe recurrir a los archivos para obtener información sobre el desarrollo normal del trabajo del área en estudio,
conociendo los formatos usados, verificando su llenado, analizando sus problemas, etc.

Fuentes de información externas.

Otros sistemas similares al que se piensa desarrollar, los proveedores, los clientes, los distribuidores, los cursos
o los libros, pueden ser fuentes de información valiosa para el diseño del sistema considerando que son algunos de los
involucrados en las operaciones de la organización y por tanto los que cuentan con información valiosa para ser
considerada.

Otros Sistemas.

Puede tenerse conocimiento de sistemas similares al que se encuentra en estudio, estos sistemas pueden
proporcionar información sobre factores importantes a considerar tanto en el análisis como en el diseño del sistema.
Aunque no debe perderse de vista que los sistemas se diseñan de acuerdo con las condiciones propias de cada
organización.

Proveedores, clientes y distribuidores.

Tanto proveedores como distribuidores y clientes son personas relacionadas con los procesos que se realizan en
la organización, además de que en el caso de clientes y distribuidores son los que reciben el servicio final de la
organización, por tanto, pueden emitir opiniones interesantes y que sirvan de apoyo al analista sobre fallas o sugerencias
de mejoras que podría 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 información valiosa para desarrollar mejor la tarea del analista.
Adicionalmente, todas las máquinas al adquirirse, proporcionan instructivos sobre su uso los cuales son otra fuente de
información con la cual se puede conocer con facilidad el equipo o software actualmente en uso así como sus principales
características.

Cursos o Seminarios.

Cuando el analista de sistemas acude a cursos o seminarios sobre el tema, puede contar con información valiosa
que le permita desarrollar su trabajo de manera estructurada y por tanto con mayor facilidad.

4.3.2. Medios para la recopilación de Información.

Hasta aquí, se han considerado las fuentes de información más relevantes para el analista de sistemas. Sin
embargo, es necesario señalar los medios a través de los cuales la información puede ser recopilada de entre estas
fuentes, los cuales pueden se describen en las siguientes líneas.

57
 Análisis y Diseño de Sistemas

1. Revisión de Documentos.

Uno de los medios más importantes de recolección de datos, es la revisión tanto de manuales, como de formas,
procedimientos y en general de cualquier documento que contenga información relevante para el desarrollo del sistema.
La revisión de documentos provee de información sobre errores que se cometan en los procesos normales de trabajo y
sobre las tareas que no se terminen por lentitud en el desempeño del trabajo. Los documentos pueden ser revisados en su
contenido cuantitativa y cualitativamente, algunos ejemplos de los primeros son: informes financieros, informes de
desempeño; la revisión cualitativa puede hacerse a memorandos, avisos y manuales que ofrecen información sobre la
ideología de la institución. En esencia este medio permite obtener información acerca de lo que es en contraposición a lo
que debería ser.

Formularios

Los formularios son transportes de datos y existen en todas las formas y tamaños.

Se usan para muy diversos propósitos, por ej.: pedidos de provisiones para un restaurante, saldo de una cuenta
bancaria, informe de fabricación de ciertos artículos, solicitudes de inscripción, actas de exámenes, etc.

Se debe obtener una copia de cada formulario usado en el sistema, ya sea que se origine dentro o fuera de la
organización. El mejor modo de ver cómo se usa un formulario, es obtener una copia del formulario vacío y otro lleno.

De cada formulario se debe conocer:

• ¿Cuál es el objetivo del formulario?

• ¿Quién lo llena?

• ¿Dónde es enviado? ó ¿De dónde viene?

• ¿Quién usa el formulario?

• ¿Qué autoridad lleva?

Muestreo

Esta técnica consta de reunir sólo 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, podría 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 información puede obtenerse usando muestreo. Saber cuánto y qué dato seleccionar es un trabajo para
especialistas que usan técnicas estadísticas.

2. Entrevista.

La entrevista es un medio de obtener información de las personas conocedoras a través de preguntas que
propone el entrevistador, dicho de otra manera, es un intercambio de información cara a cara, con un propósito
específico.

En el desarrollo de sistemas, la entrevista es el medio más significativo y productivo del que disponen los
participantes en la recolección de información, además, 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 simpatía con ellas, lo
cual es benéfico para el desarrollo del estudio.

58
 Análisis y Diseño de Sistemas

Como todo trabajo, el entrevistador debe planificar la entrevista antes de realizarla y contemplar al menos los
siguientes puntos:

1. Análisis de antecedentes

2. Determinación del objetivo de la entrevista

3. Selección de entrevistados

4. Preparación del entrevistado

5. Selección y tipo de preguntas: Las entrevistas pueden efectuarse estructuradamente o no.

Entrevista estructurada se refiere a que previo a la realización 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 efectúe de manera libre, en forma de plática durante
la cual el entrevistador permitirá que espontáneamente surja el tema de su interés. 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 espontáneamente durante la entrevista.

Desventajas

• Los entrevistadores pueden introducir sesgos en las preguntas o al informar de los resultados.

• Puede producir información sobre áreas que se minimizaron o en las que no se pensó que fueran
importantes

• El análisis e interpretación se dificulta y requiere de tiempo.

• En general se necesita de más tiempo para su desarrollo.

Entrevista Estructurada.

Ventajas.

• Asegura la elaboración uniforme de las preguntas para todos los que van a responder.

• Alto costo de preparación

• Fácil de administrar y evaluar. Los que responden pueden no aceptar un alto nivel en la estructura y el
carácter mecánico de las preguntas.

• Evaluación más objetiva tanto de quienes responden como de las respuestas a las preguntas.

59
 Análisis y Diseño de Sistemas

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 espontánea, así como la habilidad del
entrevistador para continuar con comentarios hacia el entrevistado.

• Resulta en entrevistas más 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 combinación de las dos
anteriores.

A continuación se describen algunos factores a considerar Antes, Durante y Después de realizar una entrevista:

Antes de La Entrevista.

1. Organizar y preparar la entrevista considerando :

1.1. La posición que ocupa en la organización el futuro entrevistado

1.2. Las actividades básicas 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 señalar la naturaleza del proyecto sobre el cual se está trabajando, sus
propósitos y sus objetivos.

1.2. Explicar la función del analista y lo que se espera del entrevistado.

2. En relación 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
 Análisis y Diseño de Sistemas

2.2. No probar reacciones.

2.3. No creer que sabe más que el entrevistado porque el experto es él.

2.4. Evitar terminología técnica, como por ejemplo hablar de cerebros electrónicos, 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 críticas 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 polémica con el entrevistado.

2.11. Seguir las reglas de cortesía y de trato amable como: ser puntual, cortés, calmado, paciente,
profesional, mostrar interés 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 presentándole 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 información 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.

Después 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 confirmación, correcciones o
adiciones.

4. De ser necesario solicitar nuevamente cita.

5. Archivar los resultados de la entrevista para referencias posteriores.

61
 Análisis y Diseño de Sistemas

3. Cuestionario.

El cuestionario es una técnica que permite recoger opiniones, posturas, conductas y características de personas
o situaciones a través 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 física o bien, cuando el grupo del cual se obtendrá la
información es numeroso (grupo de vendedores) o como posible medio de verificación de la información obtenida por
otros medios.

En la elaboración de un cuestionario, es necesario definir:

1. Qué datos se desean conocer (Objetivo) y quiénes son las personas más calificadas para
proporcionarlos.

2. Seleccionar el tipo de preguntas más adecuadas: abiertas, cerradas o mixtas.

3. Desarrollar un conjunto de preguntas (considerando la forma de análisis de las respuestas (tabulación

manual o electrónica)).

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 edición y de presentación.

8. Aplicar el cuestionario considerando :

8.1. Distribuir el cuestionario de ser posible con los nombres de cada persona (solamente si la
información no implica compromisos).

8.2. Distribuir el cuestionario con una explicación del propósito del mismo, así como del uso que se
dará a las respuestas y si es necesario especificar el carácter 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
 Análisis y Diseño de Sistemas

8.5. Establecer de forma amable el tiempo límite para la devolución del cuestionario.

9. Codificar y capturar la información.

10. Analizar la información recopilada

4. Observación.

La observación es una técnica que permite obtener información en forma directa a través del sentido de la vista.
Permite al observador determinar qué se está haciendo, cómo se está haciendo, quién lo hace, cuándo se realiza, cuánto
tiempo ocupa en realizarse, dónde se hace y por qué se hace.

La observación, brinda información al observador acerca de las diferencias entre lo que debería suceder de
acuerdo con los procedimientos normales de operación, controles establecidos, requisición de formas y período de
tiempo para la realización 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, información
manejada de memoria, información sin archivar, etc.

Existen varios métodos de llevar a cabo la observación. Se puede observar alguna persona o actividad sin que el
observado se dé cuenta y sin que el observador realice ninguna interacción con el observado, también 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 observación, es conveniente considerar los siguientes
lineamientos:

1. Determinar lo que se va a observar

2. Estimar el tiempo necesario de observación

3. Obtener autorización para efectuar la observación (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 observación considerando :

5.1. Familiarizarse con los componentes físicos del área en observación

5.2. Mientras se observa, tomar el tiempo en forma periódica

5.3. Anotar lo que se observa de manera específica 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 educación y seguridad en su caso.

6. Documentar y organizar formalmente las notas de la observación.

7. Es conveniente, revisar al final de la observación, los resultados y conclusiones de la misma tanto con
las personas observadas como con sus superiores inmediatos.

63
 Análisis y Diseño de Sistemas

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 observación se utilice conjuntamente con
algún otro medio de recopilación de datos como puede ser la entrevista (con la finalidad de prepararla o bien, de
estructurarla).

La observación es costosa ya que requiere de tiempo y experiencia por parte del observador.

En realidad la observación es más 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 decisión el cual es a veces
es más fácil de entender a través de otros medios como por ejemplo el de la entrevista.

A continuación se presenta un conjunto de comportamientos que el observador debe tener en cuenta en la

observación de la conducta del tomador de decisiones.
• 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 teléfono
• Realiza llamadas
• Lee información externa
• Lee información interna
• Procesa su propia información
• Le pide a otros que procesen su propia información

4.4. Especificación de Requerimientos.

Es un proceso de representación que esta basado en los siguientes principios:

• Separar funcionalidad de implementación: la especificación es una descripción de lo que se desea, en

vez de cómo se implementa.

• Se necesita un lenguaje de especificación de sistemas orientado al proceso, que es un modelo de

comportamiento deseado en términos de respuestas funcionales a distintos estímulos de entorno.

• Una especificación debe abarcar el sistema del cual el software es una componente. Solo dentro del
contexto del sistema completo y de la interacción entre las partes puede ser definido el
comportamiento de una componente específica.

• Una especificación debe abarcar el entorno en el que el sistema opera.

• Una especificación de sistema debe ser un modelo cognitivo, que es la descripción del sistema tal
como es.

• Una especificación debe ser operacional, en el sentido de ser lo suficientemente completa y formal
como para poder evaluar diferentes alternativas de implementación.

64
 Análisis y Diseño de Sistemas

• Una especificación del sistema debe ser tolerante con la incompletitud y complementable.

• Una especificación debe ser localizada y débilmente acoplada frente a las posibles modificaciones a
ésta.

• El formato de representación y el contenido deben ser adecuados al problema

• Debe añadirse la información contenida dentro de una definición, en capas de información para
representar el nivel de detalle adecuado para comprenderla

• Debe restringirse el número de formas notariales y estás deben ser consistentes en su uso.

• Las representaciones deben ser revisables.

4.4.1. Herramientas para documentar procedimientos y decisiones.

Se presentan 3 herramientas para documentar procedimientos:

1. Árboles de decisión

2. Tablas de decisión

3. Español 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
decisión. 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 situación, 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 Decisión.

Características de los árboles de decisión.

El árbol de decisión 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 método permite mostrar la
relación que existe entre cada condición y el grupo de acciones permisibles asociado con ella.

La raíz del árbol, aparece en la parte izquierda del diagrama y esté es el punto donde comienza la secuencia de
decisión. La rama a seguir depende de las condiciones existentes y de la decisión que debe tomarse. Al avanzar de
izquierda a derecha por una rama particular, se entiende una serie de toma de decisiones. Después de cada punto de
decisión, se encuentra el siguiente conjunto de decisiones a considerar. De tal forma que los nodos del árbol representan
condiciones y señalan la necesidad de tomar una determinación 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
 Análisis y Diseño de Sistemas

Uso de árboles decisiones.

El desarrollo de árboles de decisión 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 difícil para ellos pasar por alto cualquier etapa del proceso de decisión, sin importar
que este dependa de variables cuantitativas o cualitativas. Los árboles también obligan a los analistas a considerar la
consecuencia de las decisiones.

Se ha demostrado que los árboles de decisión son eficaces cuando es necesario describir problemas con más de
una dimensión o condición. También son útiles para identificar los requerimientos de datos críticos que rodean al
proceso de decisión, 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 decisión, aunque el árbol de decisión no muestra todo los datos.

Si los árboles de decisión se construyen después de completar el análisis de flujo de datos, entonces es posible
que los datos críticos 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 precisión cada dato necesario para tomar la decisión.

Los árboles de decisión no siempre son la mejor herramienta para el análisis de decisiones. El árbol de
decisiones de un sistema complejo con muchas secuencias de pasos y combinaciones de condiciones puede tener un
tamaño considerable. El gran número de ramas que pertenecen a varias trayectorias constituye más un problema que una
ayuda para el análisis. En estos casos los analistas corren el riesgo de no determinar qué políticas o estrategias de la
empresa son la guía para la toma de decisiones específicas. Cuando aparecen estos problemas, entonces es momento de
considerar las tablas de decisión.

Sirven para organizar la información recopilada con respecto a la toma de decisiones y no haya malas
interpretaciones.

Condición Acción

Condición

Condición Condición Acción

Raíz
Condición Acción

Condición Acción

Fig. 4.1: Árbol de Decisión

4.4.1.2. Tablas de Decisión.

La tabla de decisión es una matriz de renglones y columnas que indican condiciones y acciones. Las reglas de
decisiones, incluidas en una tabla de decisión establecen el procedimiento a seguir cuando existen ciertas condiciones.
Este método se emplea desde mediados de la década de los 50, cuando fue desarrollado por General Electric para el
análisis de funciones de la empresa como control de inventarios, análisis de ventas, análisis de créditos y control de
transporte y rutas.

66
 Análisis y Diseño de Sistemas

Características de las tablas de decisión.

Las tablas están integradas por cuatro secciones: identificación de condiciones, entradas de condiciones,
identificación de acciones y entrada de acciones. La identificación de condiciones señala aquellas que son relevantes. La
entrada de condiciones indican qué valor, así es que lo hay, se debe asociar para una determinada condición. La
identificación de acciones enlista el conjunto de todos los pasos que se deben seguía cuando se presenta cierta condición.
La entrada de acciones muestra las acciones específicas 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 decisión 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 decisión. La regla de decisión incorpora todas las condiciones
que deben ser ciertas y no sólo una a la vez.

Ejemplo:

Pago de los servicios médicos

La atención sanitaria en un hospital es de carácter obligatorio, sin preocupar la financiación de la asistencia. Si

el paciente dispone de seguridad social, su asistencia estará exenta de pago, sino es así pero dispone de un seguro
médico sólo hará frente al pago de la consulta. Sólo en el caso de no disponer el paciente ni de seguridad social, ni de
seguro médico pagará todos los servicios.

Condiciones Reglas de Decisión

1 El paciente tiene seguro médico SI SI NO NO
2 El paciente tiene seguro social SI NO SI NO
Acciones
1 Pagar la consulta X
2 Exento de pago X X
3 Pagar todos los servicios X
Fig. 4.2: Pago de los servicios médicos

¿Cómo construir tablas de decisión?

1. Identificar las condiciones en la decisión.

2. Identificar las acciones.

3. Estudiar las posibles combinaciones de condiciones. Si N condiciones 2N Combinaciones.

4. Llenar la tabla con las reglas de decisión.

5. Marcar las entradas correspondientes con una X.

6. Examinar la tabla para detectar reglas redundantes.

Pensemos en una tabla de decisión con el siguiente formato:

67
 Análisis y Diseño de Sistemas

Reglas de Decisión
Condiciones R1 R2 R3 R4 R5 R6 R7 R8
C1 Suficiente efectivo SI SI SI SI NO NO NO NO
C2 Crédito bueno SI SI NO NO SI SI NO NO
C3 Desea "hacerse a un lado" SI NO SI NO SI NO SI NO
Acciones
A1 Seleccionar el artículo a comprar X X X X X
A2 No seleccionar ningún artículo X X X
Fig. 4.3: Tabla de decisión con contradicciones

Verificación de tablas de decisión

Después de construir una tabla debe comprobarse:

1. Que sea completa: es decir que no se haya omitido ningún posible estado de las condiciones.

2. Que no tenga redundancias ni contradicciones:

Redundancia:

Es cuando aparece repetido el mismo estado de condición con el mismo tratamiento, es decir, dos
reglas de decisión son idénticas salvo para una condición y las acciones para las dos reglas son
idénticas. R1 y R2.

Contradicción:

Es cuando aparece repetido el mismo estado de condición 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

Reglas de Decisión
Condiciones R1 R2 R3 R4 R5 R6
C1 Suficiente efectivo SI - SI NO NO SI
C2 Crédito bueno SI SI NO NO NO NO
C3 Desea "hacerse a un lado" - SI SI SI NO NO
Acciones
A1 Seleccionar el artículo a comprar X X X X
A2 No seleccionar ningún artículo X X
Fig. 4.4: Tabla de decisión filtrada

4.4.1.3. Español Estructurado.

Consiste en expresar los procesos en español con restricciones, es decir, formar sentencias en español. También
se le conoce como lenguaje de diseño de programas. El fin de esta herramienta es crear un equilibrio entre la precisión
de un lenguaje formal de programación y la informalidad del lenguaje español.

Una sentencia en lenguaje español puede consistir en una ecuación algebraica como X = (Y * Z) / (Q + 14) pero
también podemos utilizar los verbos siguientes:

68
 Análisis y Diseño de Sistemas

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 día 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 español.

1. Operadores

Aritmético: + - * / Div() Mod() Raiz() Cuadrado()

Relacional: = <> > < >= <=

Lógicos: Y O NO

Asignación:  =

2. Sentencias de Lectura y Escritura

Lectura desde dispositivo de entrada cualquiera: Leer( )

Escritura a dispositivo de salida cualquiera: Mostrar( ) o Escribir( )

3. Sentencias de Selección

Si-Entonces-Sino.

Es usada para describir alternativas y puede tomar las 2 formas siguientes:

Si (condición) Entonces
sentencia (1)
Fin-Si

Si (condición) Entonces
sentencia (1)
Sino

69
 Análisis y Diseño de Sistemas

sentencia (2)
Fin-Si
En Caso de.

Es usada para describir alternativas basadas en múltiples 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 Repetición

Mientras-Hacer.

Es usada para describir una sentencia que repetirá las acciones hasta que la condición evaluada sea falsa.
Mientras (condición) Hacer
sentencia
Fin-Mientras
Repetir-Hasta.

Es usada para describir una sentencia que repetirá las acciones hasta que la condición evaluada sea verdadera.
Repetir
sentencia
Hasta condición
Para-Hacer.

Es usada para describir una sentencia que repetirá las acciones una cantidad de veces determinada por los
valores de inicio y término.
Para variable = valor-inicio hasta valor-final hacer
Sentencia
Fin-Para

5. Sentencias de Archivos

Apertura de archivo: Abrir (archivo-lógico)

Cerrado de archivo: Cerrar (archivo-lógico)

Lectura de registro: Leer (registro-lógico, archivo-lógico)

Almacenado de registro: Escribir (registro-lógico, archivo-lógico)

Asignación de valor a un campo de registro: registro-logico.campo = valor

70
 Análisis y Diseño de Sistemas

4.5. Otras Técnicas en el desarrollo de Sistemas

4.5.1. Gráficas Administrativas

La graficación, es una técnica que representa a través de figuras en forma esquemática y simplificada, algunos
de los aspectos de una empresa, o una actividad de la misma. De todas las herramientas y técnicas que se utilizan en el
desarrollo de los sistemas de información automatizados, la graficación es la que se identifica más estrechamente con
este trabajo, ya que es útil no solo en la recopilación de información sino también en el análisis, diseño, implementación
(comunicación) y en la documentación.

Sin considerar que son todas las que existen, las gráficas administrativas en este trabajo se clasificarán en:

1. Organigramas

2. Diagramas de Distribución

3. Diagramas de Flujo

4. Diagramas de flujo de datos y;

5. Otras gráficas.

4.5.1.1. Organigramas.

Los organigramas son la expresión gráfica de los niveles de autoridad y responsabilidad de las unidades que
conforman una organización o a una parte de ella (estructura). Los organigramas, consisten fundamentalmente de un
cierto número de casillas que representan puestos, personas, o unidades administrativas colocadas jerárquicamente y
relacionadas mediante líneas. Dependiendo de la forma en que se presentan gráficamente se conocen cuatro tipos:
verticales, horizontales, circulares o mixtos. Verticales, cuando las líneas de autoridad parten de arriba hacia abajo;
horizontales, cuando las líneas de autoridad parten de izquierda a derecha; circulares, cuando las líneas de autoridad
parten del centro hacia la periferia y mixtos, cuando se hace cualquier combinación 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 presentación:

• Utilizar nomenclatura jerárquica uniforme es decir, a cada nivel de la estructura debe de corresponder
igual denominación (todos directores o jefes o supervisores o bien, todos puestos o funciones).

• Las funciones parecidas o relacionadas deben de agruparse juntas.

• No usar diferentes tamaños o formas de las figuras geométricas para representar la importancia de las
unidades administrativas ya que el nivel dentro de la jerarquía es el que la determina.

• Algunas veces, no es recomendable incluir en un solo organigrama todos los niveles de la organización
ya que la presentación puede ser confusa, motivo por el cual se recomienda que el organigrama se
muestre una presentación general y posteriormente cada una de las áreas administrativas más
importantes por separado, y de esta manera simplificar el entendimiento del mismo.

• No mezclar estructura con flujos de información dentro de ella, ya que el organigrama sólo debe de
mostrar unidades administrativas y relaciones de estructura y no las relaciones de información entre las
unidades.

• Identificar claramente el organigrama. Esto es, la empresa a la que corresponde y el nombre de la

unidad que representa.

71
 Análisis y Diseño de Sistemas

• Establecer el momento de la elaboración y el autor del diseño ya que las estructuras cambian con el
tiempo y es conveniente conocer quién lo elaboró para posibles aclaraciones.

Fig. 4.5: Tipos de Organigramas

72
 Análisis y Diseño de Sistemas

4.5.1.2. Diagramas de Distribución.

Los diagramas de distribución física o arquitectónicos, son gráficas que representan el conocimiento del
entorno físico en el que se desarrolla una actividad por lo cual, aportan información respecto al espacio y recursos
disponibles.

Estas gráficas, son útiles para analizar la ubicación física de los sistemas electrónicos y del equipo periférico
que los acompañen, también, 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.

Técnica que facilita la descripción del trabajo administrativo especialmente en lo que se refiere a sistemas y
procedimientos y tienen como objetivo, facilitar la comprensión de los mismos. Muestran gráficamente 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
 Análisis y Diseño de Sistemas

Clasificación

Existen símbolos especiales para elaborar los diagramas, los cuales, se pueden clasificar en:

1. Abstractos.

1.1. ASME (American Society of Mechanical Engineers). Esta simbología, 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
información, datos, formas y son los más utilizados por las personas en el área de la administración.

2. Figurativos.

2.1. Fotografías

2.2. Dibujos

2.3. Caricaturas

Por la forma de presentación 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

• Panorámicos: cuando presentan una visión completa del sistema.

• Analíticos: cuando describen algún procedimiento del sistema o alguna parte en especial del
mismo.

A continuación se muestra un ejemplo de la simbología ANSI y la comparación de simbología abstracta y

figurativa en un procedimiento de salida de documentos de correspondencia.

74
 Análisis y Diseño de Sistemas

Ventajas y Desventajas.

Las ventajas asociadas a los diagramas de flujo, se refieren a:

• Son concisos y por tanto mas fáciles de entender de una mirada que una descripción narrativa. Sin
embargo para fines de documentación es conveniente acompañarlos de dicha narración para
complementar su entendimiento.

• Presentan una visión gráfica y por tanto objetiva del flujo.

• Expresan claramente la secuencia y la lógica de modo que facilitan la corrección.

• Muestran si se han cubierto todas las posibilidades.

• Facilitan la comunicación entre el elemento humano.

Sin embargo, sus principales desventajas son:

• Es necesario definir el significado de los símbolos usados porque pueden causar confusión.

• Su elaboración, requiere de tiempo.

• Cuando se llevan al detalle, pueden ser difíciles de entender.

• La información dentro de cada símbolo es muy generalizada.

• Para diseñarlo, se deben de contemplar ciertos convencionalismos como son:

75
 Análisis y Diseño de Sistemas

o Se recomienda que los diagramas vayan de arriba hacia abajo y de izquierda a derecha.

o Evitar hasta donde sea posible, el cruce de líneas.

o Si un diagrama no es claramente comprensible para quien lo contempla, debe de simplificarse

o dividirse en dos o más partes.

o La simbología utilizada, debe de contribuir a su comprensión y no a dificultarla.

o Es recomendable que cuando los diagramas sirvan para documentación, lleven una
descripción.

o Deben de evitarse los símbolos especiales.

o Es conveniente previa a la elaboración del diagrama, elaborar el algoritmo correspondiente.

o Cuando el diagrama ocupe más de una página, cada una de éstas se numerará en secuencia y
se debe dejar espacio suficiente para el título el cual debe ser breve y claro.

o El diagrama debe de ser legible y para fines de presentación, deberá estar limpio y contar con
el tamaño adecuado para que todos los asistentes a su presentación, puedan leerlos.

o El diagrama debe ser identificado con el título del diagrama, fecha de elaboración y
responsable de su elaboración.

Un problema que se presenta en el diseño de diagramas de flujo, es la identificación de lo que se va a

representar ya que en los procedimientos administrativos, se involucran no solamente actividades sino también por
ejemplo, formas o materiales, en mi opinión, el tratar de incluir en los diagramas, la secuencia lógica de otros elementos
además 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
lógica del mismo. En este sentido, los diagramas pueden seguir:

76
 Análisis y Diseño de Sistemas

1. Formas.

En algunas ocasiones se acostumbra combinar la descripción de un procedimiento con la distribución de

formas, lo cual la mayoría de las veces complica el entendimiento en lugar de facilitarlo. Si la distribución de
formas es importante en una organización, 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 más conveniente para representar la secuencia de materiales es a través
del uso de dibujos.

77
 Análisis y Diseño de Sistemas

3. Personas.

Representar la secuencia de actividades que debe realizar una persona se ejemplifica mediante el siguiente
diagrama.

4. Lógica.

Aunque los diagramas no son un lenguaje de programación, en realidad en algunos casos, ayudan en la
descripción de la secuencia de la lógica que debe de seguir un programa.

78
 Análisis y Diseño de Sistemas

5. Datos.

Los diagramas de flujo de datos han sido utilizados como herramientas del modelo desarrollado por
Edward Yourdon como metodología para el desarrollo de sistemas de información. Por la importancia de estos
diagramas para el analista de sistemas, serán considerados en un punto por separado (DFD, Diagramas de
Flujos de Datos).

79
 Análisis y Diseño de Sistemas

5. Análisis Estructurado.

5.1. Concepto

Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de información, tienen que
profundizar en un área de la Organización, 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 Organización, en función del crecimiento, cambios futuros en el

sector, introducción de nuevas tecnologías etc.

• Documentar detalles del sistema actual para su comprensión y discusión por otros profesionales de la
organización.

• Evaluar la efectividad y eficiencia del sistema actual y sus procedimientos.

• Recomendar modificaciones del sistema actual, o proponer un nuevo sistema completo, justificándolo
en cada caso.

• Documentar las características del nuevo sistema con un nivel de detalle que permita comprender a
otros sus componentes.

• Fomentar la participación 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. Análisis estructurado ¿Para qué?

Por la propia naturaleza los sistemas de información, éstos no están bien estructurados, no siguen leyes como
las ciencias, dependen de muchas circunstancias para su funcionamiento (personas, influencias políticas de la
organización, restricciones, etc.). El analista debe luchar contra estas circunstancias y determinar los requerimientos de
los sistemas de información.

Ante esta realidad, surgen preguntas como: ¿Deben dos analistas desarrollar una lista idéntica de
requerimientos cuando estudian de forma independiente la misma situación? ¿Para una situación dada, tenemos un único
diseño correcto posible? La respuesta es que dos analistas que examinan de forma independiente una situación, sin
herramientas y técnicas preestablecidas, recopilan información diferente que describa el sistema y por lo tanto en
determinación de requerimientos diferentes.

Esto obliga a normalizar, a estructurar el análisis de sistemas de información. Podemos definir análisis
estructurado como:

El método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones
para sistemas nuevos o para efectuar modificaciones a los ya existentes.

El análisis estructurado permite al analista conocer un proceso (actividad) en una forma lógica y manejable al
mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.

80
 Análisis y Diseño de Sistemas

Por otra parte una de las claves del éxito de un buen análisis será el que exista una buena comunicación entre
usuarios y analistas, esto obliga a disponer de un lenguaje común, 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 análisis estructurado es organizar las tareas asociadas con la determinación de
requerimientos para obtener la comprensión completa y exacta para una situación dada. A partir de aquí se determinan
los requerimientos que serán la base de un sistema nuevo o modificado.

La palabra estructura significa:

1. El método intenta estructurar el proceso de determinación de los requerimientos comenzando con la

documentación del sistema existente.

2. El proceso intenta incluir todos los detalles relevantes que describen al sistema en uso.

3. Fácil verificar cuando se han omitido datos relevantes.

4. La identificación 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 comunicación eficientes.

5.1.3. Componentes del análisis estructurado.

El análisis estructurado hace uso de los siguientes componentes:

1. Símbolos gráficos. Iconos y convenciones para identificar y describir los componentes de un sistema
junto con las relaciones entre esos componentes.

2. Diccionario de datos. Descripción de todos los datos utilizados en el sistema.

3. Descripciones de procesos y procedimientos. Declaraciones formales que emplean técnicas y lenguajes

que permiten a los analistas describir actividades importantes que forman parte del sistema.

4. Reglas. Estándares para describir y documentar el sistema en forma correcta y completa.

El método de análisis estructurado es sinónimo de análisis de flujo de datos que es una herramienta para
documentar el sistema existente o actual y determinar los requerimientos de información de forma estructurada.

5.2. ¿Qué es análisis 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 Organización (sistema de información), van a ser los datos. Los
datos son las guías de las actividades de la Organización, inician eventos, son procesados para dar información útil al
personal, etc.

81
 Análisis y Diseño de Sistemas

Seguir el flujo de datos por todos los procesos de la organización, además de ser la finalidad del análisis de
flujo de datos, proporciona a los analistas información de cómo se alcanzan los objetivos en la Organización.

El análisis 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 gráfica la relación 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 análisis puede pensarse de tal manera que se estudien actividades del sistema desde el punto de vista de los
datos, donde se originan, cómo se utilizan o cambian, hacia dónde van. Los componentes de la estrategia de flujo de
datos abarcan tanto la determinación de los requerimientos como el diseño de sistemas. Una notación bien establecida
facilita la documentación del sistema actual y su análisis por todos los participantes en el proceso de determinación de
requerimientos.

5.2.2. Ventajas del análisis 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 común, sencillo y fiable, estas son las características
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 análisis de flujo de datos

Las herramientas tienen el objetivo de ayudar a entender las características del sistema. Por lo tanto no deben de
ser un fin, sino un medio para el estudio del sistema.

Las herramientas utilizadas en el análisis de flujo de datos son:

1. Diagrama de flujo de datos.

2. Diccionario de datos.

3. Diagrama entidad-relación.

4. Miniespecificaciones o Especificación de Procesos.

82
 Análisis y Diseño de Sistemas

5.3. Diagramas de Flujo de Datos

5.3.1. Concepto

Los diagramas de flujos de datos (DFD), es una técnica 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é análisis 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 común, sencillo y fiable, estas son las características
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. Notación de los Diagrama Flujo de Datos

Los métodos para el análisis de flujo de datos fueron desarrollados y promovidos por dos organizaciones al
mismo tiempo, Yourdon Inc (compañía de consultoría) y Mc Donnell-Douglas (Gane and Sarson). En nuestro libro la
notación utilizada será la de Yourdon. Los DFD’s se pueden dibujar con sólo cuatro elementos gráficos 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 gráficamente como un círculo. Los sinónimos comunes son burbuja,
función o transformación.

Fig. 5.1.: Proceso

• Flujo de datos: Se representa gráficamente por medio de una flecha que entra o sale de un proceso. El
flujo se usa para describir el movimiento de bloques de información de una parte del sistema a otra.
Por ello, los flujos representan datos en movimiento, mientras que los almacenes representan datos en
reposo. En algún modelo puede representar movimiento de material. Los flujos muestran la dirección;
según 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 dirección/sentido de los datos, respecto al
proceso:

83
 Análisis y Diseño de Sistemas

1. Entrada.
Validar
Número telefónico Número
Telefónico

Fig. 5.3.: Flujo de Entrada

2. Salida.

Generar
Itinerario Itinerario Conductor
Conductor

Fig. 5.4.: Flujo de Salida

3. Divergente y Convergente.

Cuando una misma información se envía a procesos diferentes, o cuando una

información 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 más 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 sólo un dato, indivisible

84
 Análisis y Diseño de Sistemas

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.

• Almacén de datos: El almacén se utiliza para modelar una colección de datos en reposo. Se representa
por dos líneas paralelas. Es tentador asociar a los almacenes los archivos o bases de datos, es así como
a menudo se implantan en un sistema informático, pero un almacén también 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

gráficamente como un rectángulo representan fuentes (origen) o destinos externos de datos que pueden
ser: personas, programas, organizaciones u otras entidades que interactúan 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 organización 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 definición, los terminadores son en realidad parte del sistema y debieran
modelarse como procesos.

Deberemos respondernos una serie de preguntas como ¿cómo se piden los datos?, ¿en qué secuencia se reciben
los datos?, ¿en qué secuencia se generan?, no deben ser respuesta de los DFD’s, estas respuestas forman parte del
procedimiento.

85
 Análisis y Diseño de Sistemas

Cada componente en un diagrama de flujo de datos tiene una etiqueta con un nombre descriptivo. Los nombres
de los procesos también reciben un número para poder identificarlo.

Los diagramas de flujo de datos se concentran en el movimiento de datos a través 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 construcción de DFD’s

Hay una serie de reglas que son necesarias para poder construir los DFD’s correctamente. La finalidad de estas
reglas es ayudar a confeccionar DFD’s 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 comprensión.

Las reglas a seguir para la construcción de un DFD son:

1. Elegir los nombres representativos para los procesos, flujos de datos, almacenamientos y entidades
externas de forma que describa lo más 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:

Función: 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 terminología informática (Proceso, Función, Rutina, Procedimiento, etc.).

Flujos: los flujos deben identificar la información y/o los datos que fluyen a través del sistema.

Se deben evitar el uso de las palabras “información y dato”.

El nombre es una unidad, por lo tanto, si el nombre esta compuesto por más de una palabra, deberá
unirlas por un guión bajo (“_”).

Almacenes: Los almacenes deben nombrarse con nombre que representen la información y/o datos que
estos contienen.

Evitar el uso de palabras como Archivo, Almacén, 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
 Análisis y Diseño de Sistemas

2. Numerar los procesos para identificarlos de forma rápida y unívoca.

Los números no indican secuencia. El modelo de DFD es una red de procesos asincrónicos que se
intercomunican, lo cual es, una representación precisa de la manera en la realidad muchos sistemas operan. El hecho que
exista procesos no pueda realizar su función por falta de algún dato de otro proceso no implica correspondiente con la
numeración. Son la base para crear la jerarquía de diagramas cuando se introduzcan los diagramas de flujo por niveles.

3. Evitar DFD excesivamente complejos y recargados, es decir, con muchos elementos gráficos juntos.

El propósito 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 propósito del DFD, de igual importancia, es que sea leído y comprendido, no sólo por
el analista que construyo el modelo, sin por los usuarios que sean los expertos en la materia de aplicación. Esto significa
que el diagrama debe ser fácilmente entendido, fácilmente asimilado y placentero a la vista.

Existe una excepción, 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 técnicamente correcto.

• Aceptado por el usuario

• Estar lo suficientemente bien dibujado como para que no sea embarazoso mostrarlo a la dirección de la
organización.

6. Asegurarse que el DFD es consistente.

Existen reglas para asegurar la consistencia del DFD con otros modelos de sistemas; el diagrama de entidad-
relación, diagrama transición de estados, diccionario de datos, y la especificación de procesos. Las principales reglas de
consistencia son:

• Evite sumideros infinitos, procesos que tienen entradas pero no salidas. ‡ Evite burbujas de generación
espontánea, procesos que tienen salidas sin tener entradas. Situación normalmente incorrecta.

• Cuidado con flujos y procesos no etiquetados, ya que puede esconder errores importantes.

• Tener cuidado con los almacenes de “sólo lectura” o “sólo escritura”, ya que todo almacenamiento
debe tener un flujo entrante y uno saliente, es decir, la información se almacena se consume.

• Las entidades externas no pueden acceder directamente a ningún almacenamiento. Siempre debe
mediar un proceso que haga de intermediario y extraiga o inserte la información pertinente.

87
 Análisis y Diseño de Sistemas

Sumidero de información Fuente de información

Fig. 5.8.: Sumidero y Fuente de Información

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 ¿cómo? Si el sistema es intrínsecamente 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 más detalles sobre una porción del nivel anterior. Esto es

De modo que se construirá una jerarquía de diagramas, en donde cada nivel inferior es una expansión de un
proceso del nivel superior.

5.3.6. Construcción 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. ¿Cómo saber cuántos 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 más de media docena de burbujas y almacenes relacionados, si nos aparece un nivel
que contenga un número muy superior deberemos insertar un nuevo nivel a los que hubiere. Hay que procurar
que haya equilibrio en la distribución de todos los elementos gráficos 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 más complejas que otras y pueden
requerir uno o más niveles de partición. En el caso que nos encontremos con desigualdades respecto a la
división de un proceso respecto a otros, deberemos nivelar el DFD para lograr un equilibrio.

88
 Análisis y Diseño de Sistemas

3. ¿Cómo nos aseguraremos que los niveles del DFD son consistentes entre sí?

Esta cuestión es importante, ya que normalmente existe un desarrollo entre distintas personas en un
proyecto real, así como una división del trabajo. Para asegurarse que cada figura es consistente con su figura de
más 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 desagregación”, a esto se le llama
“balanceo de malla”.

4. ¿Dónde deben aparecer los almacenes?

La regla es la siguiente: “mostrar un almacén en el nivel más alto donde primeramente sirve de interfaz
entre dos o más burbujas; luego mostrarlo de nuevo en cada diagrama de nivel inferior que describa más a
fondo dichas burbujas de interface”. Por lo tanto los almacenes locales, que utilizan sólo las burbujas en una
figura de menor nivel, no se mostrarán en niveles superiores, dado que se incluyen de manera implícita en un
proceso del nivel inmediato superior.

5. ¿Cómo se realiza de hecho la partición de los DFD en niveles?

La situación 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 más aconsejable es identificar los acontecimientos
externos a los cuales debe responder el sistema y crear un primer DFD borrador. Veremos como esta primera
aproximación del DFD puede suponer un punto de partida hacia arriba o hacia abajo.

6. ¿Cuál será el último nivel de desagregación?

Para decidir cuál 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. Explosión de un proceso

A medida que vayamos conociendo más 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 más detalle su funcionamiento.

• Todos los procesos a que da lugar la explosión 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 salían del proceso n tienen que salir del conjunto n.1, n.2, n.3, etc.

89
 Análisis y Diseño de Sistemas

• Al estudiar en más 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 tendrían que reflejar en el DFD original.

• Todas las entidades externas han de estar fuera del marco de la explosión.

Fig. 5.9.: Explosión 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 físicos de flujo de datos.

Proporcionan un panorama del sistema en uso, muestra las tareas que se llevan a cabo y como se
hacen. Las características físicas incluyen:

• Nombre de personas

• Nombre o formatos de documentos

• Nombres de departamentos

• Archivo de maestro y de transacciones

90
 Análisis y Diseño de Sistemas

• Equipo y dispositivos utilizados

• Ubicaciones

El empleo de estos diagramas es aconsejable por tres razones:

• Para los analistas de sistema es más fácil describir la interacción entre los componentes
físicos que comprender las políticas empleadas. De modo que identifican las personas, lo que
hacen, los documentos que inician las actividades y el equipo para su procesamiento.

• Los diagramas físicos 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 días con estas entidades (Los diagramas lógicos van a resultar abstractos
para los usuarios).

• Los diagramas físicos proporcionan un camino para validar o verificar el punto de vista del
usuario sobre la forma en que opera el sistema en uso.

2. Diagramas lógicos de flujo de datos.

Proporcionan un panorama del sistema independiente de la implantación, que se centra en el flujo de

datos entre los procesos sin considerar los dispositivos específicos y la localización de almacenes de datos o
personas en el sistema. Los diagramas físicos de flujos de datos, no son un fin en si mismos, sino son un medio
para describir la implantación del sistema existente. El diagrama lógico es una visión retrospectiva de la
implantación actual y proporciona la base para examinar la combinación de procesos, flujo de datos, almacenes
de datos, entradas y salidas, sin importarnos los dispositivos físicos, personas o aspectos de control que
caracterizan la implantación.

Así que el diagrama lógico se obtiene del diagrama físico al llevar a cabo lo siguiente:

• Señalar 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 información 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 Organización, el analista necesita obtener una visión del
sistema. Primero los elementos físicos: personas, documentos, listados. No es difícil recordar lugares o personas
importantes (“Este trabajo lo realiza Pérez”, “La autorización del pago de facturas se realiza en el departamento de
contabilidad”, etc.), los diagramas físicos representan estos elementos.

Una vez superada esta primera fase de conocimiento del sistema actual, es necesario descifrar los aspectos más
importantes de cada actividad. Los diagramas lógicos nos permiten describir los datos, procesos y eventos de forma
abstracta, ya que el analista debe conocer el trabajo que debe realizarse más que las personas que en la actualidad lo
realizan. Los analistas generalmente comienzan por la construcción de un modelo físico por que los componentes físicos
se pueden identificar realmente durante el análisis y después lo convierten a un modelo lógico

91
 Análisis y Diseño de Sistemas

Durante la conversión, primero se pasan todos los procesos que hacen referencia a actividades físicas.

El resto de los procesos físicos se expanden después dentro de sus funciones lógicas. Para ello se toma cada
proceso físico, se busca qué es lo que hace y se reemplaza por un DFD de funciones lógicas expandido que represente
las actividades de un objeto físico.

Después se examina este último DFD, y cualquier función común o similar se combina para formar un proceso
de nivel más alto que se convierte el DFD superior.

5.3.8.1. Deducción del diagrama lógico

Los diagramas físicos de flujo de datos son un medio para alcanzar un fin, no un fin en sí mismos. Se elaboran
para describir la implantación del sistema existente, con el objetivo de tener la comprensión correcta de la implantación
real del sistema existente.

El panorama lógico es una visión retrospectiva de la implantación actual y proporciona la base para examinar la
combinación de procesos, flujo de datos, almacenes de datos, entradas y salidas sin tomar en cuenta dispositivos físicos,
personas o aspectos de control que caracterizan la implantación.

5.3.8.2. Reglas generales para el dibujo de diagramas lógicos de flujo de datos

Las reglas a tener en cuenta, para el dibujo de los diagramas lógicos 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. Sólo deben entrar al proceso los datos necesarios para llevarlo a cabo.

4. Un proceso no debe saber nada de ningún 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 están en continua ejecución, no se inician, ni tampoco se detienen.

6. La salida de los procesos puede tomar una de las siguientes formas:

• Flujo de datos con información añadida por el proceso (por ej. anotación 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 condición (por ej. de no autorizado a autorizado).

• Un cambio de contenido (por ej. integración o separación de la información contenida en uno

o mas flujos entrantes de datos).

• Cambios en la organización (por ej. separación física o reacomodo de datos).

92
 Análisis y Diseño de Sistemas

5.3.8.3. Expansión de los procesos para mayor detalle

Dado que la información contenida en el diagrama de contexto, es inadecuada para explicar en su totalidad los
requerimientos del sistema, es deseable describir el panorama lógico del procesamiento de facturas por pagar con mayor
detalle.

Para identificar los procesos utilizamos los números 1.0, 2.0 y 3.0. Podemos hacer referencia por su número
(1.0) o por su nombre (Autorización 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 número de niveles, el número de procesos por niveles, la norma común
es definir cada nivel inferior en términos de tres a siete de procesos por cada proceso de nivel superior. La utilización de
más de siete procesos hace que el diagrama sea difícil de manejar y dibujar.

Lo importante es entender que los diagramas de flujo de datos lógicos son una herramienta de ayuda para
ayudar la comprensión del sistema de la Organización. De modo que un diagrama deja de ser útil cuando no es
comprensible. Por lo tanto, debe primar el sentido común, y no determinar normas estrictas para su construcción.

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 explosión es consistente; los flujos de entradas o
salidas del proceso de nivel superior están presentes en el diagrama de nivel inferior, y apareciendo nuevos flujos,
almacenes. Esto es precisamente uno de los puntos importantes de la expansión hacia niveles inferiores: encontrar más
detalles relacionados con los procesos internos.

5.3.8.5. Convenciones de nivelación significativas

Nivelación es un término 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
almacén 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 están contenidos dentro del proceso, y aparecen en el próximo nivel cuando se
expansione el proceso. La convención de nivelación señala que estos almacenes son internos al proceso, no entradas
para él.

5.3.8.6. Añadir los controles sólo en los diagramas de bajo nivel

Hasta el momento los diagramas de flujos de datos desarrollados no incluyen información sobre controles. No
se hace referencia sobre como manejar errores o excepciones, por ejemplo como procesar facturas incorrectas. Aunque
esta información 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 más comunes cometidos al incluir los controles físicos en los diagramas lógicos de flujo de datos.
Por ejemplo: El copiado de números para documentos (copia 1, copia 2, copia para contabilidad), de instrucciones
(encontrar el registro, revisar el registro), o días para el inicio de actividades (hacerlo el lunes) no tienen nada que ver
con los aspectos lógicos y de datos de determinación de requerimientos.

93
 Análisis y Diseño de Sistemas

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 interés para los analistas, no los documentos o el lugar donde residen. Por
ejemplo, una factura contiene varios elementos diferentes de información. Los analistas están interesados en aquellos
que son importantes para un proceso en particular. Estos pueden ser el número de la factura y la fecha de expedición, o
la firma de autorización 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 específico 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 acción que se lleva a cabo. Lo mas apropiado es escoger un
verbo y un objeto que reciba la acción 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 Edición 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, revisión, reunir u organizar.

5. Utilizar los nombres de los procesos de bajo nivel ya que estos son más específicos 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.

También hemos hablado de numerar los procesos con los números 1, 2, 3, 4 y 5. Los procesos generados con la
expansión 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. Evaluación y verificación 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 señale 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
 Análisis y Diseño de Sistemas

7. ¿Existen demasiados atributos en el almacén de datos (más que los detalles necesarios)?

8. ¿El flujo de datos que llega a un proceso es demasiado extenso para la salida

5.4. Dfd’s 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 señales 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 señal binaria (esto es, está encendido o está apagado). A diferencia de otros flujos que se
discuten en este capítulo, el flujo de control no porta datos con valores. El flujo de control se manda de un proceso a otro
(o de algún 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 función es coordinar las actividades de otras burbujas en el
diagrama; sus entradas y salidas consisten sólo 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 situación extraordinaria, de la cual necesita informarse a la burbuja
de control. Por lo común sólo hay un proceso de control de estos en un DFD dado.

95
 Análisis y Diseño de Sistemas

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 cálculos 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 DFD’s.

2. Describe la composición de la estructura de datos que se mueven a los largo de los flujos.

3. Describe la composición de la estructura de datos en los almacenes.

4. Describe los detalles de las relaciones entre almacenes que aparecen en un diagrama entidad-relación.

Los analistas utilizan los diccionarios de datos por cuatro razones:

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 común para todos los elementos del sistema. Esto es muy importante
cuando trabajan varios analistas y no pueden reunirse todos los días para comunicarse.

2. Para documentar las características del sistema.

3. Localizar errores en el sistema.

5.5.1. Contenido de un Diccionario de Datos

El DD contiene los siguientes elementos:

1. Definiciones lógicas de datos:

• Elemento de Dato (Atributos de la Entidad).

• Estructura de Dato.

• Flujos de Datos.

• Almacenes de datos.

2. Definiciones lógicas de procesos.

3. Definiciones lógicas de entidades externas.

5.5.2. 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
 Análisis y Diseño de Sistemas

= Está compuesto por

+ Y

() Opcional, puede o no puede estar presente

[] Selección entre varias alternativas

{} Iteración, repetir lo mismo varias veces

** Comentario

@ Clave principal de un almacenamiento

| Separador de alternativas en selección Ejemplo:

5.5.3. Notación del Diccionario de datos

1. Descripción 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 Definición

2. Descripción 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 Validación

3. Descripción de los almacenamientos de datos: Representamos los almacenamientos de datos. De ellos se

documenta: Nombre, Clave Primaria, Contenido, Procesos que lo ocupan, y Definición

4. Descripción de los procesos: Representamos los procesos del sistema. Se documenta: Nombre,
Descripción, Flujos de Entrada, Flujos de Salida, Almacenes y Descripción (narrativa o seudo-código)

5. Descripción de las entidades externas: Representamos las entidades externas del sistema. Se documenta:
Nombre, Definición, A quien representa y Flujos de datos relacionados (E/S).

97
 Análisis y Diseño de Sistemas

5.6. Diagrama Entidad-Relación

El modelo E-R (entidad-relación) fue propuesto por Edward Chen en 1976 para la definición del esquema
conceptual de una BD. Posteriormente se ha ido enriqueciendo con nuevos mecanismos de abstracción y representación
de la realidad. Es el más ampliamente utilizado de los llamados semánticos.

Se basa en la utilización de conceptos tales como entidad (objeto), atributo y relación entre objetos. Se dispone
de un formalismo gráfico para realizar estas representaciones, pero no de un lenguaje de manipulación de datos.

La principal ventaja, que seguramente ha forzado su difusión, es que es traducible casi automáticamente a un
esquema de BD bajo Modelo Relacional, con cierta pérdida de expresividad en el proceso, pero garantizando que las
tablas que resultan están directamente en Tercera Forma Normal (3FN).

Pasaremos ahora a describir cual es el lenguaje de representación de entidades, atributos, y relaciones entre
entidades. Hacer notar, sin embargo, que se muestra una mínima parte de este lenguaje, la necesaria para comprender el
significado de los diagramas E-R más simples.

El Diagrama de entidad-relación (DER), es una técnica de modelado que nos muestra los datos relevantes del
sistema, así como las relaciones entre estos datos a un alto nivel de abstracción.

5.6.1. ¿Para qué definir un modelo orientado a datos?

Es necesario definir un modelo orientado a datos por:

• 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 DFD’s.

5.6.2. Componentes

Los tres componentes principales de un DER son:

• entidades

• atributos

• relaciones entre entidades

5.6.2.1. Representación de Entidades.

Una entidad se representará mediante un rectángulo nominado. Representa un conjunto de objetos (materiales o
inmateriales) del mundo real: empleados, artículos, clientes, planificaciones, estándares cumpliendo las siguientes
características:

• Cada uno de sus miembros individuales (instancias), pueden ser identificados unívocamente. Existe
alguna manera de diferenciar dos instancias individuales de la entidad.

98
 Análisis y Diseño de Sistemas

• Cada entidad juega una función dentro del sistema. El sistema no funciona sin acceder a sus miembros
instancias.

• Cada entidad puede ser descrito por uno o más 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 relación
entre los almacenes del DFD y las entidades del DER. Si existe una entidad artículo en un DER, debe haber un almacén
de datos artículos en el DFD asociado.

5.6.2.2. Representación de Atributos.

Un atributo se verá en un E-R como una elipse unida a una entidad mediante un arco.

En función de los distintos tipos de atributos que nos podemos encontrar, variará el tipo de representación:

• 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. Representación de Relaciones.

Las relaciones entre entidades se representan mediante un polígono 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 polígono irá etiquetado con el nombre de la relación. Asimismo, se pueden etiquetar
los arcos para realzar el papel que juega dicho objeto dentro de la relación.

Las entidades están ligadas unas a otras por relaciones. Cada instancia de la relación representa una asociación
entre 0 ó más ocurrencias de una entidad y 0 ó más ocurrencias de otra entidad

Las relaciones que pueden ser calculadas o derivadas a partir de otros datos, no se representan.

Nos podemos encontrar múltiples relaciones entres dos o más entidades, y debemos interpretarlo como una
unidad. La relación se debe estudiar desde la perspectiva de cada uno de las entidades participantes. Es el conjunto de
todas aquellas perspectivas que describen completamente la relación.

99
 Análisis y Diseño de Sistemas

5.6.3. Reglas para la construcción de DER’S

1. Construcción del modelo inicial.

El DER inicial se construye basándose 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 almacén de datos asociado. Al hacer
este refinamiento nos podemos encontrar ante la necesidad de añadir nuevas entidades o eliminarlos.

3. Añadir entidades al modelo inicial

• Datos elementales que no pueden aplicarse a todas las instancias de un entidad:

Ejemplo: Entidad Empleado. Atributos: nombre, edad, número de embarazos…

Solución: Crear un conjunto de entidades-subtipo, Empleado-Masculino, Empleado-

Femenino.

• Datos elementales aplicables a todas las instancias de dos entidades diferentes:

Ejemplo: Entidad Cliente-Caja, Cliente-Crédito. Atributos comunes: nombre, dirección.

Solución: Crear una entidad-supertipo Cliente.

• Datos elementales que describen relaciones entre entidades-tipo.

Ejemplo: Relación Compra y los datos fecha de compra, y descuento.

Solución: Crear un entidad asociativo Compra.

• Eliminar grupos de datos repetitivos dentro de una entidad.

Ejemplo: Entidad Empleado, y cada uno puede tener hijos.

Solución: Crear un entidad hijo y la relación es Padre de.

Eliminar entidad del modelo inicial.

• Entidades de las cuales solo hay una instancia, y solo tienen identificador.

Ejemplo: Entidad Cónyuge, del cual solo nos interesa el nombre.

Solución: Eliminar la entidad Cónyuge y la relación Esta Casado con y guardamos el nombre
cónyuge con el atributo de empleado.

100
 Análisis y Diseño de Sistemas

• Relaciones calculadas o derivadas.

Ejemplo: Relación Renueva, que se puede calcular a partir de diversos datos de Conductor
(fecha nacimiento, apellidos....).

Solución: Eliminar la relación RENUEVA.

5.6.4. Preguntas a resolver

Una vez vistas las herramientas y técnicas 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 mayoría de sistemas de gestión actuales son lo suficientemente complejos en cuanto a funciones y datos que
hacen aconsejable, la realización de los dos modelos.

101
 Análisis y Diseño de Sistemas

5.7. Miniespecificaciones o Especificación de Procesos.

Hemos visto que para describir la lógica de un proceso, se pueden utilizar varias alternativas como son:
narrativa, árboles de decisión, tablas de decisión y español estructurado (o seudo-código).

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 1millón al año y tienen una buena historia de
pagos o que han tenido tratos con nosotros por mas de 20 años deberán recibir trato preferencial”).

• Adjetivos indefinidos (“buena historia de pagos”, “trato preferencial”). Estas razones obligan a pensar
en otras alternativas:

Los árboles de decisión, pueden resultar una técnica no válida en situaciones complejas con gran número de
condiciones e implicaciones ya que no asegura que se hayan considerado todas.

Se debe utilizar cuando el número de acciones sea pequeño y no sean posibles todas las combinaciones.

Las Tablas de decisión, son mas precisas dado que permiten reflejar todas las combinaciones posibles. Pero son
más difíciles de entender para el usuario. Deben simplificarse una vez construidas, y se convertirán en árboles de decisión.

Se debe utilizar, siempre que se dude que el árbol muestre toda la lógica.

Por lo Tanto se opta, en esta fase, por la utilización del español estructurado, el cual provee una similitud tal
con el lenguaje de programación, que la conversión es mucho más rápida. Además, la lectura por parte del usuario, se
hace más fácil y, por ende, más entendible.

102
 Análisis y Diseño de Sistemas

6. Diseño.

El diseño podría definirse como "el proceso de aplicar distintas técnicas y principios con el propósito de definir
un dispositivo, un proceso o un sistema con suficiente detalle como para permitir su realización física".

El objetivo del diseño es producir un modelo o representación que se va a construir posteriormente. El proceso
de diseño combina la institución y los criterios basados en la experiencia en la construcción de las entidades similares;
un conjunto de principios y/o heurísticas que guían la evolución del modelo, un conjunto de criterios que permiten
juzgar la calidad y un proceso de iteración (repetición) que lleva como fin ultimo a una representación definitiva del
diseño.

Diseño de un sistema computacional es una actividad de la transformación de la declaración de lo que se

necesita a un plan de implementación de ese requerimiento en un dispositivo electrónico. (Random House College
Dictionary)

6.1. Diseño e Ingeniería de software

Diseño de software.

Cambia continuamente medida que evolucionan nuevos métodos, mejores análisis esta en una fase
relativamente temprana en el desarrollo carece de profundidad, flexibilidad y naturaleza cuantitativa de otras disciplinas
de la ingeniería, sin embargo existen métodos, criterios y notación para hacer un diseño exitoso

Ingeniería de Software

El término Ingeniería de Software surge a final de los años 60 dentro de una conferencia dedicada a “la crisis
del software”. El objetivo de la Ingeniería de Software es producir productos de software. Productos software: sistemas
software junto la documentación que describe como instalar y usar el sistema.

Los productos software caen en dos categorías:

• Productos genéricos: Desarrollados por una organización para un mercado abierto.

• Productos a medida: Encargados por un cliente.

Ingeniería del Software: “Conjunto de métodos, herramientas y procedimientos para producir software de gran
calidad” [R. Pressman]

Los métodos describen cómo construir técnicamente el software. Las herramientas dan soporte automático o
semiautomático a los métodos. Los procedimientos relacionan formalmente los métodos y las herramientas. La calidad
del software es una noción 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 cómo están
definidas en su especificación de requerimientos.

• Robustez: Capacidad de un sistema software para funcionar en situaciones anormales.

103
 Análisis y Diseño de Sistemas

• 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 aceptación, en particular datos de prueba,

para detectar fallos durante las fases de validación y operación.

• 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 computación.

• Modularidad: Independencia funcional de los componentes del programa.

• Legibilidad: Facilidad de lectura e interpretación del código del programa

6.2. Diseño

Es el núcleo técnico del proceso de ingeniería de software y se aplica independientemente del paradigma del
desarrollo usado.

Fig. 6.1.: Relación entre el modelo de análisis y el modelo de diseño.

104
 Análisis y Diseño de Sistemas

1. Diseño de datos.

Transforma el modelo de dominio de la información creado durante el análisis en las estructuras de

datos necesarias para implementar el software.

2. Diseño 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. Diseño Procedimental.

Transforma elementos estructurales de la arquitectura del programa en una descripción procedimental

de los componentes del software.

4. Diseño Arquitectónico.

Define la relación entre los principales elementos estructurales del programa.

La importancia del diseño del software reside en la calidad. El diseño es la única manera de traducir los
requisitos del cliente un sistema o producto de software.

6.2.1. Proceso del diseño

Diseño es un proceso iterativo que, parte desde las especificaciones básicas y son refinadas hasta que estos
describan el sistema completo con todo detalle.

Características:

• El diseño debe implementar todos los requisitos contenidos en el modelo de análisis y debe acomodar
todos los requerimientos implícitos que desea el cliente

• El diseño debe ser una guía que puedan leer y entender los que construyan el código y los que prueban
y mantienen el software.

• El diseño debería proporcionar una completa idea de lo que es el software, enfocando los dominios de
datos, funcional y de comportamiento desde la perspectiva de la implementación.

El diseño debería:

• Ser una organización jerárquica que, haga un uso inteligente del control entre los componentes del
software

• Ser modular, es decir, se debería hacer una partición lógica del software en elementos que realicen
funciones y subfunciones específicas.

• Contener abstracciones de datos y procedimientos

• Producir módulos (subrutinas y procedimientos, por ej.) que presenten características funcionales
independientes

• Conducir a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno
exterior

• Ser producido usando un método que pudiera repetirse según la información obtenida durante el

105
 Análisis y Diseño de Sistemas

análisis de los requerimientos de software.

Los métodos de diseño comparten los siguientes elementos:

• Un mecanismo para la transformación de un modelo de análisis en una representación del diseño

• Una notación para representar los componentes funcionales y sus interfaces

• Heurísticas para el refinamiento y la partición

• Consejos para valorar la calidad

Principios del diseño

• Diseño de software es un proceso y un modelo a la vez. El proceso de diseño es un conjunto de pasos

que permiten al diseñador describir todos los aspectos del software a construir.

• Principios para el diseño del "buen" software:

• El proceso de diseño no debería ponerse "orejeras"

• El diseño no debe inventar nada que ya esté inventado

• El diseño debería minimizar la distancia intelectual entre el sw y el problema tal y como existe en el
mundo real

• El diseño debería estructurarse para admitir cambios

• El diseño debería estructurarse para degradarse poco a poco, incluso cuando se enfrenta a datos,
sucesos o condiciones operativos aberrantes

• El diseño no es escribir código y escribir código no es diseñar

• Se debería valorar la calidad del diseño mientras se crea, no después de terminarlo

• Se debería revisar el diseño para minimizar los errores conceptuales (semánticos)

Cuando se aplican apropiadamente los principios señalados, el ingeniero de software crea un diseño 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 técnicos importantes
para el desarrollo.

Conceptos de diseño

Todos los conceptos de diseño ayudan al ingeniero a responder a las siguientes preguntas:

• ¿Qué criterios pueden emplearse para la partición del software en componentes individuales?

• ¿Cómo se extraen la función o la estructura de datos de una representación conceptual del software?

• ¿Hay criterios uniformes que definen la calidad técnica de un diseño de software?

“El principio de la sabiduría de un ingeniero de software es reconocer la diferencia entre conseguir que
funciona el programa, y hacerlo bien.”

106
 Análisis y Diseño de Sistemas

6.2.2. Principios utilizados por el Diseño

6.2.2.1. Abstracción

Cuando consideramos una solución modular para cualquier problema, se pueden plantear muchos niveles de
abstracción. Al nivel superior de abstracción se establece una solución en términos amplios usando un lenguaje del
entorno del problema. A niveles más bajos, se toma una orientación más procedimental. Se conjuga la terminología
orientada al problema con la terminología orientada a la implementación en un esfuerzo para plantear la solución.
Finalmente, en el nivel más bajo de la abstracción, la solución se establece de la manera que pueda implementarse
directamente.

Cada fase de desarrollo de software es un refinamiento en el nivel de abstracción de la solución computacional.

A medida que nos movemos a través de diferentes niveles de abstracción, trabajamos para crear abstracciones
procedimentales, de los datos y de control. Una abstracción procedimental es una secuencia dada de instrucciones que
tiene una función específica y limitada. Una abstracción de datos es una colección determinada de datos que describen
un objeto de datos. Una abstracción 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 diseño descendente. La arquitectura de un programa se

desarrolla refinando sucesivamente niveles de detalle procedimental. Se desarrolla una jerarquía descomponiendo un
enunciado macroscópico de función (una abstracción procedimental) al estilo paso a paso hasta que llegue a los
enunciados del lenguaje de programación.

En cada paso del refinamiento, se descomponen una o varias instrucciones del programa en cuestión de
instrucciones más detalladas. Esta descomposición sucesiva o refinamiento de especificaciones termina cuando todas las
instrucciones se expresan en términos de cualquier lenguaje de programación... A medida que se refinan las tareas,
también hay que refinar los datos, descomponerlos, estructurarlos, y es natural refinar las especificaciones de los datos
junto con las especificaciones del programa.

La abstracción y el refinamiento son conceptos complementarios. La abstracción permite a un diseñador

especificar procedimientos, datos, y aun así, suprimir detalles de bajo nivel a medida que progresa el diseño.

¿Qué es un módulo?

Un módulo se define como un conjunto de sentencias de programa con cuatro atributos básicos:

1. Entradas/Salidas: Datos que recibe cuando lo invocan y datos que devuelve al módulo que lo llamo.

2. Función: Qué hace con las entradas para producir las salidas.

3. Mecánica: La lógica mediante la cual lleva a cabo su función.

4. Datos internos: Zona de datos a los que únicamente puede referirse él.

Además posee otros atributos adicionales cómo:

1. Un nombre, por el cual puede ser referenciado como un todo.

2. Puede invocar o ser invocado por otros módulos.

La definición de módulo anterior es independiente del lenguaje en el cual se vaya a realizar posteriormente la
codificación.

107
 Análisis y Diseño de Sistemas

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 módulos, que están integrados para satisfacer los requisitos del programa.

“Modularidad es el atributo de software que permite que un programa ser manejable intelectualmente”. Un
software monolítico (por ej. Un programa grande compuesto por un solo modulo) no puede ser entendido fácilmente por
un lector. El número de caminos de control, ámbito de referencia, número de variables y la complejidad global hacen su
comprensión casi imposible.

Esto lleva a la conclusión: “divide y vencerás”. Es más fácil resolver un problema, cuando se rompe en piezas
manejables. Por otro lado, es posible concluir que si subdividimos el software indefinidamente, ¡el esfuerzo sería
mínimo! Desgraciadamente, intervienen otras fuerzas, que hace esta conclusión falsa. A medida que crece el número de
módulos, el esfuerzo asociado con la integración de estos también crece.

Finalmente, es importante resaltar, que un sistema puede diseñarse modularmente, aunque su implementación
deba ser monolítica. Hay situaciones en las cuales es inaceptable la introducción de una relativamente pequeña
sobrecarga de velocidad y memoria (carga de subrutinas y procedimientos). Aunque el programa fuente no parezca
modular, se mantiene su filosofía y el programa proporcionará beneficios de un sistema modular.

6.2.2.4. Ocultamiento de la información

Este principio sugiere que los módulos se caractericen por decisiones del diseño que cada uno se oculte de los
demás. Se deberían especificar y diseñar los módulos para que la información (procedimiento y los datos) contenida
dentro de un módulo sea inaccesible a otros módulos que no necesiten esta información.

La ocultación implica que se puede conseguir una modularidad eficaz definiendo un conjunto de módulos
independientes que se comunican entre sí sólo la información necesaria para conseguir la función de software. La
abstracción ayuda a los a definir las entidades procedimentales (o de información) que componen el software. La
ocultación refuerza las restricciones de acceso tanto al detalle procedimental dentro del módulo como a cualquier
estructura local de datos empleada por el módulo.

108
 Análisis y Diseño de Sistemas

6.3. Diseño de Datos (Diseño de la Base de Datos).

El propósito de esta actividad es conformar el diseño físico de la base de datos documentado en un formato
apropiado a la naturaleza de este tipo de diseño. Para lograrlo se precisa tanto de la información lógica que proporciona
el diccionario de datos y el diagrama de entidad relación, ambos componentes de la especificación de requerimientos
como de la información que entrega el documento de restricciones físicas que emana del personal de operaciones
normalmente responsable, en las unidades de informática, del centro de procesamiento, de las redes, de la seguridad del
hardware y de los datos del computador, así como de la ejecución de los programas, el manejo de los discos y otros
asuntos que bien pueden tener radical importancia para la tarea de diseñar la base de datos.

El diseño de Bases de Datos es el proceso por el que se determina la organización de una Base de Datos. El
diseño de una Base de Datos se realiza generalmente en tres fases:

La primera fase es el diseño conceptual.

La segunda fase se refiere al diseño lógico.

Y la última fase es la que estudiaremos en particular, es el Diseño Físico.

6.3.1. Diseño Físico de la Base de Datos

El punto de partida del Diseño Físico de la Base de Datos es el modelo de datos de lógica global y la
documentación que describe el modelo de la metodología del diseño de la Base de Datos lógica.

Los modelos lógicos y las relaciones derivadas fueros validadas usando la técnica de normalización, y contra
las transacciones que ellos deben soportar para los usuarios. La fase del diseño de la Base de Datos lógica fue concluida
por la fusión de los modelos de datos locales (que representa el criterio de cada usuario de la empresa) junto a la
creación de un modelo de datos global (que representa todos los criterios del usuario de la empresa).

En la tercera y final fase de la metodología del diseño de la Base de Datos, el diseñador debe decidir como
trasladar el diseño de la Base de Datos lógica (que es, las entidades, atributos, relaciones y fuerzas) a un diseño de la
Base de Datos física que puede ser implementada usando la tarjeta DBMS. Como muchas partes de Diseño Físico de la
Base de Datos son altamente dependientes de la tarjeta DBMS, debe haber más de una forma de implementar alguna
parte dada de la Base de Datos. Consecuentemente, el diseñador debe ser completamente consciente de la funcionalidad
de la tarjeta DBMS, y debe comprender las ventajas y desventajas de cada alternativa para una implementación
particular.

El diseñador también 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 lógico global en una
implementación de la Base de Datos específica. Proporcionamos los principios para cambiar estructuras de
almacenamiento por relaciones de base, decidiendo cuando crear índices, y cuando desnormalizar el modelo de datos
lógico e introducir desempleo.

Más adelante, mostramos los detalles de implementación física para aclarar la discusión. Antes presentamos la
metodología para diseños de la Base de Datos física, brevemente repasamos los procesos del diseño.

6.3.2. Comparación del Diseño Físico de la Base de Datos y el Diseño Lógico.

En la presentación de la metodología del diseño de la Base de Datos, dividimos el proceso del diseño en tres
fases principales:

109
 Análisis y Diseño de Sistemas

1) Diseño de la Base de Datos Conceptual.

2) Diseño de la Base de Datos Lógica.

3) Diseño de la Base de Datos Física.

La fase anterior al Diseño Físico, fue el diseño de la Base de Datos Lógica, es en gran parte independiente de
los detalles de implementación, tal como el funcionamiento específico de la tarjeta DBMS, y la aplicación de los
programas, pero es dependiente en el modelo de datos de la tarjeta. El rendimiento de este proceso es un modelo y
documentación de datos lógico y global que describe este modelo, así como el diccionario de datos y el esquema
relacional. A la vez, estos representan las fuentes de información para el proceso del Diseño Físico, y proporcionan al
diseñador la Base de Datos física, con un vehículo para hacer los empleos desconectados que son tan importantes para
un diseño de la Base de Datos eficiente.

Mientras el diseño de Base de Datos lógico se interesa del “qué”, el diseño de la Base de Datos Física se
interesa por el “cómo”. Esto requiere diferentes destrezas que son a menudo fundadas en personas diferentes. En
particular, el diseño de la Base de Datos física debe conocer como funciona el sistema huésped 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 Diseño Físico debe estar hecho a medida a un sistema específico
DBMS.

Sin embargo, el Diseño Físico de la Base de Datos no es una actividad aislada, hay a menudo Feed-Back entre
el Diseño Físico, lógico y de aplicación. Por ejemplo, las decisiones tomadas durante el Diseño Físico para mejorar el
funcionamiento, podría afectar a la estructura del esquema lógico.

Diseño Físico de la Base de Datos.

Es el proceso de producción de una descripción, de una implementación, de un almacenamiento secundario de

la Base de Datos, describe el almacenamiento de estructuras y métodos de acceso usados para conseguir el acceso
eficiente a los datos. El Diseño Físico de la Base de Datos es la última etapa del proceso de diseño, en el cual, teniendo
presentes los requisitos de los procesos, características 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 máxima 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 reestructuración de las relaciones para
conseguir tiempos de respuesta aceptables. Por tanto, se deberá proceder de forma iterativa desde el diseño lógico al
Diseño Físico, y viceversa para poder conseguir el ratio anteriormente citado.

Así mismo, no existe un modelo formal para el Diseño Físico (como por ejemplo, el modelo relacional para el
diseño lógico), el Diseño Físico resulta muy dependiente del producto comercial concreto hasta el momento.

110
 Análisis y Diseño de Sistemas

El Diseño Físico consta de entradas y salidas. En las entradas se podría destacar además de los objetivos del
Diseño Físico; los recursos máquina (soporte físico), recursos lógicos (sistemas operativos), esquema lógico y la
información 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 Diseño Físico 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 más importantes del Diseño Físico se encuentra la selección de los índices secundarios, que es uno de los
problemas en la instrumentación física de una Base de Datos.

Una vez diseñadas las aplicaciones se conocerá cuales son las consultas más 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 Diseño Físico, aunque no todos los sistemas comerciales disponen de
ellos, y si existen el diseñador tiene la posibilidad de actuar sobre ellos ajustándolos a cada caso concreto, algunos de
ellos se muestran a continuación, aunque más adelante los podremos ver con más detalle:

• Registros físicos.

• Punteros.

• Direccionamiento calculado (Hashing)

• Agrupamientos (cluster)

• Bloqueo y comprensión de datos.

• Asignación de espacios de almacenamientos como memorias intermedias (buffers).

• Asignación de conjuntos de datos a particiones y a dispositivos físicos.

En general los fabricantes muestran tres estrategias de Diseño Físico:

1) El SGBD impone una estructura interna, dejándole al diseñador muy poca flexibilidad, lo que suele
aumentar la independencia física/lógica, pero disminuye la eficacia.

2) El administrador diseña 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 diseñador 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 Diseño Físico de la Base de Datos implica el diseño de las relaciones de la Base y se integra fuertemente
usando el funcionamiento disponible de la tarjeta DBMS.

111
 Análisis y Diseño de Sistemas

Traducción del modelo de datos lógico global para tarjetas DBMS; implica seleccionar las estructuras de
almacenamiento y los métodos de acceso para las relaciones base.

Típicamente, el DBMS, implica un número de alternativas para construir un almacén de datos, con la excepción
del PC DBMS, el cual tiende a ajustar el almacenamiento construido. Desde el punto de vista de los usuarios, la
representación del almacenamiento interno para las relaciones debería ser transparente – el usuario debería poder
acceder a las relaciones y tuplas sin tener que especificar donde o como las tablas están almacenadas.

Esto requiere que el DBMS proporcione datos físicos independientes para que los usuarios no se vean afectados
por cambios de la estructura física de la Base de Datos, como se discutió anteriormente.

El trazado entre el modelo de datos lógico y el modelo de datos físico está definido en el esquema interno. El
diseñador debe proporcionar los detalles del Diseño Físico para ambos, el DBMS y el sistema operativo. Para el DBMS,
el diseñador debe especificar las estructuras de fichero que son usados para representar cada relación; Para el sistema
operativo, el diseñador debe especificar los detalles tales como la localización y protección de cada fichero. El paso 2
también considera enervante (es decir, debilitar las fuerzas físicas) la fuerza de normalización impuesta sobre el modelo
lógico 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
introducción del desempleo, mientras mantengan su consistencia.

El diseño de las Bases Relacionales para la tarjeta DBMS; implica el diseño de medidas de seguridad para
proteger los datos desde un acceso inautorizado. Esto implica decidir como cada modelo lógico global de datos debería
estar implementado, y los controles de acceso que son requeridos en las relaciones de base.

La fuerza de la empresa para diseñar la tarjeta DBMS; es un proceso continuo de monitorización del sistema
operacional para identificar y resolver cualquier problema del funcionamiento resultante del diseño, e implementación
de nuevos o cambiantes requerimientos.

6.3.3. La Metodología del Diseño Físico de la Base de Datos para la Base de Datos Relacional.

Esta sección nos proporciona una guía paso a paso para introducir el Diseño Físico de la Base de Datos para la
Base de Datos relacional. Por tanto, en esta metodología, demostramos la asociación cerrada entre el Diseño Físico de la
Base de Datos y la implementación para describir como los diseños alternativos pueden implementarse usando varias
tarjetas DBMS.

La primera actividad del Diseño Físico de la Base de Datos implica la traducción de las relaciones derivadas del
modelo de datos lógico 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 información
recogida durante el modelado y documentación de los datos lógicos en el diccionario de datos.

La segunda parte de este proceso usa esta información para producir el diseño de la base relacional. Este
proceso requiere un conocimiento profundo de las funciones ofrecidas por la tarjeta DBMS. Por ejemplo, el diseñador
necesitará conocer:

• Si el sistema soporta la definición de clave primaria, clave secundaria y clave externa.

• Si el sistema soporta la definición de datos requeridos (que es, si el sistema permite atributos definidos
como NO NULOS).

• Si el sistema soporta la definición de dominios.

• Si el sistema soporta la definición de la fuerza de la empresa.

• Como crear una base relacional.

112
 Análisis y Diseño de Sistemas

6.3.4. Diseño de las Bases Relacionales para la Tarjeta DBMS.

Para comenzar el proceso del Diseño Físico, primero necesitamos cotejar y asimilar la información sobre
relaciones producidas durante el modelado de datos lógicos. La información puede ser obtenida desde el diccionario de
datos y la definición de las relaciones definidas usando el DataBase Design Language (DBDL). Por cada relación
identificada en el modelo de datos lógico global, nosotros vamos a definir los siguientes pasos:

• El nombre de la relación.

• 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, también tenemos para cada atributo:

• Los dominios, la consistencia de un tipo de dato, longitud, y alguna fuerza en el dominio.

• Una opción para dejar de evaluar los atributos.

• Si el atributo puede tener nulidad.

• Si el atributo es derivado y, como sería computado.

113
 Análisis y Diseño de Sistemas

6.4. Diseño de Interfaz.

6.4.1. Diseño Efectivo de Salidas. Objetivos en el diseño de salidas

La salida es la información que reciben los usuarios del sistema de información. 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 confían en las salidas para la realización de sus tareas; y con frecuencia, juzgan el
mérito 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 diseñar una salida son seis:

1. Diseñar una salida para satisfacer el objetivo planteado

Toda salida debe contar con un propósito explícito. No es suficiente que se presente a los usuarios un reporte o
una pantalla, solo porque tecnológicamente es posible hacerlo. Durante la fase del análisis de determinación de los
requerimientos de información, el analista de sistemas identifica los propósitos a satisfacer; y con base en tales
propósitos se diseña la salida.

2. Diseñar una salida que se adapte al usuario

Es difícil personalizar la salida con un gran sistema de información que atiende a numerosos usuarios con
diferentes propósitos. Con base en entrevistas, observaciones, consideraciones de costo y, tal vez, prototipos, será
posible diseñar salidas que se ajusten a la mayoría, si no a todas las necesidades de los usuarios y sus preferencias.

3. Proveer la cantidad adecuada de información

Parte de la tarea del diseño de la salida es decidir que cantidad de información es correcta para los usuarios,
pronto se dará cuenta que es una tarea muy difícil, ya que los requerimientos de información cambian de manera
continua. Por ejemplo más que acomodar en una sola pantalla las ventas de todo el año, se podría 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

¿Quién debe recibir la salida? El incremento de las salidas en línea (on-line), desplegadas en pantalla y que son
accesibles de manera individual, han resuelto parte del problema de la distribución, pero una distribución apropiada
todavía 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 diseñen los reportes, si éstos no los ven los tomadores de decisiones
pertinentes; carecerán de valor.

5. Proporcionar oportunamente la salida

¿En qué momento debe generarse la salida? Una queja común de los usuarios es que no reciben de manera
oportuna la información para la toma de decisiones, uno de los objetivos que debe perseguir el analista es la puntualidad
en la distribución de la salida. Muchos informes se requieren por día, por mes, por año y habrá otros por excepción. Una
presentación a tiempo puede llegar a ser decisiva para la operación de la empresa.

6. Elegir el método correcto de salida

La salida puede tomar diferentes formas, incluyendo los reportes impresos en papel, la información presente en
pantalla, sonidos de audio y digitalizados que simulan la voz humana y las microfichas. La elección del método correcto
para cada tipo de usuario es otro de los objetivos en el diseño de la salida. El analista debe evaluar las ventajas
involucradas al elegir un método de salida. Los costos difieren, así como la flexibilidad, vida media, distribución,
almacenamiento y posibilidades de acceso y transporte, y, finalmente, el impacto global hacia el usuario. La elección del
método de salida no es trivial, ni es una conclusión predeterminada.

114
 Análisis y Diseño de Sistemas

6.4.1.1. Relación del contenido de la salida con el método de salida

Es posible concebir la salida como cualquier cosa que sale de la organización, a la cual se le llamaría “salida
externa” o que permanece dentro de la organización, la cual sería 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 diseñan por el analista de sistemas para
cumplir con dos funciones, como lo haría 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 sólo por él mecanismo de distribución, sino además, por
su diseño y apariencia. Muchos documentos externos, si se desea que se utilicen correctamente, deben incluir
instrucciones para el receptor. Además, muchas salidas externas se imprimen en formas que contienen el emblema de la
compañía 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 organización, 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 históricos que se manejan como reportes por excepción
y que se emiten sólo en el momento de la excepción (una desviación de lo esperado). Por ejemplo una lista de todos los
empleados sin faltas en el año.

6.4.1.2. La elección de la tecnología de salida

Para producir diferentes tipos de salidas, se requiere el uso de diferentes tecnologías. 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 líquido. Las salidas de audio
pueden amplificarse a través de parlantes o escucharse a través de una pequeña bocina del microcomputador. Las
microfichas son salidas creadas por equipos de cámaras especiales y filmadas en microfichas y microfilms.

En cierta manera, la salida de audio podría 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 comúnmente cuenta con una amplia distribución. La salida de audio por ejemplo sirve para atender
pedidos de números de catálogo con llamadas libres de cobro, (0800), las 24 horas del día. Al utilizar un teléfono digital,
los clientes marcan el número y en respuesta a las instrucciones que reciben por el audio, los clientes seleccionan el
artículo numerado, la cantidad, el precio y refieren el número de su tarjeta de crédito. Esto implica para los almacenes la
captura de ventas que de otra forma se perderían, ya sea porque la contratación de empleados pudiera ser muy cara para
justificar una atención por 24 horas.

6.4.1.3. Consideraciones al elegir la tecnología de salida

Existen varios elementos a considerar en su elección. Aunque la tecnología cambia con rapidez, hay principios
útiles que permanecen prácticamente constantes en relación a los avances tecnológicos. Estos elementos son:

1. ¿Quién usará la salida?

Por ejemplo cuando los gerentes de distrito se encuentran alejados de sus oficinas por grandes períodos,
necesitan de salidas impresas que puedan llevar consigo, conforme visiten a los gerentes de su región. 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
 Análisis y Diseño de Sistemas

También, aplican diferentes estándares, dependiendo si el receptor de la salida es interno o externo a la

organización. Los receptores de salidas externas (clientes, proveedores) requerirán de salidas diferentes que los usuarios
internos de la empresa.

Con frecuencia, los clientes carecen de acceso a las salidas electrónicas, ya que simplemente no cuentan con el
equipo requerido. En este caso, usted debe proporcionar una salida impresa. El conocer quién 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 estándares en papel de computador, una salida en letra de calidad se requerirá para una
correspondencia comercial, con un público externo.

2. ¿Cuántas personas necesitan la salida?

La elección de la tecnología de salida también queda influenciada por el número de usuarios que la usarán. Si
numerosas personas requieren de la salida, probablemente se justificarían las copias impresas. Si sólo un usuario
requiere de la salida, una salida por pantalla, en microfichas, o aún, una salida de audio puede ser lo más apropiado.

Si numerosos usuarios de la empresa necesitan salidas diferentes a tiempos diferentes, por períodos cortos y la
requieren con rapidez, entonces una alternativa será el uso de terminales conectadas en línea y con acceso directo a la
base de datos.

3. ¿En dónde se necesita la salida?

Otro factor que influye en la elección de la tecnología de salida es el destino físico de ella. Aquella información
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 información que
deba transmitirse a los usuarios a grandes distancias en operaciones satélites, puede mejor distribuirse de manera
electrónica y el receptor decidirá si lo imprime, lo presenta en pantalla o lo almacena.

4. ¿Cuál es el propósito de la salida?

Otro factor a considerar para elegir la tecnología es la función de la salida. Si la salida tiene el propósito de
atraer accionistas a la organización, y que éstos tengan a su disposición las finanzas corporativas, entonces, lo más
adecuado sería presentar un reporte anual con excelente diseño. Si el propósito 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 sería hacer uso de las pantallas de vídeo o aun del audio.

5. ¿Con qué frecuencia se requiere la salida?

Entre más frecuente se accesa una salida, más importante será el disponer con terminales conectadas en línea 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
línea, con presentaciones en pantallas. La adopción de este tipo de tecnología permite que el usuario tenga un fácil
acceso y disminuye a la vez el riesgo del desgaste físico que deteriora la frecuente manipulación de las salidas impresas.

6. ¿Bajo qué regulaciones particulares se produce la salida?

Ciertas salidas están sujetas a la regulación del gobierno que impone el uso de determinadas tecnologías. Por
ejemplo las declaraciones juradas del SII o las boletas y facturas electrónicas.

7. ¿Cuáles 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
elección de la tecnología de salida. La mayoría de los vendedores le ayudarán a estimar los costos iniciales de compra o
alquiler de un computador, incluyendo el costo de impresoras y terminales de vídeo. Sin embargo, muchos vendedores
no proporcionarán información acerca del costo para mantener operando una impresora (papel, cintas, reparaciones y

116
 Análisis y Diseño de Sistemas

mantenimiento). De tal forma que es responsabilidad del analista, investigar el costo de operación de las diferentes
tecnologías de salida.

8. ¿Cuáles son los requisitos ambientales para las tecnologías 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. Además el volumen de la salida de audio debe ser lo suficientemente alto como para escucharse, no
debería ser audible para los otros empleados (o clientes) que no lo utilizan.

En el otro extremo ciertas tecnologías son apreciadas por su discreción. Las bibliotecas que enfatizan el silencio
en el área de trabajo, hacen extensivo el uso de monitores de vídeo. Estos son mucho más silenciosos que la operación
de impresoras y, más aún que el uso de cardex consultados físicamente 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 presentación de las salidas:

• La manera de ordenar la información

Se introduce sesgo en la salida cuando el analista elige la manera de ordenar la información de un reporte.
Formas comunes de ordenamiento incluyen el cronológico, el alfabético y el de costos.

• La manera de establecer los límites de aceptación

Una segunda fuente importante de error en la salida es la definición preliminar de límites para valores
particulares que serán reportados. El analista de sistemas podría sin intención, establecer un límite demasiado bajo o
demasiado alto, rangos estrechos de las salidas por excepción o rangos amplios para estas salidas.

• La elección de gráficas

El tamaño de la gráfica debe ser proporcional, de tal forma que el usuario no confunda la importancia de las
variables presentadas. La elección del color de la gráfica es de suma importancia, de tal forma que no se distorsionen sus
conclusiones. El tipo elegido de gráfica para la salida también es una fuente de sesgo potencial. Una gráfica de torta es
inadecuada si los porcentajes del conjunto no es lo más relevante. Las gráficas de barras y de columnas pueden exagerar
las diferencias entre las variables.

Los analistas de sistemas cuentan con ciertas estrategias específicas para evitar el sesgo en la salida que
diseñen:

1- Reconocer la fuente del sesgo

2- Diseño 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- Creación de una salida flexible que permita al usuario modificar los límites, los rangos y el ordenamiento.

5- Proponer a los usuarios diferentes salidas para conducir “pruebas realistas” sobre la salida del sistema.
Prototipos.

En síntesis el analista de sistemas debe solicitar la retroalimentación activa del usuario, respecto a la salida. El
proceso de diseño requerirá de varias interacciones, antes de que el usuario sienta que es de utilidad la salida. Otro

117
 Análisis y Diseño de Sistemas

aspecto importante es diseñar una salida en la que los usuarios sean capaces de modificar los límites y los rangos
establecidos para el usuario.

6.4.1.5. Diseño de la salida impresa

Al hacer uso de la información obtenida durante la fase de determinación de los requisitos de información y una
vez decidido, el uso de la salida impresa, el analista de sistemas se encuentra en condiciones de iniciar el diseño físico de
la salida. La fuente de información básica es el diccionario de datos.

Convenciones en el diseño de reportes

Información constante:

Es la información que permanece sin cambios cada vez que se imprime el reporte. Para indicar la información
constante, el analista la anota en la forma con un carácter por espacio. El título del reporte y los encabezados de todas las
columnas se consideran como información constante.

Información variable:

Es la información que varía cada vez que el reporte se imprime.

Para determinar el ancho del reporte, determine para cada uno de los campos el máximo de:

1) los requerimientos de longitud del campo de los datos elementales, conforme éstos aparezcan en el
diccionario de datos, y

2) el renglón más largo que propone como encabezado de columna. Luego,

3) agregue los espacios que pretendan dar una separación en ambos lados. Finalmente, sume estos estimados
del campo para obtener el ancho estimado.

Calidad del papel, tipo y tamaño

La salida puede imprimirse en innumerables tipos de papel, la restricción 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 carbón, será más costoso que el simple papel de computador.

La calidad del papel también difiere por el contenido de algodón. Mientras más algodón contenga, tendrá una
mejor calidad, durabilidad y mayor precio. Pero un negocio quizás querrá que su correspondencia particular se imprima
en papel bond que contenga algodón, mediante el uso de una impresora de calidad, todo ello con el fin de dar una
imagen de mayor distinción.

Salidas en formas especiales

Las formas preimpresas tienen numerosos propósitos; entre ellos tenemos el envío a los clientes de documentos
de ida y vuelta. A través de uso de colores y de diseños corporativos las formas preimpresas pueden llevar el logotipo de
la corporación. El uso de formas innovadoras, colores y distribuciones motivan de manera dramática la atención del
usuario hacia el reporte particular.

Consideraciones de diseño

• Atributos funcionales:

Los atributos funcionales de un reporte impreso incluyen el encabezado o título del reporte, el número de la
página, la fecha de preparación, los rótulos de las columnas, el agrupamiento de los datos relacionados y el uso de
elementos de pausa. Cada uno de ellos cumple con un propósito específico para el usuario.

118
 Análisis y Diseño de Sistemas

El encabezado o título del reporte dirige al usuario de manera inmediata al tema de su lectura. El título debe ser
descriptivo y conciso. Es redundante incluir la palabra reporte en el título.

Cada página debe numerarse de tal forma que el usuario cuente fácilmente con un punto de referencia cuando
discuta la salida con otros o vuelva a localizar datos importantes. También si las páginas de las salidas se encuentran
separadas, su paginación es invaluable para reconstruir el documento.

En cada impresión incluya la fecha de la preparación 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 líneas adicionales el resto de los datos. Por ejemplo, si 200 tiendas de venta de indumentaria
deportiva se agruparan por zona geográfica, el reporte puede contar con cortes al final de cada una de las zonas.

• Atributos estilísticos/estéticos

Los reportes impresos están organizados de tal forma como los apreciarían 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 también cubre una función importante; pero su ubicación en la página también le
confiere una característica estética. Dé atención a los cortes de control, a las totales y a otra información relevante,
encerrándolos en cuadros mediante el uso de caracteres especiales, tales como asteriscos o espacios adicionales.

Esto permite agilizar la búsqueda de información decisiva y evita la larga impresión de columnas continuas de
información.

Las salidas de reportes impresos requieren de amplios márgenes a la derecha y a la izquierda, así como, en los
bordes superior e inferior. Esto permite atraer la atención del usuario al material que se centra en la página facilitando la
lectura. No debe subestimarse la relevancia de la distribución, la legibilidad y la facilidad de uso, ya que la salida se crea
para ser utilizada.

Pasos para la preparación de la hoja de distribución de la salida

A continuación se presenta una guía, paso a paso, para la preparación de la hoja de distribución de la salida:

4) Determine las necesidades del reporte.

5) Identifique a los usuarios.

6) Determine la información que se va a incluir.

7) Cuente el número de espacios necesarios y decida la dimensión global del reporte.

8) Titule el reporte

9) Numere las páginas del reporte

10) Incluya la fecha de preparación del reporte

11) Rotule cada columna de datos de manera adecuada

12) Defina la línea de detalles para los datos variables, indicando si cada espacio se utilizará para un
carácter alfabético, especial o numérico.

13) Indique la posición de las totales (cortes de control).

119
 Análisis y Diseño de Sistemas

14) Revise el boceto (o prototipo) de los reportes con los usuarios y programadores para evaluar su
factibilidad, utilidad, legibilidad, compresión y apariencia estética.

Estructura jerárquica de una salida impresa

La estructura jerárquica de una salida, nos permite analizar la composición de la misma y las ocurrencias de los
datos dentro de la salida.

Tiene como objetivo indicar el número de veces que aparece un subconjunto de datos en el conjunto al que
pertenece. Es posible colocar los signos de exclusión, inclusión o exclusión exclusiva, cuando los subconjuntos
pertenecientes al mismo nivel aparezcan 0 o 1 vez en el conjunto al que pertenecen.

6.4.2. Diseño de Pantalla.

Observe que las salidas por pantalla, difieren de diversas maneras de las salidas impresas. Estas son efímeras,
es decir, una imagen en monitor no es “permanente”, de la misma manera como lo sería una impresión; pueden estar
dirigidas en forma más específica hacia el usuario: tienen un formato con mayor flexibilidad, no son portables; y en
ocasiones, las salidas por pantalla permiten modificaciones mediante una interacción directa.

Además, los usuarios deben saber qué teclas presionar si desean consultar pantallas adicionales, cómo concluir
la presentación y si es posible, cómo interactuar con lo desplegado en la pantalla. El acceso a las presentaciones por
pantalla puede controlarse a través del uso de un código confidencial (password), mientras que la distribución de las
salidas impresas se controla de manera distinta.

6.4.2.1. Lineamientos para el diseño de pantallas

Existen cuatro lineamientos que facilitan el diseño de las pantallas. Para resumir, estos son:

1) Mantenga una pantalla sencilla.

2) Mantenga una presentación consistente en la pantalla.

3) Facilite el movimiento del usuario entre pantallas.

4) Cree una pantalla atractiva.

Las dimensiones típicas de una pantalla son de 80 columnas por 24 renglones. Las diferencias en el diseño de
pantallas radican en la necesidad de indicar los cambios de la pantalla, los movimientos entre pantallas y la conclusión
de la presentación de la salida.

Cuando la pantalla se encuentra en la fase de diseño 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 retroalimentación acerca de
las modificaciones o mejoras que desearían. Este es un proceso interactivo que continúa 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 retroalimentación de los
usuarios para diseñar pantallas de gran valía. Una vez aprobada por los usuarios, el diseño de la pantalla puede
plasmarse en la hoja de diseño de pantallas.

La presentación orienta al usuario a través 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
presentación, obtener ayuda o contar con más detalle.

Las pantallas de salida dentro de una aplicación deben presentar de manera consistente la información de
pantalla a pantalla.

120
 Análisis y Diseño de Sistemas

6.4.2.2. Objetivos del diseño de entradas

Un buen diseño de los formatos y las pantallas de entrada debe satisfacer los objetivos de eficacia, precisión,
facilidad de uso, consistencia, sencillez y atracción.

La eficacia significa que las formas y las pantallas de entrada satisfagan propósitos específicos del sistema de
información de la administración, mientras que la precisión se refiere a un diseño tal que asegure una realización
satisfactoria. La facilidad de uso implica que tanto las formas como las pantallas serán explícitas y no requerirán 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 aplicación a otra, mientras que la sencillez se refiere a mantener en un mínimo los elementos
indispensables que centren la atención del usuario. La atracción implica que el usuario disfrutará del uso o tránsito a
través de las formas y las pantallas cuyos diseños les sean más atractivos.

6.4.2.3. Buen diseño de los formularios de entrada de datos

Los formularios de entrada de datos son instrumentos importantes para el desempeño adecuado del trabajo. Por
definición, 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 información que los miembros de la organización
requieren y con frecuencia se alimentan al computador.

Existen cuatro lineamientos importantes para el diseño de los formularios de entrada:

1. Diseñe formas fáciles de llenar

Para reducir el error, agilizar su llenado y facilitar la captura de datos, es esencial que las formas sean
fáciles de llenar. El costo de las formas es mínimo si se compara con el costo del tiempo que ocupa el empleado
en el llenado y en la alimentación de los datos en el computador.

Es importante tener en cuenta el Flujo de la forma: El diseño 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 también respetar las siete secciones de una forma: Una segunda técnica que facilita el
llenado correcto de las formas consiste en la agrupación lógica de la información. Las siete secciones
principales que le confieren solidez a una forma son:
a) Encabezado
b) Identificación y acceso
c) Instrucciones
d) Cuerpo del formulario
e) Firma y verificación
f) Totales
g) Comentarios
De manera ideal, estas secciones deberían aparecer en una sola página ordenada. Obsérvese que las
siete secciones cubren la información básica requerida en la mayoría de los formularios. La parte superior del
formulario recibe tres secciones: el encabezado, las secciones de identificación y acceso y la sección de
instrucciones.

La sección del encabezado por lo general incluye el nombre y la dirección de la empresa que origina la
forma. La sección de identificación 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 organización requiere conservar un
documento por un determinado número de años. La sección de instrucciones nos dice cómo debería 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
 Análisis y Diseño de Sistemas

La parte inferior de la forma se integra con tres secciones: firmas y verificación, total y comentarios.

Otro aspecto a tener en cuenta es el rotulado: Los rótulos le indican a las personas qué anotar en un
espacio en blanco, en un renglón o en un recuadro. Se dispone de varias alternativas para rotular. Los rótulos de
línea pueden encontrarse a la izquierda de áreas en blanco y en el mismo renglón, o bien pueden imprimirse
debajo de la línea donde se registrará el dato. La ventaja de ubicar rótulos debajo de las líneas es que se dispone
de más espacio en tal línea para el dato. Otra forma de rotular es proporcionar un recuadro para los datos, en
lugar de la línea.

Los rótulos pueden ubicarse dentro, fuera o debajo del recuadro. Los recuadros auxilian a la gente a
introducir los datos en el sitio correcto y también 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 rótulos tanto encima como debajo de las líneas se presta a confusión.

Los cuadros de selección son más convenientes cuando el número 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 fácil compresión para la siguiente persona que reciba la forma y a la vez permite mantener una
organización coherente de los datos.

Puede utilizarse una combinación de rótulos y cuadros. Es posible que pudiera necesitarse de
diferentes estilos de rotulado.

2. Asegúrese que las formas cumplan con el propósito para el cual fueron diseñadas.

3. Diseñe formas que aseguren un llenado preciso.

4. Mantenga las formas atractivas.

Las formas estéticas motivan a la gente y hacen que se les dé importancia. Esto significará que cuando
la gente llene las formas, se sentirá más satisfecha y además llenará la forma en toda su extensión. Las formas
no deben parecer amontonadas, sino más bien, deben dar una apariencia de organización y lógica, aún después
de llenarse. Se logra lo anterior, al proporcionar suficiente espacio para alojar respuestas mecanográficas o
manuscritas. El uso de diferentes tipos de letra dentro de la misma forma puede mejorar su imagen. Puede
motivarse el interés en la forma al separar categorías y subcategorías con líneas de diferente grosor. Los tipos
de letra y las líneas de diferentes grosores son elementos útiles de diseño para atraer la atención y hacer que la
gente se sienta segura de que llena una forma correctamente.

6.4.2.4. El buen diseño de pantallas

Mucho de lo que ya hemos dicho acerca del buen diseño de formularios de entrada puede transferirse al diseño
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 señalador) en la pantalla, que orienta al usuario sobre la posición actual de acceso.
Conforme se introducen los datos en la pantalla, el cursor se irá desplazando un carácter hacia delante de la dirección de
la captura.

Existen cuatro lineamientos para el diseño de pantallas. Ellos son:

1. Mantenga la pantalla sencilla

La pantalla debe mostrar solo lo que es necesario para la acción particular que se lleva a cabo.

122
 Análisis y Diseño de Sistemas

a) Las tres secciones de la pantalla.

La parte superior de la pantalla contiene la sección del encabezado, parte de la cual se

encuentra programada para indicar al usuario en donde se encuentra dentro de la aplicación o paquete.
El resto del encabezado puede incluir otros elementos, tales como el nombre del archivo que el usuario
ha creado.

También debe proporcionarse al usuario la definición de los campos indicando la dimensión

previsible del dato para cada campo de la pantalla.

La tercera sección de la pantalla se denomina sección de “Comentarios e Instrucciones”. Esta

sección puede contener un menú conciso de órdenes que recuerde al usuario las funciones básicas del
sistema, tales como el cambio de pantalla, o funciones tales como la grabación de archivos o la
conclusión de la sesión de captura. La inclusión de tales funciones básicas permite que los usuarios sin
experiencia se sientan más 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

básicas que al ser llamadas sobrepongan ventanas, que cubran parcial o totalmente la pantalla activa
con nueva información.

De esta manera, el usuario comienza la interacción con el sistema, con una pantalla sencilla y
de buen diseño, y controlando la complejidad del sistema a través del uso de ventanas múltiples.

Al contar con tal ventana se facilita el acceso rápido y correcto, ya que el usuario no necesita
recordar aquellos códigos de poco uso o dejar la pantalla para consultar una lista impresa, antes de
completar la entrada de los datos. Además, el sistema desarrollado puede programarse para aceptar
solo a los códigos de clasificación listados en la pantalla y de manera automática, presentar la ventana
si el código tecleado es incorrecto. Esto evita los errores que pudieran ocurrir si cualquier código de
clasificación 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 diseño 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 también se mantiene, si la información se localiza en la
misma área cada vez que se accesa una nueva pantalla.

3. Facilidad de movimiento.

El tercer lineamiento para un buen diseño de pantalla es la facilidad de desplazarse con sencillez entre
una pantalla y otra.

a) Desplazamiento

Básicamente 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 técnicas básicas de movimiento entre pantallas, permite que los usuarios se
desplacen con rapidez a otras pantallas, mediante la colocación del cursor junto a un comando

123
 Análisis y Diseño de Sistemas

específico. 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) Diálogo en pantalla

El uso de diálogos entre el usuario y el computador facilita cierta clase de movimientos entre
las pantallas.

4. Diseño de una pantalla atractiva

Las pantallas deben atraer al usuario y mantener su atención. 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
múltiples, que amontonar todo en una sola. Existen múltiples recursos para lograr esto, algunos de ellos son:

a) El vídeo inverso y los cursores que destellan

b) El uso de diferentes tipos de letras

c) El uso de imágenes en el diseño de pantallas

Utilice imágenes típicas que los usuarios puedan interpretar fácilmente. Las imágenes para
una aplicación particular deben limitarse a no más de veinte formas reconocibles, de esta forma el
vocabulario de imágenes no se saturará y puede desarrollarse un buen esquema de codificación. Utilice
de manera consistente las imágenes que a todo lo largo de la aplicación deban aparecer juntas. Esto
asegura continuidad y comprensión. En general las imágenes son útiles si conllevan un significado.

d) El uso de color en el diseño 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
 Análisis y Diseño de Sistemas

6.5. Diseño Procedimental

El diseño procedimental transforma los elementos estructurales en una descripción procedimental del software.
El diseño procedimental se realiza después de que se ha establecido la estructura del programa y de los datos. Define los
algoritmos de procesamiento necesarios.

Permite definir un módulo sin entrar en excesivos detalles. La interfaz del módulo contiene los parámetros de
entrada y de salida, mientras la función del módulo describe las tareas que este lleva a cabo. Se permite el uso de tablas,
fórmulas, lenguaje natural, etc. Permite variar el grado de formalismo en la definición del módulo, generalmente, dando
bastante libertad a los programadores. Su inclusión como comentario en el código final facilita el mantenimiento.

Esta documentación permite a los usuarios, analistas, diseñadores y programadores ver el sistema, su software y
los procedimientos, sin necesidad de una interacción directa. Cierta documentación proporciona un panorama del
sistema, otra contiene los procedimientos que detalla lo que debe realizarse para operar el software y una distinta detalla
el código de programa utilizado.

No existe una sola técnica sencilla y estandarizada para la documentación.

Dentro del análisis de sistemas se usan técnicas de documentación para la especificación de procesos, pero los
requerimientos que estas especificaciones deben satisfacer son diferentes a las del diseño.

Una buena técnica de especificación 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 diseño e implantación

Debido a estos factores, las técnicas más utilizadas en esta fase son: lenguaje estructurado o seudocódigo,
árboles de decisión y tablas de decisión.

Pero además de utilizar una forma procedural, se debe adicionar una forma gráfica que permita delimitar los
distintos objetos de programa que participan en la función del módulo, propiamente tal. Esta forma se denomina
“Diagrama de Bloques”, la cual permite a través de dibujos simples los elementos participantes en un proceso
determinado. Los elementos gráficos son:

Proceso o Módulo nombre

Dispositivo de Entrada

Pantalla nombre nombre nombre

nombre
Archivo de Datos

Base de Datos nombre

125
 Análisis y Diseño de Sistemas

Informe o Listado (Impresión) nombre

Dispositivo de Respaldo nombre

Dirección de la Información

Documentos de Entrada

Otra manera de especificar un módulo es a través de un lenguaje de manipulación de datos, el cual es ofrecido
por la gran mayoría de los administradores de bases de datos (DBMS), denominado SQL (Secuential Query Language).

6.6. Diseño Arquitectónico.

El Diseño Arquitectónico o estructural define las relaciones entre los principales elementos estructurales del
programa. El objetivo principal del diseño estructural es desarrollar una estructura de programa modular y representar
las relaciones de control entre los módulos.

Concluido el diseño se genera el código fuente y para integrar y validar el software, se llevan a cabo pruebas
del software.

126
 Análisis y Diseño de Sistemas

7. Programación

Cuando termina la etapa de diseño, normalmente comienza la etapa de programación y prueba. La fase de
programación o implantación de un proyecto involucra la escritura de instrucciones en un lenguaje de programación para
implantar lo que el analista ha especificado y el diseñador ha organizado en módulos.

Durante esta fase el analista tiene un papel importante. En el caso extremo, una vez terminada su labor de
especificación del sistema pasa algún tiempo con el equipo de diseño durante las primeras etapas del diseño, 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 programación:

• Por ser líder del proyecto debe estar involucrado en el mismo hasta la prueba final, la aceptación y entrega
al usuario final. Además debe verificar que el código 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 más usuarios por ser los más aptos para pensar en casos
excepcionales y pocos usuales de prueba. El desarrollo de pruebas puede empezar tan pronto como se
termina la especificación.

Dado a que por lo pronto solo conoce el contenido lógico de las entradas y salidas, debe esperar a que el
modelo de implantación del usuario quede terminado para conocer el formato físico de los mismos y poder
conocer las restricciones operacionales (tiempo de respuesta, volúmenes, 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, preparación de los usuarios o en la planeación de
la instalación del nuevo sistema y conversión de datos desde el otro sistema. En la mayor parte de los
casos, esto puede llevarse a cabo de manera paralela con la programación y prueba del nuevo sistema.

• En el caso de que la especificación no se comprenda, pueda estar incompleta, ser inconsistente o

contradictoria es necesario que el programador consulte periódicamente para revisar y aclarar las
especificaciones. Otra variante puede ser la solicitud de cambio de especificación por ser demasiado difícil
de implantar.

• Puede que los usuarios cambien los requerimientos, incluso cuando los programadores están implantando
lo que decían querer.

Así como el análisis estructurado involucra una progresión 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 diseño involucra modelos de diseño que van desde diagramas de estructura de alto nivel hasta
formas de bajo nivel como el pseudocódigo y diagrama de flujo, la programación debe seguir este mismo patrón. Se
escriben módulos ejecutivos de alto nivel. Luego se desarrollaran los módulos de bajo nivel que llevan a cabo cálculos
detallados, validan datos de entrada, etc.

Las cuestiones que se deben tomar en cuenta en programación, independientemente del lenguaje utilizado son:

- Productividad: consiste en escribir mas software, mas rápidamente. 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 más importante que la eficiencia.

127
 Análisis y Diseño de Sistemas

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 volúmenes de información. Para aplicaciones de estos tipos resulta importante minimizar la cantidad de tiempo
de CPU requerido por el programa. También puede ser importante minimizar la utilización 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 número de errores y reduzca la
productividad de la persona que escribe el programa.

Corrección: es importante que el lenguaje revise cuidadosamente todo el código y detecte inconsistencias,
referencias ilegales, exija la declaración de variables, entre otros controles. Esto es indispensable principalmente en
aplicaciones donde un error puede ser critico.

Portabilidad: aspecto importante que permite correr la aplicación en distintos tipos de computadoras. Sin
embargo no existe un lenguaje universalmente portátil; siempre hay forma de que el programador aproveche las
características especiales de una computadora o un sistema operativo específicos. Por ello, si la portabilidad es un factor
importante, además de tener en cuenta el lenguaje se debe analizar el tipo de programación.

Mantenibilidad: por durar mucho tiempo los sistemas, el software debe mantenerse.

7.2. Niveles de la organización que construye el sistema

La construcción de sistema mediante una organización constituida por niveles es una forma de aprovechar más
eficientemente los recursos humanos aprovechando sus experiencias y permitiendo una actualización constante en las
nuevas tecnologías.

Consiste en dejar que la gente con mayor experiencia (analistas/diseñadores) realice las tareas de mayor nivel y
dejar la de menor nivel a los más novatos (programadores). Esto permite que la programación no se vuelva en una tarea
mecánica consistiendo es la simple traducción de las especificaciones. De esta manera la gente mayor experimentada
hará no solo las tareas de análisis de alto nivel sino también las de diseño de alto nivel e incluso escribir código de alto
nivel. Por otro lado, los novatos estarían involucrados en el proyecto desde el principio (tan pronto como se terminen las
tareas de análisis de alto nivel) y participarían en el trabajo de escribir especificaciones de procesos y módulos, en
desarrollar entradas para el diccionario de datos y escribir código para los módulos de nivel inferior.

Esto permite que los novatos hagan tareas creativas y codifiquen sus propias especificaciones e involucrándolos
en el proceso de análisis desde las etapas tempranas de su carrera. Simultáneamente obligara a los más maduros estar en
contacto con la tecnología al hacer tareas de diseño y programación.

128
 Análisis y Diseño de Sistemas

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 crítico para determinar la calidad del software, entonces el objetivo de una prueba es
descubrir algún error. Un caso de prueba es bueno cuando su ejecución conlleva una probabilidad elevada de encontrar
un error. El éxito de la prueba se mide en función de la capacidad de detectar un error que estaba oculto.

El diseño de casos de prueba para la verificación 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 diseño 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 lógico, es decir, verdadera y falsa.

• Ejecutar todos los bucles en sus límites operacionales

• Ejercitar las estructuras internas de datos.

Consideraciones:

• Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de
que se ejecute un camino del programa.

• A menudo creemos que un camino lógico tiene pocas posibilidades de ejecutarse cuando, de hecho, se
puede ejecutar de forma regular.

• Los errores tipográficos son aleatorios.

• Tal como apuntó Beizer, “los errores se esconden en los rincones y se aglomeran en los límites”.

8.1.1. Prueba del camino básico

La prueba del camino básico es una técnica 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 condición) que no estaba considerada en el conjunto de caminos independientes calculados hasta ese momento. Para

129
 Análisis y Diseño de Sistemas

obtener el conjunto un conjunto de caminos independientes se construirá el Grafo de Flujo asociado y se calculará su
Complejidad Ciclomática.

Cada nodo del grafo corresponde a una o más sentencias de código fuente. Cada nodo que contiene una
condición se denomina nodo predicado. Cualquier representación del diseño procedural se puede traducir a un grafo de
flujo.

Si se diseñan casos de prueba que cubran los caminos básicos, se garantiza la ejecución de cada sentencia al
menos una vez y la prueba de cada condición sus dos posibilidades (verdadera y falsa).

8.1.2. Pruebas de estructura de control

La técnica de prueba del camino básico 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 básico, no nos asegura completamente la
corrección del software.

Veremos a continuación otras variantes de la prueba de la estructura de control. Estas variantes amplían 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 método de diseño de casos de prueba que ejercita las condiciones lógicas
contenidas en el módulo de un programa. Los tipos de errores que pueden aparecer en una condición son los siguientes:

• Existe un error en un operador lógico (que sobra, falta o no es el que corresponde).

• Existe un error en un paréntesis lógico (cambiando el significado de los operadores involucrados).

• Existe un error en un operador relacional (operadores de comparación de igualdad, menor o igual,

etc.).

• Existe un error en una expresión aritmética.

8.1.4. Prueba de Bucles

Pruebas para Bucles simples. (N es el número máximo 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 más interior estableciendo los demás bucles en sus valores mínimos.

130
 Análisis y Diseño de Sistemas

• Realizar las pruebas de bucle simple para el más interior manteniendo los demás en sus valores
mínimos.

• Avanzar hacia fuera confeccionando pruebas para el siguiente bucle manteniendo todos los externos
en los valores mínimos y los demás bucles anidados en sus valores típicos.

• 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 evaluarán como bucles anidados.

Pruebas para Bucles no estructurados

Siempre que se usen los mecanismos que aporta la programación estructurada, este tipo de bucles no
estarán presentes.

8.2. Pruebas de caja negra

Los métodos de la caja negra se enfocan los requisitos funcionales del software. La prueba de la caja negra
intenta encontrar errores de los siguientes tipos:

• 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 inicialización o terminación.

8.2.1. Partición Equivalente

La partición equivalente es un método 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 partición equivalente se enfoca pues a definir casos de prueba
para descubrir clases de errores. Se define una condición de entrada (valor numérico específico, rango de valores,
conjunto de valores relacionados o condición lógica).

Las clases de equivalencia se pueden definir de acuerdo a las siguientes directrices:

• Si una condición de entrada especifica un rango, se define una clase de equivalencia válida y dos no
válidas.

• Si la condición de entrada es un valor específico, se define una clase de equivalencia válida y dos no
válidas.

• Si la condición de entrada especifica un miembro de un conjunto, se define una clase de equivalencia

válida y otra no válida.

• Si la condición de entrada es lógica, se define una clase válida y otra no válida.

131
 Análisis y Diseño de Sistemas

8.2.2. Análisis de Valores Límite

La técnica de Análisis de Valores Límites selecciona casos de prueba que ejerciten los valores límite dada la
tendencia de la aglomeración de errores en los extremos. Complementa la de la partición equivalente. En lugar de
realizar la prueba con cualquier elemento de la partición 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 condición de entrada especifica un rango delimitado por los valores a y b, se deben diseñar
casos de prueba para los valores a y b y para los valores justo por debajo y justo por encima de ambos.

• Si la condición de entrada especifica un número de valores, se deben desarrollar casos de prueba que
ejerciten los valores máximo y mínimo además de los valores justo encima y debajo de aquéllos.

• Aplicar las directrices anteriores a las condiciones de salida. Componer casos de prueba que produzcan
salidas en sus valores máximo y mínimo.

• Si las estructuras de datos definidas internamente tienen límites prefijados (por ej., un array de 10
entradas), se debe asegurar diseñar un caso de prueba que ejercite la estructura de datos en sus límites.

8.2.3. Conclusiones

La aplicación de casos de pruebas apropiados es esencial para la validación y verificación del sistema
construido.

• Las pruebas normalmente deberían ocupar cerca del 40% del tiempo total de desarrollo de una
aplicación. Aún así, no puede asegurarse un 100% de fiabilidad para el sistema.

• En sistemas donde la fiabilidad y corrección del software es un aspecto crítico las pruebas deben ser
más exhaustivas. En estos casos pueden aplicarse también pruebas de comparación.

• Las herramientas que reducen los tiempos de prueba son muy valiosas. Se pueden distinguir varias
categorías de herramientas de prueba: analizadores estáticos, auditores de código, generadores de archivos de
prueba, generadores de datos de prueba y controladores de prueba.

8.3. Proceso de Prueba

La evaluación debe ser de todos los elementos del sistema; ya sean programas de aplicación recién 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 evaluación se debe llevar a cabo a lo largo del desarrollo del sistema para identificar aquellos problemas
desconocidos, no para demostrar la perfección 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 análisis, diseño y
programación. 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
 Análisis y Diseño de Sistemas

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 implantación del
diseño y la programación, 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 evaluación se realiza a diferentes niveles y a varios intervalos, aun antes de que el sistema entre en
operación, de todos los programas en cuanto a su diseño con datos de prueba y verificar si los módulos se enlazan entre
sí tal como fue planeado.

También debe probarse el sistema como una unidad, evaluando las interfaces entre los subsistemas, la
operación adecuada de la salida, la utilidad y comprensión de la documentación del sistema y de la salida. Los
programadores, analistas, operadores y usuarios juegan diferentes papeles en los diferentes aspectos de la evaluación del
software.

La evaluación del hardware comúnmente se proporciona como servicio de los vendedores de equipo, quienes
harán sus propias pruebas, cuando se instale el equipo.

8.3.1. Estrategias de prueba

Las dos estrategias de prueba más comunes se conocen como prueba ascendente y descendente. El enfoque
ascendente empieza por probar los módulos individuales pequeños separadamente; esto se conoce como prueba de
unidades, de módulos o de programas. Luego los módulos se combinan para formar unidades cada vez más 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 aceptación
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 módulos ejecutivos de alto nivel del sistema, pero que los de bajo nivel existen solo como módulos
vacíos. Dado a que muchas de las funciones detalladas no se han implementado, las pruebas iniciales son muy limitadas;
el propósito 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 evaluación recae en el autor original de cada programa. El analista
sólo sirve como orientador o coordinador para asegurar que se implanten las técnicas de evaluación adecuadas y será
poco probable que de manera personal participe en este nivel de evaluación.

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 válidos como no válidos para ver si las rutinas básicas funcionan y también
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 mínimos y máximos posibles, así como todas las variaciones en
formato y en los códigos. 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 modificación.

133
 Análisis y Diseño de Sistemas

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 pequeña 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 través del sistema. Puede ser muy difícil 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 típicos 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 inválidos 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 propósito de evaluar
los objetivos del sistema.

Factores a considerar:

• Verificar que los operadores cuentan con una documentación adecuada en los manuales de
procedimientos para asegurar una operación 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 evaluación del sistema. Comúnmente se suele obviar cuando la
instalación del sistema se encuentra fuera de programa, contra una fecha límite.

La evaluación del sistema incluye la confirmación de todos los estándares de calidad para el desempeño del
sistema, tal y como fueron establecidos cuando se definieron las especificaciones iniciales del sistema. Cada uno de los
involucrados deberá una vez más, estar de acuerdo con la forma de determinar si el sistema realiza los que
supuestamente debería 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 comprensión de los manuales de
procedimientos, etc.

8.3.1.3. Prueba del sistema completo con datos reales.

Es de gran utilidad que el sistema interactúe con datos reales, los cuales han sido procesados con éxito por el
sistema existente. Esto permite una comparación precisa con lo que es una salida procesada correctamente, y una buena
idea de cómo deben manejarse los datos reales. Como ocurre con los datos de prueba, sólo deben utilizarse una pequeña
cantidad de datos reales en este tipo de evaluaciones del sistema.

No es suficiente entrevistar al usuario acerca de cómo interaccionarán con el sistema; este es un importante
periodo para evaluar la manera en que los usuarios finales y operadores interactúan con el sistema.

Elementos a observar: facilidad de aprendizaje del sistema, ajuste de factores ergonómicos; las reacciones del
usuario a la realimentación, 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. También 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
 Análisis y Diseño de Sistemas

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 recuperación.

Asegura que el sistema puede recuperarse adecuadamente de diversos tipos de fallas. Son de vital
importancia en los sistemas reales de gran procesamiento de información. 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 desempeño.

Asegura que el sistema puede manejar el volumen de datos y transacciones de entrada especificados en
el modelo de implantación del usuario, además 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 línea, de
manera que se pueda simular la operación del sistema con una gran carga.

4. Prueba no exhaustiva.

Lo ideal es generar casos de prueba para cubrir cada entrada posible y cada combinación posible de
situaciones que el sistema pudiera enfrentar alguna vez. Luego se probaría 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 decisión que pueda tomar, o lo que es lo mismo, los casos deben seleccionarse cuidadosamente
para pasar por tantos caminos lógicos como sea posible. Esto hace que el modelo de requerimientos del
usuario y los diversos modelos de implantación 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:

• Propósito: cual es el objetivo de la prueba y que parte del sistema se esta probando.

• Localización 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 estándar de prueba:

• Recorridos y revisiones: es una forma de supervisión hecha por un grupo revisor de productos técnicos
(diagramas de flujo, diagramas de estructura, programas) para descubrir errores

• Inspecciones: son similares a los recorridos pero tienen un plan más formal de puntos a examinar en el
programa, la especificación o el diseño antes de que se pueda aprobar.

135
 Análisis y Diseño de Sistemas

• Pruebas de corrección: este tipo de prueba es altamente costoso porque consiste en desarrollar pruebas
rigurosas de la corrección de un programa. Solo se justifica realizar en sistemas de alto riesgo o
máxima seguridad.

136
 Análisis y Diseño de Sistemas

9. Implantación

9.1. Conversión

La conversión 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 conversión, se necesita un plan de conversión que debe desarrollarse al terminarse el modelo de
implantación, el cual debe cubrir los siguientes puntos:

• 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 difícil considerar los datos
existentes como estáticos.

• Pudiera haber un volumen tan grande de datos existentes que sea impráctico considerar convertirlo todo a
la vez. Los archivos y registros podrían tener que convertirse en forma incremental. Esto requiere de una
planeación y coordinación cuidadosa.

• La conversión debe llevarse a cabo de una manera automatizada; esto sólo se puede hacer si los archivos y
datos actuales existen en algún formato automatizado. De ser así, debiera ser fácil escribir un programa
para traducir los archivos actuales al formato requerido por el sistema nuevo. Sin embargo, es difícil esta
forma de conversión, 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 conversión es la detección y
corrección de errores, que puede volver el proceso aún más difícil y retardar el proceso.

• Además de convertir archivos existentes, puede ser necesario convertir programas y procedimientos
existentes.

9.2. Capacitación

La capacitación es la tarea final del equipo de desarrollo del sistema. Consiste en la preparación de los usuarios,
del personal de operaciones, los programadores de mantenimiento y varios niveles de administración. Se debe realizar
un plan de capacitación 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:

• Sería conveniente que a los manuales del usuario y guías de referencia se sumen clases y seminarios en
vivo, además de charlas de orientación para administradores y personas que necesiten estar al tanto del
sistema aunque no interactúen con él a diario. Para lo cual se cuenta con una serie de medios didácticos
modernos: VHS o DVD, enseñanza por computadora, e incluso versiones de simulacro del sistema real
para que el usuario pueda ingresar transacciones e interactuar con él. La capacitación podría 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 capacitación debe hacerse en un tiempo relativamente corto, y, próxima al uso del nuevo sistema. Se
deberá negociar con ellos un programa de actividades de capacitación.

137
 Análisis y Diseño de Sistemas

9.3. Instalación

La instalación es la actualización física del sistema de información existente en uno nuevo modificado. Se
requiere hacer lo siguiente:

• Preparar la sede de la computadora. Esto requiere construir o rentar un local de cómputo con la corriente,
espacio, iluminación y control ambiental adecuados.

• Preparación de la sede del usuario, sobre todo cuando el sistema es en línea y se requiere terminales e
impresoras en el área de trabajo del usuario.

• La instalación del hardware, cuando el sistema requiere su propia computadora, usualmente la efectúa el
proveedor cuando esta tarea es compleja.

• La instalación de software en las computadoras adecuadas y prepararlas para su operación.

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 instalación especialmente capacitados a cada sede de usuarios de acuerdo a un programa preestablecido. La
instalación no será inmediata, se hará gradualmente durante un período de tiempo.

Existen cinco enfoques de conversión de sistemas:

1. Conversión Total.

Significa que para una fecha específica 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 serán 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. Conversión Paralela.

Este se refiere al uso del sistema anterior y del nuevo al mismo tiempo. Sólo 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 simultáneamente es
alto y puede resultar agotador para los usuarios. La comparación puede ser difícil, a menos que el sistema
viejo sea manual. Los usuarios continuarán interesados en le sistema anterior por estar mas familiarizados
con mismo.

3. Conversión Gradual.

Intenta combinar las ventajas de los dos métodos anteriores. El número 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 implantación del nuevo sistema.

4. Conversión por Prototipos Modulares.

Considera la construcción de un prototipo modular operativo para el cambio gradual. Conforme se

modifica cada módulo y se acepta, se pone en operación. Este permite una prueba completa antes de
utilizarse.

Los usuarios se familiarizan con los módulos conforme éstos se vuelven operativos.

138
 Análisis y Diseño de Sistemas

5. Conversión Distribuida.

Este contempla muchas instalaciones del mismo sistema. La conversión se realiza en un solo sitio. Una
vez concluida con éxito, se realiza otra conversión en los otros sitios. Permite detectar problemas y
evitarlos en otros sitios.

Sin embargo, cada sitio tendrá sus propias peculiaridades.

139
 Análisis y Diseño de Sistemas

10. Mantención

Una analista al crear un sistema debe tener la visión de realizar un diseño comprensible y duradero que sirva
para las necesidades actuales y las proyectadas durante varios años. Parte de su experiencia debe encaminarse a
pronosticar cuáles necesidades llegarán a aparecer e incorporar cierta flexibilidad y adaptabilidad en el sistema. Cuánto
mejor sea el diseño del sistema, más fácil será darle mantenimiento y se requerirá menos dinero de la empresa para su
mantenimiento.

La reducción de los costos de mantenimiento es una preocupación importante de las empresas, ya que el
mantenimiento del software, por sí sólo, puede devorar hasta el 50 % del presupuesto total de procesamiento de datos.
En el mantenimiento se reflejarán costos excesivos de manera directa sobre el diseñador del sistema. Aproximadamente
el 70% de los errores de software se han atribuido a un diseño inadecuado. Desde una perspectiva de sistemas, tiene
sentido detectar y corregir los errores de diseño en el software, en su fase inicial, cuando aún es menos costoso dejar que
los errores permanezcan sin identificarse hasta realizar el mantenimiento.

El mantenimiento se realiza para mejorar un software existente, más que para responder a una crisis o falla de
sistema. Conforme cambian los requerimientos de los usuarios, el software y la documentación también deberían
cambiar, como parte del trabajo de mantenimiento. Además los programas podrían volverse a codificar para mejorar su
eficiencia sobre el programa original. Más de la mitad del mantenimiento se orienta a tales tareas de perfeccionamiento.

El mantenimiento también se realiza para actualizar el software en respuesta a los cambios de la organización.
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
retroalimentación 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 clasificación para
jerarquizar la importancia del mantenimiento requerido. Las peticiones clasificadas permitirán a los programadores del
mantenimiento comprender cómo 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 operación, los analistas dejan el proyecto. Algunos programadores se
quedan para el mantenimiento. Pero la mayoría de los analistas, diseñadores y programadores se transfieren a otros
nuevos proyectos.

Pero el trabajo realizado debe mantenerse durante loa 5, 10 o 20 años de vida operacional del sistema, tanto los
programas como las especificaciones.

A la hora de realizar modificaciones, a menudo resulta más fácil una corrección, mejoría o cambio “rápido y
sucio” al sistema existente, que empezar a cambiar el documento de los requerimientos y luego propagar dicho cambio
al documento de diseño y la implantación del mismo. Esto ocurre sobre todo cuando se necesita el cambio para arreglar
un problema inmediato y urgente. La documentación es lo último que se quiere hacer, y muchas veces no se hace.

Los sistemas de información tienden a ser complejos desde el principio, y se vuelven cada vez más complejos
al pasar los años de mantenimiento.

Sin un buen mantenimiento, cualquier sistema puede convertirse en un misterio. La única solución es mantener
documentación precisa y actualizada por la duración del sistema mismo.

10.1. Auditoria

La auditoria es otra forma de asegurar la calidad de la información que contiene el sistema. Con una definición
amplia, la auditoria involucra a un experto que no se encuentra involucrado en la puesta en operación y el uso del
sistema, para examinar la información, con el fin de examinar su relevancia. Si se encontrara o no información relevante,

140
 Análisis y Diseño de Sistemas

tal hallazgo deberá comunicarse a otros con el propósito de mejorar la relevancia de la información que les proporciona
el sistema.

Para los sistemas de información existen dos tipos: la interna y externa. La necesidad de ambas para el sistema
que se diseña dependerá del tipo de sistema.

Para las auditorias internas operan personal de la misma organización 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 operación 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. También intervienen cuando algo fuera de lo ordinario ocurre involucrando
a los empleados de la compañía.

141