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.
![[-]](images/collapse.gif)
...
![[Imagen: frase.png]](https://frasesdelea.000webhostapp.com/frase.png)
.gif ";)")
