Examen Parcial INGENIERIA DEL SOFTWARE I PDF

24/9/2018 Examen parcial - Semana 4: INV/PRIMER BLOQUE-INGENIERIA DEL SOFTWARE I-[GRUPO1]
Examen parcial ‑ Semana 4
Fecha límite 24 sep en 23:59 Puntos 70 Preguntas 14
Disponible 21 sep en 0:0024 sep en 23:59 4 días Tiempo límite 90 minutos
Intentos permitidos 2
Instrucciones
Volver a realizar la evaluación
Historial de intentos
Intento Tiempo Puntaje
https://poli.instructure.com/courses/6105/quizzes/24984 1/11
Intento Tiempo Puntaje

ÚLTIMO Intento 1 17 minutos 70 de 70
 Las respuestas correctas estarán disponibles del 25 sep en 0:00 al 25 sep en 23:59.
Calificación para este intento: 70 de 70
Presentado 24 sep en 19:32
Este intento tuvo una duración de 17 minutos.
Pregunta 1
El proceso unificado de Rational ¿En qué fase del ciclo de vida la
arquitectura de software es el objetivo principal?
Diseño.
Transición.
Aplicación.
Elaboración.
Pregunta 2
Una compañía de software de muchos años aborda un tipo de problema
completamente nuevo para ella que no se parece en nada a lo antes
desarrollado, con esto en mente, la empresa opta para el proceso de
desarrollo tomar el modelo basado en componentes, lo cual usted justificaría
indicando que

la idea general es encontrar partes de software previamente desarrollados
que satisfagan requerimientos de la aplicación, de tal manera que no sea
necesario llevar a cabo un desarrollo repetido consumiendo tiempo y
recursos.

los modelos basados en reutilización de código son muy importantes y el
modelo basado en componentes se destaca entre ellos.

en la mayoría de los casos buena parte del esfuerzo y tiempo se centra en la
generación de código, resulta evidente que una mejora en ese sentido podría
afectar de manera favorable el desarrollo del proyecto.

una de las mayores ventajas es que el cliente puede poner en funcionamiento
el sistema sin tener que esperar demasiado, al priorizar los requerimientos,
aquellos que son más importantes son entregados primero, lo que los somete
a pruebas durante más tiempo.
Pregunta 3
Los tres grandes grupos de diagramas UML son:
De comportamiento, de estructura estática y de interacción
De estructura estática, de requerimientos, y de casos de uso.
De interacción, de funcionalidad y de interfaz.
De Booch, OMT y OOSE.
Pregunta 4
La definición es una parte del proceso de software que busca entender de
manera completa el problema a solucionar, por tanto la gestión de
requerimientos contempla

la comprensión del problema y decantarla en una serie de documentos con
una visión ordenada y técnica del problema.
la respuesta a cómo cumplirá el software las necesidades del cliente.

determinar la estructura interna adecuada que permita a los desarrolladores
comenzar la escritura de código.

los procesos y métodos necesarios para identificar, organizar y documentar
las necesidades del cliente.
Pregunta 5
Un enfoque organizado y estructurado para el diseño y documentación del
proceso de construcción de software facilita la creación de una estructura
que soporte un diseño robusto que cumpla con las expectativas del cliente y
además pueda servir como base para proyectos posteriores, surgen por
tanto los patrones de diseño de software e igualmente, el modelo de proceso
de desarrollo basado en componentes. ¿Porqué es mejor usar el primero
que el segundo?

No hay razón alguna para elegir uno de ellos, pues son básicamente lo mismo
ya que pretenden el reuso de software y se pueden usar indistintamente, con
la debida documentación, cohesión y acoplamiento.

Porque un patrón de diseño resulta ser una solución de comprobada
efectividad a un problema recurrente y que es aplicable a diferentes
problemas en distintas circunstancias y un componente es código que ofrece
un conjunto de servicios o funcionalidades, a través de interfaces definidas.

Porque es difícil encontrar componentes que satisfagan los requerimientos
identificados de manera completa, sin que se requieran modificaciones. Es
por eso que se llevan a cabo los cambios necesarios para que los
componentes a utilizar cumplan con las necesidades identificadas.

Porque ya que el correcto funcionamiento del sistema depende de la sinergia
existente entre los componentes a reutilizar, es necesario definir aquí un
diseño que satisfaga las interacciones necesarias y cumpla a la vez con los
requerimientos definidos para el sistema.
Pregunta 6
Una forma diferente a la usual de alcanzar la condición de éxito en un caso

de uso se conoce como
postcondición.
extensión.
subvariación.
flujo normal de eventos.
Pregunta 7
Durante la fase general de “desarrollo” de un proceso de software, se

responde a una pregunta genérica respecto al proceso. Dicha pregunta es
¿Quiénes van a participar en el proceso?
¿Cuánto dinero costará el desarrollo?

¿Cómo se va a implementar un producto que satisfaga las necesidades del
cliente?
¿Qué tanto tiempo va a tomar la codificación?
Pregunta 8
Ya que un caso de uso describe una actividad dentro del proceso de
software y un requerimiento es una especificación de todo aquello que debe
ser implementado en una solución de software. Los diagramas del modelo
UML reflejan entonces

el conjunto de procesos, prácticas y estándares necesarios para abordar
todos los aspectos del proceso de construcción.

un producto tangible que cumple con las necesidades y restricciones
especificadas por el cliente y refinadas en conjunto con el desarrollador.

un modelo del problema que es completo, correcto y posible de implementar a
partir de los requerimientos del cliente.

de manera inequívoca y concertada las funcionalidades que el producto de
software debe tener para satisfacer las necesidades del cliente.
Pregunta 9
Suponga un sistema para un cajero automático en el que el cliente, previa
identificación, realiza una de las siguientes transacciones:
Retira dinero en efectivo.
Deposita en efectivo o deposita en cheque.

El diagrama de casos de uso para el cajero automático es
Seleccione una:
A:
B:
C:
D:
D
A
B
C
Pregunta 10
UML es un lenguaje gráfico estándar que se usa para especificar,
documentar y visualizar el conjunto de productos de un proceso de
construcción de software, está pensado para facilitar los procesos de
comunicación dentro de los equipos de desarrollo de software, la razón de
usar además de los diagramas de casos de uso, la documentación de la
estructura interna de los casos de uso es

que la recomendación es mantener los casos de uso en el nivel de los
procesos elementales de negocio. Claramente es posible documentar casos
de uso en niveles de mayor o menor complejidad, pero enfocarse en el nivel
recomendado suele generar mejores resultados.

que un caso de uso debe describir un objetivo particular a través de la
correcta manipulación de la información y que tiene una complejidad
suficiente para que se requiera un número significativo de pasos para lograr el
objetivo esperado.

que no es una aproximación gráfica sino escrita y que ofrece información
respecto al funcionamiento detallado de cada una de esas interacciones y los
diferentes escenarios en los cuales se desenvuelve.

que un caso de uso debe describir una actividad que tiene sentido dentro del
proceso de uso del software.
Pregunta 11
Durante la fase de levantamiento de requerimientos debe existir un diálogo

constante entre
El desarrollador y el cliente.
El desarrollador y el gerente.
El gerente y el equipo de pruebas.
El cliente y los diseñadores de interfaz.
Pregunta 12
Los siguientes son tipos de requerimientos:
No funcionales y de negocio.
Funcionales, explícitos y ocultos.
Externos y de usuario.
Extensiones, subvariaciones y flujo normal.
Pregunta 13
En el proceso de ingeniería de software
se aplica a software existente ya que se debe implementar nuevos
requerimientos.

no se aplica a software existente ya que se debe es automatizar procesos
lentos.
no se aplica a software existente debido a que ya pasó por este proceso.

no se aplica a software existente ya que sólo se aplica para software nuevo.
Pregunta 14
La decisión del enfoque a tomar al abordar un proceso de construcción de
software depende de varias características, por tanto es posible llevar un
proyecto de software desde varias perspectivas a efectos de contemplar

las capacidades e intereses de la compañía de desarrollo aún a expensas del
producto a entregar al cliente.

el cambio de plataforma de sistemas del cliente a efectos de usar la
experiencia del desarrollador en lenguajes tradicionales.

la reducción de las características del producto a efectos de agilizar su
desarrollo.

el tipo de proyecto, el tipo de cliente, las restricciones de tiempo dinero o
tecnología.
Calificación de la evaluación: 70 de 70

Examen Parcial INGENIERIA DEL SOFTWARE I PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Examen Parcial INGENIERIA DEL SOFTWARE I PDF

Cargado por

Copyright:

Formatos disponibles

24/9/2018 Examen parcial - Semana 4: INV/PRIMER BLOQUE-INGENIERIA DEL SOFTWARE I-[GRUPO1]

Intento Tiempo Puntaje

Los tres grandes grupos de diagramas UML son:

Una forma diferente a la usual de alcanzar la condición de éxito en un caso

Durante la fase general de “desarrollo” de un proceso de software, se

Durante la fase de levantamiento de requerimientos debe existir un diálogo

Los siguientes son tipos de requerimientos:

También podría gustarte