Está en la página 1de 76

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
Gestión del Talento Humano.

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 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
Análisis del Riesgo
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 Cuantitativa 6

Valoración Cualitativa Periodo en el cual puede ocurrir:


Baja: X Media: Alta: Etapa de codificación de sistema
Estrategias para la administración del riesgo:

● 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

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


Comunidad, Equipo Proyectista

14
15
Análisis del Riesgo
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

Valoración Cuantitativa 6

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


Baja: X Media: Alta: cualquier etapa del desarrollo del
proyecto
Estrategias para la administración del riesgo:

● 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

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


Comunidad

16
Análisis del Riesgo
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

Valoración Cuantitativa 6

Valoración Cualitativa Periodo en el cual puede ocurrir:


Baja: X Media: Alta: Etapa de implantación y seguimiento
Estrategias para la administración del riesgo:

● 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

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


Comunidad

17
Análisis del Riesgo
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

Valoración Cuantitativa 8

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


Baja: Media: X Alta: cualquier etapa del desarrollo del
proyecto
Estrategias para la administración del riesgo:

● Sugerir políticas de incentivo para proyectistas destacados (becas, incentivos


metálicos, entre otros)

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

La comunidad

18
Análisis del Riesgo
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

Valoración Cuantitativa 6

Valoración Cualitativa Periodo en el cual puede ocurrir:


Baja: X Media: Alta: Análisis de requisitos
Estrategias para la administración del riesgo:
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)

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

Proyectistas, Comunidad, Tutor académico

19
Análisis del Riesgo
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

Valoración Cuantitativa 9

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


Baja: Media: X Alta: cualquier etapa del desarrollo del
proyecto
Estrategias para la administración del riesgo:

● 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

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


Proyectistas, Comunidad

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

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

Valoración Cuantitativa 12

Valoración Cualitativa Periodo en el cual puede ocurrir:


Baja: Media: Alta: X Etapa de instalación y pruebas del
sistema
Estrategias para la administración del riesgo:

● Sugerir la creación de políticas de versiones de la comunidad


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

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


Proyectistas, Comunidad

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

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


pérdidas de data, entre otros
Probabilidad 1

Magnitud 4

Valoración Cuantitativa 4

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


Baja: X Media: Alta: cualquier etapa del desarrollo del
proyecto
Estrategias para la administración del riesgo:

● Definir planes de contingencia informática ante catástrofes naturales o incendios


accidentales

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


Comunidad

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

Causas: Consecuencias: ​Comprometimiento de


la data del sistema
Probabilidad 2

Magnitud 4

Valoración Cuantitativa 8

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


Baja: Media: X Alta: de instalación y pruebas del sistema
Estrategias para la administración del riesgo:

● 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

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

Comunidad

23
Análisis del Riesgo
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
Fecha de identificación: ​Enero/2016 Tipo de Riesgo: ​Proyecto

Causas:​ Situaciones imprevistas Consecuencias: ​Retraso en el desarrollo


del proyecto
Probabilidad 3

Magnitud 3

Valoración Cuantitativa 9

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


Baja: Media: X Alta: cualquier etapa del desarrollo del
proyecto
Estrategias para la administración del riesgo:

● Planificar las actividades con tiempos de holgura prudenciales

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

● Equipo de Proyectistas
● Comunidad

24
Análisis del Riesgo
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
Fecha de identificación: ​Enero/2017 Tipo de Riesgo: ​Proyecto

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


gubernamental sistema fuera de la normativa institucional
Probabilidad 2

Magnitud 2

Valoración Cuantitativa 4

Valoración Cualitativa Periodo en el cual puede ocurrir:


Baja: Media: X Alta: Cualquiera
Estrategias para la administración del riesgo:

● Permitir la parametrización de secciones sensibles a cambios de normativa

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

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
entorno de producción

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
entorno de producción

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

Entregable Realizado Revisión Tipo de revisió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

Entregable Realizado Revisión Tipo de revisió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

Entregable Realizado Revisión Tipo de revisió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

Llave Nombre Campo Tipo Tamaño

PK Id bitácora de id integer
tarea

FK Id de tarea task_id integer

Detalle details text

Tabla users
Usuarios

Llave Nombre Campo Tipo Tamaño

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

Llave Nombre Campo Tipo Tamaño

PK Id Rol de id integer
Usuario

FK Id Rol rol_id integer

FK Id Usuario user_id integer

46
Tabla Roles roles

Llave Nombre Campo Tipo Tamaño

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

Llave Nombre Campo Tipo Tamaño

PK Id id integer
Autorización

FK Id Rol rol_id integer

FK Id Acción permission_id integer

Tabla permissions
Acciones

Llave Nombre Campo Tipo Tamaño

PK Id Accion id integer

Nombre de name varchar 45

47
acción

Ficha slug varchar 25

Nivel de level integer


autorización

Navegación navigation varchar 25

Tabla de absences
Permisos y
Reposos

Llave Nombre Campo Tipo Tamaño

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

Detalle details text

FK Id Usuario user_id integer

Estampas de created_at timestamp


tiempo

48
updated_at timestamp

Tabla de users_has_re
Encargados curing_activiti
en tareas es
Recurrentes

Llave Nombre Campo Tipo Tamaño

PK Id Encargado id integer

FK Id Usuario user_id integer

FK Id Tarea recurring_acti integer


Recurrente vity_id

Tabla de recurring_acti
Tareas vities
Recurrentes

Llave Nombre Campo Tipo Tamaño

PK Id de tarea id integer
recurrente

Título title varchar 25

Tipo de frequency enum


Frecuencia

Tiempo de delivere_days integer


entrega

49
Detalle details text

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

Estampas de created_at timestamp


tiempo

updated_at timestamp

Tabla de calendar
Calendario

Llave Nombre Campo Tipo Tamaño

PK Fecha workable_dat date


laborable e

Tabla de departmets
Departamento

Llave Nombre Campo Tipo Tamaño

50
PK Id id integer
Departamento

Nombre name varchar 100

Ficha slug varchar 45

Descripción description text

Tabla de passwords_re
Recuperación set
de contraseña

Llave Nombre Campo Tipo Tamaño

PK Correo de email varchar


usuario

Token token varchar

Estampa de created_at timestamp


tiempo

Tabla de migrations
Migracioneciones

Llave Nombre Campo Tipo Tamaño

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

Código de mantenimiento M003


Encontrado en Auditoría de Explotación
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

Código de mantenimiento M004


Encontrado en Auditoría de Explotación
Tipo de ● Mantenimiento correctivo
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
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

Código de mantenimiento M006


Encontrado en Auditoría de Sistema
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

Código de mantenimiento M007


Encontrado en Auditoría de Sistema
Tipo de ● Mantenimiento evolutivo
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
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

Código de mantenimiento M009


Encontrado en Auditoría de Base de datos
Tipo de ● Mantenimiento preventivo
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

Código de mantenimiento M010


Encontrado en Software Golismero
Tipo de ● Mantenimiento preventivo
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
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

Código de mantenimiento M012


Encontrado en Golismero
Tipo de ● Mantenimiento preventivo
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