Tema 4. Planificación (riesgos, calidad) y gestión de cambios

Tema 4. Planificación y diagramas de
Gantt
Grado en Diseño y Desarrollo de Videojuegos (Quintana)
Autor: Oriol Borrás Gené
GestiónyDireccióndeProyectos

Objetivos
o Profundizar en la aplicación de Diagramas de Gantt en la
gestión de proyectos.
o Conocer los principios de la gestión de la calidad en un
proyecto.
o Ofrecer una visión general de la gestión de riesgos de un
proyecto.
o Revisar los aspectos principales de la gestión del cambio en
un proyecto durante los procesos de ejecución y monitoreo.
Objetivos

• Es una herramienta que sirve para planificar y programar tareas a lo largo de un periodo determinado de
tiempo.
• Reproduce gráficamente las tareas, su duración y secuencia. Además del calendario general del proyecto y la
fechas de finalización prevista.
• Es una salida del grupo de procesos de planificación, el proceso de “Desarrollar el cronograma”, una de las
formas en las que se puede presentar. Otras son, por ejemplo, los diagramas de hitos.
• Consiste en un gráfico de barras horizontales ordenadas por actividades a realizar:
• En el eje vertical están las tareas o actividades (desde el inicio al final del proyecto)
• El eje horizontal hace referencia al tiempo, el cual se deberá definir (días, semanas, meses, semestres o
años)
• Es recomendable resaltar las tareas críticas, por ejemplo, con otro color.
• Permite mostrar de manera visual las tareas a realizar, las interdependencias entre ellas y su temporalización.
• Sirve también para monitorear los proyectos una vez iniciados para descubrir puntos críticos, periodos de
inactividad y para calcular los retrasos de ejecución.
• Se suele emplear en pequeñas y medianas empresas.
Diagramas de Gantt

Diagramas de Gantt
Construir un diagrama de Gantt
1. Definir las tareas, actividades y etapas del proyecto
2. Analizar su duración
3. Estableces dependencias entre actividades
4. Concretar prioridades
5. Asignar recursos y distribuir cargas de trabajo
6. Dibujar los ejes horizontal y vertical
7. Definir las tareas y actividades en el eje vertical
8. Dibujar bloques de tareas que no tengan tarea o actividad predecesora (inicio del
proyecto).
9. Añadir los bloques de tareas o actividades que dependan de las ya dibujadas.
PERT
PERT/CPM
• Definir holguras
• Re-planif. Camino crítico
• Re-organizar cronograma (por
retrasos de actividades)
• Re-asignar recursos

Diagramas de Gantt
Diagramas de Gantt como arma de destrucción masiva de proyectos.
1. Confiar ciegamente en los porcentajes de avance que muestran las barras de diagrama
Gantt.
2. Planificar un Gantt de proyecto en función del tiempo disponible y no en función del
tamaño del software a desarrollar.
3. Crear un Gantt ajeno al calendario real.
4. Fijar inamoviblemente una fecha “real” de fin de proyecto, independientemente de la
fecha de comienzo del proyecto.
5. Crear un Gantt gigante, a veces de años, y en el mismo fijar el día exacto en el que
finalizará el proyecto.
Fabricar software no es lo mismo que fabricar casas (link)
Fuente: https://www.javiergarzas.com/2012/06/diagramas-gantt.html

Gestión de calidad >> Planificar la gestión de la calidad
• Proceso de identificar los requisitos y/o estándares de calidad para el proyecto y sus
entregables, así como de documentar cómo el proyecto demostrará el cumplimiento
con los mismos
• Se deberá planificar y diseñar antes de que empiece la ejecución del proyecto.
• La calidad es “El grado en el que un proyecto cumple con los requisitos”.
• El grado está relacionado con la funcionalidad, forma u otras características del
producto. Un producto de grado bajo (pocas funcionalidades) puede tener una gran
calidad.
• El método Kaizen se basa en realizar pequeñas mejoras involucrando a todos en una
organización, desde directores a trabajadores.
• Ley de rendimientos marginales decrecientes, supone que el nivel de productividad
va disminuyendo a medida que se añaden más recursos en un proceso si el resto de
recursos permanece sin variación.
Gestión de proyectos: PMBOK

Entradas:
• Plan de dirección del proyecto:
• Línea base del alcance
• Línea base del cronograma
• Línea base de costos
• Registro de los interesados
• Registro de riesgos
Fuente: PMBOK (5ª edición)

Herramientas y técnicas:
• Diagrama causa-efecto o diagramas de Ishikawa.
• Diagramas de flujo
• Hojas de verificación
• Histogramas
• Diagramas de Pareto
• Diagramas de control
• Diagrama de dispersión

Gestión de calidad >> Planificar la gestión de la calidad >> salidas
Plan de gestión de la calidad
• Describe cómo se implementarán las políticas de calidad de una organización. Cómo el
equipo del proyecto planea cumplir los requisitos de calidad establecidos para el
proyecto.
• Puede ser formal o informal, detallado o formulado de manera general (en función de
los requisitos del proyecto).
Plan de mejoras del proyecto
• Detalla los pasos necesarios para analizar los procesos de dirección del proyecto.
• Áreas a tener en cuenta: límites del proceso, configuración del proceso, métricas del
proceso y objetivos de mejora del desempeño.

Métricas de calidad
• Describe de manera específica cada atributo del producto o del proyecto, y la manera en
que se medirá (valor real) el proceso de control de calidad.
• Habrá que indicar una tolerancia, la cual define las variaciones permitidas de las
métricas.
• Se emplean en los procesos de realizar el aseguramiento de calidad y de controlar la
calidad.
• Ejemplos: índice de puntualidad, el control del costo, la frecuencia de defectos, etc.

Listas de verificación de calidad o “checklist”
• Herramienta estructurada que sirve para comprobar que se hayan seguido todos los
pasos necesarios para cada ítem de calidad definido.
• Pueden ser sencillas o complejas, en función de los requisitos y prácticas del proyecto.
• Hay organizaciones que disponen de listas de verificación estandarizadas para asegurar
la consistencia en tareas que se realizan con frecuencia.

Ejemplo de plan de calidad de software
https://es.calameo.com/read/005688295503182877ba8

PROYECTO
Riesgo
• Evento o condición incierta que, en caso de darse, tendrá un
efecto positivo o negativo sobre los objetivos de un proyecto.
• Tiene una o más causas y en el caso de darse, uno o más
impactos (efectos).
• Los riesgos conocidos son aquellos que han sido identificados y
analizados durante la planificación del proyecto.
Gestión de riesgos
• Identificar, analizar y dar respuesta a los riesgos del proyecto.
• Maximizar la probabilidad y consecuencias de eventos positivos.
• Minimizar la probabilidad y consecuencias de eventos negativos.
Causas
Efectos /
impactos
RIESGO
(evento o
condición)
Pueden ser aspectos del entorno del proyecto u organización

Gestión de riesgos
• Objetivo general: identificar, estudiar y eliminar las fuentes de riesgo antes de que
empiecen a amenazar el cumplimiento satisfactorio de un proyecto software.
• Es habitual gestionar riesgos con efecto negativo amenaza para el éxito del proyecto.
5 niveles de gestión de riesgos (- a + exigencia):
1. Control de crisis
2. Arreglar cada error
3. Mitigación de riesgos
4. Prevención
5. Eliminación de causas principales
Planificación

Gestión de riesgos
Fuente: http://todopmp.com/planificar-la-gestion-los-riesgos/

Gestión de riesgos >> Normas y estándares (para software)
• MAGERIT – Metodología de Análisis y Gestión de Riesgos de los Sistemas de
Información. Versión actual 3.0 elaborada por el Consejo Superior de Administración
Electrónica (CSAE) del Gobierno de España.
• Objetivo: minimizar los riesgos de la implantación y uso de las TIC, enfocada a las Admin. públicas
• Libro I – Método (pdf)
• Libro II – Catálogo de elementos (pdf)
• Libro III – Guía de Técnicas (pdf)
• Enlace:
https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Met
odolog/pae_Magerit.html#.XXEVDpMzbOQ
• IEEE Std 1540-2001 – IEEE Standard for Software Life Cycle Processes – Risk
Management (pdf) – más info:
http://www.psmsc.com/UG2001/Presentations/06IEEEStandard1540.PDF

Gestión de riesgos >> Planificar la gestión de riesgos
• Salida es el Plan de gestión de riesgos:
• Es parte del Plan de Gestión del Proyecto y describe cómo se estructurará y realizará
la gestión de riesgos del proyecto.
• Contenido:
• Metodología: enfoques, herramientas y fuentes de datos.
• Roles y responsabilidades (líder, apoyo y miembros del equipo de g. de riesgos).
• Presupuesto: estima, sobre la base de los recursos asignados, los fondos
necesarios para su inclusión en la línea base de costos, y establece los protocolos
para la aplicación de la reserva para contingencias y la reserva de gestión.
• Calendario: cuándo y con qué frecuencia se llevarán a cabo los procesos de g. de
riesgos a lo largo del ciclo de vida del proyecto; protocolos para la utilización de
las reservas para contingencias del cronograma; y las actividades de gestión de
riesgos a incluir en el cronograma del proyecto.

• Salida es el Plan de gestión de riesgos:
• Es parte del Plan de Gestión del Proyecto y describe cómo se estructurará y realizará
la gestión de riesgos del proyecto.
• Contenido:
• Categorías de riesgo.
• Definiciones de la probabilidad e impacto de los riesgos.
• Matriz de probabilidad e impacto.
• Formatos de los informes. cómo se documentarán, analizarán y comunicarán los
resultados del proceso de gestión de riesgos. Describe formato y contenido.
• Seguimiento: documenta cómo se registrarán las actividades de gestión de
riesgos para beneficio del proyecto en curso y cómo se auditarán los procesos de
gestión de riesgos.

Categorías de riesgo
• Permiten agrupar las causas potenciales de riesgo.
• Existen diversos enfoques: listas de riesgos, estructura de
desglose del riesgo (RBS), …
• La RBS es una representación jerárquica de los riesgos
según sus categorías, éstas cambian según el tipo de
proyecto.Por ejemplo en un proyecto software podrían
ser:
• Técnicas
• Externas
• De la organización
• Dirección de proyectos
Proyecto
Técnica
Requisitos
Tecnología
Calidad
...
Externa
Mercado Cliente
Condiciones
climáticas
Subcontratas y
proveedores
...
Interna

Definiciones de la probabilidad e impacto de los riesgos:
• Será clave definir distintos niveles de probabilidad e impacto de riesgos.
Objetivo de
Proyecto
Muy bajo
(0,05)
Bajo
(0,10)
Medio (0,20) Alto
(0,40)
Muy Alto
(0,80)
Alcance
Cronograma
Costo
Calidad
Muy Alta
Alta
Media
Baja
Muy Baja
EJEMPLO: https://www.iberley.es/revista/concepto-riesgo-probabilidad-
impacto-evaluacion-impacto-proteccion-datos-219
EJEMPLO: http://pmbokuacm.weebly.com/gestioacuten-de-los-riesgos.html

Matriz de probabilidad de impacto
• Cuadrícula para vincular la probabilidad de ocurrencia de cada riesgo con su impacto
sobre los objetivos del proyecto en caso de que ocurra dicho riesgo.
• Detectar riesgos más críticos del proyecto
• Se puede utilizar una matriz de amenazas y otra de oportunidades (también se
puede fusionar en una única):
Impacto
Probabilidad
Muy Bajo Bajo Medio Alto Muy Alto
0,05 0,10 0,20 0,40 0,80
Muy Alta 0,90
Alta 0,70
Media 0,50
Baja 0,30
Muy Baja 0,10
Se puede rellenar:
• Numéricamente: Riesgo =
probabilidad x impacto
• Con códigos de colores y
textuales (bajo, medio, alto y
muy alto)
https://www.eoi.es/blogs/mcalidadon/2016/02/03/la-matriz-probabilidad-
impacto/
0 – imposible
1 – siempre

Matriz de probabilidad de impacto
• Finalmente, ubicar en cada cuadrícula las actividades del proyecto con posibilidad de
riesgo.
Impacto
Probabilidad
Muy Bajo Bajo Medio Alto Muy Alto
0,05 0,10 0,20 0,40 0,80
Muy Alta 0,90 MUY ALTA MUY ALTA
Alta 0,70 MUY ALTA
Media 0,50
Baja 0,30
Muy Baja 0,10
23
1
11

Aproximación al cálculo de reservas de contingencia.
• Se calculará el Impacto global para cada riesgo identificado
VME = % x impacto (€/tiempo).
% - Probabilidad de que se de un riesgo
Impacto – coste si se da el riesgo
• La suma de todos los VME del listado de riesgo será la Reserva de contingencia, si
sumamos la estimación de la EDT tendremos la línea base de costo. A esta habría
que añadirle la reservas de gestión (riesgos no identificados).

Gestión de riesgos >> Identificar los riesgos
• A partir del plan general podemos identificar los riesgos y obtener como resultado:
• Lista de riesgos identificados (luego se puede ir ampliando), algunas categorías
de riesgos software potenciales: elaboración de la planificación, organización y
gestión, ambiente/infraestructura de desarrollo, usuarios finales, cliente,
personal contratado, requisitos, producto, fuerzas mayores, proceso, …
• Lista de respuestas potenciales.
Fuente: PMBOK (5ª edición)

Gestión de riesgos >> Análisis cualitativo de riesgos
• Priorizar los riesgos identificados evaluando la probabilidad de ocurrencia y su
impacto en los objetivos principales del proyecto.
• Se centra en cada riesgo de manera independiente.
• Se va a evaluar:
• La probabilidad de que se de el riesgo
• El impacto del riesgo, en que proporción afecta a los objetivos básicos del
proyecto (p.ej.: cronograma, coste, …).
• Los criterios para establecer estos valores viene del plan de g. de riesgos, resumidos
en la matriz de probabilidad de impacto

Gestión de riesgos >> Análisis cuantitativo de riesgos
• Analizar los riesgos identificados del proyecto para obtener información
cuantitativa(resultados numéricos) sobre su efecto global sobre los objetivos
principales del proyecto.
• Se tendrá en cuenta las relaciones entre los propios riesgos.
• Habrá que priorizar aquellas áreas clave para cumplir los objetivos del proyecto, a la
hora de decidir los riesgos a mitigar.
• Es un proceso complejo y costoso, requiere información de calidad de un número
adecuado de proyectos para poder desarrollar modelos numéricos fiables.
• Si nuestra organización no está capacitada será necesario plantear este proceso a
medio y largo plazo.
• Técnicas: probabilidad y estadísticas; inteligencia artificial; simulaciones
(Montecarlo); …

Gestión de riesgos >> Planificar la respuesta a los riesgos
• Desarrollar opciones y acciones para mejorar las oportunidades y reducir las
amenazas a los objetivos del proyecto.
• Cómo responder a cada riesgo.
• Se asigna un responsable (propietario de la respuesta a los riesgos) para dar
respuesta a cada riesgo.
• Conceptos:
• Riesgo residual, permanece después de haber implementado la respuesta.
• Riesgo secundario, nuevo riesgo que se origina como consecuencia directa de la
respuesta a otro/s riesgo/s.
• Estrategias:
• Riesgos negativos : evitar, transferir (a parte menos crítica), mitigar y aceptar.
• Riesgos positivos: explotar, compartir, mejorar y aceptar.

Riesgos negativos :
• Aceptar el riesgo:
• Comprendemos que el riesgo se puede dar
• Tenemos un plan para actuar si se da el riesgo
• No tomamos acciones preventivas
• Evitar:
• Cambiamos la planificación para eliminar el riesgo.
• Transferir el riesgo
• Convertimos a otra parte responsable del riesgo, no es que desaparezca el riesgo, si no que
encargamos a alguien más cualificado para resolverlo que lo asuma.
• Mitigar el riesgo:
• Realizar acciones que hagan que el riesgo sea menos probable o que su impacto sea menor.

Desarrollamos un videojuego y en la fase de testing tenemos consolas para enviar a
nuestros betatesters, pero estas están muy viejas y utilizadas.
 Eliminarlos: compramos nuevas y se las enviamos. Mejor solución, pero es cara. Nos las
pueden robar nuevos riesgos.
 Mitigarlos, compramos nuevos mandos, hay probabilidad que los problemas surjan ahí
(no estamos seguros que será eso).
 Transferirlo, imponemos que los testeadores tengan consola.
 Aceptarlo, nos arriesgamos sin hacer nada y ver que pasa, esto podría retrasarlo todo.
 Escalarlo, se lo comentamos al sponsor y que decida. Si somos una empresa grande EA
seguramente tendremos más videojuegos y será una inversión a medio plazo
interesante.

Grupo de procesos de ejecución (10)
• Se coordinan todos los recursos para implementar el plan para la dirección del proyecto.
Grupo de procesos de monitoreo y control (12)
• Se supervisa el avance del proyecto y aplican acciones correctivas.
Grupo de procesos de cierre (1)
• Se aceptan formalmente los entregables del proyecto.

Ejecución y monitoreo: Gestión del cambio
Línea base
• Cualquier producto, descripción, rol, que se ha aprobado y que
es lo que está autorizado a hacer.
• Sirve para ir comprobando lo ejecutado contra lo
planificado/aprobado, que son las líneas base.
• Un plan aprobado es una línea base, hay tres en un proyecto
según el PMBOK:
• Alcance
• Tiempo
• Coste

Trazabilidad
Saber lo que ha ocurrido, para poder responder a nuestros clientes
u organización.
Cambios
A medida que se desarrolla el proyecto pueden surgir cambios,
algo que no siempre es negativo pues pueden ser para mejorar el
producto final.

Gestión de la configuración (versiones)
• Gestionar los distintos cambios y las versiones que se van
obteniendo.
• Establecer la forma de controlar las versiones, una sistemática.
• Si queremos tener gran control podemos trabajar con muchos
elementos de configuración, frente a agruparlos para simplificar,
pero con menor control de esa gestión.
• Detectar o categorizar los cambios. Ver si un cambio en el
presupuesto ha sido debido a aspectos negativos (errores en la
planificación o problemas que hayan surgido) o positivos
(incremento en el alcance con nuevas funcionalidades del
producto).
• En metodologías ágiles contamos con el Product backlog

Sistema integrado de gestión del cambio (SIGC)
1.Petición de cambio (cualquiera del proyecto la puede hacer) [plantilla
en materiales].
2.Análisis de sus beneficios respecto al coste.
3.Generar un documento de solicitud del cambio (será más o menos
completo según el proyecto)
4.Evaluar si se acepta o no, puede ser una persona o incluso un comité
de cambios (grupo de personas adecuadas para tomar la decisión de
cambios).Ante un cambio este se puede:
a) Integrar con el consecuente incremento de tiempos,
costos, etc.
b) Cambio de cromos: eliminar otra funcionalidad menos
importante y así ajustar o sustituir este añadido.
Documentos:
1. Solicitud de cambios
2. Tabla de seguimiento de cambios

Tema 4. Planificación (riesgos, calidad) y gestión de cambios

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Tema 4. Planificación (riesgos, calidad) y gestión de cambios

Ähnlich wie Tema 4. Planificación (riesgos, calidad) y gestión de cambios (20)

Mehr von Oriol Borrás Gené

Mehr von Oriol Borrás Gené (17)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Tema 4. Planificación (riesgos, calidad) y gestión de cambios

Hinweis der Redaktion