ANALISIS Y DISEÑO II

Nombre Bernardo Lima Cardenas CI 10070606 lp RU 20047728

1. La introducción al capítulo 4 menciona mapas, globos terráqueos, diagramas de flujo de

datos, dibujos arquitectónicos y partituras musicales como ejemplos de modelos. Mencione
otros tres ejemplos de modelos usados comúnmente.
R.-
− lenguaje de modelado unificado (UML).
− estatuas: sirven de modelo o representación de una deidad suprema.
− diagrama de transición de estados.
− Modelos 3D de edificios.
2. ¿Qué definición da el diccionario de la palabra "modelo"? ¿Se puede aplicar a los
sistemas de información?
R.- Según el diccionario, la palabra modelo significa: Representación en pequeño de alguna
cosa. Esta definición se puede aplicar a sistemas de información ya que un modelo de
sistemas de información tiene como objetivo poner en funcionamiento componentes
informáticos que le permitan a la administración tributaria establecer flujos de trabajo e
información a través de las distintas áreas clave de la organización, involucrando todas las
labores operativas como parte del flujo de los procesos.
3. ¿Por qué se utilizan modelos en el desarrollo de los sistemas de información?
Mencione tres razones.
R.-
− Para facilitar la comunicación con los usuarios de manera precisa.
− Para permitir realizar cambios o mejoras de manera efectiva.
− Para resaltar las propiedades críticas del sistema y comprender su funcionamiento.
4. ¿Cómo respondería si el usuario le dijera que opina que los modelos son un
desperdicio de tiempo y que debería empezar a codificar?
R.- Le explicaría que su opinión está mal fundamentada ya que el modelado de datos aporta
ventajas significativas, como reducir errores en el desarrollo de software de bases de datos,
agilizar el diseño del sistema y crear coherencia en la documentación de los datos y el
diseño del sistema en toda la organización.
5. ¿Cree que la descripción verbal que un usuario dé acerca de los requerimientos
de su sistema deba considerarse como un modelo? ¿Por qué si o por qué no?
R.- Mi opinión sería que sí debe considerarse como un modelo en ciertos casos, como
cuando el usuario describe los aspectos funcionales y datos que el sistema debe manejar.
Sin embargo, si el usuario menciona aspectos de diseño o interfaz de usuario, eso podría no
considerarse un modelo, ya que está más relacionado con la codificación de estilos.

6. ¿Por qué sería útil tener más de un modelo para un sistema?

R.- Tener más de un modelo para un sistema es útil porque permite especificar diferentes
aspectos del sistema de manera más detallada y comprensible. Cuando uno no es suficiente,
podemos recurrir a otro modelo para aclarar ciertos aspectos o representar distintos puntos
de vista.
7. Todos los modelos que se discuten en el capítulo 4 son modelos en papel. ¿Se le ocurre
algún otro tipo de modelo?
R.- Sí, podría mencionar el modelo de prototipado interactivo en el cual se crean prototipos
funcionales del sistema que los usuarios pueden probar y evaluar.
8. La mayoría de los modelos que se discuten en el capítulo 4 son herramientas gráficas
(por ejemplo, imágenes) Cuáles cree que puedan ser las ventajas de útil zar imágenes como
herramientas de modelado?
R.- Las ventajas de utilizar imágenes como herramientas de modelado son que
proporcionan una representación visual más clara de los componentes y relaciones del
modelo, lo que facilita la comprensión tanto para los analistas como para los usuarios.
9. ¿Considera que las herramientas de modelado gráfico sean suficientes para representar
los requerimientos de un sistema de información? ¿Por qué sí o porque no?
R.- Sí, considero que las herramientas de modelado gráfico son suficientes para representar
los requerimientos de un sistema de información, ya que permiten representar de manera
visual y detallada los aspectos funcionales y estructurales del sistema.
10. ¿Quién debería ser el responsable de la creación de los modelos necesarios para
describir los requerimientos de un sistema de información?
R.- El encargado es la persona dedicada al análisis de sistemas
11. ¿Debería esperarse que los usuarios crearan sus propios modelos? ¿De ser así, en qué
circunstancias?
R.- Los usuarios podrían crear sus propios modelos en circunstancias donde tengan un
conocimiento profundo de sus necesidades y del sistema que desean. Esto podría ocurrir si
están familiarizados con las herramientas de modelado y desean que el modelo sea propio.
12. ¿Cuáles son los tres principales objetivos de un diagrama de flujo de datos?
R.-
 − Resolver un problema a nivel conceptual
− Ver las funciones para el sistema
− Planificar la labor que hará el sistema

13. ¿Cuáles son los cuatro principales componentes de un diagrama de flujo de datos?
R.-
− Entidad
− Proceso
− Almacén de datos
− Flujo de datos
14. Nótese que los procesos se representan por medio de círculos en un diagrama de flujo
de datos y los terminadores se representan con rectángulos. ¿Cree que esto sea
significativo? ¿Qué pasaría si los procesos se representaran?
R.- Si, es significativo ya que las figuras utilizadas para la representación de procesos son
más adaptables debido a que un proceso puede formar una relación entre varias entidades y
los terminadores ayudan a comprender el flujo de datos.
15. Nótese que la figura 4.2 muestra tres diferentes procesos, pero no indica cuántas
computadoras puedan estar trabajando en el sistema. ¿Cree que esto sea significativo? ¿Qué
cambios se requerirían si el equipo encargado del proyecto decidiera implantar el sistema
con una sola computadora? ¿Y con tres?
R.- Generalmente el número de computadoras que serán parte del flujo de datos es
irrelevante, ya que los diagramas de flujo de datos se centran en representar cómo fluyen
los datos y procesos en un sistema, sin preocuparse por la cantidad de dispositivos o
usuarios involucrados.
16. Nótese que la figura 4.2 muestra varios distintos diagramas de flujo de datos entre
procesos, pero no indica el medio físico que se usará para transportar los datos. ¿Cree que
esto sea significativo? ¿Qué puede ocurrir si los realizadores del sistema deciden
transportar datos entre procesos utilizando líneas de telecomunicación? ¿Qué pasa si
deciden transportarlos de un proceso a otro utilizando cinta magnética?
R.- No es significativo, debido a que los procesos representan acciones específicas que
pueden ser realizadas mediante cualquier medio de comunicación entre una entidad y
además que los diagramas de flujo de datos se centran en representar la lógica de los
procesos, la transferencia de datos y las funciones involucradas, sin entrar en detalles sobre
la tecnología o el medio de comunicación que se utilizará.
17. ¿Cuál es el propósito del diccionario de datos?
R.- El propósito del diccionario de datos es proveer información acerca de qué información
se transforma y cómo se transforma, de forma más específica en comparación al diagrama
de flujo de datos que proporciona una visión global de los componentes funcionales del
sistema.

18. ¿Quién debiera encargarse de creare diccionario de datos? ¿Quién debería ser
responsable de mantenerlo al día?
R.- La responsabilidad recae en el equipo de desarrollo de sistemas de una organización.
19. La figura 4.3 muestra la definición que da el diccionario de datos de un nombre. ¿Qué
cree que puedan significar los paréntesis, (), en dicha definición?
R.- los paréntesis hacen alusión a los caracteres especiales, numéricos y alfabéticos que se
son válidos en el campo de nombre o apellido.
20. ¿Cuál es el propósito de la especificación de procesos?
R.- Su propósito es proporcionar información detallada en un entorno real, acerca del cómo
funciona el flujo de datos y sus respectivas condiciones en distintos casos de uso.
21. ¿Cuántas especificaciones de proceso debería esperar ver en una especificación
completa de los requerimientos del usuario?
R.- Puede variar en función a la complejidad del proyecto, pero entre ellos se puede
encontrar al flujo de trabajo, secuencias de interacción, reglas de negocio y restricciones de
tiempo.
22. ¿Quién debería encargarse de la especificación de procesos? ¿Quién debería
actualizarla?
R.- Generalmente se encargará el equipo de gestión de procesos de una organización.
23. Nótese que la especificación de procesos mostrada en el ejemplo de este capítulo se
parece en algo a la codificación de programas. ¿Qué piensa de la idea de usar pseudocódigo
para escribir las especificaciones de procesos? ¿Qué piensa de la idea de utilizar un
verdadero lenguaje de programación (por ejemplo, Ada), como lo han Sugerido muchos,
para las especificaciones de programas? ¿Por qué estaría bien o mal usar un verdadero
lenguaje de programación?
R.- El uso de un lenguaje de programación en la especificación de procesos puede tener
aspectos positivos, como una mayor sinterización de lo que se quiere explicar. Así también
puede tener aspectos negativos, debido a que un lenguaje de programación requiere algunos
conocimientos más avanzados en sistemas, para comprender lo que se quiere decir,
mientras que la explicación mostrada en el ejemplo es más simple de comprender.
24. ¿Cuál es el propósito de un diagrama de entidad- relación?
R.- El propósito es ayudar en la representación y el diseño del modelo lógico de una base
de datos.
25. ¿Cuáles son los principales componentes de un diagrama de entidad-relación?
R.- los principales componentes son las entidades, relaciones, atributos y cardinalidad.

26. ¿Cuántos tipos de objetos se muestran en la figura 4?5?

R.- Se muestra varias figuras rectangulares "entidades" y se relacionan mediante figuras
rombo o diamante denominadas "relaciones" y líneas que conectan las relaciones con las
entidades
27. ¿Cuántas relaciones se muestran en la figura 4?5?
R.- se puede observar 3 relaciones
28. ¿Proporciona el diagrama de entidad-relación al lector alguna información sobre las
funciones que lleva a cabo el sistema?
R.- Sí, el diagrama de entidad-relación proporciona información sobre las funciones del
sistema al definir las cardinalidades, atributos en las entidades y nombrar las entidades y
relaciones específicas que se utilizan en el sistema.
29. Proporciona el diagrama de flujo de datos al lector alguna información acerca de los
tipos de objetos o sobre las relaciones entre tipos de objetos en el sistema?
R.- Aunque el diagrama de flujo de datos no es la herramienta principal para modelar tipos
de objetos y relaciones entre ellos, puede ofrecer pistas y contexto sobre la estructura y la
interacción de los objetos en el sistema.
30. ¿Dónde deberían describirse los detalles de tipos de objetos y relaciones que se
muestran en un diagrama de entidad-relación?
R.- En el diccionario de datos.
31. ¿Cuál es el propósito de un diagrama de transición de estados?
R.- Los detalles de los tipos de objetos y relaciones que se muestran en un diagrama de
entidad-relación deberían describirse en el diccionario de datos.
32. ¿Cuáles son los componentes de un diagrama de transición de estados?
R.- Los componentes de un diagrama de transición de estados incluyen estados,
transiciones, eventos, acciones e inicialización.
33. ¿Son útiles los diagramas de transición de estados para modelar sistemas
computacionales por lotes (batch)? ¿Por qué sí o por qué no?
R.- La utilidad de los diagramas de transición de estados para modelar sistemas batch
dependerá de la naturaleza y complejidad del sistema en cuestión. Pueden ser útiles para
representar estados y transiciones en sistemas batch.
34. ¿Cuál es el propósito de un diagrama de estructuras?
R.- El propósito de un diagrama de estructuras es proporcionar una representación visual de
la organización y la relación entre los elementos en un sistema o contexto específico.

35. ¿Cuáles son los componentes gráficos de un diagrama de estructuras?

R.- Los componentes gráficos de un diagrama de estructuras incluyen cajas o rectángulos
para representar elementos, conectores, flechas, símbolos, etiquetas, iconos y marcos que
ayudan a visualizar la estructura y las relaciones.
36. ¿Es de esperarse que el usuario sea capaz de leer y entender un diagrama de
estructuras? ¿Debería esperarse que el usuario sea capaz de crear uno?
R.- La capacidad de un usuario para leer y entender un diagrama de estructuras depende de
su nivel de familiaridad con el tipo específico de diagrama y su experiencia en la materia.
No se espera que los usuarios creen diagramas de estructuras, ya que generalmente es
responsabilidad de los analistas y diseñadores de sistemas.
37. Describa la relación existente entre un diagrama de entidad-relación y un diagrama de
fujo de datos.
R.- La relación entre un diagrama de entidad-relación y un diagrama de flujo de datos es
que, juntos, proporcionan una representación completa de un sistema de información.
38. ¿Existe alguna relación entre un diagrama de flujo de datos y un diagrama de
estructuras? De ser así, ¿cuál es?
R.- Los diagramas de flujo de datos y los diagramas de estructuras se relacionan en el
sentido de que proporcionan vistas complementarias de un sistema de información durante
el análisis y diseño. Los diagramas de flujo de datos se centran en el flujo de datos y
funciones, mientras que los diagramas de estructuras se enfocan en la organización de
elementos y relaciones en el sistema. Ambos tipos de diagramas ayudan a comprender y
documentar el sistema.