EGEL Plus Ingeniería de Software key terms

Enunciado que describe qué debe hacer un sistema: una capacidad, cálculo o comportamiento observable que el software debe proporcionar a sus usuarios o a otros sistemas.

Restricción o atributo de calidad que describe cómo debe comportarse el sistema, como rendimiento, seguridad, disponibilidad o usabilidad, en lugar de una función concreta.

Descripción breve de una necesidad escrita desde la perspectiva del usuario, normalmente con la forma rol, objetivo y beneficio, que sirve como base para conversar y priorizar el trabajo.

Condición verificable que debe cumplirse para que una historia o requerimiento se considere terminado; suele expresarse como escenarios concretos de entrada y resultado esperado.

Descripción de una interacción completa entre actores externos y el sistema para alcanzar un objetivo, incluyendo el flujo principal y las alternativas relevantes.

Persona, rol o sistema externo que interactúa con el software para obtener un resultado; se modela fuera de la frontera del sistema y origina casos de uso.

Modelo estático que muestra clases, sus atributos y operaciones, y las relaciones entre ellas como asociación, herencia o composición, para representar la estructura del dominio o del diseño.

Modelo de comportamiento que muestra, en orden temporal, los mensajes intercambiados entre objetos o componentes para realizar una operación o un escenario concreto.

Principio de diseño que oculta el estado interno de un objeto y expone solo una interfaz controlada, de modo que otros módulos no dependan de detalles de implementación.

Relación entre clases en la que una subclase reutiliza y especializa el comportamiento de una superclase, estableciendo una jerarquía de tipos con sustitución.

Capacidad de que objetos de distintos tipos respondan al mismo mensaje o interfaz con comportamientos propios, permitiendo tratar variantes de forma uniforme en el código cliente.

Grado en que los elementos de un módulo pertenecen a una misma responsabilidad; una cohesión alta indica que el módulo es enfocado y fácil de entender y mantener.

Grado de dependencia entre módulos; un acoplamiento bajo reduce el impacto de los cambios y facilita probar y reemplazar partes del sistema de forma independiente.

Solución general y reutilizable a un problema recurrente de diseño de software, documentada con su contexto, estructura, participantes y consecuencias, no como código listo para copiar.

Vista que relaciona actores con los casos de uso que el sistema les ofrece, delimitando el alcance funcional y las interacciones principales del sistema.

Transformación del código que mejora su estructura interna sin cambiar el comportamiento observable, reduciendo deuda técnica y facilitando cambios futuros.

Prueba automatizada que verifica el comportamiento de una unidad pequeña de código, como una función o clase, de forma aislada y rápida para detectar regresiones temprano.

Prueba que verifica la interacción entre dos o más componentes o sistemas, comprobando que las interfaces, datos y protocolos funcionan correctamente al combinarse.

Prueba ejecutada para confirmar que el sistema satisface los criterios acordados con el cliente o usuario, y que es apto para su entrega o puesta en uso.

Prueba del producto completo en un entorno representativo, orientada a validar requisitos funcionales y no funcionales de extremo a extremo.

Medida de la proporción del código, ramas o requisitos que ejercitan las pruebas; sirve para identificar zonas no verificadas, no como garantía de calidad por sí sola.

Técnica de prueba que deriva casos a partir de entradas y salidas esperadas sin conocer la estructura interna del código, usando particiones de equivalencia o valores límite.

Técnica de prueba que diseña casos a partir de la estructura interna del programa, como caminos, condiciones y ramas, para ejercitar el código de forma dirigida.

Práctica en la que se escribe primero una prueba automatizada que falla, luego el código mínimo para pasarla y finalmente se refactoriza, repitiendo el ciclo en incrementos pequeños.

Práctica de integrar los cambios de código en un repositorio compartido con frecuencia, ejecutando automáticamente compilación y pruebas para detectar fallos de forma temprana.

Sistema que registra el historial de cambios de archivos y permite trabajar en ramas, comparar versiones, revertir estados y coordinar a varias personas sobre el mismo código.

Costo futuro implícito que surge de elegir soluciones rápidas o incompletas hoy; si no se paga con refactorización y pruebas, encarece cada cambio posterior.

Contrato que define las operaciones que un componente ofrece a sus consumidores, ocultando la implementación y permitiendo sustituirla sin afectar al código que la usa.

Lista priorizada y en evolución de elementos pendientes de un producto, como historias, mejoras y correcciones, que alimenta la planificación de iteraciones.

Iteración de duración fija en la que un equipo produce un incremento terminado y potencialmente entregable, con objetivos y alcance acordados al inicio.

Marco de trabajo ágil basado en iteraciones cortas, roles definidos y eventos regulares, que organiza el trabajo en torno a un backlog y a la inspección y adaptación continuas.

Cantidad de trabajo, medida en unidades acordadas como puntos de historia, que un equipo completa por iteración; se usa para pronosticar, no para comparar equipos.

Secuencia de actividades dependientes más larga de un proyecto, cuya duración determina la fecha mínima de término y cuyo retraso retrasa todo el proyecto.

Representación gráfica de actividades en el tiempo que muestra duraciones, solapamientos y dependencias, útil para comunicar el plan y seguir el avance del cronograma.

Punto significativo del proyecto sin duración propia, usado para marcar la consecución de un resultado o la finalización de una fase y verificar el avance.

Proceso de identificar, analizar, priorizar y planificar respuestas a amenazas u oportunidades que pueden afectar los objetivos de alcance, tiempo, costo o calidad del proyecto.

Técnica de estimación relativa que asigna un valor de esfuerzo o complejidad a cada elemento del backlog comparándolo con referencias ya estimadas por el equipo.

Esquema de organización de alto nivel que define la estructura general de un sistema, sus componentes y sus relaciones, como capas, microservicios o arquitectura orientada a eventos.

Propiedad medible del sistema, como disponibilidad, seguridad, rendimiento o modificabilidad, que guía las decisiones arquitectónicas y debe expresarse con escenarios verificables.

Estilo arquitectónico que descompone el sistema en servicios pequeños, desplegables de forma independiente y comunicados por red, cada uno dueño de su lógica y datos.

Estilo que organiza el sistema en niveles con responsabilidades definidas, donde cada capa depende de la inferior mediante interfaces, favoreciendo la separación de preocupaciones.

Marco que define características y subcaracterísticas medibles de la calidad del software, como funcionalidad, fiabilidad, eficiencia y mantenibilidad, para evaluarlo de forma sistemática.

Examen sistemático de cambios por parte de otros desarrolladores para detectar defectos, verificar estándares y compartir conocimiento antes de integrar el trabajo.

Conjunto estructurado de actividades, roles y artefactos que un equipo sigue para transformar necesidades en software entregado, mantenido y evaluado.

Marco de referencia que describe niveles progresivos de formalización y mejora de los procesos de una organización, usado para evaluar capacidades y planificar mejoras.

Práctica que mantiene el software siempre en estado desplegable y automatiza la liberación a producción con validaciones, reduciendo el tiempo entre el cambio y su entrega.