Documento Del Plan de Gestion de Riesgosv1.0

SISTEMA DE ATENCIÓN AL CLIENTE DE RESTAURANTE-SACR Version: 2.
Plan de Gestión de Riesgos Fecha: 16-Nov-17
Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx
PLAN DE GESTIÓN DE RIESGOS PARA EL PROYECTO

“SACR” SISTEMA DE ATENCIÓN AL CLIENTE DE
RESTAURANTE
Documento de identificación, análisis y estrategias para el

control de riesgos
Versión 1.0
Confidencial ©UNMSM-FISI-IS, 2017 Page 1

SISTEMA DE ATENCIÓN AL CLIENTE DE RESTAURANTE-SACR Version: 2.0
Historial de Revisiones
Fecha Versión Descripción Autor

Valdez Aguilar, Paulo
Quiroz Morante, Jair
Identificación, análisis y
Sánchez Cerrón, Jhon
07/11/2017 1.0 estrategias para el control de
Martínez Lizares, Gustavo
riesgos.
Huamani Castro, Christian
Nuñez Supo, David
Valdez Aguilar, Paulo
Quiroz Morante, Jair
Identificación, análisis y
Sánchez Cerrón, Jhon
15/11/2017 2.0 estrategias para el control de
Martínez Lizares, Gustavo
riesgos.
Huamani Castro, Christian
Nuñez Supo, David

Contenido
1. INTRODUCCIÓN
1.1 Introducciòn ........................................................................................................................... 4

2. RIESGOS DEL SOFTWARE
2.1 Categorizaciòn de riesgos.................................................................................................. 4

2.2 Tabla de riesgos .................................................................................................................. 5
3. IDENTIFICACIÓN DE LOS RIESGOS
3.1 Riesgos en el tamaño del producto ....................................Error! Bookmark not defined.

3.2 Riesgos en el impacto del negocio ......................................Error! Bookmark not defined.
3.3 Riesgos relacionados con el cliente .................................................................................. 8
3.4 Riesgos del proceso de producción .................................................................................. 9
3.5 Riesgos respecto al entorno de desarrollo ..................................................................... 10
3.6 Riesgos tecnológicos ....................................................................................................... 11
3.7 Riesgos asociados al equipo y la experiencia ................................................................. 11
4. ANÁLISIS DE LOS RIESGOS
4.1 Especificación .......................................................................Error! Bookmark not defined.

5. PLANEACIÓN DE RIESGOS

6. SUPERVISIÓN DE RIESGOS

7. PLAN RSGR

8. ANEXOS
8.1 Glosario de Términos ...........................................................Error! Bookmark not defined.

8.2 Fuentes y referencias ...........................................................Error! Bookmark not defined.

1. INTRODUCCIÓN
La era tecnológica y la globalización de la economía han traído como consecuencia el
aumento sustancial de los riesgos en general, y en particular del proceso de software. Por
lo tanto, para nuestro Sistema de Atención al Cliente de Restaurante (SACR), la no
administración de los riesgos puede implicar la posibilidad del fracaso del restaurante.
De este modo, se desarrollará un Plan de Gestión De Riesgos, que incluirá la identificación,
análisis, planeación y supervisión de estos, ya que facilitará al equipo de software a que se
cuente con estrategias para accionar contra posibles riesgos que se presenten en el
proyecto y tener impactos significativos en la fecha de entrega o en el presupuesto
establecido.
2. RIESGOS DEL SOFTWARE

Para nuestro Sistema de Atención al Cliente de Restaurante (SACR) hemos considerado las
siguientes características para los riesgos:
 Riesgos conocidos: Descubribles después de una minuciosa evaluación del Plan del
proyecto, tanto del entorno técnico como comercial.
 Riesgos predecibles: se extrapolan de la experiencia de proyectos anteriores.
 Riesgos impredecibles: difíciles de identificar por adelantado.
 Riesgos de proyecto: amenazan al plan del proyecto, la planificación temporal y

los costos.
 Riesgos del producto: amenazan la calidad del software; la implementación puede

llegar a ser imposible.
 Riesgos del negocio: amenaza la viabilidad del software a construir.
En la siguiente tabla podremos los tipos de riesgos identificados con sus diferentes
fuentes:

ID Tipo de Riesgos Riesgos Fuente

RI-01 Riesgos en el Riesgo del tamaño estimado del proyecto Jefe de Proyecto
tamaño del Riesgo del número de transacciones y
producto tamaño de la base de datos
Número de usuarios
RI-02 Riesgos en el Ruptura o mal funcionamiento de alguno de Dirección del
impacto del los equipos esenciales para la preparación restaurante
negocio de los productos
Cliente insatisfecho
Incumplimiento de las normas establecidas
por manipulación de alimentos y
conservación de los mismos
Disfuncionalidad entre los miembros que
conforman cada uno de los equipos de
trabajo y la alta rotación del personal
Número de clientes que usarán el producto
software
Efecto del producto software en la cifra de
ventas del restaurante
Cantidad y calidad de la documentación a
entregar al cliente
Costos asociados al retraso en la entrega del
producto final
Desequilibrios financieros y económicos
RI-03 Riesgos Cliente que no cuente con conocimientos Dirección del
relacionados mínimos sobre las TI actuales restaurante/Jefe
con el cliente Si el cliente está dispuesto a dedicar tiempo de Proyecto
en la especificación formal de
requerimientos, participar en las reuniones
periódicas, revisiones de los documentos de
análisis, diseño, arquitectura, etc.
Cliente se exceda en recomendar al equipo
de proyecto características o
funcionalidades que no estaban planificadas
desde un inicio para el proyecto
Presupuesto establecido por el cliente para
el desarrollo del sistema, sea menor al real
RI-04 Riesgos del No hay una política clara de normalización y Jefe de

proceso de seguimiento de una metodología Proyecto/

producción Si no todos los miembros del equipo Equipo de
conocen los estándares Proyecto
Si no existen plantillas y modelos para todos
los documentos resultado del proceso
No hay supervisión en cada fase de
desarrollo por parte del mismo equipo y del
jefe de proyecto
No disponer de testeo de calidad para el
proyecto de software
RI-05 Riesgos Si no hay herramientas de gestor de Jefe de
respecto al proyectos Proyecto/
entorno de Si no hay herramientas de gestión de Equipo de
desarrollo configuración apropiadas Proyecto
Si todas las herramientas de desarrollo no
estén integradas
No hay ayuda en línea y documentación
disponible
RI-06 Riesgos Tecnología nueva en la organización o Jefe de
tecnológicos negocio Proyecto/
El software no ha sido probado Equipo de
Proyecto
No existe interface de usuario especializada
Existen dudas de que el proyecto sea
realizable
RI-07 Riesgos No contar con el mejor personal disponible Jefe de
asociados al Proyecto/
equipo y la No hay suficiente personal disponible para Equipo de
experiencia desarrollar el proyecto Proyecto
El equipo no está comprometido con toda la
duración del proyecto
3. IDENTIFICACIÓN DE LOS RIESGOS

La lista de comprobación a utilizar para identificar riesgos y que se enfoca en un
subconjunto de riesgos conocidos y predecibles son las siguientes categorías:
Riesgos en el tamaño del producto:

 El riesgo del tamaño estimado del proyecto, en este caso no habría ningún
problema, ya que está planificado de acuerdo con los requerimientos establecidos
y definidos por el cliente juntamente con el equipo de proyecto, para el desarrollo
del software aplicativo para la atención de clientes para el restaurante. Por lo
tanto habría un riesgo si es que no se cumpliesen con lo acordado entre ambas
partes.
 El riesgo del número de transacciones y tamaño de la base de datos, son puntos

muy importantes en cuanto al número transacciones, el sistema deberá soportar el
mayor número de usuarios en línea haciendo algún pago por el consumo realizado
en el restaurante además querrá seguridad máxima al momento de hacer los
pagos mediante el aplicativo y que no intercepten su número de cuenta bancaria.
Del mismo modo la base de datos estará integrada y el tamaño de registro de
usuarios será escalable y rápida en respuesta al tener acceso a ella por parte del
administrador del sistema del aplicativo.
 Otro riesgo sería el número de usuarios, para el proyecto en desarrollo se ha

previsto mediante pruebas unitarias y de integración, que el número de usuarios
no será un problema de sobrecarga para el software aplicativo, ya que estará
diseñado y estructurado para atender varios usuarios en línea. Además si el
número de cambios en los requerimientos es alto, aumentaría los riesgos del
tamaño del software, ya que se estimaba en un inicio una proyección de como
seria para el desarrollo del software pero si se ingresan más requisitos ello podría
provocar grandes cambios que no estaban contemplados, acarreando desajustes
en la planificación, si no existen planes de contingencia que den respuesta y
solución no se podrá ejecutar el proyecto correctamente.
Riesgos en el impacto del negocio:
 El mayor riesgo de alto impacto para el restaurante es la ruptura o mal

funcionamiento de alguno de los equipos esenciales para la preparación de los
productos, tales como hornos, cocina, freidoras, neveras, etc., que eventualmente
retrasarían los procesos o los harían más costosos. Ante este eventual riesgo el
restaurante contara con un servicio de mantenimiento sistemático para garantizar
el buen funcionamiento de los equipos.

 Los consumidores de hoy son muy exigentes a algunos no les gustara la forma y el
tiempo de atención, el modelo de presentación de los platos o la sazón de los
mismos, el proceso de reserva de las mesas, las transacciones o modos de pago,
etc. Todo esto representa un riesgo muy grande, ya que un cliente insatisfecho no
regresa más o peor aún comenta su mala experiencia con amistades o conocidos,
dañando con esto la imagen del restaurante.
 El riesgo legal del restaurante puede estar relacionado con el incumplimiento de

las normas establecidas por manipulación de alimentos y conservación de los
mismos. Para mitigar este riesgo el negocio implementará sistemas de control que
garanticen que la manipulación de alimentos está siendo realizada de acuerdo a las
normas establecidas por el Ministerio de Salud, además realizara jornadas de
capacitación a sus colaboradores sobre estos temas.
 El gran riesgo administrativo que se puede correr en el restaurante es que exista

una disfuncionalidad entre los miembros que conforman cada uno de los equipos
de trabajo y la alta rotación del personal. Sin embargo, el restaurante para
contrarrestar esta situación deberá ser riguroso y metódico en su proceso de
selección, ya que una de las principales cualidades del perfil del personal tenga la
capacidad de trabajar en equipo con actitud orientada a la colaboración y al
cumplimiento de los objetivos organizacionales.
 Otro riesgo es el número de clientes que usarán el producto software, por lo que
el sistema aplicativo que tendrá el restaurante debe abarcar todos los
requerimientos y necesidades reales de los consumidores del restaurante, así
como de los nuevos clientes que se tiene proyectado conseguir a mediano y a largo
plazo.
 Otro riesgo es el efecto que tendrá el producto software en la cifra de ventas del
restaurante, generará pérdidas o ganancias. Lo que busca el restaurante es
incrementar sus ingresos con el desarrollo del aplicativo, mejorar sus procesos y
operaciones actuales, por eso es clave las reuniones periódicas entre el equipo de
proyecto y el cliente, para un buen diseño, desarrollo e implementación de un
producto final eficiente y productivo para el negocio.

 Otro riesgo identificado es sobre la cantidad y calidad de la documentación a

entregar al cliente (jefe de proyecto o representante asignado por el Restaurante),
ya que es importante que la información que ellos reciban sea clara y didáctica, ya
que, si no fuese así, generaría demora en el aprendizaje y en el entendimiento del
manejo del aplicativo por parte de los usuarios del restaurante.
 Otro riesgo son los costos asociados al retraso en la entrega del producto final,
esto afectaría de sobremanera el desarrollo planificado en un inicio, ya que el
cliente estaría en espera y además esto generaría gastos que no estaban
presupuestados inicialmente ya programados para toda la duración del proyecto.
Por lo que es importante cumplir con el cronograma ya establecido entre ambas
partes sobre la duración y entrega del aplicativo para el restaurante.
 De lo anterior se generarían costos asociados, como los créditos bancarios

realizados por el restaurante que se tienen que pagar en las fechas acordadas con
la entidad financiera, retraso o alto a las operaciones a los contratos con
proveedores, etc.
 Otro riesgo son los desequilibrios financieros y económicos, lo cual origina una
disminución de la demanda y la baja los precios, la cantidad de consumidores
disminuye porque no podrían pagar si es que los precios de los platos son muy
caros o por el alza de los insumos necesarios para la preparación de los platos.
Riesgos relacionados con el cliente:
 El riesgo seria que el cliente no tenga ni idea o que cuente con conocimientos
mínimos sobre las TI actuales. Que no esté actualizado con lo último en tecnología
si representa un gran riesgo, ya que el equipo del proyecto tendrá que hacer un
trabajo especial previo de capacitación para el conocimiento de la tecnología a
aplicar como una guía en catálogo de los costos de la tecnología a usar, su
funcionamiento, forma de uso, alcance de la misma, como sería la migración de
datos, los equipos tecnológicos necesarios para la desarrollo y la implementación,
recursos, etc. Si la tuviera, tendría una idea clara del sistema que él desea que se
desarrolle para el restaurante, mejoraría en gran manera el desarrollo del
proyecto.

 Otro riesgo seria si el cliente está dispuesto a dedicar tiempo en la especificación

formal de requerimientos, participar en las reuniones periódicas, revisiones de
los documentos de análisis, diseño, arquitectura, etc., con el equipo del proyecto.
Para ello es de gran importancia que el cliente esté involucrado con cada fase de
desarrollo del proyecto, ya que esto minimizara los riesgos de que el proyecto
fracase o no acabe satisfactoriamente como estaba planeado desde un inicio.
 Otro riesgo puede ser que el cliente se exceda en recomendar al equipo de

proyecto características o funcionalidades que no estaban planificadas desde un
inicio para el proyecto, y que estas se realicen en el transcurso del desarrollo del
mismo, generando una ruptura en el plan de costos y recursos. Por eso es
importante definir los requisitos rigurosamente y si es que se van agregar nuevas
funcionalidades al software en desarrollo, explicarle al cliente previas reuniones
que eso generaría riesgos como el incremento de costos, tiempo y recursos.
 Otro riesgo es que el presupuesto establecido por el cliente para el desarrollo del
sistema sea menor al real. Hay que hacer conocer y entender al cliente que el
desarrollo de un sistema no es barato y que en un primer momento si se haría un
gran gasto pero que a mediano y largo plazo para el restaurante, se notarían las
mejoras en el aumento de los ingreso, utilidades, mejora en la gestión,
operaciones y control de las actividades que realiza el negocio. Además que
entienda el ciclo de vida de una aplicación, ya que esta necesitara de revisiones en
la configuración, mantenimiento y de las actualizaciones de software necesarias
para su buen funcionamiento.
Riesgos del proceso de producción:
 El riesgo de si hay una política clara de normalización y seguimiento de una

metodología, si debe de existir, sin ella no habría orden y claridad en la
elaboración de los procesos del software, la metodología sirve de soporte para
estructurar un modelo de desarrollo actual.
 El riesgo si todos conocen los estándares, el equipo debe de tener conocimiento

de las normas de desarrollo, para ello deben contar con material técnico,
documentación de normas software, etc., que servirán para realizar en cada etapa

del ciclo de vida del software aplicativo SACR, el desarrollo sin conflictos con los
estándares ya establecidos internacionalmente.
 El riesgo de si existen plantillas y modelos para todos los documentos resultado

del proceso, es primordial para el aseguramiento de que todos los procesos que se
han elaborado y desarrollado durante las fases de construcción del aplicativo estén
registrados en documentos que servirán como respaldo para proyectos futuros.
 El riesgo de si aplican revisiones técnicas de la especificación de requerimientos,

diseño y codificación, todo proyecto software tiene la supervisión en cada fase de
desarrollo por parte del mismo equipo y del jefe de proyecto, con ello se hace un
seguimiento constante, si se produce algún error, cambio o desajuste en el
proceso este será corregido o cambiado para preservar la buena marcha del
proyecto. Del mismo modo se usan métodos específicos para analizar el software y
para el diseño arquitectónico y de datos.
 El riesgo de si disponen de testeo de calidad para el proyecto de software, las

pruebas unitarias y de integración proveen de resultados confiables para su
posterior análisis, si el software desarrollado está funcionando correctamente o
presenta lentitud, rendimiento bajo, o se sobrecarga la base de datos, etc. la
calidad del producto final es clave ya que el usuario no le importa mucho el código,
sino que el programa funcione rápido y eficientemente.
Riesgos respecto al entorno de desarrollo:
 El riesgo si no hay herramientas de gestor de proyectos, esta herramienta es muy

importantes ya que sirve de modelo de elaboración de un proyecto. Además hay
otras herramientas que son muy significativas para el entorno de desarrollo como
son la de gestión del proceso de desarrollo, de análisis y diseño, generadores de
código para la aplicación y el de pruebas.
 El riesgo si no hay herramientas de gestión de configuración apropiadas, la

configuración para el aplicativo SACR es primordial ya que ahí se definen las
características y funcionalidades que tendrá.

 El riesgo de que todas las herramientas de desarrollo no estén integradas, sería

muy grave, porque la integración de las mismas hace posible un buen entorno de
desarrollo. Además, se debe hacer uso de una base de datos robusta, dinámica,
compatible y que esté integrada con las herramientas que se utilizaran para dar
funcionamiento al software.
 El riesgo si no hay ayuda en línea y documentación disponible, si debe de haber

material y documentación que ayude al equipo de trabajo a realizar el análisis, el
diseño, la arquitectura y para la codificación, etc., esto sirve como respaldo para
poder elaborar un plan de actividades, ya que todos los proyectos no van a ser
iguales y se necesita de información especializada y variada que sirva como guía
para desarrollar un software en este caso un aplicativo para el restaurante.
Además el jefe de proyecto ya cuenta con gran experiencia, es un experto al cual
solicitar ayuda acerca de las herramientas a utilizar en el entorno de desarrollo.
Riesgos tecnológicos:
 El riesgo de ser una tecnología nueva en la organización o negocio, si es un punto

importante que desarrollar ya que se tendrían que hacer cambios en el software,
migración de datos, tal vez la adquisición de equipos nuevos o compatibles con la
nueva versión y en la capacitación del personal del restaurante.
 Otro riesgo es que, si debe interactuar con software que no ha sido probado, no
es recomendable ya que todo proceso de desarrollo de software está compuesto
por fases en cada una se tienen que cumplir normas técnicas que posibilitan crear
un software de calidad y de alto rendimiento. El aplicativo para el restaurante
estará diseñado y estructurado siguiendo los patrones vigentes de creación de
software.
 Otro riesgo es requerir de una interface de usuario especializada, esto hecho

puede generar que usuarios que no son especializados, se compliquen cuando
interactúen con el aplicativo, no entienden bien la funcionalidad de un icono o al
realizar una transacción o que la misma sea muy lenta de procesar. Todo esto
puede traer consecuencias negativas para el software en desarrollo.

 Otro riesgo es que existen dudas de que el proyecto sea realizable, esto puede
deberse a la falta de recursos, equipo de trabajo no convencido en el objetivo, el
tiempo estimado este siendo rebasado, etc.
Riesgos asociados al equipo y la experiencia:
 El riesgo de si contamos con el mejor personal disponible, es punto clave que el

equipo encargado de desarrollo de un proyecto, tiene que ser personas entusiastas
y responsables con el proyecto, en este caso desarrollar el aplicativo para atención
de clientes de restaurante, muy aparte de la calidad como profesionales, estudios,
conocimientos de métodos de programación, análisis, diseño, arquitectura,
pruebas unitarias y de integración, implementación y control del software. Y
contar con experiencia que acredite sus competencias, es más importante su
vocación y colaboración con el equipo para sacar adelante el proyecto.
 Otro riesgo es si hay suficiente personal disponible para desarrollar el proyecto,

se debe contar con un equipo estable de trabajo, ya que cuando se asignen nuevos
proyectos de desarrollo sea más fácil organizar el esquema de trabajo, el
planeamiento, etc.
 Otro riesgo es si el equipo está comprometido con toda la duración del proyecto,
a veces sucede que parte del equipo se retira y entra nuevo personal, pero eso
perjudica el buen desarrollo ya que les va a tomar tiempo ponerse al corriente y
eso produce demora de los entregables, que fueron establecidos en el cronograma
de actividades. Además la rotación del personal perjudicar también el proceso de
desarrollo.

4. ANALISIS DE RIESGOS
MAGNITUD
PROBABILIDAD DE LA EXPOSICION
RIESGO CATEGORIA RSGR
DE PERDIDA PERDIDA AL RIESGO
(SEMANAS)
Errores en la estimación del
TP 30% 5 1,5 A.1.1
presupuesto.
Cambio de políticas de Gestión. TP 15% 12 1,8 A.2.1
Seguridad del sitio. PR 25% 10 2,5 A.3.2
Soporte y mantenimiento. PR 10% 12 1,2 B.2.1
Inexperiencia del equipo técnico para
NE 15% 10 1,5 B.3.1
la implementación del proyecto.
Dificultad de la comunicación entre
los miembros del grupo de desarrollo NE 10% 5 0,5 B.4.2
del proyecto.
Desconocimiento o poco conociendo
por parte del equipo de desarrollo en NE 5% 10 0,5 B.2.1
la utilización de las herramientas.

PRIORIZACION DE RIESGOS
MAGNITUD
RELEVANCIA
EXP. AL DE LA
RIESGO PERDIDA
PARA LA
RIESGO GESTION
(SEMANAS)
Seguridad del sitio. 2.5 10 2
Cambio de políticas de Gestión. 1.8 12 3
Errores en la estimación del presupuesto. 1.5 5 5
Inexperiencia del equipo técnico para la
1.5 10 2
implementación del proyecto.
Soporte y mantenimiento. 1.2 12 4
Dificultad de la comunicación entre los
miembros del grupo de desarrollo del 0.5 5 2
proyecto.
Desconocimiento o poco conociendo por
parte del equipo de desarrollo en la 0.5 10 4
utilización de las herramientas.

EXP. AL RIESGO
Desconocimiento o poco…
Dificultad de la…
Soporte y mantenimiento.
Inexperiencia del equipo…

EXP. AL RIESGO
Errores en la estimación del…
Cambio de políticas de…
Seguridad del sitio.
0 0.5 1 1.5 2 2.5 3

5. PLANEACIÓN DE RIESGOS
Información del Riesgo Estrategia seleccionada

Evitar Transfer Acciones
Mitigar Aceptar Se asigna a:
ID Descripción Prioridad el ir el a realizar
el riego el riesgo
riesgo riesgo
Contar con un servicio de
mantenimiento
RI- Alta sistemático para Dirección del
Seguridad del sitio. X
0206 Prioridad garantizar el buen restaurante
funcionamiento de los
equipos.
Establecer normativas en
el proceso de desarrollo,
RI- Cambio de políticas Alta de análisis y diseño, Dirección del
X
0502 de Gestión. Prioridad generadores de código restaurante
para la aplicación y el de
pruebas.
Se tomará en cuenta
todos los impuestos
correspondientes,
honorarios y otros gastos
Errores en la Dirección del
RI- Media no relacionados con los
estimación del X restaurante/Jefe
O3O4 Prioridad recursos a los gerentes y
presupuesto. de Proyecto
expertos. Esto dará una
visión total del
presupuesto del
proyecto.

Contar con experiencia

que acredite sus
Inexperiencia del Jefe de Proyecto/
competencias, es más
RI- equipo técnico para Media Equipo de
X importante su vocación y
0404 la implementación Prioridad Proyecto
colaboración con el
del proyecto.
equipo para sacar
adelante el proyecto.
Contratar este servicio
Jefe de Proyecto/
para corregir errores,
RI- Soporte y Media Equipo de
X mejorar el rendimiento, u
0601 mantenimiento. Prioridad Proyecto
otros incidentes en el
sistema.
Propiciar el clima laboral
Dificultad de la
entre los miembros del Jefe de Proyecto/
comunicación entre
RI- Baja grupo de desarrollo del Equipo de
los miembros del X
0402 Prioridad proyecto. Impulsar las Proyecto
grupo de desarrollo
reuniones de integración
del proyecto.
en el equipo.
Desconocimiento o
Contar con material y
poco conociendo
documentación que Jefe de Proyecto/
por parte del
RI- Baja ayude al equipo a realizar Equipo de
equipo de X
0501 Prioridad el análisis, el diseño, la Proyecto
desarrollo en la
arquitectura y la
utilización de las
codificación.
herramientas.

8. ANEXOS
Glosario de Términos
 Software: todo programa ejecutable por computador. Se usa son frecuencia para
designar el sistema operativo de un computador más los programas que traducen.
 Usuario: persona que aplica un sistema informático a sus necesidades mediante

los programas adecuados.
 Entrada: trasferencia de datos o instrucciones de programa a la memoria desde un

periférico. Se utiliza en ocasiones para referirse a los datos.
 Cliente: es aquella persona que a cambio de un pago recibe servicios de alguien

que se los presta por ese concepto. Persona que compra en un establecimiento
comercial o público.
 Herramienta de desarrollo: programa que ayuda a desarrollar otros programas.
 Ingeniería de software: término que describe el proceso de diseñar programas de

computadora, que son fáciles de escribir, comprobar, modificar, leer, y funcionar.
El término intenta abarcar a la programación y las actividades involucradas a lo
largo del ciclo de vida de los programas.
 Interfaz: software necesario para interconectar un sistema de información.
 Menú: conjunto de opciones que se presentan al usuario a través de la pantalla, a

lo largo de un proceso interactivo para que pueda escoger la opción más idónea.
 Procedimiento: secuencia de pasos requeridos para solucionar un problema.

Descripción de un código que actúa como una subrutina en leguaje de alto nivel.
 Programa: conjunto de instrucciones ordenadas, que permiten realizar una tarea o

trabajo específico por un computador.

 Programación: proceso de construcción de programas a partir de las

especificaciones de problemas que se requieren resolver mediante un software.
 Salida: datos o resultados generados en un proceso o programa que han de ser

presentados al usuario mediante un dispositivo de salida.
Fuentes y Referencias
Guía de los Fundamentos de la Dirección de Proyectos. Tercera Edición. Norma Nacional
Americana. ANSI/ PMI 99-001-2004. Ed. Project Management Institute, Inc. EEUU. 2004.
409p. ISBN: 1-930699-73-5
[DAVIS93] A. Davis, Software Requirements. Objects, Functions and States, Englewood
Cliffs, Prentice Hall, New Jersey, 1993.
[GOTEL 94] Gotel, O.C.Z., Finkelstein, A.C.W., “An Analysis of the Requirements
Traceability Problem”, International Conference on Requirements Engineering, ICRE’94,
Los Alamitos, California, Abril, 1994, pp 94-101.
[SOM97] Sommerville, I., Sawyer, P., Requirements Engineering, Chichester, John Wiley &
Sons, 1997.
[PRESSMAN02] Pressman R. Ingeniería de Software. Un Enfoque Práctico. Quinta Edición.
McGraHill,2002
[GOTEL94] Publicado por Patricio Letelier, Requerimients Traceability. DOI= http://www.
dsic. upv.es/~letelier/ pub/p12.ppt, 1994
[JACOB99] I. Jacobson, G. Booch and J. Rumbaugh,The Unified Software Development
Process,1999
[ZULOAGA96] Ing. Luis Zuloaga Rotta, Análisis de Requerimientos, Referencia: The
Standish Group. DOI= http:// ww.campus.dokeos.com /courses/ IS50/document
/Exam.Parcial/An%E1lisis_Requerimientos.ppt?cidReq=IS50,1996
[LÓPEZ03] César López Rodríguez, Ejemplo de desarrollo software utilizando la
metodología RUP, Desarrollo de un sistema para la gestión de artículos deportivos.DOI=
http://ww w .dsic.upv.es / asignaturas/ facultad /lsi /ejemplorup/,2003
[SEWBOK04] Guide to the Software Engineering Body of Knowledge, SWEBOK®, A project
of the IEEE Computer Society Professional Practices Committe 2004 Version

http://repository.uniminuto.edu:8080/xmlui/bitstream/handle/10656/2989/TTI_Camacho
CarreroMonica_2014.pdf?sequence=1

Documento Del Plan de Gestion de Riesgosv1.0

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Documento Del Plan de Gestion de Riesgosv1.0

Diunggah oleh

Hak Cipta:

Format Tersedia

SISTEMA DE ATENCIÓN AL CLIENTE DE RESTAURANTE-SACR Version: 2.

Plan de Gestión de Riesgos Fecha: 16-Nov-17

Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx

PLAN DE GESTIÓN DE RIESGOS PARA EL PROYECTO

Documento de identificación, análisis y estrategias para el

Confidencial ©UNMSM-FISI-IS, 2017 Page 1

Plan de Gestión de Riesgos Fecha: 16-Nov-17

Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx

Fecha Versión Descripción Autor

Confidencial ©UNMSM-FISI-IS, 2017 Page 2

Plan de Gestión de Riesgos Fecha: 16-Nov-17

Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx

1.1 Introducciòn ........................................................................................................................... 4

2.1 Categorizaciòn de riesgos.................................................................................................. 4

3.1 Riesgos en el tamaño del producto ....................................Error! Bookmark not defined.

4.1 Especificación .......................................................................Error! Bookmark not defined.

5.1 Especificación .......................................................................Error! Bookmark not defined.

6.1 Especificación .......................................................................Error! Bookmark not defined.

7.1 Especificación .......................................................................Error! Bookmark not defined.

8.1 Glosario de Términos ...........................................................Error! Bookmark not defined.

Confidencial ©UNMSM-FISI-IS, 2017 Page 3

Plan de Gestión de Riesgos Fecha: 16-Nov-17

Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx

2. RIESGOS DEL SOFTWARE

 Riesgos predecibles: se extrapolan de la experiencia de proyectos anteriores.

 Riesgos impredecibles: difíciles de identificar por adelantado.

 Riesgos de proyecto: amenazan al plan del proyecto, la planificación temporal y

 Riesgos del producto: amenazan la calidad del software; la implementación puede

 Riesgos del negocio: amenaza la viabilidad del software a construir.

Confidencial ©UNMSM-FISI-IS, 2017 Page 4

Plan de Gestión de Riesgos Fecha: 16-Nov-17

Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx

ID Tipo de Riesgos Riesgos Fuente

Confidencial ©UNMSM-FISI-IS, 2017 Page 5

Plan de Gestión de Riesgos Fecha: 16-Nov-17

Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx

proceso de seguimiento de una metodología Proyecto/

3. IDENTIFICACIÓN DE LOS RIESGOS

Confidencial ©UNMSM-FISI-IS, 2017 Page 6

Plan de Gestión de Riesgos Fecha: 16-Nov-17

Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx

 El riesgo del número de transacciones y tamaño de la base de datos, son puntos

 Otro riesgo sería el número de usuarios, para el proyecto en desarrollo se ha

Riesgos en el impacto del negocio:

 El mayor riesgo de alto impacto para el restaurante es la ruptura o mal

Confidencial ©UNMSM-FISI-IS, 2017 Page 7

Plan de Gestión de Riesgos Fecha: 16-Nov-17

Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx

 El riesgo legal del restaurante puede estar relacionado con el incumplimiento de

 El gran riesgo administrativo que se puede correr en el restaurante es que exista

Confidencial ©UNMSM-FISI-IS, 2017 Page 8

Plan de Gestión de Riesgos Fecha: 16-Nov-17

Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx

 Otro riesgo identificado es sobre la cantidad y calidad de la documentación a

 De lo anterior se generarían costos asociados, como los créditos bancarios

Riesgos relacionados con el cliente:

Confidencial ©UNMSM-FISI-IS, 2017 Page 9

Plan de Gestión de Riesgos Fecha: 16-Nov-17

Proyecto SACR– Documento del Plan de Gestión de Riesgos.docx

 Otro riesgo seria si el cliente está dispuesto a dedicar tiempo en la especificación

 Otro riesgo puede ser que el cliente se exceda en recomendar al equipo de

Riesgos del proceso de producción:

 El riesgo de si hay una política clara de normalización y seguimiento de una

 El riesgo si todos conocen los estándares, el equipo debe de tener conocimiento