INGENIERÍA DE SOFTWARE

¿Cuál es el proceso de Ingeniería de procesos?. Análisis,Especificación,Validación,Obtención. Análisis,Especificación,Requisitos Validados ,Obtención. Análisis,Especificación,Modelos de Requisitos,Obtención,Necesidad de Clientes. Análisis,Especificación,Validación,Implementación.

Todos son actividades de requisitos excepto: La obtención de requisitos. El análisis de requisitos. La especificación de requisitos. La validación de requisitos de software. La revisión de requisitos.

¿La obtención de requisitos consiste en capturar el propósito y funcionalidades del sistema desde las perspectivas del desarrolador?. V. F.

¿El análisis de requisitos consiste en estudiar las necesidades del usuario para obtener una definición detallada de los requisitos ?. V. F.

¿Las especificación de requisitos es el proceso de documentar el comportamiento requerido de un sistema de software, a menudo utilizando una notación o modelado u otro lenguaje de especificación ?. V. F.

¿La validación de requisitos consiste en examinar los requisitos para asegurarse de que validan el sistema que el cliente y los usuarios desean ?. V. F.

El análisis de requisitos consiste en delimitar el software y establecer con qué elementos internos interacciona. V. F.

¿El análisis de requisitos consiste exclusivamente en realizar un modelo conceptual de los requisitos?. V. F.

¿En qué consiste la clasificación de requisitos?. Consiste en establecer un conjunto de categorías y situar cada requisito en ellas. La clasificación de requisitos no es siempre la misma, existiendo diversos criterios con diferente nivel de aceptación. La clasificación de requisitos es la misma, existiendo un criterio con un nivel de aceptación definido. Consiste en establecer un conjunto de valores y analizar cada requisito en ellas.

Todos son tipos de clasificación excepto?. Funcionales. No Funcionales. Del proceso. Del producto. Del Usuario.

¿Cuáles son los componentes de un diagrama de flujo de datos?. Clases, objetos, mensajes, relaciones. Entidades externas, relaciones, proceso, almacenamientos. Entidad externa, flujo, proceso, almacenamientos. Actor, entidad externa, relaciones, procesos.

¿Qué se determina en el estudio de Factibilidad Técnica de un sistema de información?. Si se puede o no desarrollar con el personal. Si se puede o no desarrollar con el personal, equipo y software. Si se puede o no desarrollar con el equipo. Si se puede o no desarrollar el software en el tiempo y costo establecidos.

En el desarrollo de un sistema de información. ¿El análisis costo-beneficio forma parte de?. Factibilidad económica. Factibilidad técnica. Factibilidad legal. Factibilidad operativa.

Clasifique los siguientes requerimientos recolectados en el desarrollo de un producto de software, en funcionales (F) y no funcionales (NF): 1. La información de enrutamiento debe protegerse contra modificaciones no autorizados. 2. Deben almacenarse todas las facturas emitidas por el sistema para su posterior consulta 3. El sistema debe permitir la realización periódica de copias de seguridad para toda la información de clientes y ventas. 4. El sistema incluirá algún tipo de comprobación de la identidad para las operaciones sensible vencimiento, etc. 1NF, 2F, 3F, 4NF. 1NF, 2NF, 3F, 4NF. 1F, 2NF, 3F, 4F. 1NF, 2F, 3NF, 4F.

¿En qué etapa del proceso de desarrollo se realiza el Diagrama de flujo de datos, diccionario de datos, mini especificaciones, diagrama de transición de estados?. Codificación. Análisis. Diseño. Pruebas.

¿Qué diagrama se utiliza en UML para definir las funcionalidades de un sistema de información?. Diagrama de clases. Diagrama de actividades. Diagrama de casos de uso. Diagrama de estados.

El proceso de Ingeniería de Requisitos tiene las siguientes actividades: obtención de requisitos, análisis de requisitos, especificación de requisitos y validación de requisitos. ¿En cuál actividad se realiza: la clasificación de los requisitos, el modelado conceptual y se delimita y define exactamente cada requisito?. Especificación de requisitos. Obtención de requisitos. Análisis de requisitos. Validación de requisitos.

A partir de los requisitos del sistema levantados por el ingeniero se obtiene como producto final la especificación del sistema, ¿Que describe la esta especificación?. La lluvia de ideas que recoge los requerimientos del usuario, producto de las reuniones preliminares. La función y características de un sistema de computación y las restricciones que gobiernan su desarrollo. Los modelos del sistema que obedece a los requerimientos funcionales y no funcionales de los usuarios. La planificación detallada de las etapas de una metodología a seguir en el proceso de construcción del software.

Cuando los analistas de sistemas indagan sobre los requerimientos de información de los usuarios, deben ser capaces de concebir la manera en que los datos fluyen a través del sistema u organización, los procesos que sufren estos datos y sus tipos de salidas. En este diseño se muestran los procesos, flujos de datos y su relación con las entidades externas y los almacenes de datos y es conocido como diagrama de flujo de datos. ¿En tal sentido se puede afirmar que una entidad externa?. Suministra información acerca de la conexión del sistema con el mundo exterior. La localización expresa la unidad o área dentro de la organización donde se realiza el proceso. Sirve para almacenar información que fluye en los procesos. Representa la información en reposo.

¿Cuándo usted va a desarrollar un sistema, en cuál de las actividades de la Ingeniería de requisitos usted realiza el diseño de prototipos de baja o alta fidelidad?. Validación de requisitos. Análisis de requisitos. Especificación de requisitos. Obtención de requisitos.

Ejemplo de Requerimientos. Requerimientos de negocio. Casos de uso y escenarios. Reglas del negocio. Requerimientos funcionales. Requerimientos de interfaces externas.

Ejemplos de Requisitos. Propiedad. Velocidad. Tamaño. Facilidad de uso. Confiabilidad. Robustez. Portabilidad.

Todos son requerimientos funcionales excepto: Es lo que debe hacer el sistema. Son declaraciones de los servicios que proveerá el sistema. Pueden clasificarse en diferentes tipos como: externo, organización, producto, etc. En algunos casos, lo que el sistema no debe hacer.

Los requerimientos no funcionales son: Son restricciones de los servicios o funciones ofrecidos por el sistema. No se refieren directamente a las funciones específicas que entrega el sistema, sino a sus propiedades o características (fiabilidad, seguridad, confiabilidad, velocidad). Lo que debe tener el sistema que se va a construir. Son declaraciones de los servicios que proveerá el sistema, de la manera en que este reaccionará a entradas particulares y de como se comportara en situaciones particulares.

Ejemplo de requisitos. Requisitos Funcionales. Requisitos no Funcionales.

El modelado conceptual tiene como objetivo fundamental facilitar la comprensión de los requisitos mediante su representación en un lenguaje o notación que comprendan quienes van a tratar con los requisitos. V. F.

El modelado es parte de la elaboración de la solución. V. F.

El modelado conceptual es una representación que permite comprender el problema que se va a resolver a través de un sistema. V. F.

En el análisis de requisitos surgen a menudo conflictos de intereses entre las diferentes partes involucradas. V. F.

El objetivo final de la negociación de los requisitos, es eliminar redundancias, inconsistencias y puntos de desacuerdo. V. F.

El modelo de casos de uso suele servir para: Para delimitar el alcance del sistema. Esbozar quienes interactuarán con el sistema a modo de actores. Definir las funcionalidades esperadas. Capturar un primer glosario de términos del dominio. Validar los requisitos del cliente. Validar los requisitos del software.

De que elementos consta un diagrama de caso de uso. Actor. Casos de Uso. Relaciones de Uso. Herencia. Comunicación. Relaciones de Caso. Relaciones de UML.

¿Un Actor es un rol que un usuario juega con respecto al sistema?. V. F.

El Caso de uso es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. V. F.

¿Qué es una asociación?. Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. Es una operación por la cual establecemos que uno o mas casos de uso tienen elementos en común que deseamos agrupar en un caso de uso más genérico. Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea).

¿Qué es una generalización?. Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple. Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Es una operación por la cual establecemos que uno o mas casos de uso tienen elementos en común que deseamos agrupar en un caso de uso más genérico.

¿Qué es una Dependencia o Instanciación ?. Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Es una operación por la cual establecemos que uno o mas casos de uso tienen elementos en común que deseamos agrupar en un caso de uso más genérico. Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

¿Qué es un requisito?. Es la capacidad que debe alcanzar o poseer un sistema o componente de un sistema para satisfacer un contrato, estándar, especificación u otro documento formal. Es la propiedad que un software desarrollado o adaptado debe tener par resolver un problema concreto. Es el proceso de documentar el comportamiento requerido de un sistema de software.

¿Qué son las actividades de requisitos?. Es la obtención, análisis, especificación y validación de requisitos de software. Es la declaración, análisis, especificación y validación de requisitos de software. Es la obtención, análisis, especificación e implementación de requisitos de software. Ninguna de las anteriores.

Un especificación debe ser: Completa. Verificable. Consistente. Modificable. Susceptible de permitir seguimientos. Utilizable durante las fases de operación y mantenimiento. Con ambiguedades.

¿Para sistemas sencillos con que documento puede ser suficiente?. Documento de definición del sistema. Documento de requisitos del sistema. Documento de especificación de requisitos del sistema (ERS).

¿A quién va dirigido el documento de definición del sistema?. Dirigido a los usuarios y clientes del sistema. Dirigido a los desarrolladores del sistema.

¿Qué incluye la de definición del sistema ?. Introducción al entorno. Objetivos. Especificaciones de rendimiento. Lista de participantes.

¿Qué incluye la de definición del sistema ?. Funcionalidades del sistema. Especificaciones de rendimiento. Requisitos de seguridad. Los Roles.

V o F El framework se refiere a una estructura básica subyacente en la ingeniería de software, que sirve al programador como estructura de desarrollo para su programación de aplicaciones. V. F.

Qué tipos de frameworks existen?. Frameworks de aplicación. Frameworks de dominio. Frameworks de clase. Frameworks de componentes. Frameworks de coordinación. Framework de prueba. Framework de trabajo. Framework experimental.

¿Cuáles son factores a considerar a la hora de elegir un framework?. Soporte de comunidad, documentación, simplicidad y potencia, seguridad, arquitectura mvc, reutilización. Soporte de base de datos, análisis de requisitos, complejidad. Estructura de datos, soporte de comunidad, documentación, simplicidad, potencia, seguridad, arquitectura mvc, reutilización. Soporte de comunidad, documentación, seguridad.

V o F UWE es una metodología basada en el proceso unificado y UML para el desarrollo de aplicaciones web. V. F.

¿Cuáles son las 3 fases principales de UWE?. fase de captura. fase de análisis y diseño. fase de implementación. fase de requisitos. fase de especificación.

Las fases de UWE son... obtención de requisitos, diseño del sistema, codificación del software, pruebas, instalación, mantenimiento. obtención de requisitos, análisis de requisitos, especificación de requisitos, ,verificación de requisitos. todas las anteriores. análisis de requerimientos, diseño del sistema, codificación del software, pruebas, instalación, mantenimiento.

V o F la fase de codificación de software se basa en Las pruebas se utilizan para asegurar el correcto funcionamiento de secciones de código. V. F.

V o F las prácticas asociadas a Mobile-D incluyen desarrollo basado en pruebas, la programación en parejas, integración continua y refactorización, así como las tareas de mejora de procesos de software. V. F.

Cuáles son las fases de Mobile-D?. Exploración. Inicialización. Producción. Estabilización. Diseño. Análisis. Pruebas.

Relacione las fases de la metodología Mobile D. Exploración. Inicialización. Producción. Estabilización. Pruebas.

V o F ¿ Los modelos de proceso de desarrollo de software también son llamados modelos de ciclo de vida?. V. F.

V o F el enfoque de "codificar y probar" genera una alta fiabilidad además de una alta flexibilidad para mejoras. V. F.

¿Qué es un ciclo de vida?. es un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso. es un esquema o marco de trabajo que ofrece una estructura base para elaborar un proyecto con objetivos específicos, una especie de plantilla que sirve como punto de partida para la organización y desarrollo de software. Es una aproximación tradicional al mantenimiento del software. Ninguna de las anteriores.

Ordene las etapas de desarrollo de software correctamente: análisis pruebas uso_y_mantenimiento planificación diseño instalación_o_despliegue implementación.

Quién debe elegir los métodos y herramientas más adecuados en cada momento para satisfacer las necesidades específicas del proyecto, además de establecer las medidas oportunas que permitan controlar la evolución del proyecto. el programador. el auditor. el director del proyecto. el gerente del área de informática.

El modelo en cascada... Consiste en una serie de fases que deben realizarse en una secuencia estrictra. Permite el feedback con el cliente. El sistema se entrega completo y de una sola vez al final. Es rápido y eficiente. No se puede regresar a fases anteriores.

V o F en el modeo en cascada se debe ir programando las actividades en el transcurso del desarrollo. V. F.

Ordene las etapas del modelo en cascada correctamente: 5_operación_mantenimiento 2_análisis_y_diseño 3_implementación_y_pruebas_unidades 1_definición_de_requerimientos 4_integración_y_pruebas_del_sistema.

V o F el modo en cascada no requiere documentación. V. F.

V o F el análisis de requerimientos genera un documento llamado Especificación de requerimientos el cual es la entrada para la fase de diseño de la arquitectura. V. F.

El modelo lineal secuencial. sólo debe usarse cuando los requerimientos se entiendan bien y sea improbable el cambio radical durante el desarrollo del sistema. sugiere un enfoque sistemático y secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento. Como es más sencillo emplear un modelo de gestión común durante todo el proyecto, aún son de uso común los procesos de software basados en el modelo en cascada. No se require conocimiento del modelo en cascada.

Vo F El modelo en V es una evolución del modelo en cascada. V. F.

¿A que modelo corresponde el siguiente gráfico?. modelo en cascada. modelo en V. modelo lineal. Scrum.

¿Por qué el software necesita modelos?. El software es invisible e intangible: solo se ve su comportamiento, sus efectos en el medio. El software es mucho más modificable que otros productos realizados por el hombre. El software se desarrolla por proyectos, no en forma repetitiva como los productos de la industria manufacturera. todas las anteriores.

¿Qué es UML?. un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. es aquello que se puede observar sino una representación simplificada. Es una descripción analógica para ayudar a visualizar algo que no se puede observar directamente y que se realiza con un propósito determinado y se destina a un público específico. ninguna de las anteriores.

¿Para que se utiliza UML?. para mejorar el entendimiento de algún aspecto dentro del equipo de desarrollo, entre el equipo de desarrollo y otros interesados en el proyecto o para documentar aspectos del desarrollo para el mantenimiento posterior del sistema. para modelar procesos de manufactura, desarrollo, etc. es lo que posibilita la comunicación entre el equipo y el usuario. permite administrar los recursos que necesita el sistema operativo del computador para manejar los programas y aplicaciones.

Relacione los tipos de diagrama. Estáticos. Dinámicos.

Relacione conceptos de modelo y diagrama. Modelo. Diagrama.

¿A que tipo de diagrama UML corresponde la siguiente imagen?. Diagrama de clases. Diagrama de casos de uso. Diagrama de secuencia. Diagrama de componentes.

V o F En el análisis de requisitos, Utilizando un proceso iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir satisfacer los objetivos planteados. V. F.

¿En que consiste la validación de requisitos?. en examinar si los documentos de requisitos definen el software que los usuarios esperan. Si los documentos de requisitos están sujetos a procesos de validación y verificación. Realizan una abstracción de las características del sistema, es decir, consisten en desarrollar un modelo del mismo. Si los documentos son acordes a estándares establecidos o son consistentes, comprensibles y completos. Demostración de que los requerimientos que definen el sistema son lo que el cliente realmente quiere. Representan el sistema de forma jerárquica, basándose en mecanismos de partición del problema y estableciendo varios niveles de detalle.

¿Cómo debe componerse un grupo ideal de revisores de requisitos?. director del proyecto, usuarios, expertos funcionales. uno o varios usuarios, un responsable del cliente, desarrolladores, analista de requisitos, expertos funcionales, experto externo. experto externo, responsable del cliente, director del proyecto, usuarios. todas las anteriores.

V o F El objetivo del grupo de revisión es buscar errores y contradicciones en los requisitos, descripciones poco claras o ambiguas y desviaciones de las prácticas estándar. Para ello se utilizará la siguiente tabla: V. F.

¿Qué es el prototipado?. es lo que posibilita la comunicación entre el equipo y el usuario. Un lenguaje visual para especificar, construir y documentar los artefactos de los sistemas. La creación de un sistema a través de sus requisitos. consiste en la elaboración de un modelo del sistema que se construye para evaluar mejor sus requisitos.

V o F El prototipado de alta fidelidad corresponde a Complejos modelos dinámicos formados por conjuntos de pantallas con ciertas funcionalidades restringidas del sistema. V. F.

¿Qué indican las dimensiones en prototipado?. madurez, dinámica del proyecto, alcance. alcance, capacidad de ejecución, estilo del proyecto. Capacidad de ejecución, madurez del proyecto,fidelidad del prototipo, alcance. madurez, fidelidad del proyecto, estilo del proyecto, capacidad de ejecución.

Relacione los valores de la metodología XP. Comunicación. Simplicidad. Retroalimentación. Coraje. Respeto.

En Scrum que función realiza el product owner?. Coordinador y facilitador del grupo. Involucrado por parte del cliente con conocimientos del negocio. Define el producto/sistema a construir. Responsable de integrar el proyecto al flujo de trabajo de la organización. Listado priorizado de los requerimientos del producto.

¿Qué es un daily Scrum?. Reunión diaria del equipo con el scrum master. Culminación del sprint. Planificación del proyecto. iteración.