Analisis y Diseno de Sistemas

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

2

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


3

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.


4

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


5

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.


6

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."


7

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.


8

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.


9

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.


10

• 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.


11

• 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.


12

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


13

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.


14

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:


15

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.


16

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:


17

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.


18

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.


19

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.


20

• 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


21

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.


22

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


23

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


24

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.


25

• 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.


26

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).


27

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


28

� 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).


29

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:


30

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.).


31

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.


32

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.


33

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.


34

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


35

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.


36

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?


37

• ¿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.


38

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)


39

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


40

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:

( ) 01 )1

Ii

RVAN

n

jj

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.


41

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.


42

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:

( ) 0)1 0

1

=−

+= ∑

=

Ii

RTIR

n

jj

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


43

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.


44

• 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


45

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.


46

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.


47

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


48

• 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.


49

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"


50

Á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?


51

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.


52

• 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.


53

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.


54

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?


55

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


56

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.


57

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.


58

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.


59

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.


60

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.


61

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.


62

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.


63

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.


64

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.


65

• 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.


66

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.

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.

Raíz

Condición

Condición

Condición

Condición

Condición

Condición Acción

Acción

Acción

Acción


67

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:


68

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:


69

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


70

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


71

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.


72

• 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


73

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.


74

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.


75

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:


76

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:


77

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.


78

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.


79

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).


80

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.


81

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.


82

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.


83

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:


84

1. Entrada.

Número telefónico

Fig. 5.3.: Flujo de Entrada

2. Salida.

Itinerario 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

Generar Itinerario Conductor

Validar Número

Telefónico


85

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.


86

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.


87

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.


88

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.


89

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.


90

• 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


91

• 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


92

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).


93

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.


94

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?


95

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.


96

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:


97

= 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).


98

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.


99

• 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.


100

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.


101

• 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.


102

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.


103

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.


104

• 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.


105

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


106

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.”


107

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.


108

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.


109

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:


110

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.


111

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.


112

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.


113

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.


114

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.


115

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.


116

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


117

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


118

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.


119

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).


120

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.


121

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.


122

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.


123

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


124

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.


125

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

Dispositivo de Entrada

Pantalla

Archivo de Datos

Base de Datos

nombre

nombre nombre

nombre

nombre

nombre


126

Informe o Listado (Impresión)

Dispositivo de Respaldo

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.

nombre

nombre


127

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.


128

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.


129

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


130

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.


131

• 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.


132

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.


133

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.


134

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.


135

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.


136

• 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.


137

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.


138

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.


139

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.


140

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,


141

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.

Analisis y Diseno de Sistemas

Documents

Transcript of Analisis y Diseno de Sistemas