EGEL Plus Ingeniería de Software flashcards

33 cards. Read the term and the definition here. The deck at the top of this page is optional.

Requerimiento funcional

Declaración de una capacidad o comportamiento que el sistema debe proporcionar. Se especifica con entradas, proceso y salida esperada, y se verifica mediante pruebas funcionales y de aceptación.

Requerimiento no funcional

Restricción sobre cómo el sistema realiza sus funciones (rendimiento, seguridad, usabilidad, disponibilidad). Debe expresarse con métricas medibles y verificables, no con adjetivos vagos.

Caso de uso

Descripción de una interacción entre un actor y el sistema para lograr un objetivo. Incluye flujo principal, flujos alternativos, precondiciones y postcondiciones, y se representa con diagramas UML de casos de uso.

Historia de usuario

Requerimiento expresado como 'Como rol, quiero acción para beneficio'. Es breve, centrada en el usuario y se complementa con criterios de aceptación verificables, a menudo en formato Given-When-Then.

Principio de responsabilidad única

Cada clase debe tener una sola razón para cambiar, es decir, una única responsabilidad. Se detecta cuando una clase es solicitada por actores distintos con intereses diferentes, lo que aumenta el acoplamiento.

Cohesión y acoplamiento

La cohesión mide cuán relacionadas están las responsabilidades dentro de un módulo (alta es deseable). El acoplamiento mide las dependencias entre módulos (bajo es deseable). Juntos guían la modularidad del diseño.

Diagrama de clases UML

Modelo estático que muestra clases, atributos, métodos y relaciones: herencia, asociación, agregación y composición. La composición implica ciclo de vida dependiente; la agregación no.

Ley de Demeter

Un objeto solo debe comunicarse con sus colaboradores directos, evitando cadenas de llamadas como a.getB().getC().hacer(). Reduce el acoplamiento y facilita el mantenimiento y las pruebas.

Prueba unitaria

Verificación aislada de una unidad de código (método o clase) usando dobles de prueba para simular dependencias. Es rápida, repetible y sirve como documentación ejecutable del comportamiento esperado.

Prueba de integración

Prueba que verifica la interacción entre módulos o entre el sistema y recursos externos como bases de datos o servicios. No aísla dependencias; busca fallos en las interfaces y contratos.

Desarrollo guiado por pruebas

Ciclo rojo-verde-refactor: se escribe primero una prueba que falla, luego el código mínimo para pasarla y finalmente se refactoriza. Produce diseño emergente y una suite de regresión desde el inicio.

Partición de equivalencia

Técnica de caja negra que divide las entradas en clases donde se espera el mismo comportamiento. Se prueba un valor representativo por clase, reduciendo el número de casos sin perder cobertura.

Análisis de valores límite

Técnica que prueba valores en las fronteras de los rangos de entrada, como a-1, a, b y b+1 para un rango [a,b]. Los errores suelen concentrarse en los límites de las condiciones.

Complejidad ciclomática

Métrica de McCabe: V(G) = E - N + 2P, equivalente al número de regiones del grafo o al número de decisiones más uno. Indica el número mínimo de caminos independientes a probar.

Cobertura de código

Porcentaje del código ejecutado por la suite de pruebas. La cobertura de sentencias mide líneas ejecutadas; la de ramas exige evaluar ambas salidas de cada decisión y es más estricta.

Prueba de regresión

Conjunto de casos que se reejecuta tras un cambio para asegurar que la funcionalidad existente sigue funcionando. Se automatiza y prioriza según el riesgo de las áreas modificadas.

Ruta crítica

Secuencia de actividades con holgura total cero que determina la duración mínima del proyecto. Cualquier retraso en una actividad crítica retrasa la fecha de fin del proyecto.

Holgura total

Tiempo que una actividad puede retrasarse sin afectar la fecha de fin del proyecto. Se calcula como LS - ES o LF - EF; si es cero, la actividad es crítica.

Valor ganado

Técnica de control que compara valor planificado (PV), valor ganado (EV) y costo real (AC). CV = EV - AC mide desviación de costo; SV = EV - PV mide desviación de cronograma.

Índice de desempeño de costo

CPI = EV / AC. Un valor menor que 1 indica que se gasta más de lo presupuestado para el trabajo realizado; mayor que 1 indica eficiencia favorable en costos.

Velocidad del equipo

Cantidad de puntos de historia completados por iteración. Se usa para pronosticar la duración: backlog total dividido entre la velocidad promedio histórica del equipo.

Scrum

Marco ágil con roles Product Owner, Scrum Master y equipo; eventos Sprint Planning, Daily, Review y Retrospective; artefactos Product Backlog, Sprint Backlog e Incremento. Itera en sprints de duración fija.

Gestión de riesgos

Proceso de identificar, analizar y responder a riesgos. Se priorizan por probabilidad por impacto y se responde con estrategias de evitar, mitigar, transferir o aceptar.

Ley de Brooks

Añadir personal a un proyecto de software tardío lo retrasa aún más, debido al costo de comunicación y a la curva de aprendizaje de los nuevos integrantes.

Atributo de calidad

Propiedad medible del sistema como disponibilidad, modificabilidad o rendimiento. Se documenta con escenarios de calidad de seis partes: fuente, estímulo, artefacto, entorno, respuesta y medida.

Arquitectura en capas

Estilo donde cada capa solo depende de la inmediata inferior. Facilita la sustitución y el aislamiento de cambios, pero puede añadir latencia y capas vacías si no se diseña con cuidado.

Patrón MVC

Separa Modelo (datos y lógica de negocio), Vista (presentación) y Controlador (gestión de entrada). Reduce el acoplamiento entre interfaz y lógica, y permite múltiples vistas sobre el mismo modelo.

ISO/IEC 25010

Estándar de calidad de producto software que define ocho características: adecuación funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad, seguridad, mantenibilidad y portabilidad.

CMMI

Modelo de madurez de procesos con cinco niveles: 1 Inicial, 2 Gestionado, 3 Definido, 4 Gestionado cuantitativamente y 5 En optimización. Cada nivel exige prácticas específicas verificables.

Modelo en V

Modelo de ciclo de vida donde cada fase de desarrollo tiene una fase de prueba correspondiente: requisitos con aceptación, diseño con integración y diseño detallado con pruebas unitarias.

Deuda técnica

Costo futuro de mantener una solución rápida o incompleta. Se hace explícita en el backlog, se prioriza su pago y se controla con métricas como complejidad y cobertura de pruebas.

Revisión de código

Inspección formal o informal del código por pares con roles definidos y lista de verificación. Detecta defectos antes de las pruebas y difunde estándares de codificación en el equipo.

Escenario de calidad

Especificación de seis partes: fuente, estímulo, artefacto, entorno, respuesta y medida de la respuesta. Hace verificable un atributo de calidad y guía las decisiones arquitectónicas.