Professional Documents
Culture Documents
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
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
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
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”.
7
1.1.1 Naturaleza de la Organización
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
Gestión del Talento Humano.
9
CAPÍTULO II GESTIÓN DE PROYECTO
INFORMÁTICO
2.1.1 Propósito
2.1.2 Alcance
10
2.1.3 Identificación de los Riegos
11
R01 Cambios de políticas gubernamentales Sistema Medio
2
12
2.1.4 Análisis detallado de riesgos de proyecto
Magnitud 4
Valoración Cuantitativa 12
13
Análisis del Riesgo
Código: R002 Cambios en la visión gerencial de la comunidad
Magnitud 3
Valoración Cuantitativa 6
14
15
Análisis del Riesgo
Código: R003 Averías en el servidor
Magnitud 3
Valoración Cuantitativa 6
16
Análisis del Riesgo
Código: R004 Fallas Eléctricas
Magnitud 3
Valoración Cuantitativa 6
17
Análisis del Riesgo
Código: R005 Problemas financieros del equipo proyectistas
Magnitud 4
Valoración Cuantitativa 8
La comunidad
18
Análisis del Riesgo
Código: R006 Fallas de comunicación entre proyectistas y la comunidad
Magnitud 2
Valoración Cuantitativa 6
19
Análisis del Riesgo
Código: R007 Cambios en las políticas de desarrollo de la comunidad
Magnitud 3
Valoración Cuantitativa 9
20
Análisis del Riesgo
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
Magnitud 4
Valoración Cuantitativa 12
21
Análisis del Riesgo
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
Magnitud 4
Valoración Cuantitativa 4
22
Análisis del Riesgo
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
Magnitud 4
Valoración Cuantitativa 8
● 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
Análisis del Riesgo
Código: R011 Falla en planificación de las actividades del proyecto
Magnitud 3
Valoración Cuantitativa 9
● Equipo de Proyectistas
● Comunidad
24
Análisis del Riesgo
Código: R012 Cambios de políticas gubernamentales
Magnitud 2
Valoración Cuantitativa 4
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
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
Diseño de diagrama de
e d 1 2 3 2 0.11
clases
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
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)
Programación de nuevos
n k, l 6 7 10 7 0.11
requisitos de sistema
Instalación de nueva
o versión de sistema en n 1 2 3 2 0.11
entorno de producción
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
28
nuevos requisitos
Diagnóstico de manejo de
u concurrencia en base de t 2 3 4 3 0.25
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
Instalación de nueva
a1 versión de sistema en w, y 1 2 3 2 0.11
entorno de producción
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
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.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
Responsabilidades
Producto Responsable
32
Estándar de Implementación Quintín Soto
2.3.3 Documentación
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.
● 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.
● 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
Entregable Estándar
36
Descripción de la Arquitectura ISO/IEC/IEEE 42010
II. Métricas
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
39
la realización 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
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
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
● 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
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
43
Diagrama de tablas no relacionales
PK Id Tarea id int
44
Tipo de Tarea task_type enum
updated_at timestamp
Tabla task_logs
Bitacora de
Tareas
PK Id bitácora de id integer
tarea
Tabla users
Usuarios
PK Id Usuario id integer
FK Id department_i integer
45
Departamento d
PK Id Rol de id integer
Usuario
46
Tabla Roles roles
PK Id Rol id integer
Tabla roles_has_per
Autorizacione missions
s
PK Id id integer
Autorización
Tabla permissions
Acciones
PK Id Accion id integer
47
acción
Tabla de absences
Permisos y
Reposos
PK Id de Permiso id integer
o Reposo
48
updated_at timestamp
Tabla de users_has_re
Encargados curing_activiti
en tareas es
Recurrentes
PK Id Encargado id integer
Tabla de recurring_acti
Tareas vities
Recurrentes
PK Id de tarea id integer
recurrente
49
Detalle details text
updated_at timestamp
Tabla de calendar
Calendario
Tabla de departmets
Departamento
50
PK Id id integer
Departamento
Tabla de passwords_re
Recuperación set
de contraseña
Tabla de migrations
Migracioneciones
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.
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.
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.
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.
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.
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
58
4.4 Resultados
Los resultados arrojados a través del proceso de auditoría se describen a detalle
en la siguiente tabla.
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.
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
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
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.
61
configuración adecuada para evitar el
clickjacking
62
CAPÍTULO V MANTENIMIENTO DEL
PROYECTO
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.
64
5.4 Informe de resultados de mantenimiento y capacitación
Se describe de forma detallada cada uno de los mantenimientos realizados
al sistema.
Descripción
Fecha y firma del
técnico
65
Código de mantenimiento M002
Encontrado en Auditoría de Explotación
Tipo de ● Mantenimiento correctivo
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
66
encontraron pertinentes.
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico
Descripción
Fecha y firma del
técnico
67
Código de mantenimiento M005
Encontrado en Auditoría de Sistema
Tipo de ● Mantenimiento evolutivo
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
68
Cambio en el
Fecha:
sistema
MANTENIMIENTO
Descripción
Fecha y firma del
técnico
Descripción
Fecha y firma del
técnico
69
Código de mantenimiento M008
Encontrado en Auditoría de Base de datos
Tipo de ● Mantenimiento preventivo
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
Cambio en el
Fecha:
sistema
MANTENIMIENTO
70
Descripción
Fecha y firma del
técnico
Descripción
Fecha y firma del
técnico
71
Código de mantenimiento M011
Encontrado en Software Golismero
Tipo de ● Mantenimiento preventivo
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
Descripción
Fecha y firma del
técnico
73
CAPÍTULO VI INTEGRACIÓN DEL PROYECTO
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.
76