WorksheetsCuestionario de Ingeniería de Software
Total questions: 52
Worksheet time: 29mins
No es un objetivo de la Ingeniería de Software
Maximizar la productividad
Minimizar riesgos
Maximizar la calidad
Minimizar el código
La portabilidad es un requisito:
Externo
Funcional
Del proceso
Del producto
La Ingeniería de Software
Incluye como una fase a la ingeniería de requerimientos
Se puede considerar una etapa de la Ingeniería de Requerimientos
Es una opción para el que no hace ingeniería de requerimientos
Es lo mismo que ingeniería de requerimientos
A la hora de construir software:
Es fundamental que los desarrolladores conozcan el problema
Lo conocerán sobre la marcha
No es decisivo
No necesitan conocerlo
Al avanzar por etapas de ingeniería de software:
Resulta más complejo solucionar un error
Más económico
Más rápido
Más fácil
No es actor principal en ingeniería de software
Vendedores de software
Desarrolladores
Clientes
Usuarios
Primer modelo de etapas de ingeniería
Modelo en cascada
Modelo en V
Espiral
Realista
La ingeniería de software
Comprende etapas de requerimientos
Solo etapas iniciales
Comprende todos los aspectos desde inicio hasta mantenimiento
Etapas finales
Los stakeholders:
Clientes
Personas sin conocimientos
Desarrolladores
Personas interesadas o afectadas por el sistema
No es etapa de Ingeniería de Requerimientos
Elicitación
Verificación
Codificación
Obtención
Especificación
No es fase de realización de entrevista
Terminación
Análisis
Desarrollo
Apertura
Durante una entrevista
El entrevistador hace preguntas para recabar info
No es necesario conocer el tema
Que hablen en términos generales
Preguntas sin preparar
Para reunir información de un grupo grande:
Cuestionario
Prototipo
Observación
Lluvia de ideas
Entrevista
Durante la etapa de análisis participan:
Usuarios y desarrolladores
Stakeholders
Encuestadores
Usuarios y clientes
Cliente y desarrollador
Se recomienda prototipos:
Cuando el costo de rechazo es muy alto
No hay dudas
Opiniones no necesarias
Comunicación fluida
No es función del análisis de requerimientos
Anotar requisitos
Indicar interfaz
Conocer elementos necesarios
Establecer restricciones (es diseño)
Técnica de sesiones conjuntas:
Escenarios
Lluvia de ideas
Etnografía
Entrevistas
JAD
Entrevistas abiertas:
Estructura jerárquica
El entrevistado guía la entrevista
Evaluación
No hay programa predefinido (semiabierta)
Durante una entrevista:
Si no es amable cortar
Es normal agresividad o rechazo
Entrevistador habla más
Mejor si es desconocido
Preparación de entrevista
Entrevistar a muchos
No pasar de 20 min
Informar al entrevistado del motivo
Usar preguntas abiertas siempre
Los requerimientos de usuario se expresan en:
Lenguaje programación
Científico
UML
Lenguaje natural
En un DFD, transforma datos:
Almacén
Entidad externa
Entidad interna
Proceso
Flujo
Modelo que representa comportamiento y cambios
Entidad-Relación
Caso de uso
Diagrama de estados
Clase
Herramientas de requisitos se dividen en:
Modelado de datos y modelado de procesos
ER y clases
DFD y casos de uso
Usuarios y desarrolladores
Características que identifican una entidad
Almacenes
Relaciones
Flujos
Atributos
Procesos
Una característica de los requisitos funcionales
Características que identifican una entidad
Almacenes
Relaciones
Flujos
Atributos
Procesos
Una característica de los requisitos funcionales:
Miden calidad
Describen qué debe hacer el sistema
Son externos
Son restricciones
Un requisito no funcional es:
Registrar usuario
Generar reporte
Tiempo de respuesta < 2s
Validar contraseña
La trazabilidad permite:
Corregir errores
Seguir requerimientos a través del proyecto
Definir arquitectura
Medir rendimiento
UML significa:
Universal Markup Language
Unified Modeling Language
Unit Model Language
Urban Modeling Language
Un caso de uso describe:
Estructura interna
Interacción entre actor y sistema
Base de datos
Procesos internos
En un caso de uso, el actor es:
Un proceso
Un archivo
Alguien que interactúa con el sistema
Un módulo
El diagrama ER modela:
Comportamiento
Datos y relaciones
Requisitos
Interfaces
Un atributo clave es:
Un proceso
Una relación
Identifica una entidad
Un flujo
Un flujo de datos representa:
Restricción
Movimiento de información
Actor
Fase del proyecto
Un prototipo sirve para:
Probar rendimiento
Probar hardware
Validar requerimientos
Validar algoritmos
La verificación de requisitos revisa:
Diseño
Código
Que los requisitos estén completos y correctos
Interfaz
Un requisito mal definido causa:
Mejores entregas
Retrasos y errores
Reducción de costos
Más productividad
El cliente debe participar en:
Codificación
Definición de requerimientos
Pruebas unitarias
Diseño técnico
Un modelo en espiral se centra en:
Estructura
Riesgos
Prototipos
Implementación
Ingeniería de requisitos busca:
Probar software
Entender necesidades del cliente
Escribir código
Hacer diagramas
La lluvia de ideas se usa para:
Validar código
Hacer testing
Generar ideas rápidamente
Crear diagramas
La observación se usa cuando:
No existen usuarios
No sirve en análisis
Se quiere ver usuarios en su ambiente real
No hay tiempo
Un requerimiento debe ser:
Ambiguo
Verificable y claro
Opcional
Variable
El documento SRS es:
Software Real System
Software Requirements Specification
System Report Software
Standard Reqs Set
El análisis estructurado usa:
Casos de uso
DFD
Diagramas 3D
Redes neuronales
La entrevista estructurada:
No tiene preguntas
Lleva preguntas planificadas
Es improvisada
La dirige el usuario
El diagrama de clases muestra:
Flujo de datos
Interfaces
Estructura de objetos y atributos
Reglas de negocio
Una relación 1:N significa:
Uno con uno
Uno con muchos
Muchos con muchos
Ninguna
El análisis funcional define:
Hardware
Funciones del sistema
Contabilidad
Servidores
Un requisito debe evitar:
Ser claro
Ser medible
Ambigüedades
Ser completo
