Instituto de Educación Superior Rosario Castellanos
Guía de Estudio
Análisis de las Estructuras de los Sistemas
Mtro. Roy Balderas Jiménez
1. Presentación de la guía
El propósito de esta guía es proveer de una herramienta esencial que le permita al
estudiante de la asignatura Análisis de las Estructuras de los Sistemas de la Licenciatura en
Tecnologías de Información y Comunicación de nuestro Instituto realizar una recapitulación
de los temas abordados a lo largo de la asignatura y programar su proceso de aprendizaje
para dimensionar en qué temas deberá poner atención para su examen final o
extraordinario. Además, encontrará ejercicios de práctica para cada tema de la asignatura.
Recomendamos que el estudiante conteste los ejercicios de práctica y que luego se
autoevalúe comparando sus respuestas con las respuestas correctas. Se espera que la
guía sea de gran utilidad en el proceso de preparación para realizar su examen final y/o
extraordinario.
2. Objetivos de la asignatura
Al finalizar la asignatura el alumno:
• Será capaz de aplicar las diferentes metodologías en la programación de software
tomando en cuenta el ciclo de vida de desarrollo de sistemas, valorando los recursos
que se pueden eficiente, realizando un correcto análisis de las necesidades.
• Aprenderá a identificar adecuadamente las etapas de ciclo de vida del desarrollo de
sistemas.
• Aprenderá a realizar adecuadamente el análisis de información.
• Será capaz de identificar, comprender y analizar para poder realizar adecuadamente las
metodologías de Jackson, Warnier y de Yourdan.
• Logrará comprender cómo realizar adecuadamente un análisis de sistemas de decisión
estructurada.
3. Revisión de temas
Unidad 1
Etapas de ciclo de vida del desarrollo de
sistemas.
Identificación de requerimientos.
Planeación.
Diseño del sistema lógico.
Pruebas.
Evaluación del usuario.
El ciclo de vida de desarrollo de sistemas1
Al proceso de desarrollo de sistemas también se le conoce como ciclo de vida de
desarrollo de sistemas (CVDS) porque las actividades asociadas con él son continuas. La
vida de un sistema de información continúa mientras éste se mantenga y sufra revisiones.
Si un sistema de información (SI) se vuelve obsoleto, necesita mejoras significativas (más
allá del ámbito del mantenimiento), necesita sustituirse debido a una nueva generación de
tecnología o si las necesidades de los SI de la organización cambian significativamente, se
iniciará un nuevo proyecto y el ciclo comenzará de nuevo.
Los SI que resuelven problemas estructurados, como son los sistemas de contabilidad, de
nómina y aplicaciones de soporte de la empresa, suelen concebirse, planearse,
desarrollarse y mantenerse dentro de esta estructura conocida como CVDS.
El CVDS es una metodología en fases para el análisis y diseño, de acuerdo con la cual los
sistemas se desarrollan mejor al utilizar un ciclo específico de actividades del analista y los
usuarios.
Aunque se asignan nombres diversos a las diferentes fases del CVDS y se organizan de
manera distinta, en términos generales, el proceso sigue los mismos pasos.
En esta guía de estudios vamos a dividir el ciclo en siete fases, como se muestra en la
figura. Cada fase se presenta de manera discreta, y en donde varias actividades pueden
ocurrir al mismo tiempo, e incluso se pueden repetir.
Identificación de los problemas, oportunidades y objetivos
En la primera fase del CVDS, el analista identifica los problemas, las oportunidades y los objetivos,
por ello esta etapa es imprescindible para el éxito del proyecto.
El objetivo es mejorar la ejecución de las labores que se llevan a cabo en la organización mediante el
uso de SI. Con ello la empresa podría obtener una ventaja competitiva o establecer un estándar en la
industria.
1
Kendall & Kendall. (2011). Análisis y diseño de sistemas. Ed. Pearson Education. 8va Ed., pp. 8-11.
La identificación de los objetivos también es un componente importante de la primera fase. El
analista primero descubre qué hace la empresa y después determina si alguno de los aspectos de las
aplicaciones de los sistemas de información puede ayudar a que la empresa logre sus objetivos al
enfrentar problemas u oportunidades específicos.
Las personas involucradas en la primera fase son usuarios, analistas y administradores de sistemas
que coordinan el proyecto. En esta fase las actividades consisten en entrevistar a los encargados de
la administración de los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto
y documentar resultados y el resultado es un informe de viabilidad, que contiene la definición de un
problema y sintetiza los objetivos.
Determinación de los requerimientos de información del factor humano
Esta fase involucra determinar las necesidades de los usuarios, mediante el uso de herramientas,
para comprender la forma en que interactúan en el contexto laboral con sus sistemas de información
actuales.
El analista utiliza métodos interactivos como entrevistas, muestreos, investigación de datos duros,
cuestionarios y los métodos discretos, como la observación del comportamiento de los responsables
de tomar las decisiones y sus entornos de oficina, y métodos integrales como la creación de
prototipos.
En esta fase el analista busca comprender qué información requieren los usuarios para realizar su
trabajo y examina cómo hacer que el sistema sea útil para las personas involucradas. Para ello debe
conocer los detalles sobre las funciones del sistema actual y al terminar esta fase deberá comprender
la forma en que los usuarios realizan su trabajo al interactuar con una computadora y saber cómo
funciona la empresa recolectando la información completa sobre personas, objetivos, datos y
procedimientos involucrados.
Análisis de las necesidades del sistema
Para esta fase el analista aprovecha el uso de herramientas y técnicas especiales que le ayudan a
determinar los requerimientos. Herramientas como los diagramas de flujo de datos (DFD) para
representar la entrada, los procesos y la salida de las funciones de la empresa que sirven para
ilustrar a los sistemas de una manera estructurada y gráfica.
A partir del uso de diversos tipos de diagramas se desarrolla un diccionario de datos para listar
todos los elementos de datos utilizados en el sistema, así como sus especificaciones.
En esta fase se analizan las decisiones estructuradas llevadas a cabo. Las decisiones
estructuradas son aquellas para las que se pueden determinar condiciones, alternativas de condición,
acciones y reglas de acción. Para el análisis de las decisiones estructuradas: se utiliza el lenguaje
estructurado, tablas de decisión y árboles de decisión.
En este punto del CVDS, el analista prepara una propuesta de sistemas en la que sintetiza todo lo
investigado sobre las necesidades de los usuarios, la capacidad de uso y la utilidad de los sistemas
actuales; incluye un análisis de costo-beneficio de las alternativas y hace recomendaciones.
Diseño del sistema recomendado
En esta fase el analista de sistemas utiliza la información recolectada previamente para realizar el
diseño lógico del sistema de información, diseña los procedimientos para ayudar a que los usuarios
introduzcan los datos con precisión, de manera que los datos que ingresen al sistema de información
sean los correctos. El analista debe ayudar a que los usuarios completen la entrada de datos efectiva
al sistema de información mediante el uso de las técnicas del buen diseño de formularios y páginas
Web o pantallas.
La interfaz del usuario se diseña con ayuda de los usuarios para asegurar que el sistema sea
perceptible, legible y seguro, así como atractivo y fácil de usar. Esta fase incluye el diseño de bases
de datos que almacenarán los datos necesarios para los encargados de tomar las decisiones en la
organización, así como controles y procedimientos de respaldo para proteger el sistema y los datos, y
producir paquetes de especificación de programas para los programadores.
Cada paquete debe contener el diseño de entradas y las salidas del sistema, especificaciones de
archivos y detalles sobre su procesamiento; pueden incluirse árboles o tablas de decisión, diagramas
UML y de flujo de datos. En esta fase, el analista trabaja con los usuarios para diseñar una salida que
cumpla con sus necesidades de información.
Desarrollo y documentación del software
En esta fase del CVDS, el analista trabaja con los programadores para desarrollar el software
requerido y desarrolla junto con los usuarios una documentación efectiva para el software. La
documentación indica a los usuarios cómo deben usar el software y qué deben hacer en caso de que
ocurran problemas. Los programadores desempeñan un rol clave en esta fase, ya que diseñan,
codifican y eliminan los errores sintácticos de los programas de computadora.
Prueba y mantenimiento del sistema
Antes de utilizar el sistema de información, se debe probar. Es mucho menos costoso detectar los
problemas antes de entregar el sistema a los usuarios. Una parte del procedimiento de prueba es
llevado a cabo por los programadores; la otra la realizan los programadores junto con los analistas de
sistemas. Se completa una serie de pruebas para señalar los problemas con datos de muestra y
después se utilizan datos reales del sistema actual.
Los planes de prueba se crean en las primeras etapas del CVDS y se depuran a medida que el
proyecto progresa. El mantenimiento del sistema y la documentación de este mantenimiento
empieza en esta fase y se lleva a cabo de manera rutinaria durante toda la vida del sistema de
información. Gran parte del trabajo cotidiano del programador consiste en el mantenimiento, y por
ello las empresas invierten una gran cantidad de recursos en este proceso.
Implementación y evaluación del sistema
En esta última fase el analista ayuda a implementar el sistema de información. En esta fase los
usuarios se capacitan para operar el sistema y la supervisión de dicha capacitación es
responsabilidad del analista de sistemas. Además, el analista necesita planear una conversión sin
problemas del sistema antiguo al nuevo. Este proceso incluye convertir los archivos de los formatos
anteriores a los nuevos, o crear una base de datos, instalar equipo y llevar el nuevo sistema a
producción.
Preguntas para autoevaluación Unidad 1:
1. Constituye la primera etapa en el ciclo de vida de los sistemas e involucra a los
usuarios, los analistas y los administradores de sistemas que coordinan el proyecto.
a. Análisis de las necesidades del sistema
b. Identificación de problemas, oportunidades y objetivos
c. Determinación de los requerimientos de información
d. Pruebas y mantenimiento del sistema
2. Durante esta etapa del ciclo de vida de los sistemas, el analista de sistemas analiza las
decisiones estructuradas llevadas a cabo. Utiliza herramientas como los diagramas de
flujo de datos (DFD) para graficar la entrada, los procesos y la salida de las funciones de
la empresa, o los diagramas de actividad o de secuencia para mostrar la secuencia de
los eventos. Todas estas herramientas le sirven para ilustrar a los sistemas de una
manera estructurada y gráfica.
a. Análisis de las necesidades del sistema
b. Identificación de problemas, oportunidades y objetivos
c. Determinación de los requerimientos de información
d. Pruebas y mantenimiento del sistema
3. Durante esta etapa del ciclo de vida de los sistemas el analista trabaja con los
programadores para desarrollar el software requerido por la organización. El analista
desarrolla junto con los usuarios una documentación efectiva para el software, pero Los
programadores desempeñan un rol clave en esta fase.
a. Análisis de las necesidades del sistema
b. Desarrollo y documentación del software
c. Determinación de los requerimientos de información
d. Pruebas y mantenimiento del sistema
4. Es la última etapa del desarrollo de sistemas. En esta etapa hay que capacitar a los
usuarios para operar el sistema y la supervisión de la capacitación es responsabilidad
del analista de sistemas. Además, el analista necesita planear una conversión sin
problemas del sistema antiguo al nuevo.
a. Análisis de las necesidades del sistema
b. Implementación y evaluación del sistema
c. Determinación de los requerimientos de información
d. Pruebas y mantenimiento del sistema
5. Esta etapa se lleva a cabo de manera rutinaria durante toda la vida del sistema de
información. Gran parte del trabajo rutinario del programador consiste en el realizar esta
fase, por lo cual las empresas invierten una gran cantidad de dinero en este proceso.
a. Análisis de las necesidades del sistema
b. Implementación y evaluación del sistema
c. Determinación de los requerimientos de información
d. Pruebas y mantenimiento del sistema
Bibliografía sugerida Unidad 1
1. Con la finalidad de conocer el ciclo de vida del desarrollo de sistemas los invito a revisar el
capítulo 12 del siguiente material:
Stair, R., Reynolds. (2010). Principios de sistemas de información. Cengage Learning. Págs. 496501. Disponible en:
https://www.academia.edu/22302493/Principios_de_Sistemas_de_Informacion_Un_Enfoque_Administrativo
2. Con la finalidad de estudiar metodologías alternativas para el desarrollo de sistemas es
recomendable consultar el capítulo 13.3 del siguiente material:
Laudon, K. C. (2012). Sistemas de información gerencial. Pearson Education. Págs 506-511.
Disponible en:
https://juanantonioleonlopez.files.wordpress.com/2017/08/sistemas-de-informacic3b3n-gerencial-12vaedicic3b3n-kenneth-c-laudon.pdf
3. Con el objetivo de comprender que es un sistema de información, así como los ciclos de los
sistemas de información les recomiendo consultar los subcapítulos 1.2 y 1.2 del siguiente
material.
Díaz Domínguez, L. F. (2013). Sistemas de información en la empresa. Universidad de Alcalá. Págs.
16-23
4. Con la finalidad de conocer los factores que afectan el éxito en el desarrollo de sistemas los
invito a revisar la parte 4 del capítulo 12 del siguiente material:
Stair, R., Reynolds. (2010). Principios de sistemas de información. Cengage Learning. Págs. 503507. Disponible en:
https://www.academia.edu/22302493/Principios_de_Sistemas_de_Informacion_Un_Enfoque_Administrativo
5. Con el objetivo de responder a la pregunta ¿Por qué debemos comprender los principios del
desarrollo de sistemas? sugiero consultar el siguiente material:
Sousa, K. J. y Oz, E. (2015). Administración de los sistemas de información. Cengage Learning.
Páginas 388-401. Disponible en:
https://www.academia.edu/28968219/Administracion_de_los_sistemas_de_informacion_Effy_Oz_5ta_Ed
Unidad 2
Análisis de información
Lenguaje estructurado.
Árboles de decisión.
Diagramas de flujo.
Análisis de información
Para determinar las necesidades de información asociadas con la creación de una estrategia de
análisis de decisiones, el analista de sistemas debe determinar los objetivos de los usuarios junto
con los objetivos de la organización, mediante el uso de una metodología. En esta parte de esta
guía de estudio hablaremos de una metodología conocida como arriba-abajo.
La metodología arriba-abajo es imprescindible, ya que todas las decisiones humanas en la
organización deben estar relacionadas, al menos en forma indirecta, con los objetivos generales de
toda la organización.
Las especificaciones de los procesos se crean para procesos primitivos en un diagrama de flujo
datos, así como para algunos procesos de nivel más alto que se expanden en un diagrama hijo.
Estas especificaciones explican la lógica de la toma de decisiones y las fórmulas que transformarán
la entrada del proceso en su salida.
Los tres objetivos al producir especificaciones de procesos son:
1. Reducir la ambigüedad del proceso.
2. Obtener una descripción precisa de lo que se va a lograr.
3. Validar el sistema de diseño. Lo que incluye asegurar que la descripción de un proceso contenga
todo el flujo de datos de entrada necesario para producir la salida. Todas las entradas y salidas se
deben representar en el diagrama de flujo de datos (DFD).
Lenguaje estructurado
Un lenguaje estructurado tiene una sintaxis, una semántica y una pragmática y su objetivo es
comunicar en forma no verbal, a los diferentes actores involucrados (personas, maquinas,
programadores, etc.), instrucciones orientadas a determinar acciones e interacción entre ellos.
Cuando la lógica del proceso involucra fórmulas o iteraciones, o cuando las decisiones estructuradas
no son complejas, una técnica para analizar el proceso de decisión es el uso del lenguaje
estructurado.
Como su nombre indica, el español estructurado se basa por una parte en la lógica estructurada, o
las instrucciones organizadas en procedimientos anidados y agrupados, y por otra parte en las
instrucciones en lenguaje natural simple tales como sumar, multiplicar y mover.
Un problema escrito se puede transformar en lenguaje estructurado si ponemos las reglas de
decisión en su secuencia apropiada y usamos la convención de las instrucciones IF-THEN-ELSE a lo
largo del proceso.
Cómo escribir lenguaje estructurado
Para escribir español estructurado es conveniente utilizar las siguientes convenciones:
1. Expresar toda la lógica en términos de uno de estos cuatro tipos: estructuras secuenciales,
estructuras de decisión, estructuras de casos o iteraciones.
2. Usar y poner en mayúsculas las palabras clave aceptadas como 𝐼𝐹, 𝑇𝐻𝐸𝑁, 𝐸𝐿𝑆𝐸, 𝐷𝑂,
𝐷𝑂 𝑊𝐻𝐼𝐿𝐸, 𝐷𝑂 𝑈𝑁𝑇𝐼𝐿 y 𝑃𝐸𝑅𝐹𝑂𝑅𝑀.
3. Aplicar sangría a los bloques de instrucciones para mostrar con claridad su jerarquía
(anidamiento).
4. Cuando haya palabras o frases definidas en un diccionario de datos subrayar esas palabras
o frases para indicar que tienen un significado especializado y reservado.
5. Tener cuidado al usar “𝑦” y “𝑜”, y evite la confusión al diferenciar entre “𝑚𝑎𝑦𝑜𝑟 𝑞𝑢𝑒” y
“𝑚𝑒𝑛𝑜𝑟 𝑜 𝑖𝑔𝑢𝑎𝑙 𝑞𝑢𝑒” y con las relaciones de igualdad. “𝐴 𝑦 𝐵” significa 𝑡𝑎𝑛𝑡𝑜 𝐴 𝑐𝑜𝑚𝑜 𝐵; “𝐴” o
“𝐵” significa que puede ser 𝐴 o 𝐵, pero no ambas. Aclarar las instrucciones lógicas sin
esperar hasta la etapa de codificación del programa.
El siguiente ejemplo muestra cómo se transforma un procedimiento hablado para procesar
reclamaciones médicas en lenguaje estructurado.
Tablas de decisión
Una tabla de decisión es una tabla de filas y columnas, separada en cuatro cuadrantes, como se
muestra en la siguiente figura.
El cuadrante superior izquierdo contiene la(s) condición(es); el cuadrante superior derecho contiene
las alternativas de condiciones. La mitad inferior de la tabla contiene las acciones a realizar a la
izquierda y las reglas para ejecutar las acciones a la derecha.
Cuando se utiliza una tabla de decisión para determinar la acción a realizar, la lógica se mueve en
sentido de las manecillas del reloj, partiendo desde el cuadrante superior izquierdo.
El argumento más importante para usar la tabla de decisión es el conjunto de reglas para cada una
de las acciones. Las reglas son las combinaciones de las alternativas de condiciones que precipitan
una acción.
Para ilustrar la creación de tablas de decisión supongamos que una tienda desea ilustrar su política
sobre compras que no son en efectivo. La empresa podría hacerlo mediante el uso de una tabla de
decisión simple, como la que se muestra en la siguiente figura.
Cada una de las tres condiciones (venta menor de $50, paga con cheque y usa tarjetas de crédito)
sólo tiene dos alternativas. Las dos alternativas son Y (sí, es verdadero) o N (no, no es verdadero).
Adicionalmente es posible realizar cuatro acciones que se describen apropiadamente en la tabla de
decisiones, es decir:
1.
2.
3.
4.
Completar la venta después de verificar la firma.
Completar la venta. No se necesita firma.
Llamar al supervisor para la aprobación.
Comunicarse vía electrónica con el banco para la autorización de la tarjeta de crédito.
Árboles de decisión
Los árboles de decisión se utilizan cuando ocurren ramificaciones complejas en un proceso de
decisión estructurado. Los árboles también son útiles cuando es imprescindible mantener una cadena
de decisiones en una secuencia específica. Aunque el nombre “árbol de decisión” se deriva de los
árboles naturales, por lo general los árboles de decisión se dibujan de lado, con la raíz en el lado
izquierdo del papel; a partir de ahí el árbol se ramifica hacia la derecha.
Esta orientación permite al analista escribir en las ramas para describir las condiciones y acciones.
En el análisis de sistemas, los árboles se utilizan principalmente para identificar y organizar las
condiciones y acciones en un proceso de decisión completamente estructurado.
La siguiente figura muestra cómo se puede dibujar el ejemplo usado en la sección sobre tablas de
decisión de esta misma unidad como un árbol de decisión.
Al dibujar el árbol hay que:
1. Identificar todas las condiciones y acciones, junto con su orden y sincronización (si son
críticas).
2. Empezar a construir el árbol de izquierda a derecha; hay que asegurarnos de enlistar todas
las alternativas posibles antes de avanzar a la derecha.
El árbol simple es simétrico y las cuatro acciones al final son únicas, aunque un árbol no tiene que
ser simétrico. La mayoría de los árboles de decisión tienen condiciones con un número distinto de
ramificaciones. Además, pueden aparecer acciones idénticas más de una vez.
El árbol de decisión tiene tres ventajas principales sobre una tabla de decisión. En primer lugar,
aprovecha la estructura secuencial de sus ramas, por lo que se puede observar de inmediato el
orden de verificación de las condiciones y ejecución de las acciones.
En segundo lugar, podemos encontrar condiciones y acciones de los árboles de decisión en algunas
ramas, pero no en otras, lo cual contrasta con las tablas de decisión, donde todas forman parte de la
misma tabla.
Esas condiciones y acciones que son críticas se conectan de manera directa con otras condiciones y
acciones, mientras que las condiciones que no importan están ausentes. En otras palabras, el árbol
no tiene que ser simétrico.
En tercer lugar, en comparación con las tablas de decisión, otras personas en la organización pueden
comprender con más facilidad los árboles de decisión. En consecuencia, son más apropiados como
herramienta de comunicación.
Algunas de las ventajas de utilizar árboles de decisión son:
• Facilita la interpretación de la decisión adoptada.
• Facilita la comprensión del conocimiento utilizado en la toma de decisiones.
• Explica el comportamiento respecto a una determinada decisión.
• Reduce el número de variables independientes
La terminología asociada a la técnica de los árboles de decisión recurre a una terminología
específica, que resulta importante clarificar:
Nodo de decisión
Nodo que indica que una decisión necesita tomarse en ese punto del proceso. Está representado por
un cuadrado.
Nodo de probabilidad
Nodo que indica que en ese punto del proceso ocurre un evento aleatorio. Probabilidades de que
ocurran los eventos posibles como resultado de las decisiones. Está representado por un círculo.
Nodo terminal
Nodo en el que todos los casos tienen el mismo valor para la variable dependiente. Es un nodo
homogéneo que no requiere ninguna división adicional, ya que es “puro”.
Rama
Nos muestra los distintos caminos que se pueden emprender cuando tomamos una decisión o bien
ocurre algún evento aleatorio. Resultados de las posibles interacciones entre las alternativas de
decisión y los eventos
Metodología del flujo de datos
Para que los analistas de sistemas puedan comprender y comunicar los requerimientos de
información de los usuarios, deben ser capaces de conceptualizar la forma en que los datos se
mueven a través de la organización, los procesos o la transformación por la que pasan los datos y las
salidas de estos.
Una descripción gráfica puede ilustrar esta información para los usuarios y analistas de una manera
útil. Por medio de una técnica de análisis estructurado conocida como diagramas de flujo de datos
(DFD), el analista de sistemas puede construir una representación gráfica de los procesos de datos a
través de la organización.
Usando combinaciones de sólo cuatro símbolos, el analista puede crear una descripción ilustrada de
los procesos con el fin de elaborar una documentación sólida para el sistema.
Ventajas de la metodología del flujo de datos
La metodología del flujo de datos tiene cuatro ventajas importantes en comparación con las
explicaciones narrativas sobre la forma en que se mueven los datos a través del sistema:
1. No hay que comprometerse demasiado pronto con la implementación técnica del sistema.
2. Permite comprender con más detalle la capacidad de interrelación de los sistemas y
subsistemas.
3. Se puede comunicar el conocimiento del sistema actual a los usuarios por medio de diagramas
de flujo de datos.
4. Se puede analizar un sistema propuesto para determinar si se han definido los datos y procesos
necesarios.
Se utilizan cuatro símbolos básicos para graficar el movimiento de los datos en los DFD: un
cuadrado doble, una flecha, un rectángulo con esquinas redondas y un rectángulo con un extremo
abierto, como se muestra en la figura. Podemos describir en forma gráfica todo un sistema y
numerosos subsistemas al combinar estos cuatro símbolos.
El cuadrado doble se utiliza para describir una entidad externa (otro departamento, una empresa,
una persona o una máquina) que pueda enviar/recibir datos hacia/desde el sistema. La entidad
externa, o simplemente entidad, también se conoce como origen o destino de los datos, y se
considera externa al sistema que se está describiendo.
Cada entidad se identifica con un nombre apropiado. Aunque interactúa con el sistema, se considera
fuera de los límites de éste. Se debe denominar a las entidades con un sustantivo. Se puede utilizar
la misma entidad más de una vez en un diagrama de flujo de datos para evitar cruzar las líneas de
flujo de datos.
La flecha muestra el movimiento de los datos de un punto a otro; la cabeza de la flecha apunta
hacia el destino de los datos. Los flujos de datos que ocurren al mismo tiempo se pueden describir
mediante el uso de flechas paralelas. Como una flecha representa datos sobre una persona, lugar o
cosa, también se debe describir con un sustantivo.
Se utiliza un rectángulo con esquinas redondas para mostrar la ocurrencia de un proceso de
transformación. Los procesos siempre expresan un cambio o transformación en los datos; por ende,
el flujo de datos que sale de un proceso siempre se identifica de manera distinta al flujo que entra al
proceso.
Los procesos representan el trabajo que se realiza en el sistema y se deben denominar mediante el
uso de uno de los siguientes formatos. Un nombre claro facilita la acción de entender lo que el
proceso lleva a cabo. Un proceso también debe recibir un número de identificación único que
indique su nivel en el diagrama. Puede haber varios flujos de datos que entren y salgan de cada
proceso.
El último símbolo básico que se utiliza en los diagramas de flujo de datos es un rectángulo con un
extremo abierto, el cual representa a un almacén de datos. El rectángulo se dibuja con dos líneas
paralelas que se cierran mediante una línea corta del lado izquierdo y cuyo extremo derecho está
abierto. Estos símbolos se dibujan con la anchura suficiente como para permitir una leyenda de
identificación entre las líneas paralelas.
En los diagramas de flujo de datos lógicos no se especifica el tipo de almacenamiento físico. En este
punto, el símbolo del almacén de datos muestra sólo un depósito de datos que permite examinar,
agregar y recuperar los datos. Como los almacenes de datos representan a una persona, lugar o
cosa, se denominan con un sustantivo.
Cómo desarrollar diagramas de flujo de datos mediante una metodología
arriba-abajo
1. Hacer una lista de las actividades de la empresa y usarla para determinar los siguientes
elementos:
• Entidades externas
• Flujos de datos
• Procesos
• Almacenes de datos
2. Crear un diagrama de contexto que muestre las entidades externas y los flujos de datos que
entran y salen del sistema. No debe mostrar procesos detallados ni almacenes de datos.
3. Dibujar el Diagrama 0, el siguiente nivel. Puede mostrar los procesos, pero debe mantenerlos en
un nivel general. En este nivel puede mostrar los almacenes de datos.
4. Crear un diagrama hijo para cada uno de los procesos en el Diagrama 0.
5. Verificar los errores y asegurarse de que las etiquetas que asigne a cada proceso y flujo de datos
sean significativas.
6. Desarrollar un diagrama de flujo de datos físico a partir del diagrama de flujo de datos lógico.
Establecer la diferencia entre los procesos manuales y los automatizados, describir los archivos e
informes actuales por nombre y agregar controles para indicar cuando se completen los procesos
o se produzcan errores.
7. Particionar el diagrama de flujo de datos físico mediante la separación o agrupación de partes del
diagrama para facilitar la programación y la implementación.
Las tareas anteriores deben tomar en cuenta las siguientes reglas básicas a seguir:
1. El diagrama de flujo de datos debe tener por lo menos un proceso y no debe haber objetos
independientes o conectados a sí mismos.
2. Un proceso debe recibir por lo menos un flujo de datos entrante y debe crear por lo menos un
flujo de datos saliente.
3. Un almacén de datos debe estar conectado con por lo menos un proceso.
4. Las entidades externas no se deben conectar entre sí. Aunque se comunican en forma
independiente, esa comunicación no forma parte del sistema que diseñamos mediante el uso de
DFD.
Bibliografía sugerida Unidad 2
1. Con el objetivo de conocer herramientas de modelado para el análisis estructurado de
sistemas y responder a la pregunta ¿para qué utiliza las herramientas de modelado un
analista de sistemas? les sugiero consultar el capítulo 4 del siguiente material de referencia:
Yourdon, E. (1993). Análisis Estructurado Moderno. Prentice-Hall. Páginas 73-83. Disponible en:
http://www.mediafire.com/file/h65vjirs7d2j1kk/YOURDON%252C_E__An%25C3%25A1lisis_y_Dise%25C3%25B1o_Estructurado_Moderno_-_Espa%25C3%25B1ol.pdf
2. Con el objetivo de comprender la importancia del modelado de datos en el análisis de
sistemas les recomiendo revisar el tema "Modelado de datos" contenido en capítulo 12 del
siguiente material de referencia:
Stair, R., Reynolds. (2010). Principios de sistemas de información. Cengage Learning. Págs. 516519. Disponible en:
https://www.academia.edu/22302493/Principios_de_Sistemas_de_Informacion_Un_Enfoque_Administrativo
3. Con la finalidad de estudiar el uso de diagramas de flujo en el proceso de análisis de sistemas y
responder a la pregunta ¿cómo desarrollo diagramas de flujos de datos para el análisis de
sistemas? les recomiendo consultar el capítulo 7 del siguiente material de referencia:
Kendall, K. E., y Kendall, Julie E. (2011). Análisis y diseño de sistemas. Pearson Educación. Páginas
195-205. Disponible en:
https://www.academia.edu/7102592/Analisis_y_Diseno_de_Sistemas_8ed_Kendall_PDF
4. Con el objetivo ilustrar la creación de un diagrama de flujo de datos para un caso real les
recomiendo revisar el ejemplo disponible el capítulo 7 del siguiente material de referencia:
Kendall, K. E., y Kendall, Julie E. (2011). Análisis y diseño de sistemas. Pearson Educación. Páginas
207-217. Disponible en:
https://www.academia.edu/7102592/Analisis_y_Diseno_de_Sistemas_8ed_Kendall_PDF
5. Con el objetivo de comprender la importancia del uso de Diagramas de Flujo de Datos
(DFD) lógicos y físicos para describir gráficamente el comportamiento de los datos les sugiero
revisar el siguiente material de referencia:
Kendall, K. E., y Kendall, Julie E. (2011). Análisis y diseño de sistemas. Pearson Educación. Páginas
193-195. Disponible en:
https://www.academia.edu/7102592/Analisis_y_Diseno_de_Sistemas_8ed_Kendall_PDF
Preguntas para autoevaluación Unidad 2:
1.
Es una herramienta útil para el análisis de decisiones y para describir la lógica de
procesos en un sistema de información.
a. Árboles de decisión
b. Diagramas de flujo
c. Diccionario de datos
d. Árboles de búsqueda
2. Es una herramienta útil para representar los procesos componentes de un sistema y el
flujo de datos entre ellos. Es un modelo gráfico lógico del flujo de la información, que
particiona un sistema en módulos que muestran niveles de detalle manejables.
Especifica de manera rigurosa los procesos o transformaciones que ocurren dentro de
cada módulo y las interfaces que existen entre ellos.
a. Árboles de decisión
b. Diagramas de flujo
c. Diccionario de datos
d. Diagrama de flujo de datos
3. Esta herramienta es útil para el análisis de decisiones. Sus elementos fundamentales son
los nodos y las ramificaciones. Es apropiado para representar acciones que se deben
llevar a cabo en cierta secuencia.
a. Árboles de decisión
b. Diagramas de flujo
c. Diccionario de datos
d. Árboles de búsqueda
4. Este lenguaje se emplea mayormente las fases de modelado del desarrollo de sistemas
de información. Permite expresar diferentes tipos de información, conocimientos o
sistemas en forma de una estructura que es definida por un conjunto consistente de
reglas. Es útil para la gestión de información y el modelado de procesos.
a. Lenguaje de sistemas.
b. Lenguaje orientado a funciones.
c. Lenguaje estructurado.
d. Lenguaje interpretado.
5. Este lenguaje nos permite expresar toda la lógica de un sistema en términos de:
estructuras secuenciales, estructuras de decisión, estructuras de casos o iteraciones.
a. Lenguaje ensamblador.
b. Lenguaje orientado a funciones.
c. Lenguaje estructurado.
d. Lenguaje interpretado.
Unidad 3
Metodologías
Metodología de Jackson.
Metodología de Warnier.
Metodología de Yourdon.
Metodologías para el desarrollo de sistemas
Entre las metodologías para el desarrollo de sistemas más utilizadas está la de
Yourdon, la cual se basa en los siguientes conceptos:
•
Usa la organización jerarquizada descendente, por medio de la descomposición
funcional para definir los requerimientos del sistema.
•
Aprovecha herramientas gráficas de comunicación y documentación.
Metodología de diseño estructurado de Yourdon
Esta metodología proporciona una manera para diseñar paso a paso sistemas y
programas detallados. Cabe mencionar que unos pasos involucran el análisis, otros
el desarrollo del diseño y otros la medición y mejora de la calidad del diseño.
La principal herramienta generada en el diseño estructurado es el diagrama de
estructura en donde se muestran los componentes de los procedimientos que
componen a los programas, su ordenación jerárquica y los datos conectados a ellos.
Un diagrama de estructura es un diagrama de árbol (jerárquico) que en términos
generales define la arquitectura global de un programa que muestra sus
procedimientos e interrelaciones. En este diagrama se utilizan bloques básicos,
cajas que representan los componentes de procedimientos y flechas que muestran
cómo se conectan.
Yourdon en su metodología propone 4 pasos para el proceso de diseño:
1.
2.
3.
4.
Construir el diagrama de flujo de datos.
Construir el diagrama de estructura.
Evaluación del diseño.
Preparación del diseño para su implantación.
De acuerdo con Yourdon es aconsejable examinar un sistema bajo los tres puntos
de vista clásicos (dimensiones), es decir las dimensiones funcional, de
información y temporal (lista de eventos), por ello propone tres perspectivas para
analizar un sistema:
• Función. ¿Qué hace el sistema?
•
•
Información. ¿Qué información utiliza el sistema?
Tiempo. ¿Cuándo sucede algo en el sistema?
En la figura se muestran los cuatro pasos básicos para el proceso de diseño de
Yourdon
Metodología de Jackson
El modelo Jackson fue generado gracias al análisis que realizó M. A. Jackson sobre el
campo de la información y la relación que esta tiene con el diseño de sistemas.
De acuerdo con el modelo de Jackson el desarrollo de toda aplicación o sistema inicia
con la generación de un modelo de la vida real relacionada con el ya mencionado
sistema.
Este modelo hace referencia al método de programación estructurada, utilizando la
técnica de diseño descendente (Top-Down), en donde el programa escrito en
pseudocódigo se utiliza en nuestra aplicación final, una vez obtenido este producto es
posible utilizar cualquier lenguaje de programación para su codificación.
En el proceso del diseño de una aplicación es necesario tener en cuenta ciertas
especificaciones proporcionadas por el usuario, las cuales se definen a continuación:
•
La naturaleza y sus funciones para realizar.
•
La naturaleza y sus datos por manejar.
•
El producto final podrá ser codificado con el fin de resolver o satisfacer las
necesidades del usuario.
Para generar este modelo es necesario seguir siguientes pasos:
• Entidad – Acción: se identifican claramente las entidades y las acciones que éstas
generan.
•
Estructura de entidad: se ordenan las acciones que afecta a las entidades
correspondientes.
•
Modelo inicial: creamos un modelo de procesamiento donde observemos
claramente las entidades y las acciones.
•
Funciones: especificamos todas las funciones respectivas a sus acciones.
•
Temporalización del sistema: establecemos y especificamos la planificación del
proceso.
•
Implementación: especificamos los elementos a utilizar haciendo referencia a
hardware y software.
Metodología de Warnier
Este modelo ayuda al diseño de las estructuras de los sistemas identificando la salida y
el resultado de un determinado procedimiento, y entonces trabaja hacia atrás para
determinar los pasos y combinaciones de entrada necesarios para producir dichos
resultados.
Esta metodología aprovecha elementos gráficos simples y los integra en los llamados
diagramas de Warnier/Orr cuyo objetivo es hacer evidentes los niveles en un sistema y
más claros los movimientos de los datos en dichos niveles.
Consideraciones que debemos tomar en cuenta en el proceso de diseño:
1. Evaluar las características de la estructura de datos.
Representar los datos en términos de sus formas elementales, es decir tomando en
cuenta que existen cuatro maneras de organizar a los enunciados o líneas de un
algoritmo: secuencial, iterativa, condicional o recursiva.
2. Transformar la representación de la estructura de datos en una jerarquía de control
para el software.
3. Refinar la jerarquía del software utilizando los criterios definidos como parte de un
método.
4. Finalmente, desarrollar la descripción procedimental del software.
Los diagramas de Warnier-Orr no son tan ilustrativos visualmente como los diagramas
que aprovechan las metodologías de Yourdon y Jackson ya que en este tipo de
diagramas las llaves son los únicos símbolos utilizados, junto con otras anotaciones
adicionales.
La característica principal de la metodología de Warnier-Orr es que es un diseño
controlado por los datos, i.e. que las estructuras de control están dadas por las
estructuras que almacenan datos.
Además, el diseño parte siempre desde el estado final del problema (lo que queremos
obtener) y va definiendo pequeños pasos que van transformando los datos hacia el
estado inicial del problema (lo que sabemos antes de empezar a ejecutar el proceso).
Los diagramas de Warnier-Orr (diagramas W-O) muestran los procesos y la secuencia
en que se realizan. Son diagramas jerárquicos cuyo propósito es describir tanto la
organización de los datos como de procedimientos.
Sobre la notación que utiliza el método de Warnier-Orr, y dado que es un método
dirigido por los datos, veamos que la notación para representar grupos de datos, al
igual que los enunciados, tienen las mismas 4 formas de organizarse: secuencial,
iterativa, condicional o recursiva.
También debemos denotar la jerarquía de la información, donde este concepto se
refiere a la relación que guarda la información entre sí. Representa a los datos con una
notación muy parecida a la de teoría de conjuntos, utilizando llaves para denotar a los
conjuntos de datos (o enunciados).
Sin embargo, cada conjunto puede ser “refinado” con una “ampliación” de su
descripción, que se encuentra siempre a la derecha de la llave. Otro aspecto muy
importante es que en el caso de los “conjuntos” de Warnier-Orr el orden es muy
importante.
Un ejemplo de la manera en que el método de Warnier-Orr representa el concepto de
jerarquía se observa a continuación:
Abre llaves. El “nombre” de la llave es el objeto de mayor jerarquía e identifica al
subconjunto de datos que se encuentran a la derecha de la llave.
Decimos entonces que lo que se encuentra a la derecha de la llave “refina” (explica con
mayor detalle) al “nombre” de la llave. Veamos que en la figura “nombre” agrupa a
𝑑𝑒𝑠𝑐𝑟1 , 𝑑𝑒𝑠𝑐𝑟1 ,. . . , 𝑑𝑒𝑠𝑐𝑟𝑛 . Y decimos entonces que las descripciones son un
refinamiento de “𝑛𝑜𝑚𝑏𝑟𝑒”, y que “𝑛𝑜𝑚𝑏𝑟𝑒” es de mayor jerarquía que las descripciones.
Preguntas para autoevaluación Unidad 3:
1. Los pasos a seguir en esta metodología para realización de programas son:
• Definir los datos de entrada y salida (resultados).
• Crear la estructura del programa a partir de las diferentes estructuras de los datos.
• Utilizar los recursos que posee el método para conseguir los resultados.
• Y escribir el pseudocódigo y codificar
a. Metodología de Jackson.
b. Metodología de Warnier.
c. Metodología de Yourdon.
d. Metodología estándar.
2. Para el diseño de __________, son necesarias las siguientes especificaciones
proporcionadas por el usuario:
-Las funciones a realizar y su naturaleza.
-Los datos a manejar y su naturaleza.
a.
b.
c.
d.
Un programa o un conjunto de programas
Una metodología
Un proceso
Una secuencia
3. La característica principal de esta metodología es que se trata de un diseño controlado
por los datos. Es decir que las estructuras de control están dadas por las estructuras
que guardan los datos. El diseño de programas usando esta metodología parte siempre
desde el estado final del problema (que es lo que queremos obtener) y va definiendo
pequeños pasos que van transformando a los datos hacia el estado inicial del problema
(que es lo que sabemos antes de ejecutar el proceso).
a. Metodología de Jackson.
b. Metodología de Warnier.
c. Metodología de Yourdon.
d. Metodología estándar.
4. Esta metodología proporciona una manera de diseñar paso a paso sistemas y
programas detallados. Se compone de los siguientes cuatro pasos:
•
•
•
•
Elaboración del diagrama de flujo de datos.
Elaboración del diagrama de estructura.
Evaluación del diseño.
Preparación del diseño para la implantación.
a.
b.
c.
d.
Metodología de Jackson.
Metodología de Warnier.
Metodología de Yourdon.
Metodología estándar.
5. Este tipo de diagramas muestran los procesos y secuencias en las que se realizan dichos
procesos. Cada proceso se define de una manera jerárquica que consiste en conjuntos de
subprocesos, que lo definen. Para elaborar este diagrama el analista trabaja hacia atrás,
usando un análisis orientado de salida. La secuencia de trabajar hacia atrás asegura que el
sistema será orientado a resultados. Este diagrama es útil tanto para los datos como para la
definición del proceso.
a.
b.
c.
d.
Diagrama de flujo de datos
Árboles de decisión
Diagrama de Warnier
Diagrama de flujo de procesos
Bibliografía sugerida Unidad 3
1. Con el objetivo de comprender la interrelación entre el ciclo de vida del desarrollo de
sistemas y las metodologías de análisis y diseño les recomiendo leer el capítulo 11 del
siguiente material de referencia:
Briano, J. C. V. (2011). Sistemas de información gerencial: Tecnología para agregar valor a las
Organizaciones. Prentice Hall. Páginas 218-230. Disponible en:
https://www.academia.edu/40150860/Sistemas_de_Informaci%C3%B3n_Gerencial_Juan_Carlos_V_Briano_LIB
ROSVIRTUAL
2. Con la finalidad de estudiar distintas metodologías de análisis y diseño estructurado los
invito a leer los subcapítulos 12.1 y 12.2 del siguiente material de referencia:
Briano, J. C. V. (2011). Sistemas de información gerencial: Tecnología para agregar valor a las
Organizaciones. Prentice Hall. Páginas 232-241. Disponible en:
https://www.academia.edu/40150860/Sistemas_de_Informaci%C3%B3n_Gerencial_Juan_Carlos_V_Briano_LIB
ROSVIRTUAL
3. Con la finalidad Con la finalidad de elaborar de forma correcta un diagrama de flujo de datos
(DFD) les recomiendo revisar el ejemplo disponible en el subcapítulo 12.4.1 del siguiente material
de referencia. En este mismo subcapítulo podrán revisar ejemplos de uso de otras herramientas
de diagramación disponibles para el análisis estructurado de sistemas; Entidad-Relación (DER),
transición de estados (DTE), casos de uso, de actividades y de secuencia:
Briano, J. C. V. (2011). Sistemas de información gerencial: Tecnología para agregar valor a las
Organizaciones. Prentice Hall. Páginas 242-255. Disponible en:
https://www.academia.edu/40150860/Sistemas_de_Informaci%C3%B3n_Gerencial_Juan_Carlos_V_Briano_LIB
ROSVIRTUAL
4. Como parte del estudio de las metodologías de análisis estructurado y con el objetivo de
desarrollar los diagramas DFD solicitados en esta unidad les recomiendo consultar el siguiente
vídeo:
José Miguel Castillo. (2017, marzo 18). Los diagramas DFD [video].
https://www.youtube.com/watch?v=b6d1cMbyHmM&list=PLEQna3YgqUXUmOzpQOpiMHjtbMqfVUXW&index=8
Unidad 4
Análisis de sistemas de decisión estructurada
Concepto
Componentes
Datos
Análisis de flujo
Análisis de decisiones estructuradas
Durante la revisión de los temas de la Unidad 2 en esta misma guía estudiamos tres
técnicas de análisis de decisiones estructuradas: lenguaje estructurado, tablas de decisión y
árboles de decisión. Aunque no es necesario utilizarlas en forma exclusiva, es costumbre
elegir una técnica de análisis para una decisión en vez de emplear las tres de forma
combinada. Los siguientes lineamientos nos permitirán elegir una de las tres técnicas para
un caso en específico.
1. Usar lenguaje estructurado cuando (a) haya muchas acciones repetitivas, o bien cuando
(b) la comunicación con los usuarios finales sea importante.
2. Usar tablas de decisión cuando (a) existan combinaciones complejas de condiciones,
acciones y reglas, o bien cuando (b) se requiera un método que evite de manera
efectiva las situaciones imposibles, redundancias y contradicciones.
3. Use los árboles de decisión cuando (a) la secuencia de condiciones y acciones sea
crítica, o bien cuando (b) no todas las condiciones sean relevantes para todas las
acciones (cuando las ramificaciones sean distintas).
Las tablas de decisión son una importante herramienta en el análisis de las decisiones
estructuradas. Una ventaja importante de usar tablas de decisión en comparación con
otros métodos es que las tablas ayudan al analista a asegurar la integridad.
Al usar tablas de decisión también se facilita la acción de verificar posibles errores, como las
situaciones imposibles, contradicciones y redundancia. También existen los procesadores
de tablas de decisión, que reciben la tabla como entrada y proveen código de programa de
computadora como salida.
“El diagrama de flujo de datos es una de las herramientas comúnmente usadas, sobre todo
por sistemas operacionales en los cuales las funciones del sistema son de gran importancia
y son más complejas que los datos que se están manejando”.
Como vimos en la revisión de los temas de la unidad 2 con ayuda de los DFD podemos
analizar y resolver problemas por medio de elementos gráficos, con estos podemos
representar algoritmos para generar alguna aplicación dentro de un sistema. Los DFD se
construyen con figuras geométricas, interaccionando entre ellas por medio de flechas.
Como es común comenzamos con el elemento inicio, partiendo de eso surgen las demás
funciones indicadas por distintas figuras dentro del diagrama de flujo, toda esta información
nos representa el tipo de procedimiento a realizar.
Es importante mencionar algunas características relevantes de los diagramas de flujo de
datos:
• Muestran que debe hacer el sistema sin referencias.
• Son diagramas explícitos y comprensibles.
• Proporcionan la posibilidad de representar el sistema a diferentes niveles de
complejidad, desde lo general a lo específico.
• Se mantienen fácilmente, pues los cambios afectan solo algunos de sus elementos y no
al todo.
Es necesario identificar las ventajas y limitaciones asociadas con los DFD:
• Facilitan la lectura de algoritmos.
• Facilitan la interacción usuario-analista.
• No permite acumular el comportamiento del sistema, por lo que se vuelve necesaria la
utilización de diagramas de transición de estados.
• No permite las relaciones entre los datos que se almacenan.
• No puede expresar contextos en los que se debe dejar en claro la necesidad de dos o
más flujos.
• No permite recoger contenido de los flujos y mucho menos el de los archivos.
Modelado a partir del diagrama entidad-relación
“El modelado de datos entidad-relación (ER) está basado en una percepción del mundo real
consistente en objetos básicos llamados entidades y de relaciones entre estos objetos”.
Este modelado fue desarrollado para dar llevar a cabo el diseño de bases de datos y
permite describir esquemáticamente la estructura lógica completa de las bases de datos.
El modelo E-R es muy importante en la actualidad ya que nos permite describir entidades y
sus relaciones con un esquema conceptual. Este modelo está compuesto por:
Entidades: es todo aquello capaz de ser definido y de todo lo que está constituido.
Atributos: son características de una entidad que pueden: identificar, relacionar y describir.
Relaciones: describen interacciones entre distintos elementos de la base de datos.
Llaves: identifican de manera única a una entidad o registro.
Diagrama de transición de estados
Dentro de los sistemas en tiempo real, cuando es necesario describir el comportamiento
correcto del sistema utilizamos una herramienta conocida como modelado para la
descripción del sistema.
Los diagramas de transición de estados (DTE) se encuentran estrechamente
relacionados con los diagramas de flujo de datos, y los podemos utilizar para desarrollar un
modelo principal del sistema, estableciendo en ellos algún comportamiento deseado.
Es importante identificar los componentes de los DTE:
1. Estados: son los comportamientos del sistema y pueden estar representados en un
periodo finito.
2. Cambios de estados: se conocen tanto en inicial y final. Son representados con
flechas.
3. Condiciones: describen un suceso externo en donde el sistema es capaz de
detectar la señal de interrupción con la cual podemos propiciar el cambio de
estados.
4. Acciones: describen cambios de estado en el sistema, realizan actividades como
producir una salida o llevar a cabo un cálculo, estas son respuestas que regresan al
ambiente externo para actuar en el futuro.
Para construir un DTE es necesario identificar los estados, inicial y final, condiciones y
acciones de estos. Para llevar a cabo este proceso es necesario tomar en cuenta las
siguientes reglas para verificar la consistencia:
1. Definir todos los estados.
2. Conocer si podemos alcanzar todos los estados.
3. Identificar si en cada uno de los estados el sistema responde adecuadamente a
todas las condiciones posibles.
Diccionario de datos
El diccionario de datos está formado por un conjunto de metadatos, las cuales tienen
diferentes características propias de los datos que son lógicas y puntuales. Describen el
funcionamiento de estas características, las cuales deben incluir nombre, descripción,
alias del contenido y la organización.
El diccionario identifica los procesos donde son utilizados los datos y los sitios en donde
se necesita el acceso rápido a la información que se requiera. Este es un complemento
del flujo de datos que se encuentra en algún sistema, ya que en el encontramos un
listado de todos los elementos que integran esa parte.
Como sabemos el flujo de datos está compuesto por dos elementos principales:
almacén de datos y procesos, en donde el diccionario de datos guarda los
complementos y describe todos estos elementos.
Para construir de manera correcta nuestros elementos del diccionario de datos es
necesario tener en cuenta únicamente los datos significativos en donde no hay ninguna
desintegración, como ejemplo podemos tomar la descomposición del nombre de un
usuario en: nombre, apellido, etc., siendo que esto depende del contexto del sistema
que se necesita.
Una vez identificados los datos se implantan en el diccionario. Para esto es necesario
especificar las características que estos datos pueden contener, como pudiera ser la
unidad de medida, notación, etcétera.
Ejemplo:
Dirección= Calle – Colonia – Numero de casa
Calle = {carácter}
Colonia = {carácter}
Numero de casa = {entero}
Bibliografía sugerida Unidad 4
1. Con el objetivo de estudiar la clasificación propuesta para los diferentes sistemas
de información y su relación con las metodologías de desarrollo de sistemas les
sugiero revisar el siguiente material de referencia:
Kendall, K. E., y Kendall, Julie E. (2011). Análisis y diseño de sistemas. Pearson Educación.
Capítulo 1. Disponible en:
https://www.academia.edu/7102592/Analisis_y_Diseno_de_Sistemas_8ed_Kendall_PDF
2. Con el objetivo de responder a la pregunta ¿Qué son los sistemas para soporte de
decisiones (DSS)? sugiero consultar el siguiente material:
Sousa, K. J. y Oz, E. (2015). Administración de los sistemas de información. Cengage
Learning. Pág. 54. Disponible en:
https://www.academia.edu/28968219/Administracion_de_los_sistemas_de_informacion_Effy_Oz_5ta
_Ed
3. Con la finalidad de comprender el propósito de las especificaciones de los
procesos y reconocer la diferencia entre las decisiones estructuradas y las
semiestructuradas sugiero revisar el siguiente material de referencia:
Kendall, K. E., y Kendall, Julie E. (2011). Análisis y diseño de sistemas. Pearson Educación.
Páginas 259-264. Disponible en:
https://www.academia.edu/7102592/Analisis_y_Diseno_de_Sistemas_8ed_Kendall_PDF
4. Como parte del estudio del proceso de análisis de sistemas y con la finalidad de
utilizar correctamente herramientas que faciliten dicho proceso (diccionario de
datos y especificaciones de proceso) recomiendo consultar el siguiente material de
referencia:
Kendall, K. E., y Kendall, Julie E. (2011). Análisis y diseño de sistemas. Pearson Educación.
Capítulo 9. Páginas 265-266. Disponible en:
https://www.academia.edu/7102592/Analisis_y_Diseno_de_Sistemas_8ed_Kendall_PDF
5. Con la finalidad de responder a la pregunta ¿cómo elegir una técnica de análisis de
decisiones estructuradas? sugiero revisar el siguiente material de referencia:
Kendall, K. E., y Kendall, Julie E. (2011). Análisis y diseño de sistemas. Pearson Educación.
Pág. 273. Disponible en:
https://www.academia.edu/7102592/Analisis_y_Diseno_de_Sistemas_8ed_Kendall_PDF