Definición de proyecto y puesta en marcha - UniExtremadura/Proyecto26-27---GA03 GitHub Wiki
Práctica 1 - Semana 1
Definición de la empresa
InforEX es una empresa especializada en el desarrollo de proyectos software para entidades públicas.
La universidad de Extremadura ha contratado a InforEX con el objetivo de renovar y mejorar la actual página web de la universidad, mejorando así la experiencia de los usuarios de la página. En la página actual se puede encontrar información para todo lo relacionado con la universidad, pero muchos usuarios se quejan de que la página puede resultar ligeramente laberíntica a la hora de buscar información específica, procedimientos, profesores determinados...
Por lo tanto, el proyecto se centrará en realizar un "lavado de cara" a la página actual, renovando el sistema de navegación y búsqueda, y facilitando algunos procedimientos como el de solicitud de becas y matriculaciones.
Definición del equipo de trabajo
| Rol | Miembro | Coste/Hora | Justificación del coste |
|---|---|---|---|
| Product Owner | Pedro Fernández Germán | 35 €/hora | Perfil estratégico responsable de maximizar el valor y definir el alcance. Evita desarrollos innecesarios. |
| Tech Lead | Gonzalo Aparicio Ortiz | 40 €/hora | Máximo responsable de la arquitectura y viabilidad tecnológica. Mitiga riesgos y deuda técnica a largo plazo. |
| Scrum Master | Lucas Méndez Fernández | 35 €/hora | Perfil centrado en la facilitación, protección del proceso y eliminación de bloqueos. |
| DevOps / QA | Pablo Márquez Hernández | 35 €/hora | Rol especializado en automatización y control de calidad. Su coste se justifica por el ahorro económico de detectar errores en fases tempranas. |
| Developer | Francisco Javier Borox González | 30 €/hora | Fuerza base de desarrollo. Dedicación intensiva a la escritura de código apoyándose en las directrices técnicas. |
Planificación de capacidad.
Se ha planificado el desarrollo del proyecto bajo una metodología de Scrum, con sprints de una semana cada uno. Cada uno de los integrantes ha calculado las horas que puede dedicarle al proyecto cada día, teniendo en cuenta otros proyectos en los que participan y las horas que dedican al ocio y proyectos personales.
| Miembro | Horas diarias | Horas por sprint | Horas totales (5 sprints) |
|---|---|---|---|
| Pedro Fernández | 2h | 10h | 50h |
| Gonzalo Aparicio | 1,5h | 7,5h | 37,5h |
| Lucas Méndez Fernández | 2,2h | 11h | 55h |
| Pablo Márquez | 2,5h | 12,5h | 62,5h |
| Francisco Javier Borox | 2,9h | 14,5h | 72,5h |
Coste del proyecto.
Teniendo en cuenta las horas que cada integrante va a dedicar al proyecto y su tarifa, podemos definir un presupuesto aproximado de los costes del proyecto.
| Rol | Miembro | Horas totales | Tarifa horaria | Coste total |
|---|---|---|---|---|
| Product owner | Pedro Fernández | 50h | 35€/h | 1.750€ |
| Tech lead | Gonzalo Aparicio | 37,5h | 40€/h | 1.500€ |
| Scrum master | Lucas Méndez Fernández | 55h | 35€/h | 1.925€ |
| DevOps / QA | Pablo Márquez | 62,5h | 35€/h | 2.188€ |
| Developer | Francisco Javier Borox | 72,5h | 30€/h | 2.175€ |
Team charter.
Se han llegado a los siguientes acuerdos y decisiones en cuanto a la comunicación del grupo:
- Canal de comunicación síncrona: Reuniones presenciales y llamadas grupales de Discord.
- Canal de comunicación asíncrona: WhatsApp para la comunicación diaria entre integrantes del proyecto, con respuesta en menos de 24h, y Outlook para comunicaciones con agentes externos al grupo de desarrollo.
- Frecuencia y duración de reuniones: Una reunión a la semana de 9:30 a 11:30, pudiendo planear reuniones adicionales si fueran necesarias.
- Disponibilidad y procedimiento de ausencias: Cualquier ausencia debe ser justificada con un mínimo de 12 horas de antelación. Si un integrante no se comunicase con el resto del grupo en un lapso de 72 horas, se procederá a comunicarlo al profesor encargado. Si se volviera a repetir sin justificación, se expulsaría a dicha persona del grupo.
- Forma de tomar decisiones: Se plantearan las ideas al resto de integrantes y se tomará una decisión en consenso.
- Gestión de conflictos: Se priorizará aquello que la mayoría de integrantes consideren importante, pero las opiniones de los integrantes con más experiencia tendrán más peso que la de los integrantes con menos experiencia.
- Acuerdos de calidad: Una vez terminado el trabajo de una persona, esta lo presentará al resto de integrantes para comprobar su calidad.
- Señales de alerta y actuación asociada: En caso de que uno de los integrantes no pueda avanzar en su trabajo, y esto perjudique el avance de otro integrante, se avisará al grupo en un periodo de 24 horas para planificar una reunión en la que se solucionará el problema.
Épicas, requisitos e historias de husuario.
markdown
| Épica | Nombre | US | h-p (est.) | Rango (h-p) | Objetivos | Descripción | Historias |
|---|---|---|---|---|---|---|---|
EP-01 |
Simplificación de trámites | 4 | 19 | 14–24 | G-02, G-03, G-04 | Digitalización de los trámites académicos clave (matrícula, desmatriculación, becas con seguimiento de estado y descarga de documentos oficiales) en un flujo online guiado. | HU-01 a HU-04 |
EP-02 |
Facilitación de navegación | 4 | 3,5 | 0–6 | G-02, G-03, G-06, G-08 | Navegación clara con menús, migas de pan y buscador global, más acceso a la información de asignaturas, eventos y servicio CAUX. | HU-05 a HU-08 |
EP-03 |
Mejora de accesibilidad | 1 | 2 | 1–3 | G-04, G-05, G-06 | Cumplimiento de WCAG 2.1 AA en los formularios críticos, empezando por una solicitud ERASMUS accesible con seguimiento de fases. | HU-09 |
EP-04 |
Cambio de diseño | 4 | 15,5 | 11–20 | G-02, G-03, G-04 | Nueva guía de estilo y rediseño estético, directorio de perfiles y apps de escritorio y móvil. | HU-10 a HU-13 |
EP-05 |
Mejora de administración técnica | 4 | 32 (mín.) | 32+ | G-01, G-04, G-06, G-07, G-08 | Base técnica estable: autoguardado ante fallos, BD robusta con backups, alta disponibilidad (≥99,5 %) e integración con Outlook. | HU-14 a HU-17 |
| Total | 17 | 72 | 58+ |
Con esto podemos calcular la capacidad y el esfuerzo que se dispone y necesita el proyecto:
- Capacidad disponible: 277,5h en conjunto de todos los miembros del equipo para los sprints planificados.
- Esfuerzo necesario: 72h+ repartidas en los cinco sprints planificados.
Esto significa que se dispone de alrededor de 205,5h para gestionar imprevistos, mejorar partes ya terminadas, realizar pruebas, y cualquier cosa que mejore el proyecto en su conjunto.
Definition of Ready (DoR)
Una historia está preparada para entrar en un Sprint Backlog cuando:
- Tiene un identificador único y estable (
US-XXX) y una épica asociada (EP-XXX). - Está relacionada con al menos un objetivo del producto o del proyecto, con trazabilidad entre la necesidad, la historia y sus criterios de aceptación.
- Identifica al usuario o stakeholder y el valor esperado, con un alcance delimitado y sus principales exclusiones.
- Define criterios de aceptación claros, observables y verificables, incluyendo casos de error y casos límite cuando correspondan.
- Tiene prioridad MoSCoW justificada y una estimación consensuada en horas-persona.
- Identifica su grado de incertidumbre, sus dependencias y los requisitos predecesores necesarios.
- Recoge los requisitos no funcionales (usabilidad, accesibilidad, seguridad, privacidad) y las restricciones técnicas, organizativas y académicas aplicables.
- No tiene dudas abiertas que impidan comprenderla, estimarla o planificarla, y tiene documentados sus supuestos y riesgos conocidos.
La lista completa de comprobación se mantiene en docs/quality/definition-of-ready.md.
Definition of Done (DoD)
Una historia está terminada cuando:
- La funcionalidad está implementada conforme a la historia de usuario, respetando la arquitectura y los principios del proyecto.
- Se han verificado todos sus criterios de aceptación, incluidos los casos de error y las situaciones límite.
- Se han ejecutado las pruebas necesarias, que cubren el comportamiento esperado y las condiciones de error importantes.
- El cambio está integrado en la rama o entorno acordado, compila y funciona correctamente, sin regresiones críticas conocidas.
- Se han comprobado los requisitos no funcionales aplicables: seguridad, privacidad, usabilidad, accesibilidad, dispositivos y rendimiento.
- La documentación técnica y de usuario está actualizada y se mantiene la trazabilidad necesidad → requisito → historia → implementación → pruebas → validación.
- El trabajo ha sido revisado según el proceso acordado por el equipo, cumple
constitution.mdy los problemas detectados están resueltos o aceptados. - No queda ninguna incidencia ni defecto crítico o bloqueante abierto.
La lista completa de comprobación se mantiene en docs/quality/definition-of-done.md.
10. Auditoría de Requisitos y Trazabilidad de IA
De acuerdo con las normativas del proyecto, el catálogo inicial de requisitos fue sometido a una revisión crítica utilizando agentes especializados de IA (requirements-reviewer.agent.md).
El equipo analizará el informe de evaluación (versión v01) generado por el agente, tomando las decisiones sobre los bloqueos y riesgos detectados y garantizando que la autoridad sobre el producto recae siempre en los miembros humanos del equipo. La baseline revisada es Campus Virtual v1.0.
| Agente e ID | Entrada (Snapshot) | Propuesta / Riesgo Detectado | Justificación de la IA y del Equipo | Decisión del Equipo |
|---|---|---|---|---|
| requirements-reviewer (F01) | EP-01 a EP-05 (HU-01 a HU-17) y constitución | Acordar una convención única de identificadores y verificar todas las referencias entre épicas. | Las historias se titulan HU-01 a HU-17, pero la constitución exige el formato US-XXX. No queda claro si HU-05 y US-05 son la misma historia, lo que puede romper la trazabilidad entre necesidad, historia, criterio, dependencia y prueba. |
Aceptada |
| requirements-reviewer (F02) | EP-03 y objetivo G-05 |
Unificar el nivel de conformidad de accesibilidad y reflejarlo en criterios verificables. | EP-03 incluye WCAG 2.1 AA mientras que G-05 exige WCAG 2.2 AA; la épica no determina cuál se debe verificar. |
Aceptada |
| requirements-reviewer (F03) | HU-01, HU-03, HU-05, HU-06, HU-07, HU-08, HU-09, HU-11, HU-17 | Precisar resultados observables, condiciones de prueba y tratamiento de estados vacíos, carga, error y casos límite. | Criterios como "ficha completa", "FAQ con buscador", "al menos 4 fases" o "login SSO" permiten implementaciones distintas y debilitan la verificación objetiva. | Aceptada |
| requirements-reviewer (F04) | EP-04 (HU-12, HU-13) y EX-01 |
Aclarar si el alcance incluye aplicaciones instalables, experiencia web responsive o ambas, y alinear límites y prioridades. | EP-04 incluye apps de escritorio y móvil, HU-12 es Won't y HU-13 es Could, pero EX-01 excluye la app móvil nativa. HU-13 habla de diseño responsive, sin aclarar si es app nativa o web adaptable. |
Rechazada |
| requirements-reviewer (F05) | HU-03, HU-05, HU-08, HU-09 | Valorar separar las historias por resultados de usuario verificables, no por capa técnica. | Agrupan resultados que podrían tener valor y criterios de aceptación independientes (p. ej. cita previa y FAQ en HU-08), lo que dificulta estimar y comprobar cada resultado. | Aceptada |
| requirements-reviewer (F06) | HU-05, HU-06, HU-07, HU-11 (y estimaciones 8+h) |
Corregir las estimaciones -1h y documentar la convención de rangos o estimaciones abiertas. |
El DoR exige una estimación consensuada en horas-persona; una estimación negativa no permite planificar y 8+h no tiene límite superior. |
Aceptada |
| requirements-reviewer (F07) | Misión y objetivos frente a EP-01 a EP-05 | Hacer explícita la relación de cada historia con sus usuarios y contrastar la cobertura de profesorado y PAS. | La misión identifica estudiantes, profesorado y PAS, pero las historias se centran en estudiantes o en un "usuario" genérico (salvo el administrador en HU-15). | Aceptada |
| requirements-reviewer (F08) | Objetivos G-01 a G-08 y metadatos Goals de las épicas |
Completar la trazabilidad por historia y aclarar dónde se especifican los resultados de formación (G-08) y feedback. | La trazabilidad a nivel de épica no permite saber qué historias contribuyen a cada objetivo; G-08 y la recogida de feedback no aparecen como resultados comprobables. | Aceptada |
| requirements-reviewer (F09) | HU-17 (EP-05) y EX-04 |
Documentar la aprobación, el alcance de datos y funciones y las dependencias de la integración con Outlook. | EX-04 excluye integraciones de terceros no aprobadas y los objetivos no nombran Outlook; no se demuestra su aprobación ni qué permisos y datos se autorizan. | Aceptada |
| requirements-reviewer (F10) | HU-08 y HU-09 | Vincular CAUX (citas y FAQ) y Erasmus con los objetivos y límites aplicables, y delimitar su parte funcional. | La alineación es plausible, pero los límites generales no concretan estos dos servicios ni qué sistemas o procesos abarcan. | Aceptada |
| requirements-reviewer (F11) | HU-01, HU-02, HU-03, HU-05, HU-08, HU-09 | Revisar cada historia como unidad de valor (INVEST) y hacer explícitas las dependencias que condicionan su planificación. | HU-01 y HU-02 dependen de US-05, US-14, US-15 y US-16 sin explicar su identidad; la estimación de 3-5h de HU-03 no se puede contrastar con su alcance. |
Aceptada |
| requirements-reviewer (F12) | Criterios de aceptación de las cinco épicas | Añadir criterios de error, estados vacíos, carga y casos límite según el flujo, con respuesta observable para el usuario. | Solo HU-02 (fuera de plazo) y HU-14 (corte de red) contemplan errores; la constitución exige especificar estos escenarios. | Aceptada |
| requirements-reviewer (F13) | HU-01, HU-02, HU-03, HU-04, HU-09 | Referenciar las reglas académicas oficiales y definir resultados, transiciones y escenarios límite. | Prerrequisitos, plazas y solapamientos (HU-01) no tienen fuente definida; HU-02 no detalla efecto ni reversibilidad; HU-03 lista estados sin transiciones; HU-09 deja idioma y créditos solo en verificaciones. | Aceptada |
| requirements-reviewer (F14) | HU-07, HU-08, HU-11, HU-15, HU-17 | Precisar la métrica, las condiciones de prueba y el origen de los datos de cada umbral temporal. | Los umbrales (30 min, 10 s, 2 s, 1 s, 5 min) no definen carga, volumen, punto de medida ni condiciones de red, por lo que no son reproducibles. | Aceptada |
| requirements-reviewer (F15) | EP-01 a EP-05 frente al DoR | Completar los criterios aplicables del DoR y registrar los no aplicables o no bloqueantes. | Faltan IDs US-XXX consistentes, trazabilidad individual a objetivos, justificación de prioridades, dependencias validadas y registro de supuestos y cuestiones pendientes. El informe no asigna estado Ready a ninguna historia. |
Aceptada |
| requirements-reviewer (F16) | Constitución, DoR y DoD | Aplicar el DoR en refinamiento y planificación, y el DoD al validar el trabajo completado. | No se observa contradicción documental entre ambos acuerdos; el DoD no sustituye criterios de aceptación faltantes ni justifica considerar una historia Ready. | Aceptada |
| requirements-reviewer (F17) | HU-01, HU-03, HU-06, HU-07, HU-08, HU-09, HU-17 | Identificar cada sistema o fuente de datos, su dependencia funcional y el comportamiento previsto si no está disponible. | Se citan sistema de expedientes, fuente oficial, sistema de citas o API de Microsoft sin responsables, disponibilidad, datos intercambiados ni condiciones de fallo. | Aceptada |
| requirements-reviewer (F18) | HU-03, HU-04, HU-11, HU-14, HU-17 | Especificar permisos, datos y estados de acceso, y documentar la retención y protección de datos. | No se concretan los roles que gestionan documentos de terceros (HU-04), la protección de borradores (HU-14) ni los permisos de Outlook (HU-17), exigidos por la constitución. | Aceptada |
| requirements-reviewer (F19) | EP-03 y criterios de todas las épicas |
Definir criterios de accesibilidad verificables por historia, alineados con la versión normativa que se determine. | La constitución define la accesibilidad como transversal, pero fuera de EP-03 solo aparece de forma puntual (HU-03, HU-10). | Aceptada |
| requirements-reviewer (F20) | HU-14, HU-15, HU-16 | Definir condiciones y escenarios de verificación de guardado, recuperación, backup y disponibilidad. | Las métricas (30 días, backups diarios, 99,5 %, RTO y RPO) no especifican integridad del borrador, restauración válida ni cálculo de disponibilidad y exclusiones. | Aceptada |
11. Planificación Operativa del Proyecto (ProjectLibre)
Para materializar la ejecución del proyecto de renovación de la plataforma digital de la Universidad de Extremadura, el equipo ha formalizado la programación de actividades en la herramienta ProjectLibre. El resultado son dos modelos de visualización complementarios sobre un mismo calendario, los mismos recursos y las mismas dependencias, con la asignación de recursos y los costes integrados.
11.1 Entregables de planificación
Toda la planificación operativa se publica en el repositorio bajo la ruta docs/organization/:
Planificacion_Sprints.pod: archivo de ProjectLibre estructurado temporalmente en 5 iteraciones (IT-001aIT-005) de 1 semana de duración. Cada iteración agrupa sus historias de usuario, su reunión semanal y un hito de fin de sprint.Planificacion_Epicas.pod: archivo de ProjectLibre estructurado funcionalmente por épicas (EP-01aEP-05), con un bloque transversal de Gestión Scrum y un bloque de Hitos.
11.2 Consolidación de la línea base de tiempo y costes
Mientras que la sección Planificación de capacidad y la sección Coste del proyecto de la definición del proyecto establecen la capacidad teórica máxima (277,5 h) y su coste asociado, la programación en ProjectLibre consolida las actividades concretas asignadas al equipo.
| Concepto | Horas | Coste |
|---|---|---|
| Capacidad teórica máxima (5 sprints) | 277,5 h | 9.537,50 € |
| Esfuerzo de historias de usuario (17 US) | 72,0 h | 2.450,00 € |
| Ceremonias de gestión Scrum (5 reuniones semanales × 5 personas × 2 h) | 50,0 h | 1.750,00 € |
| Esfuerzo programado en cronograma | 122,0 h | 4.200,00 € |
| Reserva no asignada a tareas fijas | 155,5 h | 5.337,50 € |
- Utilización de la capacidad: 122 h programadas sobre 277,5 h disponibles (≈ 44 %).
- Reserva de contingencia: 155,5 h para imprevistos, pruebas, correcciones, refactorización y cualquier mejora transversal.
- Calendario de ejecución: inicio el 19 de octubre de 2026 a las 8:00 h y finalización el 20 de noviembre de 2026 a las 17:00 h (25 días laborables, 5 sprints de lunes a viernes).
- Ausencia de sobreasignación: todas las asignaciones respetan el máximo semanal de cada miembro (ver sección Carga por persona y sprint).
11.3 Planificación por iteraciones (vista Sprints)
El modelo estructurado por Sprints organiza el trabajo por iteración. Cada sprint contiene sus historias (ordenadas por prioridad MoSCoW), la reunión semanal y un hito de Sprint Review.
| Sprint / Iteración | Esfuerzo (h) | Coste (€) | Historias desarrolladas | Fechas |
|---|---|---|---|---|
| IT-001: Cimientos técnicos | 26,5 h | 927,50 € | US-15 (BD), US-16 (estabilidad), US-05 (navegación) | 19/10/26 – 23/10/26 |
| IT-002: Autoguardado y servicios | 23,5 h | 812,50 € | US-14 (protección ante fallos), US-04 (documentos), US-06 (asignaturas), US-11 (directorio), US-07 (eventos), US-08 (CAUX) | 26/10/26 – 30/10/26 |
| IT-003: Trámites críticos | 27,0 h | 915,00 € | US-01 (matrícula), US-02 (desmatriculación), US-03 (becas) | 02/11/26 – 06/11/26 |
| IT-004: ERASMUS, móvil y Outlook | 26,5 h | 907,50 € | US-09 (ERASMUS), US-13 (app móvil), US-17 (Outlook) | 09/11/26 – 13/11/26 |
| IT-005: Cierre y colchón | 18,5 h | 637,50 € | US-10 (estética), US-12 (app escritorio) | 16/11/26 – 20/11/26 |
| TOTAL CRONOGRAMA | 122,0 h | 4.200,00 € | 17 historias + 5 reuniones semanales | 19/10/26 – 20/11/26 |
Cada esfuerzo incluye 10 h de reunión semanal (5 personas × 2 h).
Objetivos por sprint:
- IT-001: dejar listos los cimientos técnicos (base de datos y estabilidad del servicio) y la navegación base.
- IT-002: implementar el autoguardado, que es predecesor de los trámites, junto con descarga de documentos y mejoras de información y servicios.
- IT-003: completar los trámites críticos. Al final de este sprint todas las historias Must están cerradas.
- IT-004: abordar las funcionalidades Could (ERASMUS, app móvil, integración con Outlook).
- IT-005: cierre del proyecto con las historias Won't (si se mantienen) y margen para estabilización.
11.4 Planificación por épicas funcionales (vista Épicas)
El segundo modelo reorganiza las historias de usuario bajo sus épicas de negocio y extrae las reuniones Scrum a un bloque transversal de gestión.
| Épica / Bloque funcional | Esfuerzo (h) | Coste (€) | Historias (sprint) |
|---|---|---|---|
| EP-01: Simplificación de trámites | 19,0 h | 630,00 € | US-01 (S3), US-02 (S3), US-03 (S3), US-04 (S2) |
| EP-02: Facilitación de navegación | 3,5 h | 122,50 € | US-05 (S1), US-06 (S2), US-07 (S2), US-08 (S2) |
| EP-03: Mejora de accesibilidad | 2,0 h | 70,00 € | US-09 (S4) |
| EP-04: Cambio de diseño | 15,5 h | 512,50 € | US-10 (S5), US-11 (S2), US-12 (S5), US-13 (S4) |
| EP-05: Mejora de administración técnica | 32,0 h | 1.115,00 € | US-14 (S2), US-15 (S1), US-16 (S1), US-17 (S4) |
| Gestión Scrum (transversal) | 50,0 h | 1.750,00 € | 5 reuniones semanales |
| TOTAL CRONOGRAMA | 122,0 h | 4.200,00 € | 5 épicas + bloque de gestión |
Los esfuerzos de las épicas coinciden con los de la definición del proyecto (19 / 3,5 / 2 / 15,5 / 32 h). El bloque de gestión añade las 50 h de reunión, que no estaban contabilizadas en ese cuadro.
11.5 Carga por persona y sprint
Horas planificadas (historias + 2 h de reunión semanal) frente a la capacidad semanal de cada miembro.
| Miembro (Rol) | Máx. semanal | IT-001 | IT-002 | IT-003 | IT-004 | IT-005 | Total (h) | Coste (€) |
|---|---|---|---|---|---|---|---|---|
| Pedro Fernández (PO) | 10 h | 2,5 | 3,5 | 3,0 | 3,0 | 3,0 | 15,0 | 525,00 € |
| Gonzalo Aparicio (TL) | 7,5 h | 7,0 | 4,0 | 4,0 | 5,0 | 4,0 | 24,0 | 960,00 € |
| Lucas Méndez (SM) | 11 h | 3,0 | 5,0 | 4,0 | 4,5 | 2,0 | 18,5 | 647,50 € |
| Pablo Márquez (DevOps/QA) | 12,5 h | 7,0 | 5,0 | 6,0 | 5,0 | 3,5 | 26,5 | 927,50 € |
| Francisco J. Borox (Dev) | 14,5 h | 7,0 | 6,0 | 10,0 | 9,0 | 6,0 | 38,0 | 1.140,00 € |
| TOTAL | 55,5 h | 26,5 | 23,5 | 27,0 | 26,5 | 18,5 | 122,0 | 4.200,00 € |
11.6 Dependencias, secuencia e hitos
Las dependencias de las especificaciones obligan a esta secuencia:
IT-001: US-15, US-16, US-05
│
IT-002: US-14 (necesita US-15, US-16) · US-04 (necesita US-15) · US-06/07/11 · US-08
│
IT-003: US-01, US-02 (necesitan US-05, US-14, US-15, US-16) · US-03 (necesita US-04, US-14, US-15)
│
IT-004: US-09 (necesita US-03) · US-13 · US-17
│
IT-005: US-10 · US-12
11.7 Cómo interpretar los porcentajes de los recursos
En ProjectLibre, el porcentaje que aparece junto al nombre de cada persona en una tarea es su unidad de asignación: la fracción de su tiempo que dedica a esa tarea mientras dura.
Fórmula: % = horas asignadas ÷ horas de duración de la tarea
Como cada tarea dura una semana (5 días × 8 h = 40 h), el porcentaje es pequeño. Ejemplo con US-01:
| Persona | Horas | Cálculo | % mostrado |
|---|---|---|---|
| Francisco | 3 h | 3 ÷ 40 = 7,5 % | 8 % |
| Pablo | 1,5 h | 1,5 ÷ 40 = 3,75 % | 4 % |
| Lucas | 2 h | 2 ÷ 40 = 5 % | 5 % |
- Lo que hay que vigilar es que la suma de porcentajes de cada persona en una misma semana no supere su máximo, que es su dedicación diaria dividida entre 8 h:
| Miembro | Dedicación diaria | Máximo |
|---|---|---|
| Pedro Fernández | 2 h | 25 % |
| Gonzalo Aparicio | 1,5 h | 18,75 % |
| Lucas Méndez | 2,2 h | 27,5 % |
| Pablo Márquez | 2,5 h | 31,25 % |
| Francisco J. Borox | 2,9 h | 36,25 % |
Si se superase ese máximo, ProjectLibre marcaría al recurso en rojo en la hoja de recursos (sobreasignación).
11.8 Trazabilidad visual y diagramas de Gantt
A continuación se incluyen las capturas de la planificación extraídas de ProjectLibre.