Plan de Calidad Para Producto de Software 2 (Corta)

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 Jefede deSQA SQA

Jefe de Jefe de Proyecto Proyecto

Unidad Unidad de de SQA SQA

Unidad Unidad de de SCM SCM

Jefe de Jefe de Proyecto Proyecto Encargado Encargado de de Diseño Diseño

Ingeniero Ingeniero de de SQA SQA



Jefe Jefe Proyecto Proyecto

Encargado Encargado de de Seguridad Seguridad

de de


de de

Encargado Encargado de de Documentación Documentación


de de

Figura 2: Organización del Equipo de Trabajo

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: Cargo

Jefe de SQA

Descripción

Es el encargado de velar por las siguientes responsabilidades: Establecer el programa de calidad para el proyecto de acuerdo a las políticas 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 revisión de las actividades de SQA. Debe asegurar el cumplimiento del plan de prueba y gestionar su implementación. •

•

•

•

•

•

•

•

•

•

•

Unidad de SQA

Ingeniero de SQA

Es el responsable de monitorear el cumplimiento de las actividades planificadas en el plan de SQA con el fin de asegurar su ejecución en forma correcta, completa y adecuada. Además de garantizar la calidad de los entregables, la documentación y de los procesos utilizados para la producción del software. Es el encargado de concretar el plan de SQA y coordinar con el grupo de desarrollo la correcta aplicación 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 solución de los problemas detectados por las actividades de SQA que sean de su competencia. Implementar las prácticas, procesos y procedimientos definidos en el plan. Responsable ante el Jefe de Proyectos por la planificación, especificación, ejecución y evaluación de las pruebas y revisiones. Interactuar con los desarrolladores y la unidad de SCM. Auditar, monitorear, evaluar e informar sobre las actividades de desarrollo.

Gestión

Encargado de Diseño

Es el encargado de velar por las siguientes responsabilidades: •

Encargado de Seguridad

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.

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

4.3 Actividades de SQA Las actividades contempladas que debe llevar a cabo SQA, son las siguientes [MUN-00]: 

Evaluación de la selección los productos de trabajo

El plan de proyecto identifica los productos de trabajo que deben ser desarrollados y evaluados, incluyendo los estándares y guías aplicables a su desarrollo. SQA debe asistir el Jefe de Proyectos en la selección de los estándares y guías aplicables a cada entregable. 

Evaluación de las herramientas

SQA debe evaluar la selección de las herramientas existentes y adquiridas para el desarrollo. Éstas deben ser evaluadas según su funcionalidad, disponibilidad y facilidad de operación. 

Evaluación de la planificación y el monitoreo del proyecto

Durante la planificación, SQA debe apoyar la identificación apropiada de guías y estándares aplicables a los entregables del proyecto (se incluye Plan de Riesgos) y responsabilizarse de la elaboración del plan de SQA. Posteriormente, debe supervisar el cumplimiento del plan de proyecto. 

Evaluación de la especificación de requerimientos

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 requerimientos a los procedimientos definidos en el plan de proyecto.



Garantizar que se revisaron adecuadamente los entregables (especificación de requerimientos) de la fase de especificación de requerimientos.



Asegurar la incorporación de los resultados de las revisiones en los entregables de esta fase.



Corroborar que estén expresados y documentados los requerimientos funcionales, técnicos, operacionales y de interfaz, de manera tal que puedan ser verificados en el producto final.



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



Verificar la adherencia del proceso de diseño a los procedimientos definidos en le plan de proyecto.



Garantizar que se revisaron adecuadamente los entregables (Especificación de Diseño de Sistema, Especificación Funcional, Especificación de Diseño de Soporte, Plan de Pruebas (Funcional), especificación de casos y procedimientos de prueba, y Especificación de Test de componentes e integración del sistema de la fase de diseño.





Asegurar la incorporación de los resultados de las revisiones en los entregables de esta fase.

Evaluación de la implementación y de la prueba de unidad

SQA debe: 

Garantizar que el proceso de codificación, las revisiones asociadas y la pruebas de unidad sean conducidos de acuerdo a los estándares y procedimientos establecidos en el plan de proyecto.



Asegurar la incorporación de los resultados de las revisiones en los entregables ( de esta fase.



Verificar la implementación de las acciones correctivas derivadas de la prueba de unidad.



Comprobar la utilización de la especificación de procedimientos y casos de prueba durante la prueba de unidad.



Corroborar la documentación del código y de los resultados de la prueba de unidad.



Verificar que el proceso de integración y las actividades de prueba sean realizadas conforme al plan de proyecto, el diseño, el plan de prueba y los estándares y procedimientos establecidos.



Asegurar que la prueba de integración 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 aceptación y del sistema.



Monitorear las actividades de prueba y certificar sus resultados.



Revisar las pruebas.

Evaluación del producto antes de su liberación

SQA debe evaluar las actividades de preparación del producto final y su documentación para la entrega al cliente, para lo cual debe participar de la auditoría funcional y física. 

Evaluación del proceso de revisió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



Verificar la implementación de los procesos

SQA debe corroborara la adherencia de todos los procesos a los estándares y procedimientos definidos en el plan de proyecto. 

Establecer las auditorías

SQA es responsable en la institución por el desarrollo de las auditorías internas. Por lo tanto debe gestionarlas de ser preciso. Además, es su responsabilidad participar en la auditoría física y funcional.

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]. Actividad

Jefe Jefe Jefe Jefe proyecto SQA SCM Análisis

Jefe Diseño

Programador

Documentador

Evaluación de la selección de los productos de trabajo

X

X

Evaluación de las herramientas

X

X

Evaluación de la planificación y el monitoreo del proyecto

X

X

Evaluación de la especificación de requerimientos

X

X

X

X

Evaluación del Anàlisis

x

x

x

x

Evaluación del diseño

X

X

X

X

Evaluación de la implementación y de la prueba de unidad

x

X

X

X

X

X

Evaluación del producto antes de su liberación

X

X

X

X

X

X

Evaluación del proceso de revisión

X

X

Evaluación de las acciones correctivas

X

X

Evaluación del proceso de SCM

X X

Verificar la implementación de los procesos

X

X

Establecer las auditorías

X

X

X

Tabla 25: Matriz de Responsabilidades

X

Gestión

4.5 Riesgos 4.5.1 Identificación de riesgos

Lista de ítems de riesgos que pueden comprometer el éxito del proyecto. A continuación, 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 construcción de la aplicación. Pérdidas de información por fallas de Hardware o Software. Insatisfacción 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 planificación podría llevar a sacrificar la calidad del software. Mala estimación de costos de desarrollo de la aplicación. Falta de recursos de hardware específicos (impresora, entre otros). Un producto similar sale al mercado. Problemas de comunicación 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 más grande de lo pensado). Sobredimensionamiento de las capacidades de las herramientas a utilizar. Cambio en los requerimientos. Mala calendarización (estimación de plazos). Mala elección del paradigma de desarrollo. Falta de disponibilidad de la metodóloga en enseñanza y aprendizaje. Alejamiento o abandono del proyecto por parte de la metodóloga en enseñanza y aprendizaje. Escaso entendimiento del proceso del software por parte del Cliente. Problemas de salud de algún integrante del equipo de trabajo. Conflictos al interior del equipo de trabajo. Alejamiento o abandono por parte del diseñador de apoyo en el desarrollo del proyecto. Abandono definitivo por parte de algún integrante del equipo. 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:

ID 2 7 14 25

Riesgo Pérdidas de información por fallas de hardware o software Falta de recursos de Hardware específicos (impresora, entre otros). Sobredimensionamiento de las capacidades de las herramientas a utilizar. Plan de capacitación insuficiente Tabla Nº27: Riesgos Técnicos



Riesgos de Negocio:

ID 8

Riesgo Un producto similar sale al mercado Tabla Nº28: 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 construcción de la aplicación Insatisfacción 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 planificación podría llevar a sacrificar la calidad del software Mala estimación de costos de desarrollo de la aplicación Problemas de comunicación 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 más grande de lo pensado) Cambio en los requerimientos Mala calendarización (estimación de plazos) Mala elección del paradigma de desarrollo Falta de disponibilidad de la metodóloga en enseñanza y aprendizaje Alejamiento o abandono del proyecto por parte de la metodóloga en enseñanza y aprendizaje Escaso entendimiento del proceso de software por parte del Cliente Problemas de salud de algún integrante del equipo de trabajo Conflictos al interior del equipo de trabajo Alejamiento o abandono por parte del diseñador de apoyo en el desarrollo del proyecto Abandono definitivo por parte de algún integrante 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 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: Descripción de los rangos

Gestión

Ponderación de los rangos 

Escala de Priorización: 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

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

Tabla 31: Escala de Priorización



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

Riesgos Priorizados: Riesgo Probabilidad Desconocimiento del software a utilizar en la 0.9 construcción de la aplicación Pérdidas de información por fallas de hardware 0.7 o software Insatisfacción 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 planificación podría llevar a sacrificar la calidad del software Mala estimación de costos de desarrollo de la 0.8 aplicación Falta de recursos de hardware específicos 0.5 (impresora entre otros) Un producto similar sale al mercado 0.5 Problemas de comunicación 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 más grande de lo pensado) Sobredimensionamiento de las capacidades de 0.7 las herramientas a utilizar Cambios en los requerimientos 0.6 Mala calendarización (estimación de plazos) 0.9 Mala elección del paradigma de desarrollo 0.2 Falta de disponibilidad de la metodóloga en 0.2 enseñanza y aprendizaje Alejamiento o abandono del proyecto por parte 0.5 de la metodóloga en enseñanza y aprendizaje Escaso entendimiento del proceso del software 0.5 por parte del Cliente Problemas de salud de algún integrante del 0.3 equipo de trabajo Conflictos al interior del equipo de trabajo 0.2 Alejamiento o abandono por parte del 0.5 diseñador de apoyo en el desarrollo del proyecto Abandono definitivo por parte de algún 0.5 integrante del equipo Plan de capacitación insuficiente 0.2 Tabla Nº32: Riesgos Priorizados

Impacto MA

Prioridad 2

MA

3

MA

3

MA

5

MA

1

M

11

A

8

M A

12 10

B

14

MA

1

A

6

MA

3

A

7

MA MA A A

4 2 9 9

MA

5

M

12

B

13

A MA

9 5

MA

5

A

9

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 5 11 1 16 2 3 13 15 4 19 23 24 12

Riesgo La necesidad de cumplir plazos en la planificación podría 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 construcción de la aplicación Mala calendarización (estimación de plazos) Pérdidas de información por fallas de hardware o software Insatisfacción por parte del Cliente de la interfaz usuaria Mal dimensionamiento del problema (el problema es más 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 metodología en enseñanza y aprendizaje Alejamiento o abandono por parte del diseñador de apoyo en el desarrollo del proyecto Abandono definitivo por parte de algún integrante del equipo Falta de disponibilidad por parte del Cliente para participar en reuniones con los desarrolladores

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

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 Prioridad: 1 Probabilidad: 0.5 Impacto: MA Período: Ingeniería y Construcción

Hoja de control de riesgo

Fecha de identificación: 19/04/2002 Descripción: Necesidad de cambiar la herramienta de desarrollo durante el proyecto.

Detectado por:

Clasificación:

Asignado a:

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: Tabla 34: Control de Riesgo ID 4

Información de cierre:

Gestión

ID: 5 Prioridad: 1


Fecha de identificación: 15/04/2002 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:


Tabla 35: Control de Riesgo ID:5

ID: 11 Prioridad: 1


Fecha de identificación: 15/04/2002 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 c ada 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:



ID: 1 Prioridad: 2


Fecha de identificación: 15/04/2002 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: Tabla 37: Control de Riesgo ID:1


Gestión

ID: 16


Fecha de identificación: 15/04/2002 Descripción: Mala calendarización (estimación de plazos)

Prioridad: 2 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:


Tabla 38: Control de Riesgo ID: 16

ID: 2


Fecha de identificación: 16/04/2002 Descripción: Pérdidas de información por fallas de hardware o por software

Prioridad: 3 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:



ID: 3


Fecha de identificación: 17/04/2002 Descripción: Insatisfacción por parte del Cliente de la interfaz usuaria

Prioridad: 3 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 r especto 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:



Gestión

ID: 13 Prioridad: 3


Fecha de identificación: 15/04/2002 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:



ID: 15


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:


Tabla N°44: Control de Riesgo ID:15

ID: 19 Prioridad: 5


Fecha de identificación: 19/04/2002 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:



Anexos

ID: 23 Prioridad: 5


Fecha de identificación: 17/04/2002 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:



ID: 24


Fecha de identificación: 22/04/2002 Descripción: Abandono definitivo por parte de algún integrante del equipo

Prioridad: 5 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 t odos 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:



ID: 12 Prioridad: 6


Fecha de identificación: 19/04/2002 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 c omprobació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:



Plan de Calidad Para Producto de Software 2 (Corta)

Recommend Documents