Gestión

PLAN DE CALIDAD PARA PRODUCTO DE SOFTWARE

“X-PRO-L”

GONZALO TOMÁS PÉREZ LARA

MEMORIA PARA OPTAR AL TITULO DE

INGENIERO DE EJECUCION EN INFORMATICA

Profesor Guía:
MARCELLO VISCONTI

Profesor Correferente:
LUIS HEVIA

VALPARAISO, CHILE
OCTUBRE, 2005
4. GESTION

4.1 Organización

Jefe
Jefe de
de SQA
SQA

Jefe
Jefe de
de
Proyecto
Proyecto
Unidad
Unidad de
de SQA
SQA Unidad
Unidad de
de SCM
SCM

Jefe
Jefe de
de Jefe
Jefe de
de
Proyecto
Proyecto Proyecto
Proyecto

Ingeniero
Ingeniero de
de Encargado
Encargado de
de Encargado
Encargado de
de Encargado
Encargado de
de
SQA
SQA Diseño
Diseño Seguridad
Seguridad Documentación
Documentación

Jefe
Jefe de
de Jefe
Jefe de
de Jefe
Jefe de
de Jefe
Jefe de
de
Proyecto
Proyecto Proyecto
Proyecto Proyecto
Figura 2: Organización del Equipo de Trabajo
Proyecto Proyecto
Proyecto
La unidad de SQA debe estar organizada para desempeñar sus labores y otorgar un soporte al
desarrollo de software. Para ello, cuenta con tres posibilidades básicas [MUN-00]:

 Cada miembro de la unidad de SQA se especializa en todas sus prácticas y se hace

responsable de las actividades por realizar en el proyecto.
 Cada miembro de la unidad se especializa en un subconjunto de prácticas y provee el soporte
sobre ellas.
 La unidad actúa como un equipo en el cual sus miembros cooperan para llevar a cabo sus
tareas de SQA.

La organización de la unidad de SQA debe contar con:

 Un staff capaz de trabajar independientemente

 La habilidad de mejorar continuamente la forma de llevar a cabo el proceso y las prácticas de
SQA.
 La objetividad y el criterio suficientes para evaluar correctamente los problemas detectados.
 Los conocimientos técnicos para desempeñar las actividades del proyecto.
 La capacidad de comunicación para desempeñar eficientemente sus responsabilidades.

4.2 Recursos

4.2.1 Recursos humanos

Para llevar a cabo el plan de aseguramiento de calidad, se hace necesario contar con un grupo
especializado de SQA, quienes desempeñarán distintas funciones para el cumplimiento de los
objetivos. Se debe guiar al equipo de desarrollo, de tal manera de lograr un producto de alta
calidad. Este grupo de SQA debe representar al cliente dentro de la organización. Se debe dejar en
claro que el grupo de SQA no tiene la total responsabilidad de lograr una alta calidad de la
aplicación multimedia, sino que depende total y absolutamente de todo el equipo u organización.
Se debe mencionar que el esfuerzo requerido en las actividades de SQA es de aproximadamente
el 25% del tiempo total requerido para el proyecto.

Como lo demuestra la experiencia de otras empresas del rubro, una buen distribución de puestos
dentro de ella, es tener un Jefe de SQA quien tendrá la capacidad de liderazgo y experiencia en
 Gestión

otros proyectos, estará a cargo de un grupo de ingenieros de calidad y desarrolladores

(encargados del diseño, documentación, seguridad, programación), por lo que se adoptará la
siguiente distribución de cargos:
 Gestión

Encargado de Diseño Es el encargado de velar por las siguientes

responsabilidades:
 Revisar y comentar el diseño de las interfaces.
 Revisar y validar el formato de las imágenes,
resolución y tamaño, botones.
 Identificar el contenido de las ayudas, su forma
de presentación.
 Completar los informes de SQA.
 Interactuar con las diferentes herramientas
utilizadas para SQA durante el Proyecto.
 Asistir al Ingeniero en las pruebas, revisiones y
diseño.
Encargado de Seguridad Es el encargado de velar por las siguientes
responsabilidades:

 Realizar las pruebas de seguridad del sistema,

errores de programación y caídas del sistema.
 Debe completar los informes de SQA.
 Interactuar con las diferentes herramientas
utilizadas para SQA durante el Proyecto.
 Asistir al Ingeniero en las pruebas, revisiones y
seguridad.
Encargado de Documentación Es el encargado de velar por la identificación,
desarrollo y manutención de la documentación del
proyecto.

Tabla 23: Descripción de Cargos

4.2.2 Infraestructura

El grupo de SQA necesita tener acceso a computadoras que permitan realizar labores de
evaluación y auditoría eficazmente. Para, ello se dispondrá de un equipamiento destinado en el
Plan de Proyecto.

Hardware

 Monitor SVGA 17”


Procesador Atlhon 1700 MHZ

512 MB de RAM

20 GB de HD

Disquetera 3 ½

Lector de CD-ROM, 52x

Mouse USB

Teclado PS2

Impresora Epson Stylus Color 480

Tarjeta de video

Tabla 24: Equipamiento de Hardware

Gestión
 Evaluación del Análisis

SQA debe:
 Comprobar la adherencia de los entregables a los estándares definidos en el Plan de
Proyecto.
 Verificar la adherencia del proceso de especificación de Sistema (Solución Propuesta) a los
procedimientos definidos en el plan de proyecto.
 Garantizar que se revisaron adecuadamente los entregables (Especificación de Sistema,
es decir, Solución Propuesta) de la fase de Análisis.

 Evaluación del diseño

SQA es responsable de:

 Comprobar la adherencia de los entregables a los estándares definidos en el plan de

proyecto.
Gestión
SQA debe verificar que todo producto que se encuentre listo para revisión sea revisado y que las
acciones correctivas identificadas durante la revisión sean implementadas.

 Evaluación de las acciones correctivas

SQA debe analizar los problemas detectados para determinar sus causas, impactos y frecuencia
de ocurrencia, y para establecer acciones preventivas.
Además, SQA es responsable de monitorear la adecuada implementación de las acciones
correctivas derivadas de estos problemas.
Gestión
 Gestión

4.4 Responsabilidades

La autoridad de SQA deriva del gerente técnico de la organización y su principal obligación es

monitorear las actividades del proceso de desarrollo y revisar la adherencia de los productos de
trabajo a los estándares, procedimientos y al plan del proyecto. Los resultados de este seguimiento
deben ser informados al jefe de proyectos y, según sea aplicable, al Gerente Técnico.
En la siguiente tabla se adjunta una matriz de responsabilidades sobre las actividades de SQA
[WEB-01].
Gestión
ID Riesgo
1 Desconocimiento del software a utilizar en la construcción de la aplicación.
2 Pérdidas de información por fallas de Hardware o Software.
3 Insatisfacción por parte del Cliente de la interfaz usuaria.
4 Necesidad de cambiar la herramienta de desarrollo durante el proyecto.
5 La necesidad de cumplir plazos en la planificación podría llevar a sacrificar la calidad del
software.
6 Mala estimación de costos de desarrollo de la aplicación.
7 Falta de recursos de hardware específicos (impresora, entre otros).
8 Un producto similar sale al mercado.
9 Problemas de comunicación entre los integrantes del equipo.
10 Falta de disponibilidad de un integrante del equipo de trabajo.
11 Inexperiencia en desarrollo de proyectos de software por parte de los desarrolladores.
12 Falta de disponibilidad por parte del Cliente para participar en reuniones con los desarrolladores.
13 Mal dimensionamiento del problema (el problema es más grande de lo pensado).
14 Sobredimensionamiento de las capacidades de las herramientas a utilizar.
15 Cambio en los requerimientos.
16 Mala calendarización (estimación de plazos).
17 Mala elección del paradigma de desarrollo.
18 Falta de disponibilidad de la metodóloga en enseñanza y aprendizaje.
19 Alejamiento o abandono del proyecto por parte de la metodóloga en enseñanza y aprendizaje.
20 Escaso entendimiento del proceso del software por parte del Cliente.
21 Problemas de salud de algún integrante del equipo de trabajo.
22 Conflictos al interior del equipo de trabajo.
23 Alejamiento o abandono por parte del diseñador de apoyo en el desarrollo del proyecto.
24 Abandono definitivo por parte de algún integrante del equipo.
25 Plan de capacitación insuficiente

Tabla Nº26: Potenciales Riesgos

4.5.2 Clasificación

En esta etapa se clasifican los riesgos en una de las siguientes categorías:

 Riesgo Técnico: Potenciales problemas de diseño, implantación del sistema, interfaz,

verificación y mantención.
 Riesgo de Negocio: Posibles situaciones o hechos que pueden hacer fracasar la aplicación
una vez terminada.
 Riesgo de Proyecto: Dificultad durante el desarrollo relacionado con los recursos humanos, la
calendarización o la interacción cliente-servidor.
 Gestión

 Riesgos Técnicos:

Tabla Nº27: Riesgos Técnicos

 Riesgos de Negocio:

Tabla Nº28: Riesgos de Negocio

 Riesgos de Proyecto:

Tabla 29: Riesgos de Proyecto

4.5.3 Estimación de los riesgos

Para evaluar cada riesgo, se utilizó una descripción definida de la siguiente manera:

Descripción de los rangos

Muy Alto Significa que la ocurrencia del riesgo es muy probable, o que el impacto en el proyecto es
determinante para el desarrollo de éste.
Alto La ocurrencia del riesgo es probable, o el impacto en el proyecto es considerable, pero no
determinante.
Medio Significa que la probabilidad de que el riesgo se materialice es de un nivel medio, o que el
efecto en el proyecto es moderado
Bajo La ocurrencia del riesgo es casi improbable, o que el impacto en el proyecto tiene un efecto
bajo o casi nulo.
Tabla 30: Descripción de los rangos
 Gestión

Ponderación de los rangos

 Escala de Priorización:

Impacto Probabilidad Prioridad

MA 1 1
MA 0.9 2
MA 0.7 3
MA 0.6 4
MA 0.5 5
A 0.8 6
A 0.7 7
A 0.5 8
A 0.2 9
A 0.1 10
M 0.8 11
M 0.5 12
B 0.3 13
B 0.2 14

Tabla 31: Escala de Priorización

 Riesgos Priorizados:

ID Riesgo Probabilidad Impacto Prioridad

1 Desconocimiento del software a utilizar en la 0.9 MA 2
construcción de la aplicación
2 Pérdidas de información por fallas de hardware 0.7 MA 3
o software
3 Insatisfacción por parte del Cliente de la 0.7 MA 3
interfaz usuaria
4 Necesidad de cambiar la herramienta de 0.5 MA 5
desarrollo durante el proyecto
5 La necesidad de cumplir plazos en la 1 MA 1
planificación podría llevar a sacrificar la calidad
del software
6 Mala estimación de costos de desarrollo de la 0.8 M 11
aplicación
7 Falta de recursos de hardware específicos 0.5 A 8
(impresora entre otros)
8 Un producto similar sale al mercado 0.5 M 12
9 Problemas de comunicación entre los 0.1 A 10
integrantes del equipo
10 Falta de disponibilidad de un integrante del 0.2 B 14
equipo de trabajo
11 Inexperiencia en desarrollo de proyectos de 1 MA 1
software por parte de los desarrolladores
12 Falta de disponibilidad por parte del Cliente 0.8 A 6
para participar en reuniones con los
desarrolladores
13 Mal dimensionamiento del problema (el 0.7 MA 3
problema es más grande de lo pensado)
14 Sobredimensionamiento de las capacidades de 0.7 A 7
las herramientas a utilizar
15 Cambios en los requerimientos 0.6 MA 4
16 Mala calendarización (estimación de plazos) 0.9 MA 2
17 Mala elección del paradigma de desarrollo 0.2 A 9
18 Falta de disponibilidad de la metodóloga en 0.2 A 9
enseñanza y aprendizaje
19 Alejamiento o abandono del proyecto por parte 0.5 MA 5
de la metodóloga en enseñanza y aprendizaje
20 Escaso entendimiento del proceso del software 0.5 M 12
por parte del Cliente
21 Problemas de salud de algún integrante del 0.3 B 13
equipo de trabajo
22 Conflictos al interior del equipo de trabajo 0.2 A 9
23 Alejamiento o abandono por parte del 0.5 MA 5
diseñador de apoyo en el desarrollo del
proyecto
24 Abandono definitivo por parte de algún 0.5 MA 5
integrante del equipo
25 Plan de capacitación insuficiente 0.2 A 9

Tabla Nº32: Riesgos Priorizados

 Gestión

Para disminuir el efecto negativo que pudieran producir estos riesgos durante el desarrollo del
proyecto, las siguientes “Hojas de Control de Riesgos” definen planes de mitigación y de
contingencia para los trece riesgos más prioritarios.

 Riesgos más prioritarios:

ID Riesgo Prioridad
5 La necesidad de cumplir plazos en la planificación podría a llevar a sacrificar la 1
calidad del software
11 Inexperiencia en desarrollo de proyectos de software por parte de los 1
desarrolladores
1 Desconocimiento del software a utilizar en la construcción de la aplicación 2
16 Mala calendarización (estimación de plazos) 2
2 Pérdidas de información por fallas de hardware o software 3
3 Insatisfacción por parte del Cliente de la interfaz usuaria 3
13 Mal dimensionamiento del problema (el problema es más grande de lo pensado) 3
15 Cambio en los requerimientos 4
4 Necesidad de cambiar las herramienta de desarrollo durante el proyecto 5
19 Alejamiento o abandono del proyecto por parte de la asesora en metodología en 5
enseñanza y aprendizaje
23 Alejamiento o abandono por parte del diseñador de apoyo en el desarrollo del 5
proyecto
24 Abandono definitivo por parte de algún integrante del equipo 5
12 Falta de disponibilidad por parte del Cliente para participar en reuniones con los 6
desarrolladores

Tabla Nº33: Riesgos más Prioritarios

 Priorización de los Riesgos:

Según la estimación realizada anteriormente, se seleccionará los 13 riesgos con la mayor

ponderación (o prioridad más alta para controlar), para los cuales se generarán los planes de
mitigación (evitar que ocurra el riesgo) y contingencia (acciones a seguir si el riesgo se materializa)
correspondientes, con el fin de poder controlar la ocurrencia de los riesgos que podrían provocar
un retraso en el tiempo de duración del proyecto, poner en peligro el desarrollo de éste o llevarlo al
fracaso.

4.5.4 Control de riesgos

ID: 4 Hoja de control de riesgo Fecha de identificación:

19/04/2002
Prioridad: 1 Descripción: Necesidad de cambiar la herramienta de desarrollo durante el
proyecto.
Probabilidad: 0.5
Impacto: MA
Período: Ingeniería y Detectado por: Clasificación: Asignado a:
Construcción

Contexto: Cambio de herramientas de desarrollo por no cumplir con la funcionalidad necesaria para la
aplicación, obligaría a realizar el estudio de una herramienta nueva, lo que implica una replanificación.
Plan de Mitigación: Investigar y seleccionar una nueva herramienta de desarrollo, y capacitar en caso de
ser necesario
Plan de Contingencia: Cambiar de herramienta, replanificar el proyecto y asignar nuevas
responsabilidades y tareas.
Gatillador: La herramienta elegida no sirve para desarrollar la solución planificada.
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 34: Control de Riesgo ID 4

 Gestión

ID: 5 Hoja de control de riesgo Fecha de identificación:

15/04/2002
Prioridad: 1 Descripción: La necesidad de cumplir plazos en la planificación podría llevar a
sacrificar la calidad del software
Probabilidad: 0.5
Impacto: MA
Período: Todo el Detectado por: Clasificación: Asignado a:
proyecto
Contexto: El estrés causado por el escaso tiempo disponible para realizar una tarea, produce un descuido
de la calidad, y solo se centran esfuerzos en terminarla. La calidad es primordial en cualquier producto de
software.
Plan de Mitigación: Mantener control constante de la calidad del producto mediante definición de
responsables y actividades de aseguramiento de calidad (SQA)
Plan de Contingencia: Replanificar tareas
Gatillador: Detección de fallas de software en revisiones de calidad.
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 35: Control de Riesgo ID:5

ID: 11 Hoja de control de riesgo Fecha de identificación:

15/04/2002
Prioridad: 1 Descripción: Inexperiencia en desarrollo de proyectos de software por parte de los
desarrolladores.
Probabilidad: 0.5
Impacto: MA
Período: Todo el Detectado por: Clasificación: Asignado a:
proyecto
Contexto: El hecho de tener poca experiencia en el desarrollo de productos de software, afecta en cada
etapa del proceso, ya que las actividades a seguir necesitan de práctica para avanzar con confianza y
obtener un resultado exitoso en los plazos estimados.
Plan de Mitigación: Realizar cursos en áreas en que los desarrolladores necesiten mayor apoyo
Plan de Contingencia: Reformular las tareas y buscar apoyo en proyectos anteriores
Gatillador: Mala realización de una tarea durante el proceso de desarrollo
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 36: Control de Riesgo ID:11

ID: 1 Hoja de control de riesgo Fecha de identificación:

15/04/2002
Prioridad: 2 Descripción: Desconocimiento del software a utilizar en la construcción de la
aplicación
Probabilidad: 0.9
Impacto: MA
Período: Detectado por: Clasificación: Asignado a:
Construcción y
Adaptación
Contexto: La aplicación requiere herramientas de programación que los integrantes del equipo de
desarrollo conocen poco, lo que dificulta y demora el correcto desarrollo del proyecto, además de obligar a
incurrir en costos adicionales para asistir a cursos
Plan de Mitigación: Aprender a utilizar estas herramientas mediante cursos, lecturas e investigación en
general.
Plan de Contingencia: Conseguir asesoramiento en lenguajes de programación y replanificar tareas
Gatillador: no conocer las herramientas de programación al comenzar el desarrollo del proyecto
Estado: Presente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 37: Control de Riesgo ID:1

 Gestión

ID: 16 Hoja de control de riesgo Fecha de identificación:

15/04/2002
Prioridad: 2 Descripción: Mala calendarización (estimación de plazos)
Probabilidad: 0.9
Impacto: MA
Período: Todo el Detectado por: Clasificación: Asignado a:
proyecto
Contexto: El hecho de no cumplir cualquiera de los plazos genera inevitablemente atrasos en la entrega
final y afecta el objetivo del proyecto
Plan de Mitigación: Control y vigilancia al equipo de trabajo para el cumplimiento de los plazos estimados,
mediante reuniones de coordinación y una buena planificación y evaluación de funciones y tareas.
Plan de Contingencia: Replanificación de tareas
Gatillador: Incumplimiento de un hito en lo estipulado en la carta Gantt
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 38: Control de Riesgo ID: 16

ID: 2 Hoja de control de riesgo Fecha de identificación:

16/04/2002
Prioridad: 3 Descripción: Pérdidas de información por fallas de hardware o por software
Probabilidad: 0.7
Impacto: MA
Período: Todo el Detectado por: Clasificación: Asignado a:
proyecto
Contexto: La experiencia dice que siempre y en el momento menos esperado, algo falla (disquetes,
computador, entre otros.) lo que podría atentar contra el normal desarrollo del proyecto, e incluso obligar a
una replanificación.
Plan de Mitigación: Hacer respaldos de información en forma periódica
Plan de Contingencia: Asesoramiento de personal experto en recuperación de archivos. Replanificación
de tareas en caso de pérdidas importantes.
Gatillador: Cualquier dificultad técnica, como por ejemplo, que falle el equipo, que un disquete se dañe,
que se corte la luz sin haber grabado la información
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 39: Control de Riesgo ID:2

ID: 3 Hoja de control de riesgo Fecha de identificación:

17/04/2002
Prioridad: 3 Descripción: Insatisfacción por parte del Cliente de la interfaz usuaria
Probabilidad: 0.7
Impacto: MA
Período: Etapa evaluación Detectado por: Clasificación: Asignado a:
del Cliente
Contexto: El Cliente tiene una alto nivel de exigencia con respecto al diseño de la interfaz de usuario, lo
que hace probable que ésta no sea de su agrado.
Plan de Mitigación: Construcción de prototipo inicial y planificación de reuniones periódicas para
mantener comunicación constante con el Cliente. Además de conseguir asesorías de un diseñador
gráfico.
Plan de Contingencia: Se realizan los cambios correspondientes.
Gatillador: El Cliente manifiesta descontento con respecto a la interfaz usuaria.
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 40: Control de Riesgo ID:3

 Gestión

ID: 13 Hoja de control de riesgo Fecha de identificación:

15/04/2002
Prioridad: 3 Descripción: Mal dimensionamiento del problema (el problemas es más grande de
lo pensado)
Probabilidad: 0.7
Impacto: MA
Período: Todo el Detectado por: Clasificación: Asignado a:
proyecto
Contexto: Este problema puede ser causa de un mala comunicación con el Cliente y de la escasa
experiencia en el uso de herramientas de dimensionamiento de problemas, lo que provoca que los
desarrolladores asignen recursos que posteriormente no sean suficientes para cubrir las tareas requeridas
al abordar el problema real.
Plan de Mitigación: Planificar reuniones para lograr una buena comunicación con el Cliente (entrevistas),
construyendo minutas con los acuerdos y compromisos logrados, y dando buen uso a las herramientas de
dimensionamiento (Puntos de función, COCOMO).
Plan de Contingencia: Establecer nuevos acuerdos con el Cliente y acotar el campo de acción.
Gatillador: Incumplimiento de hitos o plazos establecidos en la Carta Gantt
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 41: Control de Riesgo ID:13

ID: 15 Hoja de control de riesgo Fecha de identificación:

17/04/2002
Prioridad: 4 Descripción: Cambio en los requerimientos
Probabilidad: 0.6
Impacto: MA
Período: Todo el Detectado por: Clasificación: Asignado a:
proyecto
Contexto: Para un proceso de desarrollo de software lo más importante es la especificación de
requerimientos, ya que si esta se modifica, cambia la solución del problema, y si en el proyecto el Cliente
manifestará cambios en sus necesidades, obligaría a cambiar toda la planificación del proyecto.
Plan de Mitigación: Llegar a acuerdos firmados mediante entregas formales en los cuales queden
estipulados los requerimientos y los objetivos a cumplir. Todo esto debe quedar planificado desde un
comienzo.
Plan de Contingencia: Se muestran los documentos firmados al Cliente y se llega a un acuerdo en el cual
ambas partes (desarrollador y Cliente) queden conformes.
Gatillador: Cambio inesperado de las necesidades e ideas del Cliente con respecto a la solución del
problema.
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla N°44: Control de Riesgo ID:15

ID: 19 Hoja de control de riesgo Fecha de identificación:

19/04/2002
Prioridad: 5 Descripción: Alejamiento o abandono del proyecto por parte de la metodóloga en
enseñanza y aprendizaje.
Probabilidad: 0.5
Impacto: MA
Período: Todo el Detectado por: Clasificación: Asignado a:
proyecto
Contexto: El alejamiento o abandono de la metodóloga afecta el desarrollo del proyecto, por que cuando
se le necesite para hacer consultas, no estará para responderlas.
Plan de Mitigación: Hacer una buena planificación de las reuniones, con el objetivo de conseguir la
información necesaria, para el normal desarrollo del proyecto.
Plan de Contingencia: Establecer medios de comunicación en caso de ausencia física de la metodóloga
(teléfono y e-mail).
Gatillador: Viaje o cualquier cualquier causa de ausencia (enfermedad, reunión de trabajo).
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 42: Control de Riesgo ID:19

 Anexos

ID: 23 Hoja de control de riesgo Fecha de identificación:

17/04/2002
Prioridad: 5 Descripción: Alejamiento o abandono por parte del diseñador de apoyo en el
desarrollo del proyecto
Probabilidad: 0.5
Impacto: MA
Período: Todo el Detectado por: Clasificación: Asignado a:
proyecto
Contexto: El alejamiento o abandono del diseñador, influye negativamente en el desarrollo del proyecto,
debido a que no e encontrará para responder las dudas que se susciten.
Plan de Mitigación: Hacer una buena planificación de las reuniones para obtener la información necesaria
y relevante para el normal desarrollo del proyecto.
Plan de Contingencia: Establecer medios de comunicación en caso de ausencia física del diseñador
(teléfono y e-mail).
Gatillador: Viaje o cualquier causa de ausencia (enfermedad, reunión de trabajo)
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 43: Control de Riesgo ID:23

ID: 24 Hoja de control de riesgo Fecha de identificación:

22/04/2002
Prioridad: 5 Descripción: Abandono definitivo por parte de algún integrante del equipo
Probabilidad: 0.5
Impacto: MA
Período: Todo el Detectado por: Clasificación: Asignado a:
proyecto
Contexto: El abandono de algún integrante del equipo, afecta enormemente el desarrollo del proyecto,
debido a que alteraría en forma abrupta la planificación de tareas.
Plan de Mitigación: Desarrollar una fuerte motivación y compromiso por parte de todos los integrantes del
equipo, para así cumplir con el objetivo de terminar el proyecto.
Plan de Contingencia: Hacer una replanificación de asignación de tareas.
Gatillador: Cualquier causa de ausencia (enfermedad, abandono)
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 44: Control de Riesgo ID:24

ID: 12 Hoja de control de riesgo Fecha de identificación:

19/04/2002
Prioridad: 6 Descripción: Falta de disponibilidad por parte del Cliente para participaren
reuniones con los desarrolladores
Probabilidad: 0.8
Impacto: A
Período: Todo el Detectado por: Clasificación: Asignado a:
proyecto
Contexto: La falta de disponibilidad del Cliente afecta el desarrollo normal del proyecto, ya que es una
persona fundamental para llevar a cabo la comprobación de los requerimientos del producto de software.
Plan de Mitigación: Hacer una buena planificación de las reuniones para obtener en poco tiempo, la
información necesaria y relevante para el normal desarrollo del proyecto.
Plan de Contingencia: Establecer medios de comunicación en caso de ausencia física del Cliente
(teléfono y e-mail)
Gatillador: Viaje del Cliente o cualquier causa de ausencia (enfermedad, reunión de trabajo)
Estado: Latente

Aprobado por: Fecha de cierre: Información de cierre:

Tabla 45: Control de Riesgo ID:12