Gestin

PLAN DE CALIDAD PARA PRODUCTO DE SOFTWARE X-PRO-L

GONZALO TOMS PREZ LARA

MEMORIA PARA OPTAR AL TITULO DE INGENIERO DE EJECUCION EN INFORMATICA

Profesor Gua: MARCELLO VISCONTI Profesor Correferente: LUIS HEVIA

VALPARAISO, CHILE OCTUBRE, 2005

4. GESTION 4.1 Organizacin

Jefe de SQA Jefe de SQA

Unidad de SQA Unidad de SQA

Jefe de Jefe de Proyecto Proyecto

Unidad de SCM Unidad de SCM

Jefe de Jefe de Proyecto Proyecto

Ingeniero de Ingeniero de SQA SQA Encargado de Encargado de Diseo Diseo Encargado de Encargado de Seguridad Seguridad

Jefe de Jefe de Proyecto Proyecto

Encargado de Encargado de Documentacin Documentacin

Jefe de Jefe de Proyecto Proyecto

Jefe Jefe Proyecto Proyecto

de de

Jefe Jefe Proyecto Proyecto

de de

Jefe Jefe Proyecto Proyecto

de de

Figura 2: Organizacin del Equipo de Trabajo

La unidad de SQA debe estar organizada para desempear sus labores y otorgar un soporte al desarrollo de software. Para ello, cuenta con tres posibilidades bsicas [MUN-00]: Cada miembro de la unidad de SQA se especializa en todas sus prcticas y se hace responsable de las actividades por realizar en el proyecto. Cada miembro de la unidad se especializa en un subconjunto de prcticas y provee el soporte sobre ellas. La unidad acta como un equipo en el cual sus miembros cooperan para llevar a cabo sus tareas de SQA. La organizacin 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 prcticas de SQA. La objetividad y el criterio suficientes para evaluar correctamente los problemas detectados. Los conocimientos tcnicos para desempear las actividades del proyecto. La capacidad de comunicacin para desempear 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 desempearn 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 organizacin. Se debe dejar en claro que el grupo de SQA no tiene la total responsabilidad de lograr una alta calidad de la aplicacin multimedia, sino que depende total y absolutamente de todo el equipo u organizacin. 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 distribucin de puestos dentro de ella, es tener un Jefe de SQA quien tendr la capacidad de liderazgo y experiencia en

Gestin

otros proyectos, estar a cargo de un grupo de ingenieros de calidad y desarrolladores (encargados del diseo, documentacin, seguridad, programacin), por lo que se adoptar la siguiente distribucin de cargos:
Cargo Jefe de SQA Descripcin Es el encargado de velar por las siguientes responsabilidades: Establecer el programa de calidad para el proyecto de acuerdo a las polticas organizacionales. Gestionar el desarrollo de herramientas para facilitar el proceso de SQA. Identificar las actividades de SQA requeridas para el proyecto. Identificar los participantes de las actividades de SQA. Revisar y aprobar el plan de SQA de acuerdo al plan. Implementar las actividades de SQA de acuerdo al plan. Monitorear las actividades de SQA planificadas en el plan. Resolver cualquier conflicto relacionado con las actividades de SQA. Informar a los niveles superiores sobre el estado del proceso y las actividades de SQA en el proyecto. Identificar un grupo independiente para la revisin de las actividades de SQA. Debe asegurar el cumplimiento del plan de prueba y gestionar su implementacin. Es el responsable de monitorear el cumplimiento de las actividades planificadas en el plan de SQA con el fin de asegurar su ejecucin en forma correcta, completa y adecuada. Adems de garantizar la calidad de los entregables, la documentacin y de los procesos utilizados para la produccin del software. Es el encargado de concretar el plan de SQA y coordinar con el grupo de desarrollo la correcta aplicacin de las tareas que conforman el SQA. Para esto debe velar por un buen cumplimiento de los siguientes puntos: Revisar y entregar sus observaciones sobre el Plan de SQA para el proyecto. Implementar las actividades de SQA de acuerdo al plan. Participar de la solucin de los problemas detectados por las actividades de SQA que sean de su competencia. Implementar las prcticas, procesos y procedimientos definidos en el plan. Responsable ante el Jefe de Proyectos por la planificacin, especificacin, ejecucin y evaluacin de las pruebas y revisiones. Interactuar con los desarrolladores y la unidad de SCM. Auditar, monitorear, evaluar e informar sobre las actividades de desarrollo.

Unidad de SQA

Ingeniero de SQA

Gestin

Encargado de Diseo

Es el encargado de velar por las siguientes responsabilidades:

Encargado de Seguridad

Revisar y comentar el diseo de las interfaces. Revisar y validar el formato de las imgenes, resolucin y tamao, botones. Identificar el contenido de las ayudas, su forma de presentacin. Completar los informes de SQA. Interactuar con las diferentes herramientas utilizadas para SQA durante el Proyecto. Asistir al Ingeniero en las pruebas, revisiones y diseo.

Es el encargado de velar por las siguientes responsabilidades:

Encargado de Documentacin

Realizar las pruebas de seguridad del sistema, errores de programacin y cadas 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.

Es el encargado de velar por la identificacin, desarrollo y manutencin de la documentacin del proyecto.

Tabla 23: Descripcin de Cargos

4.2.2 Infraestructura El grupo de SQA necesita tener acceso a computadoras que permitan realizar labores de evaluacin y auditora 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

Gestin

4.3 Actividades de SQA

Las actividades contempladas que debe llevar a cabo SQA, son las siguientes [MUN-00]: Evaluacin de la seleccin los productos de trabajo El plan de proyecto identifica los productos de trabajo que deben ser desarrollados y evaluados, incluyendo los estndares y guas aplicables a su desarrollo. SQA debe asistir el Jefe de Proyectos en la seleccin de los estndares y guas aplicables a cada entregable. Evaluacin de las herramientas SQA debe evaluar la seleccin de las herramientas existentes y adquiridas para el desarrollo. stas deben ser evaluadas segn su funcionalidad, disponibilidad y facilidad de operacin. Evaluacin de la planificacin y el monitoreo del proyecto Durante la planificacin, SQA debe apoyar la identificacin apropiada de guas y estndares aplicables a los entregables del proyecto (se incluye Plan de Riesgos) y responsabilizarse de la elaboracin del plan de SQA. Posteriormente, debe supervisar el cumplimiento del plan de proyecto. Evaluacin de la especificacin de requerimientos SQA debe: Comprobar la adherencia de los entregables a los estndares definidos en el plan de proyecto. Verificar la adherencia del proceso de especificacin de requerimientos a los procedimientos definidos en el plan de proyecto. Garantizar que se revisaron adecuadamente los entregables (especificacin de requerimientos) de la fase de especificacin de requerimientos. Asegurar la incorporacin de los resultados de las revisiones en los entregables de esta fase. Corroborar que estn expresados y documentados los requerimientos funcionales, tcnicos, operacionales y de interfaz, de manera tal que puedan ser verificados en el producto final. Evaluacin del Anlisis SQA debe: Comprobar la adherencia de los entregables a los estndares definidos en el Plan de Proyecto. Verificar la adherencia del proceso de especificacin de Sistema (Solucin Propuesta) a los procedimientos definidos en el plan de proyecto. Garantizar que se revisaron adecuadamente los entregables (Especificacin de Sistema, es decir, Solucin Propuesta) de la fase de Anlisis. Evaluacin del diseo SQA es responsable de: Comprobar la adherencia de los entregables a los estndares definidos en el plan de proyecto.

Gestin

Verificar la adherencia del proceso de diseo a los procedimientos definidos en le plan de proyecto. Garantizar que se revisaron adecuadamente los entregables (Especificacin de Diseo de Sistema, Especificacin Funcional, Especificacin de Diseo de Soporte, Plan de Pruebas (Funcional), especificacin de casos y procedimientos de prueba, y Especificacin de Test de componentes e integracin del sistema de la fase de diseo. Asegurar la incorporacin de los resultados de las revisiones en los entregables de esta fase. Evaluacin de la implementacin y de la prueba de unidad SQA debe: Garantizar que el proceso de codificacin, las revisiones asociadas y la pruebas de unidad sean conducidos de acuerdo a los estndares y procedimientos establecidos en el plan de proyecto. Asegurar la incorporacin de los resultados de las revisiones en los entregables ( de esta fase. Verificar la implementacin de las acciones correctivas derivadas de la prueba de unidad. Comprobar la utilizacin de la especificacin de procedimientos y casos de prueba durante la prueba de unidad. Corroborar la documentacin del cdigo y de los resultados de la prueba de unidad. Verificar que el proceso de integracin y las actividades de prueba sean realizadas conforme al plan de proyecto, el diseo, el plan de prueba y los estndares y procedimientos establecidos. Asegurar que la prueba de integracin fue completada satisfactoriamente, que sus resultados fueron registrados y divulgados y que las acciones correctivas derivadas de ella fueron implementadas. Corroborar el desarrollo adecuado de las pruebas de aceptacin y del sistema. Monitorear las actividades de prueba y certificar sus resultados. Revisar las pruebas. Evaluacin del producto antes de su liberacin SQA debe evaluar las actividades de preparacin del producto final y su documentacin para la entrega al cliente, para lo cual debe participar de la auditora funcional y fsica. Evaluacin del proceso de revisin SQA debe verificar que todo producto que se encuentre listo para revisin sea revisado y que las acciones correctivas identificadas durante la revisin sean implementadas. Evaluacin de las acciones correctivas SQA debe analizar los problemas detectados para determinar sus causas, impactos y frecuencia de ocurrencia, y para establecer acciones preventivas. Adems, SQA es responsable de monitorear la adecuada implementacin de las acciones correctivas derivadas de estos problemas.

Gestin

Verificar la implementacin de los procesos SQA debe corroborara la adherencia de todos los procesos a los estndares y procedimientos definidos en el plan de proyecto. Establecer las auditoras SQA es responsable en la institucin por el desarrollo de las auditoras internas. Por lo tanto debe gestionarlas de ser preciso. Adems, es su responsabilidad participar en la auditora fsica y funcional.

Gestin

4.4 Responsabilidades
La autoridad de SQA deriva del gerente tcnico de la organizacin y su principal obligacin es monitorear las actividades del proceso de desarrollo y revisar la adherencia de los productos de trabajo a los estndares, procedimientos y al plan del proyecto. Los resultados de este seguimiento deben ser informados al jefe de proyectos y, segn sea aplicable, al Gerente Tcnico. En la siguiente tabla se adjunta una matriz de responsabilidades sobre las actividades de SQA [WEB-01].
Actividad Evaluacin de la seleccin de los productos de trabajo Evaluacin de las herramientas Evaluacin de la planificacin y el monitoreo del proyecto Evaluacin de la especificacin de requerimientos Evaluacin del Anlisis Jefe Jefe proyecto SQA X X Jefe SCM Jefe Anlisis Jefe Diseo Programador Documentador

Evaluacin del diseo Evaluacin de la implementacin y de la prueba de unidad Evaluacin del producto antes de su liberacin Evaluacin del proceso de revisin Evaluacin de las acciones correctivas Evaluacin del proceso de SCM Verificar la implementacin de los procesos Establecer las auditoras

Tabla 25: Matriz de Responsabilidades

Gestin

4.5 Riesgos
4.5.1 Identificacin de riesgos Lista de tems de riesgos que pueden comprometer el xito del proyecto. A continuacin, se presentan 25 potenciales riesgos identificados en esta etapa del proyecto X-PRO-L:
ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Riesgo Desconocimiento del software a utilizar en la construccin de la aplicacin. Prdidas de informacin por fallas de Hardware o Software. Insatisfaccin por parte del Cliente de la interfaz usuaria. Necesidad de cambiar la herramienta de desarrollo durante el proyecto. La necesidad de cumplir plazos en la planificacin podra llevar a sacrificar la calidad del software. Mala estimacin de costos de desarrollo de la aplicacin. Falta de recursos de hardware especficos (impresora, entre otros). Un producto similar sale al mercado. Problemas de comunicacin entre los integrantes del equipo. Falta de disponibilidad de un integrante del equipo de trabajo. Inexperiencia en desarrollo de proyectos de software por parte de los desarrolladores. Falta de disponibilidad por parte del Cliente para participar en reuniones con los desarrolladores. Mal dimensionamiento del problema (el problema es ms grande de lo pensado). Sobredimensionamiento de las capacidades de las herramientas a utilizar. Cambio en los requerimientos. Mala calendarizacin (estimacin de plazos). Mala eleccin del paradigma de desarrollo. Falta de disponibilidad de la metodloga en enseanza y aprendizaje. Alejamiento o abandono del proyecto por parte de la metodloga en enseanza y aprendizaje. Escaso entendimiento del proceso del software por parte del Cliente. Problemas de salud de algn integrante del equipo de trabajo. Conflictos al interior del equipo de trabajo. Alejamiento o abandono por parte del diseador de apoyo en el desarrollo del proyecto. Abandono definitivo por parte de algn integrante del equipo. Plan de capacitacin insuficiente
Tabla N26: Potenciales Riesgos

4.5.2 Clasificacin En esta etapa se clasifican los riesgos en una de las siguientes categoras: Riesgo Tcnico: Potenciales problemas de diseo, implantacin del sistema, interfaz, verificacin y mantencin. Riesgo de Negocio: Posibles situaciones o hechos que pueden hacer fracasar la aplicacin una vez terminada. Riesgo de Proyecto: Dificultad durante el desarrollo relacionado con los recursos humanos, la calendarizacin o la interaccin cliente-servidor.

Gestin

Riesgos Tcnicos:
ID 2 7 14 25 Riesgo Prdidas de informacin por fallas de hardware o software Falta de recursos de Hardware especficos (impresora, entre otros). Sobredimensionamiento de las capacidades de las herramientas a utilizar. Plan de capacitacin insuficiente
Tabla N27: Riesgos Tcnicos

Riesgos de Negocio:
ID 8 Riesgo Un producto similar sale al mercado
Tabla N28: Riesgos de Negocio

Riesgos de Proyecto:
ID 1 3 4 5 6 9 10 11 12 13 15 16 17 18 19 20 21 22 23 24 Riesgo Desconocimiento del software a utilizar en la construccin de la aplicacin Insatisfaccin por parte del Cliente de la interfaz usuaria Necesidad de cambiar la herramienta de desarrollo durante el proyecto La necesidad de cumplir plazos en la planificacin podra llevar a sacrificar la calidad del software Mala estimacin de costos de desarrollo de la aplicacin Problemas de comunicacin entre los integrantes del Equipo Falta de disponibilidad de un integrante del equipo de trabajo Inexperiencia en desarrollo de proyectos de software por parte de los desarrolladores Falta de disponibilidad por parte del Cliente para participar en reuniones con los desarrolladores Mal dimensionamiento del problema (el problema es ms grande de lo pensado) Cambio en los requerimientos Mala calendarizacin (estimacin de plazos) Mala eleccin del paradigma de desarrollo Falta de disponibilidad de la metodloga en enseanza y aprendizaje Alejamiento o abandono del proyecto por parte de la metodloga en enseanza y aprendizaje Escaso entendimiento del proceso de software por parte del Cliente Problemas de salud de algn integrante del equipo de trabajo Conflictos al interior del equipo de trabajo Alejamiento o abandono por parte del diseador de apoyo en el desarrollo del proyecto Abandono definitivo por parte de algn integrante
Tabla 29: Riesgos de Proyecto

4.5.3 Estimacin de los riesgos Para evaluar cada riesgo, se utiliz una descripcin definida de la siguiente manera: Descripcin de los rangos
Muy Alto Alto Medio Bajo Significa que la ocurrencia del riesgo es muy probable, o que el impacto en el proyecto es determinante para el desarrollo de ste. La ocurrencia del riesgo es probable, o el impacto en el proyecto es considerable, pero no determinante. Significa que la probabilidad de que el riesgo se materialice es de un nivel medio, o que el efecto en el proyecto es moderado La ocurrencia del riesgo es casi improbable, o que el impacto en el proyecto tiene un efecto bajo o casi nulo.
Tabla 30: Descripcin de los rangos

Gestin

Ponderacin de los rangos Escala de Priorizacin:

Impacto MA MA MA MA MA A A A A A M M B B Probabilidad 1 0.9 0.7 0.6 0.5 0.8 0.7 0.5 0.2 0.1 0.8 0.5 0.3 0.2
Tabla 31: Escala de Priorizacin

Prioridad 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Riesgos Priorizados:
ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Riesgo Probabilidad Desconocimiento del software a utilizar en la 0.9 construccin de la aplicacin Prdidas de informacin por fallas de hardware 0.7 o software Insatisfaccin por parte del Cliente de la 0.7 interfaz usuaria Necesidad de cambiar la herramienta de 0.5 desarrollo durante el proyecto La necesidad de cumplir plazos en la 1 planificacin podra llevar a sacrificar la calidad del software Mala estimacin de costos de desarrollo de la 0.8 aplicacin Falta de recursos de hardware especficos 0.5 (impresora entre otros) Un producto similar sale al mercado 0.5 Problemas de comunicacin entre los 0.1 integrantes del equipo Falta de disponibilidad de un integrante del 0.2 equipo de trabajo Inexperiencia en desarrollo de proyectos de 1 software por parte de los desarrolladores Falta de disponibilidad por parte del Cliente 0.8 para participar en reuniones con los desarrolladores Mal dimensionamiento del problema (el 0.7 problema es ms grande de lo pensado) Sobredimensionamiento de las capacidades de 0.7 las herramientas a utilizar Cambios en los requerimientos 0.6 Mala calendarizacin (estimacin de plazos) 0.9 Mala eleccin del paradigma de desarrollo 0.2 Falta de disponibilidad de la metodloga en 0.2 enseanza y aprendizaje Alejamiento o abandono del proyecto por parte 0.5 de la metodloga en enseanza y aprendizaje Escaso entendimiento del proceso del software 0.5 por parte del Cliente Problemas de salud de algn integrante del 0.3 equipo de trabajo Conflictos al interior del equipo de trabajo 0.2 Alejamiento o abandono por parte del 0.5 diseador de apoyo en el desarrollo del proyecto Abandono definitivo por parte de algn 0.5 integrante del equipo Plan de capacitacin insuficiente 0.2
Tabla N32: Riesgos Priorizados

Impacto MA MA MA MA MA M A M A B MA A MA A MA MA A A MA M B A MA MA A

Prioridad 2 3 3 5 1 11 8 12 10 14 1 6 3 7 4 2 9 9 5 12 13 9 5 5 9

Gestin

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 mitigacin y de contingencia para los trece riesgos ms prioritarios. Riesgos ms prioritarios:
ID 5 11 1 16 2 3 13 15 4 19 23 24 12 Riesgo La necesidad de cumplir plazos en la planificacin podra a llevar a sacrificar la calidad del software Inexperiencia en desarrollo de proyectos de software por parte de los desarrolladores Desconocimiento del software a utilizar en la construccin de la aplicacin Mala calendarizacin (estimacin de plazos) Prdidas de informacin por fallas de hardware o software Insatisfaccin por parte del Cliente de la interfaz usuaria Mal dimensionamiento del problema (el problema es ms grande de lo pensado) Cambio en los requerimientos Necesidad de cambiar las herramienta de desarrollo durante el proyecto Alejamiento o abandono del proyecto por parte de la asesora en metodologa en enseanza y aprendizaje Alejamiento o abandono por parte del diseador de apoyo en el desarrollo del proyecto Abandono definitivo por parte de algn integrante del equipo Falta de disponibilidad por parte del Cliente para participar en reuniones con los desarrolladores
Tabla N33: Riesgos ms Prioritarios

Prioridad 1 1 2 2 3 3 3 4 5 5 5 5 6

Priorizacin de los Riesgos: Segn la estimacin realizada anteriormente, se seleccionar los 13 riesgos con la mayor ponderacin (o prioridad ms alta para controlar), para los cuales se generarn los planes de mitigacin (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 podran provocar un retraso en el tiempo de duracin del proyecto, poner en peligro el desarrollo de ste o llevarlo al fracaso. 4.5.4 Control de riesgos
ID: 4 Prioridad: 1 Probabilidad: 0.5 Impacto: MA Perodo: Ingeniera y Construccin Hoja de control de riesgo Fecha de identificacin: 19/04/2002 Descripcin: Necesidad de cambiar la herramienta de desarrollo durante el proyecto.

Detectado por:

Clasificacin:

Asignado a:

Contexto: Cambio de herramientas de desarrollo por no cumplir con la funcionalidad necesaria para la aplicacin, obligara a realizar el estudio de una herramienta nueva, lo que implica una replanificacin. Plan de Mitigacin: 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 solucin planificada. Estado: Latente Aprobado por: Fecha de cierre:
Tabla 34: Control de Riesgo ID 4

Informacin de cierre:

Gestin

ID: 5 Prioridad: 1

Hoja de control de riesgo

Fecha de identificacin: 15/04/2002 Descripcin: La necesidad de cumplir plazos en la planificacin podra llevar a sacrificar la calidad del software

Probabilidad: 0.5 Impacto: MA Perodo: Todo el Detectado por: Clasificacin: Asignado a: proyecto Contexto: El estrs 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 Mitigacin: Mantener control constante de la calidad del producto mediante definicin de responsables y actividades de aseguramiento de calidad (SQA) Plan de Contingencia: Replanificar tareas Gatillador: Deteccin de fallas de software en revisiones de calidad. Estado: Latente Aprobado por: Fecha de cierre:
Tabla 35: Control de Riesgo ID:5

Informacin de cierre:

ID: 11 Prioridad: 1

Hoja de control de riesgo

Fecha de identificacin: 15/04/2002 Descripcin: Inexperiencia en desarrollo de proyectos de software por parte de los desarrolladores.

Probabilidad: 0.5 Impacto: MA Perodo: Todo el Detectado por: Clasificacin: 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 prctica para avanzar con confianza y obtener un resultado exitoso en los plazos estimados. Plan de Mitigacin: 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 realizacin de una tarea durante el proceso de desarrollo Estado: Latente Aprobado por: Fecha de cierre:
Tabla 36: Control de Riesgo ID:11

Informacin de cierre:

ID: 1 Prioridad: 2

Hoja de control de riesgo

Fecha de identificacin: 15/04/2002 Descripcin: Desconocimiento del software a utilizar en la construccin de la aplicacin

Probabilidad: 0.9 Impacto: MA Perodo: Detectado por: Clasificacin: Asignado a: Construccin y Adaptacin Contexto: La aplicacin requiere herramientas de programacin que los integrantes del equipo de desarrollo conocen poco, lo que dificulta y demora el correcto desarrollo del proyecto, adems de obligar a incurrir en costos adicionales para asistir a cursos Plan de Mitigacin: Aprender a utilizar estas herramientas mediante cursos, lecturas e investigacin en general. Plan de Contingencia: Conseguir asesoramiento en lenguajes de programacin y replanificar tareas Gatillador: no conocer las herramientas de programacin al comenzar el desarrollo del proyecto Estado: Presente Aprobado por: Fecha de cierre:
Tabla 37: Control de Riesgo ID:1

Informacin de cierre:

Gestin

ID: 16

Hoja de control de riesgo

Prioridad: 2 Probabilidad: 0.9 Impacto: MA Perodo: Todo el Detectado por: Clasificacin: 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 Mitigacin: Control y vigilancia al equipo de trabajo para el cumplimiento de los plazos estimados, mediante reuniones de coordinacin y una buena planificacin y evaluacin de funciones y tareas. Plan de Contingencia: Replanificacin de tareas Gatillador: Incumplimiento de un hito en lo estipulado en la carta Gantt Estado: Latente Aprobado por: Fecha de cierre:
Tabla 38: Control de Riesgo ID: 16

Fecha de identificacin: 15/04/2002 Descripcin: Mala calendarizacin (estimacin de plazos)

Informacin de cierre:

ID: 2

Hoja de control de riesgo

Prioridad: 3 Probabilidad: 0.7 Impacto: MA Perodo: Todo el Detectado por: Clasificacin: Asignado a: proyecto Contexto: La experiencia dice que siempre y en el momento menos esperado, algo falla (disquetes, computador, entre otros.) lo que podra atentar contra el normal desarrollo del proyecto, e incluso obligar a una replanificacin. Plan de Mitigacin: Hacer respaldos de informacin en forma peridica Plan de Contingencia: Asesoramiento de personal experto en recuperacin de archivos. Replanificacin de tareas en caso de prdidas importantes. Gatillador: Cualquier dificultad tcnica, como por ejemplo, que falle el equipo, que un disquete se dae, que se corte la luz sin haber grabado la informacin Estado: Latente Aprobado por: Fecha de cierre:
Tabla 39: Control de Riesgo ID:2

Fecha de identificacin: 16/04/2002 Descripcin: Prdidas de informacin por fallas de hardware o por software

Informacin de cierre:

ID: 3

Hoja de control de riesgo

Prioridad: 3 Probabilidad: 0.7 Impacto: MA Perodo: Etapa evaluacin Detectado por: Clasificacin: Asignado a: del Cliente Contexto: El Cliente tiene una alto nivel de exigencia con respecto al diseo de la interfaz de usuario, lo que hace probable que sta no sea de su agrado. Plan de Mitigacin: Construccin de prototipo inicial y planificacin de reuniones peridicas para mantener comunicacin constante con el Cliente. Adems de conseguir asesoras de un diseador grfico. 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:
Tabla 40: Control de Riesgo ID:3

Fecha de identificacin: 17/04/2002 Descripcin: Insatisfaccin por parte del Cliente de la interfaz usuaria

Informacin de cierre:

Gestin

ID: 13 Prioridad: 3

Hoja de control de riesgo

Fecha de identificacin: 15/04/2002 Descripcin: Mal dimensionamiento del problema (el problemas es ms grande de lo pensado)

Probabilidad: 0.7 Impacto: MA Perodo: Todo el Detectado por: Clasificacin: Asignado a: proyecto Contexto: Este problema puede ser causa de un mala comunicacin 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 Mitigacin: Planificar reuniones para lograr una buena comunicacin con el Cliente (entrevistas), construyendo minutas con los acuerdos y compromisos logrados, y dando buen uso a las herramientas de dimensionamiento (Puntos de funcin, COCOMO). Plan de Contingencia: Establecer nuevos acuerdos con el Cliente y acotar el campo de accin. Gatillador: Incumplimiento de hitos o plazos establecidos en la Carta Gantt Estado: Latente Aprobado por: Fecha de cierre:
Tabla 41: Control de Riesgo ID:13

Informacin de cierre:

ID: 15

Hoja de control de riesgo

Fecha de identificacin: 17/04/2002

Prioridad: 4 Descripcin: Cambio en los requerimientos Probabilidad: 0.6 Impacto: MA Perodo: Todo el Detectado por: Clasificacin: Asignado a: proyecto Contexto: Para un proceso de desarrollo de software lo ms importante es la especificacin de requerimientos, ya que si esta se modifica, cambia la solucin del problema, y si en el proyecto el Cliente manifestar cambios en sus necesidades, obligara a cambiar toda la planificacin del proyecto. Plan de Mitigacin: 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 solucin del problema. Estado: Latente Aprobado por: Fecha de cierre:
Tabla N44: Control de Riesgo ID:15

Informacin de cierre:

ID: 19 Prioridad: 5

Hoja de control de riesgo

Fecha de identificacin: 19/04/2002 Descripcin: Alejamiento o abandono del proyecto por parte de la metodloga en enseanza y aprendizaje.

Probabilidad: 0.5 Impacto: MA Perodo: Todo el Detectado por: Clasificacin: Asignado a: proyecto Contexto: El alejamiento o abandono de la metodloga afecta el desarrollo del proyecto, por que cuando se le necesite para hacer consultas, no estar para responderlas. Plan de Mitigacin: Hacer una buena planificacin de las reuniones, con el objetivo de conseguir la informacin necesaria, para el normal desarrollo del proyecto. Plan de Contingencia: Establecer medios de comunicacin en caso de ausencia fsica de la metodloga (telfono y e-mail). Gatillador: Viaje o cualquier cualquier causa de ausencia (enfermedad, reunin de trabajo). Estado: Latente Aprobado por: Fecha de cierre:
Tabla 42: Control de Riesgo ID:19

Informacin de cierre:

Anexos

ID: 23 Prioridad: 5

Hoja de control de riesgo

Fecha de identificacin: 17/04/2002 Descripcin: Alejamiento o abandono por parte del diseador de apoyo en el desarrollo del proyecto

Probabilidad: 0.5 Impacto: MA Perodo: Todo el Detectado por: Clasificacin: Asignado a: proyecto Contexto: El alejamiento o abandono del diseador, influye negativamente en el desarrollo del proyecto, debido a que no e encontrar para responder las dudas que se susciten. Plan de Mitigacin: Hacer una buena planificacin de las reuniones para obtener la informacin necesaria y relevante para el normal desarrollo del proyecto. Plan de Contingencia: Establecer medios de comunicacin en caso de ausencia fsica del diseador (telfono y e-mail). Gatillador: Viaje o cualquier causa de ausencia (enfermedad, reunin de trabajo) Estado: Latente Aprobado por: Fecha de cierre:
Tabla 43: Control de Riesgo ID:23

Informacin de cierre:

ID: 24

Hoja de control de riesgo

Prioridad: 5 Probabilidad: 0.5 Impacto: MA Perodo: Todo el Detectado por: Clasificacin: Asignado a: proyecto Contexto: El abandono de algn integrante del equipo, afecta enormemente el desarrollo del proyecto, debido a que alterara en forma abrupta la planificacin de tareas. Plan de Mitigacin: Desarrollar una fuerte motivacin 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 replanificacin de asignacin de tareas. Gatillador: Cualquier causa de ausencia (enfermedad, abandono) Estado: Latente Aprobado por: Fecha de cierre:
Tabla 44: Control de Riesgo ID:24

Fecha de identificacin: 22/04/2002 Descripcin: Abandono definitivo por parte de algn integrante del equipo

Informacin de cierre:

ID: 12 Prioridad: 6

Hoja de control de riesgo

Fecha de identificacin: 19/04/2002 Descripcin: Falta de disponibilidad por parte del Cliente para participaren reuniones con los desarrolladores

Probabilidad: 0.8 Impacto: A Perodo: Todo el Detectado por: Clasificacin: 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 comprobacin de los requerimientos del producto de software. Plan de Mitigacin: Hacer una buena planificacin de las reuniones para obtener en poco tiempo, la informacin necesaria y relevante para el normal desarrollo del proyecto. Plan de Contingencia: Establecer medios de comunicacin en caso de ausencia fsica del Cliente (telfono y e-mail) Gatillador: Viaje del Cliente o cualquier causa de ausencia (enfermedad, reunin de trabajo) Estado: Latente Aprobado por: Fecha de cierre:
Tabla 45: Control de Riesgo ID:12

Informacin de cierre: