Generado con IA · Supuesto práctico

Ingeniería del software: análisis y diseño de un gestor de incidencias TIC

Caso único con preguntas Informática Comunidad Valenciana

Descargar:

Supuesto práctico generado por la IA de OposicionesIA, con su orientación y solución modelo más abajo. Dentro de la plataforma, además, puedes resolverlo y recibir una corrección con rúbrica y nota.

Ingeniería del software: análisis y diseño de un gestor de incidencias TIC

Contexto

El IES «Misericòrdia» (Borriana) encarga al departamento de Informática una aplicación para gestionar las incidencias TIC del centro. El profesorado abre incidencias (equipo, aula, descripción, prioridad); el coordinador TIC las asigna a un técnico; el técnico las resuelve y las cierra. Trabajamos el análisis y diseño con notación UML, en el marco del módulo «Entornos de Desarrollo».

Cuestiones

1. Casos de uso. Identifica los actores y elabora (descríbelo con precisión) el diagrama de casos de uso del sistema. Incluye al menos una relación <<include>> o <<extend>> justificada (p. ej. «notificar al profesor» como extensión de «cerrar incidencia»).

2. Diagrama de clases. Diseña el diagrama de clases con las entidades principales (Incidencia, Usuario/Tecnico, Equipo, Aula, Estado…), sus atributos, métodos relevantes y las relaciones (asociación, agregación/composición, herencia) con sus multiplicidades. Justifica el uso de una jerarquía de herencia si la introduces.

3. Ciclo de vida. El centro quiere una primera versión funcional pronto y prevé cambios frecuentes en los requisitos durante el curso. Argumenta qué modelo de ciclo de vida elegirías (p. ej. iterativo-incremental / ágil frente a cascada) y por qué, citando ventajas e inconvenientes para este contexto.

4. Detectar incoherencias. Un compañero propone este modelo relacional simplificado. Detecta y corrige las incoherencias de diseño (al menos tres): claves mal planteadas, cardinalidades imposibles o redundancias.

Incidencia(id, descripcion, prioridad, nombre_tecnico, telefono_tecnico, aula)
Tecnico(nombre, telefono)
Equipo(num_serie, aula, id_incidencia)   -- un equipo solo puede tener UNA incidencia en toda su vida

Pista: piensa en qué pasa cuando un técnico cambia de teléfono, cuándo un equipo tiene varias incidencias a lo largo del curso, y cómo debería referenciarse al técnico desde la incidencia.

5. Estimación y planificación. Propón una descomposición en tareas del proyecto y una estimación temporal sencilla (p. ej. con un diagrama de Gantt descrito o puntos de historia). Indica un hito de entrega mínima viable (MVP).

Orientación cómo resolverlo por tu cuenta

Cuestión 1 (Casos de uso). Recuerda que un caso de uso modela QUÉ hace el sistema, no cómo. Identifica primero los actores (humanos y, si procede, el sistema de correo como actor secundario) y luego un caso de uso por cada objetivo de negocio del enunciado. La clave está en distinguir <<include>> (comportamiento obligatorio que se factoriza y reutiliza, p. ej. autenticarse) de <<extend>> (comportamiento opcional/condicional que se añade en un punto de extensión). Error típico: usar <<include>> donde debería ir <<extend>>, dibujar el login como caso de uso de cada actor en lugar de incluirlo, o confundir actores con roles del departamento.

Cuestión 2 (Clases). No copies el modelo de datos: en clases hay métodos y la herencia se justifica por reutilización + sustituibilidad (Liskov). Piensa qué es jerarquía (Usuario→Profesor/CoordinadorTIC/Tecnico) y qué es asociación. Distingue agregación (Aula «tiene» Equipos, viven sin el aula) de composición (vida ligada). Pon multiplicidades en AMBOS extremos y navegabilidad. Considera modelar Estado con un enum o con patrón State. Error típico: olvidar multiplicidades, meter claves foráneas (eso es del modelo relacional, no del de clases).

Cuestión 3 (Ciclo de vida). Conecta los DOS datos del enunciado —«versión funcional pronto» + «cambios frecuentes»— con las propiedades de cada modelo. Argumenta por descarte: por qué cascada falla aquí (requisitos no estables, entrega tardía) y por qué iterativo-incremental/ágil encaja. Cita ventajas E inconvenientes (no vendas humo). Menciona un marco concreto (Scrum) y entregas por sprint.

Cuestión 4 (Incoherencias). Aplica normalización: busca dependencias transitivas (datos del técnico dentro de Incidencia → anomalías de actualización), referencias por atributo descriptivo en vez de por clave, y cardinalidades imposibles frente al dominio (un equipo con varias incidencias a lo largo del curso). Da AL MENOS TRES y corrígelas con el esquema reescrito y las claves bien puestas. Error típico: detectarlas pero no proponer el esquema corregido.

Cuestión 5 (Estimación). Descompón en una WBS de fases reales, estima (story points o jornadas), define el MVP mínimo defendible (abrir/asignar/cerrar) y plásmalo en un Gantt descrito con hitos.

Solución modelo respuesta completa — intenta resolverlo antes de mirar

Cuestión 1 — Diagrama de casos de uso

Actores. Tras analizar el enunciado se identifican:

Profesor/a (actor primario): abre incidencias.
Coordinador/a TIC (actor primario): asigna incidencias a técnicos y supervisa.
Técnico/a (actor primario): resuelve y cierra incidencias.
Sistema de Correo/Notificaciones (actor secundario): recibe la petición de notificar al profesor.

Conviene modelar una jerarquía de actores: Usuario es un actor abstracto del que heredan Profesor, Coordinador TIC y Técnico (todos se autentican), porque comparten el caso de uso de iniciar sesión.

Casos de uso (descripción del diagrama):

Relaciones justificadas:

<<include>> (obligatoria y reutilizada): «Abrir incidencia», «Asignar incidencia» y «Cerrar incidencia» incluyen siempre «Autenticarse». Se factoriza porque es comportamiento común y obligatorio a varios casos de uso (DRY). El caso base SIEMPRE ejecuta el incluido.
<<extend>> (opcional/condicional): «Notificar al profesor» extiende «Cerrar incidencia» en un punto de extensión (tras marcar como cerrada), bajo la condición de extensión {el profesor solicitante tiene notificaciones activas}. Es opcional: la incidencia se puede cerrar sin notificar, por eso es extensión y no inclusión.

Justificación de la elección: include modela una factorización obligatoria (siempre ocurre); extend modela una variación opcional que enriquece un caso base que es válido por sí solo. Confundirlos es el error más penalizado en esta cuestión.

Cuestión 2 — Diagrama de clases

Relaciones y multiplicidades:

Herencia (generalización): Profesor, CoordinadorTIC y Tecnico heredan de Usuario. Justificación: comparten estado (id, nombre, email, login) y el método autenticar(); satisfacen el LSP (donde se espera un Usuario puede usarse cualquier subtipo). Evita duplicar atributos y permite tratar a todos como usuarios autenticables. Si los roles fueran muy cambiantes (un mismo usuario es profesor y técnico) sería preferible composición de roles sobre herencia; con roles fijos del enunciado, la jerarquía es correcta.
Asociación Profesor 1 — 0..* Incidencia (rol solicitante): un profesor abre muchas incidencias; cada incidencia tiene un único profesor solicitante.
Asociación Tecnico 0..1 — 0..* Incidencia (rol responsable): una incidencia puede no tener técnico aún (0..1); un técnico atiende muchas (0..*).
Asociación Incidencia 0..* — 1 Equipo: cada incidencia afecta a un equipo; un equipo puede acumular muchas incidencias a lo largo del curso.
Agregación Aula ◇— Equipo (1 — 0..*): el aula «contiene» equipos, pero es agregación (rombo hueco), no composición: si se elimina el aula los equipos pueden reubicarse (su ciclo de vida no depende del aula).
Incidencia — Aula (0..* — 1): se puede derivar (el aula es la del equipo) o modelar directa; se incluye por consulta frecuente.
Estado y Prioridad se modelan como enum. Si la lógica de transiciones fuera compleja, se justificaría el patrón State (clase Estado abstracta con subclases por estado y método siguiente()).

Cuestión 3 — Modelo de ciclo de vida

Elección: modelo iterativo-incremental, concretado con un marco ágil (Scrum).

Los dos requisitos del enunciado son determinantes:

«Primera versión funcional pronto» → exige entregar valor temprano, lo que descarta los modelos secuenciales.
«Cambios frecuentes en los requisitos durante el curso» → exige absorber cambios sin replanificar todo.

Por qué NO cascada: la cascada asume requisitos estables y completos al inicio, congela el alcance y entrega software solo al final. Con requisitos volátiles, cualquier cambio obliga a retroceder fases (caro y rígido) y el centro no vería nada funcional hasta tarde. Ventaja teórica (documentación y trazabilidad), pero inadecuada aquí.

Por qué SÍ iterativo-incremental / ágil (Scrum):

	Iterativo-incremental / ágil	Cascada
Entrega temprana	Sí, por incrementos (sprints 2-4 sem.)	No, solo al final
Adaptación a cambios	Alta (replanificación por sprint)	Baja
Feedback del cliente	Continuo (revisión de sprint)	Tardío
Riesgo	Se reduce pronto	Se acumula al final

Ventajas para este contexto: MVP usable en pocas semanas; el coordinador TIC valida cada incremento y reorienta el backlog; el riesgo técnico se mitiga pronto; se prioriza por valor.

Inconvenientes a reconocer (honestidad técnica): requiere disponibilidad continua del «product owner» (coordinador TIC), menor documentación formal por defecto, estimación más difícil del alcance total y disciplina del equipo. Aun así, el balance favorece claramente lo ágil para un proyecto pequeño, evolutivo y con cliente accesible dentro del propio centro.

Cuestión 4 — Detección y corrección de incoherencias

Esquema propuesto por el compañero:

Incidencia(id, descripcion, prioridad, nombre_tecnico, telefono_tecnico, aula)
Tecnico(nombre, telefono)
Equipo(num_serie, aula, id_incidencia)

Incoherencias detectadas:

Redundancia / dependencia transitiva en Incidencia: nombre_tecnico y telefono_tecnico son atributos del técnico embebidos en la incidencia (viola 3FN: dependen de la clave del técnico, no de id). Si un técnico cambia de teléfono hay que actualizar TODAS sus incidencias → anomalía de actualización. Además, referenciar al técnico por su nombre es frágil (nombres duplicados, sin clave estable).
Cardinalidad imposible en Equipo: id_incidencia dentro de Equipo impone que cada equipo tenga una sola incidencia en toda su vida. El dominio dice lo contrario (un equipo sufre varias incidencias a lo largo del curso). La relación es 1 equipo → N incidencias, y se modela con la FK en el lado «muchos» (en Incidencia), no en Equipo.
Clave/redundancia en Tecnico y referencia incorrecta: Tecnico no tiene clave artificial estable; usa nombre como identificador implícito (no único, no inmutable). Falta un id_tecnico. Además Incidencia debe referenciar al técnico por clave foránea (id_tecnico), no copiando sus datos.
(Adicional) Redundancia de aula: el aula aparece en Incidencia y en Equipo. Si la incidencia es sobre un equipo y el equipo ya está en un aula, Incidencia.aula es derivable y puede contradecir a Equipo.aula → mejor mantenerla solo en Equipo (o como Aula propia con su clave) y derivarla.

Esquema corregido (claves primarias subrayadas con PK, foráneas marcadas FK, normalizado a 3FN):

Aula( _id_aula (PK)_, codigo, nombre )

Tecnico( _id_tecnico (PK)_, nombre, telefono, especialidad )

Equipo( _num_serie (PK)_, tipo, modelo,
        id_aula (FK -> Aula) )

Incidencia( _id (PK)_, descripcion, prioridad, estado,
            fecha_apertura, fecha_cierre,
            num_serie (FK -> Equipo),
            id_tecnico (FK -> Tecnico)  NULL,   -- NULL mientras no esté asignada
            id_profesor (FK -> Usuario) )

Justificación: cada hecho se almacena una sola vez (3FN); el teléfono del técnico vive solo en Tecnico (sin anomalías); un equipo soporta N incidencias porque la FK num_serie está en el lado «muchos» (Incidencia); el aula es única (en Equipo) y derivable para la incidencia; todas las relaciones usan claves estables, no atributos descriptivos.

Cuestión 5 — Estimación y planificación

Descomposición en tareas (WBS) y estimación (puntos de historia + jornadas orientativas):

Fase / Tarea	Entregable	Estimación
T1 Análisis: casos de uso + backlog	Documento de requisitos	3 SP (~2 j)
T2 Diseño: clases + modelo de datos	Diagramas UML + DDL	5 SP (~3 j)
T3 Base de datos + entidades/ORM	Esquema migrado	3 SP (~2 j)
T4 Login y gestión de usuarios/roles	Autenticación	5 SP (~3 j)
T5 Abrir incidencia (profesor)	Form + persistencia	5 SP (~3 j)
T6 Asignar (coordinador TIC)	Asignación a técnico	3 SP (~2 j)
T7 Resolver y cerrar (técnico)	Cambio de estados	3 SP (~2 j)
T8 Notificación al profesor (extend)	Email al cerrar	2 SP (~1 j)
T9 Panel/consultas y estadísticas	Listados y filtros	5 SP (~3 j)
T10 Pruebas + despliegue + documentación	App desplegada	5 SP (~3 j)

Diagrama de Gantt descrito (sprints de 2 semanas):

Hito MVP (entrega mínima viable, fin del Sprint 2 / semana 4): el sistema permite el flujo de negocio completo end-to-end: el profesor abre una incidencia, el coordinador la asigna a un técnico y el técnico la cierra (T4+T5+T6+T7 básico, con login). Es el conjunto mínimo que aporta valor real al centro y permite recoger feedback. Las notificaciones, el panel de estadísticas y los refinamientos se entregan en incrementos posteriores, coherente con el ciclo de vida iterativo-incremental elegido en la Cuestión 3.

Practica con supuestos como este

Genera supuestos de tu especialidad y comunidad en cualquiera de los cuatro formatos, resuélvelos y recibe corrección con nota al instante.

Crear cuenta Ver planes

Ingeniería del software: análisis y diseño de un gestor de incidencias TIC

Contexto

Cuestiones

Cuestión 1 — Diagrama de casos de uso

Cuestión 2 — Diagrama de clases

Cuestión 3 — Modelo de ciclo de vida

Cuestión 4 — Detección y corrección de incoherencias

Cuestión 5 — Estimación y planificación

Practica con supuestos como este

🍪 Esta web usa cookies

Configuración de cookies