Se debe desarrollar una versión móvil del sistema académico, que cumpla con los mismos procesos que

la aplicación web, tanto para

estudiantes como para profesores.
PRODUCTOS A ENTREGAR
SISTEMA ACADEMICO DE LA UNIVERSIDAD Matriculación
ABC Gestión de calificaciones
Pagos
Requisitos de estudiantes
BASE DE DATOS Información de estudiantes
Información de docentes
DOCUMENTACION BD Información detallada de las
funcionalidades, límites y restricciones de la
BD
MANUAL DE USUARIO Información de cómo usar el sistema
2.
3.
Visión Necesidades
Financiera • Renovar el sistema académico.
• Optimizar y dar buen uso de los recursos económicos del
proyecto.
• Rentabilidad en el desarrollo del proyecto.

Cliente • Disminuye el tiempo de los procesos de matrícula y pagos de

los estudiantes.
• Agiliza los pagos de las matrículas.
• Accesibilidad de la información en lugares remotos.
• Disminuye el tiempo para el registro de notas para la
aprobación o no del semestre en las diferentes asignaturas.
• Proporciona una interfaz amigable para el usuario (estudiante,
profesor, secretaria).
 • Disminuye la concentración del trabajo a una solo área
(secretaria) y la divide.
• Cubrir necesidades de los estudiantes y los profesores de
manera ágil, clara y precisa.

Procesos • Mejora el proceso de matrículas y pagos en línea.

internos • Generan reportes reales de las actividades que se realizan en el
transcurso de un tiempo.
• Mejora procesos de ingreso de notas de los estudiantes por
parte de los profesores.
• Ingreso de horarios, periodos, asignaturas de un semestre.
• Mejora el proceso del cumplimiento de los requisitos, así como
el cruce de horarios.
• Incorporar una versión móvil del sistema académico.
• Permitirá la migración de información.

Aprendizaje • Apoyar la capacidad de cambiar y mejorar, y agudizar los

conocimientos de las personas que usaran el nuevo sistema
académico.
• Capacita a las personas para el uso correcto del nuevo sistema
académico.
• Hacer uso de las ayudar que brindara el sistema académico.

1. Momentos Importantes
El rector de la Universidad ABC ha propuesto a la comunidad universitaria la implantación de un nuevo sistema académico en la institución.
Proceso de migración de datos desde el sistema actual al nuevo sistema.
 Finalmente, al conversar con representantes del departamento financiero mencionan que su prioridad es que el pago de las matrículas se
realice en línea

2. Requerimientos Técnicos
Un servidor de procesador de doble núcleo Marvell ARMADA 385 de 1,3 GHz, 8 TB
de almacenamiento y 4 GB de RAM DDR3.
Sistema operativo linux.
Motor SQL Estándar 2008

4. Estructura de descomposición del trabajo

5. Secuencia de tareas
6. Estimado de esfuerzo
• El esfuerzo estimado del proyecto en horas es equivalente a 36 semanas x 40hrs a la semana= 1,440hrs
• Al año, el puesto o perfil antes descrito recibe una remuneración anual de
$425USD x 2 x 12= $10,200.00 USD

• La tasa de USD/hr equivale entonces a

$10,200 USD / 1,440 hrs. = $7,08USD/hr.

• Asumiendo que los cuatro recursos participan en el proyecto el mismo número de semanas tenemos:
• El perfil de junior implica una remuneración de:
 $8,743USD (10,200/1680 x 1440), USD/hr x hrs_proy.

• Por tanto, en recurso humano es necesario pagar:

$8,743USD x 4= 34,972 USD

• Pago por vacaciones

$425USD (10,200 /24) Sueldo anual/24
$425 x 4=1,700 USD

7. Calendarización de tareas

Kellly
Fase N° de
ACTIVIDADES Predecesor Integrantes Sanchez

(Gerente)

1. Gestión de proyectos
1.1 Planificación
Planificación 1.1.1 Presupuesto 4 6
Planificación 1.1.2 Definición de roles en el equipo de trabajo 1.1.1 1 6
Planificación 1.1.3 Plan de Gestión de Riesgos 4 5
1.2 Reuniones 1,1 4 3
1.3 Documentación 1,1 1
2. Requerimientos
2.1 Especificación de Requisitos
Requerimiento 2.1.1 Módulo de Matrículas 2,1
s
Requerimiento 2.1.1.1 Ingreso de Matrícula 3 2
s
Requerimiento 2.1.1.2 Pagos de Matricula 3 2
s
Requerimiento 2.1.1.3 Consulta de Matrícula 3 2
s
Requerimiento 2.1.1.4 Modificación de Matrícula 3 2
s
Requerimiento 2.1.2 Módulo de calificaciones 2,1
s
Requerimiento 2.1.2.1 Ingreso de calificaciones 3 8
s
Requerimiento 2.1.2.2 Consulta de calificaciones 3 8
s
Requerimiento 2.1.2.3 Modificación de calificaciones 3 8
s
Requerimiento 2.1.2.4 Cancelación de calificaciones 3 8
s
Requerimiento 2.1.3 Módulo de Carreras 2,1
s
Requerimiento 2.1.3.1 Ingreso de datos de la carrera 2 2
s
Requerimiento 2.1.3.2 Consulta de datos de la carrera 2 2
s
Requerimiento 2.1.3.3 Modificación de datos de la carrera 2 2
s
Requerimiento 2.1.3.4 Eliminar datos de la carrera 2 2
s
Requerimiento 2.1.4 Módulo de estudiantes 2,1
s
Requerimiento 2.1.4.1 Ingreso de estudiantes 3 2
s
Requerimiento 2.1.2.2 Consulta de calificaciones 3 2
s
Requerimiento 2.1.2.3 Modificación de calificaciones 3 2
s
Requerimiento 2.1.2.4 Eliminar datos del estudiante 3 2
s
Requerimiento 2.2 Documentación 1,3 4 1
s
3. Diseño
Diseño 3.1 Diseño de arquitectura 2,1
Diseño 3.1.1 Prototipos 3 8
Diseño 3.1.2 Aplicación Móvil 3 8
Diseño 3.2 Diseño de interfaces 2,1
Diseño 3.2.1 Diagramas UMl 3 7
Diseño 3.2.2 Mockups 3 7
Diseño 3.4 Documentación 2,2 4 3
4. Desarrollo
Desarrollo 4.1 Desarrollo del Sistema
Desarrollo 4.1.1 Usuario 3 8
PLANIFICACIÓN DE ACTIVIDADES

Grupo de Proyecto

Carolina Ernesto Andres

Mena Horas
(Ingeniera de Quingue Gualoto Mínimo Máximo Acumulada Semana
Total, horas s
requisitos)
de
(Tecnico- (Desarroll
BD) a Equipo
dor)

5 2 2 15 11 20 15 1
6 3 10 21 1
3 1 1 10 6 11 31 1
3 1 1 8 4 16 39 1
6 6 3 9 45 1
2
2
2
5 1 8 5 12 53 2
5 1 8 5 12 61 2
5 1 8 5 12 69 2
5 1 8 5 12 77 2
2
8 24 40 34 45 117 2
8 24 40 34 45 157 2
8 24 40 34 45 197 2
8 24 40 34 45 237 2
3
6 8 5 13 245 3
6 8 5 13 253 3
6 8 5 13 261 3
6 8 5 13 269 3
3
5 1 8 6 12 277 3
5 1 8 6 12 285 3
5 1 8 6 12 293 3
5 1 8 6 12 301 3
6 3 2 11 7 15 312 3
4
4
8 16 32 28 38 344 4
8 16 32 28 38 376 4
 5
8 8 23 19 26 399 5
8 8 23 19 26 422 5
6 3 2 14 10 19 436 5

8 24 40 35 43 476 6
Desarrollo 4.1.2 Ingreso de notas del estudiante 2.1.2 3 8
Desarrollo 4.1.3 Modificación de registro de notas del 2.1.2 3 8
estudiante
Desarrollo 4.1.4 Pagos de matrículas 2.1.1 3 5
Desarrollo 4.1.5 Consulta pagos de matrículas 2.1.1 3 8
Desarrollo 4.1.6 Consulta de notas de matrículas 2.1.2 3 8
Desarrollo 4.1.7 Actualización de datos docentes 2.1.3 3 8
Desarrollo 4.1.8 Consulta de datos del estudiante a pagar 2.1.1 3 8
Desarrollo 4.1.9 Lado Servidor 2,1
Codificación 4.2 Programación 4,1
Codificación 4.2.1 Backed 4.1.2 3 8
Codificación 4.2.2 Fronted 4.1.1 3 8
Codificación 4.2.3 Desarrollo Base de datos 4.1.9 3 8
4.6 Documentación 3,4 4 2
5. Testing
Pruebas 5.1 Realizar las Pruebas del sistema 4.2.1, 4.2.2 3 1
Pruebas 5.2 Corrección de Errores 5,1 3 1
Pruebas 5.3 Prueba de Base de datos 4.2.3 3 1
Pruebas 5.4 Documentación 4,6 4 1
6. Migración
Migración 6.1 Análisis de datos 5,1 3 2
Migración 6.2 Transformación de datos 5,1 3 2
 Migración 6.3 Migrar los datos 5,1 3 2
Migración 6.4 Validación 5,1 3 2
Migración 6.5 Documentación 5,4 3 2
7. Implementación
Implementaci 7.1 Elaborar la documentación 6,5 4 4
ón
Implementaci 7.1.1 Manual de usuario 2
ón
7.2 Plan de mantenimiento y soporte
7.2.1 Sistema Web 4 4
7.2.2 Aplicación Movil 4 4

8 24 40 35 43 516 6
8 24 40 35 43 556 6

8 24 37 33 41 596 6
8 24 40 26 43 636 6
8 24 40 26 43 676 7
8 24 40 26 43 716 7
8 24 40 26 43 756 7
7

8 24 40 25 44 796 8
8 24 40 25 44 836 8
8 24 40 25 44 876 8
5 3 1 11 8 14 887 8

3 8 12 8 16 899 9
3 8 12 8 16 911 9
8 2 11 6 14 987 9
 5 2 1 9 5 13 998 9

7 1 10 7 14 1008 10
10 3 15 11 19 1023 10
16 3 21 18 25 1044 10
6 2 10 6 15 1054 10
6 1 9 5 14 1063 10

16 2 2 24 20 30 1087 11
4 10 14 11 19 1101 11
11
2 2 2 10 6 14 1111 12
2 2 2 10 6 14 1121 12
780 1267 1121

8. Asignación de tareas a recursos disponibles

Miembro Rol Responsabilidades
Kelly Sánchez • Gerente del proyecto • Planificar el proyecto
• Capacitador • Mantener el proyecto dentro del presupuesto
• Dar solución de problemas
• Relacionar el sistema web con los usuarios que van a hacer uso de la misma
Andrés Gualoto • Analista del proyecto • Entender las necesidades del cliente.
• Diseñador gráfico • Crear un diseño consistente en todo el sistema.
Ernesto Quingue • Desarrollador • Responsable de hacer el seguimiento de su propio progreso
• Tester • Implementar las ideas del arquitecto.
• Documentar el código.

Carolina Mena • Arquitecto de Software
• Arquitecto del Sistema
• Revisar y probar que el código sea funcional
• Traducir los requisitos en una solución técnica.
• Decidir qué camino tomar en base a la arquitectura global que ha elegido.
• Pensar el sistema antes de construirlo.
• Tener en cuenta los requisitos de rendimiento y disponibilidad, el número de
usuarios / visitantes, etc. y en base a esto, diseña una infraestructura de servidores
y una red.

9. Roles y responsabilidades
R: Responsable A: Au torización C: Consultoría I:Informado

GERE TÉCNI TÉCN TÉCNI EXPERT

Actividades RECTO DIREC DIREC NTE CO ICO CO DISEÑ O EN EXPERT
R TOR TOR DE (Caroli (Ernes (André ADO MIGRAC O EN
(Sponsor FINANC TECNOL PROY na to s R IÓN DE SEGURI
) IERO OGÍAS ECTO Mena) Quing Gualot GRÁ DATOS DAD
(Kelly ue) o) FICO
1. Gestión del Proyecto
1.1 Planificación
1.1.1 Establecer objetivos y A C C R I I I
estrategias
1.1.2 Presupuesto A C R I I I
1.1.3 Definición de Roles A R I I I
1.1.4 Plan de Gestión de Riesgos A C R I I I
1.2 Reuniones A R I I I
1.3 Documentación A C R I I I
2. Requerimientos
2.1 Especificación de Requisitos
2.1.1 Módulo de Matrículas
2.1.1.1 Ingreso de Matrícula A C R I I I
2.1.1.2 Pago de Matrícula I C R I I I
2.1.1.3 Consulta de Matrícula I C R I I I
2.1.1.4 Modificación de Matrícula A C R I I I
2.1.1.5 Cancelación de Matrícula A C R I I I
2.1.2 Módulo de Calificaciones
2.1.2.1 Ingreso de Calificaciones A C R I I I
2.1.2.2 Consulta de Calificaciones A C R I I I
2.1.2.3 Modificación de A C R I I I
Calificaciones
2.1.2.4 Cancelación de A C R I I I
Calificaciones
2.1.3 Módulo de Carrera
2.1.3.1 Ingreso de datos de la carrera A C R I I I
2.1.3.2 Consulta de datos de la A C R I I I
carrera
2.1.3.3 Modificación de datos de la A C R I I I
carrera
2.1.3.4 Eliminar datos de la carrera A C R I I I
2.1.4 Módulo de Estudiantes
2.1.4.1 Ingreso de datos del A C R I I I
estudiante
2.1.4.2 Consulta de datos del A C R I I I
estudiante
2.1.4.3 Modificación de datos del A C R I I I
estudiante
2.1.4.4 Eliminar datos del estudiante A C R I I I
2.2 Documentación
3. Diseño
3.1 Diseño de la Arquitectura
3.1.2 Prototipos I A C C R C
3.2 Diseño de base de datos I A R C I C
3.3 Diseño de Interfaces

3.3.1 Prototipos
3.4 Documentación
3.4.1 Diagramas UML I A R I I
3.4.2 MockUps I A I R I C
4. Desarrollo
4.1 Desarrollo del sistema
4.1.1 Lado del Usuario
4.1.1.1 Ingreso de notas del I I A R I I
estudiante
4.1.1.2 Modoficación de datos del I I A R I I
estudiante
4.1.1.3 Consulta de datos del I I A R I I
estudiante
4.1.1.4 Pagos de matrículas I I A I R I
4.1.1.5 Consulta de pagos de I I A I R I
matrículas
4.1.1.6 Ingreso de calificaciones del I I A I R I
estudiante
4.1.1.7 Modificación de I I A I R I
calificaciones del estudiante
4.1.1.8 Consulta de notas I I A I R I
4.1.1.9 Ingreso datos de datos de I I A I I R
docentes
4.1.1.10 Consulta de datos de I I A I I R
docentes
4.1.1.11 Modificación de datos de I I A I I R
docentes
4.1.1.12 Ingresar datos de la carrera I I A R I I
4.1.1.13 Modificación de datos de la I I A R I I
carrera
4.1.1.14 Consulta de datos de la I I A R I I
carrera
4.1.2 Lado del Servidor A I R I C
4.1.3 Programación
4.1.3.1 Backed A I R C C
4.1.3.2 Fronted A C I R
4.2 Desarrollo de la Base de Datos A R I I C
4.3 Documentación A I R I
5. Testing
5.1 Pruebas I I A I R I C
5.2 Revisión de Errores I I A R I I C
6. Migración de Datos
6.1 Análisis de Datos I A R I I
6.2 Transformación de Datos I I A I R I C
6.3 Migración de Datos A I R I I I C
6.4 Validación de Datos A I R I I I C
7. Implementación
7.1 Documentación
7.1.1 Manual de Usuario I I A R
7.1.2 Diccionario de Datos I A R
7.2 Plan de mantenimiento y soporte I I A R I I
10. Presupuesto del proyecto
 Proyecto Planificado para (36 semanas)
Recursos humanos 34,972 USD

Gastos de 2,000 USD

mantenimiento

Adquisición de software 1,500 USD

Pago por vacaciones 1,700 USD

Beneficios (Gastos x 0,5) 20,086 USD

Costos del proyecto antes 60,258 USD

de impuestos

11. Plan de comunicación

Plan de Comunicaciones
del Proyecto
Sistema Académico
Fecha: 19/01/2021
Información del Proyecto

Empresa / Organización Software Developing

Proyecto Sistema Académico
 Fecha de preparación 18/01/2021
Cliente Universidad ABC
Patrocinador principal Universidad ABC
Gerente de Proyecto Kelly Sánchez

Restricciones y Premisas Restricciones de las comunicaciones

• Los involucrados del proyecto no acuerden tiempos disponibles para las reuniones de discusión sobre la gestión.
• Los miembros del equipo de proyecto se encuentran en ubicaciones físicas distintas.

• El manejo de la información es escalable, es decir, varía de gerentes para el suministro de la información requerida.
• En uno de los niveles de acceso para obtener información, el gerente o encargado de proporcionarla, se rehúse a colaborar
con el equipo.
• Que no sea posible establecer comunicación remota con alguno de los involucrados para el manejo de la información.
• Tener inconvenientes con alguno de los involucrados en el proyecto y esto incida en el desarrollo de la gestión.
• Llegada después del tiempo estipulado a las reuniones acordadas o ausencia en las mismas.

Premisas de las comunicaciones

• Todos los involucrados del proyecto poseen correo electrónico y acceso a Internet.
 • Todos los entregables del proyecto realizados por Software Developing consignarán en el portafolio (electrónico y físico) del
proyecto establecido por la coordinación de Proyecto

Roles involucrados en las comunicaciones

Rol Nombre de quien lo realiza Actividades que realiza Entregable generado Cumplimien
to del rol
Planificador del Proyecto Kelly Sánchez − Planear reuniones y actividades a − Plan de comunicaciones del Se cumplo a
de gestión realizarse para la gestión. proyecto. cabalidad
− Planificar la documentación de los − Instrumento de validación.
entregables − Cuestionario.
− Diario de Campo

Tabla de Requerimientos de Comunicación del Proyecto

Comunicación Objetivo Formato Frecuencia Enviado por Recibido por

Reporte Semanal de Informar el estado de las Herramientas de Office utilizando el formato Semanal, Gerente del Rector, Director de
Avance de Proyecto actividades del proyecto al preestablecido y enviado como anexo por todos los proyecto Tecnologías
culminar la semana de trabajo correo electrónico viernes

Informe sobre los Obtener información oportuna Herramientas de Office utilizando el formato Semanal, Gerente del Rector, Director de
entregables del sobre la documentación de la preestablecido y enviado como anexo por Lunes y Proyecto Tecnologías
proyecto Gestión del Proyecto correo electrónico y otros formatos elaborados Miércoles por
por los gestores y gerentes de la lo general
universidad
Reuniones sobre Discutir y recibir información Herramientas de Office utilizando el formato Semanal Gerente del Rector, Director de
actividades y/o relacionada con el desarrollo de preestablecido y enviado como anexo por Proyecto Tecnologías, Director
entregables del la gestión correo electrónico y otros formatos elaborados Financiero
proyecto por los gestores y gerentes de la
universidad. Llamadas telefónicas
12. Plan de control de cambios

PLAN DE GESTIÓN DE CAMBIOS

NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

Sistema Académico para la Universidad SAU

ROLES DE LA GESTIÓN DE CAMBIOS: ROLES QUE SE NECESITAN PARA OPERAR LA GESTIÓN DE CAMBIOS

NOMBRE PERSONA
DEL ASIGNADA RESPONSABILIDADES NIVELES DE AUTORIDAD
ROL
Personal de la Generar la solicitud del
Generador universidad cambio,con definición y Ninguno
del justificación dela misma.
cambio

Desarrollador Revisar criticidad delcambio. Sobre el personal de la

Revisor Nivel Aceptar o no el cambio. universidad
1
 Ingeniera de
Requisitos Comunicar el cambio Sobre el desarrollador
Revisor Nivel aceptado. Generar el
2 cambio.

Revisar criticidad delcambio.

Gerente del Aceptar o no el cambio. Hacer recomendaciones sobre
proyecto Comunicar el cambio
Revisor Nivel los cambios
aceptado. Generar el
3
cambio.
Archivar.
TIPOS DE CAMBIOS: DESCRIBIR LOS TIPOS DE CAMBIOS Y LAS DIFERENCIAS PARA TRATAR CADA UNO DE ELLOS .

Tres tipos de cambios:

1. De costos: Cambios que involucren una modificación de los costos establecidos, ya sea en
materiales o mano de obra principalmente.
2. De alcance: Cambios que soliciten modificar el alcance establecido del proyecto, ya sea por
parte de la organización o del CSJ.
3. De tiempo: Cambios que contengan la solicitud de adicionar tiempo, reprogramación,
combinación o intercambio de tareas.
PROCESO GENERAL DE GESTIÓN DE CAMBIOS: D ESCRIBIR EN DETALLE LOS PROCESOS DE LA GESTIÓN DE CAMBIOS ,
ESPECIFICANDO QUÉ, QUIÉN, CÓMO, CUÁNDO Y DÓNDE.

El solicitante tramitará la solicitud de cambio

en el formato designado, indicando de forma
Solicitud de cambios detallada las causas y consecuencias
contempladas para el cambio. Se pasa el
siguiente nivel para la evaluación del
cambio.
Presenta la solicitud de cambio al director de
proyectos.
 El revisor nivel 1, recibe la solicitud del cambio,
evalúa de acuerdo a la criticidad del cambio si es
posible aceptarla o es necesario escalar la solicitud.
Si la solicitud la puede aceptar, la evalúa. En caso
Revisor Nivel 1 de
aceptar el cambio lo comunica y da trámite al
cambio solicitado. Finamente archiva el cambio
para

retroalimentación del proceso y base de

conocimientos.
Evalúa los impactos integrales del cambio.

El revisor nivel 2, recibe la solicitud del cambio,

evalúa de acuerdo a la criticidad del cambio si es
posible aceptarla o es necesario escalar la solicitud.
Si la solicitud la puede aceptar, la evalúa. En caso
Revisor Nivel 2 de aceptar el cambio lo comunica y da trámite al
cambio solicitado. Finamente archiva el cambio
para retroalimentación del proceso y base de
conocimientos.
 El revisor nivel 3, recibe la solicitud del cambio,
evalúa de acuerdo a la criticidad del cambio si es
posible aceptarla o es necesario escalar la solicitud.
Si la solicitud la puede aceptar, la evalúa. En caso
Revisor Nivel 3 de aceptar el cambio lo comunica y da trámite al
cambio solicitado. Finamente archiva el cambio
para retroalimentación del proceso y base de
conocimientos.

PLAN DE CONTINGENCIA ANTE SOLICITUDES DE CAMBIO URGENTES: DESCRIBIR EL PLAN DE

CONTINGENCIA PARA ATENDER SOLICITUDES DE CAMBIO SUMAMENTE URGENTES QUE NO PUEDEN ESPERAR A QUE SE REÚNA EL
COMITÉ DE CONTROL DE CAMBIOS.

Ante un cambio de suma urgencia, el receptor del cambio lo escalará con el revisor
nivel 3, para que sea el directamente quien realice la gestión sobre la solicitud de
cambio.
HERRAMIENTAS DE GESTIÓN DE CAMBIOS: DESCRIBIR CON QUE HERRAMIENTAS SE CUENTA PARA OPERAR LA
GESTIÓN DE CAMBIOS.

File Server, Microsoft Outlook

SOFTWARE

Escalamientos por niveles de criticidad

PROCEDIMIENTOS

Formato de solicitud de cambios

FORMATOS

N/A
OTROS
 13. Plan de calidad

GXPost
Plan de SQA
Versión 1.0

Historia de revisiones
Fecha Versión Descripción Autor

27/01/2022 1.0 Plan de Calidad Kelly Sánchez

Cynthia Mena

Ernesto Quingue

Andrés Gualoto

Contenido
1. PROPÓSITO ........................................................................................................................... 3

2. REFERENCIAS ...................................................................................................................... 3

3. GESTIÓN................................................................................................................................ 3

3.1. ORGANIZACIÓN .................................................................................................................. 3

3.2. ACTIVIDADES ..................................................................................................................... 3

3.2.1. Ciclo de vida del software cubierto por el Plan ............................................................. 3

3.2.2. Actividades de calidad a realizarse .............................................................................. 3

3.2.3. Revisar cada producto ................................................................................................ 3

3.2.4. Revisar el ajuste al proceso ......................................................................................... 4

3.2.5. Realizar Revisión Técnica Formal (RTF) ...................................................................... 4

3.2.6. Asegurar que las desviaciones son documentadas ......................................................... 4

3.2.7. Relaciones entre las actividades de SQA y la planificación ............................................ 4

3.3. RESPONSABLES .................................................................................................................. 5

4. DOCUMENTACIÓN .............................................................................................................. 5

4.1. PROPÓSITO......................................................................................................................... 5

4.2. DOCUMENTACIÓN MÍNIMA REQUERIDA ................................................................................. 5

4.2.1. Especificación de requerimientos del software .............................................................. 5

4.2.2. Descripción del diseño del software ............................................................................. 6

4.2.3. Plan de Verificación & Validación ............................................................................... 7

4.2.4. Reportes de Verificación & Validación ......................................................................... 7

4.2.5. Documentación de usuario .......................................................................................... 7

4.2.6. Plan de Gestión de configuración ................................................................................ 7

4.3. OTROS DOCUMENTOS .......................................................................................................... 7

5. ESTÁNDARES, PRÁCTICAS, CONVENCIONES Y MÉTRICAS ......................................... 7

5.1. ESTÁNDAR DE DOCUMENTACIÓN .......................................................................................... 8

5.2. ESTÁNDAR DE VERIFICACIÓN Y PRÁCTICAS ........................................................................... 8

5.3. OTROS ESTÁNDARES ........................................................................................................... 8

6. REVISIONES Y AUDITORÍAS .............................................................................................. 8

6.1. OBJETIVO .......................................................................................................................... 8

6.2. REQUERIMIENTOS MÍNIMOS ................................................................................................. 8

6.2.1. Revisión de requerimientos .......................................................................................... 8

6.2.2. Revisión de diseño preliminar ...................................................................................... 8

6.2.3. Revisión de diseño crítico ............................................................................................ 9

6.2.4. Revisión del Plan de Verificación & Validación ............................................................ 9

6.2.5. Auditoría funcional ..................................................................................................... 9

6.2.6. Auditoría física ........................................................................................................... 9

6.2.7. Auditorías internas al proceso ..................................................................................... 9

6.2.8. Revisiones de gestión .................................................................................................. 9

6.2.9. Revisión del Plan de gestión de configuración .............................................................. 9

6.2.10. Revisión Post Mortem ................................................................................................. 9

6.2.11. Agenda ...................................................................................................................... 9

6.3. OTRAS REVISIONES ............................................................................................................. 9

6.3.1. Revisión de documentación de usuario ......................................................................... 9

1. Propósito

El alcance del plan es abarcar la parte del ciclo de vida que corresponde al desarrollo del proyecto con sus diferentes fases.

2. Gestión
1. Organización
Las líneas de trabajo dentro de la organización que están más relacionadas con la calidad del software son: Verificación y Gestión
de Proyecto.

2. Actividades
1. Ciclo de vida del software cubierto por el Plan
Las etapas más importantes del ciclo de vida del software que cubre el Plan son la etapa del relevamiento de requerimientos y el
principio de la etapa de diseño dado una buena especificación de requerimientos y un diseño adecuado constituyen una base sólida
para el proyecto; y errores detectados en forma tardía de estas etapas son muy costosos e incluso podrían hacer fracasar al proyecto.

Los productos de proyecto que tendrán revisiones de calidad son todos los entregables que requiere el modelo de proceso seguido
en el proyecto.

Se hace especial énfasis en los entregables que incluyen:

• Especificación de Requerimientos
• Descripción de la Arquitectura y Alcance del Sistema
• Plan de Verificación
2. Actividades de calidad a realizarse
Las tareas a ser llevadas a cabo deberán reflejar las evaluaciones a realizar, los estándares a seguir, los productos a revisar, los
procedimientos a seguir en la elaboración de los distintos productos y los procedimientos para informar de los defectos detectados
a sus responsables y realizar el seguimiento de los mismos hasta su corrección.
Las actividades que se realizarán son:

• Revisar cada producto

• Revisar el ajuste al proceso
• Realizar Revisión Técnica Formal (RTF)
• Asegurar que las desviaciones son documentadas.
3. Revisar cada producto

Se revisaran los siguientes planes:

• Plan de Gestión de riesgos

• Plan de verificación
• Especificación de requisitos
• Documentación del sistema
Se verificará que no queden correcciones sin resolver en los informes de revisión previos, si se encuentra alguna no resuelta, debe
ser incluida en la siguiente revisión. Se revisan los productos contra los estándares.

4. Realizar Revisión Técnica Formal (RTF)

El objetivo de la RTF es descubrir errores en la función, la lógica ó la implementación de cualquier producto del software, verificar
que satisface sus especificaciones, que se ajusta a los estándares establecidos, señalando las posibles desviaciones detectadas. El
objetivo es llegar a detectar lo antes posible, los posibles defectos o desviaciones en los productos que se van generando a lo largo
del desarrollo.

En la reunión participan el responsable de SQA e integrantes del equipo de desarrollo.

Se convocará a la reunión formalmente a los involucrados, informando del material que ellos deben preparar por adelantado, llevando
una lista de preguntas y dudas que surgen del estudio del producto a ser revisado.

Esta reunión no será mayor a dos horas, para obtener el Informe de RTF.

5. Asegurar que las desviaciones son documentadas

Las desviaciones encontradas en las actividades y en los productos serán documentadas y manejadas de acuerdo a un procedimiento
establecido en el plan de gestión de cambios.

Se verificará que los responsables de cada plan los modifiquen cada vez que sea necesario, basados en las desviaciones encontradas.

6. Relaciones entre las actividades de SQA y la planificación

Actividad Semana cuando se realiza

Planificar la Calidad Semana 2

Evaluar y Ajustar el Plan de SQA Semanas 3 y 4

Revisión Técnica Formal (RTF) Semanas 5, 6, 7, 8, 10, 11 y 12

Revisar las entregas Todas las semanas

Revisar el Ajuste al Proceso Semanas 3 a 12 (inclusive)

Evaluar la calidad de los productos Semanas 3 a 14 (inclusive)

Realizar el informe final de SQA Semana 14

Describir la Versión Semanas 5, 7, 9, 11 y 13

Escribir las notas de la versión Semanas 6, 8, 10, 12 y 14

3. Responsables
Kelly Sánchez (Gerente del proyecto)

3. Documentación
1. Propósito
Identificación de los planes Verificación & Validación, uso y mantenimiento del software.

Se establecerá como los documentos van a ser revisados para chequear consistencia, confirmando el criterio e identificación de las
revisiones.

2. Documentación mínima requerida

• Plan de gestión de actividades.
• Plan de gestión de cambios.
• Plan de gestión de riesgo.
• Documentación del software
1. Especificación de requerimientos del software
El documento de especificación de requerimientos describirá, de forma clara y precisa, cada uno de los requerimientos esenciales
del software además de las interfaces externas.

El cliente deberá obtener como resultado del proyecto una especificación adecuada a sus necesidades en el área de alcance del
proyecto, de acuerdo al compromiso inicial del trabajo y a los cambios que este haya sufrido a lo largo del proyecto, que cubra
aquellos aspectos que se haya acordado detallar con el cliente.

Los requerimientos de calidad del producto a construir son considerados dentro de atributos específicos del software que tienen
incidencia sobre la calidad en el uso’ y se detallan a continuación:

Funcionalidad

a. Adecuación a las necesidades

b. Precisión de los resultados

c. Interoperabilidad

d. Seguridad de los datos

Confiabilidad

a. Madurez

b. Tolerancia a faltas

c. Recuperabilidad

Usabilidad

a. Comprensible

b. Aprendible
c. Operable

d. Atractivo

Eficiencia

a. Comportamiento respecto al tiempo

b. Utilización de recursos

Mantenibilidad

a. Analizable

b. Modificable

c. Estable, no se producen efectos inesperados luego de modificaciones

d. Verificable

Portabilidad

a. Adaptable

b. Instalable

c. Co-existencia

d. Reemplazante

Cada uno de estos atributos debe cumplir con las normas y regulaciones aplicables a cada uno.

2. Descripción del diseño del software

El documento de diseño especificará como el software será construido para satisfacer los requerimientos.

Describirá los componentes y subcomponentes del diseño del software, incluyendo interfaces internas. Este documento será
elaborado primero como Preliminar y luego será gradualmente extendido hasta llegar a obtener el Detallado.

El cliente obtendrá como resultado del proyecto el diseño de un producto de software que cubra aquellos aspectos que se haya
acordado con el cliente incorporar al diseño, en función de la importancia que estos presenten y de sus conexiones lógicas.
 El diseño deberá:

• Corresponder a los requerimientos a incorporar:

a. Todo elemento del diseño debe contribuir a algún requerimiento

b. La implementación de todo requerimiento a incorporar debe estar contemplada en por lo menos un elemento del diseño.
• Ser consistente con la calidad del producto
3. Plan de Verificación & Validación
El Plan de V & V identificará y describirá los métodos a ser utilizados en:

• La verificación de que:
a. Los requerimientos descritos en el documento de requerimientos han sido aprobados por una autoridad apropiada. En este caso sería
que cumplan con el acuerdo logrado entre el cliente y el equipo.

a. Los requerimientos descritos en el documento de requerimientos son implementados en el diseño expresado en el documento de diseño.
b. El diseño expresado en el documento de diseño esta implementado en código.
• Validar que el código, cuando es ejecutado, se adecua a los requerimientos expresados en el documento de requerimientos.
4. Reportes de Verificación & Validación
Estos documentos especificarán los resultados de la ejecución de los procesos descritos en el Plan de V & V.

5. Documentación de usuario
La documentación de usuario especificará y describirá los datos y entradas de control requeridos, así como la secuencia de entradas,
opciones, limitaciones de programa y otros elementos necesarios para la ejecución exitosa del software.

Todos los errores serán identificados y las acciones correctivas descritas.

Como resultado del proyecto el cliente obtendrá una documentación para el usuario de acuerdo a los requerimientos específicos del
proyecto.

6. Plan de Gestión de configuración

El Plan de gestión de configuración contendrá métodos para identificar componentes de software, control e implementación de
cambios, y registro y reporte del estado de los cambios implementados.
 3. Otros documentos
N/A

4. Estándares, prácticas, convenciones y métricas

1. Estándar de documentación
Como estándares de documentación se definirán dos documentos:

• Estándar de documentación técnica y

• Estándar de documentación de usuario.
La documentación técnica del producto:

• Será adecuada para que un grupo independiente del de desarrollo pueda encarar el mantenimiento del producto.
• Incluirá fuentes, Modelos de Casos de Uso, Objetos
Para la escritura de documentos se han definido plantillas para ser utilizadas en la elaboración de entregables.

En estas plantillas se definen:

• Encabezado y pie de página.

• Fuente y tamaño de fuente para estilo normal
• Fuente y tamaño de fuente para los títulos a utilizar
• Datos mínimos que se deben incluir: fecha, versión y responsables.
2. Estándar de verificación y prácticas
Se utilizan las prácticas definidas en el Plan de Verificación y Validación.

Como estándar se utiliza el documento de:

Std 1012-1986 IEEE Standard for Software Verification and Validation Plans.

3. Otros Estándares
N/A

5. Revisiones y auditorías
1. Objetivo
Definición de las revisiones y auditorías técnicas y de gestión que se realizarán.

Especificación de cómo serán llevadas a cabo dichas revisiones y auditorías.

2. Requerimientos mínimos
1. Revisión de requerimientos
Esta revisión se realiza para asegurar que se cumplió con los requerimientos especificados por el Cliente.

2. Revisión de diseño preliminar

Esta revisión se realiza para asegurar la consistencia y suficiencia técnica del diseño preliminar del software.

3. Revisión de diseño crítico

Esta revisión se realiza para asegurar la consistencia del diseño detallado con la especificación de requerimientos.

4. Revisión del Plan de Verificación & Validación

Esta revisión se realiza para asegurar la consistencia y completitud de los métodos especificados en el Plan de V & V.

5. Auditoría funcional
Esta auditoría se realiza previa a la liberación del software, para verificar que todos los requerimientos especificados en el documento
de requerimientos fueron cumplidos.

6. Auditoría física
Esta revisión se realiza para verificar que el software y la documentación son consistentes y están aptos para la liberación.

7. Auditorías internas al proceso

Estas auditorías son para verificar la consistencia: del código versus el documento de diseño, especificaciones de interfase,
implementaciones de diseño versus requerimientos funcionales, requerimientos funcionales versus descripciones de testeo.

8. Revisiones de gestión
Estas revisiones se realizan periódicamente para asegurar la ejecución de todas las actividades identificadas en este Plan. Deben
realizarse por una persona ajena al grupo de trabajo (en caso de que sea posible).
 9. Revisión del Plan de gestión de configuración
Esta revisión se realiza para asegurar la consistencia y completitud de los métodos especificados en el Plan de gestión de
configuración.

3. Otras revisiones
1. Revisión de documentación de usuario
Se revisará la completitud, claridad, correctitud y aplicación de uso.
14. Plan de gestión de riesgos

Plan de Gestión
de Riesgos
SISTEMA ACADÉMICO
Fecha: 30/01/2022
Tabla de contenido
Información del Proyecto ............................................................................................................. 3

Metodología ..................................................................................................................................... 3
Roles y Responsabilidades ......................................................................................................... 3

Definiciones...................................................................................................................................... 3
Identificación de riesgos............................................................................................................... 5

Clasificación del Riesgo ............................................................................................................... 5

Sistema de GPR ............................................................................................................................. 7

Definiciones de Probabilidad e Impacto de Riesgos........................................................... 9

Definiciones de Probabilidad ...................................................................................................... 9

Definiciones de Impacto ............................................................................................................... 9

Matriz de Probabilidad e Impacto.............................................................................................. 9
Revisión de la tolerancia de los interesados (Stakeholders)......................................... 10
Formatos de Registro de Riesgos ......................................................................................... 10

Definición de Acciones .............................................................................................................. 10

Aprobaciones................................................................................................................................ 11

Información del Proyecto

Empresa / Organización Software Developing
 Proyecto Sistema Académico

Fecha de preparación 30/01/2022

Cliente Universidad ABC

Patrocinador principal Autoridades de la institución

Gerente de Proyecto Kelly Sánchez

Metodología
La gestión de los Riesgos del Proyecto incluye los procesos relacionados con llevar a cabo la planificación de la gestión, la
identificación, el análisis, la planificación de respuesta a los riesgos, así como su monitoreo y control en el proyecto.

Roles y Responsabilidades
Gerente del Proyecto
Representa a nuestra empresa frente al cliente
Define y aplica al proyecto los métodos y herramientas estandarizadas de
Gestión de Proyectos
Lidera y organiza el equipo del proyecto.
Es responsable de cumplir con las exigencias de alcance, tiempo y costes del
proyecto.
Prepara los informes periódicos, tanto internos como externos Define e
implementa la estrategia del proyecto, considerando los riesgos y oportunidades
de este Realiza un seguimiento y revisión periódica del estado del proyecto.
 Gestor de Calidad
Planificación de la Calidad, preparación del plan de gestión de calidad
Monitorización y Control de Calidad Control de Calidad
Realización de inspecciones internas y externas
Seguimiento de las quejas del cliente y proveedores

Desarrolladores
Coordinar los trabajos de desarrollo de acuerdo con los requerimientos.

Definiciones
1. Gestión de riesgos: Es el proceso mediante el cual las instituciones identifican, miden, controlan / mitigan y monitorean los riesgos inherentes a la
Institución, con el objeto de definir el perfil de riesgo, el grado de exposición que la institución está dispuesta a asumir y los mecanismos de 10
cobertura, para proteger los recursos propios y de terceros que se encuentran bajo su control y gestión.
2. Base de datos: Conjunto de datos relacionados que se almacenan de forma tal que se puede acceder fácilmente, con la posibilidad de relacionarlos,
ordenarlos, según criterios del administrador de la base de datos, o el usuario final. Una de sus características es que existe una mínima duplicidad
de información.
3. Evento externo: Refiérase a los acontecimientos que no involucran las operaciones normales de la Institución, los cuales pueden afectar su posición
financiera u operativa. Ejemplo: terremoto, incendios, factores climáticos, sociales, políticos.
4. Riesgo: Es un evento o una condición con incertidumbre que, si ocurre, tiene un efecto negativo y amenaza el logro de un resultado.
5. Insumo: Es el conjunto de materiales, datos o información que sirven como entrada a un proceso.
6. Datos: Es cualquier forma de registro electrónico, óptico, magnético, impreso o en otros medios, susceptible de ser capturado, almacenado,
procesado y distribuido.
7. Información: Es cualquier forma de registro electrónico, óptico, magnético o en otros medios, previamente procesado a partir de datos, que puede
ser almacenado, distribuido y sirve para análisis, estudios y toma de decisiones.
 8. Administración de la información: Es el proceso mediante el cual se captura, procesa, almacena y transmite información, independientemente del
medio que se utilice; ya sea impreso, escrito en papel, almacenado electrónicamente, transmitido por correo o por medios electrónicos o
presentado en imágenes.
9. Integridad: Es la garantía de mantener la totalidad y exactitud de la información y de los métodos de procesamiento.
10. Disponibilidad: Es la garantía de que los usuarios autorizados tienen acceso a la información cada vez que lo requieran a través de los medios
adecuados que satisfagan sus necesidades.
11. Cumplimiento: Se refiere a la observancia de las leyes, regulaciones y acuerdos contractuales a los que los procesos del Ministerio están sujetos;
12. Eficacia: Es la capacidad para contribuir al logro de los objetivos institucionales de conformidad con los parámetros establecidos.
13. Eficiencia: Es la capacidad para aprovechar racionalmente los recursos disponibles en pro del logro de los objetivos institucionales, procurando la
optimización de aquellos y evitando dispendios y errores;
14. Vulnerabilidades: características que tiene una persona o un grupo para predecir un peligro natural o causado por el hombre; hacerle frente;
resistir a sus efectos y recuperarse.
15. Identificación de los riesgos: Se identifica con precisión dónde, cuándo, porqué, y cómo podrían los eventos que afecten a la organización prevenir,
degradar, retardar o potenciar el logro de los objetivos organizacionales.
16. Análisis de los riesgos: Se identifican y evalúan los controles existentes que mitigan los riesgos identificados. Así mismo se determina la severidad
de los riesgos, definidos a partir de la consecuencia y probabilidad de ocurrencia de cada riesgo.
17. Tratamiento del riesgo: Se desarrollan e implementan estrategias específicas y eficaces en relación a costos y planes de acción para incrementar los
beneficios potenciales y reducir las pérdidas potenciales. Aquí se incluye la Política de Gestión del Riesgo.
18. Comunicación y consulta: Se identifican las partes involucradas, internas y externas, y se procede a comunicar y consultarles, a lo largo de cada
etapa del proceso.
19. Monitoreo y Revisión: Se monitorean los riesgos y las medidas tomadas para mitigar el riesgo.

Identificación de riesgos
La identificación de los riesgos es parte del proceso de planeación y debe ser permanente y participativa, verificando los aspectos
que pueden afectar al cumplimiento de los objetivos institucionales en sus distintos niveles:
• Objetivos estratégicos
• Objetivos específicos
• Objetivos operativos
• Procesos
• Proyectos
Clasificación del Riesgo
A continuación se señalan a manera de ejemplo las opciones más utilizadas:
1. Internacional. Económico: cuando se identifican factores de la economía internacional que puedan afectar al cumplimiento de los objetivos.
Ejemplo: caída del precio del petróleo, alza de tasas de interés, desaceleración en la economía mundial, suspensión de apoyo financiero
internacional no reembolsable.
2. Nacional (o Regional). General: se podrán considerar las situaciones en el ámbito nacional o regional, que no estén en otras clasificaciones.
Ejemplo: de demora o falta de aprobación de otras entidades en el ámbito de sus competencias, dependencia de otras Instituciones del Estado.
3. Nacional (o Regional). Ambiental: cuando un factor ambiental (sismos, erupción volcánica, caída de ceniza) se constituye en un riesgo para el
cumplimiento de objetivos institucionales.
4. Nacional (o Regional). Económico: cuando se identifican factores de la economía nacional o regional que puedan afectar al cumplimiento de los
objetivos. Ejemplo: condiciones financieras desfavorables para el financiamiento público, ajustes al Presupuesto General del Estado.
5. Nacional (o Regional). Jurídico: dentro de esta categoría se puede considerar los cambios en la normativa legal vigente.
6. Nacional (o Regional). Político: por ejemplo el cambio de autoridades nacionales.
7. Organizacional. General: por ejemplo, fraude Interno y retraso en los procesos administrativos.
8. Organizacional. Ambiental: por ejemplo, inundaciones, riesgo de incendio, ventilación, iluminación y calor.
9. Organizacional. Económico/ Fiscal: por ejemplo déficit presupuestario y cambios en la programación de desembolsos de créditos.
10. Organizacional. Jurídico: por ejemplo, fallas en contratos y transacciones que pueden afectar el funcionamiento o la condición de una institución,
derivadas de error, dolo, negligencia o imprudencia en la concertación, instrumentación, formalización o ejecución de contratos y transacciones
contratos con proveedores, contratos con el personal de la Institución, cambios y/o modificaciones a la normativa legal vigente.
11. Organizacional. Patrimonial, ejemplo: riesgos a la estructura física de la edificación, seguridad de las instalaciones, existencia de elementos
vulnerables como: superficies de trabajo, pasillos y corredores de tránsito, equipos eléctricos y sistemas de emergencia.
12. Organizacional. Político, ejemplo: agresiones y toma a las instalaciones, toma de rehenes, colocación de bombas, robos y asaltos, cambio de
autoridades institucionales.
13. Organizacional. Seguridad, se incluirán: riesgos tecnológicos como: falta de disponibilidad de los Sistemas del MINFIN, acceso a la Red de Internet,
falta de mantenimiento y/o actualización de los sistemas y bases de registros, respaldo de la información, violación externa de las bases de datos,
daños físicos a los servidores, obsolescencia de los equipos informáticos, licencias de software caducadas; seguridad de la información; agresiones y
toma a las instalaciones, toma de rehenes, colocación de bombas, robos y asaltos
14. Organizacional. Social/ Laboral, se incluirán los riesgos de Seguridad y Salud Ocupacional como: factores ergonómicos y psicosociales, clima laboral
desfavorable, negligencia, poco personal capacitado, falta de personal.
 15. Proyecto. General, se pueden señalar los riesgos que causan reprogramación de hitos, cancelación o retraso en la ejecución del proyecto. Ejemplo:
cambio de autoridades.
16. Proyecto. Alcance: se considerarán los riesgos que puedan afectar a los límites iniciales definidos en los proyectos, el cumplimiento al trabajo
previsto- productos o subproductos. Ejemplo: cambio en especificaciones técnicas, geográficas, etc.
17. Proyecto. Calidad: si se identifica un factor que afecte la calidad de los productos o subproductos del proyecto.
18. Proyecto. Costo: se identificarán riesgos como: la falta de presupuesto para ejecución del proyecto, cambios en el presupuesto inicial planificado,
que afecten a la ejecución y normal desarrollo del proyecto.
19. Proyecto. Recursos: por ejemplo: falta de equipos o sistemas, poco personal para ejecutar el proyecto, alta rotación del personal.
20. Proyecto. Tiempo: se identificarán los factores que afecten la duración del proyecto. Ejemplo: demora en la revisión y aprobación de los
documentos del proyecto.
21. Proyecto. Técnico: riesgos que perjudiquen el desempeño de los sistemas o equipos.

Sistema de GPR
Ítem Detalle
Clasificación Se seleccionará la clasificación del riesgo de acuerdo a Estructura
(RBS) Desglosada de Riesgos (Risk Breakdown Structure)
Riesgo Se ingresará el nombre para identificar el Riesgo, conforme la
sintaxis: Evento + “CAUSARÍA” + Impacto
Descripción Se detallará el Riesgo y se hará constar de forma específica el tipo
de riesgo, si no consta dentro de las categorías predefinidas en
GPR, así como se identificará el nombre del proceso que se ve
afectado con el riesgo.
Fecha de Seleccionar la fecha en la cual el riesgo se identifica e ingresa en el
Identificación sistema GPR
Objetivo Se deberá seleccionar el objetivo de la unidad que se verá
impactado por la ocurrencia de dicho riesgo.
Responsable Se deberá seleccionar la persona responsable de darle seguimiento
a este riesgo, que puede ser el titular de la unidad o la persona que
sea designada.
 Probabilidad Seleccionar la probabilidad de que este riesgo ocurra en una escala
del 10% al 100%.
Impacto Seleccionar el impacto del Riesgo en escala del 10 al 100
Calificación El sistema calcula automáticamente, multiplicando la Probabilidad
por el Impacto.
Costo Potencial Se ingresará un monto, en el caso que la ocurrencia del riesgo
del Impacto genere un costo.
Fecha Estimada Identificar la fecha en la cual el riesgo puede ocurrir con la
de Ocurrencia probabilidad definida.
Estado Identifica si el riesgo está Abierto o ya ha sido Cerrado
Fecha Cierre La fecha en la cual el riesgo fue cerrado.
Acción Detalle la acción que se llevará a cabo para gestionar el riesgo.
Tipo Seleccione el tipo de acción: evitar, prevenir, transferir, de
contingencia.
Comprometida Se ingresa la fecha en la cual el responsable del riesgo se
compromete en finalizar la acción.
Completada Se ingresa la fecha en la cual el responsable del riesgo finalizó la
acción.

Definiciones de Probabilidad e Impacto de Riesgos

Definiciones de Probabilidad
Muy Alta La mayor parte de la operación se interrumpe, impacto significativo, Daño
no reversible a la reputación o las relaciones con los interesados. (0,80)

Alta Pérdida temporal de la funcionalidad o capacidad, daños y pérdidas

importantes, daños en la reputación sin implicaciones a largo plazo.
(0,40)
 Media Interrupción moderada a las actividades del día a día, requiere
procedimientos de enmienda. Si son media, ya no es tan alta ni baja si no
entre el medio (0,20)

Baja Poca interrupción a las actividades del día a día, procedimientos de

solución de fácil implementación, situación, manejada inmediatamente.
(0,10)

Muy Baja No afecta las actividades del día a día, No causa daño (0,05)

Definiciones de Impacto
Objetivo Muy bajo Bajo Medio Alto Muy Alto
de (0,05) (0,20) (0,80)
(0,10) (0,40)
Proyecto

Alcance Disminución Áreas de Áreas de Reducción El elemento

del alcance alcance alcance del alcance terminado del
apenas secundarias principales inaceptable proyecto es
perceptible afectadas afectadas para el efectivamente
patrocinador inservible

Tiempo Aumento de Aumento Aumento Aumento Aumento del

tiempo del tiempo del tiempo del tiempo tiempo >20%
insignificante <5% del 5-10% del 10-20%

Costo Aumento de Aumento Aumento Aumento Aumento del

coste del coste del coste del coste coste >40%
insignificante <10% del 10-20% del 20-40%

Calidad Sólo las La Reducción El elemento

aplicaciones reducción de la terminado del
 Degradación muy de la calidad proyecto es
de la calidad exigentes calidad inaceptable efectivamente
apenas requiere la para el inservible
perceptible aprobación patrocinador
del
patrocinador

Matriz de Probabilidad e Impacto

Probabilidad Amenazas Oportunidades

0,90 0,05 0,09 0,18 0,36 0,72 0,72 0,36 0,18 0,09 0,05

0,70 0,04 0,07 0,14 0,28 0,56 0,56 0,28 0,14 0,07 0,04

0,50 0,03 0,05 0,10 0,20 0,40 0,40 0,20 0,10 0,05 0,03

0,30 0,02 0,03 0,06 0,12 0,24 0,24 0,12 0,06 0,03 0,02

0,10 0,01 0,01 0,02 0,04 0,08 0,08 0,04 0,02 0,01 0,01

0,05 0,10 0,20 0,40 0,80 0,80 0,40 0,20 0,10 0,05

Revisión de la tolerancia de los interesados (Stakeholders)

En royecla combinación de probabilidad e impacto superior a 0,14 determina el umbral a partir del cual el riesgo no puede tener
como plan de respuesta la aceptación con plan de contingencias, sino que es obligado establecer acciones preventivas para evitar
o reducir
Formatos de Registro de Riesgos

Definición de Acciones
Acciones Descripción
Evitar Evita la amenaza del riesgo eliminando su causa, o seleccionando
acciones alternativas.
Prevenir Atenúa la probabilidad de ocurrencia
Transferir Transfiere el riesgo a un tercero
Contingencia Reduce el impacto. Éstas son acciones de un plan de “reserva”

Aprobaciones
Aprobador Fecha Firma

Kelly Sánchez 30/01/2022 Aprobado

Ernesto Quingue 30/01/2022 Aprobado

Carolina Mena 30/01/2022 Aprobado

Andres Gualoto 30/01/2022 Aprobado

Solicitud de cambio
Sistema Académico para la Universidad SAU
 Fecha: 03-02-2022

Datos de la solicitud de cambio

Nro control de solicitud de cambio 001
Solicitante del cambio Carolina Mena

Área del solicitante Desarrollador

Lugar Riobamba

Patrocinador del proyecto SAU

Gerente del proyecto Kelly Sanchez

Categoría de cambio
Marcar todas las que apliquen:

Causa / origen del cambio

Descripción de la propuesta de cambio

Cambio en los costos de producción.

Justificación de la propuesta de cambio

Los valores iniciales fueron valores calculados con errores.

Falta de equipos para la realización del proyecto.

Impacto del cambio en la línea base

Alcance:
Cronograma:

Costo:

Calidad:
Implicaciones de recursos (materiales y capital humano)

Los recursos asignados no son los necesarios para realizar el proyecto.

Implicaciones para los interesados

Retraso en el tiempo y más inversión.

Implicaciones en la documentación del proyecto

 Tiempo.
Recursos.
Costos.

Riesgos

Cancelación del proyecto

Comentarios

Aprobación

El cambio fue aprobado

Firmas del comité de cambios
Nombre Rol / Cargo Firma

Kelly Sanchez Gerente

Ernesto Quingue Tecnico

Carolina Mena Técnico

Andres Gualoto Desarrollar