PG-3819 Iso

UNIVERSIDAD MAYOR DE SAN ANDRES
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMATICA
PROYECTO DE GRADO
“Sistema de gestión de documentación de proyectos
Caso: Innovative Apps”
Para optar al grado de licenciatura en Informática
Mención: Ingeniería de Sistemas Informáticos
Postulante: Edith Jhoselyn López Fernández

Tutor de Metodológico: PhD. Javier Hugo Gustavo Reyes Pacheco
Asesor: Lic. Jhonny Roberto Felipez Andrade
La Paz – Bolivia
2021
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE DOCUMENTO
SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo
la referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este material,
sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
Dedicatoria
A mis padres y abuelos por haberme
forjado como la persona que soy
actualmente, muchos de mis logros
se los debo a ellos.
A mis hermanas y tíos por el apoyo

que me brindan día a día.
[email protected]
AGRADECIMIENTOS
Al concluir esta etapa de mi vida quiero extender un profundo agradecimiento a quienes me

acompañaron en el proceso y que siempre me brindaron su apoyo. Esta mención en especial a
mi familia.
Al doctor Javier Hugo Gustavo Reyes Pacheco por el tiempo, guía y conocimiento que me
proporcionó, ya que fueron fundamentales en la elaboración de este proyecto.
Al licenciado Jhonny Roberto Felipez Andrade por el tiempo y consejos que me proporcionó el
transcurso de la elaboración del presente proyecto.
A la Empresa Innovative Apps por darme la oportunidad, apoyo, colaboración e información

necesaria para que se haga posible la implementación del presente proyecto.
A los docentes de la carrera de Informática por los conocimientos transmitidos durante toda la
etapa de mi formación universitaria.
RESUMEN
La cantidad de información que se genera en las empresas crece de forma exponencial

y la necesidad de organizar la información es un factor importante para el éxito. Por
ello, las copias en papel están pasando a ocupar un segundo plano y se implementan
sistemas para organizar la información y acelerar el flujo de trabajo.
El presente trabajo contiene el proceso de desarrollo del Sistema de gestión de

documentación de proyectos para la empresa Innovative Apps. Tiene como finalidad
desarrollar un sistema de gestión de documentación de proyectos para tener un
avance adecuado.
En el proyecto se realizó un análisis previo y con el mismo se realizó el diseño de cada

uno de los módulos, utilizando como metodología de desarrollo programación extrema
(XP) y para el análisis y diseño el modelo Lenguaje Unificado de Modelado (UML).
Además de implementar los principios SOLID en el código.
El sistema brinda la capacidad de llevar un control de la información y seguimiento de

la documentación de los proyectos en la empresa y se podrá obtener reportes que
ayudarán en la toma de decisiones de acuerdo a los requerimientos de los usuarios.
Para la evaluación de la calidad se usó el estándar ISO 9126 y para la estimación de

costos el modelo COCOMO II
Palabras clave: documentación, sistema web,proyectos, SOLID, XP, programación

extrema, UML ISO 9126, COCOMO
ABSTRACT
The quantity of information that companies generate grow up of exponentially and the
necessity to organize information is an important condition for success. Thus, the paper
copies are becoming obsolete and informatics systems are implemented to organize
the information and speed up the work flow.
This project works on the development of Management System of documentation’s

project for “Innovative Apps” company. It has as purpose to develop a system of
management documentation of projects to have a correct advancement.
It was made a previous analysis and with it, the desing of each module was developed;
as a methodology, we worked with extreme programming (XP) and Unified Modeling
Language (UML) was used for the analysis and desing. I also worked with SOLID on
the code.
The system offers the possibility to control information and monitoring projects’
documentation in the Company and reports will be generated to help in decision making
according to the user’s requeriments.
For evaluation of quality, it was used ISO 9126 standard and for cost estimate,
COCOMO II model was used.
Palabras clave: documentation, web system, projects, SOLID, XP, extreme

programming, UML, ISO 9126, COCOMO
Contenido
CAPÍTULO I MARCO INTRODUCTORIO .................................................................. 1
1.1 Introducción .................................................................................................... 1
1.2 Antecedentes ................................................................................................. 1
1.3 Problemática .................................................................................................. 3
1.3.1. Problema principal ................................................................................... 3
1.3.2. Problemas secundarios ........................................................................... 3
1.4 Objetivo .......................................................................................................... 4
1.4.1. Objetivo general ....................................................................................... 4
1.4.2. Objetivos específicos ............................................................................... 4
1.5 Justificación .................................................................................................... 5
1.6 Metodología.................................................................................................... 5
1.7 Aporte ............................................................................................................. 7
1.8 Cronograma de acción ................................................................................... 7
CAPÍTULO II MARCO TEÓRICO ............................................................................... 8
2.1 Antecedentes de la empresa Innovative Apps ............................................... 8
2.1.1 Proyectos ................................................................................................. 8
2.2 Gestión de documentos ................................................................................. 9
2.2.1. Bases teóricas ......................................................................................... 9
2.2.2. Bases metodológicas ............................................................................. 10
2.3 Ingeniería de software .................................................................................. 11
2.4 Metodologías de programación .................................................................... 11
2.5 Programación extrema ................................................................................. 13
2.5.1 Roles XP ................................................................................................ 13
2.5.2 Fases ..................................................................................................... 14
2.6 Lenguaje unificado de modelado.................................................................. 15
2.6.1 Diagramas de casos de uso .................................................................. 16
2.6.2 Diagramas de actividad ......................................................................... 17
2.6.3 Diagramas de secuencia ....................................................................... 18
2.6.4 Diagramas de clases ............................................................................. 18
2.6.5 Modelos de navegación ......................................................................... 18
2.7 Herramientas de desarrollo .......................................................................... 19
i
2.7.1 Java Spring Boot ................................................................................... 19
2.7.2 React ..................................................................................................... 21
2.7.3 MySql ..................................................................................................... 21
2.8 Calidad de software...................................................................................... 22
2.8.1 ISO 9126................................................................................................ 22
2.8.2 Métrica punto de función........................................................................ 23
2.8.3 Escala de valoración .............................................................................. 26
2.8.4 Incidencias o no conformidades ............................................................ 26
2.9 Principios S.O.L.I.D. ..................................................................................... 27
2.10 Arquitectura en capas ............................................................................... 28
2.11 Seguridad.................................................................................................. 29
2.12 Cocomo II .................................................................................................. 30
2.12.1 USC-COCOMO II.2000.4 ................................................................... 30
CAPÍTULO III MARCO APLICATIVO ....................................................................... 32
3.1 Análisis del sistema actual ........................................................................... 32
3.2 Fase de exploración ..................................................................................... 34
3.2.1. Características de los usuarios .............................................................. 34
3.2.2. Casos de uso de la situación actual ...................................................... 35
3.2.3. Requerimientos...................................................................................... 36
3.2.4. Prototipo arquitectura del sistema ......................................................... 37
3.3 Fase de planificación.................................................................................... 37
3.3.1. Casos de uso ......................................................................................... 37
3.3.2. Historias de usuario ............................................................................... 38
3.3.3. Plan de entregas.................................................................................... 48
3.3.4. Estructura de proyecto ........................................................................... 49
3.4 Fase de iteraciones ...................................................................................... 50
3.4.1. Iteración 1 .............................................................................................. 50
3.4.2. Iteración 2 .............................................................................................. 65
3.4.3. Iteración 3 .............................................................................................. 75
3.4.4. Iteración 4 .............................................................................................. 83
3.5 Fase de Pruebas .......................................................................................... 92
CAPÍTULO IV CALIDAD, SEGURIDAD Y COSTO DE SOFTWARE ...................... 93
ii
4.1 Calidad ......................................................................................................... 93
4.1.1 Funcionalidad ........................................................................................ 93
4.1.2 Confiabilidad .......................................................................................... 96
4.1.3 Usabilidad .............................................................................................. 97
4.1.4 Eficiencia ............................................................................................... 98
4.1.5 Mantenimiento ..................................................................................... 100
4.1.6 Portabilidad .......................................................................................... 101
4.2 Seguridad ................................................................................................... 101
4.2.1 Seguridad en la base de datos ............................................................ 102
4.2.2 Autentificación ..................................................................................... 102
4.2.3 Encriptación ......................................................................................... 102
4.2.4 Seguimiento de acciones de usuario ................................................... 102
4.3 Costos ........................................................................................................ 102
4.3.1 Calculo del costo del sistema desarrollado .......................................... 103
CAPÍTULO V CONCLUCIONES Y RECOMENDACIONES ................................... 106
5.1 Conclusiones .............................................................................................. 106
5.2 Recomendaciones...................................................................................... 107
iii
CAPÍTULO I
MARCO INTRODUCTORIO
Este primer capítulo se enfocará en dar un panorama general del proyecto con la
introducción, el problema que pretendemos resolver, los objetivos que se cumplirán en
el desarrollo del proyecto, los motivos y los métodos que serán utilizados.
1.1 Introducción
La cantidad de información que se genera en las empresas crece de forma exponencial

y la necesidad de organizar la información es un factor importante para el éxito. Por
ello, las copias en papel están pasando a ocupar un segundo plano. Para organizar,
compartir y acelerar el flujo de trabajo de forma eficiente es necesario un sistema de
gestión de documentación.
Un sistema de gestión documental está diseñado para almacenar, administrar y

controlar el flujo de documentos dentro de una organización. Se trata de una forma de
organizar los documentos en una localización centralizada a la que los empleados
puedan acceder de forma fácil y sencilla.
Las empresas de software manejan documentación a nivel técnico (Manuales de

instalación, mockups, manuales técnicos, manuales de deploy, etc), a nivel comercial
(Manual de usuario, propuestas, control de mesas de apoyo, etc) y a nivel legal
(contratos). Además, estos documentos tienen clasificación de acuerdo a los roles
definidos en las empresas y por proyectos.
Por lo cual, el presente proyecto plantea la implementación y diseño de un sistema de

gestión de documentación de proyectos para la empresa Innovative Apps que tendrá
como función principal organizar la información de la empresa de acuerdo a sus
clasificaciones.
1.2 Antecedentes
Autores como Patricia Russo define que “Para implementar un sistema de gestión
documental en una organización tenemos que mirar la documentación en todos sus
estados, formatos y complejidad (…) El enfoque del SGD tiene que basarse en el
1
modelo de negocio de la organización y la incorporación de la documentación al
nuevo sistema tiene que plantearse desde su origen” (Russo. 2009).
Para tratadistas como Rhoads, la gestión de documentos se circunscribe a todo lo que

sucede a los documentos de una organización a través de su ciclo vital, desde su
nacimiento, pasando por su vida activa y productiva como medio para cumplir con las
funciones de la organización, hasta su destrucción. (Rhoads, 1995).
Considerando la temática que trata este proyecto se encontró proyectos similares en

la carrera de informática de la universidad Mayor de San Andrés, podemos mencionar
los siguientes:
“Modernización del centro de documentación para la dirección de planificación

y control”, que tiene como objetivo desarrollar e implementar un sistema informático
para la Modernización del Centro de Documentación, en la Dirección de Planificación
y Control del Gobierno Municipal de La Paz, a fin de proporcionarles una herramienta
que permita contar con procesos sistematizados, mediante el uso de metodologías y
herramientas de desarrollo de software orientada a objetos y que apoye al proceso de
toma de decisiones en la Unidad de Coordinación y Gestión de Proyectos. (Villca,
2006).
“Centro de documentación virtual caso: facultad de agronomía”, que tiene como

objetivo implementar un Centro de Documentación Virtual en la Facultad de Agronomía
perteneciente a la Universidad Mayor de San Andrés. (Ruiz, 2014).
“Sistema web de registro y control de documentación ambiental caso: dirección

de gestión y control ambiental”, que tiene como objetivo desarrollar un sistema web
de registro y control de la documentación ambiental de las Unidades Industriales, que
brinde datos fiables y ordenados al personal de la Dirección de Gestión y Control
Ambiental del Gobierno Autónomo Municipal de El Alto, que pueda ser modificado por
el personal de archivo. (Mujica, 2015).
2
1.3 Problemática
Actualmente la empresa Innovative Apps genera documentos en forma indiscriminada

sin que responda a una planeación, control y organización de los mismos conforme a
las funciones específicas que requiere. Por tanto, no existe una estructura definida
para la administración y gestión de documentos de forma sistematizada, por lo cual
existen diversos problemas como la pérdida de información, tiempo perdido en la
búsqueda de los documentos, deficiencia en la actualización de información, entre
otros.
1.3.1. Problema principal

De lo anterior se define el siguiente problema principal:
La falta de gestión de documentación de proyectos hace que los mismos no

puedan tener un avance adecuado.
1.3.2. Problemas secundarios

Se ha verificado los siguientes problemas secundarios:
 Al momento de asignar un proyecto nuevo o ya en proceso a un miembro del

equipo este no cuenta con toda la documentación requerida como mockups,
diagramas, versionamiento, manuales de instalación del proyecto y vistas de
progresos, lo cual retrasa el avance del proyecto.
 No se cuenta con un banco de información general como manuales de
instalación de las herramientas que se utilizan, métodos de documentación de
código, estructuras de proyectos y nomenclaturas usadas en la empresa, lo cual
hace que el código no esté uniformizado y retrasa la integración de nuevos
miembros del equipo.
 En el área legal de la empresa no se cuenta con la digitalización de los contratos
lo que genera que a veces trabajen con versiones físicas desactualizadas
llegando a entorpecer la renovación de los contratos y los cumplimientos
legales.
3
 Documentos extraviados, desactualizados o con ediciones digitales duplicadas,
lo que genera perdida de información y demora en encontrar los documentos.
 La unidad de seguimiento de proyectos no puede evaluar el avance del
proyecto.
1.4 Objetivo
Es importante crear una solución para centralizar la información de la empresa

organizado y eficiente, asignar la información necesaria a los miembros del equipo y
agilizar el proceso de adaptación a un proyecto recién asignado.
Para los administrativos llevar una vista general del progreso de los proyectos, tener
los documentos importantes del proyecto digitalizados y tener respaldado los
requerimientos de soporte de los proyectos.
1.4.1. Objetivo general

Desarrollar un sistema de gestión de documentación de proyectos para tener un
avance adecuado de los mismos.
1.4.2. Objetivos específicos

Los objetivos específicos son los siguientes:
 Determinar la bases teóricas y metodológicas acerca de la gestión de

documentos.
 Analizar el estado de los procesos y procedimientos en la gestión de
documentos en la empresa Innovative Apps.
 Desarrollar los módulos para el sistema.
 Evaluar la calidad y seguridad del software.
 Aplicar el sistema de gestión de documentación de proyectos en la empresa
Innovative Apps.
4
1.5 Justificación
La implementación de un sistema de gestión de documentación de proyectos para la

empresa Innovative Apps es de gran importancia porque reducirá el tiempo de
desarrollar un proyecto en la empresa.
Este sistema es una herramienta de apoyo para analizar la coherencia, continuidad y

productividad en los proyectos.
Facilitará el acceso a los documentos de una manera rápida y eficaz reduciendo la

intervención de recurso humano.
Según d’Alòs-Moner para asegurar la eficiencia de las organizaciones y su capacidad

innovadora y la plena integración de la información y la documentación en sus
procesos de actividad, es necesario que los documentos y sus contenidos estén:
 Accesibles, donde, cuándo y por quien sea necesario.

 Usables, de manera que además de accesibles sean interpretables para las
personas que deben hacer uso de ellos.
 Integrados, en función de las necesidades y requerimientos de la empresa y sus
trabajadores.
 Actualizados, según el desarrollo de la organización y su producción
documental, para garantizar su permanente vigencia. (D’ALÒS-MONER, 2011).
1.6 Metodología
El desarrollo de este proyecto se realizará con la metodología XP porque es óptimo

para equipos pequeños además que es una metodología ágil y para el análisis y diseño
se utilizará UML (Unified Modeling Language).
Se realizará el diseño del proyecto en tres capas:
 Interfaz de usuario tomando como herramienta React.

 Interfaz de aplicación tomando como herramienta Spring Boot.
 Interfaz de base de datos tomando como herramienta Mysql.
5
De acuerdo con Roger Pressman, las etapas metodológicas a llevar a cabo para el
desarrollo de Sistemas de Información, consta de 5 fases y se establecen de la
siguiente manera:
 Toma de datos, tiene como objetivos buscar, investigar y ayudar a los usuarios
a documentar sus necesidades deberá hacerse siempre usando el lenguaje
natural.
 Análisis de requisitos, tiene como objetivo principal detectar conflictos en los

requisitos obtenidos.
 Diseño, el diseño del software es realmente un proceso de muchos pasos pero
que se clasifican dentro de uno mismo. En general, la actividad del diseño se
refiere al establecimiento de las estructuras de datos, la arquitectura general del
software, representaciones de interfaz y algoritmos. El proceso de diseño
traduce requisitos en una representación de software.
 Generación de código, esta actividad consiste en traducir el diseño, en una
forma legible por la máquina. La generación de código se refiere tanto a la parte
de generación de los ambientes virtuales, como a la parte en la cual se añadirá
comportamiento a estos ambientes.
 Evaluación del producto, una vez que se ha generado código, comienzan las
pruebas del software o sistema que se ha desarrollado. De acuerdo con
Pressman, el proceso de pruebas se centra en los procesos lógicos internos del
software, asegurando que todas las sentencias se han comprobado, y en los
procesos externos funcionales, es decir, la realización de las pruebas para la
detección de errores.
 Calidad y seguridad, es la concordancia con los requisitos funcionales y de
rendimiento explícitamente establecidos con los estándares de desarrollo
plenamente documentados y con las características implícitas que se espera de
todo software desarrollado profesionalmente.
 Mantenimiento, El software indudablemente sufrirá cambios, y habrá que hacer

algunas modificaciones a su funcionalidad. Es de suma importancia que el
6
software de calidad pueda adaptarse con fines de acoplarse a los cambios de
su entorno externo.
1.7 Aporte
El aporte del proyecto es el uso de SOLID en el desarrollo del sistema.
1.8 Cronograma de acción
La Tabla 1.1 se define el cronograma de acción
Tabla 1.1 Cronograma de acción
Actividad Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6

Diseño de diagramas UML
Diseño de base de datos

Diseño de interfaces
Diseños de clases
Desarrollo y consumo de
api rest de Modulo de
usuario
documentos
asignación de
documentos
Desarrollo del canal de
comunicación
Fuente: Elaboración propia
7
CAPÍTULO II
MARCO TEÓRICO
En el presente capítulo detallamos los conceptos y definiciones que se necesitan en el

desarrollo del proyecto.
2.1 Antecedentes de la empresa Innovative Apps
Innovative Apps S.R.L. es una empresa orientada a satisfacer las necesidades

tecnológicas de sus clientes. Sus servicios se basan en el software a medida y
consultoría tecnológica.
2.1.1 Proyectos
Los proyectos en la empresa Innovative Apps son para la creación, actualización
y consultoría de sistemas informáticos, para empresas externas o creaciones
propias.
En los proyectos trabajan los gerentes de la empresa, los gerentes de ventas, los
desarrolladores del área de backend, frontend y mobile, diseñadores gráficos y
testers. La distribución del personal es variable y pueden trabajar en múltiples
proyectos en paralelo, además en algunos proyectos puede participar un consultor
externo.
El ciclo de vida de la documentación de un proyecto es la siguiente:
 Cada proyecto es documentado desde la propuesta con un informe para el

futuro cliente y en algunos casos una presentación.
 Si la propuesta es aceptada se trabaja con la toma de requerimientos.
 Al concluir los requerimientos se realiza un contrato.
 En base a los requerimientos se diseña uno o más opciones de diseño con
mockups.
 Además, se trabaja en el diseño inicial de la base de datos.
 En el transcurso del avance del proyecto se va documentando los APIS de
los cuales requirieron una documentación extensa, los cuales incluyen los
diccionarios de datos.
8
 Se documentan las pruebas que se realizaron en los sprints o itereaciones.
 Se van realizando los manuales técnicos.
 Al finalizar se realizan los manuales de usuario, en algunos casos se
realizan presentaciones y videos del sistema.
Además, la empresa tiene documentos guía de instalación de las herramientas

con las versiones que se utilizan en la empresa. También guías de despliegue
de los sistemas y guías de nomenclatura para el desarrollo en los diferentes
lenguajes de programación que manejan.
2.2 Gestión de documentos
Las organizaciones necesitan una forma eficiente de ejercer control de documentos en

los Sistemas de Gestión, de manera que los empleados trabajen con un sistema
centralizado y controlado, al que tengan acceso, pudiendo así contar con la
información que necesitan cuando la requieran. Para explicar mejor la gestión de
documentos tomaremos en cuenta las bases teóricas y las bases metodológicas.
2.2.1. Bases teóricas

Para explicar lo que es Gestión de Documentos o Gestión Documental
partiremos de la definición presentada por Elisa García-Morales que nos dice:
“... es la parte del sistema de información de la empresa desarrollada con el
propósito de almacenar y recuperar documentos, que debe estar diseñada para
coordinar y controlar todas aquellas funciones y actividades específicas que
afectan a la creación, recepción, almacenamiento, acceso y preservación de los
documentos, salvaguardando sus características estructurales, y contextuales,
y garantizando su autenticidad y veracidad.
Gran parte de los profesionales suelen confundir la Gestión Documental con la

aplicación de las últimas tecnologías al manejo de la información, cuando
realmente esto es sólo un aspecto complementario. Esto lo ilustra mejor Elisa
García-Morales al indicar que “... cuando se parte de la premisa de que tratamos
la gestión documental como un simple conjunto de herramientas tecnológicas
que permiten trabajar, producir y acceder mejor a los documentos, se está
9
obviando todo el componente organizativo y funcional del sistema. Este es el
que permite sentar las bases para que todos esos documentos, sean un
conjunto coherente que de respuesta a las necesidades de la empresa a corto,
mediano y largo plazo.
Desde el punto de vista de Ricardo García y Bonifacio Martín “en la actualidad

la gestión documental es entendida como un proceso global, corporativo e
integral del proceso documental de una organización. Es por ello más acertado
hablar de Sistemas de Gestión de la Documentación, los cuales controlan la
producción, la circulación, el almacenamiento y la recuperación de cualquier tipo
de información.
2.2.2. Bases metodológicas
Para las bases metodológicas usaremos algunas normas ISO sobre gestión de
documentos. Las normas ISO son pautas estándares internacionales para
optimizar los procesos comerciales, son documentos técnicos de aplicación
voluntaria, y, por lo tanto, no son vinculantes como una ley.
 ISO 15489 - Información y documentación: Gestión de documentos.

- La norma propone una metodología específica para diseñar e
implementar el sistema de gestión de documentos, definir los procesos
técnicos y elaborar los instrumentos principales. También destaca la
importancia de los metadatos para la gestión de los documentos
electrónicos y señala los requisitos que éstos deberían cumplir.
 ISO 16175 - Información y documentación. Principios y requisitos
funcionales para documentos en entornos de oficina electrónica. -
Como la gestión de los documentos electrónicos sólo se puede realizar
mediante un software, cabe trasladar el modelo de gestión manual a
unos requerimientos que debe cumplir el software para gestionar los
documentos electrónicos producidos por organizaciones o personas en
el desarrollo de su actividad, asegurando su integridad, autenticidad y
validez a lo largo del tiempo, y que puedan ser recuperados cuando sea
necesario.
10
 ISO 23081 - Gestión de documentos. Metadatos para la gestión de
documentos. - Se centra en el marco necesario para definir elementos
de metadatos para la gestión de documentos y ofrece unas directrices
genéricas sobre ellos, independientemente de que se trate de
documentos físicos, analógicos o digitales. Presenta una aproximación
lógica a los metadatos para la gestión de documentos en las
organizaciones, modelos conceptuales de metadatos y una visión
general del conjunto de los distintos tipos de elementos de metadatos
válidos para cualquier entorno de gestión de documentos.
2.3 Ingeniería de software
Una de las primeras definiciones fue hecha por Fritz Bauer en 1969: “Ingeniería de
Software es el establecimiento y uso de principios robustos de ingeniería, orientados
a obtener software que sea fiable y funcione de manera eficiente sobre máquinas
reales”.
Los métodos de la ingeniería de software proporcionan la experiencia técnica para

elaborar software. Incluyen un conjunto amplio de tareas, como comunicación, análisis
de los requerimientos, modelación del diseño, construcción del programa, pruebas y
apoyo. Los métodos de la ingeniería de software se basan en un conjunto de principios
fundamentales que gobiernan cada área de la tecnología e incluyen actividades de
modelación y otras técnicas descriptivas (Pressman, 2010).
La ingeniería de software busca encontrar mejores medios para construir software. Los
medios tradicionales de construcción son, por lo general, costosos, y generan
productos ineficientes y equivocados. Los nuevos medios de construcción deben ser
más confiables, predecibles y capaces de entregar productos económicos y
funcionales.
2.4 Metodologías de programación
Inicialmente, es importante conocer la definición de metodología y desarrollo.

Metodología es una palabra compuesta por tres vocablos griegos: metá (“más allá”),
11
odós (“camino”) y logos (“estudio”); considerando lo anterior, la definición de
metodología son los métodos para luego determinar cuál es el más adecuado.
Una Metodología de desarrollo de software, consiste principalmente en hacer uso de

diversas herramientas, técnicas, métodos y modelos para el desarrollo. Regularmente
este tipo de metodología, tienen la necesidad de venir documentadas, para que los
programadores que estarán dentro de la planeación del proyecto, comprendan
perfectamente la metodología y en algunos casos el ciclo de vida del software que se
pretende seguir.
De acuerdo con Pressman (2010), las metodologías de programación clásicas son

llamadas también modelos de proceso prescriptivo, y fueron propuestas originalmente
para poner orden en el caos del desarrollo de software que existía cuando se empezó
a generar masivamente. La historia indica que estos modelos tradicionales, propuestos
en la década del 60, han dado cierta estructura útil al trabajo de IS y constituyen un
mapa razonablemente eficaz para los equipos de software.
En los años finales del siglo XX se publicaron centeneres de artículos y libros que
proponían distintas metodologías, técnicas y notaciones para el desarrollo orientado al
objeto. En cuanto al proceso de desarrollo de software, se distinguen tres grandes
corrientes.
Metodologías dirigidas por los datos (data- driven), que se basan en la parte estructural
de los objetos y son una extensión del modelo conceptual en el modelo
Entidad/Relación.
Metodologías dirigidas por las responsabilidades (responsability-driven), que

representan el enfoque más purista de la orientación al objeto centrándose en las
“responsabilidades” de los objetos, esto es, las acciones que puede llevar a cabo un
objeto.
Proceso de unificado de desarrollo de software (USDP Unified Software Develpment

Process): se deriva de la metodología Objectory, de Jacobson; la metodología de
Booch; y la técnica de modelado de objetos, de Rumbaugh. (Piattini, 2000).
12
Metodologías ágiles, las empresas operan en un entorno global que cambia
rápidamente; en ese sentido, deben responder a nuevas oportunidades y mercados,
al cambio de las condiciones económicas así, como al surgimiento de productos y
servicios nuevos y competitivos. Para ello es necesario emplear computadoras y
dispositivos computacionales, por lo que el software es partícipe de casi todas las
operaciones empresariales, de modo que debe desarrollarse de manera ágil para
responder con oportunidad y calidad a todo lo necesario.
2.5 Programación extrema
La Programación Extrema (XP) es posiblemente el método ágil más conocido y

ampliamente utilizado. La Programación Extrema abarca un conjunto de reglas y
prácticas que ocurren en el contexto de cuatro actividades del marco de trabajo
(Pressman, 2010).
2.5.1 Roles XP
Describiremos los roles de acuerdo con la propuesta original de Beck.
 Programador, produce el código del sistema. Debe existir una

comunicación y coordinación adecuada entre los programadores y otros
miembros del equipo.
 Cliente, escribe las historias de usuario y las pruebas funcionales para
validar su implementación. Además, asigna la prioridad a las historias de
usuario y decide cuáles se implementan en cada iteración centrándose en
aportar mayor valor al negocio. El cliente es sólo uno dentro del proyecto,
pero puede corresponder a un interlocutor que está representando a varias
personas que se verán afectadas por el sistema.
 Encargado de pruebas (Tester), ejecuta las pruebas regularmente,
difunde los resultados en el equipo y es responsable de las herramientas
de soporte para pruebas.
 Encargado de seguimiento (Tracker), proporciona realimentación al
equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto
entre las estimaciones realizadas y el tiempo real dedicado, comunicando
13
los resultados para mejorar futuras estimaciones. También realiza el
seguimiento del progreso de cada iteración y evalúa si los objetivos son
alcanzables con las restricciones de tiempo y recursos presentes.
Determina cuándo es necesario realizar algún cambio para lograr los
objetivos de cada iteración.
 Entrenador (Coach), es responsable del proceso global. Es necesario que
conozca a fondo el proceso XP para proveer guías a los miembros del
equipo de forma que se apliquen las prácticas XP y se siga el proceso
correctamente.
 Consultor, es un miembro externo del equipo con un conocimiento
específico en algún tema necesario para el proyecto. Guía al equipo para
resolver un problema específico.
 Gestor (Big boss), es el vínculo entre clientes y programadores, ayuda a
que el equipo trabaje efectivamente creando las condiciones adecuadas.
Su labor esencial es de coordinación.
2.5.2 Fases
El ciclo de vida ideal de XP consiste de cinco fases:
 Fase I: Exploración. En esta fase, los clientes plantean a grandes rasgos

las historias de usuario que son de interés para la primera entrega del
producto. Al mismo tiempo el equipo de desarrollo se familiariza con las
herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se
prueba la tecnología y se exploran las posibilidades de la arquitectura del
sistema construyendo un prototipo. La fase de exploración toma de pocas
semanas a pocos meses, dependiendo del tamaño y familiaridad que
tengan los programadores con la tecnología.
 Fase II: Planificación de la Entrega. En esta fase el cliente establece la
prioridad de cada historia de usuario, y correspondientemente, los
programadores realizan una estimación del esfuerzo necesario de cada una
de ellas. Se toman acuerdos sobre el contenido de la primera entrega y se
determina un cronograma en conjunto con el cliente. Una entrega debería
14
obtenerse en no más de tres meses. Esta fase dura unos pocos días. Las
estimaciones de esfuerzo asociado a la implementación de las historias la
establecen los programadores utilizando como medida el punto.
 Fase III: Iteraciones. Esta fase incluye varias iteraciones sobre el sistema
antes de ser entregado. El Plan de Entrega está compuesto por iteraciones
de no más de tres semanas. El cliente quien decide qué historias se
implementarán en cada iteración (para maximizar el valor de negocio). Al
final de la última iteración el sistema estará listo para entrar en producción.
En esta fase se hace el diseño que se lo hará con los diagramas UML y se
hace la codificación.
 Fase IV: Pruebas. Una de las características de la metodología XP es el
cambio constante, por eso cuando el código de una función está listo se
somete a una serie de pruebas unitarias continuas, con el objetivo de
corregir fallas periódicamente.
XP trabaja con tiempos relativamente cortos, por lo que el control
automatizado y constante es muy importante.
Muchas veces, es el propio cliente quien cumple las funciones de Tester
cuando tiene conocimientos de programación (se recomienda que sea así
para que sus apreciaciones sean realmente válidas para el equipo).
2.6 Lenguaje unificado de modelado
UML es un lenguaje de modelado orientado a objetos que permite representar

gráficamente los elementos estáticos y dinámicos de una aplicación software (Booch
et al., 2005; Pressman, 2010).
UML permite una modelación de los componentes estáticos de una aplicación software
(diagramas de casos de uso, diagramas de clases), así como del comportamiento
dinámico de sus principales elementos durante su funcionamiento (entre ellos
diagramas de estados y diagramas de secuencias). Los diagramas de estados
permiten la modelación de los principales estados y los eventos que ocasionan sus
cambios para una instancia de una clase, o para un sistema como un todo, mientras
que los diagramas de secuencias permiten modelar instancias de interacción entre
15
actores u objetos de clases de un sistema a través de mensajes. Mediante estos
últimos diagramas es posible conocer lo que ocurre internamente entre los actores e
instancias de clases que participan en un diagrama de estados de un sistema de
software. Según Booch et al. (2005), los diagramas de secuencias UML constituyen
elementos relevantes en el desarrollo de una aplicación software.
2.6.1 Diagramas de casos de uso
Un caso de uso es una descripción de las acciones de un sistema desde el punto

de vista del usuario. Es una herramienta valiosa dado que es una técnica de
aciertos y errores para obtener los requerimientos del sistema, justamente desde
el punto de vista del usuario.
Los diagramas de caso de uso modelan la funcionalidad del sistema usando

actores y casos de uso. Los casos de uso son servicios o funciones provistas por
el sistema para sus usuarios.
En la figura 2.1 tenemos un ejemplo de como son los símbolos de los diagramas
de casos de uso, el rectángulo representa los límites del sistema que contiene los
casos de uso. Los actores se ubican fuera de los límites del sistema, los casos de
uso se representan con óvalos. La etiqueta en el óvalo indica la función del sistema
y siempre contiene los símbolos del actor y del caso de uso, junto con líneas
conectoras. Los actores son similares a las entidades externas; existen fuera del
sistema. El término actor se refiere a un rol específico de un usuario del sistema
Figura 2.1 Símbolos de los casos de uso.

Fuente: Elaboración propia.
16
2.6.2 Diagramas de actividad
Un diagrama de actividades ilustra la naturaleza dinámica de un sistema mediante

el modelado del flujo ocurrente de actividad en actividad. Una actividad representa
una operación en alguna clase del sistema y que resulta en un cambio en el estado
del sistema. Típicamente, los diagramas de actividad son utilizados para modelar
el flujo de trabajo interno de una operación.
Una actividad es la especificación de una secuencia parametrizada de

comportamiento. Una actividad muestra un rectángulo con las puntas
redondeadas adjuntando todas las acciones, flujos de control y otros elementos
que constituyen la actividad. Una acción representa un solo paso dentro de una
actividad. Las acciones se denotan por rectángulos con las puntas redondeadas.
Un nodo inicial o de comienzo se describe por un gran punto negro, como se
muestra a continuación. El nodo final de flujo se describe como un círculo con otro
circulo sobre puesto.
Las bifurcaciones y uniones tienen la misma notación: tanto una barra horizontal
como vertical (la orientación depende de si el flujo de control va de derecha a
izquierda o hacia abajo y arriba. Estos indican el comienzo y final de hilos actuales
de control. En la figura 2.2 especificamos los símbolos en un diagrama de
actividad.
Figura 2.2 Símbolos de los diagramas de actividad.

17
2.6.3 Diagramas de secuencia
Un diagrama de secuencias muestra la interacción de un conjunto de objetos de

una aplicación a través del tiempo, en el cual se indicarán los módulos o clases
que formaran parte del programa y las llamadas que se hacen cada uno de ellos
para realizar una tarea determinada, por esta razón permite observar la
perspectiva cronológica de las interacciones. Es importante recordar que el
diagrama de secuencias se realiza a partir de la descripción de un caso de uso.
2.6.4 Diagramas de clases
aporta una visión estática o de estructura de un sistema, sin mostrar la naturaleza

dinámica de las comunicaciones entre los objetos de las clases.
Los elementos principales de un diagrama de clase son cajas, que son los íconos
utilizados para representar clases e interfaces. Cada caja se divide en partes
horizontales. La parte superior contiene el nombre de la clase. La sección media
menciona sus atributos. Un atributo es algo que un objeto de dicha clase conoce
o puede proporcionar todo el tiempo. Por lo general, los atributos se implementan
como campos de la clase, pero no necesitan serlo. Podrían ser valores que la clase
puede calcular a partir de sus variables o valores instancia y que puede obtener
de otros objetos de los cuales está compuesto. Pressman (2010)
Una clase abstracta o un método abstracto se indica con el uso de cursivas en el

nombre del diagrama de clase. Los diagramas de clase también pueden mostrar
relaciones entre clases. Una clase que sea una subclase de otra clase se conecta
con ella mediante una flecha con una línea sólida y con una punta triangular hueca.
2.6.5 Modelos de navegación
Su finalidad es definir cómo se le brindará a cada usuario del sistema el acceso a

la información y la funcionalidad que le es relevante para llevar a cabo su labor
dentro del sistema y qué secuencias de caminos deberán seguir para conseguirlo.
18
El Modelo de Navegación, establece la semántica navegacional ligada a las clases
de los objetos del modelo. En éste modelo es donde se deja explicita la navegación
permitida en la aplicación por cada agente del sistema.
Un esquema navegacional es una unidad de interacción abstracta que ilustra una

vista sobre un grupo de datos y/o servicios accesibles para un usuario en un
momento determinado. Es una unidad debido a que proporciona el elemento lógico
básico de creación de la navegación aceptada en los modelos navegacionales de
interacción ya que representa un contacto con el usuario y abstracta ya que sólo
se establecen qué datos o servicios se plasmaran en el contexto, pero no define
cual será la forma de presentación.
2.7 Herramientas de desarrollo
A continuación, se detallarán los conceptos de las herramientas que se utilizó en el

desarrollo de este proyecto.
2.7.1 Java Spring Boot

Para entender el concepto de Spring Boot primero debemos tener el concepto de
que es Spring Framework. Escrito inicialmente por Rod Johnson, fue lanzado por
primera vez en el mes de junio del año 2003 bajo la licencia Apache 2.0, siendo
una plataforma Java de código abierto. Convirtiéndose desde entonces en el
framework más popular para Java empresarial, para crear código de alto
rendimiento, liviano y reutilizable. Ya que su finalidad es estandarizar, agilizar,
manejar y resolver los problemas que puedan ir surgiendo en el trayecto de la
programación.
Spring, ofrece como elemento clave el soporte de infraestructura a nivel de

aplicación, brindando un completo modelo tanto para la configuración como para
la programación de aplicaciones empresariales desarrolladas bajo Java, sin
discriminación en cuanto al despliegue de la plataforma.
Todo esto trae consigo una gran ventaja, ya que permite que los equipos de
desarrollo puedan enfocarse directamente en la lógica empresarial que requiere la
19
aplicación, haciendo el proceso más corto, rápido y eficaz, ahorrando líneas de
código evitando tareas repetitivas.
Spring se puede considerar como el padre de los frameworks Java, ya que da

soporte a varios frameworks como: Hibernate, Struts, Tapestry, EJB, JSF, entre
otros.
Si bien es cierto que Spring Framework es muy potente, la configuración inicial y

la preparación de las aplicaciones para producción son tareas bastante tediosas.
Spring Boot simplifica el proceso al máximo gracias a sus dos principales
mecanismos.
 Contenedor de aplicaciones integrado: Spring Boot permite compilar

nuestras aplicaciones Web como un archivo .jar que podemos ejecutar
como una aplicación Java normal (como alternativa a un archivo .war, que
desplegaríamos en un servidor de aplicaciones como Tomcat). Esto lo
consigue integrando el servidor de aplicaciones en el propio .jar y
levantándolo cuando arrancamos la aplicación. De esta forma, podemos
distribuir nuestras aplicaciones de una forma mucho más sencilla, al poder
configurar el servidor junto con la aplicación. Esto también es muy útil en
arquitecturas de microservicios, puesto que permite distribuir nuestras
aplicaciones como imágenes Docker que podemos escalar
horizontalmente.
 Starters: Spring Boot nos proporciona una serie de dependencias,
llamadas starters, que podemos añadir a nuestro proyecto dependiendo de
lo que necesitemos: crear un controlador REST, acceder a una base de
datos usando JDBC, conectar con una cola de mensajes Apache ActiveMQ,
etc.
Una vez añadimos un starter, éste nos proporciona todas las dependencias
que necesitamos, tanto de Spring como de terceros. Además, los starters
vienen configurados con valores por defecto, que pretenden minimizar la
necesidad de configuración a la hora de desarrollar.
20
Al igual que con Spring Framework, cualquier configuración puede ser modificada
de ser necesario: desde el puerto en el que la aplicación escucha peticiones, hasta
el banner que sale por consola al arrancar la aplicación.
2.7.2 React
React es una librería de JavaScript declarativa, eficiente y flexible para construir

interfaces de usuario. Permite componer IUs complejas de pequeñas y aisladas
piezas de código llamadas “componentes”. Ayuda a crear interfaces de usuario
interactivas de forma sencilla. Diseña vistas simples para cada estado en tu
aplicación, y React se encargará de actualizar y renderizar de manera eficiente los
componentes correctos cuando los datos cambien.
Las vistas declarativas hacen que el código sea más predecible, por lo tanto, fácil
de depurar.
React ha sido diseñado desde su inicio para ser adoptado gradualmente, así
puedes usar tan poco o mucho de React como se requiera. Si quieres una prueba
de React, agregar interactividad a una simple página HTML o empezar una
aplicación compleja con React.
2.7.3 MySql
MySQL es un sistema de gestión de bases de datos relacional desarrollado bajo

una licencia dual: licencia pública general y licencia comercial por Oracle
Corporation y está considerada como la base de datos de código abierto más
popular del mundo y una de las más populares en general junto a Oracle y
Microsoft SQL Server, todo para entornos de desarrollo web. Está desarrollado en
su mayor parte en ANSI C y C++.
MySQL fue inicialmente desarrollado por MySQL AB. MySQL AB fue adquirida por
Sun Microsystems en 2008, y ésta a su vez fue comprada por Oracle Corporation
en 2010, la cual ya era dueña desde 2005 de Innobase Oy, empresa finlandesa
desarrolladora del motor InnoDB para MySQL.
21
Al contrario de proyectos como Apache, donde el software es desarrollado por una
comunidad pública y los derechos de autor del código están en poder del autor
individual, MySQL es patrocinado por una empresa privada, que posee el copyright
de la mayor parte del código. Esto es lo que posibilita el esquema de doble
licenciamiento anteriormente mencionado. La base de datos se distribuye en
varias versiones, una Community, distribuida bajo la Licencia pública general de
GNU, versión 2, y varias versiones Enterprise, para aquellas empresas que
quieran incorporarlo en productos privativos. Las versiones Enterprise incluyen
productos o servicios adicionales tales como herramientas de monitorización y
asistencia técnica oficial. En 2009 se creó un fork denominado MariaDB por
algunos desarrolladores descontentos con el modelo de desarrollo y el hecho de
que una misma empresa controle a la vez los productos MySQL y Oracle
Database.
MySQL es usado por muchos sitios web grandes y populares, como Wikipedia,
Google (aunque no para búsquedas), Facebook, Twitter, Flickr y YouTube.
2.8 Calidad de software
Según Pressman la calidad del diseño se refiere a las características que los
diseñadores especifican para un producto. El tipo de materiales, tolerancias y
especificaciones del desempeño, todo contribuye a la calidad del diseño. Si se utilizan
mejores materiales, tolerancias más estrictas y se especifican mayores niveles de
desempeño, la calidad del diseño de un producto se incrementa si se fabrica de
acuerdo con las especificaciones.
En el desarrollo del software, la calidad del diseño incluye el grado en el que el diseño
cumple las funciones y características especificadas en el modelo de requerimientos.
La calidad de la conformidad se centra en el grado en el que la implementación se
apega al diseño y en el que el sistema resultante cumple sus metas de requerimientos
y desempeño.
2.8.1 ISO 9126
22
El estándar ISO 9126 se desarrolló con la intención de identificar los atributos clave
del software de cómputo. Este sistema identifica seis atributos clave de la calidad:
 Funcionalidad. Grado en el que el software satisface las necesidades

planteadas según las establecen los atributos siguientes: adaptabilidad,
exactitud, interoperabilidad, cumplimiento y seguridad.
 Confiabilidad. Cantidad de tiempo que el software se encuentra disponible
para su uso, según lo indican los siguientes atributos: madurez, tolerancia a
fallas y recuperación.
 Usabilidad. Grado en el que el software es fácil de usar, según lo indican los
siguientes subatributos: entendible, aprendible y operable.
 Eficiencia. Grado en el que el software emplea óptimamente los recursos del
sistema, según lo indican los subatributos siguientes: comportamiento del
tiempo y de los recursos.
 Facilidad de recibir mantenimiento. Facilidad con la que pueden efectuarse
reparaciones al software, según lo indican los atributos que siguen:
analizable, cambiable, estable, susceptible de someterse a pruebas.
 Portabilidad. Facilidad con la que el software puede llevarse de un ambiente
a otro según lo indican los siguientes atributos: adaptable, instalable,
conformidad y sustituible.
Igual que otros factores de la calidad del software estudiados en las subsecciones
anteriores, los factores ISO 9126 no necesariamente conducen a una medición
directa. Sin embargo, proporcionan una base útil para hacer mediciones indirectas
y una lista de comprobación excelente para evaluar la calidad del sistema.
Pressman (2010).
2.8.2 Métrica punto de función
La métrica de punto de función (PF) puede usarse de manera efectiva como medio
para medir la funcionalidad que entra a un sistema.
Los puntos de función se derivan usando una relación empírica basada en

medidas contables (directas) del dominio de información del software y en
23
valoraciones cualitativas de la complejidad del software. Los valores de dominio
de información se definen en la forma siguiente:
 Número de entradas externas (EE). Cada entrada externa se origina de un

usuario o se transmite desde otra aplicación, y proporciona distintos datos
orientados a aplicación o información de control. Con frecuencia, las
entradas se usan para actualizar archivos lógicos internos (ALI). Las
entradas deben distinguirse de las consultas, que se cuentan por separado.
 Número de salidas externas (SE). Cada salida externa es datos derivados
dentro de la aplicación que ofrecen información al usuario. En este contexto,
salida externa se refiere a reportes, pantallas, mensajes de error, etc. Los
ítems de datos individuales dentro de un reporte no se cuentan por
separado.
 Número de consultas externas (CE). Una consulta externa se define como
una entrada en línea que da como resultado la generación de alguna
respuesta de software inmediata en la forma de una salida en línea (con
frecuencia recuperada de un ALI).
 Número de archivos lógicos internos (ALI). Cada archivo lógico interno es
un agrupamiento lógico de datos que reside dentro de la frontera de la
aplicación y se mantiene mediante entradas externas.
 Número de archivos de interfaz externos (AIE). Cada archivo de interfaz
externo es un agrupamiento lógico de datos que reside fuera de la
aplicación, pero que proporciona información que puede usar la aplicación.
Una vez recolectados los datos anteriores la tabla de la Figura 2.3 se completa y
un valor de complejidad se asocia a cada conteo. Una vez que hemos asignado
los valores a cada uno de los componentes, obtendremos un resultado parcial de
la medición si sumamos todos ellos, de forma independiente para transacciones
lógicas y para ficheros lógicos. El valor que obtenemos es aún un valor no
ajustado, es decir, falta determinar el factor de ajuste (VAF) por el que se ha de
multiplicar el valor no ajustado.
24
Figura 2.3 Punto función.
Fuente: Pressman 2010.
Se utiliza la siguiente fórmula para obtener el valor de los valores de ajuste de valor
(FAV):
FAV = 0.65 + 0.01 * ∑(Fi )
Los Fi (i = 1 a 14) son factores de ajuste de valor.
El FAV puede variar entre 0.65 y entre 1.35, el valor 0.65 del VAF se utiliza como
factor corrector del conteo total de Puntos Función.
El valor 0.01 es el error mínimo aceptable al de la complejidad.
La ecuación para el punto función es la siguiente:
PF = conteo total * FAV

PF = conteo total * [0.65 + 0.01 * ∑(Fi )]
El conteo total es el número total de puntos función sin ajustar obtenidos del
resultado de la tabla de la Figura 2.3 y utilizando la ecuación FAV como corrector.
Los Fi (i = 1 a 14) son factores de ajuste de valor (FAV) con base en respuestas a
las siguientes preguntas:
1. ¿El sistema requiere respaldo y recuperación confiables?
2. ¿Se requieren comunicaciones de datos especializadas para transferir

información hacia o desde la aplicación?
3. ¿Existen funciones de procesamiento distribuidas?
25
4. ¿El desempeño es crucial?
5. ¿El sistema correrá en un entorno operativo existente enormemente utilizado?
6. ¿El sistema requiere entrada de datos en línea?
7. ¿La entrada de datos en línea requiere que la transacción de entrada se
construya sobre múltiples pantallas u operaciones?
8. ¿Los ALI se actualizan en línea?
9. ¿Las entradas, salidas, archivos o consultas son complejos?
10. ¿El procesamiento interno es complejo?
11. ¿El código se diseña para ser reutilizable?
12. ¿La conversión y la instalación se incluyen en el diseño?
13. ¿El sistema se diseña para instalaciones múltiples en diferentes
organizaciones?
14. ¿La aplicación se diseña para facilitar el cambio y su uso por parte del usuario?
Cada una de estas preguntas se responde usando una escala que varía de 0 (no
importante o aplicable) a 5 (absolutamente esencial). Los valores constantes en la
ecuación y los factores ponderados que se aplican a los conteos de dominio de
información se determinan de manera empírica.
2.8.3 Escala de valoración
De Vellis (en García, 2005), plantea la siguiente escala de valoración de

confiabilidad:
 Por debajo de .60 es inaceptable.

 De .60 a .65 es indeseable.
 Entre .65 y .70 es mínimamente aceptable.
 De .70 a .80 es respetable.
 De .80 a .99 es muy buena.
2.8.4 Incidencias o no conformidades
A través de la ejecución de los test para calcular la eficiencia son generadas las
incidencias o No Conformidades, las cuales se han clasificado en diferentes
categorías, ellos son:
26
 Tiempos de Respuesta: Actualmente Google considera que el tiempo de
respuesta del servidor, debe estar por debajo de los 200 milisegundos (0.2
segundos). No obstante, un tiempo de respuesta hasta 500 ms, es
aceptable.
 Concurrencia de Usuarios.
 Errores HTTP: Los códigos HTTP describen el estado de un URL cuando
un visitante intenta accederlo. Esto incluye mensajes de error que aparecen
cuando un visitante encuentra problemas en un sitio web. Los códigos son
números de tres dígitos. Hay cinco clases de códigos HTTP de error. El
primer dígito determina su categoría.
2.9 Principios S.O.L.I.D.
SOLID es el acrónimo que acuñó Michael Feathers, basándose en los principios de la

programación orientada a objetos que Robert C. Martin había recopilado en el año
2000 en su paper “Design Principles and Design Patterns”. Representa cinco principios
básicos de la programación orientada a objetos y el diseño. Cuando estos principios
se aplican en conjunto es más probable que un desarrollador cree un sistema que sea
fácil de mantener y ampliar con el tiempo. Los principios SOLID son guías que pueden
ser aplicadas en el desarrollo de software para eliminar malos diseños provocando que
el programador tenga que refactorizar el código fuente hasta que sea legible y
extensible. Puede ser utilizado con el desarrollo guiado por pruebas.
 Principio de Responsabilidad Única: La S del acrónimo del que hablamos

hoy se refiere a Single Responsibility Principle (SRP). Según este principio “una
clase debería tener una, y solo una, razón para cambiar”.
El principio de Responsabilidad Única es el más importante y fundamental de
SOLID, muy sencillo de explicar, pero el más difícil de seguir en la práctica.
 Principio de Abierto/Cerrado: El segundo principio de SOLID lo formuló
Bertrand Meyer en 1988 en su libro “Object Oriented Software Construction” y
dice: “Deberías ser capaz de extender el comportamiento de una clase, sin
modificarla”. En otras palabras: las clases que usas deberían estar abiertas para
poder extenderse y cerradas para modificarse.
27
 Principio de Sustitución de Liskov: La L de SOLID alude al apellido de quien
lo creó, Barbara Liskov, y dice que “las clases derivadas deben poder sustituirse
por sus clases base”.
Esto significa que los objetos deben poder ser reemplazados por instancias de
sus subtipos sin alterar el correcto funcionamiento del sistema o lo que es lo
mismo: si en un programa utilizamos cierta clase, deberíamos poder usar
cualquiera de sus subclases sin interferir en la funcionalidad del programa.
 Principio de Segregación de la Interfaz: En el cuarto principio de SOLID se
sugiere: “Haz interfaces que sean específicas para un tipo de cliente”, es decir,
para una finalidad concreta.
En este sentido, según el Interface Segregation Principle (ISP), es preferible
contar con muchas interfaces que definan pocos métodos que tener una
interface forzada a implementar muchos métodos a los que no dará uso.
 Principio de Inversión de Dependencias: En el último principio se sugiere
“Depende de abstracciones, no de clases concretas”.
Los módulos de alto nivel no deberían depender de módulos de bajo nivel.
Ambos deberían depender de abstracciones.
Las abstracciones no deberían depender de los detalles. Los detalles deberían
depender de las abstracciones.
2.10 Arquitectura en capas
La arquitectura en capas o Layered Architecture es el patrón de arquitectura más

común. Este patrón es el estándar para la mayoría de las aplicaciones de Java EE, por
lo cual es ampliamente conocido.
Los componentes de este patrón se organizan en capas horizontales, cada capa

desempeña un papel específico dentro de la aplicación. Aunque el patrón de
arquitectura en capas no especifica el número y los tipos de capas que deben existir,
la mayoría de constan de cuatro capas estándar: presentación, negocio, persistencia
y base de datos.
28
Una de las principales características de este patrón es la separación de
preocupaciones (SoC Separation of concerns) entre los componentes. Los
componentes están interconectados, pero no dependen unos de otros.
2.11 Seguridad
La seguridad informática se fundamenta en tres principios, que debe cumplir todo

sistema informático:
 Confidencialidad: Se refiere a la privacidad de los elementos de información

almacenados y procesados en un sistema informático, basándose en este
principio, las herramientas de seguridad informática deben proteger el sistema
de invasiones y accesos por parte de personas o programas no autorizados.
Este principio es particularmente importante en sistemas distribuidos, es decir,
aquellos en los que los usuarios, computadores y datos residen en localidades
diferentes, pero están física y lógicamente interconectados.
 Integridad: Se refiere a la validez y consistencia de los elementos de
información almacenados y procesados en un sistema informático. Basándose
en este principio, las herramientas de seguridad informática deben asegurar que
los procesos de actualización estén bien sincronizados y no se dupliquen, de
forma que todos los elementos del sistema manipulen adecuadamente los
mismos datos. Este principio es importante en sistemas descentralizados, es
decir, aquellos en los que diferentes usuarios, computadores y procesos
comparten la misma información.
 Disponibilidad: Se refiere a la continuidad de acceso a los elementos de
información almacenados y procesados en un sistema informático. Basándose
en este principio, las herramientas de seguridad informática deber reforzar la
permanencia del sistema informático, en condiciones de actividad adecuadas
para que los usuarios accedan a los datos con la frecuencia y dedicación que
requieran, este principio es importante en sistemas informáticos cuyos
compromisos con el usuario, es prestar servicio permanente.
29
2.12 Cocomo II
El modelo COCOMO original se convirtió en uno de los modelos de estimación de

costo más ampliamente utilizados y estudiados en la industria. Evolucionó hacia un
modelo de estimación más exhaustivo, llamado COCOMO II. Como su predecesor,
COCOMO II en realidad es una jerarquía de modelos de estimación que aborda las
áreas siguientes:
 Modelo de composición de aplicación. Se usa durante las primeras etapas de

la ingeniería de software, cuando son primordiales la elaboración de prototipos
de las interfaces de usuario, la consideración de la interacción del software y el
sistema, la valoración del rendimiento y la evaluación de la madurez de la
tecnología.
 Modelo de etapa temprana de diseño. Se usa una vez estabilizados los
requisitos y establecida la arquitectura básica del software.
 Modelo de etapa postarquitectónica. Se usa durante la construcción del
software.
Como todos los modelos de estimación para software, los modelos COCOMO II
requieren información sobre dimensionamiento. Como parte de la jerarquía del
modelo, están disponibles tres diferentes opciones de dimensionamiento: puntos
objeto, puntos de función y líneas de código fuente.
2.12.1 USC-COCOMO II.2000.4
Es una aplicación que permite estimar el costo, el esfuerzo y el cronograma al

planificar una nueva actividad de desarrollo de software. COCOMO II es la última
gran extensión del COCOMO original.
Consta de tres submodelos, cada uno de los cuales ofrece una mayor fidelidad a
medida que avanza uno en el proceso de planificación y diseño del proyecto.
Son necesarios una serie de datos para realizar la estimación, que son los
siguientes:
30
 Nombre del proyecto: campo en el que se debe indicar el nombre del
proyecto.
 Nombre del módulo: sirve para especificar el nombre de cada módulo que
componga el proyecto.
 Horas por persona al mes: el valor de horas por persona mensuales que
utilizará el modelo en los cálculos.
 Tamaño del módulo: indica el tamaño de cada módulo en líneas de código.
Se puede calcular de tres maneras, introduciendo su valor en el campo
SLOC, utilizando el modelo de los puntos de función o empleando el modelo
de adaptación y reutilización.
 Sueldo mensual: contiene la cantidad monetaria que percibe el
desarrollador del módulo cada mes.
31
CAPÍTULO III
MARCO APLICATIVO
En el presente capítulo se da a conocer el seguimiento al desarrollo del proyecto,

teniendo como base la metodología XP complementándolo con herramientas UML y
las etapas metodológicas de Roger Pressman, A continuación, se detallará un análisis
de la situación actual y luego se describirán las fases de la metodología XP orientado
a nuestro proyecto.
3.1 Análisis del sistema actual
La empresa Innovative Apps no cuenta con un sistema para poder gestionar los
documentos. La documentación de los proyectos está de manera desorganizada en
los servidores y en las computadoras personales de los gerentes.
En la empresa existen diferentes tipos de documentos que cumplen una función

importante en el avance de un proyecto. Cada tipo de documento tiene un editor y
algunos un revisor que aprueba la edición de un documento. Se cuenta con los
archivos base para los documentos que son repetitivos en su estructura.
Existen los documentos que son guías de trabajo, los cuales no están asignados a los
proyectos porque son archivos generales que se usan en todos los proyectos como
base de inicio o como base de actualización a un nuevo empleado en la empresa.
Los tipos de documentos que se tienen en la empresa son:
 Contratos: Son los acuerdos legales por proyecto. Este tipo de documento
cuenta con un archivo base para que pueda ser replicado en otros proyectos.
Solo los gerentes de proyecto pueden editar y visualizar este documento. Los
tipos de archivos para estos documentos son formato de documento portátil
(.pdf) y Word (.doc, .docx).
 Change request: Una solicitud de cambio es documentada por los gerentes de
proyectos, no es editable. Los tipos de archivos para estos documentos son
formato de documento portátil (.pdf) y Word (.doc, .docx).
 Propuestas: Las propuestas son los documentos con los que se inicia un
proyecto, los gerentes comerciales y los gerentes de proyectos son los que
32
crean y editan las propuestas. Los tipos de archivos para estos documentos son
formato de documento portátil (.pdf) y Word (.doc, .docx).
 Presentaciónes: En cada proyecto antes del contrato se hace la presentación
del proyecto a los clientes de la empresa para que ellos comprendan todos los
beneficios que ofrece la empresa Innovative Apps. Los gerentes comerciales
son los que crean y editan las presentaciones. Los tipos de archivos para estos
documentos son formato de documento portátil (.pdf) y PowerPoint (.ppt, .pptx).
 Mockups: Son los diseños de las pantallas, pueden ser diseños para sistemas
web o para aplicaciones móviles. Los tipos de archivos para estos documentos
son formato de documento portátil (.pdf), Adobe XD (.xd) y figma (.fig). Los
encargados de crear y editar estos documentos son los diseñadores gráficos,
luego pasan por la revisión de un gerente y finalmente es enviado a los
desarrolladores para poder ser implementado.
 Modelo de Base de Datos: El modelo de base de datos relacional lo crean y
editan los desarrolladores del área de backend. Los tipos de archivos para estos
documentos son PowerDesigner (.bpm, .cdm .pdm).
 Manual de Instalación: El manual de instalación es creada por los
desarrolladores luego es revisado y confirmado por el área testing. Los tipos de
archivos para estos documentos son formato de documento portátil (.pdf) y
Word (.doc, .docx).
 Manual de usuario: El manual de usuario es creada por los desarrolladores
luego es revisado, complementado y confirmado por el área testing. Los tipos
de archivos para estos documentos son formato de documento portátil (.pdf) y
Word (.doc, .docx).
 Manual técnico: El manual de usuario es creada por los desarrolladores luego
es revisado, complementado y confirmado por el área de testing. Los tipos de
archivos para estos documentos son formato de documento portátil (.pdf) y
Word (.doc, .docx).
 Guías de trabajo: Las guías de trabajo son creadas por los desarrolladores
para guía de proyectos futuros similares, con la actualización de herramientas
33
este documento es también actualizado. Los tipos de archivos para estos
documentos son formato de documento portátil (.pdf) y Word (.doc, .docx).
Con toda esta información se pudo clasificar a los documentos por tipo como se
presenta en la Tabla 3.1:
Tabla 3.1 Clasificación de documentos.
Tipo Nombre
Gerencial Contratos
Change request
Ventas Propuestas
Presentaciones
Diseño Mockups
Desarrollo Modelo de base de datos
Manuales Manual de instalación
Manual de usuario
Manual técnico
Guías Guías de trabajo
3.2 Fase de exploración
En esta fase plantearemos los usuarios, casos de uso de la situación actual,

requerimientos y se hará un prototipo de la arquitectura del sistema.
3.2.1. Características de los usuarios

En la empresa existen diferentes roles y un empleado puede tener más de un rol,
los roles identificados son:
 Gerente de proyectos: Interactúan tanto con el equipo interno como con el

cliente Es asignado a los proyectos y tiene acceso a todos los documentos
y reportes.
 Gerente de ventas: Tiene una gran responsabilidad dentro de la empresa
por que el producto o servicio que ofrece es la principal fuente de ingresos.
Es asignado a los proyectos y tiene acceso a los documentos todos los
documentos y reportes exceptuando los contratos.
 Diseñador gráfico: Son los responsables de la imagen de los sistemas y
aplicaciones. En los documentos solo se les asigna los mockups.
34
 Desarrollador backend: Se encarga de diseñar la lógica y las soluciones
para que todas las acciones solicitadas en una página web sean ejecutadas
de manera correcta. Trabaja del lado del servidor y procesa la información
recibida a través del frontend.
 Desarrollador frontend: Se encarga de la parte visual, la interfaz, se
encuentra en la parte del cliente.
 Desarrollador móvil: Desarrolla aplicaciones para celulares y tablets para
sistemas operativos como iPhone o Android.
 Tester: Se encarga de probar un software durante su fase de desarrollo con
el fin de detectar fallos e informar sobre ellos.
3.2.2. Casos de uso de la situación actual

En la Figura 3.1 definimos el diagrama de casos de uso de la situación actual del
manejo de documentos en los proyectos de la empresa.
Figura 3.1 Casos de uso de la situación actual.

35
3.2.3. Requerimientos
La toma de requerimientos nos ayudará a definir las historias de usuario. Los
requerimientos funcionales son los siguientes:
RF1 Registrar los datos del personal que trabaja en la empresa.

RF2 Registrar y asociar los roles de la empresa.
RF3 Registrar y asociar los recursos de la empresa.
RF4 Registrar los proyectos.
RF5 Registrar los documentos de un proyecto.
RF6 Registrar los documentos base para la empresa.
RF7 Asignar proyectos al personal.
RF8 Notificar la asignación del proyecto al personal.
RF8 Habilitar un canal de comunicación del proyecto entre el personal asignado.
RF9 Registrar los parámetros de opciones para el registro de documentos.
RF10 Emitir reportes sobre los proyectos.
Los requerimientos no funcionales son los siguientes:
RNF1 Contar con una persona encargada del mantenimiento de la aplicación.

RFN2 Equipo idóneo para el funcionamiento y uso correcto.
RNF3 Interfaz gráfica agradable para los usuarios.
RNF4 Solo el usuario administrador puede modificar, eliminar y crear otros
usuarios.
RNF5 Todos los usuarios tienen una identificación y una contraseña.
RFN6 Las consultas y entradas serán realizadas de manera ágil y en un tiempo
adecuado.
RFN7 El sistema debe funcionar todos los días y todo el día con un nivel del
99% de este tiempo.
RNF8 Se proporcionará un manual para el uso correcto del sistema.
RNF9 Desarrollado con java 8.
RNF10 Desarrollado con Spring Boot 5
RNF11 Se debe contar con una conexión de internet razonable.
RNF12 El sistema debe ser ejecutado en un navegador web
36
RNF13 El sistema funciona en cualquier sistema operativo, solo se requiere un
navegador.
3.2.4. Prototipo arquitectura del sistema

El proyecto consta de una aplicación web que interactúa mediante peticiones
REST con el web service el cual tiene acceso a la base de datos del proyecto y
a los apis de notificación de Firebase AWS. Cuando la aplicación web este
publicado en internet el usuario podrá acceder a ella mediante un navegador web.
El diseño del prototipo se encuentra en la Figura 3.2
Figura 3.2 Prototipo de arquitectura.

3.3 Fase de planificación
En esta fase estableceremos los casos de uso, las historias de usuario con sus
prioridades y estimación de esfuerzo y el plan de entregas (“Release Plan”).
3.3.1. Casos de uso

El diagrama de casos de uso del sistema de gestión de documentación de
proyectos está representado en la Figura 3.3.
37
Figura 3.3 Diagrama de casos de uso del sistema de gestión de documentación de proyectos.
3.3.2. Historias de usuario

Con el anterior análisis podemos definir las historias de usuario especificadas en
esta sección las cuales serán usadas para la planeación de las iteraciones que
tendremos en el proceso de desarrollo del sistema.
La historia de usuario de login detallada en la tabla 3.2 define todo el proceso de

ingreso de usuarios al sistema con la autentificación usando un username y una
38
contraseña, validándolos roles del usuario y recuperando los recursos a los que
tendrá acceso.
Tabla 3.2 Historia de usuario: Login.
Historia de usuario
Número: 1 Usuario: Administrador - Usuario
Nombre historia: Login
Prioridad en negocio:
Alta Riesgo de desarrollo: Media
Puntos estimados: 6 Iteración asignada: 1

Programador responsable: Edith Lopez
Descripción:
El usuario podrá ingresar al sistema para poder hacer uso de las funcionalidades
asignadas.
Observaciones:
Para que un usuario pueda ingresar al sistema debe tener asignado un usuario y una
contraseña además de que su cuenta debe estar activa.
La historia de usuario de gestión de usuarios solo es accesible para usuarios con

rol de administrador, se divide en tres tareas de creación, edición y eliminación de
usuarios, esta historia de usuario se detalla en la tabla 3.3.
Tabla 3.3 Historia de usuario: Gestión de usuarios.
Historia de usuario
Número: 2 Usuario: Administrador
Nombre historia: Gestión de usuarios
Alta Riesgo de desarrollo: Baja
Descripción:
El usuario podrá agregar, modificar y eliminar usuarios.
Observaciones:
La historia de usuario de gestión de roles solo es accesible para usuarios con rol
de administrador, se divide en tres tareas de creación, edición y eliminación de
roles, esta historia de usuario se detalla en la tabla 3.4.
39
Tabla 3.4 Historia de usuario: Gestión de roles.
Historia de usuario
Nombre historia: Gestión de roles
Media Riesgo de desarrollo: Baja
Descripción:
El usuario podrá agregar, modificar y eliminar roles.
Observaciones:
La historia de usuario de gestión de recursos solo es accesible para usuarios con

recursos, esta historia de usuario se detalla en la tabla 3.5.
Tabla 3.5 Historia de usuario: Gestión de recursos.
Historia de usuario
Nombre historia: Gestión de recursos
Descripción:
El usuario podrá agregar, modificar y eliminar recursos.
Observaciones: Se considera recurso a los menús de funciones.
La historia de usuario de gestión de proyectos solo es accesible para usuarios con

proyectos, esta historia de usuario se detalla en la tabla 3.6.
Tabla 3.6 Historia de usuario: Gestión de proyectos.
Historia de usuario
Nombre historia: Gestión de proyectos
40
Descripción:
El usuario podrá agregar, modificar y eliminar proyectos.
Observaciones:
La historia de usuario de gestión de documentos solo es accesible para usuarios

con rol de administrador, se divide en tres tareas de creación, edición y eliminación
de documentos, esta historia de usuario se detalla en la tabla 3.7.
Tabla 3.7 Historia de usuario: Gestión de documentos.
Historia de usuario
Nombre historia: Gestión de documentos
Descripción:
El usuario podrá agregar, modificar y eliminar documentos.
Observaciones:
La historia de usuario de gestión de parámetros solo es accesible para usuarios

con rol de administrador, se divide en tres tareas de creación, edición y eliminación
de parámetros, esta historia de usuario se detalla en la tabla 3.8.
Tabla 3.8 Historia de usuario: Gestión de parámetros del sistema.
Historia de usuario
Nombre historia: Gestión de parámetros del sistema
Baja Riesgo de desarrollo: Baja
Descripción:
El usuario podrá agregar, modificar y eliminar parámetros.
Observaciones:
41
La historia de usuario de descarga de proyectos solo es accesible para usuarios
con rol de administrador los reportes serán sobre detalle de los tiempos y estados
de los proyectos filtrados por fechas se detalla en la tabla 3.9.
Tabla 3.9 Historia de usuario: Descargar reportes.
Historia de usuario
Nombre historia: Descargar reportes
Baja Riesgo de desarrollo: Media
Descripción:
El usuario podrá descargar los reportes de documentos de los proyectos según a
filtros de fechas.
Observaciones:
La historia de usuario de consulta de proyectos asignados es accesible para

usuarios con rol de usuario, en esta sección el usuario podrá ver solo los proyectos
en los que participa, esta historia de usuario se detalla en la tabla 3.10.
Tabla 3.10 Historia de usuario: Consultar proyectos asignados.
Historia de usuario
Número: 9 Usuario: Usuario
Nombre historia: Consultar proyectos asignados
Media Riesgo de desarrollo: Media
Descripción:
El usuario podrá listar la información de los proyectos a los cuales fue asignado.
Observaciones:
La historia de usuario de recibir notificaciones es accesible para todos los usuarios,

en esta habilitamos al usuario para recibir notificaciones las notificaciones se
envían por rol o por mensaje personal, esta historia de usuario se detalla en la
tabla 3.11.
42
Tabla 3.11 Historia de usuario: Recibir notificaciones.
Historia de usuario
Número: 10 Usuario: Usuario - Administrador
Nombre historia: Recibir notificaciones
Descripción:
El usuario recibirá notificaciones sobre los proyectos a los que está asignado
Observaciones:
La historia de usuario consulta de comentarios de proyecto es accesible para todos

los usuarios, el usuario podrá escribir comentarios sobre el proyecto o sobre los
documentos del proyecto y también podrá ver los comentarios de otros usuarios,
esta historia de usuario se detalla en la tabla 3.12
Tabla 3.12 Historia de usuario: Consultar comentarios de proyecto.
Historia de usuario
Nombre historia: Consultar comentarios de proyecto.
Descripción:
El usuario podrá listar los comentarios del proyecto al cual fue asignado.
Observaciones:
La historia de usuario de consulta de documentos de proyecto es accesible para

usuarios con rol de usuario, el usuario podrá ver los documentos de los proyectos
en los que participa, esta historia de usuario se detalla en la tabla 3.13.
Tabla 3.13 Historia de usuario: Consultar documentos de proyecto.
Historia de usuario
Nombre historia: Consulta documentos de proyecto.
43
Descripción:
El usuario podrá listar los documentos del proyecto al cual fue asignado.
Observaciones:
Solo podrá listar documentos del proyecto al que está asignado y tiene permisos

todos los usuarios, se habilitará la opción de descarga de los documentos, esta
historia de usuario se detalla en la tabla 3.14.
Tabla 3.14 Historia de usuario: Descargar documentos de proyectos.
Historia de usuario
Nombre historia: Descarga documentos de proyecto.
Descripción:
El usuario podrá descargar los documentos del proyecto al cual fue asignado.
Observaciones:
Solo podrá listar documentos del proyecto al que está asignado y tiene permisos
La historia de usuario de consulta de documentos guía, es accesible para todos

los usuarios, esta historia de usuario se detalla en la tabla 3.15.
Tabla 3.15 Historia de usuario: Consultar documentos guía.

Historia de usuario
Nombre historia: Consulta documentos guía.
Descripción:
El usuario podrá listar los documentos generales asignados.
Observaciones:
44
todos los usuarios, se habilitará la opción de descarga de los documentos, esta
Tabla 3.16 Historia de usuario: Descargar documentos guía.
Historia de usuario
Nombre historia: Descarga documentos guía.
Descripción:
El usuario podrá descargar los documentos generales asignados.
Observaciones:
La historia de usuario de actualizar documento es accesible para todos los

usuarios que tenga asignado la opción de editor, esta historia de usuario se detalla
en la tabla 3.17.
Tabla 3.17 Historia de usuario: Actualizar documentos.
Historia de usuario
Número: 16 Usuario: Administrador - Usuario
Nombre historia: Actualiza documentos.
Descripción:
El usuario podrá editar la versión de un documento.
Observaciones:
El usuario debe estar asignado como editor del documento.
La historia de usuario de asignar roles es accesible para todos los usuarios

administrador, un administrador podrá asignar roles a un usuario, esta historia de
usuario se detalla en la tabla 3.18.
45
Tabla 3.18 Historia de usuario: Asignar roles.
Historia de usuario
Nombre historia: Asignar roles.
Descripción:
El usuario podrá asignar roles a los usuarios.
Observaciones:
La historia de usuario de asignar recursos es accesible para todos los usuarios

administrador, un administrador podrá asignar recursos a un rol, esta historia de
usuario se detalla en la tabla 3.19.
Tabla 3.19 Historia de usuario: Asignar recursos.
Historia de usuario
Nombre historia: Asignar recursos.
Alta Riesgo de desarrollo: Baja
Descripción:
El usuario podrá asignar recursos a los roles.
Observaciones:
La historia de usuario de asignar usuarios es accesible para todos los usuarios

administrador, un administrador podrá asignar usuarios a un proyecto, esta historia
de usuario se detalla en la tabla 3.20.
Tabla 3.20 Historia de usuario: Asignar usuarios.
Historia de usuario
Nombre historia: Asignar usuarios.
46
Descripción:
El usuario podrá asignar usuarios a los proyectos.
Observaciones:
La historia de usuario de asignar editores es accesible para todos los usuarios

administrador, un administrador podrá asignar editores a un documento, esta
Tabla 3.21 Historia de usuario: Asignar editores.
Historia de usuario
Nombre historia: Asignar editores.
Descripción:
El usuario podrá asignar usuarios editores a los documentos.
Observaciones:
La historia de usuario de comentar un proyecto está habilitada para todos los

usuarios, un usuario podrá comentar los proyectos en los que está asignado, esta
Tabla 3.22 Historia de usuario: Comentar un proyecto.
Historia de usuario
Número: 21 Usuario: Administrador - usuario
Nombre historia: Comentar un proyecto.
Descripción:
El usuario podrá comentar sobre un proyecto.
Observaciones:
47
La historia de usuario de asignar revisores es accesible para todos los usuarios
administrador, un administrador podrá asignar revisores a un documento, esta
Tabla 3.23 Historia de usuario: Asignar revisores.
Historia de usuario
Nombre historia: Asignar revisores.
Descripción:
El usuario podrá asignar usuarios revisores a los documentos.
Observaciones:
3.3.3. Plan de entregas

Basándonos en las historias de usuario definidas anteriormente, se ha elaborado
el siguiente plan de entregas, el cual muestra las historias de usuario que se
llevarán a cabo en cada iteración. Para este plan de entregas se ha tomado en
cuenta la prioridad y el esfuerzo de cada historia de usuario.
La prioridad puede ser baja, media o alta.
Los puntos de esfuerzo solo son relevantes para el equipo y se usa para estimar
el tamaño de una historia de usuario. Los puntos dan una idea del tamaño y el
esfuerzo que se necesita para que las tareas sean realizadas.
El valor de esfuerzo se basa en la serie Fibonacci 1, 2, 3, 5, 8, 13, 20, 40, 100,

considerando que un valor mayor 13 tomaría el esfuerzo de todo un sprint, en tal
caso se plantea rediseñar la historia de usuario.
En la tabla 3.24 se muestra el plan de entrega del sistema de gestión de

documentación de proyectos.
48
Tabla 3.24 Plan de entregas.
Historia
Iteración Prioridad Esfuerzo Fecha inicio Fecha fin
de usuario
Historia 1 1 Alta 5 26/9/2020 28/9/2020
Historia 2 1 Alta 5 28/9/2020 30/9/2020
Historia 3 1 Media 5 30/9/2020 2/10/2020
Historia 4 1 Media 5 2/10/2020 4/10/2020
Historia 17 1 Media 3 4/10/2020 6/10/2020
Historia 18 1 Media 3 6/10/2020 8/10/2020
Historia 5 2 Alta 8 8/10/2020 10/10/2020
Historia 6 2 Alta 8 10/10/2020 12/10/2020
Historia 19 2 Media 3 12/10/2020 14/10/2020
Historia 20 2 Media 5 14/10/2020 16/10/2020
Historia 22 2 Media 5 14/10/2020 16/10/2020
Historia 16 3 Media 8 16/10/2020 18/10/2020
Historia 9 3 Media 5 18/10/2020 20/10/2020
Historia 12 3 Media 5 20/10/2020 22/10/2020
Historia 14 3 Media 5 22/10/2020 24/10/2020
Historia 13 3 Baja 3 24/10/2020 26/10/2020
Historia 15 3 Baja 3 26/10/2020 28/10/2020
Historia 7 4 Baja 7 28/10/2020 30/10/2020
Historia 8 4 Baja 7 30/10/2020 1/11/2020
Historia 10 4 Baja 5 1/11/2020 3/11/2020
Historia 11 4 Baja 5 3/11/2020 5/11/2020
Historia 21 4 Baja 3 5/11/2020 7/11/2020
3.3.4. Estructura de proyecto

Como se especificó en el título 1.6 para este proyecto se utilizará Java Spring Boot
con el patrón de arquitectura en capas el cual se describe en el título 2.9, con la
aplicación de este patrón las capas para la estructura de este proyecto son las
siguientes:
 Models: Los modelos de la aplicación son las entidades. Las entidades en

JPA no son más que una clase simple (POJO) que representan datos que
pueden persistir en la base de datos. Una entidad representa una tabla
almacenada en una base de datos. Cada instancia de una entidad
representa una fila en la tabla.
49
Debido a que estos objetos de dominio no tienen dependencias de otras
capas de la aplicación, los cambios en otras capas no los afectan. Pueden
evolucionar libres de dependencias. Este es un excelente ejemplo del
principio de responsabilidad única la "S" en "SOLID" especificado en el título
2.8, que establece que los componentes deben tener una sola razón para
cambiar. Para nuestro objeto de dominio, esta razón es un cambio en los
requisitos del negocio.
 Repositories: Se comporta como la puerta de entrada a nuestra base de
datos. Realiza la consulta con los parámetros enviados desde el service. Es
responsable de dos conceptos. Encapsulando los detalles de la capa de
persistencia y proporcionando una interfaz CRUD para una sola entidad
Cada clase de entidad debe tener un repository respectivo
 Services: Es donde se realiza toda la lógica de negocio. Solo se debe
acceder a la capa repositories desde la capa services
 Controllers: Se crean los end points del CRUD para devolver objetos de
salida en formato JSON y se encarga de enviar los códigos de estado HTTP.
Esta capa solo tiene acceso a la capa de services.
3.4 Fase de iteraciones
En esta fase nos basaremos en el plan de entregas ya definido. Cada iteración se rige
en la metodología XP, apoyándonos con diagramas UML como son los diagramas de
actividad, diagramas de secuencia, diagramas de clases y diagramas de navegación.
3.4.1. Iteración 1
En esta iteración se han desarrollado las historias de usuario que se planificaron
en la tabla 3.24. Se inició con los diagramas de actividad y secuencia de la historia
de usuario 1 en el cual se desarrollará el login. En la Figura 3.4 definimos el
diagrama de actividad.
50
Figura 3.4 Diagrama de actividad del login.
En la Figura 3.5 definimos el diagrama de secuencia del login.
Figura 3.5 Diagrama de secuencia del login. Fuente:

Elaboración propia.
En historia de usuario 2 se desarrollará la gestión de usuarios. Para esta historia

de usuario definimos tres diagramas de actividad, en la Figura 3.6 se definen los
diagramas de actividad de las tareas de agregar y editar usuario.
51
Figura 3.6 Diagrama de actividad agregar y editar usuarios.
En la Figura 3.7 se define el diagrama de actividad de la tarea de eliminar usuario.
Figura 3.7 Diagrama de actividad eliminar usuario.

En la Figura 3.8 definimos el diagrama de secuencia de la gestión de usuarios.
52
Figura 3.8 Diagrama de secuencia de gestión de usuarios.
Para esta historia de usuario se implementó las clases para la creación de la

interfaz de programación de aplicaciones (API) según lo establecido en el titulo
3.3.4. El diagrama de clases se encuentre en la Figura 3.9
Figura 3.9 Diagrama de clases según el patrón por capas.

53
Esta estructura de diagrama de clases se repite para los CRUD de cada modelo.
La figura 3.9 nos muestra un ejemplo del principio de inversión de dependencias

la “D” en “SOLID” para una explicación más específica en la Figura 3.10 se muestra
un contra ejemplo en el cual los dos módulos están fuertemente acoplados lo cual
hace más complicado el proceso de compilación y el desarrollo de los tests.
Figura 3.10 Ejemplo de acoplamiento fuerte entre módulos.

Para evitar los problemas de los módulos fuertemente acoplados debemos invertir
las dependencias, esto se consigue estableciendo un contrato entre los módulos
de alto nivel con los módulos de bajo nivel. En Java un contrato es una interfaz.
Introduciendo una interfaz en el diagrama de la Figura 3.10 tendremos un
diagrama de clases según la Figura 3.11
Figura 3.11 Ejemplo de inversión de dependencias.

En la Figura 3.11 observamos que los módulos se han desacoplado y que se

comunican entre ellas mediante una interfaz. En tiempo de ejecución, sin embargo,
la clase UserController seguirá invocando a la implementación UserServiceImpl.
Continuando con el desarrollo de las historias de usuario en la historia de usuario

3 se desarrollará la gestión de roles. Para esta historia de usuario definimos tres
diagramas de actividad, en la Figura 3.12 se definen los diagramas de actividad
de las tareas de agregar y editar rol.
54
Figura 3.12 Diagrama de actividad agregar y editar roles.
En la Figura 3.13 se define el diagrama de actividad de la tarea de eliminar rol.
Figura 3.13 Diagrama de actividad eliminar rol.

En la Figura 3.14 definimos el diagrama de secuencia de la gestión de roles.
55
Figura 3.14 Diagrama de secuencia de gestión de roles.
En historia de usuario 4 se desarrollará la gestión de roles. Para esta historia de
usuario definimos tres diagramas de actividad, en la Figura 3.15 se definen los
diagramas de actividad de las tareas de agregar y editar recurso.
Figura 3.15 Diagrama de actividad agregar y editar recursos.

56
En la Figura 3.16 se define el diagrama de actividad de la tarea de eliminar recurso.
Figura 3.16 Diagrama de actividad eliminar recurso.

Al implementar los roles podemos definir algunas acciones para los roles, por
ejemplo, el rol de gerente y tester podrá editar, publicar y validar un archivo. Con
esta implementación podremos ejemplificar el principio de segregación de interfaz
la “I” de “SOLID” que estable establece que los clientes no deberían verse forzados
a depender de interfaces que no usan. Para una mejor comprensión se especifica
en el título 2.9. Para representar estas acciones tendríamos el siguiente código:
public interface IActionsRoles {

void editFile();
void checkFile();
void publicFile();
}
class Manager implements IActionsRoles {

@Override
public void editFile() {
}
@Override
public void checkFile() {
}
@Override
public void publicFile() {
}
}
57
class Tester implements IActionsRoles {
@Override
}
@Override
}
@Override
}
}
Hasta aquí la implementación está bien. Pero ahora imaginemos que queremos
añadir al rol de diseñador. Este role no puede validar archivos, pero si tiene la
funcionalidad de editar archivos y publicarlos. Podríamos definir la siguiente clase
para los diseñadores:
class Designer implements IActionsRoles {

@Override
}
@Override
throw new UnsupportedOperationException();
}
@Override
}
}
Como el diseñador no puede validar un archivo se le añade una excepción si es
que se llama a ese método. Esto viola el principio de segregación de interfaz, ya
que estas clases no tienen por qué depender de métodos que no usan.
Lo más correcto sería segregar más las interfaces, tanto como sea necesario. Y
así a la hora de añadir nuevas funcionalidades, esto nos ahorrará bastante tiempo,
y, además, cumplimos con el primer principio de Responsabilidad Única. En este
caso podríamos hacer lo siguiente:
public interface IActionsRoles {

void editFile();
void publicFile();
}
public interface IActionsRolesCheckers {

void checkFile();
}
58
class Manager implements IActionsRoles, IActionsRolesCheckers {
@Override
}
@Override
}
@Override
}
}
class Designer implements IActionsRoles {

@Override
}
@Override
}
}
Así, cada clase implementa las interfaces de la que realmente necesita

implementar sus métodos.
En la Figura 3.17 definimos el diagrama de secuencia de la gestión de recursos.
Figura 3.17 Diagrama de secuencia de gestión de recursos.

59
En historia de usuario 17 se desarrollará asignar roles a los usuarios. Para esta
historia de usuario definimos el diagrama de actividad en la Figura 3.18.
Figura 3.18 Diagrama de actividad asignar roles a usuario.

En la Figura 3.19 definimos el diagrama de secuencia de asignar roles.
Figura 3.19 Diagrama de secuencia de asignar roles a usuario.

En historia de usuario 18 se desarrollará asignar recursos a los roles. Para esta

historia de usuario definimos el diagrama de actividad en la Figura 3.20.
60
Figura 3.20 Diagrama de actividad asignar recursos a rol.
En la Figura 3.21 definimos el diagrama de secuencia de asignar recursos.
Figura 3.21 Diagrama de secuencia de asignar recursos a rol.

En esta iteración se llegó a diseñar el diagrama de clases en la Figura 3.22
61
Figura 3.22 Diagrama de clases de la iteración 1.
También definimos el modelo de navegación de la Figura 3.23
Figura 3.23 Modelo de navegación de la iteración 1.

62
Para esta iteración se diseñó los primeros componentes para la interfaz de usuario.
En la figura 3.1 observamos la interfaz del login.
Ilustración 3.1 Interfaz del login.

En la figura 3.2 observamos la interfaz del menú que estará siempre visible y las
tablas componentes que se reutilizarán cuando se requiera listar.
Ilustración 3.2 Interfaz del menú y componente tabla.

En la figura 3.3 se observa el diseño del componente modal para adicionar y editar
registros.
63
Ilustración 3.3 Modal para adicionar y editar registros
En la figura 3.3 se observa el diseño del componente modal para asignar registros.
Ilustración 3.4 Modal para asignar registros.

64
3.4.2. Iteración 2
en la tabla 3.24 para la segunda iteración.
Se inició con los diagramas de actividad y secuencia de la historia de usuario 5 en

el cual se desarrollará la gestión de proyectos. Para esta historia de usuario
definimos tres diagramas de actividad, en la Figura 3.24 se definen los diagramas
de actividad de las tareas de agregar y editar proyecto.
Figura 3.24 Diagrama de actividad agregar y editar proyectos.

En la Figura 3.25 se define el diagrama de actividad de la tarea de eliminar

proyecto.
65
Figura 3.25 Diagrama de actividad eliminar proyecto.
En la Figura 3.26 definimos el diagrama de secuencia de la gestión de proyectos.
Figura 3.26 Diagrama de secuencia de gestión de proyectos.

66
En historia de usuario 6 se desarrollará la gestión de documentos. Para esta
historia de usuario definimos tres diagramas de actividad, en la Figura 3.27 se
definen los diagramas de actividad de las tareas de agregar y editar documentos.
Figura 3.27 Diagrama de actividad agregar y editar documentos.

documento.
Figura 3.28 Diagrama de actividad eliminar documento.

67
En la Figura 3.29 definimos el diagrama de secuencia de la gestión de
documentos.
Figura 3.29 Diagrama de secuencia de gestión de proyectos.

En esta historia de usuario de implementó un método para guardar los archivos de

diferentes extensiones ya que de cada tipo se guarda de forma diferente. Con esta
implementación de guardado de archivos se puede ejemplificar el principio abierto
y cerrado la “O” de “SOLID”
En el siguiente código tenemos una clase FileProcessor la cual se encarga de

guardar los archivos como parámetro recibe el tipo de archivo y el archivo para
guardar en este ejemplo solo tomamos en cuenta los archivos CSV y los archivos
de Excel.
Si en el siguiente código quisiéramos añadir un nuevo tipo de archivo por ejemplo

un archivo PDF tendríamos que modificar la función de saveFile y esta
modificación se tendría que hacer por cada tipo de archivo nuevo al que se quiera
dar la funcionalidad de guardar.
68
public class FileProcessor {
private void saveFile(String type, File file) {

if (type.equals("CSV")){
saveCSV(file);
}
if (type.equals("XLS")){
saveXLS(file);
}
}
private void saveCSV(File file) {

//***
}
private void saveXLS(File file) {

//***
}
}
Para que cumpla con el principio open/close podríamos hacer lo siguiente:
public class FileProcessor {
private void saveFile(BaseFile baseFile) {

baseFile.save();
}
}
abstract class BaseFile {

public String type;
abstract void save();
}
class CSVFile extends BaseFile {

@Override
void save() { /***/ };
}
class ExcelFile extends BaseFile {

@Override
void save() { /***/ };
}
Cada archivo extiende la clase abstracta BaseFile e implementa el método

abstracto save().
Así, cada archivo tiene su propia implementación del método save(), por lo que el
método saveFile() solo llama al método save() de la clase instanciada.
Ahora, si añadimos un nuevo file, la función saveFile() no tendrá que ser

modificada. Solo tendremos que añadir una nueva clase para el archivo.
69
Para detectar si estamos violando el principio de sustitución de Liskov la “L” en
“SOLID” la forma más sencilla es observando las clases que extienden de otras
clases. Si estas poseen métodos sobrescritos que devuelven null o lanzan
excepciones sabiendas de que la clase de la que heredan no lo hace, estamos
ante una clara violación del principio.
Si por otra parte estamos heredando de clases abstractas que nos obligan también
a lanzar excepciones o retornar null, también estamos ante un caso de violación
del LSP. En este ejemplo no estamos violando el principio de sustitución de Lisvok.
En historia de usuario 19 se desarrollará asignar usuarios a los proyectos. Para

esta historia de usuario definimos el diagrama de actividad en la Figura 3.30.
Figura 3.30 Diagrama de actividad asignar usuarios a proyecto.

En la Figura 3.31 definimos el diagrama de secuencia de asignar usuarios.
70
Figura 3.31 Diagrama de secuencia asignar usuarios a proyecto.
En historia de usuario 20 se desarrollará asignar editores a los documentos. Para

Figura 3.32 Diagrama de actividad asignar editores a documento.

En la Figura 3.33 definimos el diagrama de secuencia de asignar editores.
71
Figura 3.33 Diagrama de actividad asignar editores a documento.
En historia de usuario 22 se desarrollará asignar revisores a los documentos. Para

Figura 3.34 Diagrama de actividad asignar revisores a documento.

En la Figura 3.35 definimos el diagrama de secuencia de asignar revisores.
72
Figura 3.35 Diagrama de secuencia asignar revisores a documento.

73

74
3.4.3. Iteración 3
en la tabla 3.24 para la tercera iteración.

el cual se desarrollará la consulta de proyectos asignados. En la Figura 3.38
definimos el diagrama de actividad.
Figura 3.38 Diagrama de actividad listar proyectos asignados.

En la Figura 3.39 definimos el diagrama de secuencia de consulta de proyectos

asignados.
Figura 3.39 Diagrama de secuencia listar proyectos asignados.

En historia de usuario 12 se desarrollará la consulta de documentos de proyecto.

Para esta historia de usuario definimos el diagrama de actividad en la Figura 3.40.
75
Figura 3.40 Diagrama de actividad listar documentos asignados.
En la Figura 3.41 definimos el diagrama de secuencia de consulta de documentos

de proyecto.
Figura 3.41 Diagrama de secuencia listar documentos asignados.

En historia de usuario 14 se desarrollará la consulta de documentos guía. Para

Figura 3.42 Diagrama de actividad listar documentos guía.

76
En la Figura 3.43 definimos el diagrama de secuencia de consulta de documentos
guía.
Figura 3.43 Diagrama de secuencia listar documentos asignados.

En historia de usuario 13 se desarrollará la descarga de documentos de proyectos.

Figura 3.44 Diagrama de actividad descargar documento.

En la Figura 3.45 definimos el diagrama de secuencia de descarga de documentos

de proyecto.
77
Figura 3.45 Diagrama de secuencia descargar documento.
En historia de usuario 14 se desarrollará la descarga de documentos guía. Para
Figura 3.46 Diagrama de actividad descargar documento guía.

En la Figura 3.47 definimos el diagrama de secuencia de descarga de documentos
guía.
Figura 3.47 Diagrama de secuencia descargar documento guía.

78
En historia de usuario 16 se desarrollará la actualización de documentos. Para
Figura 3.48 Diagrama de actividad editar documento.

En la Figura 3.49 definimos el diagrama de secuencia de actualización de

documentos.
Figura 3.49 Diagrama de secuencia editar documento

79

80

81
En esta iteración se diseñó una nueva pantalla para la vista de documentos de un
proyecto. En la ilustración 3.5 se encuentra la vista de un proyecto nuevo.
Ilustración 3.5 Vista de proyectos nuevos.

En la ilustración 3.6 se encuentra la vista de un proyecto ya en proceso.
Ilustración 3.6 Vista proyectos en proceso.

82
También se adicionó un nuevo componente de modal para descargas, el diseño
del modelo se encuentra en la ilustración 3.7
Ilustración 3.7 Modal de descargas.

3.4.4. Iteración 4
en la tabla 3.24 para la cuarta iteración.

el cual se desarrollará la gestión de parámetros. Para esta historia de usuario
definimos tres diagramas de actividad, en la Figura 3.52 se definen los diagramas
de actividad de las tareas de agregar y editar parámetro.
83
Figura 3.52 Diagrama de actividad agregar y editar parámetros.

parámetro.
Figura 3.53 Diagrama de actividad eliminar parámetro.
84
En la Figura 3.54 definimos el diagrama de secuencia de la gestión de parámetros.
Figura 3.54 Diagrama de secuencia de gestión de parámetros.

En historia de usuario 8 se desarrollará la descarga de reportes. Para esta historia
de usuario definimos el diagrama de actividad en la Figura 3.55.
Figura 3.55 Diagrama de actividad descargar reportes.

85
En la Figura 3.56 definimos el diagrama de secuencia de la descarga de reportes.
Figura 3.56 Diagrama de secuencia descargar reportes.

En historia de usuario 10 se desarrollará recibir notificaciones. Para esta historia

Figura 3.57 Diagrama de actividades recepción de notificaciones.

En la Figura 3.58 definimos el diagrama de secuencia de recibir notificaciones.
86
Figura 3.58 Diagrama de secuencia recepción de notificaciones.
En historia de usuario 11 se desarrollará la consulta de comentarios de proyecto.

Figura 3.59 Diagrama de actividades consultar comentarios.

En la Figura 3.60 definimos el diagrama de secuencia de consultar comentarios.
Figura 3.60 Diagrama de actividades consultar comentarios.

En historia de usuario 21 se desarrollará comentar un proyecto. Para esta historia

87
Figura 3.61 Diagrama de actividades agregar comentario.
En la Figura 3.62 definimos el diagrama de secuencia de agregar comentario.
Figura 3.62 Diagrama de secuencia agregar comentario.

88
89
90
En esta iteración se rediseñó la pantalla para la vista de documentos de un
proyecto. En la ilustración 3.8 se encuentra la vista de un proyecto nuevo.
Ilustración 3.8 Vista proyecto nuevo.

En la ilustración 3.9 se encuentra la vista de un proyecto ya en proceso.
Ilustración 3.9 Vista proyecto en proceso.

91
3.5 Fase de Pruebas
En esta fase se hicieron las pruebas unitarias de React utilizando Jest y de Java
utilizando JUnit. El criterio de aceptación es de un 80% de coverage en los modulos
tanto de front como de backend.
En la Iustración 3.10 podemos observar el code coverage de los unit tests de Java.
Ilustración 3.10 Code coverage java

En la Iustración 3.11 podemos observar el code coverage de los unit tests de React.
Ilustración 3.11 Code coverage react

92
CAPÍTULO IV
CALIDAD, SEGURIDAD Y COSTO DE SOFTWARE
En este capítulo se aplicarán las métricas de calidad, se explicarán las medidas de

seguridad del software y el costo para evaluar el proyecto.
4.1 Calidad
Para evaluar el presente proyecto se aplican las métricas según el estándar ISO 9126,
evaluando la fiabilidad, funcionalidad, portabilidad, usabilidad y mantenimiento.
4.1.1 Funcionalidad
Para evaluar la funcionalidad se hará uso de la métrica de punto de función. En la

tabla 4.1 especificamos los valores de dominio de la información para el cálculo de
punto de función.
Tabla 4.1 Detalle de los valores de dominio.
PARÁMETROS DE MEDICIÓN
Entradas externas 1: Control de ingreso Simple
2: Registro de usuarios Medio
3: Registro de roles Medio
4: Registro de recursos Medio
5: Registro de proyectos Medio
6: Registro de documentos Medio
7: Registro de documentos guía Medio
8: Registro de parámetros Medio
9: Registro de comentarios Medio
Salidas externas 1: Reporte de proyectos Medio
2: Descarga de documentos Simple
3: Descarga de documentos guía Simple
4: Reporte de edición de documentos Medio
Consultas externas 1: Pantalla de logon Medio
2: Lista de usuarios Simple
3: Lista de roles Simple
4: Lista de recursos Simple
5: Lista de proyectos Simple
6: Vista de proyecto Medio
7: Lista de documentos Medio
8: Lista de documentos guía Medio
93
9: Lista de parámetros Simple
10: Lista de comentarios Simple
11: Lista de notificaciones Simple
Archivos lógicos 1: Tabla de usuarios Medio
internos 2: Tabla de roles Medio
3: Tabla de recursos Medio
4: Tabla de proyectos Medio
5: Tabla de documentos Medio
6: Tabla de versiones Medio
7: Tabla de parámetros Medio
8: Tabla de notificaciones Medio
Archivos de interfaz 1: Archivos de documentos en el disco Medio
externos 2: Cliente para notificaciones con Firebase Complejo
3: Impresora Simple
Los puntos de función se calculan completando la tabla 4.2, utilizando los datos
detallados en la tabla 4.1.
Tabla 4.2 Cálculo de puntos de función.
Valor de dominio de Factor ponderado Total

información Simple Medio Complejo
Entradas externas 1x3=3 8 x 4 = 32 0x6=0 35
Salidas externas 2x4=8 2 x 5 = 10 0x7=0 18
Consultas externas 7 x 3 = 21 4 x 4 = 16 0x6=0 37
Archivos lógicos internos 0 x 7 = 0 8 x 10 = 80 0 x 15 = 0 80
Archivos de interfaz externos 1x5=5 1x7=7 1 x 10 = 10 22
Conteo total 192
El resultado de la tabla 4.2 nos da un conteo total de 192, es el total de Puntos

Función sin Ajustar, este resultado será utilizado para calcular los puntos de
función y los puntos de función máximos.
Para calcular puntos de función debemos obtener antes los factores de ajuste de
valor (FAV) con base a las respuestas a las preguntas los cual se detalla en la
tabla 4.3. Las siguientes preguntas se responden usando una escala que varía de
cero que significa no importante o aplicable a cinco que significa absolutamente
esencial.
94
Tabla 4.3 Factores de ajuste de valor.
Fi Factor Fi Valor 0-5

1 ¿El sistema requiere respaldo y recuperación confiables? 5
2 ¿Se requiere comunicación de datos especializadas para transferir información 4
hacia o desde la aplicación?
3 ¿Existen funciones de procesamiento distribuidas? 4
4 ¿El desempeño es crucial? 3
5 ¿El sistema correrá en un entorno operativo existente enormemente utilizado? 3
6 ¿El sistema requiere entrada de datos en línea? 4
7 ¿La entrada de datos en línea requiere que la transacción de entrada se 3
construya sobre múltiples pantallas u operaciones?
8 ¿Los ALI se actualizan en línea? 4
9 ¿Las entradas, salidas, archivos o consultas son complejos? 3
10 ¿El procesamiento interno es complejo? 4
11 ¿El código se diseña para ser reutilizable? 4
12 ¿La conversión y la instalación se incluyen en el diseño? 3
13 ¿El sistema se diseña para instalaciones múltiples en diferentes organizaciones? 0
14 ¿La aplicación se diseña para facilitar el cambio y su uso por parte del usuario? 5
∑(𝑭𝒊) 49
Para calcular los puntos de función se utilizará la ecuación 4.1. la cual es detallada
en el titulo 2.7.2.
𝑃𝐹 = 𝐶𝑂𝑁𝑇𝐸𝑂 𝑇𝑂𝑇𝐴𝐿 ∗ [0.65 + 0.01 ∗ ∑(𝐹𝑖)] (4.1)
Reemplazando los valores obtenemos:
𝑃𝐹 = 192 ∗ [0.65 + 0.01 ∗ 49] = 218.88
El total de puntos de función ajustados es 218.88
Considerando a ∑(𝐹𝑖_𝑚𝑎𝑥) como el valor máximo de los factores de ajuste de

valor, calculamos el punto de valor máximo:
𝑃𝐹𝑀𝐴𝑋 = 192 ∗ [0.65 + 0.01 ∗ 70]
𝑃𝐹𝑀𝐴𝑋 = 259.2
La funcionalidad está dada por:
𝑃𝐹
𝑃𝐹𝑅𝐸𝐴𝐿 = ∗ 100
𝑃𝐹𝑀𝐴𝑋
95
218.88
𝑃𝐹𝑅𝐸𝐴𝐿 = ∗ 100 = 84.44
259.2
Interpretando, el sistema tiene una funcionalidad o utilidad del 84%.
4.1.2 Confiabilidad
La confiabilidad es la capacidad de un sistema de desempeñar una función
requerida, en condiciones establecidas durante un período de tiempo determinado.
Durante el desarrollo de la aplicación en el periodo de pruebas en distintos

navegadores se encontraron diferentes fallas en la siguiente tabla 4.4 se muestra
el resultado de los fallos del sistema web por periodos de tiempo de ocho horas de
ejecución. Las ocho horas fueron definidas por las ocho horas en las que debería
trabajar correctamente el sistema y se toma en cuenta el número mínimo de
peticiones para realizar una tarea básica en el sistema.
Para calcular la probabilidad de fallo en la tabla 4.4 se utilizará la siguiente

ecuación:
𝐹𝑎𝑙𝑙𝑜𝑠
Probabilidad de fallo =
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑒𝑡𝑖𝑐𝑖𝑜𝑛𝑒𝑠
Tabla.4.4 Calculo fallos de la aplicación.
Tiempo en horas Número de peticiones Fallos Probabilidad de fallo

8 Horas 3 0 0
16 Horas 9 1 0,1
32 Horas 20 2 0,1
64 Horas 40 3 0,075
El valor promedio de las fallas producidas en un tiempo de servicio (PFTS) está

definido en la siguiente ecuación donde la probabilidad de fallo es la sumatoria de
las probabilidades de fallo de la tabla 4.4 y los periodos de tiempo son los cuatro
periodos de tiempo de 8 horas definidas en la tabla 4.4:
∑ 𝑝𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 𝑑𝑒 𝑓𝑎𝑙𝑙𝑜
PFTS =
𝑃𝑒𝑟𝑖𝑜𝑑𝑜𝑠 𝑑𝑒 𝑡𝑖𝑒𝑚𝑝𝑜
96
0.27
PFTS = = 0.068
4
El valor promedio de fallas es igual a 0.068 con los que podemos calcular la
confiabilidad que está dada por la siguiente ecuación:
Confiabilidad = (1 − 𝑃𝐹𝑇𝑆) ∗ 100
Reemplazando los datos obtenemos:
Confiabilidad = (1 − 0.068) ∗ 100 = 93.2
Con este resultado podemos nos indica que el sistema tiene un 93.2% de
confiabilidad. Según la escala de valoración detallada en el título 2.7.3 la
confiabilidad es muy buena.
4.1.3 Usabilidad
La usabilidad es la capacidad del software de ser entendido, aprendido y usado

por los usuarios. Para determinar el porcentaje de usabilidad del sistema se optó
por realizar una encuesta a diez integrantes de la empresa Innovative Apps de
manera anónima, de las diez personas, dos son del grupo del aseguramiento de
calidad (QA), un diseñador gráfico, dos del grupo de desarrollo frontend, una del
grupo de desarrollo móvil, una del grupo de desarrollo backend, una del área
comercial y dos gerentes. En la tabla 4.5 encontramos los resultados de la
encuesta.
Tabla 4.5 Resultados de las encuestas.
Pregunta Respuesta Porcentaje

SI NO
¿Aprendió de manera rápida a usar el sistema? 8 2 80
¿Las pantallas que vio fueron de su agrado? 8 2 80
¿El sistema responde rápido a sus solicitudes? 10 0 100
¿El sistema le facilita el trabajo? 10 0 100
¿Es fácil navegar por las distintas opciones? 8 2 80
¿El sistema le proporciono las respuestas requeridas? 9 1 90
¿El sistema es comprensible ? 8 2 80
¿El sistema satisface sus requerimientos? 10 0 100
¿El tiempo en realizar un proceso es menor al realizado sin el sistema? 10 0 100
97
¿Considera que el acceso al sistema es seguro? 9 1 90
¿El registro de datos es efectivo? 10 1 100
PROMEDIO 91
Con el resultado de la encuesta podemos deducir que el sistema tiene un grado de

usabilidad de 91%.
4.1.4 Eficiencia
Para evaluar la eficiencia en un producto de software se han desarrollado un

conjunto de métricas que indican qué porciento de eficiencia presenta una
aplicación web convirtiéndose el valor de esta EF (dada en por ciento) en un
Indicador a obtener. Dentro de las diferentes métricas propuestas para las
evaluaciones se encuentras las relacionadas con las Incidencias o No
Conformidades generadas en el proceso de Testing de los cuales se encuentra la
especificación en el título 2.8.4. Se deben tener en cuenta para lograr una
evaluación más exacta que se realicen los tres tipos de prueba.
El resultado de la Eficiencia (EF) se calcula con siguiente ecuación:
𝑇𝑅 + 𝐶 + 𝐸𝐻𝑇𝑇𝑃
EF =
3
Donde:
TR = Porcentaje del tiempo de Respuesta.
C = Porcentaje de concurrencia.
EHTTP = Porcentaje de errores HTTP.
Podemos llevar estos tres datos los datos descritos en la tabla 4.6.
Tabla 4.6 Factores de eficiencia.
Número Factor de ajuste Valor

obtenido
1 Es de respuesta rápida al utilizar sus funciones 91
2 Tiene rendimiento de acuerdo a los factores que utiliza 80
3 El tiempo de respuesta a sus consultas es adecuado 84
Promedio 94
98
Para calcular los anteriores por cientos se utilizarán las siguientes métricas:
Porcentaje del tiempo de Respuesta.

𝑇𝑅𝐸 ∗ 100
TR =
𝑇𝑅𝑅
Donde:
TRR = Tiempo de Respuesta Real.
TRE = Tiempo de Respuesta Esperado
Tomando en cuenta el tiempo de respuesta aceptable definido en el título 2.8.4

tomamos el valor 500ms como el TRE y calculamos el TRR en Gtmetrix que es
uno de los principales servicios de medición de tiempo de respuesta, dando de
resultado 845ms como el tiempo más largo esperado en el sistema.
Reemplazando estos datos:
0.5 ∗ 100
%TR = = 91%
0.55
Dando por resultado 91% como tiempo de Respuesta
Concurrencia.
𝐶𝑅 ∗ 100
C=
𝐶𝐸
Donde:
CR= Concurrencia Real.
CE= Concurrencia Esperada.
La concurrencia esperada diaria es de 20 personas conectas al día, sin embargo,

la concurrencia real es que hay menos personas conectadas un promedio de 16
personas. Reemplazando estos datos:
16 ∗ 100
C= = 80
20
Dando el resultado de 80% de concurrencia.

Errores HTTP
EHTTP ∗ 100
HTTP = 100 −
CURL
99
Donde
EHTTP = Errores HTTP generados.
CURL = Cantidad de URL visitadas.
Con las anteriores pruebas se evidenciaron errores de badRequest, NotFound y
Unforbidden en algunas url’s el total de errores fue de 5 de 30 url’ visitadas.
Reemplazando estos datos:
5 ∗ 100
HTTP = 100 − = 84
30
Dando un resultado de 84% de respuestas adecuadas.
Reemplazando estos tres datos en la fórmula de eficiencia tenemos:
91 + 80 + 84
EF = = 85
3
Dando como resultado que el sistema tiene una eficiencia de 94%.
4.1.5 Mantenimiento
Para las métricas de mantenimiento se usa el índice de madurez del software (IMS)
el cual se representa con la ecuación 4.3.
MT − (𝐹𝑎 + 𝐹𝑐 + 𝐹𝑑 )
𝐼𝑀𝑆 =
MT
Donde:
Mt = número de módulos en la versión actual.
Fa = número de módulos en la versión actual que cambiaron.
Fc = número de módulos en la versión actual que se agregaron.
Fd = número de módulos en la versión anterior que se borraron en la versión actual.
Reemplazando los datos se obtiene:

11 − (0 + 1 + 0)
𝐼𝑀𝑆 = = 0.91
11
Con este resultado podemos decir que el sistema cuenta con un índice de madurez
del 91%.
100
4.1.6 Portabilidad
La portabilidad es la facilidad con la que el software pueda llevarse de un ambiente

a otro. Para eso calcularemos el grado de portabilidad definido en la ecuación 4.4
𝐶𝑃
𝐺𝑃 = 1 −
𝐶𝑅𝐷
Donde:
CP: Es el costo de portabilidad.
CDR: Es el costo de re-desarrollo
Si GP > 0: La portabilidad es más rentable que el re-desarrollo.
Si GP = 1: La portabilidad es perfecta.
Si GP < 0: El re-desarrollo es más rentable que la portabilidad.
Considerando el número de archivos para que el sistema se transporte a otro
servidor se requiere solo que deba modificar el archivo propierties para el backend
y el archivo .config para el frontend.
Para el re-desarrollo consideramos el total de archivos que tiene el sistema en esta

versión.
Reemplazando estos datos en la ecuación 4.4.
2
𝐺𝑃 = 1 − = 0.06
155
Con este resultado podemos decir que la portabilidad es más rentable que el re-
desarrollo.
4.2 Seguridad
La seguridad es uno de los aspectos más importantes que se debe tomar en cuenta al
momento de implementar un sistema de información. Una vez registrados los datos en
el sistema, almacenamos información de mucha importancia para la toma de
decisiones por las cuales se deben considerar políticas de seguridad.
101
4.2.1 Seguridad en la base de datos
Se usó como base de datos MySQL el cual ya cuenta con sus propias medidas de
seguridad como la autentificación y el manejo de roles y privilegios. Para este
sistema se creó el esquema con el usuario manager el cual tiene todos los
privilegios con el que ya cuentan en su servidor y para los otros usuarios solo esta
con la opción de “read only”.
En cuanto a prevenir el SQL Injection se evitó el uso de SQL incorporado y en

cambio se usó QueryDSL que es un API de consultas para JPA más segura.
4.2.2 Autentificación
Para la autentificación se definió que se debe usar un usuario y contraseña.

Además, la información que se muestra al ingresar es de acuerdo al rol del usuario.
Se implementó un acceso con token para cada API con una expiración
parametrizable y que contiene los datos para verificar que usuario está utilizando
ese token.
4.2.3 Encriptación
Todas las contraseñas están encriptadas y son irreversibles, se usó la

implementación de Spring Security para el encriptado BCryptPasswordEncoder
que se basa en el algoritmo BCrypt para las contraseñas de hash.
4.2.4 Seguimiento de acciones de usuario
Para mejorar la seguridad se implementó un seguimiento de las acciones de

usuario, con el que se podrá saber quién modificó, creó o eliminó algún registro.
Además, se implementó un archivo de log para saber si existieron errores que no
fueron por la base de datos.
4.3 Costos
La técnica de análisis de costo y beneficio, tiene como objetivo fundamental

proporcionar una medida sobre la rentabilidad de un proyecto, haciendo una
comparación de los costos previstos con los beneficios esperados en la realización del
102
mismo. Esta técnica se debe utilizar al comparar proyectos y así poder tener una buena
toma de decisiones.
Como se mencionó en el capítulo II, se hará uso de la aplicación USC-COCOMO

II.2000.4 por su facilidad en los cálculos
4.3.1 Calculo del costo del sistema desarrollado
Para calcular el costo del sistema desarrollado tomaremos en cuenta los siguientes
puntos:
 El lenguaje de desarrollo define un multiplicador de acuerdo al

seleccionado, en el caso particular de este cálculo es JAVA y su valor es 53
 El salario mínimo en Bolivia es de 2.122 bolivianos que es alrededor de
305$.
 Las horas de trabajo en Bolivia son de 8 horas diarias de lunes a viernes lo
cual es alrededor 184 horas al mes.
En la figura 4.1 podemos observar las entradas de los puntos de función en la
aplicación USC-COCOMO II.2000.4 las cuales las detallamos y calculamos
previamente en la tabla 4.2.
103
Figura 4.1 Tabla de entradas de los puntos de función.
Fuente: USC-COCOMO II.2000.4
Con las variables ya declaradas en la aplicación obtenemos el resultado detallado

en la figura 4.2
Figura 4.2 Resultados obtenidos por la aplicación.

Fuente: USC-COCOMO II.2000.4
Analizando los datos obtenidos mediante la aplicación podemos detallar los

siguientes resultados:
104
 El tiempo de desarrollo es de 11 semanas.
 El número ideal de programadores es 3.
 El costo del proyecto es de 9499 dólares.
Para concluir podemos decir que el desarrollo será de dos meses y medio y el costo
en bolivianos del sistema es de 65225 bolivianos.
105
CAPÍTULO V
CONCLUCIONES Y RECOMENDACIONES
El presente capítulo se describen las conclusiones que se alcanzaron con el desarrollo

del proyecto y las recomendaciones que se da para futuras versiones.
5.1 Conclusiones
El objetivo general descrito en el capítulo I indica: “Desarrollar un sistema de gestión

de documentación de proyectos para tener un avance adecuado de los mismos.” En
el capítulo III presentamos todo el proceso de desarrollo que se hizo para crear este
sistema el cual ya registra la documentación de los proyectos y gracias a esto en la
empresa Innovative Apps se tiene un avance más fluido y rápido con sus proyectos.
Podemos concluir que el objetivo general fue alcanzado en su totalidad.
En cuanto a los objetivos específicos se detallan a continuación:
 “Determinar la bases teóricas y metodológicas acerca de la gestión de

documentos”, Las bases teóricas y metodológicas se detallan en el capítulo II,
los cuales aplicamos para el desarrollo en el capítulo III.
 “Analizar el estado de los procesos y procedimientos en la gestión de
documentos en la empresa Innovative Apps”, el análisis del estado se hizo en
el capítulo III, lo cual ayudó en la fase de exploración de la metodología.
 “Desarrollar los módulos para el sistema”, los módulos se desarrollaron en las
iteraciones detalladas en el capítulo III.
 “Evaluar la calidad y seguridad del software”, la evaluación de calidad y
seguridad esta detallada en el capítulo IV concluimos que la calidad del sistema
es aceptable y cuenta con todas las medidas de seguridad.
 “Aplicar el sistema de gestión de documentación de proyectos en la empresa
Innovative apps”, el sistema se encuentra ya en uso con los nuevos proyectos
de la empresa Innovative Apps.
Con base a todo lo expuesto podemos concluir que este sistema facilitará el manejo
de los documentos para mejorar el avance de los proyectos en la empresa Innovative
106
Apps. Además de que se logró demostrar que la aplicación cumple con los objetivos y
la justificación lo cual demuestra que es eficiente y una buena solución para esta
institución.
5.2 Recomendaciones
Las siguientes recomendaciones contribuirán en futuros desarrollos de sistemas con

SOLID:
 Los principios SOLID son buenas prácticas que pueden ayudar a escribir un
mejor código, más limpio, más escalable y mantenible.
 Las soluciones son heurísticas y con la práctica la implementación se vuelve
más fácil y entendible.
 Un código limpio tendrá más probabilidad de tener buena calidad.
 Los principios SOLID son una base para algunos patrones de diseño.
Las siguientes recomendaciones contribuirán en la ampliación del nivel de alcance

del presente proyecto:
 Agregar un módulo para la descarga de documentos públicos para dar a

conocer proyectos propios de la empresa.
 La creación de una aplicación móvil, la cual será más útil para los gerentes y
para el área comercial.
 Mantener la seguridad del sistema dando de baja los usuarios que ya no
necesitan los accesos al mismo y sin compartir usuarios en el uso diario del
sistema.
107
BIBLIOGRAFÍA
HERNÁNDEZ Sampieri, R., FERNÁNDEZ Collado, C., & BAPTISTA Lucio, P.

(2014). Metodología de la investigación, 6a. ed. México D.F.: McGraw-Hill.
RUSSO Gallo, P. (2009) “Gestión documental en las organizaciones”
RHOADS, James. (1995) La función de la gestión de documentos y archivos en los

sistemas nacionales de información. Bogotá; Archivo General de la Nación: UNESCO.
VILLCA Marca, Juana (2006) Modernización del centro de documentación para la

dirección de planificación y control.
RUIZ Cadena, Rudy (2014) Centro de Documentación Virtual CASO: Facultad de

Agronomía.
MUJICA Villa, Alejandra (2015) Sistema web de registro y control de documentación

ambiental caso: dirección de gestión y control ambiental.
D’ALÒS-MONER, Adela (2011) “Gestión de documentos: sonrisas y lágrimas”. El

profesional de la información.
PRESSMAN, Roger (2010) Ingeniería de software: Un enfoque práctico, 7ª ed. Madrid,

Mcgraw-Hill Interamericana
BOOCH, G., Rumbaugh, J., JACONSON, I., Unified Modeling Language User Guide,
Segunda Edición , Addison-Wesley Object Technology Series (2005).
AENOR (2006). UNE-ISO/TR 15489-2. Información y documentación – Gestión de

documentos - Parte 2: Directrices. Madrid: AENOR.
UNE-ISO 16175-1:2012 (2012). Información y documentación. Principios y requisitos

funcionales para documentos en entornos de oficina electrónica. Parte 1:
Generalidades y declaración de principios. Madrid: Aenor.
UNE-ISO 16175-2:2012 (2012). Información y documentación. Principios y requisitos

funcionales para documentos en entornos de oficina electrónica. Parte 2: Directrices y
requisitos funcionales para sistemas que gestionan documentos electrónicos. Madrid:
Aenor.
UNE-ISO 23081-1:2008. (2008). Gestión de documentos. Metadatos para la gestión
de documentos. Parte 1: Principios; Parte 2: Elementos de implementación y
conceptuales. Madrid: Aenor.
DEVELLIS, R. F. (1991). Scale development: Theory and applications. Newbury Park,

CA: Sage Publications.
BAUER, Fritz. NAUR, P y RANDELL, B (editores). Software Engineering: A report on

a Conference sponsored by the NATO Science Comittee/NATO. 1969 citada en
MARTIN, James y McCLURE, Carma. Structured Techniques for Computing. Prentice-
Hall. Englewood Cliffs, NJ, EE.UU. 1985.
PIATTINI, Mario, Calvo-Manzano José y Cervera Joaquín (2000). Análisis y diseño

detallado de aplicaciones informáticas de gestión, México, Alfaomega Grupo Editor.
RICHARDS Mark (2015) Software Architecture Patterns, O'Reilly Media, Inc.
Spring Boot (2.4.4) [Framework] Spring Boot Reference Documentation (2012).

Recuperado de https://docs.spring.io/spring-
boot/docs/current/reference/htmlsingle/#boot-documentation
React JS (17.0.2) [Framework] React Documentation (2020). Recuperado de

https://es.reactjs.org/docs/getting-started.html
MySql (8.0) [Gestor base de datos] MySQL Documentation (2020). Recuperado de

https://dev.mysql.com/doc/
DIAGRAMA RELACIONAL

PG-3819 Iso

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PG-3819 Iso

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRES

FACULTAD DE CIENCIAS PURAS Y NATURALES

Postulante: Edith Jhoselyn López Fernández

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

A mis hermanas y tíos por el apoyo

Al concluir esta etapa de mi vida quiero extender un profundo agradecimiento a quienes me

A la Empresa Innovative Apps por darme la oportunidad, apoyo, colaboración e información

La cantidad de información que se genera en las empresas crece de forma exponencial

El presente trabajo contiene el proceso de desarrollo del Sistema de gestión de

En el proyecto se realizó un análisis previo y con el mismo se realizó el diseño de cada

El sistema brinda la capacidad de llevar un control de la información y seguimiento de

Para la evaluación de la calidad se usó el estándar ISO 9126 y para la estimación de

Palabras clave: documentación, sistema web,proyectos, SOLID, XP, programación

This project works on the development of Management System of documentation’s

Palabras clave: documentation, web system, projects, SOLID, XP, extreme

La cantidad de información que se genera en las empresas crece de forma exponencial

Un sistema de gestión documental está diseñado para almacenar, administrar y

Las empresas de software manejan documentación a nivel técnico (Manuales de

Por lo cual, el presente proyecto plantea la implementación y diseño de un sistema de

Para tratadistas como Rhoads, la gestión de documentos se circunscribe a todo lo que

Considerando la temática que trata este proyecto se encontró proyectos similares en

“Modernización del centro de documentación para la dirección de planificación

“Centro de documentación virtual caso: facultad de agronomía”, que tiene como

“Sistema web de registro y control de documentación ambiental caso: dirección

Actualmente la empresa Innovative Apps genera documentos en forma indiscriminada

1.3.1. Problema principal

La falta de gestión de documentación de proyectos hace que los mismos no

1.3.2. Problemas secundarios

 Al momento de asignar un proyecto nuevo o ya en proceso a un miembro del

Es importante crear una solución para centralizar la información de la empresa

1.4.1. Objetivo general

1.4.2. Objetivos específicos

 Determinar la bases teóricas y metodológicas acerca de la gestión de

La implementación de un sistema de gestión de documentación de proyectos para la

Este sistema es una herramienta de apoyo para analizar la coherencia, continuidad y

Facilitará el acceso a los documentos de una manera rápida y eficaz reduciendo la

Según d’Alòs-Moner para asegurar la eficiencia de las organizaciones y su capacidad

 Accesibles, donde, cuándo y por quien sea necesario.

El desarrollo de este proyecto se realizará con la metodología XP porque es óptimo

Se realizará el diseño del proyecto en tres capas:

 Interfaz de usuario tomando como herramienta React.

 Análisis de requisitos, tiene como objetivo principal detectar conflictos en los

 Mantenimiento, El software indudablemente sufrirá cambios, y habrá que hacer

El aporte del proyecto es el uso de SOLID en el desarrollo del sistema.

1.8 Cronograma de acción

La Tabla 1.1 se define el cronograma de acción

Tabla 1.1 Cronograma de acción

Actividad Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6

Diseño de base de datos

En el presente capítulo detallamos los conceptos y definiciones que se necesitan en el

2.1 Antecedentes de la empresa Innovative Apps

Innovative Apps S.R.L. es una empresa orientada a satisfacer las necesidades

El ciclo de vida de la documentación de un proyecto es la siguiente:

 Cada proyecto es documentado desde la propuesta con un informe para el

Además, la empresa tiene documentos guía de instalación de las herramientas

2.2 Gestión de documentos

Las organizaciones necesitan una forma eficiente de ejercer control de documentos en

2.2.1. Bases teóricas

Gran parte de los profesionales suelen confundir la Gestión Documental con la