ENTORNOS DE DESARROLLO TEMA1 FASES DESARROLLO SOFTWARE 03

INFORMACIÓN
ESTADÍSTICAS
RÉCORDS
Título del test:
ENTORNOS DE DESARROLLO TEMA1 FASES DESARROLLO SOFTWARE 03

Descripción:
E.D.D. ENTORNOS DE DESARROLLO G.SUPERIOR D.A.M.

Autor:
AVATAR
Alberto Martínez Meco Lizcano
(Otros tests del mismo autor)


Fecha de Creación:
09/10/2019

Categoría:
Informática
Sigue en facebook las noticias y los mejores tests de daypo apretando en 'Me gusta'
Últimos Comentarios
No hay ningún comentario sobre este test.
Temario:
¿Como es el esquema de las fases del desarrollo de una aplicación software del modelo en cascada? Análisis-Diseño-Codificación-Pruebas-Mantenimiento Análisis-Diseño-Implementación-Pruebas-Codificación Análisis-Desarrollo-Codificación-Pruebas-Mantenimiento.
¿A que modelo de desarrollo pertenece este enunciado? "En este modelo las etapas para el desarrollo de software tienen un orden; de tal forma que, para empezar una etapa, es necesario finalizar la etapa anterior. Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente. Este modelo tiene distintas variantes por ejemplo la que produce una realimentación entre etapas." Modelo en Cascada. Modelo Iterativo Incremental. Modelo en Espiral. Modelo en V.
¿A que modelo de desarrollo pertenece este enunciado? "Está basado en varios ciclos cascada realimentados aplicados repetidamente. Este modelo entrega el software en partes pequeñas, pero utilizables, llamadas incrementos. En general, cada incremento se construye sobre aquel que ya ha sido entregado." Modelo en Cascada. Modelo Iterativo Incremental. Modelo en V. Modelo en Espiral.
¿A que modelo de desarrollo pertenece este enunciado? "Este modelo combina el modelo cascada con el modelo iterativo de construcción de prototipos. Cada ciclo está formado por cuatro fases y, cuando termina, produce una versión incremental del software con respecto al ciclo anterior. En este aspecto se parece al modelo iterativo incremental con la diferencia de que en cada ciclo se tiene en cuenta el análisis de riesgos." Modelo en Cascada. Modelo en Espiral. Modelo Iterativo Incremental. Modelo en V.
¿A que modelo de desarrollo pertenece este enunciado? "Es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. En él se describen las actividades y resultados que deben producirse durante el desarrollo del producto. El lado izquierdo representa la descomposición de las necesidades y la creación de las especificaciones del sistema. El lado derecho representa la integración de las piezas y su verificación. Es muy similar al modelo de cascada, ya que es muy rígido y contiene una gran cantidad de iteraciones." Modelo en Cascada. Modelo en V. Modelo en Espiral. Modelo Iterativo Incremental.
¿Como es el esquema de las fases del desarrollo de una aplicación software del modelo iterativo incremental? Análisis-Diseño-Código-Pruebas (todos estos pasos en incrementos) Análisis-Diseño-Código-Implementación (todos estos pasos en incrementos) Análisis-Desarrollo-Código-Pruebas (todos estos pasos en incrementos).
¿Como es el esquema de las fases del desarrollo de una aplicación software del modelo en espiral? Determinar objetivos -Análisis del riesgo - Desarrollar y probar - Planificación Determinar objetivos - Análisis del riesgo - Desarrollar e Implementar -Planificación Análisis - Determinar objetivos - Desarrollar y probar - Planificación.
En las fases del desarrollo de una aplicación software ¿este modelo en V es correcto? verdadero falso.
Al realizar un proyecto, la parte más importante es entender qué se quiere realizar y analizar las posibles alternativas y soluciones. Por ello, es fundamental analizar los requisitos que el cliente ha solicitado. Dentro del Análisis indica las distintas técnicas que se usaran para tener una buena comunicación entre el cliente y los desarrolladores: Entrevistas - Desarrollo conjunto de aplicaciones (JAD) - Planificación conjunta de requisitos (JRP). Brainstorming - Prototipos - Casos de Uso. Ambas respuestas son corretas.
Dentro del Análisis ¿que son los requisitos funcionales de un sistema software? Nos describen al detalle la función que realiza el sistema, la reacción ante determinadas entradas y cómo se comporta en distintas situaciones. Los requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes del mismo, como la fiabilidad o la capacidad de almacenamiento. Técnica que se basa en la representación de lo que queremos que haga el sistema. Describe qué hace el sistema, pero no cómo lo hace.
Dentro del Análisis ¿que son los requisitos NO funcionales de un sistema software? Los requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes del mismo, como la fiabilidad o la capacidad de almacenamiento. Nos describen al detalle la función que realiza el sistema, la reacción ante determinadas entradas y cómo se comporta en distintas situaciones. Técnica que se basa en la representación de lo que queremos que haga el sistema. Describe qué hace el sistema, pero no cómo lo hace.
¿A que diagrama de flujo representa esta imagen? Diagramas de flujo de datos (DFD). Diagramas de flujo de control (DFC). Diagrama Entidad/Relación (DER). Diagramas de transición de estados (DTE).
¿A que diagrama de flujo representa esta imagen? Diagramas de flujo de control (DFC). Diagramas de transición de estados (DTE). Diagrama Entidad/Relación (DER). Diagramas de flujo de datos (DFD).
Nos referimos a Diccionario de datos (DD) como la descripción detallada de los datos utilizados por el sistema que gráficamente están representados por los flujos de datos y almacenes presentes sobre el conjunto de DFD y es fundamental que todo lo que se realice quede plasmado en el documento “Especificación de Requisitos de Software (ERS)”. verdadero falso.
Dentro del Análisis de un sistema existen los Diagramas de Flujo, marca los correctos con su definición: Diagramas de flujo de datos (DFD). Nos va a representar el flujo de datos entre procesos (identifican funciones), entidades externas (componentes que no son del sistema) y almacenes del sistema (datos desde el punto de vista estático). Diagramas de flujo de control (DFC). Similar al DFD, pero en vez de flujo de datos muestra el flujo de control. Diagramas de transición de estados (DTE). Representación de cómo se comporta el sistema ante acciones externas. Diagrama Entidad/Relación (DER). Se usa para representar datos y sus relaciones. Diagrama de Flujo de Datos Obtenidos (DFDO). Diagrama que usa los datos obtenidos en el DFD y los combina con el DER.
¿Que respuesta se refiere al diseño de un sistema software estructurado? Basado en el flujo de datos a través del sistema. Produce un modelo de diseño con cuatro elementos: Diseño de datos, Diseño arquitectónico, Diseño de la interfaz y Diseño a nivel de componentes (diseño procedimental). Basado en el conjunto de objetos con propiedades y comportamientos, además de eventos que activan operaciones que modifican el estado de los objetos. Ambas respuestas son incorrectas.
¿Que respuesta se refiere al diseño de un sistema software orientado a objetos? Basado en el flujo de datos a través del sistema. Produce un modelo de diseño con cuatro elementos: Diseño de datos, Diseño arquitectónico, Diseño de la interfaz y Diseño a nivel de componentes (diseño procedimental). Basado en el conjunto de objetos con propiedades y comportamientos, además de eventos que activan operaciones que modifican el estado de los objetos. Ambas respuestas son correctas.
Para realizar el diseño estructurado o diseño orientado a objetos usaremos algunas herramientas básicas, marcas las correctas: Diagramas de flujo. Diagrama de cajas. Tablas de decisión. Pseudocódigo. Diagrama de expansión.
Marca las 4 capas del diseño de software orientado a objetos (DOO): Subsistema: funciones y procedimientos que realizan las acciones del sistema principal. Clases y objetos: en esta capa se indica la arquitectura de objetos global y la jerarquía de clases que hacen falta para implementar un sistema. Mensajes: indica cómo se realiza la colaboración entre objetos. Responsabilidades: operaciones y atributos que identifican a cada clase. Comentarios: contendrá solo información que sea relevante para la lectura y comprensión del programa.
La Codificación es la tercera fase, una vez realizado el diseño. Aquí el programador se encarga de recibir los datos del diseño y transformarlo en lenguaje de programación. A estas instrucciones las llamaremos código fuente. Escoge las series de normas que se siguen al programar en código Java: Nombre de ficheros-Organización de ficheros-Indentación-Comentarios-Declaraciones-Sentencias-Separaciones-Nombres. Nombre de ficheros-Organización de ficheros-Identación-Separaciones-Nombres. Nombre de ficheros-Organización de ficheros-Comentarios-Declaraciones.
En esta imagen a que esquema nos referimos: A un CASO DE USO que es una técnica definida por UML (del inglés Unified Modeling Language) y se basa en la representación de lo que queremos que haga el sistema. Describe qué hace el sistema, pero no cómo lo hace. A PROTOTIPOS que es una versión inicial del sistema en el que se puede ver el problema y sus posibles soluciones. Se puede desechar o usar para añadir más cosas.
En cualquier proyecto que se trabaje con un grupo de personas habrá que tener unas normas de codificación y estilo que sean sencillas, claras y homogéneas, las cuales nos facilitará la corrección en caso de que sea otra persona la que lo ha realizado: Los archivos de código fuente tendrán como extensión .java o .css Se usarán 4 espacios como unidad de indentación. Longitud de líneas de código no superior a 80 caracteres. Longitud de líneas de comentarios no superior a 70 caracteres.
Al iniciar la etapa de pruebas ya contaremos con el software, por lo que trataremos de encontrar errores en la codificación en la especificación o en el diseño. Al iniciar la etapa de pruebas ya contaremos con el software, por lo que trataremos de encontrar errores en la codificación en la especificación o en el diseño, marca las distintas tareas que utilizaremos: Verificación: conjunto de actividades que permiten comprobar si el producto se está construyendo correctamente. Validación: acciones para comprobar si el producto es correcto y si se ajusta a los requisitos del cliente. Finalización: ejecutaremos el compilador para depurar los últimos errores.
Para la realización del Diseño de Pruebas se usan técnicas como de caja blanca y prueba de caja negra. La primera valida la estructura interna del sistema y, la segunda, los requisitos funcionales sin observar el funcionamiento interno del programa. No son pruebas excluyentes y podemos combinarlas para descubrir distintos tipos de error. También existen pruebas nube que empieza de las pruebas mas bajas a las pruebas mas amplias para hacer un conjunto de todas las pruebas que hemos hecho en un proyecto. ¿Son correctas todas estas pruebas en la parte de Diseño? verdadero falso.
Denunciar test Condiciones de uso
Usamos cookies para personalizar su experiencia. Si sigue navegando estará aceptando su uso. Más información.