EGEL Plus Ingeniería de Software study materials
EGEL Plus Ingeniería de Software study resources

EGEL Plus Ingeniería de Software: Análisis y diseño de software

EGEL Plus Ingeniería de Software · Work through your exam, one topic at a time.

All guide sections

Análisis y diseño de software

Qué debe dominar el sustentante

El análisis traduce necesidades a un modelo comprensible; el diseño la convierte en una solución estructurada. Debe distinguir requerimientos funcionales (qué hace el sistema) de no funcionales (rendimiento, seguridad, usabilidad) y reconocer requerimientos del usuario frente a requerimientos del sistema. En modelado, domine los diagramas UML de casos de uso, clases, secuencia y estados, y sepa qué representa cada uno: los casos de uso capturan actores y objetivos, no flujos internos; la secuencia muestra interacción temporal entre objetos; las clases describen estructura y relaciones (asociación, agregación, composición, herencia).

También se evalúan principios de diseño: cohesión alta, acoplamiento bajo, encapsulamiento, abstracción y separación de responsabilidades. Reconozca patrones de diseño básicos (creacionales, estructurales, de comportamiento) por su intención, no por su estructura exacta.

Trampas frecuentes

  • Confundir agregación (relación débil, el todo no posee la parte) con composición (el todo controla el ciclo de vida de la parte).
  • Marcar un requerimiento no funcional como funcional solo porque menciona una acción (“el sistema debe responder en 2 segundos” es no funcional).
  • Asumir que un diagrama de casos de uso define el orden de pasos; eso corresponde a escenarios o diagramas de actividad/secuencia.
  • Elegir un patrón por popularidad y no por el problema que resuelve.

Ejemplo trabajado

Enunciado: “El sistema debe permitir registrar pedidos y notificar al cliente en menos de 5 segundos”. El registro es funcional; el tiempo de respuesta es no funcional (rendimiento). Si además se pide que un pedido no exista sin cliente, eso es una regla de negocio del modelo de clases: la relación Pedido–Cliente sería una asociación con multiplicidad 1..* a 1.

Regla práctica: ante cualquier enunciado, pregunte primero “¿describe comportamiento o una cualidad del comportamiento?”. Esa sola pregunta separa funcional de no funcional en la mayoría de los reactivos.