Informe de Proyecto Colmena T4 PDF

República Bolivariana de Venezuela
Ministerio del poder popular para la educación universitaria,

ciencia tecnología e innovación
Barquisimeto – Estado Lara
PNF Informática
SISTEMA AUTOMATIZADO PARA LA GESTIÓN DEL TALENTO

HUMANO DE LA UNIVERSIDAD POLITÉCNICA TERRITORIAL
ANDRÉS ELOY BLANCO
Integrantes:
TSU. Quintín Soto C.I. V.-23.850.459
Tutor Asesor: Ing. José Cadenas
Tutor Externo: Lic. Carlos Soto
ÍNDICE GENERAL
ÍNDICE GENERAL 2
RESUMEN 4
INTRODUCCIÓN 5
CAPÍTULO I DESCRIPCIÓN DEL PROYECTO 6

1.1 Caracterización de la comunidad 6
1.1.1 Naturaleza de la Organización 8
1.1.2 Justificación e impacto social 8
1.2 Objetivos del proyecto 8
1.2.1 Objetivo General 8
1.2.2 Objetivos Específicos 8
CAPÍTULO II GESTIÓN DE PROYECTO INFORMÁTICO 10

2.1 Análisis de riesgo 10
2.1.1 Propósito 10
2.1.2 Alcance 10
2.1.3 Identificación de los Riegos 11
2.1.4 Análisis detallado de riesgos de proyecto 13
2.2 Pert/CPM 27
2.2.1 PERT (Project Evaluation and Review Techniques) 27
2.2.2 Diagrama CPM (Critical Path Method) 30
2.2.3 Análisis del diagrama de ruta crítica 30
2.3 Plan de aseguramiento de la calidad 31
2.3.1 Propósito 31
2.3.2 Gestión 32
2.3.3 Documentación 33
2.3.4 Estándares y métricas 36
2.3.5 Revisiones 38
2.3.6 Testeo 41
CAPÍTULO III GESTIÓN DE BASE DE DATOS Y SEGURIDAD INFORMÁTICA 43

3.1 Diagrama de base de datos 43
3.1.1 Diccionario de datos 44
3.2 Monitoreo de transacciones 52
3.2.1 Uso y aumento diario de las tablas 52
3.3 Revisión preventiva de las tablas relacionadas con la seguridad 53
2
3.4 Diagnóstico de posibles cuellos de botella en un plazo de tiempo determinado 53
3.5 Diagnóstico sobre la seguridad física, lógica, redes y estaciones de trabajo, base
de datos del proyecto 53
3.5.1 Seguridad Física 53
3.5.2 Seguridad Lógica 54
3.5.3 Seguridad en la Base de Datos 55
3.7 Métodos de cifrado programados en el sistema 56
3.8 Matriz de riesgos en relación a la seguridad informática 56
CAPÍTULO IV AUDITORÍA INFORMÁTICA 58

4.1 Tipos de auditorías 58
4.2 Herramientas y técnicas 58
4.3 Metodología seleccionada 58
4.4 Resultados 59
CAPÍTULO V MANTENIMIENTO DEL PROYECTO 63

5.1 Propósito del mantenimiento 63
5.2 Tipo de mantenimiento 63
5.3 Plan de mantenimiento y capacitación 64
5.4 Informe de resultados de mantenimiento y capacitación 65
CAPÍTULO VI INTEGRACIÓN DEL PROYECTO 74

6.1 Diagnóstico del proyecto para integración con sistemas existentes 74
CAPÍTULO VII CONCLUSIONES Y RECOMENDACIONES 76
3
SISTEMA AUTOMATIZADO PARA LA GESTIÓN DEL TALENTO HUMANO DE
LA UNIVERSIDAD POLITÉCNICA TERRITORIAL ANDRÉS ELOY BLANCO
Integrantes:
Quintín Soto C.I. V.-23.850.459
Tutor Asesor: Ing. José Cadenas
Tutor Externo: Lic. Carlos Soto
RESUMEN
4
INTRODUCCIÓN
5
CAPÍTULO I DESCRIPCIÓN DEL PROYECTO
1.1 Caracterización de la comunidad
La Universidad Politécnica Territorial Andrés Eloy Blanco (UPTAEB) nació

como Ciclo Básico Superior (CBS) en 1972 como la antesala de los estudiantes de
educación superior que debían cursar dos semestres en esta casa de estudios
antes ingresar a las instituciones universitarias que para la época funcionaban en
Barquisimeto: la Universidad Centroccidental Lisandro Alvarado (UCLA), el
Instituto Pedagogico (UPEL–IPB) y la Universidad Nacional Experimental
Politécnica Antonio José de Sucre (Unexpo).
El CBS comenzó actividades el 7/3/1973 con una matrícula de 3.500
estudiantes. Un año después, el Ministerio de Educación estableció oportunidades
de estudio a los bachilleres que deseaban proseguir carrera en las hoy UCLA,
UPEL y Unexpo.
En 1979, con matrícula de 7.000 estudiantes, el Ministerio de Educación
recomienda elaborar un proyecto de “Instituto de ensayo para los Estudios
Básicos”. Tres años después (1982) el CNU aprueba la transformación del CBS en
Instituto Universitario Experimental Barquisimeto (IUEB).
El nuevo instituto planteó la necesidad de formar técnicos superiores en la
región centroccidental, y el 31/07/1986, el M.E autoriza al IUEB para ofrecer la
especialidad de Administración, menciones Costos y Mercadotecnia. En enero de
1987 ingresan 200 alumnos (100 por cada mención), sumados a los estudiantes
de la UCLA que aún permanecían en el IUEB mientras cursaban el Ciclo Básico.
El 8/12/1988 se oficializa el nombre de Andrés Eloy Blanco como epónimo
de la institución. Al año siguiente se transforma en Instituto Universitario
Experimental y seguidamente en Instituto Universitario Experimental de
Tecnología Andrés Eloy Blanco (Iuetaeb).
6
En septiembre de 1989 se inició la carrera de Turismo. En julio 1990 egresa
la 1ra. promoción de 65 técnicos superiores (38 en Costos y 27 en
Mercadotecnia). Ese mismo año comienza a impartirse la especialidad de
Deportes, menciones Atletismo, Natación, Lucha y Levantamiento de Pesas.
En septiembre de 1992 fue creada la carrera de Higiene y Seguridad
Industrial; en 1993 la de Control de Calidad; en 1997 las de Contaduría y
Mercadotecnia –que sustituyeron la de Administración– y en marzo de 1998
comenzó la de Información y Documentación.
En febrero de 2001, el ME declara en proceso de modernización y
transformación al Iuetaeb y el 21/11/2006 el presidente Hugo Chávez anunció la
creación de la Misión Alma Mater para fundar nuevas universidades y transformar
los 29 tecnológicos y colegios universitarios del país en universidades politécnicas.
Cuatro años después, mediante decreto 7.569 publicado en Gaceta Oficial
5.987, el recordado comandante Chávez anuncia la transformación del Iuetaeb y
de otros cinco tecnológicos en universidades politécnicas territoriales. Así nace la
Universidad Politécnica Territorial de Lara Andrés Eloy Blanco (Uptaeb), el
16/07/2010.
Según el decreto, la Uptaeb “tiene como objetivos estratégicos contribuir
con la soberanía tecnológica de la nación a través del estudio, la investigación y el
trabajo creador en múltiples campos de estudio, enfocados en el abordaje de los
problemas en su contexto territorial, de acuerdo con las necesidades del pueblo”.
La institución imparte los siguientes Programas Nacionales de Formación

(PNF): TSU y licenciaturas en: Deportes, Entrenamiento Deportivo,
Administración, Ciencias de la Información, Contaduría Pública y Turismo, así
como TSU e ingenierías en: Sistemas de Calidad y Ambiente, Higiene y Seguridad
Laboral, Agroalimentación e Informática.
7
1.1.1 Naturaleza de la Organización
Como institución de educación pública el encargo social del UPTAEB se

fundamenta en la construcción de conocimientos partiendo de los proyectos
sociotecnológicos, la formación crítica en el ámbito histórico, social, político,
económico y cultural y en el trabajo en contextos reales con principios bioéticos
que permitan disfrutar de la vida en un ambiente seguro, sano y ecológicamente
equilibrado. Es por esto, sumado a la concepción de Universidad Politécnica,
fomenta la formación de ciudadanos y ciudadanas.
1.1.2 Justificación e impacto social
El desarrollo de la presente investigación pretende generar un impacto positivo

sobre la administración del Talento Humano de la UPTAEB, permitiendo una gestión
automatizada de los procesos de gestión del mismo. Acarreando consigo una mejora en
el control y la gestión de los procesos que involucran el talento humano, evitando la
sobrecarga de tareas al personal y sirviendo como herramienta de recordatorios para
cumplir con sus asignaciones mediante el uso del sistema.
1.2 Objetivos del proyecto
1.2.1 Objetivo General
Implantar un Sistema de Gestión del Talento Humano para la Universidad

Politécnica Territorial Andrés Eloy Blanco
1.2.2 Objetivos Específicos
● Diagnosticar los riesgos de Proyecto del Sistema Automatizado para la

Gestión del Talento Humano.
● Determinar la seguridad informática del Sistema Automatizado para la
8
● Aplicar una auditoría informática al Sistema Automatizado para la Gestión
del Talento Humano.
● Generar un plan de mantenimiento para el Sistema Automatizado para la
9
CAPÍTULO II GESTIÓN DE PROYECTO
INFORMÁTICO
2.1 Análisis de riesgo
Uno de los elementos clave a la hora de asegurar el éxito en el proyecto,

medido en términos de cumplimiento de plazos, costes, alcance funcional y
calidad final de la solución, es la Gestión de Riesgos. Implantar una Gestión de
Riesgos adecuada será un elemento decisivo a la hora de asegurar el Proyecto,
mediante la identificación y el análisis por adelantado de los riesgos potenciales
que puedan afectar al Proyecto, y la elaboración de las acciones de contingencia
adecuadas para evitar su aparición o para minimizar el impacto en el Proyecto, en
caso de que finalmente el riesgo se verifique.
2.1.1 Propósito
Este apartado presenta el análisis de los riesgos identificados en la fase

inicial del proyecto. Para cada riesgo observado se valorarán sus efectos y
contexto de aparición para el caso en que se convierta en un hecho. Además, se
definirán estrategias para reducir la probabilidad del riesgo o para controlar sus
posibles efectos.
2.1.2 Alcance
El ámbito del análisis de riesgos cubre toda la extensión del proyecto

observado desde su fase inicial. Será necesario durante el desarrollo del proyecto
revisar y actualizar los contenidos del análisis de riesgos en caso de que se
detecten nuevos riegos no visibles en este momento.
10
2.1.3 Identificación de los Riegos
Cod Riesgo Categoría Impacto
R00 Disolución del equipo de proyectistas Proyecto Alto

1
R00 Cambios en la visión gerencial de la comunidad Proyecto Medio

2
R00 Averías en el servidor Sistema Medio

3
R00 Fallas eléctricas Sistema Medio

4
R00 Problemas financieros del equipo de proyectistas Proyecto Alto

5
R00 Fallas de comunicación entre proyectistas y la Proyecto Medio

6 comunidad
R00 Cambios en las políticas de desarrollo de la Proyecto Alto

7 comunidad
R00 Conflictos de versiones en tecnologías utilizadas Sistema Alto

8 en la comunidad
R00 Daños ocasionados por catástrofes naturales o Sistema Bajo

9 incendios accidentales
R01 Manejo inadecuado de permisologías del sistema Sistema Alto

0
R01 Falla en planificación de las actividades del Proyecto Medio

1 proyecto
11
R01 Cambios de políticas gubernamentales Sistema Medio
2
12
2.1.4 Análisis detallado de riesgos de proyecto
Análisis del Riesgo

Código: R001 Disolución del equipo de proyectistas
Descripción Deserción por parte de los miembros del equipo de proyecto
Fecha de identificación: Tipo de Riesgo: Proyecto

Octubre/2015
Causas: Problemas personales de los Consecuencias: Sobrecarga de trabajo a
integrantes del equipo de proyectistas los integrantes restantes del equipo
proyectistas, originando retrasos sobre
fechas de las metas planificadas
Probabilidad 3
Magnitud 4
Valoración Cuantitativa 12
Valoración Cualitativa Periodo en el cual puede ocurrir: En

Baja: Media: Alta: X cualquier etapa del desarrollo del
proyecto
Estrategias para la administración del riesgo:
● Redimensionar el alcance del proyecto en materia de requisitos de sistema (SRS)

● Reprogramar actividades de proyecto
Responsables de administrar el riesgo y tiempo estimado de ejecución:

Comunidad y Equipo Proyectista
13
Código: R002 Cambios en la visión gerencial de la comunidad
Dado que hubo un cambio de encargado de la comunidad,

surgieron nuevos requerimientos y otros fueron cambiados. Un
Descripción cambio de visión gerencial durante la ejecución del proyecto

puede traer consigo nuevas estrategias de abordaje sobre los
problemas que busca solucionar el sistema y por tanto cambios
en los requerimientos de sistema.
Fecha de identificación Tipo de Riesgo: Proyecto
Noviembre/2016
Causas: Cambio del representante de Consecuencias: Retrasos en el
la comunidad (Coordinador del cumplimiento de la planificación de
departamento del PNF-I) proyecto, carga de trabajo no prevista
para el equipo proyectista
Probabilidad 2
Magnitud 3
Valoración Cualitativa Periodo en el cual puede ocurrir:

Baja: X Media: Alta: Etapa de codificación de sistema
● Lograr el cumplimiendo de lo establecido en el contrato original de requisitos (SRS)

● Evaluación en la viabilidad de los cambios
● Generación de propuestas para ajustar los tiempos a la culminación de las
actividades relacionadas con las modificaciones exigidas
● Plantear reuniones para integrarse con la nueva gerencia

Comunidad, Equipo Proyectista
14
15
Código: R003 Averías en el servidor
Descripción: Daños que afecten la integridad física y lógica del servidor
Fecha de identificación: Tipo de Riesgo: Sistema

Febrero/2017
Causas: Desgaste de equipo Consecuencias: Posible pérdida de data
y funcionamiento erróneo del sistema
Probabilidad 2
Magnitud 3

Baja: X Media: Alta: cualquier etapa del desarrollo del
proyecto
● Sugerir la instauración de políticas de mantenimiento preventivo en el servidor

(Limpieza de componentes tales como: tarjetas RAM, tarjeta madre, fan coolers,
revisión física de disco duro, entre otros)
● Sugerir la instauración de políticas preventivas, tales como: recuperación y
respaldo de la data

Comunidad
16
Código: R004 Fallas Eléctricas
Cortes no programados en el suministro eléctrico, sobrecarga
Descripción: eléctrica o carga insuficiente
Fecha de identificación: Tipo de Riesgo: Sistema

Marzo/2016
Causas: Causas imprevistas Consecuencias: Fallas lógicas en el
sistema, perdida de data
Probabilidad 2
Magnitud 3

Baja: X Media: Alta: Etapa de implantación y seguimiento
● Sugerir la utilización de UPS para el servidor de una carga que soporte un

aproximado de 3 a 4 horas para que se realicen las rutinas de respaldo
correspondientes

Comunidad
17
Código: R005 Problemas financieros del equipo proyectistas
Equipo Proyectista conformado por estudiantes del PNFI, los
Descripción: cuales no perciben ingresos por la realización del presente

proyecto
Fecha de identificación: Enero/2016 Tipo de Riesgo: Proyecto
Causas: Crisis económica nacional Consecuencias: Posible deserción de

proyectistas lo cual originó retrasos en el
cumplimiento de las actividades de
proyecto
Probabilidad 2
Magnitud 4

Baja: Media: X Alta: cualquier etapa del desarrollo del
proyecto
● Sugerir políticas de incentivo para proyectistas destacados (becas, incentivos

metálicos, entre otros)
La comunidad
18
Código: R006 Fallas de comunicación entre proyectistas y la comunidad
Descripción: Debido a la dinámica de trabajo que lleva la comunidad, se

hace dificultoso generar espacios para realizar reuniones de
trabajo del proyecto entre los involucrados (proyectistas,
tutores, comunidad)
Fecha de identificación: Marzo/2015 Tipo de Riesgo: Proyecto
Causas: Dinámicas laborales Consecuencias: Análisis de requisitos no

claros, lo cual genera retrasos en el
proyecto
Probabilidad 3
Magnitud 2

Baja: X Media: Alta: Análisis de requisitos
Crear canales de comunicación no presenciales utilizando las TIC, como lo son
documentos compartidos en la nube, correos electrónicos, reuniones vía llamadas VoIP
(skype, hangouts, facebook calls, entre otros)
Proyectistas, Comunidad, Tutor académico
19
Código: R007 Cambios en las políticas de desarrollo de la comunidad
Descripción: Debido cambios en los estándares programáticos de la

comunidad, las tecnologías utilizadas para el desarrollo del
proyecto quedan fuera de los nuevos estándares
Fecha de identificación: Tipo de Riesgo: Proyecto
Diciembre/2016
Causas: Cambios en la concepción de Consecuencias: La escalabilidad del
macro proyecto de la comunidad proyecto se ve comprometida, por no
estará acorde a los nuevos estándares
programáticos
Probabilidad 3
Magnitud 3

proyecto
● Solicitar a la comunidad mantener las políticas de desarrollo durante la ejecución

del proyecto
● Sugerir estrategias de interoperabilidad para aumentar la compatibilidad entre
sistemas

Proyectistas, Comunidad
20
Código: R008 Conflictos de versiones en tecnologías utilizadas en la
comunidad
Descripción: Versiones de las tecnologías utilizadas para el desarrollo del
sistema no compatibles con las instaladas en el servidor de la
universidad (lenguajes de programación, motores de base de
datos, entre otros)
Fecha de identificación: Marzo/2016 Tipo de Riesgo: Sistema
Causas: Problemas en la Consecuencias: Funcionamiento

administración del servidor, inadecuado del sistema
desactualización del servidor, políticas
de versiones inexistentes
Probabilidad 3
Magnitud 4

Baja: Media: Alta: X Etapa de instalación y pruebas del
sistema
● Sugerir la creación de políticas de versiones de la comunidad

● Hacer velar el cumplimiento de versiones a través de documento SRS

Proyectistas, Comunidad
21
Código: R009 Daños ocasionados por catástrofes naturales o incendios
accidentales
Descripción Daños sobre las estaciones de trabajo o servidor que puedan
ocurrir durante una catástrofe natural
Fecha de identificación: Junio/2017 Tipo de Riesgo: Proyecto
Causas: Causas imprevistas Consecuencias: Daños sobre equipos,

pérdidas de data, entre otros
Probabilidad 1
Magnitud 4

Baja: X Media: Alta: cualquier etapa del desarrollo del
proyecto
● Definir planes de contingencia informática ante catástrofes naturales o incendios

accidentales

Comunidad
22
Código: R010 Manejo inadecuado de permisologías del sistema por parte de
súper usuarios
Descripción: Debido a la naturaleza organizativa del sistema, un manejo
inadecuado de permisología puede causar que la información
manejada en el sistema se vea comprometida
Fecha de identificación: Mayo/2017 Tipo de Riesgo: Sistema
Causas: Consecuencias: Comprometimiento de

la data del sistema
Probabilidad 2
Magnitud 4
Valoración Cualitativa Periodo en el cual puede ocurrir: Etapa

Baja: Media: X Alta: de instalación y pruebas del sistema
● Añadir verificación de seguridad extra para acciones sensibles dentro del sistema
● Resaltar la importancia del manejo adecuado de las permisologías de sistema
Comunidad
23
Código: R011 Falla en planificación de las actividades del proyecto
Descripción: retardos en los tiempos de entrega sobre las actividades del

proyecto
Causas: Situaciones imprevistas Consecuencias: Retraso en el desarrollo

del proyecto
Probabilidad 3
Magnitud 3

proyecto
● Planificar las actividades con tiempos de holgura prudenciales
● Equipo de Proyectistas
● Comunidad
24
Código: R012 Cambios de políticas gubernamentales
Descripción: Los cambios en las políticas gubernamentales pueden causar

obsolescencia sobre el sistema debido a que parte del mismo
fue programado rigiéndose por las normativas actuales
Causas: Cambios en la administración Consecuencias: Funcionamiento de

gubernamental sistema fuera de la normativa institucional
Probabilidad 2
Magnitud 2

Baja: Media: X Alta: Cualquiera
● Permitir la parametrización de secciones sensibles a cambios de normativa
Equipo Proyectista
25
Análisis cuantitativo del riesgo
4 4 8 12 16
Alto (8 - 16)
3 3 6 9 12
Medio (3 - 6)
2 2 4 6 8 Bajo (1 - 2)
1 1 2 3 4
Valores:
1 2 3 4 1. Bajo
2. Medio
3. Alto
26
2.2 Pert/CPM
2.2.1 PERT (Project Evaluation and Review Techniques)
Etiqueta Actividad Precedencia a m b Te σ2
Levantamiento de
a 2 3 4 3 0.11
información
Definición de alcances de
b a 3 4 6 4 0.25
sistema
c Análisis de requisitos (SRS) b 2 3 5 3 0.25
Diseño de base de datos

d c 2 3 4 3 0.11
(MER)
Diseño de diagrama de
e d 1 2 3 2 0.11
clases
f Programación de sistema c, d, e 6 7 10 7 0.44
g Pruebas de sistema f 3 4 6 4 0.25
Instalación de sistema en
h f 1 2 3 2 0.11
entorno de producción
Corrección de errores,
i g 3 4 6 4 0.25
defectos y fallas
j Despliegue de proyecto i 1 2 4 2 0.25
27
Evaluación de nuevos
k requisitos para crecimiento j 2 3 4 3 0.11
de sistema
Análisis de requisitos
l k 2 3 5 3 0.25
nuevos (SRS v2)
Rediseño de base de datos

m l 2 3 4 3 0.11
(MER v2)
Programación de nuevos
n k, l 6 7 10 7 0.11
requisitos de sistema
ñ Pruebas de sistema n 3 4 6 4 0.25
Instalación de nueva
o versión de sistema en n 1 2 3 2 0.11
Migración de datos de base

p o 1 2 3 2 0.11
de datos a nuevo esquema
Corrección de errores,
q ñ 3 4 6 4 0.25
defectos y fallas
Despliegue de nueva
r q 1 2 4 2 0.25
versión de proyecto
Evaluación de nuevos
s requisitos para seguridad y r 2 3 4 3 0.25
mantenimiento de sistema
t Definición de alcances de s 2 3 5 3 0.11
28
nuevos requisitos
Diagnóstico de manejo de
u concurrencia en base de t 2 3 4 3 0.25
datos
Rediseño de base de datos

para requisitos de
v u 2 3 4 3 0.11
seguridad y mantenimiento
(MER v3)
Optimización para manejo

w de transacciones de base v 3 4 6 4 0.25
de datos
Diagnóstico de seguridad
x t 2 3 4 3 0.11
de sistema
Programación de
algoritmos para
y x 3 4 6 4 0.25
optimización de seguridad
de sistema
z Pruebas de sistema w, y 3 4 6 4 0.25
Instalación de nueva
a1 versión de sistema en w, y 1 2 3 2 0.11
Migración de datos de base

b1 a1 1 2 3 2 0.11
de datos a nuevo esquema
c1 Corrección de errores, z 3 4 6 4 0.25
29
defectos y fallas
Despliegue de nueva
d1 c1 1 2 4 2 0.25
versión de proyecto
a = Tiempo optimista
m = Tiempo más probable
b = Tiempo pesimista
Fórmulas
2.2.2 Diagrama CPM (Critical Path Method)
2.2.3 Análisis del diagrama de ruta crítica
A través del diagrama de ruta crítica se aprecia el tiempo máximo de

duración que pudo tomar la realización del proyecto. Durante las realización de las
actividades el equipo de proyectistas se dividió las actividades para la realización
plena de cada una de ellas, al inicio de las actividades paralelas se definió un
encargado para cada actividad para de esta manera garantizar el cumplimiento de
30
dichas actividades, sin embargo a partir de la actividad “Evaluación de nuevos
requisitos para seguridad y mantenimiento de sistema” de etiqueta (s) el número
de integrantes del equipo de proyectistas se redujo a uno, esto convirtiendo a las
actividades de etiqueta v, y, a2 y b1 que se realizaron en paralelo en actividades
críticas pues el equipo proyectista debería encargarse de todas las actividades en
simultáneo para cumplirse dentro de los tiempos establecidos.
2.3 Plan de aseguramiento de la calidad
2.3.1 Propósito
El objetivo de este plan es definir la calidad del software deseado y describir
cómo valorar esta, estableciendo las pautas y actividades que deben desarrollarse
para garantizarse. Identificar para cada actividad los atributos de calidad
relevantes, los métodos de evaluación y sus responsables. Además, este plan
brinda elementos de apoyo a la gestión del proyecto para realizar verificaciones
sobre la adecuación al proceso y así detectar desvíos que puedan resultar en
acciones correctivas en etapas tempranas. Este plan abarca las partes del ciclo de
vida relacionadas con: Inicial, Construcción de Productos de Software,
Construcción de productos de Investigación y Presentación. Las etapas
relacionadas al mantenimiento no están contempladas debido a que no está en el
alcance del proyecto, sin embargo, se tomarán consideraciones acerca del futuro
del producto.
Acrónimos y abreviaturas
● SQA: Aseguramiento de la Calidad del Software
● SCM: Gestión de Configuración del Software
● GP: Gestión del Proyecto
Referencias
● IEEE Std 730-1998, IEEE Standard for Software Quality Assurance
Plans.
● IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance
Planning.
● IS-1(2001) – Proyecto de Ingeniería de Software
● IS-2 (2001) - Modelo de Calidad
31
2.3.2 Gestión
La gestión del proyecto está a cargo del Administrador del Proyecto, sin
embargo será monitoreada tanto por este, como por el Responsable de SQA. Se
intenta controlar que las actividades se ajusten al plan propuesto y minimizar
posibles desviaciones.
Organización:
Tareas
Actividad Entregable Asociado
Realizar el Plan de SQA Plan de SQA
Identificar propiedades de Calidad Propiedades de Calidad
Evaluar la calidad de los productos Informe de revisión de SQA
Revisar el ajuste al proceso Informe de revisión de SQA
Realizar Revisión Técnica Formal Informe de Revisión Técnica Formal
Evaluar y ajustar el Plan de SQA Documento de Evaluación y Ajustar

Plan de SQA
Revisar la entrega semanal Entrega semanal de SQA
Realizar evaluación final de SQA Evaluación final de SQA
Reuniones de Apoyo a la calidad No Aplica
Responsabilidades
Producto Responsable
Documento de Requerimientos Quintín Soto
Alcance del Sistema Quintín Soto
Descripción de la Arquitectura Quintín Soto
Modelo de Diseño Quintín Soto
Modelo de Datos Quintín Soto
32
Estándar de Implementación Quintín Soto
Estándar de documentación técnica Quintín Soto
Documento de Riesgos Quintín Soto
Plan del Proyecto Quintín Soto
Plan de Verificación y Validación Quintín Soto
Reporte de pruebas unitarias, de Quintín Soto

integración y del Sistema
Plan de Implantación Quintín Soto
Estándar de Documentación de Quintín Soto

Usuario
Documentación de Usuario Quintín Soto
Plan de Gestión de Configuración Quintín Soto
2.3.3 Documentación
Documentación mínima requerida
I. Especificación de Requerimientos
El documento de especificación de requerimientos deberá 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. La
especificación debe:
● Ser completa:
○ Externa, respecto al alcance acordado.
○ Internamente, no deben existir elementos sin especificar.
● Ser consistente, no pueden haber elementos contradictorios.
33
● Ser no ambigua, todo término referido al área de aplicación debe
estar definido en un glosario.
● Ser verificable, debe ser posible verificar siguiendo un método
definido, si el producto final cumple o no con cada requerimiento.
● Estar acompañada de un detalle de los procedimientos adecuados
para verificar si el producto cumple o no con los requerimientos.
● Incluir requerimientos de calidad del producto a construir.
II. Diseño del Sistema y Descripción de la Arquitectura

El documento de diseño específica como el software será construido
para satisfacer los requerimientos. Deberá describir los componentes y
subcomponentes del diseño del software, incluyendo interfaces internas.
Este documento deberá ser elaborado primero como Preliminar y luego
será gradualmente extendido hasta llegar a obtener el Detallado. El cliente
deberá obtener 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 debe:
● Corresponder a los requerimientos a incorporar:

○ Todo elemento del diseño debe contribuir a algún
requerimiento.
○ 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.
● La descripción de la arquitectura utilizada debe especificar el patrón
arquitectónico utilizado.
III. Plan de Verificación y Validación
El Plan de V & V deberá identificar y describir los métodos a ser utilizados

en
● La verificación de que:
○ 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.
34
○ Los requerimientos descritos en el documento de
requerimientos son implementados en el diseño expresado en
el documento de diseño.
○ El diseño expresado en el documento de diseño está
implementado en código.
● Validar que el código, cuando es ejecutado, se adecua a los
requerimientos expresados en el documento de requerimientos.
IV. Reportes de Verificación

Estos documentos deben especificar los resultados de la ejecución
de los procesos descritos en el Plan de V & V.
● Documentación de Usuario
La documentación de usuario, como el manual del sistema
debe describir de forma detallada las cualidades del sistema y su
uso, mencionando cada función que debe cumplir cada rol que se
desempeña dentro del sistema
● Plan de Configuración
El Plan de gestión de configuración debe contener métodos
para identificar componentes de software, control e implementación
de cambios, y registro y reporte del estado de los cambios
implementados.
● Plan de Proyecto
El plan de gestión de proyecto debe describir la planificación
de forma completa del proyecto, de manera que pueda desarrollarse
de forma controlada. Debe analizar su factibilidad, definir el alcance,
describir las actividades de gestión que deben ser llevadas a cabo
durante el proceso de desarrollo, definir mecanismos de control y
ajuste para las distintas áreas del proyecto, establecer las línea de
trabajo, distribución de recursos humanos juntos con sus
responsabilidades y cronograma de trabajo. Además debe analizar
los riesgos del proyecto con estrategias de mitigación, controles y
planes de contingencia.
35
2.3.4 Estándares y métricas
Identificar los estándares utilizados en el proyecto (documentación,
codificación, testeo, diseño, otros.). Para cada entregable que se revise se debe
indicar el estándar o plantilla que se utiliza para su creación. Por lo que se deben
detallar las métricas de calidad que se aplicarán al producto y proceso.
I. Estándar de documentación
Estándar de Documentos en General

Para la elaboración del documento se han definido plantillas para
todos los documentos a realizar. En ellos se definen:
● Fuente: Arial - Tamaño: 12 - Color: Negro - Estilos: Normal, Título 1,
Título 2,Título 3, Título 4, hasta el nivel que sea necesario.
● Cada documento debe contar con una carátula al principio que debe
contener:
○ Título explicativo del contenido del documento
○ Membrete institucional
○ Versión del Documento
○ Historial de versiones, que incluye el número de versión, la
fecha, Asunto de la modificación, Responsable que la realizó.
Se observa, que la versión del documento debe coincidir con
el último campo de esta tabla.
○ Índice del contenido del documento y por consiguiente todas
las páginas deben estar numeradas.
○ Es deseable, que incluya al comienzo cuál es el objetivo del
documento.
Estándar de Documentación Técnica

Por documentación Técnica se entiende MER, Modelos, Diagrama
de Casos de Uso, Diagramas de Sistema en general. En el documento
"Estándar de Documentación Técnica" se define el programa de software a
utilizar y algunas convenciones.
Entregable Estándar
Documento de Requerimientos IEEE 830-1998
Alcance del Sistema IEEE 830-1998
36
Descripción de la Arquitectura ISO/IEC/IEEE 42010
Modelo de Diseño ISO/IEC 9126-3
Modelo de Datos ISO/IEC 9126-3
Estándar de documentación técnica IEEE 1063-2001
Documento de Riesgos IEEE 1058
Plan del Proyecto Metodología RUP y XP
Plan de Verificación y Validación IEEE-1012
Reporte de pruebas unitarias, de ISO/IEC/IEEE 29119

integración y del Sistema
Plan de Implantación y capacitación IEEE-1074
Estándar de Documentación de Usuario IEEE Std 1063-2001
Plan de Gestión de Configuración e IEEE Std 828-2005

Instalación
II. Métricas
● Métrica de Adecuación de Interfaz de Usuario

El documento de Requerimientos define las políticas de
interfaz a ser utilizadas teniendo en cuenta los tipos de usuarios, el
sistema Colmena y el conjunto de patrones, Se espera un
cumplimiento del cien por ciento de estas pautas, de lo contrario, se
solicitarán acciones correctivas para llegar al nivel de satisfacción
deseado.
● Métrica del Cubrimiento de las Pruebas
Se realizarán pruebas Unitarias y de Sistema por lo que este
punto tiene el objetivo de cuantificar la cantidad de pruebas
realizadas sobre el total, lo cual nos sugiere una noción de
verificación del sistema.
Sea N la cantidad total de pruebas a desarrollar y llamemos C
a la cantidad de pruebas efectivamente realizadas. Entonces,
37
Porcentaje de Cubrimiento de las Pruebas de Iteración = (C / N ) *
100
2.3.5 Revisiones
I. Tipos de Revisión
● Revisión de requerimientos
Esta revisión se realiza para asegurar que se cumplió con los
requerimientos especificados por el Cliente.
● Revisión de Diseño del Sistema y Descripción de la Arquitectura
Esta revisión se realiza para asegurar la consistencia del
diseño detallado con la especificación de requerimientos.
● 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.
● Reportes de Verificación
Estos documentos deben especificar los resultados de la
ejecución de los procesos descritos en el Plan de V & V.
● Realizar la 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. Es un proceso de revisión riguroso, su 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. Por
esta característica se adopta esta práctica para productos que son
de especial importancia.
● Revisión del Desempeño de las Pruebas mediante RTF
Esta revisión tendrá por objetivo estudiar el desempeño de las
pruebas realizadas para así obtener de esa manera una noción de la
correctitud del Sistema en base a los errores detectados en las
pruebas de una versión anterior.
● 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.
38
● Revisión del Cubrimiento de Pruebas mediante RTF
Esta revisión tendrá por objetivo estudiar el cubrimiento de las
pruebas realizadas para así obtener de esa manera una noción de
prueba del Sistema.
● Revisión del Código Generado mediante RTF
Esta revisión tendrá por objetivo revisar el código generado
para verificar el cumplimiento de los Estándares de Implementación
definidos anteriormente.
II. Agenda
En esta sección se detallan todas las revisiones de calidad que se
realizarán durante todo el proyecto, organizadas por fase e iteración.
Fase I – Inicial
Iteración I
Entregable Realizado Revisión Tipo de revisión
Documento de Fase I, Semana 2 Fase I, Semana 3 Revisión de los

Requerimientos requerimientos
funcionales y no
funcionales del
sistema
Alcance del Fase I, Semana 3 Fase I, Semana 3 Revisión del posible

Sistema alcance del
desarrollo del
sistema.
-Evaluar los
tiempos estimados
para cada fase del
desarrollo
Descripción de Fase I, Semana 4 Fase I, Semana 4 Revisión de la

la Arquitectura arquitectura
seleccionada para
el desarrollo
Modelo de Fase I, Semana 4 Fase I, Semana 5 Revisión de los

Datos datos
seleccionados para
39
la realización de la
Base de Datos
Modelo del Fase I, Semana 5 Fase I, Semana 5 Se Evalúa el diseño

Diseño de la Base de
Datos
Fase II – Elaboración
Documento de Fase II, Semana 6 Fase II, Semana 6 -Se Evalúa los
Riesgos riesgos
seleccionados que
puedan afectar al
Proyecto de
alguna forma
Plan del Proyecto Fase II, Semana 6 Fase II, Semana 7 -Se Evalúa los
plazos y fases
planteadas para el
desarrollo del
proyecto
Fase III – Construcción
Reporte de Fase III, Semana Fase III, Semana -Se Evalúa las
pruebas unitarias, 8 9 pruebas realizada
de integración y por el equipo de
proyecto.
del Sistema
-Revisión de los
resultados
arrojado por
dichas pruebas
Plan de Fase III, Semana Fase III, Semana -Se Evalúa las
Implantación y 9 10 fases y plazos
capacitación implementados
para la
capacitación de
los docentes.
40
-Revisión del plan
de implantación.
Fase IV – Transición
Estándar de Fase IV, Semana Fase IV, Semana -Se Evalúa y

Documentación 11 12 verifica que la
de Usuario documentación
dirigida al usuario.
Plan de Gestión Fase IV, Semana Fase IV, Semana - Revisión de plan
de Configuración 12 13 de configuración
e Instalación del sistema
-Evaluación de los
pasos a seguir
para el proceso de
instalación del
sistema
2.3.6 Testeo
I. Requerimientos de Calidad del Producto de Software a Construir
Los requerimientos de calidad del producto de software 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. Cada uno
de estos atributos debe cumplir con las normas y regulaciones aplicables a
cada uno.
● Funcionalidad
Adecuación a las necesidades. El producto a construir debe
satisfacer las necesidades del cliente. Este aspecto debe darse en
todo el producto.
● Interoperabilidad
El sistema podrá interoperar con otro sistema ya existente
llamado Colmena, por lo que debe utilizar y proponer interfaces
41
conocidas. En especial en la comunicación con la capa de servicios
de colmena
● Confiabilidad
Tolerancia a faltas. El sistema debe responder de manera
aceptable ante faltas en la programación. Este aspecto debe ser
considerado en todo el producto a construir.
● Usabilidad
Desde el punto de vista de la Usabilidad, debemos tener en
cuenta que el Producto a construir no será puesto en producción sino
que será tomado como prueba de concepto por los técnicos de
Artech. Es por ello que se identifican los siguientes atributos:
○ Comprensible
Desde el punto de vista interno nos ayudará a lograr
otros aspectos de calidad como la evolucionabilidad y
verificabilidad. Además, se debe tener especial énfasis en la
Interfaz de Usuario, dado que esta debe cumplir con la
interfaz estándar de K2B.
○ Aprendible
Este atributo es uno de los fundamentales, dado que el
objetivo de nuestro producto es ser prueba de concepto, por lo
que se debe procurar que el cliente sea capaz de aprender y
entienden la estructura interna del producto.
○ Operable
II. Mantenibilidad
Este aspecto de calidad es fundamental dado que nuestro producto
de software debe ser capaz de que se le realicen modificaciones luego de
su entrega para agregarle características que no estaban dentro del
alcance del proyecto (evolucionabilidad), ya que se espera que Artech
continúe el desarrollo del mismo en su prueba de concepto. Es por ello que
se identifican los siguientes atributos dentro de este:
● Analizable
● Modificable
● Estable, no se producen efectos inesperados luego de
modificaciones
● Verificable
● Evolucionabilidad
Estos aspectos deben ser cuidados en todo el producto, prestando
especial atención al código generado.
42
CAPÍTULO III GESTIÓN DE BASE DE DATOS Y
SEGURIDAD INFORMÁTICA
3.1 Diagrama de base de datos
La base de datos del sistema fue desarrollada en PostgreSQL por los estándares
de la comunidad. A continuación, se muestra el diagrama de base de datos, en donde se
indica la base de datos utilizada en el sistema
Diagrama de tablas relacionales
43
Diagrama de tablas no relacionales
3.1.1 Diccionario de datos
Tabla Tareas tasks
Llave Nombre Campo Tipo Tamaño
PK Id Tarea id int
Título title varchar 255
Fecha estimated_dat date

estimada de e
entrega
Fecha de deliver_date date

entrega
Detalle de details text

tarea
Complejidad complexity integer
Prioridad priority integer
Estado de task_status enum

tarea
44
Tipo de Tarea task_type enum
Vista seen boolean
FK Id Usuario user_id integer
Estampas de created_at timestamp

tiempo
updated_at timestamp
Tabla task_logs
Bitacora de
Tareas
PK Id bitácora de id integer
tarea
FK Id de tarea task_id integer
Detalle details text
Tabla users
Usuarios
PK Id Usuario id integer
FK Id department_i integer
45
Departamento d
Cedula cedula varchar 15
Nombres firstname varchar 45
Apellidos lastname varchar 45
Tipo de user_type enum

Usuario
Correo email varchar 45
Clave password varchar 25
Teléfono phone varchar 15
Fecha de birthdate date

Nacimiento
Sexo gender boolean
Tabla Roles users_has_rol

de Usuario es
PK Id Rol de id integer
Usuario
FK Id Rol rol_id integer
46
Tabla Roles roles
PK Id Rol id integer
Nivel de rol level integer
Nombre del name varchar 45

rol
Ficha slug varchar 25
Tabla roles_has_per
Autorizacione missions
s
PK Id id integer
Autorización
FK Id Rol rol_id integer
FK Id Acción permission_id integer
Tabla permissions
Acciones
PK Id Accion id integer
Nombre de name varchar 45
47
acción
Nivel de level integer

autorización
Navegación navigation varchar 25
Tabla de absences
Permisos y
Reposos
PK Id de Permiso id integer
o Reposo
Permiso o type boolean

Reposo
Fecha de start_date date

Inicio
Fecha de end_date date

Finalización

tiempo
48
Tabla de users_has_re
Encargados curing_activiti
en tareas es
Recurrentes
PK Id Encargado id integer
FK Id Tarea recurring_acti integer

Recurrente vity_id
Tabla de recurring_acti
Tareas vities
Recurrentes
PK Id de tarea id integer
recurrente
Título title varchar 25
Tipo de frequency enum

Frecuencia
Tiempo de delivere_days integer

entrega
49
Prioridad priority integer
Complejidad complexity integer
Tipo de Tarea task_type enum
Fecha de start_date date

Inicio
Ultimo last_launch date

lanzamiento
Activa active boolean

tiempo
Tabla de calendar
Calendario
PK Fecha workable_dat date

laborable e
Tabla de departmets
Departamento
50
PK Id id integer
Departamento
Nombre name varchar 100
Descripción description text
Tabla de passwords_re
Recuperación set
de contraseña
PK Correo de email varchar

usuario
Token token varchar
Estampa de created_at timestamp

tiempo
Tabla de migrations
Migracioneciones
PK Batch batch integer
Migración migration varchar
51
3.2 Monitoreo de transacciones
A continuación se muestra el estudio de las transacciones del sistema en
entorno de producción, en este se muestra detalladamente el aumento diario de la
data por cada una de las tablas de la base de datos.
3.2.1 Uso y aumento diario de las tablas
Tabla Incremento promedio diario Módulos que la afectan

en Bytes
task_logs 2002kb Seguimiento de tareas
tasks 1140kb Seguimiento de tareas, Tareas
users 0kb Usuarios
roles 0kb Roles
users_has_roles 160kb Roles
permissions 0kb Roles
absences 517kb Ausencias
recurring_activities 0kb Actividades Recurrentes
responsibles 0kb Actividades Recurrentes
calendar 0kb Calendario
52
3.3 Revisión preventiva de las tablas relacionadas con la
seguridad
Al realizar la revisión de las tablas de usuarios, roles, roles por usuario,
permisos y permisos por roles, las cuenta se encuentran relacionadas
directamente con la seguridad del sistema no se encontró ningún problema que
comprometiese el sistema.
3.4 Diagnóstico de posibles cuellos de botella en un plazo de

tiempo determinado
Un cuello de botella o embudo en comunicación e informática hace
referencia a cuando se realizan múltiples solicitudes simultáneas más las mismas
no pueden ser atendidas al mismo tiempo, quedando encoladas hasta que la cola
es saturada y abortando el proceso. De esa manera, siendo el sistema Colmena
una aplicación web que funciona en la intranet de la UPTAEB y se tiene acceso
desde cualquier computador conectado a la intranet. El proceso que genera mayor
cantidad de consultas a la base de datos es el de Seguimiento de Tareas, más sin
embargo no se genera gran cantidad de conexiones simultáneas a un mismo
recurso por tanto no se cuenta con un posible cuello de botella.
3.5 Diagnóstico sobre la seguridad física, lógica, redes y

estaciones de trabajo, base de datos del proyecto
3.5.1 Seguridad Física
Se encontró que las instalaciones en donde se encuentran las áreas de

cómputo en donde es utilizado el sistema no posee ningún tipo de prevención
contra desastres naturales, el área de trabajo no posee protección antisísmica, los
equipos no se encuentran protegidos contra vibraciones tampoco se tienen
53
establecidos planes de recuperación de datos o de sistema en caso de desastre
natural. No se cuenta con ningún tipo de extintores o protección anti incendios.
Las instalaciones eléctricas no fueron adecuadas para el uso de

computadores, no se tienen fuentes de alimentación eléctrica alternas pero
algunos de los computadores cuentan con UPS para su funcionamiento en caso
de falla eléctrica. No se realizó un trabajo de medición sobre el ruido
electromagnético al momento de la instalación de los computadores. La institución
carece de planes de contingencia en caso de fallas eléctricas o de fallas causadas
por ruido electromagnético y de equipos de alarma para detectar anomalías
electromagnéticas. El área de cómputo cuenta con un sistema de temperatura
adecuado, más sin embargo no posee control de humedad, además el personal de
limpieza no cuenta con implementos de limpieza adecuados para los
computadores, tampoco se tiene una normativa de buen uso de los equipos ni un
plan de mantenimiento a equipos.
Se tiene un protocolo de acceso a las instalaciones más no se tiene registro

de personas que ingresan ni mecanismos de seguridad para prevenir daños o
hurtos sobre los equipos de computo.
3.5.2 Seguridad Lógica
El sistema cuenta con protección de acceso mediante el uso de

contraseñas de acceso encriptadas además de protección de uso a través de roles
de usuario y lleva un seguimiento de acciones realizadas mediante una bitácora
de sistema que se almacena en la base de datos para hacer del mismo un sistema
auditable. Asimismo permite hacer respaldo parciales de data, estos respaldos no
son encriptados.
Los usuarios tienen la capacidad de recuperar sus datos de acceso en caso

de pérdida sin necesidad de consultar a un administrador de sistema, más sin
54
embargo se le permite a los usuarios ingresar dispositivos de almacenamiento
externos en el computador en donde se utiliza el computador además de permitir
una navegación web libre, esto generando riesgos de entrada para software
malicioso a las estaciones de trabajo en donde el sistema es utilizado.
No fueron encontradas puertas traseras en el sistema, a pesar de no contar

con protección contra inyecciones de tipo XSS el sistema no cumple con las
características para realizar este ataque.
El sistema no cuenta con rutinas de recuperación de datos en caso de fallas

de servidor ni chequeo de transacciones fallidas, tampoco de recuperación de
índices de base de datos.
3.5.3 Seguridad en la Base de Datos
Se cuenta con una base de datos propia del sistema, la cual no es

compartida con otros sistemas, se tienen restricciones pertinentes para mantener
la integridad referencial de datos. El sistema no cuenta con un manejo adecuado
de roles y privilegios para la interacción con la base de datos, este se conecta a
través de un usuario de base de datos de único a nombre del cual se realizan
todas las interacciones del sistema, este usuario solo tiene permisos sobre la base
de datos del sistema.
Asimismo no cuenta con rutinas de de recuperación y respaldo de
información de la base de datos, no se lleva un control de concurrencia en base de
datos, no se tienen validaciones en la base de datos, no se lleva un seguimiento
de acciones realizadas en la base de datos (bitácora), no se realizan
actualizaciones periódicas al sistema gestor de base de datos dando cabida a
fallos de seguridad no corregidos.
55
3.7 Métodos de cifrado programados en el sistema
Siendo de vital importancia para cualquier sistema brindar a los usuarios
una protección de acceso se decidió encriptar la contraseña para ser guardada en
la base de datos, evitando lo más posible cualquier intento de ingreso de
secuestro de credenciales de acceso a sistema utilizando los datos almacenados
en la base de datos, para ello se implementó el algoritmo de cifrado bcrypt,
algoritmo de una vía, en el que se encripta la información más no es posible
desencriptarla, solo es posible compararla con otra entrada a través del mismo
algoritmo. Asimismo, buscando proteger la sensibilidad en los datos se
implementará un algoritmo de esteganografía para guardar una palabra o frase
clave en de manera encriptada mediante brcrypt en una imagen para su posterior
autenticación como protección de acceso a cualquier sección sensible del sistema,
siendo el corazón del sistema el manejo de asignaciones, para proteger la
veracidad de los datos se decidió implementar el algoritmo anteriormente expuesto
en el módulo de tareas del sistema.
3.8 Matriz de riesgos en relación a la seguridad informática

De ésta se evidenció los datos e información más sensibles que de sufrir
daño a causa de los factores con mayor probabilidad (fallas o sobrecargas
eléctricas, fallas de sistema, mantenimiento de software en el servidor)
comprometería el funcionamiento adecuado del sistema, entre ellos está el
seguimiento de tareas en donde se almacena las iteraciones de una tarea (sus
cambios de estado y la interacción entre el creador y el responsable de la misma)
y la información de la permisología del sistema que es en donde se almacena la
información de los roles y perfiles de usuario, una falla en esta sección del sistema
podría dejar sin acceso a una parte del sistema o dar acceso a módulos sensibles
56
por parte de personal no autorizado. Otros factores con probabilidad media que
podrían afectar son La intrusión a la red interna, el mal manejo de sistemas y
herramientas, el manejo inadecuado de las contraseñas (compartir contraseñas,
contraseñas muy sencillas) y la falta de mantenimiento físico al servidor.
57
CAPÍTULO IV AUDITORÍA INFORMÁTICA
4.1 Tipos de auditorías

Se decidió realizar una auditoría integral del proyecto en donde llevó a cabo
un compendio de auditorías. Se realizó una auditoría de Proyecto en la cual se
revisó a detalle la planificación, la metodología de desarrollo y la documentación
del sistema. Asimismo se realizó una auditoría de explotación cuyo objetivo fue
revisar las entradas y salidas del sistema además de las validaciones del mismo.
Además se hizo una auditoría de redes y comunicaciones en donde el objetivo fue
detallar a fondo cómo operan las redes del entorno de producción del sistema
desde su cableado, las configuraciones de red, su topología, entre otros. De la
misma manera se realizó una auditoría de sistema cuyo objetivos fueron verificar
la aceptación del sistema, determinar el estado actual del sistema (debilidades,
fortalezas). Por último se hizo una auditoría de base de datos en donde se
inspeccionó el estado de la base de datos, su estructura y su mantenibilidad.
4.2 Herramientas y técnicas

Para el desarrollo de la auditoría del proyecto se hizo uso de múltiples
técnicas y herramientas, como lo son cuestionarios, entrevistas estructuradas,
listas de chequeo, además de herramientas automatizadas como Tinker,
PHP-Faker, PHPUnit y Golismero.
4.3 Metodología seleccionada

Se implementó como metodología de auditoría caja blanca, esta fueré
aplicada al módulo de tareas del sistema en donde el objetivó fue auditar su
funcionamiento y revisar detalladamente la manera en que este transforma la
data.
58
4.4 Resultados
Los resultados arrojados a través del proceso de auditoría se describen a detalle
en la siguiente tabla.
Tipo de Diagnóstico del Hallazgo Solución Propuesta

Auditoría
Desarrollo No se verificó que el motor de base Realizar una estudio para determinar qué tan
de datos es el adecuado para el adecuado es el motor de base de datos
sistema seleccionado y cúal es el motor más acorde.
Desarrollo No se verificó que el lenguaje de Realizar una estudio para determinar qué tan
programación es el adecuado para el adecuado es el lenguaje de programación
sistema seleccionado y cúal es lenguaje más acorde.
Desarrollo El sistema no se encuentra instalado Realizar los ajustes pertinentes en servidor y en

en servidor de producción debido a sistema para que este pueda ser desplegado en
problemas en la configuración del ambiente de producción
servidor
Explotación Se encontró que el sistema solicita Revisar con detalle los datos de entrada para
datos que posteriormente no son determinar su pertinencia, generar reportes con
utilizados para ningún reporte o salida los datos no utilizados o eliminar su entrada de no
ser necesarios
Explotación El sistema no presenta todos los Hacer un estudio de los reportes actualmente
reportes necesarios para el análisis existentes y generar nuevos reportes de ser
de la información del mismo necesario
Explotación Se detectó una falla en el diseño de Realizar una actualización en el esquema de

base de datos al intentar generar un base de datos para que este permita la gestión de
cambio en una tarea grupal tareas de manera grupal
59
Sistema La documentación de sistema debe Actualizar la documentación de sistema
ser actualizada para estar acorde al
estado actual del sistema y que esto
permita facilitar el proceso de
mantenimiento de sistema en el futuro
Sistema Se encontró que el sistema no solicita Solicitar confirmación para acciones que realicen
un mensaje de confirmación para la cambios en la base de datos
actualización de datos, por lo cual
puede incurrir en pérdida de datos
Sistema El sistema no permite generar Codificar un módulo de respaldo y restauración

respaldos de la data, ni tampoco hace de datos, además de generar respaldos
respaldos automáticos automáticos
Base de No se tiene un plan de actualización Sugerir al administrador del servidor de

Datos para el SGBD, por tanto puede producción que se generen planes para la
incurrir en fallos de seguridad por actualización de las herramientas del servidor
desactualización
Base de El sistema no posee validaciones en Generar validaciones para la capa de base de

Datos la capa de base de datos datos en donde sea requerido
60
A continuación son descritos los resultados obtenidos gracias a la
herramienta Golismero, implementada para encontrar fallos de seguridad a través
de la seguridad ofensiva.
N° Diagnóstico del Hallazgo Solución propuesta
1 Es posible conseguir la IP base del Sugerir al administrador del servidor

servidor en donde se aloja el sistema a configurar el servidor HTTP para no
través de una petición HTTP 1.0 mostrar el IP de retorno,
2 El archivo /.htaccess contiene Revisar de manera cautelosa el archivo

configuración y/o información de .htaccess para evitar que su contenido
autorización revelase información que comprometa la
seguridad del sistema
3 Posee una URL /login No se toma ninguna acción, el sistema

cuenta con protección de autentificación el
cual restringe la entrada indebida al mismo.
4 El archivo /web.config es accesible Revisar de manera cautelosa el archivo

públicamente web.config para evitar que su contenido
revelase información que comprometa la
seguridad del sistema
5 El header de X-Content-Type-Options Sugerir al administrador del servidor

no se ha configurado. Esto permite a configurar el servidor HTTP para que se
los usuario renderizar el contenido del agregue la configuración adecuada del
sitio de una manera distinta al MIME header X-Content-Options
6 El header X-Frame-Options anti Sugerir al administrador del servidor

Clickjacking no está presente configurar el servidor HTTP para que se
agregue la configuración adecuada del
header X-Frame-Options con la
61
configuración adecuada para evitar el
clickjacking
7 Se devuelve el header x-powered Sugerir al administrador del servidor

PHP/7.0.28-0ubuntu0.16.04.1 configurar el servidor HTTP para cambiar
el mensaje del header o no mostrarlo
según encuentre conveniente.
8 La cookie de seguridad XSRF-TOKEN Agregar la bandera httponly a la cookie de

es creada sin la bandera de httponly seguridad XSRF-TOKEN para evitar la
utilización del token XSRF para peticiones
no http
9 El header X-XSS-Protection no se Sugerir al administrador del servidor

encuentra configurar el servidor HTTP para que este
devuelva el header X-XSS-Protection para
alertar a los usuarios de la posibilidad de
ataque XSS en algún formulario
62
CAPÍTULO V MANTENIMIENTO DEL
PROYECTO
5.1 Propósito del mantenimiento

El propósito de realizar mantenimiento preventivo y/o correctivo, no es más
que alargar el tiempo de vida útil del sistema, su base de datos y demás
compuestos, convirtiendo el sistema en una herramienta que pueda ser usado por
mucho tiempo y adaptable a las necesidades que surjan con el pasar del mismo.
El mantenimiento realizado al sistema debe ser; Evolutivo, el cual modificará y
mejorará los módulos que lo requieran, con la finalidad de aumentar o cambiar las
funcionalidades ya sea por las necesidades del usuario o algunas externas.
5.2 Tipo de mantenimiento

A medida que pasa el tiempo, las aplicaciones de software deben ser
sometidas a procesos de modificación que extiendan su vida útil o mejoren sus
características. Corrección de bugs, adaptación a nuevos entornos tecnológicos o
agregado de funcionalidad son algunas de las tareas que incluye el mantenimiento
del software, una actividad que se debe repetir periódicamente desde el comienzo
hasta el final de su vida útil.
En el presente proyecto se realizó un mantenimiento preventivo al sistema,

para así evitar posibles focos de problemas que pudiesen comprometer el sistema
en el futuro. Asimismo, como mantenimiento correctivo gracias a los resultados
arrojados por el proceso de auditoría se corrigió los defectos encontrados en el el
software.
63
5.3 Plan de mantenimiento y capacitación
Se generó un plan en el cual se describe cómo se llevó a cabo el proceso
de mantenimiento según los resultados de la auditoría y la capacitación de los
usuarios para instruirlos de las nuevas funcionalidades del sistema y de sus
correcciones. Para el mantenimiento del sistema fueron planificadas dos fases, la
primera de ellas consistió en el plan de mejoras en las funcionalidades de respaldo
y recuperación de datos del sistema, para que el sistema fuese capaz de realizar
respaldos parciales de la data automáticamente y asimismo los usuarios pudieran
crear respaldos de la información y también restaurarlos. La segunda fase constó
de las mejoras de seguridad, de funcionalidad y de optimización que fueron
detectadas en la auditoría de sistema.
Asimismo, para la capacitación de los usuarios en materia de la nueva

versión del sistema se tomó como objetivo mostrarles el manejo adecuado del
mismo, las capacidades actuales del sistema y debatir el crecimiento posible del
sistema en el futuro. El contenido de la capacitación se estructuró de la
siguiente manera.
● Cambios en la entrada al sistema.
● Actualización de clave de acceso.
● Uso adecuado de la imagen y frase de seguridad.
● Nuevo funcionamiento del módulo de tareas.
● Mejoras no visibles en materia de seguridad.
● Respaldo y recuperación de datos.
64
5.4 Informe de resultados de mantenimiento y capacitación
Se describe de forma detallada cada uno de los mantenimientos realizados
al sistema.
Código de mantenimiento M001

Encontrado en Auditoría de Desarrollo
Tipo de ● Mantenimiento correctivo
mantenimiento
Detalles técnicos ● Ajustes de servidor y de sistema para funcionar
en producción
● El sistema no se encuentra instalado en servidor de
Fallas encontradas producción debido a problemas en la configuración
del servidor.
● Se cambió la configuración del servidor http
Solución para permitir la sobre-escritura de configuración
en tiempo de ejecución para que el sistema
pudiese funcionar.
● Se realizó un cambio en todo el sistema de
enrutamiento del Proyecto para que las rutas
fuesen absolutas y pudiesen ser
implementadas de manera funcional.
Cambio en el
Fecha: Cambio:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico
65
Encontrado en Auditoría de Explotación
mantenimiento
Detalles técnicos ● Solicitud de datos no utilizados
● El sistema solicita en el momento del registro
Fallas encontradas de datos de usuario el género del mismo y
posteriormente esta información no es
implementada.
● Se eliminó dicho campo de la base de datos.
Solución ● Se eliminó la entrada del mismo en los
formularios del sistema en donde se encuentre.
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico

Tipo de ● Mantenimiento evolutivo
mantenimiento
Detalles técnicos ● Evaluación de nuevos reportes
● El sistema no muestra todos los reportes
Fallas encontradas posibles.
● Se evaluó los reportes existentes en busca de

Solución una mejoría.
● Se revisó que reportes sería pertinentes
agregar al sistema.
● Se agregaron de los reportes que se
66
encontraron pertinentes.
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico

mantenimiento
Detalles técnicos ● Falla de diseño en módulo de tareas
● Se detectó una falla en el diseño de base de
Fallas encontradas datos al intentar generar un cambio en una
tarea grupal.
● Se realizó de ajustes pertinentes al diseño de
Solución base de datos.
● Se codificó de módulo de tareas con respecto
al nuevo esquema de base de datos.
● Se realizaron ajustes en módulos afectados por
los cambios.
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico
67
Encontrado en Auditoría de Sistema
mantenimiento
Detalles técnicos ● Documentación de sistema desactualizada
● La documentación de sistema debe ser
Fallas encontradas actualizada para estar acorde al estado actual
del sistema y que esto permita facilitar el
proceso de mantenimiento de sistema en el
futuro
● Se revisó y actualizó la documentación de
Solución sistema.
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico

Tipo de ● Mantenimiento preventivo
mantenimiento
Detalles técnicos ● Solicitud de confirmación para data sensible
● Se encontró que el sistema no solicita un
Fallas encontradas mensaje de confirmación para la actualización
de datos, por lo cual puede incurrir en pérdida
de datos
● Se codificó un mensaje de solicitud de
Solución confirmación para acciones sensibles que de
ser erradas puedan incurrir en pérdida de data.
68
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico

mantenimiento
Detalles técnicos ● Respaldo y recuperación de data
● El sistema no permite la creación de backups
Fallas encontradas de la data ni tampoco la restauración de los
mismos
● Se codificó un módulo de respaldo y
Solución recuperación de datos que permita a los
usuarios crear backups y descargarlos, así
como la creación de backups automáticos de
sistema.
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico
69
Encontrado en Auditoría de Base de datos
mantenimiento
Detalles técnicos ● Actualizaciones periódicas de SGBD
● No se tiene un plan de actualización para el
Fallas encontradas SGBD, por tanto puede incurrir en fallos de
seguridad por desactualización.
● Se sugirió al administrador del servidor de
Solución producción que se generen planes para la
actualización de las herramientas del mismo.
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico

Encontrado en Auditoría de Base de datos
mantenimiento
Detalles técnicos ● Validaciones en capa de base de datos
● El sistema no posee validaciones en la capa de
Fallas encontradas base de datos
● Se codificaron validaciones en capa de base de

Solución datos para entradas sensibles del sistema.
Cambio en el
Fecha:
sistema
MANTENIMIENTO
70
Descripción
Fecha y firma del
técnico

Encontrado en Software Golismero
mantenimiento
Detalles técnicos ● IP base del servidor
● Es posible conseguir la IP base del servidor en
Fallas encontradas donde se aloja el sistema a través de una
petición HTTP 1.0
● Se sugirió al administrador del servidor de
Solución instalar un servidor de DNS para no mostrar la
ip del servidor de manera pública.
● Se sugirió al administrador del servidor para la
configuración del servidor HTTP para no
devolver la IP base del servidor a través de una
petición HTTP 1.0
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico
71
Encontrado en Software Golismero
mantenimiento
Detalles técnicos ● Configuración para headers
● El header de X-Content-Type-Options no se ha
Fallas encontradas configurado. Esto permite a los usuario
renderizar el contenido del sitio de una manera
distinta al MIME
● El header X-Frame-Options anti Clickjacking no
está presente
● En las peticiones se devuelve el header
x-powered PHP/7.0.28-0ubuntu0.16.04.1
● El header X-XSS-Protection no se encuentra
● Incentivo al administrador de servidor para la
Solución correcta configuración de los headers en
servidor HTTP.
● Se generó una guía de configuración de las
sugerencias de mejoras en configuración de
servidor HTTP para ser entregada al
administrador de servidor.
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico

Encontrado en Golismero
mantenimiento
Detalles técnicos ● httpOnly flag para XSRF-TOKEN
72
● La cookie de seguridad XSRF-TOKEN es
Fallas encontradas creada sin la bandera de httponly.
● Se agregó la bandera httponly a la cookie de

Solución seguridad XSRF-TOKEN para evitar la utilización
del token XSRF para peticiones no http.
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico
73
CAPÍTULO VI INTEGRACIÓN DEL PROYECTO
6.1 Diagnóstico del proyecto para integración con sistemas

existentes
Una de las características de la programación actual es que el código de la
misma pueda ser reutilizable y que esta contribuya a la estandarización de la
tecnología, es decir, conocimientos, técnicas, métodos, diseños, en líneas
generales los sistemas informáticos en su totalidad. He aquí, donde cobra
importancia una de las grandes bondades de la integración tecnológica, y es
conseguir una gestión centralizada a nivel de datos, de procesos y de aplicación,
esta herramienta ha venido a ser muy sustancial e indispensable en la actualidad
por sus múltiples beneficios como: evitar la fraccionamiento de la información,
reducción del tiempo de gestión en las diferentes unidades de la institución, en
este caso la Universidad Politécnica Territorial Andrés Eloy Blanco, mejorar la
comunicación entre las diferentes unidades o departamentos de la institución, con
el objetivo de conectar aplicación y compartir información, evitar errores y volver a
programar procesos.
Debido a la naturaleza operativa del sistema y como fue concebido no es

posible lograr una integración a nivel de datos pues el diseño de las bases de
datos que implementan los sistemas que funcionan en la comunidad no son
compatibles entre sí. Aún así es posible lograr que los sistemas interactúen entre
sí implementando medidas de interoperabilidad. Entre los posibles sistemas que
pueden interoperar a futuro se puede mencionar el Sistema de Información para la
Gestión de Evaluaciones, en el cual se generan planes de evaluaciones, se
almacenan las notas de los estudiantes entre otras funcionalidades, con este el
sistema se podría comunicar vía API (Interfaz de Programación de Aplicaciones)
74
para generar Tareas que indiquen al docente la carga de notas, o la actualización
de sus planes de clase o evaluación, asimismo el sistema podría recibir data
desde cualquier sistema para la creación de asignaciones que sirvan a los
usuarios para estár atentos de sus pendientes en los demás sistemas de la
organización.
75
CAPÍTULO VII CONCLUSIONES Y
RECOMENDACIONES
Habiendo culminado con total satisfacción todas las etapas y objetivos que
fueron planteados en el proyecto, fueron entregados al Programa Nacional de
Formación en Informática de la Universidad Politécnica Territorial Andrés Eloy
Blanco el informe técnico del proyecto, toda la documentación con manuales y
documentos anexos además de la codificación.
El sistema cumple con las exigencias de estándar provistos por la
comunidad en materia de arquitectura de software, tecnologías empleadas e
indentación de código, de esta manera facilita su mantenibilidad y su
escalabilidad, siendo más sencillo para el personal de planta realizar
mantenimientos de software.
Asimismo el uso de la metodología de desarrollo RUP, conjuntamente con
el lenguaje UML y el manejo de los conceptos de la programación orientada a
objetos y el patrón arquitectónico MVC, en conjunto con el framework Laravel
propiciaron que el desarrollo del sistema sea entendible, sostenible e Incremental.
Se recomienda evaluar continuamente el estado del servidor y de sus

herramientas, siempre revisando las actualizaciones disponibles para evitar fallos
por obsolescencia o por desactualización, así como también es necesario que se
evalúe el rendimiento del servidor para determinar de manera temprana el
requerimiento de hardware para que los sistemas funcionen de manera adecuada.
76

Informe de Proyecto Colmena T4 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Informe de Proyecto Colmena T4 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

República Bolivariana de Venezuela

Ministerio del poder popular para la educación universitaria,

SISTEMA AUTOMATIZADO PARA LA GESTIÓN DEL TALENTO

CAPÍTULO I DESCRIPCIÓN DEL PROYECTO 6

CAPÍTULO II GESTIÓN DE PROYECTO INFORMÁTICO 10

CAPÍTULO III GESTIÓN DE BASE DE DATOS Y SEGURIDAD INFORMÁTICA 43

CAPÍTULO IV AUDITORÍA INFORMÁTICA 58

CAPÍTULO V MANTENIMIENTO DEL PROYECTO 63

CAPÍTULO VI INTEGRACIÓN DEL PROYECTO 74

CAPÍTULO VII CONCLUSIONES Y RECOMENDACIONES 76

1.1 Caracterización de la comunidad

La Universidad Politécnica Territorial Andrés Eloy Blanco (UPTAEB) nació

La institución imparte los siguientes Programas Nacionales de Formación

Como institución de educación pública el encargo social del UPTAEB se

1.1.2 Justificación e impacto social

El desarrollo de la presente investigación pretende generar un impacto positivo

1.2 Objetivos del proyecto

1.2.1 Objetivo General

Implantar un Sistema de Gestión del Talento Humano para la Universidad

1.2.2 Objetivos Específicos

● Diagnosticar los riesgos de Proyecto del Sistema Automatizado para la

2.1 Análisis de riesgo

Uno de los elementos clave a la hora de asegurar el éxito en el proyecto,

Este apartado presenta el análisis de los riesgos identificados en la fase

El ámbito del análisis de riesgos cubre toda la extensión del proyecto

Cod Riesgo Categoría Impacto

R00 Disolución del equipo de proyectistas Proyecto Alto

R00 Cambios en la visión gerencial de la comunidad Proyecto Medio

R00 Averías en el servidor Sistema Medio

R00 Fallas eléctricas Sistema Medio

R00 Problemas financieros del equipo de proyectistas Proyecto Alto

R00 Fallas de comunicación entre proyectistas y la Proyecto Medio

R00 Cambios en las políticas de desarrollo de la Proyecto Alto

R00 Conflictos de versiones en tecnologías utilizadas Sistema Alto

R00 Daños ocasionados por catástrofes naturales o Sistema Bajo

R01 Manejo inadecuado de permisologías del sistema Sistema Alto

R01 Falla en planificación de las actividades del Proyecto Medio

Análisis del Riesgo

Descripción Deserción por parte de los miembros del equipo de proyecto

Fecha de identificación: Tipo de Riesgo: ​Proyecto

Valoración Cualitativa Periodo en el cual puede ocurrir: ​En

● Redimensionar el alcance del proyecto en materia de requisitos de sistema (SRS)

Responsables de administrar el riesgo y tiempo estimado de ejecución:

Dado que hubo un cambio de encargado de la comunidad,

Descripción cambio de visión gerencial durante la ejecución del proyecto

Valoración Cualitativa Periodo en el cual puede ocurrir:

● Lograr el cumplimiendo de lo establecido en el contrato original de requisitos (SRS)

Responsables de administrar el riesgo y tiempo estimado de ejecución:

Descripción: Daños que afecten la integridad física y lógica del servidor

Fecha de identificación: Tipo de Riesgo: ​Sistema

Valoración Cualitativa Periodo en el cual puede ocurrir: ​En

● Sugerir la instauración de políticas de mantenimiento preventivo en el servidor

Responsables de administrar el riesgo y tiempo estimado de ejecución:

Cortes no programados en el suministro eléctrico, sobrecarga

Descripción: eléctrica o carga insuficiente

Fecha de identificación: Tipo de Riesgo: ​Sistema

Valoración Cualitativa Periodo en el cual puede ocurrir:

● Sugerir la utilización de UPS para el servidor de una carga que soporte un

Responsables de administrar el riesgo y tiempo estimado de ejecución:

Equipo Proyectista conformado por estudiantes del PNFI, los

Descripción: cuales no perciben ingresos por la realización del presente

Fecha de identificación: ​Enero/2016 Tipo de Riesgo: ​Proyecto

Causas:​ Crisis económica nacional Consecuencias: ​Posible deserción de

Fecha de identificación: Tipo de Riesgo: Proyecto

Valoración Cualitativa Periodo en el cual puede ocurrir: En

Fecha de identificación: Tipo de Riesgo: Sistema

Valoración Cualitativa Periodo en el cual puede ocurrir: En

Fecha de identificación: Tipo de Riesgo: Sistema

Fecha de identificación: Enero/2016 Tipo de Riesgo: Proyecto

Causas: Crisis económica nacional Consecuencias: Posible deserción de

Valoración Cualitativa Periodo en el cual puede ocurrir: En

Causas: Dinámicas laborales Consecuencias: Análisis de requisitos no

Valoración Cualitativa Periodo en el cual puede ocurrir: En

Causas: Problemas en la Consecuencias: Funcionamiento

Causas: Causas imprevistas Consecuencias: Daños sobre equipos,

Valoración Cualitativa Periodo en el cual puede ocurrir: En

Causas: Consecuencias: Comprometimiento de

Valoración Cualitativa Periodo en el cual puede ocurrir: Etapa

Causas: Situaciones imprevistas Consecuencias: Retraso en el desarrollo

Valoración Cualitativa Periodo en el cual puede ocurrir: En

Causas: Cambios en la administración Consecuencias: Funcionamiento de