Ingenieria de software

Las características del producto software, que lo distinguen de otros productos son: El software se desarrolla, no se fabrica en el sentido clásico como el hardware. La mayoría del software se desarrolla a medida. El software no se deteriora. La mayoría del software se desarrolla ensamblando componentes. La curva de fallos del software es similar a la curva de fallos del hardware.

Marque todas las proposiciones que considere verdaderas: Una de las actividades protectoras o “sombrilla” del software es la gestión del proyecto. El Lenguaje de Modelado Unificado es RUP. El desarrollador es un stakeholder o involucrado en el desarrollo del proyecto de software. El modelo de desarrollo en cascada tiene como desventaja que a menudo es difícil para el cliente establecer todos los requisitos desde un inicio. La curva de fallos del software es decreciente hasta el final del ciclo de vida.

Marque aquellas proposiciones que considere verdaderas: Las fases o etapas de RUP son: Inicio, Elaboración, Implementación y Transición. UML es un lenguaje para modelar. RUP, SCRUM y XP son modelos de procesos de desarrollo de software. Modelado de negocio es una Fase de RUP. Una de las principales características de RUP es que es iterativo e incremental.

Marque aquellas proposiciones que considere verdaderas: Construcción es una Fase de RUP. XP es un modelo ágil que fomenta la utilización de casos de uso como mecanismo efectivo para el diseño. Análisis y Diseño es un flujo de trabajo de RUP. El software empotrado reside en la memoria de solo lectura y controla información en determinados dispositivos como microondas, lavadoras y autos. La curva de fallos del software es inestable y tiene incrementos en la medida que ocurren cambios en el mismo.

¿Cuáles de los siguientes diagramas UML se utiliza para el modelado estructural del software?. Diagrama de clases. Diagrama de secuencia. Diagrama de actividad. Diagrama de despliegue.

¿Cuáles de los siguientes diagramas UML se utiliza para el modelado del comportamiento del software?. Diagrama de clases. Diagrama de secuencia. Diagrama de actividad. Diagrama de comunicación.

¿Por qué modelamos?. Modelamos porque: Los modelos permiten especificar la estructura del sistema. Los modelos brindan una plantilla que nos guía a construir el sistema. Los modelos documentan las decisiones que hemos tomado. Los modelos ayudan a comprender los sistemas. Los modelos permiten especificar el comportamiento del sistema.

RUP es: Un lenguaje de modelado que permite la representación orientada a objetos. Un modelo de proceso de desarrollo de software dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental. Un modelo de proceso de desarrollo de software organizado en fases y flujos de trabajo. Un proyecto de desarrollo de software que utiliza personas y herramientas para la modelación.

La Ingeniería de Software es: Un proceso de desarrollo de software dividido en etapas y actividades. Una tecnología multicapa que incluye un enfoque de calidad que incluye un proceso de desarrollo de software, métodos y herramientas. La aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software. La aplicación de un lenguaje de modelado para representar las abstracciones del software durante el proceso de desarrollo.

UML es: Un lenguaje que permite modelar abstracciones de software orientado a objetos. Un lenguaje de programación orientado a objetos. Un lenguaje que permite la modelación de la estructura estática y dinámica de un sistema. Un lenguaje que puede utilizarse para representar información en las diferentes etapas del ciclo de vida del software. Una herramienta CASE.

Constituyen modelos de proceso de desarrollo de software: Modelo de desarrollo basado en prototipos. Ciclo de vida clásico. XP. UML. RUP.

El producto software: Se define como el conjunto de documentos, diagrama, código fuente, ejecutables del sistema y otros tipos de información que se necesita para representar el software en forma comprensible para las computadoras y los desarrolladores e involucrados. Generalmente se desarrolla a medida; las posibilidades de ensamblar componentes aún son limitadas para diferentes tipos de problemas. Puede clasificarse de diferentes tipos, desde software de sistemas hasta software de inteligencia artificial. Necesita mantenimiento, siendo ésta una de las fases genéricas del software donde pueden corregirse errores, adaptarse y perfeccionarse el software.

Problemas que se enfrentan en el proceso de desarrollo de software: Un sistema puede tener muchos tipos de usuarios y ninguno tiene una visión de conjunto. Los usuarios no saben cómo hacer más eficiente la operación del sistema en su conjunto. Los usuarios no saben qué partes de su trabajo pueden transformarse en software. Los usuarios no saben detallar o especificar lo que saben de forma precisa.

Marque todas las proposiciones que considere verdaderas: Producto de software = código fuente + ejecutables del sistema + documentación + diagramas + manuales. RUP se distingue por estar dirigido por casos de uso, basado en escenarios y ser iterativo e incremental. Una de las disciplinas o flujos de trabajo de RUP es el Modelado del negocio. El software se desarrolla generalmente ensamblando componentes reutilizables. El desarrollo de software de calidad debe realizarse utilizando un proceso de desarrollo.

El propósito del flujo de trabajo de Modelado de negocio es: Entender la estructura y la dinámica de la organización. Entender los problemas actuales e identificar mejoras potenciales. Entender los problemas actuales e identificar mejoras potenciales. Asegurarse de que los clientes, usuarios finales y desarrolladores tienen una idea común de la organización.

Marque aquellas proposiciones que considere verdaderas: Un diagrama de actividad auxilia a los miembros del equipo a entender cómo se desarrolla el proceso de negocio y cómo reacciona ante determinados eventos. La relación <<extend>> sirve para compartir una funcionalidad común entre varios casos de uso, también puede utilizarse para estructurar un caso de uso describiendo sus subfunciones. El flujo de trabajo de Modelado de Negocio utiliza diagramas de actividad para la especificación gráfica de los casos de uso del negocio. El flujo de trabajo de Modelado del negocio involucra a Actores del negocio y Trabajadores del negocio en el diagrama de casos de uso del negocio {FALSE}.

Marque aquellas proposiciones que considere Verdaderas: El flujo de trabajo de Modelado de negocio tiene su mayor incidencia en la fase de Elaboración de RUP. Un diagrama de actividad puede utilizarse para mostrar el flujo de trabajo de un proceso de negocio, así como las decisiones o bifurcaciones que existan en el mismo. En el flujo de trabajo de Modelado de Negocio se utiliza el diagrama de objetos para representar las relaciones que existen entre los trabajadores del negocio y las entidades que éstos manipulan. Un diagrama de actividad se utiliza para el modelado estático de un proceso de negocio. Un diagrama de actividad permite especificar un caso de uso del negocio.

Marque aquellas proposiciones que considere Verdaderas: Un diagrama de actividad puede representarse con calles donde se ubica el comportamiento de actores y trabajadores del negocio. Las reglas de negocio describen las políticas, normas, operaciones, definiciones y restricciones presentes en una organización. La relación de asociación es un tipo de relación simple entre un actor y un caso de uso. Un candidato a actor del negocio es cualquier individuo, grupo, organización o máquina que interactúa con el negocio.

Un candidato a actor del negocio puede ser: Cliente. Socio. Sistema informático. Proveedor.

Marque aquellas proposiciones que considere Verdaderas: Los estereotipos básicos para las clases en el modelo de Análisis son: <<boundary>>, <<control>> y <<entity>>. Una clase en el Análisis define atributos y operaciones que pueden refinarse en la fase de diseño. Una clase estereotipada como <<entity>> puede participar en relaciones como asociación, composición y generalización – especialización. El estereotipo <<entity>>; es empleado para identificar clases que constituyen los límites del sistema o puntos por los cuales algún actor externo puede interactuar con el sistema. Una clase estereotipada como <<boundary>>; puede ser utilizada como interfaz con algún actor externo al sistema.

Marque aquellas proposiciones que considere verdaderas. La arquitectura de un sistema constituye un amplio marco que describe su forma y su estructura, sus componentes y cómo estos interactúan. Los diagramas de clases se utilizan para documentar modelos de comportamiento del sistema. La necesidad de distribución específica del sistema en nodos de procesamiento no está relacionada con la arquitectura del mismo. La agregación es una relación estructural entre instancias en la cual una clase representa el todo y consta de otras que son las partes. Un diagrama de clases muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones.

Marque aquellas proposiciones que considere Verdaderas: En el modelo de Análisis, con el estereotipo <<control>> se modelan clases, cuyo estado debe ser conservado más allá de la ejecución del sistema y cuyos objetos se pueden almacenar y recuperar con posterioridad. En el modelo de Análisis, las clases cuya característica común es representar la persistencia de la información se modelan con el estereotipo <<entity>>. El modelo de Análisis representa una vista externa del sistema. En el diagrama de clases del Análisis, cada estímulo generado por un actor es recibido por una clase del tipo <<boundary>>. Las clases estereotipadas como <<control>>; garantizan el cumplimiento de las reglas de negocio.

Marque aquellas proposiciones que considere Verdaderas: Las clases estereotipadas como <<control>>; se utilizan para coordinar y llevar el control de la secuencia de eventos necesarios para completar cada interacción de un actor con el sistema {FALSE}. Las operaciones del tipo Create, Read, Update y Delete, se modelan en clases con estereotipo <<entity>>. No es una buena práctica en el modelado de clases del Análisis, comunicar una clase interfaz con una clase entidad. Es recomendable, como una buena práctica de modelado, tener una clase controladora en un caso de uso, que sea la coordinadora general. Los aspectos dinámicos del sistema se modelan con clases estereotipadas como << control>> debido a que ellas manejan y coordinan las acciones y los flujos de control principales, y delegan trabajo a otros objetos.

Marque aquellas proposiciones que considere verdaderas: En UML, un diagrama de secuencia muestra las interacciones entre objetos en secuencia temporal durante un escenario concreto. En UML, un diagrama de comunicación muestra las interacciones entre objetos organizadas en torno a los objetos y los enlaces y mensajes que ocurren entre ellos. En UML, los diagramas de clases se utilizan para documentar modelos de comportamiento del sistema. En UML, los diagramas de despliegue muestran las instancias de componentes de software en tiempo de ejecución y generalmente ayudan a identificar sus dependencias y su localización en nodos físicos.

Las relaciones entre clases, en un Diagrama de Clases del Diseño, pueden ser: <<include>>. <<extend>>. generalización - especialización. agregación. composición. asociación. secuencia.

Marque aquellas proposiciones que considere Verdaderas: El modelo de Análisis representa una vista externa del sistema y está descrito en el lenguaje del cliente. En el modelo de Análisis se utilizan los siguientes estereotipos para las clases: entidad, control y abstracta. En el modelo de Análisis se definen realizaciones de casos de uso que se pueden representar con diagramas de interacción. El modelo de Análisis es utilizado fundamentalmente para comprender cómo debería ser diseñado e implementado el sistema. El modelo de Análisis se utiliza fundamentalmente para capturar la funcionalidad del sistema.

Marque aquellas proposiciones que considere Verdaderas: El modelo de diseño del software en un modelo conceptual porque es un plano de la implementación. Un diagrama de secuencia es un diagrama estático de UML que permite mostrar las interacciones entre objetos mediante transferencia de mensajes entre objetos o subsistemas. Los subsistemas de diseño son una forma de organizar los artefactos del modelo de diseño en piezas más manejables. Un subsistema de diseño puede estar formado por de clases del diseño, realizaciones de caso de uso, interfaces y otros subsistemas. Los subsistemas de servicio contienen clases del análisis del tipo <<entity>> y <<control>>.

Marque aquellas proposiciones que considere Verdaderas: Las interfaces se utilizan para especificar las operaciones que proporcionan las clases y los subsistemas. Es significativo para la arquitectura del software en la vista de diseño, la descomposición del modelo en subsistemas, interfaces y la dependencia entre ellos. En el diseño, el arquitecto de software es responsable de mantener la integridad de una o más realizaciones de casos de uso – diseño. Uno de los patrones de arquitectura de software que pueden emplearse en el modelo de diseño de software es MVC (Modelo, Vista, Controlador). Un diagrama de clases en el diseño de software, es un diagrama estático de UML que incluye clases, subsistemas y relaciones asociados a un caso de uso.

Marque aquellas proposiciones que considere Verdaderas: En el modelo de diseño se utilizan tres estereotipos para las clases: <<entity>>, <<control>> y <<boundary>>. El diseño es el centro de atención de la fase de Inicio de RUP. El lenguaje utilizado para especificar una clase del diseño es el mismo que el lenguaje de programación para la implementación. Una clase de diseño presenta atributos que pueden ser public, protected, private y métodos u operaciones. La secuencia de acciones en una realización de un caso de uso en el diseño se representa mediante diagramas de interacción.

Marque aquellas proposiciones que considere Verdaderas: Los diagramas de comunicación se utilizan para mostrar cómo interactúan los objetos para efectuar el comportamiento de un caso de uso concreto. El diagrama de secuencia es un tipo de diagrama usado en el diseño de software para modelar la estructura entre objetos. En la realización de un caso de uso en el modelo de Análisis, se recomienda hacer un diagrama de comunicación para cada variante de flujo de eventos de un caso de uso. En un diagrama de secuencia los objetos se comunican mediante relaciones del tipo <<include>> y <<extend>>. En un diagrama de comunicación, un mensaje es una comunicación entre objetos y porta información con la expectativa de que el objeto que lo reciba va a realizar cierta actividad.

Marque aquellas proposiciones que considere Verdaderas: Para que un objeto pueda responder a un mensaje en un diagrama de secuencia, será necesario que asuma esa responsabilidad implementada en forma de método. La línea de vida en un diagrama de secuencia, representa el comportamiento de un objeto durante su existencia. Los diagramas de interacción en UML son: diagrama de clases y diagrama de comunicación. El modelo de Análisis se describe en el lenguaje del desarrollador. En el modelo de Análisis, las clases estereotipadas como <<control>> representan abstracciones de ventanas, formularios, interfaces de comunicaciones, interfaces de impresoras y sensores.

Marque aquellas proposiciones que considere Verdaderas: El mayor trabajo del flujo de trabajo de Implementación se concentra en la fase de Elaboración en RUP. El modelo de despliegue contiene nodos que representan recursos de cómputo. En el modelo de despliegue, las relaciones entre los nodos representan medios de comunicación como intranet, internet, entre otros. Es un propósito del flujo de trabajo de Implementación distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue. Un componente de tipo <<file>> representa un documento que contiene código fuente.

Marque aquellas proposiciones que considere Verdaderas: En el flujo de trabajo de Implementación se sigue un enfoque incremental que da lugar a un sistema integrado en pasos pequeños y manejables. El ingeniero de componentes es un trabajador del flujo de Implementación que garantiza que cada componente implemente la funcionalidad correcta. Algunos de los estereotipos utilizados para caracterizar los componentes de implementación son: <<file>>; <<boundary>> y <<executable>>. Los componentes modelan elementos físicos que pueden hallarse en un nodo tales como casos de uso, actores y diagramas de secuencia. En un diagrama de despliegue se representan dos tipos de elementos, nodos y conexiones, así como la distribución de componentes del sistema con respecto a la partición física del sistema.

Constituyen requisitos funcionales para un sistema automatizado Tienda de Música Online los siguientes: Comprar créditos para adquirir canciones. Buscar canciones en un catálogo online. Descargar las canciones en la computadora. Alcanzar el 98% de fiabilidad ante fallo del software. Utilizar una metáfora de interfaz similar a Spotify.

El diagrama de casos de uso del sistema está compuesto por: Actores. Trabajadores del negocio. Casos de uso. Relaciones entre actores y casos de uso. Relaciones estereotipadas entre casos de uso. Entidades del negocio. Clases de control.

Se modela un sistema de reservación de vuelos ¿Cuál de los siguientes requisitos es funcional?. El sistema debe funcionar correctamente en cualquier navegador web. El sistema no debe tardar más de cinco segundos en mostrar los resultados de una búsqueda. El sistema debe permitir que el usuario busque por fecha el vuelo, tipo vuelo, disponibilidad de asientos y costo de los vuelos. El sistema debe permitir al administrador actualizar las aerolíneas y vuelos.

Se modela un sistema de reservación de vuelos ¿Cuál de los siguientes requisitos es no funcional?. El sistema debe ser portable y funcionar en Mozilla y Chrome. El sistema no debe tardar más de cinco segundos en mostrar los resultados de una búsqueda de vuelos hacia un destino. El sistema debe permitir al usuario hacer búsquedas de vuelos por fechas. El sistema debe permitir al usuario hacer búsquedas de vuelos por destinos.

Constituyen requisitos funcionales para un sistema automatizado Tienda de Música Online los siguientes: Adquirir una canción a cambio de una cantidad de créditos. Consultar información sobre canciones disponibles. Tener una curva de aprendizaje no mayor de 3 días. Autenticar usuarios. Almacenar información sobre las canciones que se pueden adquirir y su precio en créditos.

¿Cuál es el propósito fundamental del flujo de trabajo Requisitos?. Guiar el desarrollo hacia el sistema correcto a partir de una descripción de los requisitos del sistema (funcionales y no funcionales). Guiar el desarrollo hacia el sistema correcto a partir de una descripción de los requisitos del sistema (funcionales y no funcionales). Descubrir los Requisitos funcionales y representarlos como casos de uso y los Requisitos no funcionales como propiedades o capacidades del sistema. Llegar a un acuerdo entre los integrantes del equipo de software sobre cómo debe desarrollarse el sistema.

Un caso de uso es: Un "fragmento” de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. Una especificación de una secuencia de acciones que el sistema puede llevar a cabo interactuando con sus actores, incluyendo alternativas dentro de la secuencia (flujo de sucesos). Una secuencia de acciones entre el actor y el sistema, que produce un resultado de valor para el actor.

El diagrama de casos de uso del sistema es un artefacto gráfico en el que se representan: Los actores del sistema. Los casos de uso del sistema. Las relaciones que existen entre actores y casos de uso. Las relaciones que existen entre casos de uso.

El modelo de casos de uso del sistema contiene: El diagrama de casos de uso del sistema. Una breve descripción de cada actor del sistema. Una descripción o especificación de la funcionalidad que se ejecutará al realizarse un caso de uso. Una breve descripción de los trabajadores del negocio.

Marque aquellas proposiciones que considere verdaderas: Un requisito es una característica que el sistema debe tener o es una restricción que el sistema debe satisfacer para ser aceptada por el cliente. Sólo los trabajadores del negocio podrán convertirse en actores del sistema. Un requisito funcional describe la interacción entre el sistema y su ambiente (usuario y cualquier otro sistema externo que interactúa con el sistema) independientemente de su implementación. Un actor representa un rol, que es jugado por personas, dispositivos de hardware o incluso otro sistema al interactuar con el sistema. Un caso de uso es una forma en que un actor utiliza el sistema.

Un caso de uso es una forma en que un actor utiliza el sistema. Los casos de uso proporcionan un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguen a una comprensión común del sistema. Un caso de uso es una descripción de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor. En la especificación textual de un caso de uso se debe especificar solamente el flujo básico de eventos. La relación <<extend>> modela el comportamiento común en un caso de uso. Los requisitos no funcionales incluyen restricciones como el tiempo de respuesta, la precisión, recursos consumidos, seguridad.

El flujo de trabajo Requisitos es tan complicado porque: La mayoría de los usuarios no sabe qué partes de su trabajo pueden transformarse en software. Con frecuencia los usuarios no saben cuáles son los requisitos ni tampoco cómo especificarlos de una forma precisa. Los requisitos son cambiantes, así como puede serlo el negocio, la tecnología y los recursos.