Donar $20 Donar $50 Donar $100 Donar mensualmente
 


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
[Diseño de Sistemas][Pedido] Final: parte teórica
Autor Mensaje
Angie Sin conexión
Empleado del buffet
Sin estado :(
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1
Agradecimientos dados: 0
Agradecimientos: 0 en 0 posts
Registro en: Jul 2008
Mensaje: #1
[Diseño de Sistemas][Pedido] Final: parte teórica Finales Diseño de Sistemas
Hola!

Alguien esta preparando diseño para esta fecha?
Mas abajo dejo un listado de las preguntas teóricas que encontré que tomaron entre el 2006 y 2007, si les parece vamos respondiendolas...

¿Encontraron algo de material sobre: modelo de ambientes y modelo de peters ? Hay muchas preguntas sobre estos dos temas relacionándolos con rup, pero no puedo encontrar nada de ellos (sólo el cubo del modelo de peters) ni en apuntes de la materia ni en internet.

Gracias!!!

----------------------------------------
Teoría:
Spoiler: Mostrar
Requerimientos
V/F
El proceso de Ingeniería de Requerimientos está incluido en el proceso de diseño de sistemas y software.
Los requerimientos funcionales se obtienen mediante el proceso de ingeniería de requerimientos.
El proceso de ingeniería de requerimientos está incluido en el análisis del sistema.
Los requerimientos funcionales se definen sin entrevistar a los usuarios.
Los requerimientos funcionales se obtienen mediante entrevistas con usuarios.
La ingeniería de requerimientos incluye actividades de validación y gestión.
Los artefactos del RUP se usan en la ingeniería de requerimientos.
Desarrollar
• Cómo se especifican los requerimientos.

Heurísticas
V/F
La forma de mezquita se obtiene minimizando el fan in y maximizando el fan out.
La forma de mezquita se obtiene maximizando el fan out.
La forma de mezquita en una carta estructurada se obtiene minimizando el fan out.
La forma de mezquita se obtiene minimizando el fan in.
El alto y ancho de una carta estructura no son heurísticas de diseño.
Las heurísticas permiten identificar si los requerimientos relevados se contemplan en el alcance definido.
Cuando se llama a ejecutar un módulo de cohesión secuencial ejecutan todos sus componentes internos.
Cuando se llama a ejecutar un módulo de cohesión secuencial ejecutan sólo alguno de sus componentes internos.
Cuando se llama a ejecutar un módulo de cohesión funcional ejecutan todos sus componentes internos.
Cuando se llama a ejecutar un módulo de cohesión lógica ejecutan todos sus componentes internos.
El acoplamiento entre dos módulos influye en la cohesión de los mismos.
Fan-out es el número de módulos que llaman a un módulo.
Desarrollar
• Explique la heurística forma de mezquita. Ejemplifique.
• De un ejemplo de utilización de la heurística de forma de mezquita de un grupo de módulos.
• Enumere heurísticas de diseño estructurado.
• De un ejemplo de utilización de la heurística de maximizar fan in.
• Explique módulo, carta estructurada, heurística y relación entre DFD y Diagrama de estructura.
• Enumere niveles de cohesión y acoplamiento.

Modelo de Peters
V/F
El eje temporal del modelo de Peters corresponde a Roles de RUP.
El eje temporal del modelo de Peters corresponde a actividades de RUP.
El eje formal del modelo de Peters corresponde a Roles de RUP.
El eje formal del modelo de Peters corresponde a artefactos de RUP.
El eje formal de modelo de Peters corresponde a Fases de RUP.
El eje mental del modelo de Peters puede asimilarse a roles del RUP.
El eje mental del modelo de Peters puede asimilarse a actividades del RUP.
El eje mental del modelo de Peters se relaciona con el tipo de sistema del modelo de ambientes.
Los artefactos del RUP se corresponden con el eje formal de Peters.
Los artefactos del RUP se corresponden con el eje temporal del Peters.
Los artefactos del RUP se usan solo en la actividad de análisis y diseño.
Los roles del RUP se relacionan con el eje mental de Peters.
Los roles del RUP se corresponden con el de tecnología en modelo de ambientes.
El modelo de ambientes no se relaciona con el modelo de Peters.
El eje tipo de problema del modelo de ambientes corresponde a Roles.
Desarrollar
• Observando el modelo de Peters en qué eje puede estar incluido el Rol de Gerente de proyecto.

Tiempo real – Red de Petri
V/F
J2EE es un entrono propicio para desarrollar STR.
STR debe ser desarrollado en un entorno que permita un control preciso de la duración de la respuesta a estímulos.
Los sensores modifican el entorno del sistema.
Los STR monitorean y controlan su entorno operativo.
UML incluye notaciones para modelos de máquinas de estado.
En el desarrollo de STR es frecuente la utilización de lenguajes de bajo nivel por razones de performance.
La red de Petri es útil para mostrar el flujo de datos de información (vínculo con punta de flecha) y de control (vínculo con punta de rombo) entre procesos de control y sus almacenamientos.
La red de Petri es útil para vincular almacenamientos de un DFD RT.
La red de Petri es útil para tener trazabilidad de los mensajes con los objetos de un STR desarrollado en objetos usando UML.
Los sistemas de tiempo real poseen arquitectura de repositorio.
En el DFD de tiempo real siempre aparece un flujo de datos continuo.
Los sistemas de tiempo real son una metodología.
Los casos de uso no se utilizan para modelar sistemas de tiempo real.
Las tareas de tiempo real se comunican solamente por mensajes.
Cualquier lenguaje permite programar en tiempo real.
El DFD y la carta estructurada no se aplican para sistemas de tiempo real.
No hay una metodología específica para diseñar sistemas de tiempo real.
Desarrollar
• Enumere y ejemplifique flujos contínuos, discretos y de control en STR.
• Ejemplificar una Red de Petri que incluya sincronismo y exclusión mutua.

Interfases – Documentación - Ayuda
V/F
El proceso de diseño de interfases de usuario solo se aplica para sistemas orientados a objeto.
La ayuda en línea es una característica de las interfases visuales.
El diseño de interfaces de usuario tiene en cuenta la experiencia del usuario.
El diseño de interfases webapp están centrados en el usuario.
El diseño de interfases de aplicaciones web no siempre se centra en el usuario.
La documentación operativa facilita la tarea del personal de sistemas.
El help online de un sistema facilita la tarea del personal de sistemas.
La mejor documentación siempre esta impresa en papel.
La documentación de un sistema no incluye información de noermas y procedimientos.
La documentación operativa facilita la tarea del usuario.
La documentación operativa facilita la tarea del personal de sistemas.
Desarrollar
• Enumere características de interfases visuales.
• Con qué tema de Diseño se corresponden estos conceptos:
- Tiempo de respuesta.
- Facilidades de ayuda.
- Manejo de Error.
- Etiquetado de menú y comando.
- Accesibilidad a la aplicación.
- Internacionalización.

Arquitectura
V/F
Los sistemas centralizados poseen arquietectura de cliente-servidor.
Los sistemas centralizados poseen arquitectura de repositorio.
Los sistemas distribuidos poseen arquitectura de cliente-servidor.
Desarrollar
• Enumere las ventajas de la arquitectura de repositorio.
• Explique arquitectura cliente/servidor, ventajas y desventajas de la misma, con un ejemplo de aplicación.
• Enumere arquitecturas de software y ventajas y desventajas de las mismas.
• Describa el rol de arquitecto de software, en qué actividades participa y enumerar que artefactos y modelos utiliza y produce.


Sincronismo
V/F
Un estímulo puede ser periódico y aperiódico al mismo tiempo.
El flujo de control es siempre sincrónico.
El flujo de datos puede ser sincrónico y asincrónico al mismo tiempo.
Un estímulo puede ser sincrónico y asincrónico al mismo tiempo.
Un estímulo puede ser sincrónico o asincrónico, nunca ambos.

RUP
V/F
Las actividades de RUP siguen un modelo en espiral.
Los artefactos del RUP son guías para documentar.
El proceso unificado de desarrollo de software incluye actores y artefactos.
UML y RUP son métodos para diseño de software.
Desarrollar
• Enumere tres artefactos y vincúlelos con actividades de RUP.
• Los roles que plantea el Proceso Unificado, explicando brevemente alguno de ellos.
• Enumere los artefactos que plantea utilizar el Proceso Unificado explicando brevemente alguno de ellos indicando en que actividad son producidos.
• Explique el modelo de UP.
• Explique diferencia entre actividad y fase en el UP y que modelos UML se utilizan en cada una.


UML
V/F
Los modelos de UML se documentan sólo con herramientas CASE.
Cada escenario debe tener un correlato con un diagrama de secuencia.
Cada caso de uso está representado con una clase del diagrama de clase.
La relación extends de los casos de uso se traduce en una multiplicidad 1 a n en el diagrama de clases.
Todos los casos de uso deben tener, por lo menos, un escenario principal.
UML incluye notaciones para modelso de máquinas de estado.
Los escenarios secundarios deben tener diagramas de secuencia asociados.
Diagrama de objetos es útil para mostrar el flujo de datos de información entre las clases del sistema.
No pueden vincularse varios actores con un mismo caso de uso.
Si nadie en una organización lee los manuales para que perder tiempo en la documentación de los sistemas y no aprovecharlo en temas mas fructíferos para la organización.
Si se ha realizado la especificación de procesos en el DFD, no es necesario realizar la Carta Estructurada debido a que se puede realizar la programación del sistema directamente de la misma.
El diagrama de actividades de UML es el mas adecuado para modelar un sistema de tiempo real.
Un manual de normas y procedimientos de una organización esta desarrollado y mantenido por el área de sistemas.
Desarrollar
Un sensor y un actuador son elementos de UML.
Si no cuento con la presencia permanente del usuario, entonces me conviene utilizar XP, como modelo de desarrollo de software de un sistema.

Varios
V/F
Un DFD puede utilizarse en el diseño de un sistema orientado a objetos.
Un diagrama de casos de uso puede usarse con la metodología estructurada.
La funcionalidad de un DFD es mayor que en un diagrama de casos de uso, para el mismo sistema en desarrollo.
La línea de vida en un diagrama de secuencia es el tiempo en que el objeto esta inactivo.
Es lo mismo una relación de extensión que de inclusión.
Primero se deben encontrar los casos de uso y luego los actores.
Siempre existen escenarios alternativos en un caso de uso.
El modelo de casos de uso no debe utilizarse en sistemas estructurados.
Los DFD pueden usarse para modelar colaboraciones de objetos.
Los módulos siempre se factorizan en otros dos de menor nivel.
La pirámide de diseño de una aplicación web comienza por el diseño de componentes.
Desarrollar
• De un ejemplo normalizado en tercera forma normal de un archivo de alumno de la carrera de ingeniería en sistemas considerando datos personales, cursadas, parciales, finales y asistencia de cada materia.
• Ejemplifique una estructura en tercera formal normal.
• Describa atributos en una aplicación web.
• Enumerar objetivos del diseño de aplicaciones web.
----------------------------------------
Otros adjuntos en este tema
.jpg  peters.JPG ( 37,1 KB / 1336) por Adriano
.rar  ResumenDiseño.rar ( 256,86 KB / 226) por Dandurff
24-07-2008 18:03
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
focaembalsamada Sin conexión
Empleado del buffet
Sin estado :(
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1
Agradecimientos dados: 0
Agradecimientos: 0 en 0 posts
Registro en: Jul 2008
Mensaje: #2
Re: Diseño de sistemas - Final: parte teórica
Hola, rendiste el sabado pasado? Si es asi, tenes el final para pasarmelo?
Gracias!
30-07-2008 13:45
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
pablo Sin conexión
ModdIng
Hombre de ingenio (?)
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1.646
Agradecimientos dados: 0
Agradecimientos: 7 en 7 posts
Registro en: Apr 2008
Mensaje: #3
Re: Diseño de sistemas - Final: parte teórica
Yo tampoco conseguí casi nada... salvo el foro de LeaTex que me pasó en el thread que creé preguntando sobre el final.

Pero hay muchos temas que no sé de donde sacarlos, porque en la cursada me los dieron muuuy por arriba o no me los dieron U.u.

Mi idea serìa rendirlo este sàb pero no sè de donde prepararlo bien Confused...

Cuando llegue a casa me pongo a responder segin mi criterio y lo que me acuerdo, pero si alguien tiene una mejor referencia, bàrbaro!

Saludos!
30-07-2008 14:04
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
LeaTex Sin conexión
Presidente del CEIT
.
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 4.852
Agradecimientos dados: 55
Agradecimientos: 195 en 50 posts
Registro en: Apr 2008
BlogSpot Facebook Google+ Last.fm LinkedIn Twitter
YouTube
Mensaje: #4
Re: Diseño de sistemas - Final: parte teórica
El problema es que el Modelo de Peters no lo dan en la cursada (salvo Quiroga) y después lo toman como loco. Creo que en el grupo que les pasé algo subimos. Por ahí también creo que hay un archivo de Word con un montón de V/F para que practiquen.

30-07-2008 14:11
Visita su sitio web Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Adriano Sin conexión
Presidente del CEIT
sonaiNTU arap anoD
**********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 6.677
Agradecimientos dados: 235
Agradecimientos: 718 en 242 posts
Registro en: Jul 2008
Facebook Twitter
Mensaje: #5
Re: Diseño de sistemas - Final: parte teórica
Modelo de Peters
• Eje Temporal: refleja todas las etapas del proyecto
• Eje Formal: posición mental que se adopta frente a un problema
• Eje Lógico: pasa de los modelos mentales hasta las expresiones lingüísticas.
Existe un cuarto eje de experiencia del profesional de sistemas.

(adjunto jpg)

Correspondencia con RUP:
(en el grafico se ver CLARISIMO)

Eje Temporal = ROLES RUP
Eje Formal = ARTEFACTOS RUP
Eje Logico = ACTIVIDADES RUP

De nada, de nada =P

Spoiler: Mostrar
El lunes rindo AM II y prometo despues de esa fecha armar y subir algun resumen de la teoria de Diseño de Sistemas
Si puedo contestar alguna duda lo hare, pero posta estoy hasta las b**** con las ecuaciones diferenciales xD


Archivo(s) adjuntos Imagen(es)
   
30-07-2008 21:13
Visita su sitio web Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
pablo Sin conexión
ModdIng
Hombre de ingenio (?)
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1.646
Agradecimientos dados: 0
Agradecimientos: 7 en 7 posts
Registro en: Apr 2008
Mensaje: #6
Re: [Diseño de Sistemas][Pedido] Final: parte teórica
Buen resumen Adriano =P... sobre el modelo de ambientes tenés alguna idea?

Gracias!
16-08-2008 01:21
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
LeaTex Sin conexión
Presidente del CEIT
.
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 4.852
Agradecimientos dados: 55
Agradecimientos: 195 en 50 posts
Registro en: Apr 2008
BlogSpot Facebook Google+ Last.fm LinkedIn Twitter
YouTube
Mensaje: #7
Re: [Diseño de Sistemas][Pedido] Final: parte teórica
Muchachos, acabo de subir un par de archivos al grupo http://ar.groups.yahoo.com/group/utn-siamofuori
Entre ellos hay un rar de finales y parciales muy bueno, con un compilado de V/F de todos los finales.

Lo de modelo de Peters lo pueden sacar de la página de Donadello de la UB:
http://www.ub.edu.ar/catedras/ingenieri ... rodis2.htm

16-08-2008 18:30
Visita su sitio web Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
LeaTex Sin conexión
Presidente del CEIT
.
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 4.852
Agradecimientos dados: 55
Agradecimientos: 195 en 50 posts
Registro en: Apr 2008
BlogSpot Facebook Google+ Last.fm LinkedIn Twitter
YouTube
Mensaje: #8
Re: [Diseño de Sistemas][Pedido] Final: parte teórica
Ah, me olvidaba algunas cosas.

1) No dejen de leer esta "pregunta de final" respondida por el jefe de cátedra. Por ahí les sirve:
http://espanol.answers.yahoo.com/questi ... 539AAuCFjg

2) Si están entre el 3 y el 4, le cuenta a Donadello este chiste y seguro los aprueba:
http://espanol.answers.yahoo.com/questi ... 832AA7EtXM

16-08-2008 18:39
Visita su sitio web Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
luigino82 Sin conexión
Empleado del buffet
Sin estado :(
*

Ing. en Sistemas
Facultad Regional La Plata

Mensajes: 6
Agradecimientos dados: 0
Agradecimientos: 0 en 0 posts
Registro en: Aug 2008
Mensaje: #9
Re: [Diseño de Sistemas][Pedido] Final: parte teórica
Hola gente copada.. ¿alguien rindió Diseño en la última fecha? no tuve una buena cursada con Leone y el ayudante los sábados a la tarde.. unos ladris tremendos ambos..!! ¿aprobó alguien? ¿que tomaron? ¿alguno quiere prepararla... a ver si en grupo se hace mas liviano.. saludos
27-08-2008 00:44
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
juanmanuelferrara Sin conexión
Empleado del buffet
Sin estado :(
*

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1
Agradecimientos dados: 0
Agradecimientos: 0 en 0 posts
Registro en: Nov 2008
Mensaje: #10
Re: [Diseño de Sistemas][Pedido] Final: parte teórica
Buenas.. muy util todas las preguntas de v/f que subiste.
Ahora la pregunta es... tenes esa misma planilla pero con las respuestas??
Te agradezco si me las envias dado que estare rindiendo examen en estos dias y me serian de gran ayuda.

Muchas Gracias.
Juan.

Angie escribió:Hola!

Alguien esta preparando diseño para esta fecha?
Mas abajo dejo un listado de las preguntas teóricas que encontré que tomaron entre el 2006 y 2007, si les parece vamos respondiendolas...

¿Encontraron algo de material sobre: modelo de ambientes y modelo de peters ? Hay muchas preguntas sobre estos dos temas relacionándolos con rup, pero no puedo encontrar nada de ellos (sólo el cubo del modelo de peters) ni en apuntes de la materia ni en internet.

Gracias!!!

----------------------------------------
Teoría:
Spoiler: Mostrar
Requerimientos
V/F
El proceso de Ingeniería de Requerimientos está incluido en el proceso de diseño de sistemas y software.
Los requerimientos funcionales se obtienen mediante el proceso de ingeniería de requerimientos.
El proceso de ingeniería de requerimientos está incluido en el análisis del sistema.
Los requerimientos funcionales se definen sin entrevistar a los usuarios.
Los requerimientos funcionales se obtienen mediante entrevistas con usuarios.
La ingeniería de requerimientos incluye actividades de validación y gestión.
Los artefactos del RUP se usan en la ingeniería de requerimientos.
Desarrollar
• Cómo se especifican los requerimientos.

Heurísticas
V/F
La forma de mezquita se obtiene minimizando el fan in y maximizando el fan out.
La forma de mezquita se obtiene maximizando el fan out.
La forma de mezquita en una carta estructurada se obtiene minimizando el fan out.
La forma de mezquita se obtiene minimizando el fan in.
El alto y ancho de una carta estructura no son heurísticas de diseño.
Las heurísticas permiten identificar si los requerimientos relevados se contemplan en el alcance definido.
Cuando se llama a ejecutar un módulo de cohesión secuencial ejecutan todos sus componentes internos.
Cuando se llama a ejecutar un módulo de cohesión secuencial ejecutan sólo alguno de sus componentes internos.
Cuando se llama a ejecutar un módulo de cohesión funcional ejecutan todos sus componentes internos.
Cuando se llama a ejecutar un módulo de cohesión lógica ejecutan todos sus componentes internos.
El acoplamiento entre dos módulos influye en la cohesión de los mismos.
Fan-out es el número de módulos que llaman a un módulo.
Desarrollar
• Explique la heurística forma de mezquita. Ejemplifique.
• De un ejemplo de utilización de la heurística de forma de mezquita de un grupo de módulos.
• Enumere heurísticas de diseño estructurado.
• De un ejemplo de utilización de la heurística de maximizar fan in.
• Explique módulo, carta estructurada, heurística y relación entre DFD y Diagrama de estructura.
• Enumere niveles de cohesión y acoplamiento.

Modelo de Peters
V/F
El eje temporal del modelo de Peters corresponde a Roles de RUP.
El eje temporal del modelo de Peters corresponde a actividades de RUP.
El eje formal del modelo de Peters corresponde a Roles de RUP.
El eje formal del modelo de Peters corresponde a artefactos de RUP.
El eje formal de modelo de Peters corresponde a Fases de RUP.
El eje mental del modelo de Peters puede asimilarse a roles del RUP.
El eje mental del modelo de Peters puede asimilarse a actividades del RUP.
El eje mental del modelo de Peters se relaciona con el tipo de sistema del modelo de ambientes.
Los artefactos del RUP se corresponden con el eje formal de Peters.
Los artefactos del RUP se corresponden con el eje temporal del Peters.
Los artefactos del RUP se usan solo en la actividad de análisis y diseño.
Los roles del RUP se relacionan con el eje mental de Peters.
Los roles del RUP se corresponden con el de tecnología en modelo de ambientes.
El modelo de ambientes no se relaciona con el modelo de Peters.
El eje tipo de problema del modelo de ambientes corresponde a Roles.
Desarrollar
• Observando el modelo de Peters en qué eje puede estar incluido el Rol de Gerente de proyecto.

Tiempo real – Red de Petri
V/F
J2EE es un entrono propicio para desarrollar STR.
STR debe ser desarrollado en un entorno que permita un control preciso de la duración de la respuesta a estímulos.
Los sensores modifican el entorno del sistema.
Los STR monitorean y controlan su entorno operativo.
UML incluye notaciones para modelos de máquinas de estado.
En el desarrollo de STR es frecuente la utilización de lenguajes de bajo nivel por razones de performance.
La red de Petri es útil para mostrar el flujo de datos de información (vínculo con punta de flecha) y de control (vínculo con punta de rombo) entre procesos de control y sus almacenamientos.
La red de Petri es útil para vincular almacenamientos de un DFD RT.
La red de Petri es útil para tener trazabilidad de los mensajes con los objetos de un STR desarrollado en objetos usando UML.
Los sistemas de tiempo real poseen arquitectura de repositorio.
En el DFD de tiempo real siempre aparece un flujo de datos continuo.
Los sistemas de tiempo real son una metodología.
Los casos de uso no se utilizan para modelar sistemas de tiempo real.
Las tareas de tiempo real se comunican solamente por mensajes.
Cualquier lenguaje permite programar en tiempo real.
El DFD y la carta estructurada no se aplican para sistemas de tiempo real.
No hay una metodología específica para diseñar sistemas de tiempo real.
Desarrollar
• Enumere y ejemplifique flujos contínuos, discretos y de control en STR.
• Ejemplificar una Red de Petri que incluya sincronismo y exclusión mutua.

Interfases – Documentación - Ayuda
V/F
El proceso de diseño de interfases de usuario solo se aplica para sistemas orientados a objeto.
La ayuda en línea es una característica de las interfases visuales.
El diseño de interfaces de usuario tiene en cuenta la experiencia del usuario.
El diseño de interfases webapp están centrados en el usuario.
El diseño de interfases de aplicaciones web no siempre se centra en el usuario.
La documentación operativa facilita la tarea del personal de sistemas.
El help online de un sistema facilita la tarea del personal de sistemas.
La mejor documentación siempre esta impresa en papel.
La documentación de un sistema no incluye información de noermas y procedimientos.
La documentación operativa facilita la tarea del usuario.
La documentación operativa facilita la tarea del personal de sistemas.
Desarrollar
• Enumere características de interfases visuales.
• Con qué tema de Diseño se corresponden estos conceptos:
- Tiempo de respuesta.
- Facilidades de ayuda.
- Manejo de Error.
- Etiquetado de menú y comando.
- Accesibilidad a la aplicación.
- Internacionalización.

Arquitectura
V/F
Los sistemas centralizados poseen arquietectura de cliente-servidor.
Los sistemas centralizados poseen arquitectura de repositorio.
Los sistemas distribuidos poseen arquitectura de cliente-servidor.
Desarrollar
• Enumere las ventajas de la arquitectura de repositorio.
• Explique arquitectura cliente/servidor, ventajas y desventajas de la misma, con un ejemplo de aplicación.
• Enumere arquitecturas de software y ventajas y desventajas de las mismas.
• Describa el rol de arquitecto de software, en qué actividades participa y enumerar que artefactos y modelos utiliza y produce.


Sincronismo
V/F
Un estímulo puede ser periódico y aperiódico al mismo tiempo.
El flujo de control es siempre sincrónico.
El flujo de datos puede ser sincrónico y asincrónico al mismo tiempo.
Un estímulo puede ser sincrónico y asincrónico al mismo tiempo.
Un estímulo puede ser sincrónico o asincrónico, nunca ambos.

RUP
V/F
Las actividades de RUP siguen un modelo en espiral.
Los artefactos del RUP son guías para documentar.
El proceso unificado de desarrollo de software incluye actores y artefactos.
UML y RUP son métodos para diseño de software.
Desarrollar
• Enumere tres artefactos y vincúlelos con actividades de RUP.
• Los roles que plantea el Proceso Unificado, explicando brevemente alguno de ellos.
• Enumere los artefactos que plantea utilizar el Proceso Unificado explicando brevemente alguno de ellos indicando en que actividad son producidos.
• Explique el modelo de UP.
• Explique diferencia entre actividad y fase en el UP y que modelos UML se utilizan en cada una.


UML
V/F
Los modelos de UML se documentan sólo con herramientas CASE.
Cada escenario debe tener un correlato con un diagrama de secuencia.
Cada caso de uso está representado con una clase del diagrama de clase.
La relación extends de los casos de uso se traduce en una multiplicidad 1 a n en el diagrama de clases.
Todos los casos de uso deben tener, por lo menos, un escenario principal.
UML incluye notaciones para modelso de máquinas de estado.
Los escenarios secundarios deben tener diagramas de secuencia asociados.
Diagrama de objetos es útil para mostrar el flujo de datos de información entre las clases del sistema.
No pueden vincularse varios actores con un mismo caso de uso.
Si nadie en una organización lee los manuales para que perder tiempo en la documentación de los sistemas y no aprovecharlo en temas mas fructíferos para la organización.
Si se ha realizado la especificación de procesos en el DFD, no es necesario realizar la Carta Estructurada debido a que se puede realizar la programación del sistema directamente de la misma.
El diagrama de actividades de UML es el mas adecuado para modelar un sistema de tiempo real.
Un manual de normas y procedimientos de una organización esta desarrollado y mantenido por el área de sistemas.
Desarrollar
Un sensor y un actuador son elementos de UML.
Si no cuento con la presencia permanente del usuario, entonces me conviene utilizar XP, como modelo de desarrollo de software de un sistema.

Varios
V/F
Un DFD puede utilizarse en el diseño de un sistema orientado a objetos.
Un diagrama de casos de uso puede usarse con la metodología estructurada.
La funcionalidad de un DFD es mayor que en un diagrama de casos de uso, para el mismo sistema en desarrollo.
La línea de vida en un diagrama de secuencia es el tiempo en que el objeto esta inactivo.
Es lo mismo una relación de extensión que de inclusión.
Primero se deben encontrar los casos de uso y luego los actores.
Siempre existen escenarios alternativos en un caso de uso.
El modelo de casos de uso no debe utilizarse en sistemas estructurados.
Los DFD pueden usarse para modelar colaboraciones de objetos.
Los módulos siempre se factorizan en otros dos de menor nivel.
La pirámide de diseño de una aplicación web comienza por el diseño de componentes.
Desarrollar
• De un ejemplo normalizado en tercera forma normal de un archivo de alumno de la carrera de ingeniería en sistemas considerando datos personales, cursadas, parciales, finales y asistencia de cada materia.
• Ejemplifique una estructura en tercera formal normal.
• Describa atributos en una aplicación web.
• Enumerar objetivos del diseño de aplicaciones web.
----------------------------------------
30-11-2008 15:14
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
LeaTex Sin conexión
Presidente del CEIT
.
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 4.852
Agradecimientos dados: 55
Agradecimientos: 195 en 50 posts
Registro en: Apr 2008
BlogSpot Facebook Google+ Last.fm LinkedIn Twitter
YouTube
Mensaje: #11
Re: [Diseño de Sistemas][Pedido] Final: parte teórica
juanmanuelferrara escribió:Buenas.. muy util todas las preguntas de v/f que subiste.
Ahora la pregunta es... tenes esa misma planilla pero con las respuestas??
Te agradezco si me las envias dado que estare rindiendo examen en estos dias y me serian de gran ayuda.

Muchas Gracias.
Juan.

vale leer los post anteriores:
LeaTex escribió:Muchachos, acabo de subir un par de archivos al grupo http://ar.groups.yahoo.com/group/utn-siamofuori
Entre ellos hay un rar de finales y parciales muy bueno, con un compilado de V/F de todos los finales.

Lo de modelo de Peters lo pueden sacar de la página de Donadello de la UB:
http://www.ub.edu.ar/catedras/ingenieri ... rodis2.htm

30-11-2008 23:15
Visita su sitio web Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Ricitos Sin conexión
Secretario General
Sin estado :(
*******

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 733
Agradecimientos dados: 9
Agradecimientos: 11 en 7 posts
Registro en: Apr 2008
Mensaje: #12
Re: [Diseño de Sistemas][Pedido] Final: parte teórica
Che, no me pasarias el rar q subiste al grupo utn-siamofuori ??
Graciasss
01-12-2008 10:21
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
pablo Sin conexión
ModdIng
Hombre de ingenio (?)
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1.646
Agradecimientos dados: 0
Agradecimientos: 7 en 7 posts
Registro en: Apr 2008
Mensaje: #13
Re: [Diseño de Sistemas][Pedido] Final: parte teórica
Gracias por los aportes que hagan! Nos van a servir a más de uno ;)

"No estoy de acuerdo con lo que decís, pero defenderé hasta la muerte vuestro derecho a decirlo" - Voltaire.
01-12-2008 10:49
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Dandurff Sin conexión
Empleado de Fotocopiadora
...
**

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 34
Agradecimientos dados: 0
Agradecimientos: 16 en 6 posts
Registro en: May 2008
Mensaje: #14
Re: [Diseño de Sistemas][Pedido] Final: parte teórica
Les dejo el resumen que usamos para la cursada de Iriart. No será mucho, pero algo es algo.
Créditos a brunodiaz que hizo la primer parte! :wave:


Archivo(s) adjuntos
.rar  ResumenDiseño.rar (Tamaño: 256,86 KB / Descargas: 226)
01-12-2008 11:56
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
brunodiaz Sin conexión
The Dark Knight
Bla
**********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 7.762
Agradecimientos dados: 136
Agradecimientos: 381 en 132 posts
Registro en: May 2008
Mensaje: #15
Re: [Diseño de Sistemas][Pedido] Final: parte teórica
Dandurff escribió:Les dejo el resumen que usamos para la cursada de Iriart. No será mucho, pero algo es algo.
Créditos a brunodiaz que hizo la primer parte! wave

400 diapositivas en un par de hojas
solamente con iriart puede pasar
02-12-2008 18:02
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Buscar en el tema
Enviar respuesta 




Usuario(s) navegando en este tema: 1 invitado(s)



    This forum uses Lukasz Tkacz MyBB addons.