Gestión de Proyectos

3º Ingeniería Informática · Universidad de A Coruña · Apuntes basados en diapositivas oficiales

T1 ¿Es mejorable el proceso software?

Para saber si el proceso software es mejorable necesitamos conocer los objetivos que persigue (esfuerzo, tiempo, coste, calidad) y el grado de cumplimiento de esos objetivos.

Datos históricos — Crisis del Software

Los estudios históricos demuestran sistemáticamente que el proceso software tiene graves problemas:

DoD — Año 1979 (proyectos contratados, $6.8M)

Resultado	%
Pagado pero nunca entregado	29%
Entregado pero nunca usado	48%
Usado pero con trabajo extra o abandonado después	19%
Usado después de cambios	~3%
Usado tal como se entregó	~1%

Capers Jones — Años 80 (software Administración Pública americana)

Solo el 5–10% era directamente usable
Entre el 30–40% nunca se había usado o nunca se podría usar

Standish Group — Chaos Report (1994–2006)

Proyectos exitosos	1994	1996	1998	2000	2006
% exitosos	16%	27%	26%	28%	35%
% completamente fallidos	31%	—	—	—	19%
% challenged (entregados con problemas)	53%	—	—	49%	46%

Tendencia Hay mejora progresiva desde 1994: "There is less chaos in software development today than there has been since The Standish Group started reporting chaos back in 1994".

Capers Jones — Análisis de riesgos por categoría de proyecto (90s)

Tipo de proyecto	Problema	%
Software comercial	Comercialización posterior a lo previsto	50%
	Inadecuada documentación de usuario	70%
	Baja satisfacción de usuarios	55%

Software de gestión	Surgir nuevos requisitos	80%
	Baja calidad	~70%
	Sobrecoste / Mala gestión configuración	~60% / 50%
Software de sistemas	Proyectos largos	70%
	Excesivo papeleo	60%
	Módulos propensos a errores	50%
Software subcontratado	Criterios de aceptación imprevistos	30%
	Altos costes de mantenimiento	60%
	Problemas cliente/subcontrata	50%
Proyectos usuarios particulares	Errores ocultos	65%
Proyectos usuarios particulares	Software inmantenible	60%

Proyectos "challenged" — % características entregadas

1994: solo el 61% de las características requeridas fueron entregadas
2000: solo el 67% de las características requeridas fueron entregadas

¿Cómo mejorar? — Solución: 3 pilares

No existe una "bala de plata". Las pruebas solas no son suficientes:

Limitaciones de las pruebas Un programador comete ~100 defectos por cada KLOC (1000 líneas de código). El éxito en detección mediante pruebas es menor del 50%. Por tanto, a más defectos antes de las pruebas → más defectos tras ellas.

La solución es trabajar con calidad desde el principio y a lo largo de todo el proceso, no solo al final. Hay que mejorar simultáneamente en tres aspectos interrelacionados:

Desarrollo

Elección de un ciclo de vida adecuado a cada proyecto.

Asignatura: Proceso Software

Gestión

Aplicar aproximaciones sistemáticas para gestionar esfuerzo, tiempo y coste.

Asignatura: Gestión de Proyectos

Calidad

Mejora de la calidad del proceso y del producto.

Asignatura: Aseguramiento de la Calidad

Parámetros de calidad Deben establecerse por anticipado, ser cuantificables (medibles) y verificables (procedimiento objetivo para verificarlos). Ejemplos: satisfacción del usuario, número de errores, tiempo medio entre fallos.

T2 Planificación y Seguimiento de Proyectos

Definición de Proyecto

Proyecto Conjunto de recursos humanos, materiales y financieros; con una organización, planificación, productos específicos, objetivos y un entorno de riesgo.

Las 3 características fundamentales

Característica	Descripción
Discreto	Con inicio y fin definidos, y un producto final a obtener
Complejo	Con un conjunto de diferentes tareas interrelacionadas
Único	En relación a su producto final y a su entorno de desarrollo

Un proyecto no es un proceso cotidiano o rutinario (funciones normales).

Las 4 dimensiones de un proyecto

Para el examen Personas · Proceso · Producto · Tecnología
(Aunque también pueden referirse a: Esfuerzo, Tiempo, Coste y Calidad)

Objetivos de la gestión del proyecto

La gestión busca la entrega de productos finales:

Cumpliendo las especificaciones
En plazo
Dentro del presupuesto
Con los niveles de calidad correspondientes

Ciclo de Vida del Proyecto — KPMG

El modelo de ciclo de vida utilizado es la aproximación Information Technology Project Management de KPMG Consulting, con 5 fases:

#	Fase	Actividades
1	Evaluación y aprobación del proyecto	Decidir si se aborda el proyecto
2	Planificación y puesta en marcha	Identificar y cuantificar requisitos; identificar recursos
3	Planificación del trabajo	Detalle de actividades, organización infraestructura, RR.HH.
4	Seguimiento y control	Comparar con plan, analizar impacto, ajustar
5	Finalización del proyecto	Cierre formal

Fases adyacentes (transversales): Gestión de calidad · Gestión de cambios · Gestión de riesgos.

Técnicas de Planificación

WBS — Work Breakdown Structure

Definición Técnica que consiste en estructurar las tareas de un proyecto por tipos y niveles de agregación. Es la estructura de descomposición/desglose de un proyecto en actividades con diferentes niveles de detalle.
→ Responde a: ¿Qué hay que hacer?

OBS — Organisational Breakdown Structure

Definición Técnica que estructura la organización del proyecto por unidades organizativas y personas que poseen responsabilidad. Refleja cómo están organizadas las áreas en términos de responsabilidad funcional.
→ Responde a: ¿Quién hace qué?

Diagrama de Gantt

Representa en una escala de tiempos cada actividad mediante barras que representan su duración en fechas de calendario. Es una representación simplificada de una red de precedencia. No representa explícitamente las relaciones de precedencia.

Relación Gantt-Redes El Diagrama de Gantt tiene una estrecha relación con las Redes de Precedencia, pues es una representación simplificada de éstas. V/F: VERDADERO

Histograma de recursos

Diagrama de barras que muestra la asignación de recursos a lo largo del tiempo. Permite detectar sobrecargas e infrautilizaciones.

Redes de Precedencia

Técnicas basadas en grafos que permiten reflejar las relaciones entre actividades. Existen dos métodos:

Método	Representación	Relaciones	Uso
PDM (Precedence Diagramming Method)	Nodos = actividades; vectores = dependencias	CC, CF, FC, FF	Más empleado
ADM (Arrow Diagramming Method)	Vectores = actividades; nodos = hitos	Lineales, convergencia, divergencia	Poco empleado; requiere actividades ficticias

ADM requiere actividades ficticias En ADM a veces son necesarias actividades ficticias (duración 0 y coste 0) para reflejar ciertas combinaciones de precedencia.

PERT y CPM

Característica	PERT	CPM
Orientación	Eventos/sucesos (técnica ADM)	Actividades (técnica PDM)
Probabilidad	Sí — considera incertidumbre	No — determinista
Duración actividad	Media ponderada de 3 valores	Un único valor más probable

Fórmula PERT

Duración esperada (distribución beta) T_PERT = (T_optimista + 4 × T_más_probable + T_pesimista) / 6

Donde To = tiempo mínimo si no surge ningún problema Tmp = tiempo normal de duración Tp = tiempo máximo

Pasos del CPM (Método del Camino Crítico)

Elaborar la red de precedencia (PDM) a partir de la WBS
Identificar todos los posibles caminos dentro del grafo dirigido (inicio → fin)
Calcular los tiempos totales de cada camino
El camino crítico es el de mayor duración

Para el CPM no se necesitan recursos El análisis de tiempos NO tiene en cuenta los recursos necesarios ni su disponibilidad para el cálculo del camino crítico.

Tipos de Restricciones Lógicas

Sobre una restricción se puede aplicar una demora (positiva o negativa), lo que permite adelantar o retrasar la actuación de la restricción.

Tipo	Nombre	Descripción	Ejemplo
FC (FS)	Fin a Comienzo	B no puede comenzar hasta que A haya terminado. La más usual.	Pulir antes de pintar
CC (SS)	Comienzo a Comienzo	B no puede comenzar hasta que A haya comenzado.	Instalar fontanería y electricidad en una obra
FF	Fin a Fin	B no puede terminar hasta que A haya terminado.	Backup del viejo PC e instalación del nuevo
CF (SF)	Comienzo a Fin	B no puede terminar hasta que A haya comenzado. Poco usual.	Vigilancia de una central nuclear / impresión de nóminas por sistema antiguo y nuevo

CC no implica inicio simultáneo CC significa que B puede empezar una vez que A haya comenzado, NO que deban empezar al mismo tiempo. V/F: FALSO ("CC debe empezar al mismo tiempo que la otra tarea").

Equivalencia FC/CC A FC B es equivalente a A CC+2d B si A dura 2 días. V/F: VERDADERO

La Hamaca

Actividad Hamaca Tipo especial de actividad que mide el tiempo transcurrido entre dos puntos de la red (entre actividades, hitos, etc.). Se crea en MS-Project como tarea resumen.

Restricción importante Las restricciones lógicas se deben establecer con las tareas elementales, NO con las hamacas. En una hamaca NO se pueden poner relaciones.

Camino Crítico — Análisis de tiempos

El análisis de tiempos calcula para cada actividad:

Early start / Early finish: fechas más tempranas (cálculo hacia delante)
Late start / Late finish: fechas más tardías (cálculo hacia atrás)
Holgura total = fecha más tardía de terminación − fecha más temprana de finalización

Holgura Holgura = Late finish - Early finish (= Late start - Early start)

Las actividades con holgura = 0 forman parte del camino crítico.

Camino crítico — características

Pueden existir varios caminos críticos (desde el principio al fin del proyecto)
Cualquier retraso en una actividad crítica afecta a todo el proyecto
Si una actividad no crítica consume su holgura total, se convierte en crítica
La holgura puede ser negativa (el proyecto ya está retrasado)
En MS-Project, el camino crítico no siempre es continuo de principio a fin

Definiciones relacionadas

Actividad Unidad más elemental del nivel de planificación. Puede identificarse por su duración, consumo de recursos o ambas. Cada actividad es una parte independiente y homogénea del proyecto.

Evento / Hito (Milestone) Tipo especial de actividad sin duración (duración 0) que indica un acontecimiento importante. No consume recursos. Se usa para puntos de control.

Hito Un hito tiene trabajo y duración 0 (no "que su duración es 0 sin trabajo"). En MS-Project se puede poner coste a los hitos.

Nivelación de Recursos

Después de asignar recursos y detectar sobrecargas en el histograma, se aplica nivelación. Las causas de sobrecarga pueden ser:

No disponibilidad de recursos en determinados períodos
Mayor carga de la soportable por su dedicación en una tarea
Mayor carga por trabajar en varias tareas simultáneamente

Posibles soluciones a sobrecargas: alargamiento de actividades al eliminar recursos · cambio de recursos · introducir recursos que compartan el esfuerzo · modificación de la temporalidad · segmentación de actividades.

Estrategia	Descripción
A TIEMPO	Se mantiene fija la fecha de fin del proyecto y se modifican las duraciones de actividades que no pertenezcan al camino crítico
A RECURSO	Se puede variar la fecha de fin del proyecto y las duraciones de las actividades para ajustarse a las disponibilidades de los recursos

Línea Base (Baseline)

Línea base — vista del proyecto Foto fija de la planificación a efectos de comparación. Es el proceso de almacenamiento de los datos de análisis y nivelación que constituyen la información de comparación para los sucesivos controles de avance.

Una línea base puede tener sobrecargas Aunque no sea lo ideal, se puede establecer la línea base con sobrecargas. La línea base NO copia datos previstos en datos actuales (al contrario). V/F: VERDADERO que puede tener sobrecargas.

Una vez establecida la línea base, se aplica un procedimiento formal para evaluar y verificar cada cambio posterior.

Seguimiento de Proyectos

Según Paulk, los objetivos del seguimiento y supervisión son:

Comparar resultados actuales con los planes previstos (línea de base)
Tomar acciones correctivas cuando existan desviaciones significativas

En el momento de realizar el seguimiento se establece el Time Now (fecha de progreso o fecha de hoy).

A nivel de actividad se indica:

Tiempo: fecha real de comienzo, fecha real de fin, duración pendiente o % de completitud
Esfuerzo: esfuerzo real realizado, esfuerzo pendiente
Coste: costes reales incurridos

Lord Kelvin: "Cuando tú puedas medir aquello sobre lo que hablas, sabes algo de ello; si no puedes medirlo, tu conocimiento es escaso y no satisfactorio."
Tom DeMarco: "No puedes controlar lo que no puedes medir."

Métricas de Seguimiento

Tipos de métricas

Métricas de producto: cuantifican atributos del producto (tamaño, complejidad, fiabilidad…)
Métricas de proceso: cuantifican atributos del proceso (productividad, ratio de defectos…)

Métricas de progreso

Miden el grado de realización de las actividades de acuerdo con la planificación. La diferencia entre lo real y lo planificado indica adherencia al plan.

Métricas de esfuerzo

Miden las dedicaciones de los recursos humanos. Se capturan normalmente a través de hojas de trabajo con periodicidad concreta (diaria, semanal…).

Interpretación combinada esfuerzo/progreso:

Horas reales vs. plan	Progreso real vs. plan	Tendencia
Más horas (↑)	Más progreso (↑)	Puede acabar antes pero gastando más
Menos horas (↓)	Más progreso (↑)	Puede acabar antes y gastar menos
Más horas (↑)	Menos progreso (↓)	Acabará más tarde y gastará más
Menos horas (↓)	Menos progreso (↓)	Acabará más tarde y gastará menos

Valor Ganado (Earned Value)

Indicadores básicos BCWS = Budgeted Cost of Work Scheduled (coste presupuestado del trabajo planificado) BCWP = Budgeted Cost of Work Performed (coste presupuestado del trabajo realizado) ACWP = Actual Cost of Work Performed (coste real del trabajo realizado)
Variaciones CV = BCWP - ACWP (Variación de coste; negativo = gasta más de lo previsto) SV = BCWP - BCWS (Variación de programa; negativo = va más lento)
Coste estimado a la finalización TCE = ACWP + ETC (coste real + estimación pendiente hasta finalizar)

Interpretación: Si CV es negativo → el proyecto gasta más de lo presupuestado. Si SV es negativo → se realiza menos trabajo de lo previsto.

Curvas de Rayleigh-Norden

Modelo Rayleigh-Norden Asume que el esfuerzo para proyectos de desarrollo de software a lo largo del tiempo se distribuye en una colección de curvas de Rayleigh, una para cada actividad del desarrollo. Características típicas:

Los recursos más experimentados se necesitan en requisitos y diseño
La mayor cantidad de recursos se necesita en la construcción
La necesidad de personal baja en las pruebas

CMMI Nivel 2

CMMI Nivel 2 La planificación y el seguimiento de proyectos son dos áreas de proceso (KPA) del nivel 2 de CMMI (NO nivel 3). En este nivel solo se busca la repetitividad: obtener medidas de proyectos con procedimientos similares para repetir éxitos y evitar fracasos.

Examen frecuente "Planificación y seguimiento de proyecto son KPA de CMMI Nivel 3" → FALSO. Son del nivel 2.

T2 Comunicación y Negociación

Planificaciones Excesivamente Optimistas

Robert L. Glass: "Trabajar con planificaciones imposibles es el mayor problema en sistemas de información."

Según Steve McConnell, hay tres factores que conllevan al núcleo de los problemas de planificaciones optimistas:

1. Ilusiones

Clientes, responsables y usuarios desean obtener el máximo partido a su inversión lo antes posible. La mayoría de planificaciones son ambiciosas, no de tipo medio.

2. Falta de conocimiento de estimación

Es imposible estimar correctamente el software en sus estados iniciales. El personal no tiene historial de estimaciones ni conoce los efectos de no emplearla correctamente.

3. Presión de planificación

Crea un círculo vicioso: más presión → más estrés → más errores → más retrasos → más presión. Los recursos ven la presión como exclusiva de su proyecto aunque la hayan sufrido siempre.

Consecuencias: anima la toma de atajos y soluciones rápidas; perjudica costes, calidad e integridad del producto.

Negociación Conveniente (Principled Negotiation)

Método del libro "Getting to Yes" de Roger Fisher y William Ury (1981), derivado del Proyecto de Negociación de Harvard. Se centra en la negociación ventajosa para todos.

Consta de 4 partes: personas, intereses, opciones, criterios.

1. Separar las personas del problema

Si las personalidades son diferentes, las negociaciones pueden estar condicionadas por esas diferencias
Hay que comprender la posición del lado contrario e intentar no personalizar
La mayoría de las personas no son irracionales cuando insisten en una postura (e.g., una fecha imposible)
¿Qué hacer? Trabajar para mejorar la relación, establecer expectativas realistas, sugerir cambios que acerquen posturas

2. Centrarse en los intereses, no en las posiciones

Las posiciones son tan estrictas que para que una parte gane la otra tiene que perder
Los intereses subyacentes son más amplios: si la negociación se centra en ellos se abren muchas posibilidades
En planificación: muchas veces se exige una fecha para todo el producto cuando no es necesario → posible opción: entrega incremental

Formulación MAL: "Quiero A" vs "Quiero B" → juego de suma cero BIEN: "Quiero A porque necesito C" → "Te doy B porque en C te ayudo haciendo D y además E"

3. Inventar opciones para beneficios mutuos

Para un técnico es importante: tiene capacidad de generar opciones técnicas que la otra parte no puede
Opciones posibles en planificación software: entrega incremental priorizando prestaciones, eliminación/reducción de prestaciones, componentes comerciales preconstruidos
Advertencia: no comprometerse firmemente con nuevas opciones hasta analizarlas con calma individualmente

4. Insistir en criterios objetivos

Para eliminar bloqueos, usar criterios objetivos
Presentar criterios objetivos, mantener mente abierta, discutir qué criterios son más adecuados
No negociar la propia estimación, pero sí los elementos que se usan para estimar
Insistir en que la estimación la prepare alguien cualificado
Insistir en proceso racional: (1) comprometerse con requisitos antes que con la estimación, (2) refinar estimaciones conforme avanza el proyecto, (3) reestimar si cambian los requisitos

Comunicación en negociación NO: "No puedo entregarlo en esa fecha."
MEJOR: "Con mi equipo, puedo entregar esos requisitos desarrollados 1 mes más tarde de esa fecha."

Comunicación Eficaz

Premisa La comunicación eficaz entre dos personas se produce cuando el receptor interpreta el mensaje en el sentido que pretende el emisor.

Comunicación verbal vs. no verbal

Tipo	Descripción	Peso
Verbal	Palabras empleadas e inflexiones de la voz (tono y variaciones)	20–35%
No verbal	Contacto visual, gestos faciales, movimientos de brazos/manos, postura y distancia corporal	65–80%

Dato clave para el examen Entre el 65% y el 80% del total de la comunicación con los demás se realiza a través de canales no verbales. Los mensajes verbales y no verbales deben coincidir.

Escucha activa

Escuchar y entender la comunicación desde el punto de vista del emisor: entender no solo lo que se dice, sino los sentimientos e ideas que subyacen. No es lo mismo que oír.

Conviene mostrar escucha activa:

Verbal: "Ya veo", "Entonces…", "No me digas", parafrasear lo escuchado
No verbal: contacto visual frecuente pero no exagerado, gestos

No conviene: mostrarse distante, distraerse, interrumpir, ofrecer soluciones prematuramente, rechazar sentimientos del emisor.

Técnicas de comunicación eficaz

No criticar al receptor: hablar de lo que hace, no de lo que es
Discutir temas uno a uno; no acumular sensaciones
Ser específico y concreto: evitar vaguedades
Evitar generalizar: no usar "todos", "nadie", "siempre", "nunca"
Ser breve; elegir el lugar y momento correcto

Comunicación Asertiva

La asertividad es la conducta de interactuar siendo directo, honesto y respetuoso. Ante situaciones incómodas, las respuestas se clasifican en 3 tipos:

Conducta	Creencia	Resultado
Pasiva / Sumisa	"Soy inferior, mis derechos no cuentan"	No se expresan opiniones; se violan los propios derechos
Agresiva	"Soy superior, impongo mis ideas"	Acusaciones, insultos, amenazas; se ganan enemigos
Asertiva	"Soy igual a todos, todos igualmente importantes"	Cooperación y negociación; satisfacción propia + relaciones satisfactorias

6 Técnicas de asertividad

Técnica	Objetivo	Ejemplo
Mensajes YO	Describir comportamiento sin condenarlo; describir sentimiento y consecuencia; expresar qué se quiere	"Cuando tú [conducta], yo me siento [sentimiento] porque [consecuencia]; por lo que por favor te pido [petición]"
Disco rayado	Reiterar de forma persistente y tranquila el mensaje central sin que otros elementos distraigan	El funcionario que repite "una fotocopia siempre debe acompañarse del original"
Banco de niebla	Reconocer total o parcialmente que la otra parte puede tener razón; negarse a mantener la discusión; no cambiar de postura	"Sé que estás muy cansado porque tu jefe te encarga muchas cosas, y lo entiendo, pero por favor baja tú la basura"
Aplazamiento asertivo	Aplazar la respuesta hasta estar más tranquilos y capaces de responder correctamente	"Si te parece bien, lo miramos mañana con calma y te explico todo lo que quieras"
Ignorar	No prestar atención cuando la persona está muy enfadada y todo puede acabar mal	Alejarse de la situación
Pregunta asertiva	No pensar mal del crítico; asumir que las críticas son bienintencionadas; pedir aclaraciones	"¿Por qué te molesta mi forma de actuar?", "¿Qué defecto encuentras en esta solución?"

T3 Gestión de Riesgos

Definición de Riesgo Evento o condición incierta que, en caso de ocurrir, tiene un efecto negativo sobre los objetivos de un proyecto. Tiene una causa y, si ocurre (evento de riesgo), una consecuencia (efecto).
El Air Force define riesgo como la forma de expresar la incertidumbre a lo largo del ciclo de vida: la probabilidad de que en un punto del ciclo de vida no se alcancen los objetivos propuestos con los recursos disponibles.

Pilares y Niveles

Los 4 pilares de McConnell (desarrollo rápido, económico y de calidad)

Pilar 1: Personas (equipos motivados y eficaces)
Pilar 2: Proceso (ciclo de vida adecuado)
Pilar 3: Gestión de Riesgos
Pilar 4: Defensa contra errores clásicos

Tom Gilb: "Si no controlas los riesgos, ellos te controlarán a ti."

Probabilidades en el mundo real

Probabilidad de finalizar un proyecto complejo en el tiempo estimado → tiende a 0
Probabilidad de cancelar un proyecto complejo → tiende a 0.5
Peat Marwick (1988): de 600 empresas, el 35% ha tenido al menos un proyecto que se le fue de las manos
Allstate (1982): planificaron 5 años y $8M; 6 años después necesitaban $100M

5 Niveles de control de riesgos — Pressman

Niveles 1, 2 y 3 = "se ha perdido la batalla"

Nivel	Nombre	Descripción
1	Control de crisis	Controlar riesgos solo cuando se han convertido en problemas. Actuar de bombero apagando el fuego.
2	Arreglar cada error	Detectar y reaccionar rápidamente ante cualquier riesgo, pero solo después de producirse.
3	Mitigación de riesgos	Planificar con antelación el tiempo para cubrir riesgos, pero sin intentar eliminarlos inicialmente.
4	Prevención	Crear y llevar a cabo un plan como parte del proyecto para identificar riesgos y evitar que se conviertan en problemas.
5	Eliminación de causas principales	Identificar y eliminar los factores que puedan hacer posible la presencia de algún tipo de riesgo.

Estructura de Boehm

La gestión de riesgos según Boehm se compone de:

Estimación de riesgos: Identificación → Análisis → Priorización → Planificación de la gestión
Control de riesgos: Resolución → Monitorización

Diferencia riesgos vs. errores clásicos Los errores clásicos se cometen con más frecuencia. Los riesgos son menos comunes o pueden ser únicos para un proyecto determinado.

6 Categorías de Riesgo

Categoría	Descripción
Estratégicos	Relacionados con estrategia de la organización, pérdidas/beneficios, imagen (e.g., pérdida de mercado)
Comerciales	Relacionados con la venta, seguimiento del cliente, precio y actualizaciones (e.g., pérdida del cliente)
Contractuales y financieros	Relacionados con términos contractuales: penalizaciones, niveles de calidad, calendarios de pagos
De gestión	Relacionados con la organización del proyecto: recursos, equipos, calendarios, estimaciones
De proyecto	Aspectos técnicos del software: especificación, diseño, desarrollo, integración y validación
De explotación	Fallos durante la explotación que pueden causar daños significativos o ser peligrosos para la vida

Identificación de Riesgos

Consiste en elaborar una lista de riesgos que pueden afectar al proyecto. El riesgo se define como fuente de resultados insatisfactorios.

5 Estrategias de identificación

#	Estrategia	Descripción
1	Resultados insatisfactorios y causas	Identificar resultados insatisfactorios → pensar en causas → identificar riesgos asociados
2	Marco clasificatorio	Usar las 6 categorías de riesgo para ser sistemático
3	Particionar el espacio del problema	"Divide y vencerás": examinar cada tarea WBS e identificar 4-6 riesgos principales por partición
4	Evento de riesgo y efecto	Estudiar la cadena: Causa → Evento de riesgo → Efecto
5	Listas de comprobación	Construidas de información histórica. Identificación rápida pero no exhaustiva → usarlas como punto de partida

Agrupación por causas Una vez identificados, los riesgos pueden clasificarse por causas origen. No es obligatorio pero ayuda a saber a qué prestar atención. Las causas típicas incluyen: falta del ciclo de vida definido, pobre planificación, pobre gestión de requisitos, tecnología inmadura, etc.

Valoración — Exposición al Riesgo

Exposición al Riesgo (ER) ER = Probabilidad × Impacto (magnitud de pérdida)

Ejemplo 25% probabilidad × 4 semanas de retraso = 1 semana de exposición Si se suman todas las ER → retraso total estimado del proyecto

Magnitud de pérdida = Impacto Las diapositivas usan indistintamente estos términos. ER = P × I es correcto.

Formas de medir probabilidad e impacto

Numérica: valor entre 0 (imposible) y 1 (seguro)
Subjetiva: Alta / Media / Baja (con valores numéricos asignados)

Técnica Delphi

Método Delphi Técnica de aproximación por juicio de expertos. Varios miembros identifican riesgos y les asignan probabilidad e impacto. Las estimaciones son discutidas por el grupo y refinadas iterativamente.
Es la técnica más conocida para estimación subjetiva. V/F: VERDADERO.

Umbrales de actuación

Umbral	Exposición	Acción
Baja (B)	Riesgo de bajo impacto o baja probabilidad	Se vive con ellos (gestión de problemas)
Media (M)	Exposición media	Se define un plan de contingencia
Alta (A)	Alta exposición	Se definen acciones de prevención, alternativas y plan de contingencia

Priorización no es solo ordenación Algunos riesgos deben tratarse como relevantes independientemente de su posición en la lista: riesgos que producirían pérdidas considerables aunque con baja probabilidad. El jefe de proyecto puede y debe hacerlo. V/F: VERDADERO.

80/20 en riesgos: los proyectos suelen gastar el 80% del presupuesto en arreglar el 20% de sus problemas. Hay que centrarse fundamentalmente en ese 20%.

Análisis, Estrategias y Control

Clasificación de riesgos para el análisis

Gestionables y dentro del alcance: el coste de gestionar el riesgo es asumible → estudiar alternativas, definir estrategias de mitigación
Gestionables y fuera del alcance: el impacto de gestionar el riesgo es poco asumible
Inevitables: gestionar estos riesgos conllevaría cambiar la concepción del proyecto completamente

3 Estrategias de gestión de riesgos

Estrategia	Descripción
Transferir	Sacar el riesgo del proyecto a través de subcontratas
Prevenir	Desarrollar el proyecto de forma que el riesgo no pueda convertirse en problema; considerar caminos alternativos
Controlar	Aceptar la posibilidad del riesgo; establecer medidas para reducir exposición; planificar acciones de contención; hacer seguimiento frecuente

8 Acciones de resolución de riesgos

Evitar: no realizar actividades arriesgadas
Trasladar: de una parte del sistema a otra (expertos supervisan noveles; riesgo fuera del camino crítico)
Informarse: conocer mejor el riesgo, ver si es posible o no
Asumir: si consecuencias pequeñas y esfuerzo de mitigación grande
Comunicar: comunicar el posible impacto si ocurre
Controlar: planificar acciones en caso de ocurrir
Recordar: para proyectos futuros
Contingencia: planificar actividades para cuando ocurra

Control y seguimiento de riesgos

Actividades centradas en: asegurar que los planes de gestión se llevan a cabo; vigilar los parámetros identificativos de los riesgos; revalorar y reanalizar riesgos.

¿Cuándo? Cada vez que se haga el informe de seguimiento del proyecto. El modelo en espiral los establece intrínsecamente.

Dos alternativas de gestión Gestión de Problemas (bombero): según aparecen los problemas se van solventando.
Gestión de Riesgos (gestor): los posibles impactos se mitigan con planes. No exime de hacer gestión de problemas cuando sea necesario.

T4 Gestión de la Configuración del Software (GCS)

Definición y Objetivos

Definiciones

Según Babich El arte de coordinar el desarrollo de software para minimizar la confusión. El arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de programación. El objetivo es maximizar la productividad minimizando los errores.

Según IEEE La GCS cubre todas las actividades utilizadas para identificar y definir los elementos de configuración y sus relaciones. Permite controlar cambios durante el ciclo de vida, conocer los sucesivos estados y verificar la completitud y consistencia.
Misión resumida: minimizar la confusión, minimizar los errores y maximizar la productividad.

Según Pressman El arte de identificar, organizar y controlar las modificaciones que sufre el software. El objetivo es maximizar la productividad minimizando los errores.

2 Objetivos fundamentales de la GCS

Objetivo	Descripción
1. Facilitar la visibilidad	Sobre el estado del producto (estado actual) y sobre su historia (evolución). Se evalúan y controlan los cambios.
2. Mantener la integridad	Establecer y mantener la integridad de los productos generados durante el proyecto y a lo largo de todo su ciclo de vida. Un producto íntegro satisface necesidades del usuario, cumple requisitos de rendimiento y se puede trazar su evolución desde su concepción.

Actividades de la GCS 1. Identificación de la configuración
2. Control de cambios en la configuración
3. Generación de informes de estado
4. Auditoría de la configuración

Actividades ampliadas por herramientas CASE Las herramientas CASE suelen añadir: Control de versiones · Construcción (building) · Gestión de problemas · Control del trabajo en equipo.

Conceptos Básicos

Configuración del software Conjunto de toda la información y productos utilizados o generados en un proyecto como resultado del proceso de ingeniería del software. Es el término que designa al conjunto de todos los ECS de un proyecto.

Elemento de Configuración del Software (ECS) Cada uno de los componentes de la configuración del software. Es la unidad de trabajo para la GCS: debe ser un elemento que se pueda definir y controlar de forma separada. El sistema en su conjunto también es un ECS.

Línea Base (Baseline) — dos vistas

Vista	Definición
Del proceso	Punto de referencia en el proceso de desarrollo marcado por la aprobación de uno o más ECS mediante una revisión técnica formal.
Del producto	Conjunto de ECS revisados y aceptados que sirven como base para el desarrollo posterior y que solo se pueden cambiar a través de un proceso formal de control de cambios.
Del proyecto (puente)	Foto fija de la planificación a efectos de comparación.

Concepto de línea base Se introduce para permitir cambios rápidos e informales antes de que un ECS pase a la línea base. Después, cualquier cambio requiere procedimiento formal. Ejemplo: cambio en una librería de cálculo de la letra del NIF en un banco.

Control de Versiones

Versión vs. Revisión

Versión Instancia de un ECS, en un momento dado del proceso de desarrollo, almacenada en un repositorio y que puede ser recuperada en cualquier momento para su uso o modificación.

Revisión Cada una de las versiones que aparecen en el tiempo según se va avanzando en el desarrollo de un ECS. Las revisiones van formando una cadena de revisión: cada revisión es una actualización de, y viene a sustituir a, la anterior.

Grafo de evolución (grafo de revisión)

Representación gráfica de las diferentes revisiones de un ECS y sus relaciones de sucesión temporal: 1 → 2 → 3 → ...

Modelo de trabajo: Check-in / Check-out

CHECKOUT: se extrae una copia del repositorio al entorno local de trabajo
(Modificación local)
CHECKIN: se introduce la copia modificada de vuelta al repositorio creando una nueva revisión

Las herramientas de control de versiones almacenan solo una de las revisiones (la primera o la última) y guardan la historia de cambios (deltas) para poder recuperar cualquier otra.

Deltas

Delta La secuencia de operaciones que, aplicadas sobre la revisión r1, dan como resultado la revisión r2.

Clasificación	Tipo	Descripción
Dirección	Directos	Desde la versión más antigua hacia la más reciente
Dirección	Inversos	Desde la versión más reciente hacia la más antigua
Localización	Separados	El delta se almacena en un fichero separado
Localización	Mezclados	El delta se mezcla con el fichero de la revisión

Variantes, Releases y Building

Variantes

Variante Versiones de un ECS que coexisten en un determinado momento y que se diferencian en ciertas características. Una variante no reemplaza a otra (como sí hacen las revisiones), sino que abre un nuevo camino de desarrollo. Se reconocen en el grafo de evolución como una ramificación.

Tipo	Subtipo	Descripción
Temporales	De exploración	Para explorar diferentes soluciones alternativas en paralelo y quedarse con la mejor
	De pruebas	Con elementos especiales para facilitar la realización de pruebas
	En paralelo (de uso y tirar)	Varias personas trabajan simultáneamente sobre la misma versión; se mezclan al acabar
Permanentes	De requisitos de usuario	El caso más típico era el idioma en las aplicaciones
Permanentes	De plataforma	Una variante por cada sistema operativo o plataforma hardware

Configuraciones alternativas y Release

Release Una configuración del sistema que se va a comercializar o entregar al cliente. Debe identificarse y almacenarse para poder recuperarla en cualquier momento. La GCS también se encarga de controlar la gestión e instalación de releases.

Las configuraciones alternativas se especifican mediante los ECS que las componen y la versión adecuada de cada uno. Se pueden usar atributos de versión y una especificación de configuración para recuperar los ECS adecuados.

Building (Construcción)

Building Actividad que gestiona la compilación y el enlazado de los distintos componentes. Necesita saber qué componentes enlazar, en qué versión y dónde están. Toma esta información de la identificación de la configuración y el control de versiones.
Make: herramienta que facilita la construcción automática de una configuración concreta (recupera ECS en la versión adecuada, los compila y linkea).

Gestión de problemas

Actividad complementaria al control de cambios. Gestiona la evolución de los problemas detectados sobre el software (tanto en pruebas como informes de usuarios). Las tareas incluyen: admisión y registro de incidencias, asignación a responsable, monitorización del estado, registro de actividades de corrección, generación de informes.

Control del trabajo en equipo

Al compartir elementos de trabajo existe el riesgo de sobreescritura de cambios. La solución es el desarrollo en paralelo con variantes. La necesidad resultante es la operación de integración (merge) para combinar los cambios de todas las variantes.

Influencia de la GCS

La GCS tiene gran influencia en: metodologías de desarrollo · entorno de desarrollo (herramientas) · organización (nuevos roles/procedimientos) · calidad (integridad del producto).

V/F Preguntas Verdadero/Falso — Examen

Preguntas recopiladas de exámenes y prácticas. Ordenadas por tema.

T1 — Proceso Software

✓ VERDADERO

Para definir calidad es suficiente con establecer con anticipación parámetros cuantificables y verificables enfocados desde un punto de vista concreto.

Los parámetros de calidad deben ser cuantificables y verificables, y definirse por anticipado desde el punto de vista elegido.

✓ VERDADERO

La estimación afecta al ciclo de vida.

La estimación de duración, coste, esfuerzo y recursos influye en cómo se planifica y gestiona el proyecto a lo largo del ciclo de vida.

✓ VERDADERO

El incremento del grado de cumplimiento en los proyectos de desarrollo se debe a la mejora de la gestión de proyectos. (parcialmente)

Si se refiere a causa única es falso, pero si no lo especifica puede ser verdadero. La mejora en gestión contribuye, junto a otros factores.

T2 — Planificación

✓ VERDADERO

Si no se hace seguimiento se pierde el control del proyecto sin importar lo buena que sea tu planificación.

No puedes controlar lo que no puedes medir. Sin seguimiento los imprevistos no se detectan.

✓ VERDADERO

Una línea base puede tener sobrecargas.

Se puede establecer la línea base aunque haya sobrecargas de recursos.

✗ FALSO

En MS-Project, el camino crítico siempre será un camino continuo desde el principio al final del proyecto.

El camino crítico puede no ser continuo si hay actividades en paralelo, etc.

✗ FALSO

El ciclo de vida solo es aplicable cuando se está desarrollando el proyecto.

El ciclo de vida incluye análisis, diseño, pruebas y mantenimiento, no solo desarrollo.

✗ FALSO

Para aplicar CPM y calcular las fechas early y late es imprescindible conocer las asignaciones de los recursos.

El análisis de tiempos para CPM NO tiene en cuenta los recursos. Solo necesita duraciones y restricciones lógicas.

✓ VERDADERO

Es un hito si tiene trabajo y duración 0.

Cuidado: tiene TRABAJO y duración 0 (no que "tenga duración 0 sin trabajo").

✓ VERDADERO

El Diagrama de Gantt tiene una estrecha relación con las Redes de Precedencia, pues es una representación simplificada de éstas.

El Gantt es una representación simplificada de la red de precedencia.

✗ FALSO

En Project no se pueden poner coste a los hitos.

MS-Project sí permite asignar coste a los hitos.

✗ FALSO

MS-Project no controla la correcta aplicación en seguimiento de las restricciones lógicas.

Restricciones lógicas = relaciones. En la planificación sí se tienen en cuenta; en el seguimiento se usan las fechas. Project sí las controla en planificación.

✓ VERDADERO

MS-Project puede identificar sobrecargas que sean "ficticias", pero también permite confirmar si realmente son sobrecargas o no.

✗ FALSO

Una holgura no puede ser negativa.

La holgura SÍ puede ser negativa (indica que el proyecto ya va retrasado).

✗ FALSO

Una demora es proporcional al tiempo de retraso entre tareas.

Solo es aplicable al camino crítico; en general no hay proporcionalidad fija.

✓ VERDADERO

Si acortamos los caminos críticos el proyecto durará menos.

✗ FALSO

Los objetivos que busca la Gestión de Proyectos son la finalización en plazo, dentro del presupuesto y la consecución del nivel de calidad deseado.

Falta el cuarto objetivo: cumplir las especificaciones. No son solo tres.

✗ FALSO

Una tarea CC (comienzo a comienzo) debe empezar al mismo tiempo que la otra tarea.

CC significa que puede empezar una vez que la otra haya comenzado, no que deba empezar exactamente al mismo tiempo.

✓ VERDADERO

A FC B es equivalente a A CC+2d B si A dura 2 días.

✗ FALSO

Si las actividades A y B tienen una relación CC con C, C puede empezar si A tiene el 50% de realización.

CC implica que C puede empezar cuando A y B hayan COMENZADO, no cuando tengan un determinado porcentaje.

✓ VERDADERO

Para crear una tarea hamaca en Project es necesario crearla como tarea resumen.

✗ FALSO

En una hamaca se pueden poner relaciones.

Las restricciones (relaciones) deben ponerse sobre tareas elementales, no sobre hamacas.

✗ FALSO

Planificación y seguimiento de proyecto son KPA de CMMI Nivel 3.

Son KPA del CMMI Nivel 2 (no nivel 3).

✗ FALSO

Al establecer línea de base en MS-Project, los datos previstos "se copian" en los datos actuales.

Es al revés o no ocurre tal copia directa.

✗ FALSO

Una efectiva gestión de proyectos sólo requiere poner en ejecución buenas prácticas de desarrollo.

Requiere también planificación disciplinada, mediciones adecuadas, acciones correctivas y liderazgo. El "sólo" la hace falsa.

✗ FALSO

Un trabajador solo necesita saber dónde tiene que trabajar, cuándo, con qué esfuerzo y qué tiene que hacer.

También necesita saber cuánto va a cobrar (condiciones económicas).

T3 — Gestión de Riesgos

✓ VERDADERO

En la gestión de riesgos, para cuantificar los riesgos no tienen por qué tomarse las mismas medidas en todos.

Los umbrales de actuación son B/M/A y dependiendo del nivel se aplican acciones distintas.

✓ VERDADERO

Aunque haya una forma de priorizar riesgos, a veces el Jefe de Proyecto puede y debe tratar como relevantes riesgos que no lo son atendiendo a su priorización.

Algunos riesgos con baja probabilidad pero gran impacto deben tratarse aunque no ocupen posición alta en la lista.

✗ FALSO

Si haces gestión de riesgos no es necesario hacer gestión de problemas.

La gestión de riesgos NO exime de hacer gestión de problemas cuando sea necesario.

✗ FALSO

La cuantificación no es imprescindible para priorizar los riesgos.

Para priorizar riesgos ES imprescindible un método de cuantificación o valoración.

✓ VERDADERO

La fórmula ER = I × P sirve para estimar un riesgo (Impacto × Probabilidad).

"Magnitud de pérdida" es el impacto. ER = P × I.

✓ VERDADERO

Delphi es la técnica más conocida de aproximación por juicio de expertos para estimación.

T4 — GCS

✗ FALSO

En el GCS se pueden hacer modificaciones sin tener que formalmente decir qué cambios hiciste.

Una vez establecida la línea base, cualquier cambio requiere procedimiento formal.

✓ VERDADERO

Los cambios en la configuración se controlan en GCS a través de Auditorías de configuración. (debate)

Según daypo es verdadero; aunque el "control de cambios" es la actividad específica, las auditorías también verifican los cambios. Considerarlo verdadero en el examen.

✓ VERDADERO

La integridad de los productos se chequea en GCS a través de su actividad de Auditorías de configuración.

✓ VERDADERO

La GCS está dentro de las disciplinas de control de la integridad de los productos.

✓ VERDADERO

Una variante implica una configuración alternativa.

✓ VERDADERO

Una variante/release se ve en un grafo de evolución como una ramificación.

✓ VERDADERO

La gestión de la configuración del software se encarga de la evolución del software.

✗ FALSO

Un Plan de Proyecto es el único producto de salida (entregable) de las actividades de Gestión de Proyectos que habría que someter a Gestión de la Configuración del Software.

Se entregan muchas más cosas: plan de riesgos, de problemas, de calidad, etc.

✓ VERDADERO

La integridad del producto es gestionada en su fase de control mediante la GCS.

✓ VERDADERO

Hay al menos 3 razones que justifican, en GCS, la necesidad de tener disponibles las versiones intermedias de un ECS.

Para saber la última versión, la relación entre versiones, y dónde están.

✓ VERDADERO

En la GCS, la visibilidad se define en la fase de identificación de la configuración.

✗ FALSO

En el ciclo de vida incremental, si un incremento está mal, afectará a incrementos anteriores y posteriores.

No tiene por qué romper los anteriores; solo si en el incremento se tocan partes comunes.

Comunicación / Negociación

✓ VERDADERO

En una conversación están todos los implicados: personas, narrador, emisor, etc.

REF Datos Clave para el Examen

Fórmulas y cifras

PERT T = (Optimista + 4×Más_probable + Pesimista) / 6 Earned Value CV = BCWP - ACWP (negativo = gasta más) SV = BCWP - BCWS (negativo = va más lento) TCE = ACWP + ETC Exposición al Riesgo ER = Probabilidad × Impacto Comunicación no verbal 65–80% del total de la comunicación Defectos por KLOC ~100 defectos/KLOC | tasa detección pruebas < 50%

Tabla resumen de restricciones

Tipo	Condición	Ejemplo	¿La más usual?
FC (FS)	B empieza cuando A termina	Pulir → Pintar	Sí, la más usual
CC (SS)	B empieza cuando A empieza	Fontanería + Electricidad	No
FF	B termina cuando A termina	Backup + Instalar PC nuevo	No
CF (SF)	B termina cuando A empieza	Vigilancia central nuclear	Poco usual

Niveles CMMI relevantes

Nivel	Nombre	KPAs relevantes del curso
1	Inicial	—
2	Repetible	Planificación y seguimiento de proyectos
3	Definido	—

Resumen 4 Actividades GCS

Actividad	Propósito
1. Identificación	Definir y etiquetar ECS y sus relaciones. Base del proceso. Donde se define la visibilidad.
2. Control de cambios	Gestionar cómo evoluciona el producto. Ningún cambio sin evaluación y aprobación.
3. Informes de estado	Registro histórico. Estadísticas. Ayuda a decidir si arreglar o reescribir.
4. Auditoría	Verificar integridad: producto completo, cumple requisitos, rendimiento correcto.

Las 4 partes de la Negociación Conveniente

Separar las personas del problema
Centrarse en los intereses, no en las posiciones
Inventar opciones para beneficios mutuos
Insistir en criterios objetivos

Las 6 técnicas de asertividad

Mensajes YO
Disco rayado
Banco de niebla
Aplazamiento asertivo
Ignorar
Pregunta asertiva

ENE 26 Examen Enero 2026 — Resuelto

Examen real con respuestas razonadas. Las V/F incluyen la justificación exacta desde las diapositivas oficiales.

Verdadero / Falso

✓ VERDADERO

Es altamente recomendable establecer una clasificación de proyectos de cara a Gestión de Proyectos y de Riesgos y emplearla también para segmentar los históricos para Estimación.

Las actividades y WBS se definen "de acuerdo a la tipología del proyecto" (desarrollo, viabilidad, implantación…). Los perfiles de riesgo son distintos por categoría (tabla T1). Para estimación, CMMI nivel 2 busca repetibilidad: comparar históricos solo tiene sentido entre proyectos del mismo tipo.

✓ VERDADERO

En notación ADM las relaciones de precedencia entre las actividades son del tipo acabar-para-empezar.

ADM usa vectores para actividades y nodos para eventos/hitos. Sus tres tipos de relaciones (lineales, convergencia, divergencia) son variaciones estructurales, pero todas son fin-a-comienzo (FS/FC). Precisamente por no soportar CC, FF ni CF es una técnica poco empleada frente a PDM.

✓ VERDADERO

Si MS-Project identifica una sobrecarga, no es seguro que ese recurso realice más esfuerzo del posible.

MS-Project puede identificar sobrecargas "ficticias" y permite confirmar si realmente son sobrecargas o no. Por tanto, la detección no garantiza que sea real.

✓ VERDADERO

Una buena estrategia es usar las modalidades de seguimiento que ofrece MS-Project en función de la holgura de la tarea sobre la que se hace seguimiento.

Para tareas críticas (holgura = 0) el seguimiento debe ser más preciso y frecuente; para las no críticas hay más margen. El jefe de proyecto usa la holgura para priorizar la atención en el seguimiento.

✓ VERDADERO

Para calcular las fechas early y late en CPM no se necesitan conocer las asignaciones de los recursos.

Literal en las diapositivas: "El análisis de tiempos no tiene en cuenta los recursos necesarios, ni su disponibilidad, para el cálculo del camino crítico." Solo se necesitan duraciones y restricciones lógicas.

✗ FALSO

Al establecer línea base en MS-Project, los datos reales "se copian" en los datos previstos.

Al establecer línea base se copian los datos actuales planificados (el schedule actual) en los campos de línea base. Los datos reales (trabajo ya realizado) no se tocan.

✓ VERDADERO

Al establecer línea base en MS-Project, los datos actuales "se copian" en los datos previstos.

Operación correcta: el estado actual de la planificación queda fotografiado como línea base (previstos). "Actuales" aquí significa el plan vigente, no el trabajo real ya registrado.

✗ FALSO

Al establecer línea de base en MS-Project, los datos previstos "se copian" en los datos actuales.

Exactamente al revés: los actuales van a los previstos, no al contrario.

✗ FALSO

MS-Project siempre pintará el Camino Crítico como un camino continuo desde el principio al final del proyecto.

Pueden existir varios caminos críticos y el camino puede ser discontinuo. En clase se mostró con ejemplos en Project que esto puede ocurrir.

✗ FALSO

A FC B es equivalente a A CC+2d B si la duración estimada de A es 2 días.

Trampa: "estimada" ≠ "real". Si la duración estimada es 2 días pero A tarda 3 días en la ejecución real, la equivalencia no se cumple. La equivalencia solo es válida con la duración real/actual.

✓ VERDADERO

A FC B es equivalente a A CC+2d B si A dura 2 días. (versión de otro año)

Aquí "dura" es la duración real. FC = la restricción se activa al terminar A; CC+2d = la restricción se activa 2 días después del comienzo de A. Si A dura exactamente 2 días reales, ambas expresiones son equivalentes.

✗ FALSO

Si para un riesgo se ha calculado su ER y es baja, el Jefe de Proyecto no puede tratar ese riesgo como relevante.

Las diapositivas dicen explícitamente: "Algunos riesgos pueden priorizarse independientemente del lugar que ocupen en la lista: riesgos que producirían pérdidas considerables con una baja probabilidad." El ER es un indicador, no una obligación.

✗ FALSO

La GCS es una disciplina dentro de la Ingeniería del Software cuya única misión es la de controlar la evolución de un sistema software durante su ciclo de desarrollo.

Tres errores: (1) "única misión" → tiene dos objetivos: visibilidad (estado Y evolución) e integridad; (2) solo dice "evolución" pero también controla el estado actual; (3) "ciclo de desarrollo" → es el ciclo de vida completo, incluyendo mantenimiento.

Preguntas abiertas

2 · Tres características genéricas de un proyecto (1 punto)

Característica	Descripción exacta (diapositivas)
Discreto	Con inicio y fin definidos, y un producto final a obtener
Complejo	Con un conjunto de diferentes tareas interrelacionadas
Único	En relación a su producto final y a su entorno de desarrollo

Complemento Un proyecto no es un proceso cotidiano ni rutinario (funciones normales).

3 · Entregables de Gestión de Proyectos que deben someterse a control de versiones en GCS (1 punto)

Cualquier documento generado durante la gestión del proyecto es un ECS: evoluciona, tiene sucesivas versiones y cualquier cambio debe estar controlado. Los principales son:

Plan de Proyecto — se actualiza a lo largo del ciclo de vida
Plan de Gestión de Riesgos — se revisa en cada ciclo de seguimiento
Informes de seguimiento / Informes de situación — cada iteración genera una nueva versión con datos actualizados
Plan de Calidad
Actas del Comité de Seguimiento

Trampa de examen La V/F "el Plan de Proyecto es el único entregable que habría que someter a GCS" es FALSA exactamente por esto.

4 · Tres opciones técnicas en la "parte de opciones" de negociación conveniente (1 punto)

De las opciones listadas en las diapositivas para la planificación de proyectos software:

Entrega incremental priorizando prestaciones: ciclos de desarrollo evolutivos — se entrega lo más importante antes de la fecha límite impuesta
Reducción de prestaciones: implementarlas solo hasta cierto punto (funcionalidad básica en fecha, avanzada después)
Eliminación de prestaciones: suprimir funcionalidades considerando integraciones con otros sistemas ya existentes
(alternativa) Empleo de componentes comerciales preconstruidos: aunque no se ajusten exactamente, aceleran el desarrollo

5 · Baja laboral de R1 el día 2 — cómo actualizar Project (1 punto)

Establecer el Time Now en la fecha en que R1 inicia la baja (inicio del día 3 de la tarea T)
Registrar el trabajo real de R1: introducir las horas/días reales trabajados por R1 (los 2 días completados)
Poner el trabajo pendiente de R1 = 0: indicar que R1 no realizará más trabajo en esta tarea
Bloquear la disponibilidad de R1 en su calendario de recurso durante el período de baja (evita que Project lo asigne en otros proyectos)
Añadir R2 como recurso a la tarea T con fecha de inicio = día siguiente a la baja de R1
Asignar a R2 el trabajo pendiente (el restante de la tarea T)
Recalcular: Project ajusta las fechas de finalización de T según disponibilidad y carga de R2

6 · Modelar el coste de la supercomputadora alquilada (13.000 €/mes) (1 punto)

La supercomputadora es un recurso de maquinaria (recurso no humano recurrente, no consumible). En MS-Project:

Crear un recurso nuevo en el pool de recursos: nombre "Supercomputadora LeaderGPU"
Tipo: Costo (Cost resource) en versiones modernas, o Trabajo/Maquinaria con tasa mensual
Asignar el coste: 13.000 €/mes como tasa estándar (o convertido a €/hora si Project lo requiere: 13.000 ÷ horas laborables del mes)
Asignarlo a las tareas que usan la supercomputadora durante su duración (o al proyecto completo si se usa durante toda su vida)

Resultado Project calculará automáticamente el coste total multiplicando la tasa por la duración de uso. Queda como elemento de coste trazable en los informes de seguimiento de costes junto a los recursos humanos.