Examen Parcial 1

6/4/2019 Examen parcial - Semana 4: INV/PRIMER BLOQUE-INGENIERIA DEL SOFTWARE I-[GRUPO1]
Examen parcial - Semana 4
Fecha límite 9 de abr en 23:55 Puntos 70 Preguntas 14 Disponible 6 de abr en 0:00-9 de abr en 23:55 4 días Tiempo límite 90 minutos Intentos permitidos 2
Instrucciones
https://poli.instructure.com/courses/8504/quizzes/32540 1/11
Historial de intentos
Intento Tiempo Puntaje
Intento Tiempo Puntaje

MANTENER Intento 2 9 minutos 60 de 70
ÚLTIMO Intento 2 9 minutos 60 de 70
Intento 1 40 minutos 50 de 70
 Las respuestas correctas estarán disponibles del 10 de abr en 0:00 al 10 de abr en 23:55.
Calificación para este intento: 60 de 70

Presentado 6 de abr en 12:02
Este intento tuvo una duración de 9 minutos.
Pregunta 1 5 / 5 ptos.
Durante la fase de levantamiento de requerimientos debe existir un diálogo constante entre
El gerente y el equipo de pruebas.
El desarrollador y el gerente.
El cliente y los diseñadores de interfaz.
El desarrollador y el cliente.
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
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.
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.
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.
Los tres grandes grupos de diagramas UML son:
De estructura estática, de requerimientos, y de casos de uso.
De interacción, de funcionalidad y de interfaz.
De Booch, OMT y OOSE.
De comportamiento, de estructura estática y de interacción
Incorrecto Pregunta 4 0 / 5 ptos.
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?
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.
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.
No dice que son distintos.
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.
Incorrecto Pregunta 5 0 / 5 ptos.
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
de manera inequívoca y concertada las funcionalidades que el producto de software debe tener para satisfacer las necesidades del cliente.
el conjunto de procesos, prácticas y estándares necesarios para abordar todos los aspectos del proceso de construcción.
Es la definición de ingeniería de software.
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.
En un proceso de diseño e implementación del software
se determinar las funcionalidades del software que cumplen las necesidades del cliente.
se diseña y realiza la programación del software.
se desarrolla sólo el diseño de la base de datos del software.
se valida y comprueba que el software cumpla los requerimientos.
Los diagramas de caso de uso
muestra la secuencia de estados de un objeto respecto a unos estímulos.
muestra las interacciones de los actores con el sistema y las relaciones entre dichas interacciones.
permite visualizar las relaciones entre las clases que involucran el sistema.
muestra la forma en que los objetos se comunican entre sí al transcurrir el tiempo.
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
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.
las capacidades e intereses de la compañía de desarrollo aún a expensas del producto a entregar al cliente.
el tipo de proyecto, el tipo de cliente, las restricciones de tiempo dinero o tecnología.
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 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 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 una actividad que tiene sentido dentro del proceso de uso del software.
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.
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?
¿Qué tanto tiempo va a tomar la codificación?
¿Cómo se va a implementar un producto que satisfaga las necesidades del cliente?
En el proceso de ingeniería de software
no se aplica a software existente ya que se debe es automatizar procesos lentos.
no se aplica a software existente ya que sólo se aplica para software nuevo.
no se aplica a software existente debido a que ya pasó por este proceso.
se aplica a software existente ya que se debe implementar nuevos requerimientos.
El proceso unificado de Rational ¿En qué fase del ciclo de vida la arquitectura de software es el objetivo principal?
Elaboración.
Aplicación.
Diseño.
Transición.
Una forma diferente a la usual de alcanzar la condición de éxito en un caso de uso se conoce como
subvariación.
flujo normal de eventos.
extensión.
postcondición.
Los siguientes son tipos de requerimientos:
No funcionales y de negocio.
Extensiones, subvariaciones y flujo normal.
Externos y de usuario.
Funcionales, explícitos y ocultos.
Calificación de la evaluación: 60 de 70

Examen Parcial 1

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Examen Parcial 1

Hochgeladen von

Copyright:

Verfügbare Formate

6/4/2019 Examen parcial - Semana 4: INV/PRIMER BLOQUE-INGENIERIA DEL SOFTWARE I-[GRUPO1]

Examen parcial - Semana 4

Intento Tiempo Puntaje

Intento Tiempo Puntaje

ÚLTIMO Intento 2 9 minutos 60 de 70

Calificación para este intento: 60 de 70

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

El gerente y el equipo de pruebas.

El cliente y los diseñadores de interfaz.

Los tres grandes grupos de diagramas UML son:

De estructura estática, de requerimientos, y de casos de uso.

De interacción, de funcionalidad y de interfaz.

De Booch, OMT y OOSE.

De comportamiento, de estructura estática y de interacción

Incorrecto Pregunta 4 0 / 5 ptos.

No dice que son distintos.

Incorrecto Pregunta 5 0 / 5 ptos.

Es la definición de ingeniería de software.

En un proceso de diseño e implementación del software

se diseña y realiza la programación del software.

se desarrolla sólo el diseño de la base de datos del software.

se valida y comprueba que el software cumpla los requerimientos.

Los diagramas de caso de uso

muestra la secuencia de estados de un objeto respecto a unos estímulos.

muestra la forma en que los objetos se comunican entre sí al transcurrir el tiempo.

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.

¿Quiénes van a participar en el proceso?

¿Cuánto dinero costará el desarrollo?

¿Qué tanto tiempo va a tomar la codificación?

¿Cómo se va a implementar un producto que satisfaga las necesidades del cliente?

En el proceso de ingeniería de software

no se aplica a software existente ya que se debe es automatizar procesos lentos.

no se aplica a software existente ya que sólo se aplica para software nuevo.

no se aplica a software existente debido a que ya pasó por este proceso.

se aplica a software existente ya que se debe implementar nuevos requerimientos.

flujo normal de eventos.

Los siguientes son tipos de requerimientos:

Extensiones, subvariaciones y flujo normal.

Funcionales, explícitos y ocultos.

Das könnte Ihnen auch gefallen