ESCUELA MILITAR DE INGENIERÍA

“Mcal. Antonio José de Sucre”

BOLIVIA

PROYECTO DE GRADO TÉCNICO

SISTEMA WEB PARA LA ADMINISTRACIÓN DE

EDIFICIOS

EST. MIGUEL JOAQUIN IRIARTE HUALLPA

LA PAZ, 2023
ESCUELA MILITAR DE INGENIERÍA
“Mcal. Antonio José de Sucre”
BOLIVIA

PROYECTO DE GRADO TÉCNICO

SISTEMA WEB PARA LA ADMINISTRACION DE

EDIFICIOS

EST. MIGUEL JOAQUIN IRIARTE HUALLPA

Modalidad: Proyecto de Grado

Técnico, presentado como
requisito para optar al Grado
Académico de Técnico Superior en
Informática

TUTOR: ING. LIZ WENDY SEPULVEDA MEDINA

LA PAZ, 2023
 DEDICATORIA

Quiero expresar mi más profundo agradecimiento y dedicar este Proyecto de Grado

Técnico a aquellos que han sido fundamentales en mi camino hacia el logro de mis
metas.

A: Dios, quien me ha acompañado en cada

paso y ha sido mi guía constante.

A: mi familia, y en especial a mis padres,

quienes han sido el pilar fundamental en mi
vida. Su amor, apoyo y sacrificio han sido la
base sólida sobre la cual construyó mis logros.
Estoy profundamente agradecido por su
constante aliento y por creer en mí incluso
cuando yo mismo dudaba.

A: mis hermanos, Luis, Joel y Vladimir, por su

apoyo incondicional y comprensión. Ellos han
estado a mi lado en todo momento,
recordándome la importancia del trabajo
arduo y la perseverancia en la búsqueda del
éxito.
 AGRADECIMIENTOS

A: mi familia por su confianza inquebrantable, comprensión y apoyo incondicional

en cada momento de mi vida. Su amor y respaldo han sido un pilar fundamental en
mi desarrollo académico y personal.

A: la Ing. Liz Wendy Sepúlveda Medina, quien ha sido mi tutora en este Trabajo de
Grado Técnico. Su disposición, orientación y dedicación han sido invaluables para
la elaboración de este proyecto. Agradezco sinceramente su tiempo y conocimiento
compartido.

A: los docentes de la Escuela Militar de Ingeniería de la carrera de Técnico Superior

en Informática. Gracias a sus enseñanzas a lo largo de estos años, adquirí los
conocimientos y habilidades necesarios para desarrollar este proyecto. Sus
dedicaciones y compromisos con la educación han sido de gran impacto en mi
formación.

A: mis camaradas de estudio, con quienes compartí momentos inolvidables a lo

largo de todos estos años. Agradezco su apoyo constante, su amistad y el ambiente
de compañerismo que hemos construido juntos. Los recuerdos que hemos creado
son verdaderamente gratos y valoro probablemente su presencia en mi vida.
ÍNDICE
 ÍNDICE

Pág.
CAPÍTULO 1. GENERALIDADES

Antecedentes legales ............................................................................. 2

Antecedentes académicos ..................................................................... 3

Identificación del problema ..................................................................... 5

Formulación del problema ...................................................................... 6

Objetivo general ..................................................................................... 6

Objetivo especifico ................................................................................. 6

Justificación técnica................................................................................ 7

Justificación social .................................................................................. 7

Justificación económica .......................................................................... 7

Límites .................................................................................................... 8

Alcances ................................................................................................. 8

[Link] Alcance geográfico ................................................................................. 8

[Link] Alcance temporal .................................................................................... 8

CAPITULO 2: MARCO TEÓRICO

xiii
 Metodología de desarrollo ágil ............................................................. 10

[Link] Planificación ......................................................................................... 11

[Link] Análisis ................................................................................................. 11

[Link] Diseño .................................................................................................. 11

[Link] Codificación .......................................................................................... 11

[Link] Integración ............................................................................................ 11

[Link] Mantenimiento ...................................................................................... 11

[Link] Principios ágiles.................................................................................... 12

Metodología scrum ............................................................................... 14

[Link] Elementos de scrum ............................................................................. 15

[Link] Roles .................................................................................................... 15

[Link] Fases de scrum .................................................................................... 15

[Link] Principales etapas de scrum ................................................................ 16

[Link] Principales características de las etapas de scrum .............................. 17

Ingeniería web ...................................................................................... 17

Características...................................................................................... 18

Modelo uwe .......................................................................................... 19

[Link] Modelo de requerimientos .................................................................... 19

[Link] Modelo de contenido y modelo de usuario ........................................... 19

[Link] Modelo de navegación ......................................................................... 19

[Link] Modelo de presentación ....................................................................... 20

xiv
 Laravel .................................................................................................. 23

[Link] Características...................................................................................... 24

[Link] ................................................................................................. 25

[Link] Características...................................................................................... 25

Php ....................................................................................................... 27

Javascript ............................................................................................. 27

Servidor apache ................................................................................... 28

Autenticación ........................................................................................ 29

Autorización .......................................................................................... 29

Cifrado .................................................................................................. 29

Hash ..................................................................................................... 29

Prueba testing ...................................................................................... 30

[Link] Las pruebas manuales ......................................................................... 30

[Link] Las pruebas automatizadas ................................................................. 30

Funciones de un administrador de edificios ......................................... 32

Principales dificultades de los administradores .................................... 33

Prorrateo .............................................................................................. 34

CAPITULO 3: MARCO PRÁCTICO

xv
 Fase de exploración ............................................................................. 40

Identificación de los involucrados ......................................................... 41

Recopilación de la información ............................................................. 42

[Link] Observación ......................................................................................... 42

Descripción de los procesos actuales .................................................. 42

[Link] Proceso de registro de los pagos de los gastos comunes ordinarios ... 42

[Link] Proceso de la reservación de las áreas comunes de un edificio .......... 43

Determinación de requerimientos ......................................................... 44

[Link] Identificar los actores de acuerdo al Scrum .......................................... 45

Pre-game .............................................................................................. 45

[Link] Planificación del sistema ...................................................................... 45

Game o development ........................................................................... 47

Diagrama de caso de uso general ........................................................ 48

[Link] Planificación de las iteraciones ............................................................ 49

[Link] Primer sprint registro de usuarios ........................................................ 49

Modelo de requerimientos .................................................................... 51

[Link] Diagramas de caso de uso ................................................................... 51

Modelo de contenidos ......................................................................... 53

Modelo navegacional............................................................................ 53

Modelo de presentación ....................................................................... 54

Segundo sprint módulo registro de roles .............................................. 55

Modelo de requerimientos .................................................................... 57

[Link] Diagramas de caso de uso ................................................................... 57

Modelo de contenidos .......................................................................... 58

xvi
 Modelo navegacional............................................................................ 59

Modelo de presentación ....................................................................... 60

Tercer sprint registro de apartamentos................................................. 61

Modelo de requerimientos .................................................................... 63

[Link] Diagrama de caso de uso ..................................................................... 63

Modelo de contenidos .......................................................................... 64

Modelo navegacional............................................................................ 65

Modelo de presentación ....................................................................... 66

Cuarto sprint registro de residentes...................................................... 67

Modelo de requerimientos .................................................................... 69

[Link] Diagramas de caso de uso ................................................................... 69

Modelo de contenidos .......................................................................... 70

Modelo navegacional............................................................................ 71

Modelo de presentación ....................................................................... 72

Quinto sprint registro de gastos comunes ............................................ 73

Modelo de requerimientos .................................................................... 75

[Link] Diagrama de caso de uso ..................................................................... 75

Modelo de contenidos .......................................................................... 76

Modelo navegacional............................................................................ 77

Modelo de presentación ....................................................................... 78

[Link] Sexto sprint cálculo de prorrateo .......................................................... 79

Modelo de requerimientos .................................................................... 81

[Link] Diagramas de caso de uso ................................................................... 81

Modelo de contenidos .......................................................................... 82

Modelo navegacional............................................................................ 83
xvii
 Modelo presentación ............................................................................ 84

[Link] Séptimo sprint registro de áreas comunes ........................................... 85

Modelo de requerimientos .................................................................... 87

[Link] Diagrama de caso de uso ..................................................................... 87

Modelo de contenidos .......................................................................... 88

Modelo navegacional............................................................................ 89

Modelo de presentación ....................................................................... 90

[Link] Octavo sprint reservación de espacios comunes ................................. 91

Modelo de requerimientos .................................................................... 93

[Link] Diagrama de caso de uso ..................................................................... 93

Modelo de contenidos .......................................................................... 94

Modelo navegacional............................................................................ 95

Modelo de presentación ....................................................................... 96

[Link] Noveno sprint registro de visitantes...................................................... 97

Módulo de requerimientos .................................................................... 99

[Link] Diagrama de caso de uso ..................................................................... 99

Modelo de contenidos ........................................................................ 100

Modelo navegacional.......................................................................... 101

Modelo de presentación ..................................................................... 102

[Link] Decimo sprint revisión de reportes ..................................................... 103

Modelo de requerimientos .................................................................. 105

[Link] Diagrama de caso de uso ................................................................... 105

Modelo de contenidos ........................................................................ 106

Modelo navegacional.......................................................................... 107

Modelo de presentación ..................................................................... 108

xviii
 Diseño de la base de datos ................................................................ 109

[Link] Modelo relacional de la base de datos ............................................... 110

[Link] Diccionario de datos. .......................................................................... 111

Diseño de Interfaz del sistema web .................................................... 114

[Link] Interfaz de autenticación .................................................................... 114

[Link] Interfaz de dashboard......................................................................... 115

[Link] Diseño de Interfaz del registro del apartamento ................................ 116

[Link] Diseño de la interfaz del registro de residente ................................... 116

[Link] Diseño de la interfaz de la gatos ........................................................ 117

[Link] Diseño de la interfaz del prorrateo...................................................... 118

[Link] Diseño de la interfaz de los áreas comunes ....................................... 119

[Link] Diseño de la interfaz de los reservaciones ......................................... 120

[Link] Diseño de la interfaz de los visitantes ................................................ 121

[Link] Diseño de la interfaz de los reportes .................................................. 122

[Link] Diseño de la interfaz de los usuarios .................................................. 123

[Link] Diseño de la interfaz de los roles........................................................ 124

Sprint 1 modelo de autenticación de usuarios .................................... 125

[Link] Planificación del sprint ........................................................................ 125

[Link] Desarrollo del sprint............................................................................ 126

Sprint 2 módulo de registro de apartamentos ..................................... 127

[Link] Planificación del sprint ........................................................................ 127

[Link] Desarrollo del sprint............................................................................ 128

Sprint 3 módulo de registro de apartamentos ..................................... 128

xix
[Link] Planificación del sprint. ....................................................................... 128

[Link] Desarrollo del sprint............................................................................ 129

Sprint 4 módulo de registro de residentes .......................................... 129

[Link] Planificación del sprint ........................................................................ 129

[Link] Desarrollo del sprint............................................................................ 130

Sprint 5 módulo de registro de gastos ................................................ 131

[Link] Planificación del sprint ........................................................................ 131

[Link] Desarrollo del sprint............................................................................ 131

Sprint 6 módulo de cálculo de prorrateo ............................................. 132

[Link] Planificación del sprint ........................................................................ 132

[Link] Desarrollo del sprint............................................................................ 132

Sprint 7 módulo de registro de áreas comunes .................................. 133

[Link] Planificación del sprint ........................................................................ 133

[Link] Desarrollo del sprint............................................................................ 133

Sprint 8 módulo de registro de reservaciones .................................... 134

[Link] Planificación del sprint ........................................................................ 134

[Link] Desarrollo del sprint............................................................................ 134

Sprint 9 módulo de registro de visitantes ............................................ 135

[Link] Planificación del sprint ........................................................................ 135

[Link] Desarrollo del sprint............................................................................ 135

Sprint 10 módulo de revisión de reportes ........................................... 136

[Link] Planificación del sprint ........................................................................ 136

[Link] Desarrollo del sprint............................................................................ 136

Pruebas unitarias del sistema ............................................................ 137

xx
[Link] Caso de prueba de autenticación de usuarios ................................... 137

[Link] Caso de prueba de registro de roles .................................................. 139

[Link] Caso de prueba de registro de apartamentos .................................... 140

[Link] Caso de prueba de registro de residentes .......................................... 141

[Link] Caso de prueba de registro de gastos comunes ................................ 142

[Link] Caso de prueba de registro de cálculo de prorrateo........................... 143

[Link] Caso de prueba de registro de áreas comunes .................................. 144

[Link] Caso de prueba de reservación de áreas comunes ........................... 145

[Link] Caso de prueba de registro de visitantes ........................................... 146

[Link] Caso de prueba de revisión de reportes ............................................. 147

Funcionalidad ..................................................................................... 148

Usabilidad ........................................................................................... 151

Mantebilidad ....................................................................................... 153

Portabilidad ........................................................................................ 154

Calidad total ....................................................................................... 155

Costos fijos ......................................................................................... 156

[Link] Compra de equipo .............................................................................. 156

[Link] Licencia de software ........................................................................... 156

[Link] Desarrollo de software ........................................................................ 157

Costos variables ................................................................................. 160

[Link] Recopilación de la información ........................................................... 160

xxi
[Link] Costo total del proyecto ...................................................................... 160

CAPITULO 4: CONCLUSIONES Y RECOMENDACIONES

BIBLIOGRAFIA

GLOSARIO

ANEXOS

xxii
 ÍNDICE DE FIGURAS
Pág.
Figura 1: Ciclo de desarrollo de software .............................................................. 12
Figura 2: Arquitectura de software ........................................................................ 13
Figura 3: Metodología scrum ................................................................................. 15
Figura 4: Fases de scrum ...................................................................................... 16
Figura 5: Organigrama de la administración de del edificio ................................... 41
Figura 6: Proceso de registro de los pagos de los gastos comunes ordinarios ..... 43
Figura 7: Proceso de la reservación de las áreas comunes de un edificio ............ 43
Figura 8: Orden jerárquico según al tipo de usuario .............................................. 46
Figura 9: Diagrama de caso de uso general ......................................................... 48
Figura 10: Diagrama de caso de uso registro de usuario ...................................... 51
Figura 11: Diagrama de contenido de registro de usuario ..................................... 53
Figura 12: Diagrama navegacional de registro de usuario .................................... 54
Figura 13: Diagrama de presentación de registro de usuario ................................ 55
Figura 14: Diagrama de caso de uso Módulo de registro de roles ........................ 57
Figura 15: Diagrama de contenido módulo de registro de roles ............................ 59
Figura 16: Diagrama navegacional de registro de roles ........................................ 60
Figura 17: Diagrama de modelo de presentación de registro de roles .................. 61
Figura 18: Diagrama de caso de uso de registro de apartamentos ....................... 63
Figura 19: Diagrama de contenido de registro de apartamentos........................... 65
Figura 20: Diagrama navegacional de registro de apartamentos .......................... 66
Figura 21: Diagrama de presentación de registro de apartamentos...................... 67
Figura 22: Diagrama de caso de uso de registro de residentes ............................ 69
Figura 23: Diagrama de contenido de registro de residentes ................................ 71
Figura 24: Diagrama navegacional de registro de residentes ............................... 72
Figura 25: Diagrama presentación de registro de residentes ................................ 73
Figura 26: Diagrama de caso de registro de gastos comunes .............................. 75
Figura 27: Diagrama de contenido de registro de gastos comunes ...................... 77
Figura 28: Diagrama navegacional de registro de gastos comunes ...................... 78
Figura 29: Diagrama de presentación de registro de gastos comunes. ................ 79
xxiii
Figura 30: Diagrama de caso de uso Módulo de cálculo de prorrateo .................. 81
Figura 31: Diagrama de contenido módulo de cálculo de prorrateo ...................... 83
Figura 32: Diagrama navegacional de cálculo de prorrateo .................................. 84
Figura 33: Diagrama de modelo de contenido de cálculo de prorrateo ................. 85
Figura 34: Diagrama de caso de uso de registro de áreas comunes .................... 87
Figura 35: Diagrama de contenido de registro de áreas comunes ........................ 89
Figura 36: Diagrama navegacional de registro de áreas comunes ....................... 90
Figura 37: Diagrama de presentación de registro de áreas comunes ................... 91
Figura 38: Diagrama de caso de uso reservación de espacios comunes ............. 93
Figura 39: Diagrama de contenido de reservación de espacios comunes ............ 95
Figura 40: Diagrama navegacional de reservación de espacios comunes ............ 96
Figura 41: Diagrama de presentación de reservación de espacios comunes ....... 97
Figura 42: Diagrama de caso de uso de registro de visitantes .............................. 99
Figura 43: Diagrama de contenido de registro de visitantes ............................... 101
Figura 44: Diagrama navegacional de registro de visitantes ............................... 102
Figura 45: Diagrama presentación de registro de visitantes ............................... 103
Figura 46: Diagrama de caso de uso de revisan de reportes .............................. 105
Figura 47: Diagrama de contenidos de seguimiento de revisión de reportes ...... 107
Figura 48: Diagrama navegacional de revisión de reportes ................................ 108
Figura 49: Diagrama de presentación de revisión de reportes ........................... 109
Figura 50: Diagrama entidad relación de la administración de edificio ................ 110
Figura 51: Diseño de la base de datos ................................................................ 111
Figura 52: Diseño de interfaz Inicio de sesión web. ............................................ 115
Figura 53: Diseño de interfaz de dashboard web. ............................................... 115
Figura 54: Diseño de interfaz del registro del apartamento ................................ 116
Figura 55: Diseño de Interfaz del registro de residente ...................................... 117
Figura 56: Diseño de la interfaz de la gastos ...................................................... 118
Figura 57: Diseño de la interfaz del prorrateo ..................................................... 119
Figura 58: Diseño de la interfaz de los áreas comunes ....................................... 120
Figura 59 Diseño de la interfaz de las reservaciones .......................................... 121
Figura 60 Diseño de la interfaz de los visitantes ................................................. 122
xxiv
Figura 61 Diseño de la interfaz de los reportes ................................................... 123
Figura 62 Diseño de la interfaz de los usuarios................................................... 124
Figura 63 Diseño de la interfaz de los roles ........................................................ 125
Figura 64: Interfaz de registro de usuarios .......................................................... 126
Figura 65: Interfaz de autenticación de usuarios ................................................. 127
Figura 66: Módulo de registro de roles ................................................................ 128
Figura 67: Interfaz de registro de apartamentos.................................................. 129
Figura 68: Interfaz de registro de residentes ....................................................... 130
Figura 69: Interfaz de registro de gastos ............................................................. 131
Figura 70: Interfaz de cálculo de prorrateo .......................................................... 132
Figura 71: Interfaz de registro de áreas comunes ............................................... 133
Figura 72: Interfaz de registro de reservaciones ................................................. 134
Figura 73: Interfaz de registro de visitantes ........................................................ 135
Figura 74: Interfaz de revisión de reportes .......................................................... 136

xxv
 ÍNDICE DE TABLAS
Pág.
Tabla 1: Planificación en base a la metodología scrum ........................................ 37
Tabla 2: Identificación de involucrados ................................................................. 41
Tabla 3: Especificación de requerimientos ............................................................ 44
Tabla 4: Tabla de actores de acuerdo al Scrum .................................................... 45
Tabla 5: Especificación de usuarios del sistema ................................................... 46
Tabla 6: Product backlog del sistema de administración para edificios ................. 47
Tabla 7: Id 1 del producto backlog ........................................................................ 49
Tabla 8: Primer sprint backlog módulo de registro de usuario .............................. 50
Tabla 9: Descripción del caso de registro de usuario ............................................ 52
Tabla 10: Id 2 del producto backlong .................................................................... 55
Tabla 11: Segundo sprint backlog módulo de registro de roles ............................. 56
Tabla 12: Descripción del caso de módulo de registro de roles ............................ 58
Tabla 13: Id 3 del producto backlog ...................................................................... 61
Tabla 14: Tercer sprint backlog módulo de registro de apartamentos ................... 62
Tabla 15: Descripción del caso de registro de apartamentos ................................ 64
Tabla 16: Id 4 del producto backlog ...................................................................... 67
Tabla 17: Cuarto sprint backlog módulo de registro de residentes........................ 68
Tabla 18: Descripción del caso de uso de estadísticas de la administración ........ 70
Tabla 19: Id 5 del producto backlog ...................................................................... 73
Tabla 20: Quinto sprint backlog módulo de registro de gastos comunes .............. 74
Tabla 21: Descripción del caso de seguimiento de la reservación ........................ 76
Tabla 22: id 6 del producto backlog ....................................................................... 79
Tabla 23: Sexto sprint backlog módulo de cálculo de prorrateo ............................ 80
Tabla 24: descripción del caso de módulo de cálculo de prorrateo ....................... 82
Tabla 25: Id 7 del producto backlog ...................................................................... 85
Tabla 26: Séptimo sprint backlog módulo de registro de áreas comunes ............. 86
Tabla 27: Descripción de caso de registro de áreas comunes .............................. 88
Tabla 28: Id 8 del producto backlog ...................................................................... 91
Tabla 29: Octavo sprint backlog módulo de reservación de áreas comunes ........ 92
xxvi
Tabla 30: Descripción de caso de reservación de espacios comunes .................. 94
Tabla 31: Id 9 del producto backlog ...................................................................... 97
Tabla 32: noveno sprint backlog módulo de registro de visitantes ........................ 98
Tabla 33: Descripción del caso de uso de registro de visitantes ......................... 100
Tabla 34: Id 10 del producto backlog .................................................................. 103
Tabla 35: Decimo sprint backlog módulo de revisión de reportes ....................... 104
Tabla 36: Descripción del caso de uso de revisión de reportes .......................... 106
Tabla 37: Descripcion tabla apartamentos .......................................................... 112
Tabla 38: Descripción tabla áreas comunes ....................................................... 112
Tabla 39: Descripción tabla residente ................................................................. 112
Tabla 40: Descripción tabla expense .................................................................. 112
Tabla 41: Descripción tabla gastos ..................................................................... 113
Tabla 42: Descripción tabla reportes ................................................................... 113
Tabla 43: Descripción tabla reservaciones .......................................................... 113
Tabla 44: Descripción tabla usuarios .................................................................. 113
Tabla 45: Descripción tabla roles ........................................................................ 114
Tabla 46: Descripción tabla sexos....................................................................... 114
Tabla 47: Primer sprint módulo de registro de usuarios ...................................... 126
Tabla 48: Segundo sprint registro de roles .......................................................... 127
Tabla 49: Tercer sprint registro de apartamentos................................................ 128
Tabla 50: Cuarto sprint de registro de gastos...................................................... 130
Tabla 51: Quinto sprint registro de gastos ........................................................... 131
Tabla 52: Sexto sprint cálculo de prorrateo ......................................................... 132
Tabla 53: Séptimo sprint registro de áreas comunes .......................................... 133
Tabla 54: Octavo sprint registro de reservaciones .............................................. 134
Tabla 55: noveno sprint registro de visitantes ..................................................... 135
Tabla 56: Decimo sprint revisión de reportes ...................................................... 136
Tabla 57: Escenario de plan de pruebas. ............................................................ 137
Tabla 58: Criterios de aceptación registro de usuarios ....................................... 138
Tabla 59: Suit de pruebas sprint 1 registro de usuarios ...................................... 138
Tabla 60: Prueba de registro de roles ................................................................. 139
xxvii
Tabla 61: Suit de pruebas sprint 2 registro de roles ............................................ 139
Tabla 62: Prueba de registro de roles ................................................................. 140
Tabla 63: Suit de pruebas sprint 3 registro de apartamentos .............................. 140
Tabla 64: Prueba de registro de residentes ........................................................ 141
Tabla 65: Suit de pruebas sprint 4 registro de residentes ................................... 141
Tabla 66: Prueba de registro de gastos comunes ............................................... 142
Tabla 67: Suit de pruebas sprint 5 registro de gastos comunes .......................... 142
Tabla 68: Prueba de registro de cálculo de prorrateo ......................................... 143
Tabla 69: Suit de pruebas sprint 6 registro de cálculo de prorrateo .................... 143
Tabla 70: Prueba de registro de áreas comunes................................................. 144
Tabla 71: Suit de pruebas sprint 7 registro de áreas comunes ........................... 144
Tabla 72: Prueba de reservación de áreas comunes .......................................... 145
Tabla 73: Suit de pruebas sprint 8 de reservación de áreas comunes ............... 145
Tabla 74: Prueba de registro de visitantes .......................................................... 146
Tabla 75: Suit de pruebas sprint 9 registro de visitantes ..................................... 146
Tabla 76: Prueba de revisión de reportes ........................................................... 147
Tabla 77: Suit de pruebas sprint 10 revisión de reportes .................................... 147
Tabla 78: Cálculo punto de función ..................................................................... 149
Tabla 79: Valores de ajuste de complejidad ........................................................ 149
Tabla 80: Ajuste de complejidad ......................................................................... 150
Tabla 81: Escala de ajustes de usabilidad .......................................................... 151
Tabla 82: Cuestionario de usabilidad .................................................................. 152
Tabla 83: Mantebilidad del sistema ..................................................................... 153
Tabla 84: Portabilidad ......................................................................................... 154
Tabla 85: Resultados calidad total ...................................................................... 155
Tabla 86: Costos fijos y variables ........................................................................ 155
Tabla 87: Factor LDC/PF de lenguajes de programación ................................... 157
Tabla 88: Costo de recopilación de información (expresado en Bs.) .................. 160
Tabla 89: Costo total del proyecto (expresado en Bs) ......................................... 161

xxviii
 INDICE DE ECUACIONES
Pág.
Ecuación 1: Puntos de función ajustada. ............................................................ 150
Ecuación 2: Hallar la usabilidad del software. ..................................................... 152
Ecuación 3: Índice de madurez del software. ...................................................... 153
Ecuación 4: Hallar líneas de código. ................................................................... 158
Ecuación 5: Hallar el esfuerzo. ............................................................................ 159
Ecuación 6: Hallar el tiempo. ............................................................................... 159

xxix
 INDICE DE ANEXOS

ANEXO A: Árbol de problemas

ANEXO B: Árbol de objetivos

ANEXO C: Requerimientos de desarrollo de software

ANEXO D: Cuestionario de usabilidad

xxx
RESUMEN
EJECUTIVO
 RESUMEN EJECUTIVO

El presente Proyecto de Grado Técnico denominado sistema web para la

administración de edificios, tiene como objetivo contribuir en las tareas y actividades
que realiza el administrador de un edifico, con una herramienta que permita un
adecuado control y seguimiento de ingresos y egresos.

Para alcanzar el objetivo propuesto, se ha dividido el presente documento en cuatro

capítulos principales.

En el Capítulo 1 “Generalidades”, se definió los problemas y metas que persigue el

proyecto que se determinaron a partir de un análisis de relevamiento específico y
consistente de las condiciones actuales que presenta la administración de un edificio.
Asimismo, la importancia del desarrollo del sistema, junto con el alcance y la
contribución que brindara.

En el Capítulo 2 “Marco Teórico”, se expone la base fundamental teórica en la que se

describe el proyecto dando los conceptos y la orientación metodológica necesaria para
apoyar el desarrollo del sistema propuesto.

En el Capítulo 3 “Marco Practico”, el desarrollo del proyecto se presenta de forma

detallada y concreta, organizado y ejecutado según la metodología SCRUM, que
incluye las principales etapas del desarrollo del sistema: planificación, desarrollo,
revisión y retrospectiva.

El capítulo 4 “Conclusiones y Recomendaciones”, se detalla las conclusiones extraídas

tras finalizar el Proyecto de Grado Técnico y las sugerencias sobre la funcionalidad del
sistema.
 CAPÍTULO 1

GENERALIDADES
 CAPÍTULO 1

GENERALIDADES

INTRODUCCIÓN

La evolución de la tecnología ha incrementado bastante en la actualidad, la

implementación de estos Sistemas de Información en un negocio o administración de
una empresa e edificio cualquiera sea esta, ha logrado mejorar la forma en la que
realizan sus procesos, la cantidad de datos que es necesario procesar, hace que la
automatización sea realmente necesaria.

Y más cuando se trata de administrar un edificio que está bajo una estructura jurídica
denominada propiedad horizontal de la ley del 30 de diciembre de 1949, la propuesta
de mi proyecto es desarrollar un sistema web que ayude a los administradores a tener
accesibilidad en el control de los gastos comunes, la reservación de áreas comunes y
saber cuentos residentes son en el condominio.

Para la creación del sistema se utilizará frameworks de código abierto, por la parte del
backend Laravel y [Link] en la parte de frontend, gestor de base de datos y la
metodología de desarrollo SCRUM con el modelado UWE.

Brindando un mayor control para el administrador de un edificio que ayudará a la

accesibilidad de la información de pagos de los gastos comunes y las reservaciones
de los espacios comunes que compone un condominio. Este proyecto busca
aprovechar los avances tecnológicos y la automatización para mejorar la eficiencia en
la administración de edificios bajo la estructura de propiedad horizontal, usar
herramientas y accesibilidad a los administradores para gestionar de manera más
efectiva los procesos y datos involucrados en la administración de un condominio.

1 - 163
 ANTECEDENTES

A continuación, presentaremos los antecedes legales y académicos sobre los cuales

se rige el presente Trabajo de Grado.

Antecedentes legales

En el campo del derecho, se utiliza una estructura jurídica denominada propiedad

horizontal, que hace referencia a un conjunto de normas de la ley que fue promulgada
el 30 Diciembre de 1949 en el Código Civil boliviano a un vigente para identificar de la
mencionada ley los artículos que son necesarios para el desarrollo del presente
proyecto.

Artículo 3°.- Se reputan bienes comunes los necesarios para la existencia,

seguridad, conservación del edificio y los que permitan a todos y a cada uno de
los propietarios el uso y goce del piso o departamento de su exclusivo dominio,
tales como el terreno, los Cimientos, los muros exteriores y soportantes, la obra
gruesa de los suelos, la techumbre, la habitación del portero y sus
dependencias, las instalaciones generales de calefacción, refrigeración, energía
eléctrica, alcantarillado y agua potable, los vestíbulos, terrazas, puertas de
entrada, escaleras, ascensores, patios, pozos y corredores de uso común,
desagües de aguas pluviales, etcétera. Los bienes a que se refiere el artículo
precedente en ningún caso podrán dejar de ser comunes.

Artículo 4°.- El derecho de cada propietario sobre los bienes comunes será
proporcional al valor del piso o departamento de su dominio. En proporción a
este mismo valor deberá contribuir a los gastos concernientes a dichos bienes,
particularmente a los de administración, mantenimiento y reparación y al pago
de servicios y primas de seguros. Todo lo cual se entiende sin perjuicio de las
estipulaciones expresas de las partes.

Artículo 5°.- La obligación del propietario de un piso o departamento por gastos

comunes sigue siempre al dominio del piso o departamento, aún respecto de

2 - 163
gastos devengados antes de su adquisición y el crédito gozará del privilegio
establecido por el Artículo 1454 del Código Civil. Lo anterior deberá entenderse
sin perjuicio del Derecho para exigir el pago al propietario constituido en mora,
aun cuando deje de poseer el pisó o departamento y salve además, la acción de
evicción del nuevo poseedor del piso o departamento contra quién haya lugar.

Artículo 6°.- Cada propietario podrá servirse a su arbitrio de los bienes comunes
siempre que los emplee según su destino ordinario y sin perjuicio del uso
legítimo de los demás.

Artículo 7°.- Los derechos y obligaciones de cada propietario en los bienes que
se reputan comunes son inseparables del dominio, uso y goce de su respectivo
piso o departamento. Por consiguiente, en la transferencia, trasmisión,
gravamen o embargo de un piso o departamento se entenderá comprendidos
esos derechos y no podrán efectuarse estos mismos actos con relación a ellos
separadamente del piso o departamento a que accedan.

Artículo 9°.- El propietario de cada piso o departamento podrá hipotecarlo o

gravarlo libremente, y dividido el inmueble de que forma parte en los casos en
que se proceda a la división conforme al Artículo 17º de esta ley, subsistirá la
hipoteca o el gravamen sin que para ello se requiera el consentimiento de los
propietarios de los demás pisos o departamentos. (Congreso nacional, 1949).

Antecedentes académicos

En la revisión bibliográfica efectuada para el presente Proyecto de Grado Técnico se

identificaron los siguientes trabajos.

“APLICACIÓN WEB PROGRESIVA PARA ADMINISTRACION E IDENTIFICACION

DE VEHICULOS”.
Realizado por el Licenciado Chipana Ticona Yasmani Roman, de la Carrera de
Ingeniería de Sistemas en la universidad Escuela Militar de Ingeniería, el año 2020,
cuyo propósito fue: “Desarrollar una aplicación web progresiva de administración e

3 - 163
identificación de los vehículos para disminuir los errores en la información y mejorar el
tiempo en el reporte vehicular. ”, (Roman, 2020).

La diferencia con el presente Trabajo de Grado, será enfocado a la administración de

un edificio para la accesibilidad de la información de los ingresos y egresos de los
gastos comunes ordinarios.

“MODELO DE GESTIÓN PÚBLICA DE ADMINISTRACIÓN DE BIENES Y

SERVICIOS PARA INCREMENTAR LA EFICIENCIA EN LAS DIRECCIONES
ADMINISTRATIVAS DEL EJÉRCITO DE BOLIVIA.”.

Realizado por el Licenciada Vargas Reyes Adriana Alejandra, de la Carrera de

Ingeniería Comercial en la universidad Escuela Militar de Ingeniería, el año 2019, cuyo
propósito fue: “Adecuar un modelo de gestión pública de Administración de Bienes y
Servicios para incrementar la eficiencia en la Dirección Administrativa del Ejército de
Bolivia.”, (Alejandra, 2019).

La diferencia con el presente Trabajo de Grado, será enfocado a la administración de

los ingresos y egresos de los gastos comunes ordinarios que es realizado en un edificio
e incrementar la eficiencia en el control de estos pagos mencionados.

“SISTEMA DE ADMINISTRACION PARA VENTA DEPRODUCTOS ARTESANALES

EMPLEANDO COMERCIO ELECTRONICO.”.

Realizado por el Licenciado Mendez Chávez Junior, de la Carrera de Ingeniería en

Sistemas en la universidad Escuela Militar de Ingeniería, el año 2020, cuyo propósito
fue: “Desarrollar un sistema de administración para ventas de productos artesanales
empleando comercio electrónico para controlar las ventas de productos de las
asociaciones artesanales en la ciudad de Riberalta.”, (Junior, 2020).

La diferencia con el presente Trabajo de Grado, será enfocado en el control de los

pagos de mantenimientos que son realizados en la áreas comunes de un edificio
agilizando así el proceso para el administrador.

4 - 163
 PLANTAMIENTO DEL PROBLEMA

En la última década, en el país se ha visto un vertiginoso despliegue de rascacielos

(edificios) y residenciales cerrados (departamentos) que han sido adaptados al
dominio legal a través de un régimen jurídico denominado propiedad horizontal, lo que
sugiere que un conjunto de reglas para edificaciones o terrenos públicos, que regula
la distribución y organización de las diversas propiedades.

El administrador como los propietarios de cada departamento tiene la dificultad con la

accesibilidad a la hora de adquirir la información de los reportes de cuentas de los
gastos comunes que representan aquellos ya considerados en el presupuesto, como
sueldos del personal, mantenimiento de espacios, reparaciones y de consumo, como
gas, electricidad, agua, gasto de reserva y otros.

Provocando una dificultad al administrador del edificio al no poder realizar un prorrateo

exacto y llevar el control de pagos que realiza cada propietario mensualmente de los
gatos comunes ordinarios, la falta de comunicación entre los propietarios hacia el
administrador del edificio genera una falta de control en las reservaciones de áreas
comunes, comunicados, mantenimientos y pagos de los gatos comunes que compone
y es parte del edificio.

Una administración inadecuada de un edificio puede tener consecuencias negativas

tanto en el mantenimiento y funcionamiento del edificio como en las relaciones entre
los propietarios.

Identificación del problema

La falta de control a los ingresos, egresos y reservaciones de las áreas comunes del
edificio provoca una deficiencia en los reportes de los gastos realizados sobre los
bienes comunes y sus mantenimientos, como los pagos realizados de los servicios
básicos para la rendición de cuentas a los residentes, por parte del administrador,
asimismo la falta de control en las reservas de las áreas comunes puede dar lugar a
conflictos entre los residentes y problemas en la administración de estos espacios. Si

5 - 163
no se lleva un registro adecuado de las reservas y no se establecen políticas claras al
respecto, es probable que se produzcan malentendidos y disputas entre los residentes.

Formulación del problema

La inadecuada administración de un edificio provoca una deficiencia en el control del

derecho de cada propietario sobre los bienes comunes en la contribución a los gastos
concernientes de mantenimiento, reparación, al pago de servicios.

OBJETIVOS

Objetivo general

Desarrollar un sistema web para la administración de edificios con la finalidad de

brindar un mayor control para el administrador de un edificio que ayudará a la
accesibilidad de la información de pagos de los gastos comunes y las reservaciones
de los espacios comunes que compone un condominio.

Objetivo especifico

 Analizar los procesos actuales de la administración de edificios para determinar a

los actores y sus características.

 Identificar los requerimientos funcionales y no funcionales para determinar las

necesidades del proceso de la administración del edificio.

 Diseñar una interfaz amigable que ayude de manera dinámica en la administración

del edificio en el control de los ingresos, egresos y las reservaciones de las áreas
comunes siendo accesible a la información para los residentes.

 Realizar las pruebas testing, para comprobar el correcto funcionamiento del

sistema con el control de la administración de un edificio en los ingresos, egresos
y la reservaciones de las áreas comunes.

6 - 163
 JUSTIFICACIÓN

Las justificaciones del presente Trabajo de Grado se sustentaran con los siguientes
puntos que se detallaran a continuación.

Justificación técnica

El sistema se realizará utilizando la metodología de desarrollo SCRUM con el

modelado UWE que está basada en el Proceso Unificado y para el desarrollo web, se
utilizará los Frameworks de código abierto, Laravel en la parte del backend que
proporciona seguridad de clase alta y su código de desarrollo web está seguro y
protegido y en frontend [Link] ayuda a desarrollar el proyecto en menor tiempo, y el
gestor de base de datos MySQL que es compatible con varios lenguajes para el
sistema

Justificación social

El presente Proyecto de Grado beneficiará a los administradores de los edificios de

vivienda como de comercio, al contar con una herramienta que facilite el trabajo e
información de los ingresos y egresos de las áreas comunes como los pagos de
servicio básicos, mantenimientos y seguridad de la comunidad.

Justificación económica

El presente Proyecto de Grado beneficiará a los administradores de un edificio de

vivienda como de comercio, tomando en cuenta que se desarrollara en software libre
con el beneficio que tenga más recursos económicos al no invertir en hojas de control
manual, el recibo de reportes de los pagos realizados de los gatos comunes ordinarios
y reservaciones de los espacios comunes para la rendición de cuentas a los
residentes. Este proyecto busca igual beneficiar a los administradores de edificios de
comercio que les permita optimizar sus procesos y recursos. Esto se traducirá en
ahorros económicos al eliminar la necesidad de utilizar hojas de control manual.

7 - 163
 LÍMITES Y ALCANCES

Límites

El presente Proyecto de Grado Técnico no contemplara los siguientes puntos:

 El sistema no aceptara pagos online de ningún tipo tanto como gastos

extraordinarios y ordinarios.

 El sistema no realizara la emisión de facturas para la declaración de impuestos.

 El sistema no podrá generar informes de ingresos y egresos.

Alcances

[Link] Alcance geográfico

El siguiente Proyecto de Grado se realizará para todas las administraciones de

edificios que se encuentran en el departamento de La Paz-Bolivia.

[Link] Alcance temporal

La elaboración del presente Proyecto de Grado se desarrollará de acuerdo con el

calendario académico de la Escuela Militar de Ingeniera de la gestión 2022 a la gestión
del 2023, donde se encuentran marcadas las fechas de presentación y defensa del
Proyecto de Grado.

8 - 163
 CAPÍTULO 2
MARCO TEÓRICO
 CAPÍTULO 2

MARCO TEÓRICO

ANÁLISIS DE SISTEMAS

Es el estudio de las especificaciones de dominio de los objetos que interactúan con

el propósito de comprender y documentar las características esenciales. Las
palabras claves son estudio comprensión y documentación. (Object Oriented
System Analysis). Otras definiciones del Análisis de sistemas:

 Análisis de sistema es modelar un sistema dentro de su entorno.

 Análisis de sistema es proceder a la definición de un problema, siendo la fase de
diseño la solución de ese problema.

En la actualidad para muchas organizaciones, los sistemas de información basados

en computadoras son el corazón de las actividades cotidianas y objeto de gran
consideración en la toma de decisiones, las empresas consideran con mucho
cuidados las capacidades de sus sistemas de información cuando deciden ingresar
o no en nuevos mercados o cuando planean la respuesta que darán a la
competencia

Este proceso también se denomina proceso de análisis de decisiones y se utiliza

para ayudar a evaluar problemas técnicos, alternativas y sus incertidumbres para
respaldar la toma de decisiones. ([Link], 2015).

Entonces el análisis del sistema es una de las etapas de la construcción de un

sistema informático. Esto incluye identificar información actual y proponer
características generales de soluciones futuras que se basaran en una descripción
ideal para el sistema.

9 - 163
 METODOLOGÍA DE DESARROLLO

Una metodología es un conjunto integrado de técnicas y métodos que permiten un

enfoque uniforme y abierto para cada actividad en el ciclo de vida de un proyecto
de desarrollo. Este es un proceso de software detallado y completo, se basa en una
combinación de modelos de procesos comunes. Identifican artefactos, funciones y
actividades, así como las mejores prácticas y técnicas. La metodología de desarrollo
de software es una forma sistemática de implementar, administrar y ejecutar un
proyecto para hacerlo con una alta probabilidad de éxito (Maida, 2015).

La metodología de desarrollo de software o metodología de desarrollo de sistemas

en ingeniería de software es un marco utilizado para estructurar, planificar y
controlar el proceso de desarrollo de sistemas de información.

Metodología de desarrollo ágil

Los procesos ágiles de desarrollo de software, conocidos anteriormente como

metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las
metodologías tradicionales enfocándose en la gente y los resultados.

Es un marco de trabajo conceptual de la ingeniería de software que promueve

iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen
muchos métodos de desarrollo ágil (Redhat, 2022).

El objetivo principal de los procesos ágiles es permitir la adaptabilidad y flexibilidad

durante el desarrollo de software, alentando la colaboración y la entrega continua
de valor al cliente. Estos métodos enfatizan la importancia de la comunicación
efectiva, el trabajo en equipo y la capacidad de respuesta a los cambios en los
requisitos o circunstancias del proyecto. El software desarrollado en una unidad de
tiempo es llamado una iteración, la cual debe durar de una a cuatro semanas. Cada
iteración del ciclo de vida incluye planificación, análisis, diseño, codificación,
integración y mantenimiento donde el incremento de software, se evalúa.

10 - 163
[Link] Planificación

Respecto a la Planificación se debe dividir en planificación estratégica, operativa de

contingencia la primera su trabajo es arduo y competitivo donde realiza los trabajos
de manera eficiente es importante tomar en cuenta las diversidades de estrategias
que pueden ser utilizados, además es de vital importancia en las aplicaciones de la
web progresivas el manejo operativo que nos dará una señal como se debe manejar
algunos factores de vital importancia en el sistema.

[Link] Análisis

El análisis es un estudio profundo en el ciclo de vida del software donde debemos

hacer por donde comenzar a realizar las alternativas indicadas para una buena toma
de decisiones respecto al sistema.

[Link] Diseño

El Diseño tiene la rentabilidad en el software de descomponer y organizar el sistema

para que los módulos puedan ser desarrollados por separado.

[Link] Codificación

La codificación es escribir el código fuente de cada módulo y realizar sobre ellos las
pruebas necesarias, es la aplicación de un lenguaje de programación en el sistema.

[Link] Integración

La integración es combinar todos los módulos y probar el sistema completo antes

de pasar a su explotación.

[Link] Mantenimiento

El mantenimiento en el ciclo de Software es la explotación es necesario realizar

cambios ocasionales bien para corregir errores o para introducir mejoras (IVAN,
2018).
11 - 163
 Figura 1: Ciclo de desarrollo de software

Fuente: Ivan, 2018.

Una iteración no debe agregar demasiadas funciones para justificar la

comercialización del producto, pero el objetivo es tener una demostración (sin
errores) al final de cada iteración, el equipo vuelve a evaluar las prioridades del
proyecto al final de cada iteración.

[Link] Principios ágiles

Los principios fundamentales de una metodología ágil se pueden resumir:

 Nuestra principal prioridad es satisfacer al cliente a través de la entrega

temprana y continua de software de valor cumpliendo los requisitos necesarios
para el sistema..

 Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo.

Los procesos ágiles se doblegan al cambio como ventaja competitiva para el
cliente y asi cumpliendo las necesidades del cliente para el sistema que se esta
desarrollando .
12 - 163
 Entregar con frecuencia software que funcione, en periodos de un par de
semanas hasta un par de meses, con preferencia en los periodos breves.

 Las personas del negocio y los desarrolladores deben trabajar juntos de forma
cotidiana a través del proyecto.

 La forma más eficiente y efectiva de comunicar información de ida y vuelta

dentro de un equipo de desarrollo es mediante la conversación cara a cara.

 El software que funciona es la principal medida del progreso.

 Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores,

desarrolladores y usuarios deben mantener un ritmo constante de forma
indefinida.

 La simplicidad como arte de maximizar la cantidad de trabajo que no se hace,

es esencial.

 Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto

organizan (Javier, 2021).

Figura 2: Arquitectura de software

Fuente: Javier, 2021.

13 - 163
 Metodología scrum

Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el

desarrollo de productos complejos desde principios de los años 90. Scrum no es un
proceso o una técnica para construir productos; en lugar de eso, es un marco de
trabajo dentro del cual se pueden emplear varias técnicas y procesos. Scrum
muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas
de desarrollo, de modo que podamos mejorar. El marco de trabajo Scrum consiste
en los Equipos Scrum, roles, eventos, artefactos y reglas asociadas. Cada
componente dentro del marco de trabajo sirve a un propósito específico y es
esencial para el éxito de Scrum y para su uso. Las reglas deScrum relacionan los
eventos, roles y artefactos, gobernando las relaciones e interacciones entre ellos.

Entorno: No sufre modificaciones de forma rápida, sino que se alargan en el tiempo.

 Cliente: Tiene muy claro que es lo que se necesita, sabe transmitirlo y nosotros
entendemos perfectamente sus necesidades.

 Equipo: Disponemos del equipo de profesionales necesario para poder atender

a esa necesidad y además sabemos cómo resolverla.

 Fases: Las fases se harían de una forma lineal, organizada y no surgiría ningún

 El cliente: Será la persona que nos está pidiendo una solución para un problema
específico.

 El usuario: La persona que utilizará esta nueva solución.

 El tiempo: El proyecto se atendrá a unas fechas de comienzo y unas fechas de

fin.

 Jefe de Proyecto: Figura necesaria para la gestión de los recursos, así como la
planificación del proyecto.

14 - 163
[Link] Elementos de scrum

Los elementos están compuestos por roles y artefactos quienes darán inicio para la
elaboración del SCRUM (Scrumstudy, 2013).

Figura 3: Metodología scrum

Fuente: Scrumstudy, 2013.

[Link] Roles

Personas involucradas que tienen diferente cargo en el momento de desarrollar el

SCRUM, está conformado por 3 roles principales:

 El Product Owner (Dueño del Producto)

 El Scrum Master (Dueño del proceso)
 Team (Miembros del Equipo de Desarrollo)

[Link] Fases de scrum

Scrum considera cinco fases de trabajo. Todas estas etapas están definidas por
tiempos máximos de ejecución y las reuniones se cronometran para no extenderlas
innecesariamente. De esta manera se garantiza que funcione como una
metodología ágil, las cuales son.

 Fase de Inicio: Crear la visión del proyecto, identificar al SCRUM Master,

formar equipos SCRUM.

15 - 163
 Fase de Planificación y estimación: Crear historias de usuario, estimar
historias de usuario, comprometer historias de usuario, identificar tareas,
estimar tareas.

 Fase de implementación: Crear entregables, realizar y refinar el producto.

 Fase de revisión y retrospectiva: Demostrar y validar el sprint y retrospectiva

del sprint.

 Fase de lanzamiento: Enviar entregables y retrospectiva del proyecto.

Figura 4: Fases de scrum

LANZAMIENTO INICIO

REVISION Y PLANIFICACION Y
RETROSPECTIVA ESTIMACION

IMPLEMENTACION

Fuente: Elaboración propia

[Link] Principales etapas de scrum

Posteriormente a los eventos se planifican las fases de Scrum la cual indica las
etapas, actividades y procesos que deben llevar los actores activos en el proceso
de acuerdo a: (Schwaber & Sutherland, 2020).

 Planificación del Sprint: Un mini proyecto dentro del proyecto principal, cada
uno de ellos tiene un objetivo en particular. Este plan resultante es creado por
el trabajo colaborativo de todo el equipo de Scrum.

16 - 163
 Etapa de desarrollo: Al realizar el trabajo de sprint, los encargados deben
asegurarse de que no haya cambios recientes que puedan afectar el objetivo
del sprint. Además, asegurarse de cumplir con los plazos estipulados adaptar
el Sprint según sea necesario, ajustando el próximo trabajo planeado.

 Revisión del Sprint: Al final del desarrollo del intervalo, los resultados se
pueden analizar y evaluar. Si es necesario, todo el equipo colaborará para
identificar las áreas que deben cambiarse, el propósito de la revisión es
inspeccionar el resultado del Sprint y determinar futuras adaptaciones.

 Retrospectiva del Sprint: El propósito de la retrospectiva Sprint es planificar

formas de aumentar la calidad y la eficacia, esta etapa permitirá que el
siguiente sprint pueda ser mucho más efectivo y ágil.

[Link] Principales características de las etapas de scrum

 El desarrollo de software se realiza mediante interacciones, denominadas

Sprint, con una duración variable de hasta 30 días. El resultado de cada sprint
es un incremento ejecutable que se muestra al cliente.

 Las reuniones a lo largo del proyecto, entre ellas la reunión que no dura más
de 15 minutos del equipó de desarrollo para la coordinación e integración.

Ingeniería web

El enfoque de diseño de UWE para procesos de negocios web consiste en introducir

clases de proceso específicas que forman parte de un modelo de proceso separado
con una interfaz definida para el modelo de navegación. Para modelar las
características adaptativas de las aplicaciones web de forma no invasiva, UWE
utiliza técnicas de modelado orientado a aspectos (AOM). Siguiendo el principio de
separación de preocupaciones, UWE propone construir un modelo adaptativo para
sistemas personalizados o dependientes del contexto y tejer los modelos después
para que el sistema sea más fácil de entender y diseñar.

17 - 163
Las principales razones para utilizar los mecanismos de extensión de UML en lugar
de técnicas de modelado propietarias son la aceptación de UML en el desarrollo de
sistemas de software, la flexibilidad para la definición de un lenguaje de modelado
específico del dominio Web: el llamado perfil UML, y Amplio soporte de modelado
visual por herramientas UML CASE existentes.

UWE utiliza notación UML "pura" y tipos de diagramas UML siempre que sea posible
para el análisis y diseño de aplicaciones Web, es decir, sin extensiones de ningún
tipo. Para las características específicas de la Web, como nodos y enlaces de la
estructura de hipertexto, el perfil UWE incluye estereotipos, valores etiquetados y
restricciones definidas para los elementos de modelado. La extensión UWE cubre
navegación, presentación, procesos comerciales y aspectos de adaptación. La
notación UWE se define como una extensión "ligera" de UML (Universidad tecnica
del norte, 2015).

Uwe cubre todo el ciclo de la vida de este tipo de aplicaciones centrando además
su atención en aplicaciones personalizadas o adaptativas para tener un diseño más
simple.

Características

La metodología UWE define vistas especiales representadas gráficamente por

diagramas en UML, tales como el modelo de navegación y el modelo de
presentación.

Los diagramas se pueden adaptar como mecanismos de extensión basados en

estereotipos que proporciona UML. Estos mecanismos de extensión son los que
UWE utiliza para definir estereotipos que son los que final- mente se utilizarán en
las vistas especiales para el modelado de aplicaciones Web.

De esta manera, se obtiene una notación UML adecuada para un dominio específico
a la que se conoce como perfil UML (Lmu – ludwig-maximilians-universität münche,
2022).

18 - 163
 Modelo uwe

El método UWE consiste en la construcción de seis modelos de análisis y diseño.

Dicha construcción se realiza dentro del marco de un proceso de diseño iterativo e
incremental. Las actividades de modelado abarcan: el análisis de requerimientos,
diseño conceptual, modelo de usuario, diseño de la navegación, de la presentación
y diseño de la adaptación.

[Link] Modelo de requerimientos

El primer paso para el desarrollo de un sistema web que se especificará con UWE,
es realizar la identificación de los requerimientos y plasmarlos en un modelo de
requerimientos.

Los requerimientos pueden ser documentados en diferentes niveles de detalle, para

este caso, UWE propone dos niveles de granularidad. En primera instancia se
deben describir detalladamente las funcionalidades del sistema, las cuales son
modeladas con casos de uso UML. Como segundo paso, se debe elaborar una
descripción de los casos de uso más detallada.

[Link] Modelo de contenido y modelo de usuario

El diseño conceptual se basa en el modelo de análisis e incluye los objetos

involucrados en las actividades típicas que los usuarios realizan con la aplicación.

El propósito del modelo de contenido es proporcionar una especificación visual de

la información relevante para el dominio del sistema web, que comprende
principalmente el contenido de la aplicación Web.

[Link] Modelo de navegación

El modelo de estructura de navegación define la estructura de nodos y links de una

WebApp mostrando cómo se puede realizar la navegación utilizando elementos de

19 - 163
acceso tales como índices, visitas guiadas, consultas y menús los elementos de
modelado son:

 Clases de navegación, que se denotan con (0), representan los nodos

navegables de la estructura de hipertexto.
 Links de navegación, que muestran el vínculo directo entre las clases de
navegación.

 Caminos de navegación alternativos, los cuales son visualizados con el

estereotipo <<menu>> ( ).

 Primitivas de acceso, las cuales se utilizan ya sea para llegar a múltiples

instancias de una clase de navegación (<<index>> o <<guided tour>>) o para
seleccionar ítems (<<query>>).

 Clases de procesos, las cuales modelan los puntos de entrada y de salida de

los procesos de negocio. Cada clase de proceso está asociada a un caso de
uso de proceso.

 Links de procesos, que representan el vínculo entre las clases de proceso y de

navegación.

El modelo de estructura de navegación se representa mediante diagramas de clases

UML estereotipados con las clases de navegación y procesos, menús y primitivas
de acceso y así también los links de navegación y proceso.

[Link] Modelo de presentación

El modelo de presentación proporciona una vista abstracta de la interfaz de usuario

(UI) de la aplicación web. Se basa en el modelo de navegación y describe qué
elementos (por ejemplo texto, elementos, links, formularios) se utilizarán para
presentar los nodos de navegación, los elementos básicos del modelo de
presentación son:

20 - 163
 Clases de presentación, las cuales se basan directamente en los nodos del
modelo de navegación. Una clase de presentación ( ) está compuesta por
elementos de UI tales como, texto (<<text>> ), vinculo (<<anchor>> ), botón
(<<button>> ), imagen (<<image>> ), formulario (<<form>> ), y colección de
vínculos (<<anchored collection>> )

 Páginas web (<<page>>), que se utilizan para modelar la información

proveniente de varios nodos de navegación y que se presentan en una misma
página web.

 Grupo de presentación (<<presentation group>>), el cual es un contenedor de

clases de presentación, y a su vez de otros grupos de presentación (Daniel the
wolf, 2015).

BASE DE DATOS

Una base de datos es una colección organizada de información o datos

estructurados, generalmente almacenados electrónicamente en un sistema
informático. Una base de datos generalmente está controlada por un sistema de
administración de bases de datos (DBMS). En conjunto, los datos, el DBMS y las
aplicaciones relacionadas se denominan sistema de base de datos. La mayoría de
las veces simplemente se abrevia como base de datos. 17 - 29 Los datos de los
tipos más comunes de bases de datos en funcionamiento en la actualidad se utilizan
a menudo como la estructura de filas y columnas de varias tablas para aumentar la
eficiencia del procesamiento y la recuperación de datos. De esta forma, los datos
se pueden recuperar, administrar, modificar, actualizar, controlar y organizar
fácilmente. La mayoría de las bases de datos utilizan el lenguaje de consulta
estructurado (SQL) para escribir y consultar datos.
Esto se conoce como modelos de base de datos y permite el diseño y la
implementación de algoritmos y otros mecanismos lógicos de gestión, según sea el
caso (Oracle, 2022).

21 - 163
 MySQL

MySQL tiene una interfaz visual, todas las opciones y herramientas disponibles,
puede usarse para almacenar toda la información requerida en una base de datos
relacional y puede administrar fácilmente todos estos datos como lo menciona
(Camps-Pare et al., 2005, p. 235) MySQL es un sistema gestor de bases de datos
(SGBD, DBMS por sus siglas en inglés) muy conocido y ampliamente usado por su
simplicidad y notable rendimiento.

A continuación, se mencionan las características más importantes, entre las que

podemos mencionar las siguientes:

 Acceso a las bases de datos de forma simultánea por varios usuarios y/o
aplicaciones.

 Seguridad, en forma de permisos y privilegios, determinados usuarios tendrán

permiso para consulta o modificación de determinadas tablas. Esto permite
compartir datos sin que peligre la integridad de la base de datos o protegiendo
determinados contenidos.

 Potencia: SQL es un lenguaje muy potente para consulta de bases de datos,

usar un motor nos ahorra una enorme cantidad de trabajo

 Portabilidad: SQL es también un lenguaje estandarizado, de modo que las

consultas hechas usando SQL son fácilmente portables a otros sistemas y
plataformas. Esto, unido al uso de C/C++ proporciona una portabilidad enorme.
(MySQL, 2022)

FRAMEWORKS

Un framework es un entorno de trabajo que tiene como objetivo facilitar la

programación al proporcionar un conjunto de características que aceleran los
procesos, reducen los errores, promueven la colaboración y dan como resultado

22 - 163
productos de mayor calidad. Aunque el framework proporciona una estructura para
el desarrollo y no necesita estar regido por un solo lenguaje de programación, a
menudo hay diferentes marcos en el mercado que son específicos para un lenguaje
en particular. Los desarrolladores pueden crear sitios web o programas sin
frameworks, especialmente para proyectos pequeños. Sin embargo, a medida que
los proyectos se vuelven más complejos, las organizaciones requieren seguir
algunas pautas, desarrollar código que sea fácil de entender para otros
desarrolladores y otros aspectos que requieren el uso de frameworks.

El hecho de escribir código o desarrollar una aplicación más fácilmente te sirve para
tener una mejor organización y control de todo el código elaborado, pudiendo usarlo
nuevamente en el futuro.

Al reducir tiempos implica una mayor productividad, del mismo modo que reutilizar
recursos te lleva a minimizar riesgos. Por ello, usar uno o varios frameworks supone
una gran ayuda para programadores y desarrolladores, ya que facilita sus tareas de
forma considerable (Seoestudios, 2020).

Backend y frontend

El frontend es la parte de un sitio web que interactúa con los usuarios, por eso
decimos que está del lado del cliente.

El backend es la parte que se conecta con la base de datos y el servidor que utiliza
dicho sitio web (Platzi, 2018).

Laravel

Laravel es un marco de aplicación web con una sintaxis expresiva y elegante.

Creemos que el desarrollo debe ser una experiencia agradable y creativa para que
sea realmente satisfactorio. Laravel intenta eliminar el dolor del desarrollo al facilitar
las tareas comunes que se utilizan en la mayoría de los proyectos web, como la
autenticación, el enrutamiento, las sesiones y el almacenamiento en caché.

23 - 163
Laravel tiene como objetivo hacer que el proceso de desarrollo sea agradable para
el desarrollador sin sacrificar la funcionalidad de la aplicación. Laravel es accesible,
pero poderoso, y proporciona herramientas poderosas necesarias para aplicaciones
grandes y robustas. Una excelente inversión del contenedor de control, el sistema
de migración expresivo y el soporte de pruebas unitarias estrechamente integrado
le brindan las herramientas que necesita para crear cualquier aplicación con la que
tenga la tarea.

[Link] Características

Contiene además un amplio conjunto de características, que sirven para realizar la

mayoría de las aplicaciones web. Entre ellas podemos encontrar.

 Un sistema de rutas, mediante las cuales es fácil crear y mantener todo tipo de
URLs amistosas a usuarios y buscadores, rutas de API, etc.

 Un sistema de abstracción de base de datos, con un ORM potente pero sencillo

de manejar, mediante el que podemos tratar los datos de la base de datos como
si fueran simples objetos.

 Un sistema para creación de colas de trabajo, de modo que es posible enviar

tareas para ejecución en background y aumentar el rendimiento de las
aplicaciones.

 Varias configuraciones para envío de email, con proveedores diversos.

 Un sistema de notificaciones a usuarios, mediante email, base de datos y otros

canales.

 Una abstracción del sistema de archivos, mediante el cual podemos escribir

datos en proveedores cloud, y por supuesto en el disco del servidor, con el
mismo código.

 Gestión de sesiones.

24 - 163
 Sistema de autenticación, con todo lo necesario como recordatorios de clave,
confirmación de cuentas, recordar un usuario logueado, etc.

La posibilidad de acceder a datos en realtime y recibir notificaciones cuando éstos

se alteran en la base de datos (Laravel, 2022).

[Link]

Está diseñado para crear aplicaciones de red escalables. En el siguiente ejemplo

de "hola mundo", se pueden manejar muchas conexiones al mismo tiempo. En cada
conexión, se activa la devolución de llamada, pero si no hay trabajo por hacer,
[Link] se suspenderá.(Node,js, 2022).

[Link] Características

 [Link] es similar en diseño e influenciado por sistemas como Event Machine

de Ruby y Twisted de Python

 [Link] lleva el modelo de eventos un poco más allá. Presenta un bucle de

eventos como una construcción en tiempo de ejecución en lugar de como una
biblioteca. En otros sistemas, siempre hay una llamada de bloqueo para iniciar
el bucle de eventos. Por lo general, el comportamiento se define a través de
devoluciones de llamada al comienzo de un script y, al final, se inicia un servidor
a través de una llamada de bloqueo como EventMachine::run().

 Se trata de un framework de concurrencia http es un ciudadano de primera clase

en [Link], diseñado teniendo en cuenta la transmisión y la baja latencia. Esto
hace que [Link] sea ideal para la base de una biblioteca o marco web.

 A los desarrolladores que provienen de lenguajes o frameworks exclusivamente

de backend están acostumbrados a ciertos patrones de programación que no
son exactamente iguales en frontend. Es aconsejable aprender ciertas bases

25 - 163
 de frontend general. Una buena base de Javascript también es muy
recomendable.

 [Link] le da mayor protagonismo al enfoque tradicional «centrado en HTML»

así como a los sistemas de plantillas. Si te gustan, [Link] probablemente te
resulte muy atractivo (Roman M. J., 2022).

LENGUAJE DE PROGRAMACION

Un lenguaje de programación es un lenguaje de computadora que los

programadores utilizan para comunicarse y para desarrollar programas de software,
aplicaciones, páginas webs, scripts u otros conjuntos de instrucciones para que
sean ejecutadas por los ordenadores.

Así como los idiomas que utilizan los humanos para comunicarse, los ordenadores
tienen sus propios lenguajes de programación. Cada lenguaje de programación
tiene un conjunto único de palabras clave (palabras que entiende) y una sintaxis
especial para organizar las instrucciones del programa específico de programación.

Estos lenguajes de programación vienen en forma de instrucciones o secuencias de

órdenes en forma de algoritmos con el fin de controlar el comportamiento físico o
lógico del ordenador, de manera que se puedan obtener diversas clases de datos o
ejecutar determinadas tareas.

El profesional encargado de ejecutar estos lenguajes de programación se llama

programador o desarrollador web.

Estos especialistas pueden desarrollar un sinfín de softwares, aplicaciones y

páginas web utilizando distintos tipos de lenguajes de programación que respondan
a cada necesidad tecnológica (Wild code school, 2021).

El lenguaje de programación es un conjunto de uso para crear software y

aplicaciones. Permite a los programadores comunicarse con las computadoras.

26 - 163
 Php

PHP (Hypertext Preprocessor) es un lenguaje de código abierto muy popular

especialmente adecuado para el desarrollo web y que puede ser incrustado en
HTML.

Lo que distingue a PHP de algo del lado del cliente como Javascript es que el código
es ejecutado en el servidor, generando HTML y enviándolo al cliente. El cliente
recibirá el resultado de ejecutar el script, aunque no se sabrá el código subyacente
que era.

El servidor web puede ser configurado incluso para que procese todos los ficheros
HTML con PHP, por lo que no hay manera de que los usuarios puedan saber qué
se tiene debajo de la manga (Php, 2022).

Javascript

JavaScript es un lenguaje de programación que los desarrolladores utilizan para

hacer páginas web interactivas. Desde actualizar fuentes de redes sociales a
mostrar animaciones y mapas interactivos, las funciones de JavaScript pueden
mejorar la experiencia del usuario de un sitio web.

Como lenguaje de scripting del lado del servidor, se trata de una de las principales
tecnologías de la World Wide Web. Por ejemplo, al navegar por Internet, en
cualquier momento en el que vea un carrusel de imágenes, un menú desplegable
“click-to-show” (clic para mostrar), o cambien de manera dinámica los elementos de
color en una página web, estará viendo los efectos de JavaScript (Amazon web
service, 2022).

JavaScript es un lenguaje de programación que se utiliza ampliamente para crear

páginas web interactivas. Con JavaScript, los desarrolladores pueden agregar una
variedad de funciones y efectos a un sitio web para mejorar la experiencia del
usuario y asi pueden mejorar la experiencia del usuario de un sitio web

27 - 163
 SERVIDOR WEB

Un servidor web es un software que forma parte del servidor y tiene como misión
principal devolver información (páginas) cuando recibe peticiones por parte de los
usuarios.

En otras palabras, es el software que permite que los usuarios que quieren ver una
página web en su navegador puedan hacerlo (Web empresa, 2022).

Servidor apache

Apache, un servidor web de código abierto creado por un desarrollador de software

estadounidense Roberto MacCool. Apache se lanzó en 1995. A principios de la
década de 2020, los servidores Apache implementaron alrededor del 30 por ciento
del contenido de Internet, solo superados por Apache, Nginx.
Como servidor web, Apache es responsable de aceptar solicitudes de directorio
(HTTP) de los usuarios de Internet y enviarles la información deseada en forma de
archivos y páginas web. Gran parte del software y el código de la Web están
diseñados para funcionar junto con las características de Apache. Los
programadores que trabajan en aplicaciones web suelen utilizar una versión
doméstica de Apache para obtener una vista previa y probar el código. Apache
también tiene una función segura para compartir archivos, que permite a los
usuarios colocar archivos en el directorio raíz de su software Apache y compartirlos
con otros usuarios. El impacto del servidor Apache en la comunidad de software de
código abierto se explica en parte por la licencia única a través de la cual se
distribuye el software de Apache Software Fundación (Britannica, 2022).

SEGURIDAD DE SISTEMAS

La seguridad del sistema se refiere a proteger la integridad, confidencialidad y

disponibilidad de los sistemas informáticos y la información que contienen. Esto
incluye implementar medidas y controles para prevenir y mitigar los riesgos de

28 - 163
seguridad de la información y proteger los activos digitales y los recursos del
sistema de amenazas y ataques maliciosos.

Autenticación

Laravel se envía con un sessionprotector que mantiene el estado mediante

almacenamiento de sesión y cookies.

Los proveedores definen cómo se recuperan los usuarios de su almacenamiento

persistente. Laravel viene con soporte para recuperar usuarios usando Eloquent y
el generador de consultas de bases de datos.

Autorización

Laravel también proporciona una forma sencilla de autorizar las acciones del usuario
contra un recurso determinado. Por ejemplo, aunque un usuario esté autenticado,
es posible que no esté autorizado para actualizar o eliminar ciertos modelos de
Eloquent o registros de bases de datos.

Cifrado

Los servicios de encriptación de Laravel brindan una interfaz simple y conveniente

para encriptar y desencriptar texto a través de OpenSSL usando encriptación AES-
256 y AES-128. Todos los valores cifrados de Laravel se firman con un código de
autenticación de mensajes (MAC) para que su valor subyacente no se pueda
modificar ni alterar una vez cifrado.

Hash

La Hash fachada de Laravel proporciona hash seguro de Bcrypt y Argon2 para

almacenar las contraseñas de los usuarios. Si está utilizando uno de los kits de inicio
de la aplicación Laravel, Bcrypt se utilizará para el registro y la autenticación de
forma predeterminada, el hash resulta una representación única e irreversible de la
contraseña original.

29 - 163
Bcrypt es una excelente opción para cifrar contraseñas porque su "factor de trabajo"
es ajustable, lo que significa que el tiempo que lleva generar un hash puede
aumentar a medida que aumenta la potencia del hardware. Al codificar contraseñas
(Laravel, 2022).

Prueba testing

De manera general, lo primero que debemos tener en cuenta es que existen

pruebas de software manuales y pruebas de software automatizadas.

[Link] Las pruebas manuales

Son llevadas a cabo por personas, quienes navegan e interactúan con el software
(usando herramientas adecuadas para cada caso).

Estas pruebas resultan costosas, ya que se requiere contar con un profesional

encargado de esta labor; para configurar un entorno y así mismo ejecutar las
pruebas.
Como es de esperarse, estas pruebas están expuestas a errores humanos: por
ejemplo, se pueden cometer errores tipográficos u omitir pasos durante la prueba.

[Link] Las pruebas automatizadas

Por el contrario, son realizadas por máquinas, que ejecutan un "test script" que ya
ha sido escrito previamente, estos tests (o pruebas) pueden variar mucho en cuanto
a complejidad:

 Desde verificar que el método de una clase específica funcione correctamente,

 Hasta asegurar que una secuencia de acciones complejas en la UI se lleven a
cabo correctamente y devuelvan los resultados esperados.

Estas pruebas son más rápidas y confiables que las que se llevan a cabo
manualmente pero la calidad de estas pruebas automatizadas depende de qué tan
bien escritos se encuentren los "tests scripts" (el código que determina qué es lo

30 - 163
que se hará en la prueba para las pruebas automatizadas) y de esta forma asegurar
que el sistema rinda a su mejor capacidad y realice su funcionamiento
correctamente para la devolución de resultados esperados.

a) Smoke testing

Las pruebas de humo son pruebas que verifican la funcionalidad básica de una
aplicación.

 Se pretende que sean pruebas rápidas de ejecutar, y su objetivo es asegurar

que las características más importantes del sistema funcionan como se espera.

Los smoke tests pueden ser muy útiles:

 Justo después de construir una nueva versión de nuestra aplicación, para

decidir si estamos listos para ejecutar pruebas más costosas,

 Justo después de un proceso de deployment, para asegurar que la aplicación

está funcionando adecuadamente en el nuevo entorno desplegado.

 Son un conjunto de pruebas automatizadas de alto nivel, y seleccionadas

estrictamente.

 Tienen lugar entre las pruebas de integración y las pruebas de regresión. Y

están ahí para verificar que la funcionalidad principal del sitio opera como es
debido.

 Se dice que el término "prueba de humo" tiene su origen en la plomería. Si se

podía ver humo saliendo de una tubería, significaba que tenía fugas y era
necesario hacer reparaciones.

No son pruebas específicas. Son pruebas significativas que ocurren a un nivel más
general. Idealmente deben ejecutarse cada día, en cada uno de los entornos.
De modo que si un smoke test falla, significa que hay un grave problema con la
funcionalidad de nuestro software (Jess, 2018).
31 - 163
 ADMINISTRACIÓN DE EDIFICIOS

Es una disciplina que proviene de facility management. Este rubro se encarga de

supervisar los servicios duros y blandos de un edificio, lo que garantiza que la
seguridad, la salud, la organización, el cumplimiento de leyes y el mantenimiento de
estructuras se cumplan en un nivel satisfactorio. Hay esencialmente dos tipos de
edificios donde se ejerce esta actividad: residenciales y comercial. Los servicios
duros por lo general se refieren a los servicios físicos, estructurales, tales como
sistemas de alarma contra incendios, cámaras ascensores, etc., mientras que
aluden los servicios blandos como: limpieza, jardinería, seguridad, RRHH, en
general servicios de origen humano.

Funciones de un administrador de edificios

 Conocer las disposiciones legales sobre copropiedad, propiedad exclusiva y

común, así como la legislación laboral para poder ejercer su cargo en la forma
más correcta posible.

 Hacerse cargo de la parte administrativa de la comunidad. Esto implica ser el

responsable de los sueldos y el cobro de los gastos comunes, por ejemplo.

 Velar porque los trabajadores del condominio realicen correctamente sus

funciones y cumplan con sus responsabilidades.

 La mantención del condominio. Generar todos los contratos y todas las labores
de mantención necesarias para que en el condominio no deje de funcionar en
ninguna de sus dependencias o instalaciones. Para eso se requieren
mantenciones preventivas. Adicionalmente a esto, el administrador debe saber
reaccionar ante las eventualidades, por ejemplo, rotura de cañerías, desagües,
incendios, terremotos, etc. Esto implica tener un contingente de personal al cual
contactar y solicitar los arreglos correspondientes.

 Mantener una buena coordinación y comunicación con el comité de

administración y los copropietarios, de manera que se puedan recoger
32 - 163
 correctamente las inquietudes y prioridades que tiene el comité y poder
desarrollar su función de acuerdo a esas prioridades. Además, entregar la
información lo más completa y clara posible.

 Rendir cuenta a la comunidad en los tiempos acordados y al término de su

relación con la comunidad.

 Debe tener un manejo cuidadoso de los recursos de la comunidad, debe hacerlo

en forma transparente para que todos puedan saber en qué se gastan los
recursos.

Principales dificultades de los administradores

 La falta de recursos económicos.

 La falta de conocimiento o falta de compromiso del comité de administración

que entorpecen la labor de administración.

 Los propietarios y residentes que no comprenden las implicancias de vivir en un

condominio donde deben respetar las normas establecidas en el reglamento de
copropiedad.

 La falta de experiencia o de conocimientos del mismo administrador ante

algunas situaciones (Bienes raices, 2022).

CONDOMINIO

Un edificio (propiedad horizontal) o condominio, una urbanización, están

conformados por departamentos, estacionamientos cubiertos, bauleras, locales
comerciales y casas o viviendas unifamiliares, denominados inmuebles, con acceso
independiente a la calle o a un elemento común.

El propietario de cualquiera de estos departamentos o casas comparte áreas,

servicios e instalaciones comunes, siendo que el funcionamiento y mantenimiento
33 - 163
de los mismos, en cuanto a su uso y costo, se regula por estatutos y por el
reglamento de régimen interior (Propiedad horizontal o propiedad en condominios,
2022).

Prorrateo

El prorrateo se entiende como el porcentaje sobre los espacios comunes que le

corresponde a cada copropietario y usualmente se calcula según la superficie total
de cada vivienda, bodega o estacionamiento.

Dentro de las obligaciones de un administrador de condominio está el cobro de los

gastos comunes. Una duda recurrente entre los arrendatarios o propietarios es
cómo se calcula el prorrateo de gastos comunes

Cuando una persona compra un inmueble dentro de una copropiedad inmobiliaria,

también adquiere la obligación de contribuir para los gastos comunes, entendidos
como la suma de todos los gastos de la comunidad en un mes, divididos en
ordinarios y extraordinarios, según el artículo 7 de la ley del 30 Diciembre de 1949
denominada propiedad horizontal.

Los gastos comunes ordinarios administración, manutención, reparación y gastos

regulares de uso o consumo colectivo como gastos comunes extraordinarios: los
cobros adicionales o diferentes a los anteriores, en especial a lo que dice relación
con mantenimientos mayores de acuerdo con el artículo 4 de la misma norma, debe
realizar dicho aporte en proporción al derecho que le corresponda en los bienes de
dominio común (Koporcic, 2022).

34 - 163
 CAPÍTULO 3
MARCO PRÁCTICO
 CAPÍTULO 3

MARCO PRÁCTICO

PLAN DE DESARROLLO DE SOFTWARE

El objetivo del plan de desarrollo de software es la definición de las actividades de

términos de las fases y el sprint necesario para la implementación de un servicio,
debido a la magnitud del presente Trabajo de Grado,

Describe las tareas a realizar en cada fase para que el grupo de trabajo para que
permanezca organizado y enfocado en completar cada tarea planificada, para que
la documentación y los sistemas de respaldo estén diseñados adecuadamente de
acuerdo con el método, para evitar conflictos entre las dos áreas.

El software a desarrollar es un producto entregable y en evidencia de la solución

planteada. Para ello es necesario analizar la situación actual, entender y abstraer el
sistema e identificar el entorno en el cual trabajará el agente tal como lo establece
la metodología Scrum en su primera etapa para el plan de desarrollo se encuentran
todas las tareas que se realizaran.

Así como los productos entregables que son las pruebas de que se efectuó cada
tarea de manera correcta y elaborada en su respectivo tiempo como se muestra a
continuación, en la tabla 1 donde se podrá observa el plan de desarrollo que se
ejecutara para el inicio del sistema donde la implementación será exitosa de un
servicio a través de la definición de actividades.

En resumen, se busca lograr una implementación exitosa del servicio a través de la

definición y ejecución de actividades.

36-163
 Tabla 1: Planificación en base a la metodología scrum

METODOLOGIA SCRUM PRODUCTO

ETAPA TAREA
FASES SPRINT ENTREGABLE

Fase de exploración,
descripción de la
estructura organizativa
Organigramas
de la administración de
un edificio.
ANALISIS DE LA SITUACIÓN ACTUAL

Tabla de
Identificar a los actores
involucrados en
involucrado en los
los procesos.
procesos de la
administración de un
edificio
INICIO

Resultado de la
observación para
Análisis de los procesos la descripción
actuales grafica de los
procesos.

Tabla de
ESPECIFICACION DE LOS

Determinación de los
especificación de
requerimientos
requerimientos
REQUISITOS

Identificar los roles de

acuerdo al Scrum. Tabla de Roles.

/…
37-163
 …/

Diagrama de
casos de uso,
ANALISIS DEL SISTEMA navegacional,
contenido,
Análisis del sistema
presentación,
propuesto
estado

PLANIFICACIÓN Y ESTIMACIÓN
Diagrama de
casos de uso,
navegacional,
contenido,
presentación
expandido.
Modelo
DISEÑO DEL SISTEMA

Relacional de la
Modelar el sistema. Base de Datos.
Diccionario de
datos.
Diseño de
interfaz dinámica
de la página web
Módulo de
registro de
Sprint 1
usuarios
DESARROLLO DEL SISTEMA

Módulo de
IMPLEMENTACIÓN

Sprint 2 registros de roles

Y REVISIÓN

Codificación
Módulo de
Sprint 3 registro de
apartamentos
Módulo de
registros de
Sprint 4
residentes

/…

38-163
 …/
Módulo de
registros de
Sprint 5 gastos comunes
como
extraordinarios

Módulo de
Sprint 6 cálculo del
prorrateo

Módulo de
registro de áreas
de áreas
Sprint 7
comunes

Módulo de
Sprint 8 reservación de
áreas comunes

Módulo de
registro de los
Sprint 9
visitantes

Módulo de
Sprint 10 revisión de
reportes
PRUEBAS DEL SISTEMA

Tabla de pruebas
LANZAMIENTO

de funcionalidad
Pruebas de
del sistema
funcionalidad del
sistema web

/…

39-163
 …/

IMPLEMENTACIÓN
Nota de
Pruebas
implementación.

Fuente: Elaboración Propia.

ANÁLISIS DE LA SITUACIÓN ACTUAL

Se realizó el análisis de la situación actual, el cual permite comprender las

actividades y procesos en cuanto a la administración de un edificio y como se
controla los pagos de los gastos comunes extraordinarios, que realizan cada
residente al mes y la reservación de los espacio comunes que compone un edificio
de condominio, para lo cual se acudió a método de observación y entrevistas.

El objetivo de este análisis fue obtener una comprensión profunda de cómo se

administran y controlan los pagos de los gastos comunes y la reserva de espacios
comunes en el edificio de condominios que puede implicar la estipulación de
horarios, la coordinación de eventos o la implementación de políticas para garantizar
un uso equitativo de estas áreas.. Con esta información, se podrán identificar
posibles mejoras en los procesos existentes, optimizar la gestión de recursos y
brindar un mejor servicio a los residentes.

Fase de exploración

Se realizó varias reuniones con diferentes administradores y residentes que

compone un edificio de condominio, donde se pudo observar las solicitudes que se
detalla en la recopilación de la información como se muestra en la figura 5.

40-163
 Figura 5: Organigrama de la administración de del edificio

Administrador
del edificio

Residentes

Gestor de
Auxiliares de
servcios
servicios
comunes

Fuente: Elaboración Propia

Identificación de los involucrados

En esta etapa se identificaron a todas las partes involucradas en un sistema de

condominios. Esto implica identificar a todas las personas y entidades que tienen
una relación directa o indirecta con el funcionamiento y la gestión del edificio como
se muestra en la tabla 2.

Tabla 2: Identificación de involucrados

N° PERSONAL DESCRIPCIÓN
1. Administrador del edificio Es el principal actor sobre la situación y
disponibilidad de los ingresos, egresos, y coordinar
las necesidades de información con los residentes.
2. Residentes Su cometido entre otros, es vigilar, evaluar y
dictaminar el puntual desempeño de las tareas del
administrador, así como la ejecución de los acuerdos
y decisiones en todos los asuntos comunes del
condómino.

Fuente: Elaboración Propia.

41-163
 Recopilación de la información

Para este proceso de la recopilación de la información, se utilizó las técnicas de

observación los cuales determinan un conocimiento adecuado dentro de la
administración de un edificio, garantizando de esta manera que el sistema sea de
gran utilidad tanto para el administrador como el residente, que se detallan a
continuación.

[Link] Observación

Esta técnica se utilizó para ver la forma de cómo se realizan los procesos en la
administración de un edificio, de las cuales se pudieron evidenciar las siguientes:

 Se observó que los residentes que no comprenden las implicancias de vivir en

un condominio donde deben respetar las normas establecidas en el reglamento
de copropiedad.

 Se observó la dificultad por parte del administrador en rendir cuenta a la

comunidad en los tiempos acordados y al término de su relación con la
comunidad

 Se observó la dificultad por parte del administrador y residente la comunicación

de la reservación de los espacios comunes.

Descripción de los procesos actuales

La información obtenida de los procesos actuales que desarrolla la administración

de un edificio, ha sido extraída de las entrevistas y encuestas realizadas.

[Link] Proceso de registro de los pagos de los gastos comunes ordinarios

El registro de los pagos realizados se lo realiza en los paquetes ofimáticos de word,

excel y son almacenados en un ordenador como se observa a continuación en la
figura 6.

42-163
Figura 6: Proceso de registro de los pagos de los gastos comunes ordinarios

Residente
realiza pago de Guarda en
Administrador Se alamcena
sus gastos el
del edificio en exel
comunes ordenador
ordinarios

Fuente: Elaboración Propia.

Como se puede apreciar en la figura seis el proceso de registro de los pagos

comunes ordinarios se inicia a través del residente hacia el administrador, una vez
que a este funcionario del edificio realice todos los cobros realizados la información
se registra en una hoja excel (el número de departamento, nombre del residente,
etc.) para posteriormente asignarlos en el reporte mensual.

[Link] Proceso de la reservación de las áreas comunes de un edificio

El proceso de la reservación de las áreas comunes de un edificio se lo realiza en

base de un comunicado que se le presenta al administrador por parte del residente
como se muestra a continuación en la figura 7.

Figura 7: Proceso de la reservación de las áreas comunes de un edificio

comunicado
confirmación de la
Petición de de la solicitud reservación
reservación por parte del del espacio
del residente administrador comun a los
del edificio demas
residentes

Fuente: Elaboración Propia.

43-163
Como se puede apreciar en la figura siete el proceso de la reservación de las áreas
comunes de un edificio se inicia a través del residente hacia el administrador, una
vez que a este funcionario del edificio realice toda la información se da un
comunicado a los demás residentes sobre la reservación del espacio común.

IDENTIFICACIÓN DE LOS REQUISITOS

En base al análisis realizado se elaboró una tabla de especificación de

requerimientos en donde se establece la funcionalidad que tendrá el sistema para
mejorar los procesos en la administración de un edificio.

Determinación de requerimientos

En la tabla 3 se tienen la pila de productos que contiene los requerimientos no

funcionales del sistema y los requerimientos funcionales todo esta información se
encontrará en el (ANEXO C).

Tabla 3: Especificación de requerimientos

N° REQUERIMIENTO TIPO
R1 Gestión de usuario.
R1.1 Registro y Actualización de Datos Evidente
R1.2 Asignar roles de usuario por niveles de acuerdo a la función que Evidente
desempeña.
R2 Autenticación de usuario.
R2.1 Verificar la autenticación de usuario para ingresar al sistema. Evidente
R.2.2 Seguridad en el acceso y manejo de la información del sistema. Oculto
R3 Elaboración de interfaces para el sistema. Evidente
R3.1 Desarrollo de formularios para el sistema.
R4 Desarrollo de la base de datos.
R4.1 Diseño y desarrollo de la base de datos para la administración de
la información de los ingresos y egresos.

Fuente: Elaboración Propia.

44-163
[Link] Identificar los actores de acuerdo al Scrum

A continuación, se muestra la identificación de actores de acuerdo al SCRUM como

se muestra en la tabla 4.

Tabla 4: Tabla de actores de acuerdo al Scrum

N° ACTOR TAREA NOMBRE

1. Product Owner Responsable de maximizar el valor [Link]. Samuel Calle
(dueño del del producto. Condori
producto)
2. Scrum Master Responsable de promover y apoyar Ing. Medina Sepúlveda Liz
Scrum. Wendy
3. Desarrollador 1 Desarrollo Web. Iriarte Huallpa Miguel Joaquín

Fuente: Elaboración Propia.

 Product Owner: Es el encargado de optimizar y maximizar el valor del producto,

dicho de otra manera, será el altavoz del cliente debiendo entender
perfectamente cuál es la deriva que se desea para el producto en todo
momento.

 Scrum Master: Es el que se asegura que el proceso Scrum se lleve a cabo

correctamente, así como de facilitar la ejecución del proceso, también ayudara
a eliminar los impedimentos que van surgiendo.

 Equipo de desarrollo: El equipo de desarrollo está conformado por una persona

que se encargaran del desarrollo de la programación web.

Pre-game

En este punto se desarrollara los requerimientos iniciales para poder visualizar,

especificar, documentar el sistema, detallar el funcionamiento y procedimientos.

[Link] Planificación del sistema

A continuación se describen los actores y acciones que realizará cada actor que
interactuará con el sistema como se muestra en la tabla 5.

45-163
 Tabla 5: Especificación de usuarios del sistema

Usuario Función
Administrador Es el principal actor del sistema la persona
encargada del manejo directo e indirecto de
toda la información, gestionar y rendir cuentas
a la comunidad en los tiempos acordados y al
término con la comunidad y realiza un informe o
reporte de los ingresos y egresos del edificio
bajo un condominio
Residente Cumple la función de supervisar las funciones
del administrador en su desempeño, tiene
acceso a todo.
.
Fuente: Elaboración Propia.

Los usuarios identificados en el sistema se organizan de manera jerárquica para el

acceso al sistema y las funciones que cada uno de ellos tendrá dentro del sistema
como se muestra en la figura 8.

Figura 8: Orden jerárquico según al tipo de usuario

Fuente: Elaboración Propia.

46-163
Se dividirá los requerimientos en la fase del Pre-Game para la clasificación y
organización donde se mostrara las historias a realizar, prioridad, tiempo total
estimado, fechas de inicio estimado y si tienen alguna dependencia con otra historia
como se muestra en la tabla 6.

Tabla 6: Product backlog del sistema de administración para edificios

Tarea Historia Prioridad Tiempo total Fecha de inicio Dependencia

Id estimado (Días) estimado
1 Registro de usuarios Alta 13 3/12/2022 1.2

2 Registros de roles Alta 13 15/12/2022 1.2

3 Registros de Alta 13 27/12/2022 1.2

apartamentos
4 Registros de Alta 13 8/01/2023 1.2
residentes
5 Registros de gastos Alta 13 20/01/2023 1.2
comunes
6 Calculo del Alta 11 31/01/2023 1.2
prorrateo
7 Registro de áreas Alta 11 11/02/2023 1.2
comunes
8 Reservación de Alta 11 22/02/2023 1.2
espacios comunes
9 Registro de Alta 11 02/03/2023 1.2
visitantes
10 Revisión de reportes Alta 11 13/03/2023 1.2

Fuente: Elaboración Propia.

Game o development

En este punto de la fase se obtendrá cada uno de las tareas ID, planificando y
organizando las sub tareas como se hizo en la tabla6: Product backlog.
Implementando la metodología web UWE para el diseño y modelado Web.

47-163
 Diagrama de caso de uso general

Un diagrama de casos de uso general es una representación gráfica utilizada en el

análisis y diseño de sistemas para mostrar las interacciones entre los actores
(usuarios o sistemas externos) y el sistema en cuestión. Proporciona una visión
general de las funciones o acciones que el sistema puede realizar y cómo se
relacionan con los actores donde se podrá apreciar todas las interacciones como se
muestra en la figura 9.

Figura 9: Diagrama de caso de uso general

Fuente: Elaboración Propia.

48-163
[Link] Planificación de las iteraciones

A continuación, se describe las tareas y actividades que realizara en cada iteración

con el sistema.

[Link] Primer sprint registro de usuarios

Para empezar las iteraciones en el Game, se mostrara la información acerca del

primer sprint y la duración aproximadamente que va a tener en el transcurso de ese
periodo, se cuenta por el número de días de trabajo y la fecha de inicio del sprint
como se muestra en la tabla 7.

Tabla 7: Id 1 del producto backlog

Sprint Historia Inicio Duración (Días)

ID 1 Registro de usuarios 03/12/2022 13

Fuente: Elaboración Propia.

Y como se puede apreciar en la tabla 7, el primer sprint en un proyecto de desarrollo

de software es un período de tiempo definido durante el cual se llevan a cabo tareas
y actividades específicas. La duración del sprint puede variar, pero generalmente
se sitúa entre dos y cuatro semanas. La fecha de inicio del sprint se establece para
marcar el inicio oficial de las actividades del equipo de desarrollo. Durante el sprint,
se realizan reuniones diarias de seguimiento para evaluar el progreso y hacer los
ajustes si es necesario.

A continuación se identificara las tareas del sprint Id, del sistema donde se obtuvo
una planificación sobre el modulo y el detalle de las tareas con todos sus atributos
como e id, las tareas a realizar, el tipo, quien será el responsable de realizarlo como
también la estimación de cuantos días se podrá realizar cada tarea y la prioridad
que tendrá cada una como se muestra en la tabla 8.

49-163
 Tabla 8: Primer sprint backlog módulo de registro de usuario

Terea Estimación
Tereas Tipo Responsable prioridad Estado
Id en días
Planificación de
1.1 Análisis Iriarte 1 Alta Terminado
la iteración
Analizar los
requerimientos y
1.2 Análisis Iriarte 1 Alta Terminado
posterior Casos
de uso
Construir el
1.3 modelo de Análisis Iriarte 1 Alta Terminado
contenido
Diseñar el
1.4 modelo Análisis Iriarte 1 Alta Terminado
navegacional
Construir el
1.5 modelo de Análisis Iriarte 1 Alta Terminado
presentación
Construir el
modelo de Análisis Iriarte 1 Alta Terminado
1.6
procesos
Creación de
1.7 usuario y uso de Codificación Iriarte 1 Alta Terminado
sesión
Desarrollar el
módulo de
1.8 Prototipado Iriarte 2 Alta Terminado
registro de
usuario
Desarrollar el
módulo de
1.9 Codificación Iriarte 1 Alta Terminado
administración
del Sistema
Validación de
1.10 Prueba Iriarte 2 Alta Terminado
Usuario

/…

50-163
 …/
Seguridad de Iriarte
Codificación
1.11 Control de administrador 1 Alta Terminado
Prueba
usuario (MD5) del edificio

Fuente: Elaboración Propia.

Modelo de requerimientos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario.

[Link] Diagramas de caso de uso

El primer caso de uso del id 1: Registro de usuarios, para registrar usuarios que
tendrán acceso al sistema como se muestra en la figura 10.

Figura 10: Diagrama de caso de uso registro de usuario

Fuente: Elaboración Propia

51-163
La descripción de los casos de uso muestran los pasos que sigue el usuario para
interactuar con el sistema como se muestra en la tabla 9.

Tabla 9: Descripción del caso de registro de usuario

Nombre del Registro de usuarios.

Caso de Uso:

Número de 1
casos de uso

Usuario Administrador del edificio

Propósito Accede al Sistema para el registro de usuarios.

Precondición Pertenecer al condominio del edificio.

Curso Normal Alternativas

Acción de los Usuarios Respuesta del Sistema

1.1) El Sistema hace una validación si existe o no el

1) Todos los usuarios ingresan con una cuenta usuario.
de usuario y contraseña.
1.2) En caso de no existir no pertenece al
condominio del edificio se olvidó la contraseña
y usuario.

2) Se realiza un control de usuarios quienes 2.1) Compara con los datos que tiene la B.D. de los
son las personas que ingresaron o quieren usuarios registrados.
ingresar al Sistema.

3) Ingresar en modo Privilegio de

Administrador (Administrador del edificio

4) Ingreso al Sistema 3.1.) Envía el Sistema al perfil de usuario que

corresponde.

Post Condición Acceso al Sistema.

Fuente: Elaboración Propia

52-163
 Modelo de contenidos

El modelo de contenidos se especificara las clases que se ha trabajado en la etapa

del primer Sprint teniendo la clase registro y los que van a interactuar con el sistema
como se muestra en la figura 11.

Figura 11: Diagrama de contenido de registro de usuario

Fuente: Elaboración Propia

Modelo navegacional

En un modelo de navegación, los nodos representan las diferentes páginas o

pantallas que un usuario puede visitar, mientras que los enlaces indican las
transiciones o acciones que el usuario puede realizar para moverse de un nodo a
otro. En el contexto de un proceso de registro de usuario como se muestra en la
figura 12

53-163
 Figura 12: Diagrama navegacional de registro de usuario

Fuente: Elaboración Propia

Modelo de presentación

Para el modelo de presentación se hizo el diseño de pantalla de cómo quedara la

interfaz gráfica, en esta etapa se hizo un prototipo de la página principal del Inicio de
registro del usuario como se muestra en figura 13.

54-163
 Figura 13: Diagrama de presentación de registro de usuario

Fuente: Elaboración Propia

Segundo sprint módulo registro de roles

Se mostrara la información acerca del segundo sprint y la duración

aproximadamente que va a tener en el transcurso de ese periodo, se cuenta por el
número de días de trabajo y la fecha de inicio del sprint como se muestra en la tabla
10.

Tabla 10: Id 2 del producto backlong

Sprint Historia Inicio Duración (Días)

Módulo de registro de
ID 2 15/12/2022 13
roles

Fuente: Elaboración Propia

A continuación se identificara las tareas del sprint Id, del sistema donde se obtuvo
una planificación sobre el modulo y el detalle de las tareas con todos sus atributos
como se muestra en la tabla 11 para realizar un trabajo más ordenado.

55-163
 Tabla 11: Segundo sprint backlog módulo de registro de roles

Terea Estimación
Tereas Tipo Responsable prioridad Estado
Id en días
Planificación
1.1 Análisis Iriarte 1 Alta Terminado
de la iteración
Analizar los
requerimientos
1.2 Análisis Iriarte 1 Alta Terminado
y posterior
Casos de uso
Construir el
1.3 modelo de Análisis Iriarte 1 Alta Terminado
contenido
Diseñar el
1.4 modelo Análisis Iriarte 1 Alta Terminado
navegacional
Construir el
1.5 modelo de Análisis Iriarte 1 Alta Terminado
presentación
Construir el
modelo de Análisis Iriarte 1 Alta Terminado
1.6
procesos
Creación de
1.7 usuario y uso Codificación Iriarte 2 Alta Terminado
de sesión
Desarrollar el
módulo de
1.8 Prototipado Iriarte 1 Alta Terminado
registro de
roles
Desarrollar el
módulo de
1.9 Codificación Iriarte 2 Alta Terminado
administración
del Sistema
Validación de
1.10 Prueba Iriarte 1 Alta Terminado
Usuario

/…

56-163
 …/
Seguridad de Iriarte
Codificación
1.11 Control de administrador 1 Alta Terminado
Prueba
usuario (MD5) del edificio

Fuente: Elaboración Propia

Modelo de requerimientos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario.

[Link] Diagramas de caso de uso

El primer caso de uso del id 2: registro de roles, para dividir los usuarios del
condominio del edificio como se muestra en figura 14.

Figura 14: Diagrama de caso de uso Módulo de registro de roles

Fuente: Elaboración Propia

57-163
La descripción de los casos de uso muestran los pasos que sigue el usuario para
interactuar con el sistema para la creación de un nuevo rol para cuando el usuario
tenga que ingresar al sistema como se muestra en la tabla 12.

Tabla 12: Descripción del caso de módulo de registro de roles

Nombre del Módulo de registro de roles

Caso de Uso:

Número de 2
casos de uso

Usuario Administrador del edificio

Propósito Accede al Sistema para la creación de registro de roles

Precondición Pertenecer al condominio del edificio.

Curso Normal Alternativas

Acción de los Usuarios Respuesta del Sistema

1.1) El Sistema hace una validación si existe o no el
1) El administrador del edificio ingresa con usuario.
una cuenta de usuario y contraseña.
1.2) En caso de no existir no pertenece al
condominio del edificio se olvidó la contraseña
y usuario.
2) Se realiza la validación del administrador 2.1) Compara con los datos que tiene la B.D. de los
usuarios registrados.

3) Ingresar al módulo de registro de roles

4) Ingreso los datos 3.1.) Envía el Sistema los que corresponde.

Post Condición Acceso al Sistema para el registro de roles

Fuente: Elaboración Propia

Modelo de contenidos

El modelo de contenidos se especificara las clases que se ha trabajado en la etapa

del segundo Sprint teniendo se pueden identificar varias clases relacionadas con la
funcionalidad de registro y los actores que interactúan y representa el proceso en el
sistema, esta clase puede contener atributos y métodos relacionados con la

58-163
información del usuario. Esta clase puede contener atributos y métodos como se
muestra en figura 15.

Figura 15: Diagrama de contenido módulo de registro de roles

Fuente: Elaboración Propia

Modelo navegacional

En modelo navegacional determinaremos las páginas de registro de usuario,

utilizando los nodos (nodes) y enlaces (links), según el comportamiento del usuario
en el momento de ingresar para el registro de roles del edificio como se muestra en
figura 16.

59-163
 Figura 16: Diagrama navegacional de registro de roles

Fuente: Elaboración Propia

Modelo de presentación

Para el modelo de presentación se hizo el diseño de pantalla de cómo quedara la

interfaz gráfica, en esta etapa se hizo un prototipo de la página principal del Inicio de
cálculo de prorrateo como se muestra en figura 17.

60-163
 Figura 17: Diagrama de modelo de presentación de registro de roles

Fuente: Elaboración Propia

Tercer sprint registro de apartamentos

Para empezar las iteraciones en el Game, se mostrara la información acerca del

tercer sprint y la duración aproximadamente que va a tener en el transcurso de ese
periodo, se cuenta por el número de días de trabajo y la fecha de inicio del sprint
como se muestra en la tabla 13.

Tabla 13: Id 3 del producto backlog

Sprint Historia Inicio Duración (Días)

ID 3 Registro de apartamentos 27/12/2022 13

Fuente: Elaboración Propia

A continuación se identificara las tareas del sprint Id, del sistema donde se obtuvo
una planificación sobre el modulo y el detalle de las tareas con todos sus atributos
como se muestra en la tabla 14.

61-163
 Tabla 14: Tercer sprint backlog módulo de registro de apartamentos

Terea Estimación
Tereas Tipo Responsable prioridad Estado
Id en días
Planificación
1.1 Análisis Iriarte 1 Alta Terminado
de la iteración
Analizar los
requerimientos
1.2 Análisis Iriarte 1 Alta Terminado
y posterior
Casos de uso
Construir el
1.3 modelo de Análisis Iriarte 1 Alta Terminado
contenido
Diseñar el
1.4 modelo Análisis Iriarte 1 Alta Terminado
navegacional
Construir el
1.5 modelo de Análisis Iriarte 1 Alta Terminado
presentación
Construir el
modelo de Análisis Iriarte 1 Alta Terminado
1.6
procesos
Creación de
1.7 usuario y uso Codificación Iriarte 2 Alta Terminado
de sesión
Desarrollar el
módulo de
1.8 Prototipado Iriarte 1 Alta Terminado
registro de
apartamentos
Desarrollar el
módulo de
1.9 Codificación Iriarte 2 Alta Terminado
administración
del Sistema
Validación de
1.10 Prueba Iriarte 1 Alta Terminado
Usuario

/…

62-163
 …/
Seguridad de Iriarte
Codificación
1.11 Control de administrador 1 Alta Terminado
Prueba
usuario (MD5) del edificio

Fuente: Elaboración Propia

Modelo de requerimientos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario

[Link] Diagrama de caso de uso

El tercer caso de uso del id 3 registro de apartamentos, para que indique los
usuarios que tendrán acceso al sistema como se muestra en figura 18.

Figura 18: Diagrama de caso de uso de registro de apartamentos

Fuente: Elaboración Propia

63-163
La descripción de los casos de uso muestran los pasos que sigue el usuario para
interactuar con el sistema como se muestra en la tabla 15.

Tabla 15: Descripción del caso de registro de apartamentos

Nombre del Registro de apartamentos

Caso de Uso:
Número de 3
casos de uso
Usuario Administrador del edificio- residente
Propósito Accede al Sistema para el registro de apartamentos
Precondición Pertenecer al condominio del edificio.
Curso Normal Alternativas
Acción de los Usuarios Respuesta del Sistema
1.1) El Sistema hace una validación si existe o no el
1) Todos los usuarios ingresan con una usuario.
cuenta de usuario y contraseña.
1.2) En caso de no existir no pertenece al condominio
del edificio se olvidó la contraseña y usuario.
2) Se realiza un control de usuarios quienes 2.1) Compara con los datos que tiene la B.D. de los
son las personas que ingresaron o usuarios registrados.
quieren ingresar al Sistema.
3) Ingreso al Sistema 3.1) Envía el Sistema los datos del apartamento
registrado.

4) Ingresar para el registro de los apartamentos 4.1.) verificar si los datos fueron llenados correctamente

Post Condición Acceso al Sistema.

Fuente: Elaboración Propia

Modelo de contenidos

El modelo de contenidos se especificara las clases que se ha trabajado en la etapa

del tercer sprint teniendo la clase registro y los que van a interactuar con el sistema
se pueden identificar varias clases relacionadas con la funcionalidad y los actores
que interactúan con el sistema. Una posible clase que se ha trabajado en esta etapa
es la clase "Registro", que representa el proceso de registro de usuarios en el
sistema. Esta clase puede contener atributos y métodos relacionados con la
información del usuario como se muestra en figura 19.

64-163
 Figura 19: Diagrama de contenido de registro de apartamentos

Fuente: Elaboración Propia

Modelo navegacional

En modelo navegacional determinaremos las páginas de registro de usuario,

utilizando los nodos (nodes) y enlaces (links), según el comportamiento del usuario
en el momento de poder realizar el registro de un apartamento como se muestra en
figura 20.
65-163
 Figura 20: Diagrama navegacional de registro de apartamentos

Fuente: Elaboración Propia

Modelo de presentación

Para el modelo de presentación se hizo el diseño de pantalla de cómo quedara la

interfaz gráfica, en esta etapa se hizo un prototipo de la página principal del Inicio de
Sesión del usuario como se muestra en figura 21.

66-163
 Figura 21: Diagrama de presentación de registro de apartamentos

Fuente: Elaboración Propia

Cuarto sprint registro de residentes

Para empezar las iteraciones en el Game, se mostrara la información acerca del

cuarto sprint y la duración aproximadamente que va a tener en el transcurso de ese
periodo, se cuenta por el número de días de trabajo y la fecha de inicio del sprint
como se muestra en la tabla 16.

Tabla 16: Id 4 del producto backlog

Sprint Historia Inicio Duración (Días)

Registro de
ID 4 08/01/2023 13
residentes

Fuente: Elaboración Propia

A continuación se identificara las tareas del sprint Id, del sistema donde se obtuvo
una planificación sobre el modulo y el detalle de las tareas con todos sus atributos
como se muestra en la tabla 17.

67-163
 Tabla 17: Cuarto sprint backlog módulo de registro de residentes

Estimación
Terea Id Tereas Tipo Responsable prioridad Estado
en días
Planificación de
1.1 Análisis Iriarte 1 Alta Terminado
la iteración

Analizar los
requerimientos
1.2 Análisis Iriarte 1 Alta Terminado
y posterior
Casos de uso

Construir el
1.3 modelo de Análisis Iriarte 1 Alta Terminado
contenido

Diseñar el
1.4 modelo Análisis Iriarte 1 Alta Terminado
navegacional

Construir el
1.5 modelo de Análisis Iriarte 1 Alta Terminado
presentación

Construir el
modelo de Análisis Iriarte 1 Alta Terminado
1.6
procesos

Creación de
1.7 usuario y uso Codificación Iriarte 2 Alta Terminado
de sesión

Módulo de
1.8 registro de Prototipado Iriarte 1 Alta Terminado
residentes

Desarrollar el
módulo de
1.9 Codificación Iriarte 2 Alta Terminado
administración
del Sistema

Validación de
1.10 Prueba Iriarte 1 Alta Terminado
Usuario

/…

68-163
 …/
Seguridad de Iriarte
Codificación
1.11 Control de administrador 1 Alta Terminado
Prueba
usuario (MD5) del edificio

Fuente: Elaboración Propia

Modelo de requerimientos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario.

[Link] Diagramas de caso de uso

El cuarto caso de uso del id 4: de registro de residentes, para la accesibilidad del

administrador del edificio como se muestra en figura 22.

Figura 22: Diagrama de caso de uso de registro de residentes

Fuente: Elaboración Propia

69-163
La descripción de los casos de uso muestran los pasos que sigue el usuario para
interactuar con el sistema como se muestra en la tabla 18.

Tabla 18: Descripción del caso de uso de estadísticas de la administración

Nombre del Registro de residentes

Caso de Uso:
Número de 4
casos de uso
Usuario Administrador del edificio - residente

Propósito Accede al Sistema para el registro de residentes

Precondición Pertenecer al condominio del edificio.

Curso Normal Alternativas

Acción de los Usuarios Respuesta del Sistema

1.1) El Sistema hace una validación si existe o no el
1) Todos los usuarios ingresan con una cuenta usuario.
de usuario y contraseña.
1.2) En caso de no existir no pertenece al
condominio del edificio se olvidó la contraseña
y usuario.
2) Se realiza un control de usuarios quienes 2.1) Compara con los datos que tiene la B.D. de los
son las personas que ingresaron o quieren usuarios registrados.
ingresar al Sistema.

3) Ingreso al Sistema 3.1.) Envía el Sistema al perfil de usuario que

corresponde.
4) se ingresa al módulo de registro de 4.1) se envía los datos de acuerdo al modulo
residentes
Post Condición Acceso al Sistema.

Fuente: Elaboración Propia

Modelo de contenidos

El modelo de contenidos se especificara las clases que se ha trabajado en la etapa

del cuarto sprint teniendo la clase de registros de residentes y los usuarios que van
a interactuar con el sistema, se pueden identificar varias clases relacionadas los
actores que interactúan. Una posible clase que se ha trabajado en esta etapa es la
clase "Registro", que representa el proceso. Esta clase puede contener atributos y
métodos relacionados con la información del usuario como se muestra en figura 22.

70-163
 Figura 23: Diagrama de contenido de registro de residentes

Fuente: Elaboración Propia

Modelo navegacional

En modelo navegacional determinaremos las páginas de registro de usuario,

utilizando los nodos (nodes) y enlaces (links), según el comportamiento del usuario
en el momento de registrar nuevos residentes como se muestra en figura 24.

71-163
 Figura 24: Diagrama navegacional de registro de residentes

Fuente: Elaboración Propia

Modelo de presentación

Para el modelo de presentación se hizo el diseño de pantalla de cómo quedara la

interfaz gráfica, en esta etapa se hizo un prototipo de la página principal del Inicio de
registrar nuevos residentes como se muestra en figura 25.

72-163
 Figura 25: Diagrama presentación de registro de residentes

Fuente: Elaboración Propia

Quinto sprint registro de gastos comunes

Para empezar las iteraciones en el Game, se mostrara la información acerca del

quinto sprint y la duración aproximadamente que va a tener en el transcurso de ese
periodo, se cuenta por el número de días de trabajo y la fecha de inicio del sprint
como se muestra en la tabla 19.

Tabla 19: Id 5 del producto backlog

Sprint Historia Inicio Duración (Días)

Registro de gastos
ID 5 20/01/2023 13
comunes

Fuente: Elaboración Propia

A continuación se identificara las tareas del sprint Id, del sistema donde se obtuvo
una planificación sobre el modulo y el detalle de las tareas con todos sus atributos
como se muestra en la tabla 20.

73-163
 Tabla 20: Quinto sprint backlog módulo de registro de gastos comunes

Estimación
Terea Id Tereas Tipo Responsable prioridad Estado
en días
Planificación
1.1 Análisis Iriarte 1 Alta Terminado
de la iteración
Analizar los
requerimientos
1.2 Análisis Iriarte 1 Alta Terminado
y posterior
Casos de uso
Construir el
1.3 modelo de Análisis Iriarte 1 Alta Terminado
contenido
Diseñar el
1.4 modelo Análisis Iriarte 1 Alta Terminado
navegacional
Construir el
1.5 modelo de Análisis Iriarte 1 Alta Terminado
presentación
Construir el
modelo de Análisis Iriarte 1 Alta Terminado
1.6
procesos
Creación de
1.7 usuario y uso Codificación Iriarte 2 Alta Terminado
de sesión
Módulo de
registro de
1.8 Prototipado Iriarte 1 Alta Terminado
gastos
comunes
Desarrollar el
módulo de
1.9 Codificación Iriarte 2 Alta Terminado
administración
del Sistema
Validación de
1.10 Prueba Iriarte 1 Alta Terminado
Usuario

/…

74-163
 …/
Seguridad de Iriarte
Codificación
1.11 Control de administrador 1 Alta Terminado
Prueba
usuario (MD5) del edificio

Fuente: Elaboración Propia

Modelo de requerimientos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario

[Link] Diagrama de caso de uso

El quinto caso de uso del id 5: el registro de gastos comunes, para los usuarios que
tendrán acceso al sistema como se muestra en figura 26.

Figura 26: Diagrama de caso de registro de gastos comunes

Fuente: Elaboración Propia

La descripción de los casos de uso muestran los pasos que sigue el usuario para
interactuar con el sistema como se muestra en la tabla 21.

75-163
 Tabla 21: Descripción del caso de seguimiento de la reservación

Nombre del Registro de gastos comunes

Caso de Uso:

Número de 5
casos de uso

Usuario Administrador del edificio- administrador

Propósito Accede al Sistema para el registro de gastos comunes

Precondición Pertenecer al condominio del edificio.

Curso Normal Alternativas

Acción de los Usuarios Respuesta del Sistema

1.3) El Sistema hace una validación si existe o no el

1) Todos los usuarios ingresan con una usuario.
cuenta de usuario y contraseña.
1.4) En caso de no existir no pertenece al condominio
del edificio se olvidó la contraseña y usuario.

2) Se realiza un control de usuarios quienes 2.1) Compara con los datos que tiene la B.D. de los
son las personas que ingresaron o usuarios registrados.
quieren ingresar al Sistema para registro
de gastos comunes.

3) Ingreso al Sistema 3.1) Envía el Sistema al perfil de usuario que

corresponde para la reservación.

4) Ingresar para realizar el registro de los 4.1.) verificar que los datos sean llenados correctamente
gastos comunes

Post Condición Acceso al Sistema.

Fuente: Elaboración Propia

Modelo de contenidos

En el modelo de contenidos se especificará las clases que se ha trabajado en la

etapa del quinto Sprint teniendo la clase registro y los que van a interactuar con el
sistema. Esta clase puede contener atributos y métodos relacionados con la
información como se muestra en figura 27.

76-163
 Figura 27: Diagrama de contenido de registro de gastos comunes

Fuente: Elaboración Propia

Modelo navegacional

En modelo navegacional se tiene las páginas de registro de usuario, utilizando los

nodos (nodes) y enlaces (links), según el comportamiento del usuario en el
momento de poder realizar el registro de gastos comunes como se muestra en figura
28.

77-163
 Figura 28: Diagrama navegacional de registro de gastos comunes

Fuente: Elaboración Propia

Modelo de presentación

Para el modelo de presentación se hizo el diseño de pantalla de cómo quedara la

interfaz gráfica, en esta etapa se hizo un prototipo de la página principal del Inicio
seguimiento de registros de gastos comunes como se muestra en figura 29.

78-163
 Figura 29: Diagrama de presentación de registro de gastos comunes.

Fuente: Elaboración Propia

[Link] Sexto sprint cálculo de prorrateo

Para empezar las iteraciones en el Game, se mostrara la información acerca del

sexto sprint y la duración aproximadamente que va a tener en el transcurso de ese
periodo, se cuenta por el número de días de trabajo y la fecha de inicio del sprint
como se muestra en la tabla 22.

Tabla 22: id 6 del producto backlog

Sprint Historia Inicio Duración (Días)

ID 6 Calculo de prorrateo 01/01/2023 11

Fuente: Elaboración Propia.

A continuación se identificara las tareas del sprint Id, del sistema donde se obtuvo
una planificación sobre el modulo y el detalle de las tareas con todos sus atributos
como e id, las tareas a realizar, el tipo, quien será el responsable de realizarlo como
también la estimación de cuantos días se podrá realizar cada tarea y la prioridad
que tendrá cada una como se muestra en la tabla 23.

79-163
 Tabla 23: Sexto sprint backlog módulo de cálculo de prorrateo

Terea Estimación
Tereas Tipo Responsable prioridad Estado
Id en días
Planificación de
1.1 Análisis Iriarte 1 Alta Terminado
la iteración
Analizar los
requerimientos y
1.2 Análisis Iriarte 1 Alta Terminado
posterior Casos
de uso
Construir el
1.3 modelo de Análisis Iriarte 1 Alta Terminado
contenido
Diseñar el
1.4 modelo Análisis Iriarte 1 Alta Terminado
navegacional
Construir el
1.5 modelo de Análisis Iriarte 1 Alta Terminado
presentación
Construir el
modelo de Análisis Iriarte 1 Alta Terminado
1.6
procesos
Creación de
1.7 usuario y uso de Codificación Iriarte 1 Alta Terminado
sesión
Desarrollar el
módulo de
1.8 Prototipado Iriarte 1 Alta Terminado
cálculo de
prorrateo
Desarrollar el
módulo de
1.9 Codificación Iriarte 1 Alta Terminado
administración
del Sistema
Validación de
1.10 Prueba Iriarte 1 Alta Terminado
Usuario

/…

80-163
 …/
Seguridad de Iriarte
Codificación
1.11 Control de administrador 1 Alta Terminado
Prueba
usuario (MD5) del edificio

Fuente: Elaboración Propia.

Modelo de requerimientos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario.

[Link] Diagramas de caso de uso

El sexto caso de uso del id 6: cálculo de prorrateo, para dividir los gatos del
condominio en partes iguales de los gastos del edificio como se muestra en figura
30

Figura 30: Diagrama de caso de uso Módulo de cálculo de prorrateo

Fuente: Elaboración Propia.

81-163
La descripción de los casos de uso muestran los pasos que sigue el usuario para
interactuar con el sistema como se muestra en la tabla 12

Tabla 24: descripción del caso de módulo de cálculo de prorrateo

Nombre del Módulo de cálculo de prorrateo

Caso de Uso:
Número de 6
casos de uso
Usuario Administrador del edificio

Propósito Accede al Sistema para el cálculo de prorrateo de un edificio.

Precondición Pertenecer al condominio del edificio.

Curso Normal Alternativas

Acción de los Usuarios Respuesta del Sistema

1.1) El Sistema hace una validación si existe o no el
1) El administrador del edificio ingresa con usuario.
una cuenta de usuario y contraseña.
1.2) En caso de no existir no pertenece al
condominio del edificio se olvidó la contraseña
y usuario.
2) Se realiza la validación del administrador 2.1) Compara con los datos que tiene la B.D. de los
usuarios registrados.

3) Ingresar al cálculo de prorrateo

4) Ingreso los costos del edificio 3.1.) Envía el Sistema al cálculo de prorrateo que
corresponde.

Post Condición Acceso al Sistema para el cálculo del prorrateo

Fuente: Elaboración Propia.

Modelo de contenidos

El modelo de contenidos se especificara las clases que se ha trabajado en la etapa

del sexto sprint teniendo se pueden identificar varias clases relacionadas con la
funcionalidad de registro y los actores que interactúan y representa el proceso en el
sistema, esta clase puede contener atributos y métodos relacionados con la
información del usuario. Esta clase puede contener atributos y métodos como se
muestra en figura 31.
82-163
 Figura 31: Diagrama de contenido módulo de cálculo de prorrateo

Fuente: Elaboración Propia.

Modelo navegacional

En modelo navegacional determinaremos las páginas de registro de usuario,

utilizando los nodos (nodes) y enlaces (links), según el comportamiento del usuario
en el momento de ingresar para el cálculo del prorrateo de los gatos del edificio
como se muestra en figura 32.

83-163
 Figura 32: Diagrama navegacional de cálculo de prorrateo

Fuente: Elaboración Propia.

Modelo presentación

Para el modelo de presentación se hizo el diseño de pantalla de cómo quedara la

interfaz gráfica, en esta etapa se hizo un prototipo de la página principal del Inicio de
cálculo de prorrateo como se muestra en figura 33.

84-163
 Figura 33: Diagrama de modelo de contenido de cálculo de prorrateo

Fuente: Elaboración Propia.

[Link] Séptimo sprint registro de áreas comunes

Para empezar las iteraciones en el Game, se mostrara la información acerca del

septimo sprint y la duración aproximadamente que va a tener en el transcurso de
ese periodo, se cuenta por el número de días de trabajo y la fecha de inicio del sprint
como se muestra en la tabla 25.

Tabla 25: Id 7 del producto backlog

Sprint Historia Inicio Duración (Días)

Registro de áreas
ID 7 12/02/2022 11
comunes

Fuente: Elaboración Propia.

A continuación se identificara las tareas del sprint Id, del sistema donde se obtuvo
una planificación sobre el modulo y el detalle de las tareas con todos sus atributos
como se muestra en la tabla 26.
85-163
 Tabla 26: Séptimo sprint backlog módulo de registro de áreas comunes

Estimación
Terea Id Tereas Tipo Responsable prioridad Estado
en días
Planificación de
1.1 Análisis Iriarte 1 Alta Terminado
la iteración
Analizar los
requerimientos
1.2 Análisis Iriarte 1 Alta Terminado
y posterior
Casos de uso
Construir el
1.3 modelo de Análisis Iriarte 1 Alta Terminado
contenido
Diseñar el
1.4 modelo Análisis Iriarte 1 Alta Terminado
navegacional
Construir el
1.5 modelo de Análisis Iriarte 1 Alta Terminado
presentación
Construir el
modelo de Análisis Iriarte 1 Alta Terminado
1.6
procesos
Creación de
1.7 usuario y uso Codificación Iriarte 1 Alta Terminado
de sesión
Desarrollar el
módulo de
1.8 Prototipado Iriarte 1 Alta Terminado
registro de
áreas comunes
Desarrollar el
módulo de
1.9 Codificación Iriarte 1 Alta Terminado
administración
del Sistema
Validación de
1.10 Prueba Iriarte 1 Alta Terminado
Usuario
/…

86-163
 …/
Seguridad de Iriarte
Codificación
1.11 Control de administrador 1 Alta Terminado
Prueba
usuario (MD5) del edificio

Fuente: Elaboración Propia.

Modelo de requerimientos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario

[Link] Diagrama de caso de uso

El séptimo caso de uso del id 7: de registro de espacios comunes, para los usuarios
que tendrán acceso al sistema como se muestra en figura 34.

Figura 34: Diagrama de caso de uso de registro de áreas comunes

Fuente: Elaboración Propia.

La descripción de los casos de uso muestran los pasos que sigue el usuario para
interactuar con el sistema como se muestra en la tabla 27 de la descripción de cómo
se realizara el registro de las áreas comunes.

87-163
 Tabla 27: Descripción de caso de registro de áreas comunes

Nombre del Registro de las áreas comunes.

Caso de Uso:

Número de 7
casos de uso

Usuario Administrador del edificio- administrador

Propósito Accede al Sistema para el registro de áreas comunes

Precondición Pertenecer al condominio del edificio.

Curso Normal Alternativas

Acción de los Usuarios Respuesta del Sistema

1.1) El Sistema hace una validación si existe o no el
1) Todos los usuarios ingresan con una usuario.
cuenta de usuario y contraseña.
1.2) En caso de no existir no pertenece al condominio
del edificio se olvidó la contraseña y usuario.

2) Se realiza un control de usuarios quienes 2.1) Compara con los datos que tiene la B.D. de los
son las personas que ingresaron o usuarios registrados.
quieren ingresar al Sistema.

3) Ingreso al Sistema 3.1) Envía el Sistema al perfil de usuario que

corresponde para el registro.

4) Ingresar para el registro de las áreas 4.1.) verificar si los datos esta llenado correctamente para
comunes el registro del área común que compone un edifico

Post Condición Acceso al Sistema.

Fuente: Elaboración Propia.

Modelo de contenidos

El modelo de contenidos se especificara las clases que se ha trabajado en la etapa

del tercer Sprint teniendo la clase registro y los que van a interactuar con el sistema
se pueden identificar varias clases relacionadas con la funcionalidad y los actores
que interactúan con el sistema. Una posible clase que se ha trabajado en esta etapa
es la clase "Registro", que representa el proceso de registro de usuarios en el
sistema. Esta clase puede contener atributos y métodos relacionados con la
información del usuario como se muestra en figura 35.

88-163
 Figura 35: Diagrama de contenido de registro de áreas comunes

Fuente: Elaboración Propia.

Modelo navegacional

En modelo navegacional determinaremos las páginas de registro de usuario,

utilizando los nodos (nodes) y enlaces (links), según el comportamiento del usuario
en el momento de poder realizar el registro de un área común como se muestra en
figura 36.
89-163
 Figura 36: Diagrama navegacional de registro de áreas comunes

Fuente: Elaboración Propia.

Modelo de presentación

Para el modelo de presentación se hizo el diseño de pantalla de cómo quedara la

interfaz gráfica, en esta etapa se hizo un prototipo de la página principal del Inicio de
Sesión del usuario como se muestra en figura 37.

90-163
 Figura 37: Diagrama de presentación de registro de áreas comunes

Fuente: Elaboración Propia.

[Link] Octavo sprint reservación de espacios comunes

Para empezar las iteraciones en el Game, se mostrara la información acerca del

octavo sprint y la duración aproximadamente que va a tener en el transcurso de ese
periodo, se cuenta por el número de días de trabajo y la fecha de inicio del sprint
como se muestra en la tabla 28.

Tabla 28: Id 8 del producto backlog

Sprint Historia Inicio Duración (Días)

Reservación de los
ID 8 23/02/2022 11
espacios comunes

Fuente: Elaboración Propia.

A continuación se identificara las tareas del sprint Id, del sistema donde se obtuvo
una planificación sobre el modulo y el detalle de las tareas con todos sus atributos
como se muestra en la tabla 29.

91-163
Tabla 29: Octavo sprint backlog módulo de reservación de áreas comunes

Terea Estimación
Tereas Tipo Responsable prioridad Estado
Id en días
Planificación
1.1 Análisis Iriarte 1 Alta Terminado
de la iteración
Analizar los
requerimientos
1.2 Análisis Iriarte 1 Alta Terminado
y posterior
Casos de uso
Construir el
1.3 modelo de Análisis Iriarte 1 Alta Terminado
contenido
Diseñar el
1.4 modelo Análisis Iriarte 1 Alta Terminado
navegacional
Construir el
1.5 modelo de Análisis Iriarte 1 Alta Terminado
presentación
Construir el
modelo de Análisis Iriarte 1 Alta Terminado
1.6
procesos
Creación de
1.7 usuario y uso Codificación Iriarte 1 Alta Terminado
de sesión
Desarrollar el
módulo de
1.8 reservación de Prototipado Iriarte 1 Alta Terminado
las áreas
comunes
Desarrollar el
módulo de
1.9 Codificación Iriarte 1 Alta Terminado
administración
del Sistema
Validación de
1.10 Prueba Iriarte 1 Alta Terminado
Usuario

/…

92-163
 …/
Seguridad de Iriarte
Codificación
1.11 Control de administrador 1 Alta Terminado
Prueba
usuario (MD5) del edificio

Fuente: Elaboración Propia.

Modelo de requerimientos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario.

[Link] Diagrama de caso de uso

El octavo caso de uso del id 8: reservación de los espacios comunes, para los
usuarios que tendrán acceso al sistema como se muestra en figura 38.

Figura 38: Diagrama de caso de uso reservación de espacios comunes

Fuente: Elaboración Propia.

93-163
La descripción de los casos de uso muestran los pasos que sigue el usuario para
interactuar con el sistema como se muestra en la tabla 30.

Tabla 30: Descripción de caso de reservación de espacios comunes

Nombre del Reservación de los espacios comunes.

Caso de Uso:
Número de 8
casos de uso
Usuario Administrador del edificio- residente
Propósito Accede al Sistema para la reservation de espacios comunes.
Precondición Pertenecer al condominio del edificio.
Curso Normal Alternativas
Acción de los Usuarios Respuesta del Sistema
1.1) El Sistema hace una validación si existe o no el
1) Todos los usuarios ingresan con una usuario.
cuenta de usuario y contraseña.
1.2) En caso de no existir no pertenece al condominio
del edificio se olvidó la contraseña y usuario.
2) Se realiza un control de usuarios quienes 2.1) Compara con los datos que tiene la B.D. de los
son las personas que ingresaron o usuarios registrados.
quieren ingresar al Sistema.
3) Ingreso al Sistema 3.1) Envía el Sistema al perfil de usuario que
corresponde para la reservación.

4) Ingresar para la reservación delos espacios 4.1.) verificar si no está ocupado el espacio común para
comunes la reservación
Post Condición Acceso al Sistema.

Fuente: Elaboración Propia.

Modelo de contenidos

El modelo de contenidos se especificara las clases que se ha trabajado en la etapa

del octavo sprint teniendo la clase registro y los que van a interactuar con el sistema
se pueden identificar varias clases relacionadas con la funcionalidad y los actores
que interactúan con el sistema. Una posible clase que se ha trabajado en esta etapa
es la clase "Registro", que representa el proceso de registro de usuarios en el
sistema. Esta clase puede contener atributos y métodos relacionados con la
información del usuario como se muestra en figura 39.

94-163
 Figura 39: Diagrama de contenido de reservación de espacios comunes

Fuente: Elaboración Propia.

Modelo navegacional

En modelo navegacional determinaremos las páginas de registro de usuario,

utilizando los nodos (nodes) y enlaces (links), según el comportamiento del usuario
en el momento de poder realizar la reservación de un espacio común como se
muestra en figura 40.

95-163
 Figura 40: Diagrama navegacional de reservación de espacios comunes

Fuente: Elaboración Propia.

Modelo de presentación

Para el modelo de presentación se hizo el diseño de pantalla de cómo quedara la

interfaz gráfica, en esta etapa se hizo un prototipo de la página principal del Inicio de
Sesión del usuario como se muestra en figura 41.

96-163
 Figura 41: Diagrama de presentación de reservación de espacios comunes

Fuente: Elaboración Propia.

[Link] Noveno sprint registro de visitantes

Para empezar las iteraciones en el game, se mostrara la información acerca del

primer sprint y la duración aproximadamente que va a tener en el transcurso de ese
periodo, se cuenta por el número de días de trabajo y la fecha de inicio del sprint
como se muestra en la tabla 31.

Tabla 31: Id 9 del producto backlog

Sprint Historia Inicio Duración (Días)

Registro de
ID 9 06/03/2023 11
visitantes

Fuente: Elaboración Propia.

A continuación se identificara las tareas del sprint Id, del sistema donde se obtuvo
una planificación sobre el modulo y el detalle de las tareas con todos sus atributos
como se muestra en la tabla 32.
97-163
 Tabla 32: noveno sprint backlog módulo de registro de visitantes

Terea Estimación
Tereas Tipo Responsable prioridad Estado
Id en días
Planificación
1.1 Análisis Iriarte 1 Alta Terminado
de la iteración
Analizar los
requerimientos
1.2 Análisis Iriarte 1 Alta Terminado
y posterior
Casos de uso
Construir el
1.3 modelo de Análisis Iriarte 1 Alta Terminado
contenido
Diseñar el
1.4 modelo Análisis Iriarte 1 Alta Terminado
navegacional
Construir el
1.5 modelo de Análisis Iriarte 1 Alta Terminado
presentación
Construir el
modelo de Análisis Iriarte 1 Alta Terminado
1.6
procesos
Creación de
1.7 usuario y uso Codificación Iriarte 1 Alta Terminado
de sesión
Módulo de
1.8 registro de Prototipado Iriarte 1 Alta Terminado
residentes
Desarrollar el
módulo de
1.9 Codificación Iriarte 1 Alta Terminado
administración
del Sistema
Validación de
1.10 Prueba Iriarte 1 Alta Terminado
Usuario

/…

98-163
 …/
Seguridad de Iriarte
Codificación
1.11 Control de administrador 1 Alta Terminado
Prueba
usuario (MD5) del edificio

Fuente: Elaboración Propia.

Módulo de requerimientos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario.

[Link] Diagrama de caso de uso

El noveno caso de uso del id 9: de registro de visitantes, para la accesibilidad de los

residentes y administrador del edificio como se muestra en figura 42.

Figura 42: Diagrama de caso de uso de registro de visitantes

Fuente: Elaboración Propia.

99-163
La descripción de los casos de uso muestran los pasos que sigue el usuario para
interactuar con el sistema como se muestra en la tabla 33.

Tabla 33: Descripción del caso de uso de registro de visitantes

Nombre del Registro de visitantes

Caso de Uso:

Número de 9
casos de uso

Usuario Administrador del edificio

Propósito Accede al Sistema para el registro de visitantes.

Precondición Pertenecer al condominio del edificio.

Curso Normal Alternativas

Acción de los Usuarios Respuesta del Sistema

1.1) El Sistema hace una validación si existe o no el
1) Todos los usuarios ingresan con una cuenta usuario.
de usuario y contraseña.
1.2) En caso de no existir no pertenece al
condominio del edificio se olvidó la contraseña
y usuario.
2) Se realiza un control de usuarios quienes 2.1) Compara con los datos que tiene la B.D. de los
son las personas que ingresaron o quieren usuarios registrados.
ingresar al Sistema.

3) Ingreso al Sistema 3.1.) Envía el Sistema al perfil de usuario que

corresponde.

Post Condición Acceso al Sistema.

Fuente: Elaboración Propia.

Modelo de contenidos

El modelo de contenidos se especificara las clases que se ha trabajado en la etapa

del noveno sprint teniendo la clase de registro de visitantes y los usuarios que van
a interactuar con el sistema, se pueden identificar varias clases relacionadas los
actores que interactúan. Una posible clase que se ha trabajado en esta etapa es la
clase "Registro", que representa el proceso. Esta clase puede contener atributos y
métodos relacionados con la información del usuario como se muestra en figura 43.

100-163
 Figura 43: Diagrama de contenido de registro de visitantes

Fuente: Elaboración Propia.

Modelo navegacional

En modelo navegacional determinaremos las páginas de registro de usuario,

utilizando los nodos (nodes) y enlaces (links), según el comportamiento del usuario
en el momento de ingresar para el registro de los visitantes como se muestra en
figura 44.
101-163
 Figura 44: Diagrama navegacional de registro de visitantes

Fuente: Elaboración Propia.

Modelo de presentación

Para el modelo de presentación se hizo el diseño de pantalla de cómo quedara la

interfaz gráfica, en esta etapa se hizo un prototipo de la página principal del Inicio de
reportes e informes de los ingresos y egresos como se muestra en figura 45

102-163
 Figura 45: Diagrama presentación de registro de visitantes

Fuente: Elaboración Propia.

[Link] Decimo sprint revisión de reportes

Para empezar las iteraciones en el Game, se mostrara la información acerca del

décimo sprint y la duración aproximadamente que va a tener en el transcurso de
ese periodo, se cuenta por el número de días de trabajo y la fecha de inicio del sprint
como se muestra en la tabla 34.

Tabla 34: Id 10 del producto backlog

Sprint Historia Inicio Duración (Días)

Revisión de
ID 10 17/03/2023 11
reportes

Fuente: Elaboración Propia.

A continuación se identificara las tareas del sprint Id, del sistema donde se obtuvo
una planificación sobre el modulo y el detalle de las tareas con todos sus atributos
como se muestra en la tabla 35.

103-163
 Tabla 35: Decimo sprint backlog módulo de revisión de reportes

Terea Estimación
Tereas Tipo Responsable prioridad Estado
Id en días
Planificación
1.1 Análisis Iriarte 1 Alta Terminado
de la iteración
Analizar los
requerimientos
1.2 Análisis Iriarte 1 Alta Terminado
y posterior
Casos de uso

Construir el
1.3 modelo de Análisis Iriarte 1 Alta Terminado
contenido
Diseñar el
1.4 modelo Análisis Iriarte 1 Alta Terminado
navegacional
Construir el
1.5 modelo de Análisis Iriarte 1 Alta Terminado
presentación
Construir el
modelo de Análisis Iriarte 1 Alta Terminado
1.6
procesos
Creación de
1.7 usuario y uso Codificación Iriarte 1 Alta Terminado
de sesión
Módulo de
1.8 revisión de Prototipado Iriarte 1 Alta Terminado
reportes

Desarrollar el
módulo de
1.9 Codificación Iriarte 1 Alta Terminado
administración
del Sistema
Validación de
1.10 Prueba Iriarte 1 Alta Terminado
Usuario

/…

104-163
 …/
Seguridad de Iriarte
Codificación
1.11 Control de administrador 1 Alta Terminado
Prueba
usuario (MD5) del edificio

Fuente: Elaboración Propia.

Modelo de requerimientos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la

funcionalidad que debe ofrecer desde la perspectiva del usuario.

[Link] Diagrama de caso de uso

El décimo caso de uso del id 10: seguimiento de la reservación realizada, para los
usuarios que tendrán acceso al sistema como se muestra en figura 46

Figura 46: Diagrama de caso de uso de revisan de reportes

Fuente: Elaboración Propia.

105-163
La descripción de los casos de uso muestran los pasos que sigue el usuario para
interactuar con el sistema como se muestra en la tabla 36.

Tabla 36: Descripción del caso de uso de revisión de reportes

Nombre del Revisión de reportes

Caso de Uso:
Número de 10
casos de uso
Usuario Administrador del edificio- residente

Propósito Accede al Sistema para la seguimiento de la reservación realizada

Precondición Pertenecer al condominio del edificio.

Curso Normal Alternativas

Acción de los Usuarios Respuesta del Sistema

1.1) El Sistema hace una validación si existe o no el
1) Todos los usuarios ingresan con una usuario.
cuenta de usuario y contraseña.
1.2) En caso de no existir no pertenece al
condominio del edificio se olvidó la contraseña
y usuario.
2) Se realiza un control de usuarios quienes 2.1) Compara con los datos que tiene la B.D. de los
son las personas que ingresaron o usuarios registrados.
quieren ingresar al Sistema para la
revisión de reportes.
3) Ingreso al Sistema 3.1) Envía el Sistema al perfil de usuario que
corresponde para la revisión.

4) Ingresar para la revisión de reportes 4.1.) verificar si los datos están correctos

Post Condición Acceso al Sistema.

Fuente: Elaboración Propia.

Modelo de contenidos

En el modelo de contenidos se especificará las clases que se ha trabajado en la

etapa del décimo sprint teniendo la clase registro y los que van a interactuar con el
sistema. Esta clase puede contener atributos y métodos relacionados con la
información como se muestra en figura 47.

106-163
 Figura 47: Diagrama de contenidos de seguimiento de revisión de reportes

Fuente: Elaboración Propia.

Modelo navegacional

En modelo navegacional se tiene las páginas de registro de usuario, utilizando los

nodos (nodes) y enlaces (links), según el comportamiento del usuario en el
momento de poder realizar el seguimiento y revisión de los reportes como se
muestra en figura 48.

107-163
 Figura 48: Diagrama navegacional de revisión de reportes

Fuente: Elaboración Propia.

Modelo de presentación

Para el modelo de presentación se hizo el diseño de pantalla de cómo quedara la

interfaz gráfica, en esta etapa se hizo un prototipo de la página principal del Inicio
seguimiento de la reservación realizada como se muestra en figura 49.

108-163
 Figura 49: Diagrama de presentación de revisión de reportes

Fuente: Elaboración Propia.

DISEÑO DEL SISTEMA

El diseño de sistemas es el proceso de definición de la arquitectura, módulos,

interfaces y datos de un sistema para satisfacer unos requisitos previamente
especificados. El sistema podría verse como la aplicación de teoría al desarrollo de
un nuevo producto.

Diseño de la base de datos

Se realizó el diseño del modelo físico de la base de datos basado en el seguimiento

de los parámetros de la información que maneja la administración de edificio, como
se muestra en figura 50 de la base de datos.

109-163
 Figura 50: Diagrama entidad relación de la administración de edificio

Fuente: Elaboración Propia

[Link] Modelo relacional de la base de datos

Este diagrama describe las especificaciones de las clases que intervienen en el

sistema y las interfaces de la aplicación que se está desarrollando, este diagrama
ayudara de gran manera en la elaboración de la base de datos como se muestra en
figura 51.
110-163
 Figura 51: Diseño de la base de datos

Fuente: Elaboración Propia

[Link] Diccionario de datos.

Descripción de la base de datos del sistema.

PK=CLAVE PRIMARIA FK=CLAVE FORANEA

111-163
 Tabla 37: Descripcion tabla apartamentos

TABLA: Apartamentos
CAMPO TIPO DESCRIPCIÓN CLAVE
Id Int Código id PK
Numero_apartamento Varchar (45) Número del apartamento
Nombre_propietario Varchar (45) Nombre del propietario del
apartamento
Piso Int Donde se encuentra el
apartamento
Nombre_torre Varchar(45) Nombre del edifico donde se
encuentra el apartamento

Fuente: Elaboración Propia

Tabla 38: Descripción tabla áreas comunes

TABLA: Areas comunes

CAMPO TIPO DESCRIPCIÓN CLAVE
Id Int Código id PK
Nombre Varchar (45) Nombre del área común
Descripción Varchar (45) Descripción del área comun

Fuente: Elaboración Propia

Tabla 39: Descripción tabla residente

TABLA: Residente
CAMPO TIPO DESCRIPCIÓN CLAVE
Id Int Código id PK
Apartamento_id Bigint (20) Id de apartamentos FK
Nombre_residente Varchar (45) Nombre del residente
Ci Int Carnet del residente
Celular Int Celular del residente
Sexo Bigint (20) Id de sexos FK
Fecha Date Fecha de nacimiento del residente

Fuente: Elaboración Propia

Tabla 40: Descripción tabla expense

TABLA: Expense
CAMPO TIPO DESCRIPCIÓN CLAVE
Id Int Código id PK
Gasto_id Bigint (20) Id de gastos FK
Monto Decimal (8.2) Monto total del gasto
Cantidad Decimal (8.2) Entre cuantas personas se dividirá
Monto_prorrateado Decimal (8.2) Monto dividido

Fuente: Elaboración Propia

112-163
 Tabla 41: Descripción tabla gastos

TABLA: Gastos
CAMPO TIPO DESCRIPCIÓN CLAVE
Id Int Código id PK
Nombre Varchar (40) Nombre del gasto

Fuente: Elaboración Propia

Tabla 42: Descripción tabla reportes

TABLA: Reportes
CAMPO TIPO DESCRIPCIÓN CLAVE
Id Int Código id PK
Nombre Varchar (45) Nombre del documento
Documento Varchar (40) Documento que se va a cargar
Descripción Varchat(45) Breve resumen del documento

Fuente: Elaboración Propia

Tabla 43: Descripción tabla reservaciones

TABLA: Reservaciones
CAMPO TIPO DESCRIPCIÓN CLAVE
Id Int Código id PK
Nombre Varchar (40) Nombre del que está realizando la
reservación
Área_id Bignt (20) Id de áreas FK
Motivo Varchar(40) Motivo de la reservación
Fecha_inicio Date Inicio de la reservación
Fecha_fin Date Fin de la reservación

Fuente: Elaboración Propia

Tabla 44: Descripción tabla usuarios

TABLA: Usuarios
CAMPO TIPO DESCRIPCIÓN CLAVE
Id Int Código id PK
Nombre Varchar (100) Nombre del usuario para el ingreso
al sistema
Correo Varchar (100) Correo electrónico para el ingreso FK
al sistema
Verificación Varchar (100) Verificación del correo
Contraseña Varchar (100) Contraseña de usuario para el
ingreso al sistema
Confirmar Varchar (100) Confirmación de la contraseña
ingresada

Fuente: Elaboración Propia

113-163
 Tabla 45: Descripción tabla roles

TABLA: Roles
CAMPO TIPO DESCRIPCIÓN CLAVE
Id Int Código id PK
Nombre Varchar (40) Nombre del rol FK
Guardar_nombre Varchar (40) Se guarda los privilegios del rol FK

Fuente: Elaboración Propia

Tabla 46: Descripción tabla sexos

TABLA: Sexos
CAMPO TIPO DESCRIPCIÓN CLAVE
Id Int Código id PK
Nombre Varchar (40) Nombre del sexo

Fuente: Elaboración Propia

Diseño de Interfaz del sistema web

El diseño de la interfaz de usuario crea un medio eficaz de comunicación entre el

usuario y la computadora, el diseño identifica los objetos, acciones y crea una
pantalla de interfaz de usuario es una disciplina crucial en el desarrollo de software
y sistemas interactivos.

Es la apariencia de la interfaz de usuario, que incluye la selección de colores,

tipografía, iconos y otros elementos visuales. El diseño visual tiene como objetivo
crear una interfaz atractiva y coherente que refleje la identidad de la marca y facilite
la comprensión de la información

Su objetivo es crear una experiencia de usuario intuitiva, eficiente y agradable. A

continuación, se muestran las diferentes interfaces que fueron diseñados para el
sistema.

[Link] Interfaz de autenticación

En la figura 52, respectivamente, se muestra el modelo de una experiencia intuitiva

para el inicio de sesión para el ingreso al sistema web.

114-163
 Figura 52: Diseño de interfaz Inicio de sesión web.

Fuente: Elaboración Propia

[Link] Interfaz de dashboard

En la figura 53 podemos observar el modelo de dashboard del sistema web.

Figura 53: Diseño de interfaz de dashboard web.

Fuente: Elaboración Propia

115-163
[Link] Diseño de Interfaz del registro del apartamento

En la figura 54 podemos observar el modelo de registro del apartamento del sistema

web.

Figura 54: Diseño de interfaz del registro del apartamento

Fuente: Elaboración Propia

[Link] Diseño de la interfaz del registro de residente

En la figura 55 podemos observar el modelo de registro de los residentes del

sistema web.

116-163
 Figura 55: Diseño de Interfaz del registro de residente

Fuente: Elaboración Propia

[Link] Diseño de la interfaz de la gatos

En la figura 56 podemos observar el modelo de registro de los gatos de los espacios

comunes del sistema web.

117-163
 Figura 56: Diseño de la interfaz de la gastos

Fuente: Elaboración Propia

[Link] Diseño de la interfaz del prorrateo

En la figura 57 podemos observar el modelo del cálculo del prorrateo de los espacios
comunes del sistema web.

118-163
 Figura 57: Diseño de la interfaz del prorrateo

Fuente: Elaboración Propia

[Link] Diseño de la interfaz de los áreas comunes

En la figura 58 podemos observar el modelo de los registros de las áreas comunes

del sistema web.

119-163
 Figura 58: Diseño de la interfaz de los áreas comunes

Fuente: Elaboración Propia

[Link] Diseño de la interfaz de los reservaciones

En la figura 59 podemos observar el modelo de los registros de los reservaciones

del sistema web.

120-163
 Figura 59 Diseño de la interfaz de las reservaciones

Fuente: Elaboración Propia

[Link] Diseño de la interfaz de los visitantes

En la figura 60 podemos observar el modelo de los registros de los visitantes del

sistema web.

121-163
 Figura 60 Diseño de la interfaz de los visitantes

Fuente: Elaboración Propia

[Link] Diseño de la interfaz de los reportes

En la figura 61 podemos observar el modelo de los registros de los reportes del

sistema web.

122-163
 Figura 61 Diseño de la interfaz de los reportes

Fuente: Elaboración Propia

[Link] Diseño de la interfaz de los usuarios

En la figura 62 podemos observar el modelo de los de los usuarios del sistema

web.

123-163
 Figura 62 Diseño de la interfaz de los usuarios

Fuente: Elaboración Propia

[Link] Diseño de la interfaz de los roles

En la figura 63 podemos observar el modelo de los registros de los roles del sistema
web.

124-163
 Figura 63 Diseño de la interfaz de los roles

Fuente: Elaboración Propia

CODIFICACION DEL SOFTWARE

Sprint 1 modelo de autenticación de usuarios

[Link] Planificación del sprint

Este sprint corresponde al módulo de registro de usuarios, tabla 47.

125-163
 Tabla 47: Primer sprint módulo de registro de usuarios

Sprint 1: Modulo de registro de usuarios

SPRINT INICIO FIN DURACIÓN DIAS
1 03/12/2022 14/12/2022 13
ID TAREAS TIPO ESTADO
1.1 Planificación y análisis de los requerimientos del sprint. Planificación Terminado
1.2 Diseño de la interfaz del registro de usuario Diseño terminado
1.3 Desarrollo del módulo de registro de usuario Desarrollo terminado
1.3 Diseño de interfaz para la autenticación de usuarios. Diseño Terminado
1.4 Desarrollo del módulo de autenticación. Desarrollo Terminado

Fuente: Elaboración Propia

[Link] Desarrollo del sprint

Figura 64: Interfaz de registro de usuarios

Fuente: Elaboración Propia

126-163
 Figura 65: Interfaz de autenticación de usuarios

Fuente: Elaboración Propia

Sprint 2 módulo de registro de apartamentos

[Link] Planificación del sprint

Este sprint corresponde al módulo de registro de roles en la tabla número 48.

Tabla 48: Segundo sprint registro de roles

SPRINT 2: Módulo de registro de apartamentos

SPRINT INICIO FIN DURACIÓN DIAS
2 15/12/2022 28/12/2022 13 DIAS
ID TAREAS TIPO ESTADO
2.1 Planificación y análisis de los requerimientos del Planificación Terminado
sprint.
2.2 Diseño de interfaz de registro de roles. Diseño Terminado
2.3 Desarrollo del registro de roles. Desarrollo Terminado

Fuente: Elaboración Propia

127-163
[Link] Desarrollo del sprint

En la figura 66, se muestra el módulo del registro de roles del sistema web, donde
se puede crear, modificar y eliminar.

Figura 66: Módulo de registro de roles

Fuente: Elaboración Propia

Sprint 3 módulo de registro de apartamentos

[Link] Planificación del sprint.

Este sprint corresponde al módulo de registro de apartamentos, en la tabla 49 se

detalla las tareas planificadas para este sprint:

Tabla 49: Tercer sprint registro de apartamentos

Sprint 3: Registro de apartamentos

SPRINT INICIO FIN DURACIÓN DIAS
3 08/01/2023 19/01/2023 13 DIAS
ID TAREAS TIPO ESTADO
4.1 Planificación de los requerimientos del sprint. Planificación Hecho
4.2 Diseño del módulo de registro de apartamentos Diseño Hecho
4.3 Desarrollo del módulo de registro de apartamentos Desarrollo Hecho

Fuente: Elaboración Propia

128-163
[Link] Desarrollo del sprint

En la figura 67 se muestra el módulo de registro de apartamentos, en esta acción

se observa cuantos propietarios están registrados cuantos pagaran sus gastos
comunes.

Figura 67: Interfaz de registro de apartamentos

Fuente: Elaboración Propia

Sprint 4 módulo de registro de residentes

[Link] Planificación del sprint

Este sprint corresponde al módulo de registro de residentes, para que el

administrador pueda tener un control de los gatos, en la tabla 50 se detalla las tareas
planificadas.

129-163
 Tabla 50: Cuarto sprint de registro de gastos

Sprint 4: Registro de gastos

SPRINT INICIO FIN DURACIÓN DIAS
4 20/01/2023 19/01/2023 13 DIAS
ID TAREAS TIPO ESTADO
5.1 Planificación y análisis de los requerimientos del Planificación Hecho
sprint.
5.2 Diseño del módulo de registros de residentes Diseño Hecho
5.3 Desarrollo del módulo de registros de residentes Desarrollo Hecho

Fuente: Elaboración Propia

[Link] Desarrollo del sprint

En la figura 68, se muestra el módulo del registro de residentes que compone un

condómino de edificio, donde el administrador podrá tener control de los gastos.

Figura 68: Interfaz de registro de residentes

Fuente: Elaboración Propia

130-163
 Sprint 5 módulo de registro de gastos

[Link] Planificación del sprint

Este sprint corresponde al módulo de registro de gastos, donde el administrador

podrá visualizar los gastos, en la tabla 51 se detalla las tareas planificadas para este
sprint:

Tabla 51: Quinto sprint registro de gastos

Sprint 5: registro de gastos

SPRINT INICIO FIN DURACIÓN DIAS
5 06/08/2021 19/01/2023 13 DIAS
ID TAREAS TIPO ESTADO
5.1 Planificación de los requerimientos del sprint. Planificación Hecho
5.2 Diseño de interfaz del módulo de registro de gastos. Diseño Hecho
5.3 Desarrollo del módulo de registro de gastos Desarrollo Hecho

Fuente: Elaboración Propia

[Link] Desarrollo del sprint

En la figura 69 se muestra el módulo de registros de gastos, donde el administrador

podrá visualizar los gastos comunes del edificio

Figura 69: Interfaz de registro de gastos

Fuente: Elaboración Propia

131-163
 Sprint 6 módulo de cálculo de prorrateo

[Link] Planificación del sprint

Este sprint corresponde al módulo de cálculo de prorrateo, donde el administrador

podrá visualizar los gastos prorrateados, en la tabla 52 se detalla las tareas
planificadas para este sprint:

Tabla 52: Sexto sprint cálculo de prorrateo

Sprint 6: cálculo de prorrateo

SPRINT INICIO FIN DURACIÓN DIAS
6 30/01/2023 08/02/2023 10 DIAS
ID TAREAS TIPO ESTADO
5.1 Planificación de los requerimientos del sprint. Planificación Hecho
5.2 Diseño de interfaz del módulo cálculo de prorrateo. Diseño Hecho
5.3 Desarrollo del módulo cálculo de prorrateo Desarrollo Hecho

Fuente: Elaboración Propia

[Link] Desarrollo del sprint

En la figura 70 se muestra el módulo de registros de gastos, donde el administrador

podrá visualizar los gastos comunes prorrateados del edificio

Figura 70: Interfaz de cálculo de prorrateo

Fuente: Elaboración Propia

132-163
 Sprint 7 módulo de registro de áreas comunes

[Link] Planificación del sprint

Este sprint corresponde al módulo de registro de áreas comunes, donde el

administrador podrá visualizar las áreas de un edificio, en la tabla 53 se detalla las
tareas planificadas para este sprint:

Tabla 53: Séptimo sprint registro de áreas comunes

Sprint 7: registro de áreas comunes

SPRINT INICIO FIN DURACIÓN DIAS
7 09/02/2023 18/02/2023 10 DIAS
ID TAREAS TIPO ESTADO
5.1 Planificación de los requerimientos del sprint. Planificación Hecho
5.2 Diseño de interfaz del módulo de registro de áreas. Diseño Hecho
5.3 Desarrollo del módulo de registro de áreas Desarrollo Hecho

Fuente: Elaboración Propia

[Link] Desarrollo del sprint

En la figura 71 se muestra el módulo de registros de áreas comunes, donde el

administrador podrá visualizar las áreas comunes del edificio

Figura 71: Interfaz de registro de áreas comunes

Fuente: Elaboración Propia

133-163
 Sprint 8 módulo de registro de reservaciones

[Link] Planificación del sprint

Este sprint corresponde al módulo de registro de reservaciones, donde el

administrador podrá visualizar las reservaciones realizadas o por realizar, en la tabla
54 se detalla las tareas planificadas para este sprint:

Tabla 54: Octavo sprint registro de reservaciones

Sprint 8: registro de reservaciones

SPRINT INICIO FIN DURACIÓN DIAS
8 19/02/2023 24/02/2023 11 DIAS
ID TAREAS TIPO ESTADO
5.1 Planificación de los requerimientos del sprint. Planificación Hecho
5.2 Diseño de interfaz del módulo de registro de Diseño Hecho
reservación.
5.3 Desarrollo del módulo de registro de reservación Desarrollo Hecho

Fuente: Elaboración Propia

[Link] Desarrollo del sprint

En la figura 72 se muestra el módulo de registros de reservaciones, donde el

administrador podrá visualizar las reservaciones realizadas del edificio

Figura 72: Interfaz de registro de reservaciones

Fuente: Elaboración Propia

134-163
 Sprint 9 módulo de registro de visitantes

[Link] Planificación del sprint

Este sprint corresponde al módulo de registro de visitantes, donde el administrador

podrá visualizar a todos los visitantes, en la tabla 55 se detalla las tareas
planificadas para este sprint:

Tabla 55: noveno sprint registro de visitantes

Sprint 9: registro de visitante

SPRINT INICIO FIN DURACIÓN DIAS
5 24/02/2023 01/03/2023 11 DIAS
ID TAREAS TIPO ESTADO
5.1 Planificación de los requerimientos del sprint. Planificación Hecho
5.2 Diseño de interfaz del módulo registro de visitantes Diseño Hecho
5.3 Desarrollo del módulo registro de visitantes Desarrollo Hecho

Fuente: Elaboración Propia

[Link] Desarrollo del sprint

En la figura 73 se muestra el módulo de registros de visitantes, donde el

administrador podrá visualizar los visitantes comunes del edificio

Figura 73: Interfaz de registro de visitantes

Fuente: Elaboración Propia

135-163
 Sprint 10 módulo de revisión de reportes

[Link] Planificación del sprint

Este sprint corresponde al módulo de revisión de reportes, donde el administrador

podrá visualizar los reportes, en la tabla 56 se detalla las tareas planificadas para
este sprint:

Tabla 56: Decimo sprint revisión de reportes

Sprint 10: revisión de reportes

SPRINT INICIO FIN DURACIÓN DIAS
5 06/08/2021 19/01/2023 13 DIAS
ID TAREAS TIPO ESTADO
5.1 Planificación de los requerimientos del sprint. Planificación Hecho
5.2 Diseño de interfaz del módulo de registro de gastos. Diseño Hecho
5.3 Desarrollo del módulo de registro de gastos Desarrollo Hecho

Fuente: Elaboración Propia

[Link] Desarrollo del sprint

En la figura 74 se muestra el módulo de revisión de reportes, donde el administrador

podrá visualizar los reportes comunes del edificio

Figura 74: Interfaz de revisión de reportes

Fuente: Elaboración Propia

136-163
 PRUEBAS DEL SISTEMA

Concluido con el desarrollo de los diferentes módulos, se realizar las diferentes

pruebas para identificar posibles fallos de implementación y la calidad del software.
A continuación, en la tabla 57 detallan las pruebas que se aplicaron al sistema

Tabla 57: Escenario de plan de pruebas.

N° DESCRIPCION DE CASOS DE PRUEBA RESULTADO

1 Registro de usuarios cumple

2 Registro de roles Cumple

3 Registro de apartamentos Cumple

4 Registro de residentes Cumple

5 Registro de gastos comunes Cumple

6 Registro de calculo de prorrateo Cumple

7 Registro de areas communes Cumple

8 Reservacion de areas communes Cumple

9 Registro de visitantes Cumple

10 Registro de revision de reports Cumple

Fuente: Elaboración Propia

Pruebas unitarias del sistema

Las pruebas unitarias son una práctica fundamental en el desarrollo de software, y

su objetivo principal es identificar errores en el funcionamiento de componentes o
unidades individuales de código. Estas pruebas se enfocan en verificar que cada
unidad de código y darle un formato adecuado con la finalidad de optimizar la
calidad del sistema.

[Link] Caso de prueba de autenticación de usuarios

A continuación, en la tabla 58 se ve los criterios de aceptación que se verificaran en

el sprint 1 del módulo de registro de usuarios.

137-163
 Tabla 58: Criterios de aceptación registro de usuarios

Script 1 registro de usuarios

Descripción del Script 1 Criterios de aceptación
Como Registrar usuarios al sistema con un Al crear al usuario debe tener todos los datos
correo electrónico y una contraseña. correctos
Quiero Registrar al usuario con un rol a El rol y permisos sean definidos por el
elegir administrador del edificio
Para Mantener el control de los accesos al No se puede generar dos usuarios con el
sistema mismo correo electrónico

Fuente: Elaboración Propia

En la tabla 58 se ve cuáles son los criterios de aceptación considerados para los

casos de prueba

Tabla 59: Suit de pruebas sprint 1 registro de usuarios

Suite de pruebas
Caso Datos
Resultado Resultado
N° de Prioridad Precondiciones de pasos
esperado obtenido
prueba entrada
-Tener el Datos 1. 1. El 1. Se
sistema del Solicitar ingreso a la guardó el
instalado en el usuario los página es registro
equipo. a datos el correcto. correctame
-Realizar el registrar del 2. se nte
Registro registro y la usuario generó el 2. Se
1 de Alta usuarios asignaci que se registro del muestra al
usuarios ón del rol va a usuario usuario
que registrar registrado
tendrá al
dentro sistema
del
sistema

Fuente: Elaboración Propia

138-163
[Link] Caso de prueba de registro de roles

A continuación, en la tabla 60 se ve los criterios de aceptación que se verificaran en

el sprint 2 del módulo de registro de roles.

Tabla 60: Prueba de registro de roles

Script 2 registro de roles

Descripción del Script 2 Criterios de aceptación
Como Registrar al usuario con un rol de Al crear al usuario debe tener todos los datos
asignado correctos
Quiero Registrar al usuario con un rol a El rol y permisos sean definidos por el
elegir administrador del edificio
Para Mantener el control de los accesos al No se puede generar dos usuarios con el
sistema mismo correo electrónico

Fuente: Elaboración Propia

En la tabla 60 se ve cuáles son los criterios de aceptación considerados para los

casos de prueba

Tabla 61: Suit de pruebas sprint 2 registro de roles

Suite de pruebas
Caso
Datos de Resultado Resultado
N° de Prioridad Precondiciones pasos
entrada esperado obtenido
prueba
-Tener el Datos del 1. 1. El 1. Se guardó
sistema usuario Solicitar ingreso a el registro
instalado en el para la los la página correctamente
equipo. asignación datos es el 2. Se muestra
-Realizar el del rol que del correcto. al usuario
Registro
1 Alta registro roles tendrá usuario 2. se registrado con
de roles
dentro del que se generó el el rol asignado
sistema va a registro
registrar del rol
al
sistema

Fuente: Elaboración Propia

139-163
[Link] Caso de prueba de registro de apartamentos

A continuación, en la tabla 62 se ve los criterios de aceptación que se verificaran en

el sprint 3 del módulo de registro de apartamentos.

Tabla 62: Prueba de registro de roles

Script 3 registro de apartamentos

Descripción del Script 3 Criterios de aceptación
Como Registrar un apartamento con el rol Para registrar el apartamento debe tener todos
de ser administrador los datos correctos
Quiero Registrar el apartamento con el rol El administrador del edificio solo él puede
de administrador registrar nuevos apartamentos
Para Mantener el control de los No se puede crear un mismo apartamento dos
apartamentos veces

Fuente: Elaboración Propia

En la tabla 62 se ve cuáles son los criterios de aceptación considerados para los

casos de prueba

Tabla 63: Suit de pruebas sprint 3 registro de apartamentos

Suite de pruebas
Resultad
N Caso Datos de Resultado
Prioridad Precondiciones pasos o
° de prueba entrada obtenido
esperado
-Tener el Datos del [Link] 1. El 1. Se guardó
sistema apartame r los ingreso a el registro
instalado en el nto a datos la página correctament
equipo. registrar del es el e
Registro
-Realizar el dentro del aparta correcto. 2. Se
de
1 Alta registro de sistema mento 2. se muestra el
apartame
apartamentos que se generó el apartamento
ntos
va a registro registrado
registra del
r al apartame
sistema nto

Fuente: Elaboración Propia

140-163
[Link] Caso de prueba de registro de residentes

A continuación, en la tabla 64 se ve los criterios de aceptación que se verificaran en

el sprint 4 del módulo de registro de residentes.

Tabla 64: Prueba de registro de residentes

Script 4 registro de residentes

Descripción del Script 4 Criterios de aceptación
Como Registrar al residentes con un rol de Al crear al usuario debe tener todos los datos
asignado de administración correctos
Quiero Registrar al residentes un rol de El rol y permisos sean definidos por el
administrador administrador del edificio
Para Mantener el control de los de No se puede generar dos residentes con el
registros de los residentes en el mismo ci de
sistema

Fuente: Elaboración Propia

En la tabla 64 se ve cuáles son los criterios de aceptación considerados para los

casos de prueba

Tabla 65: Suit de pruebas sprint 4 registro de residentes

Suite de pruebas
N Caso Priorid Precondicione Datos de Resultado Resultado
pasos
° de prueba ad s entrada esperado obtenido
-Tener el Datos del 1. 1. El 1. Se
sistema usuario Solicitar ingreso a la guardó el
instalado en el para el los página es registro
equipo. registro datos el correcto. correctame
-Realizar el del del 2. se nte
Registro de
1 Alta registro residente resident generó el 2. Se
residentes
residentes e que registro del muestra
se va a residente registrado el
registra residente
r al
sistema

Fuente: Elaboración Propia

141-163
[Link] Caso de prueba de registro de gastos comunes

A continuación, en la tabla 66 se ve los criterios de aceptación que se verificaran en

el sprint 5 del módulo de registro de gastos comunes.

Tabla 66: Prueba de registro de gastos comunes

Script 5 registro de gastos comunes

Descripción del Script 5 Criterios de aceptación
Como Registrar gastos comunes con un rol Al crear los gastos comunes debe tener todos
de asignado los datos correctos
Quiero Registrar gastos comunes El rol y permisos sean definidos por el
administrador del edificio
Para Mantener el control de los gastos No se puede generar gastos comunes sin el rol
comunes correcto

Fuente: Elaboración Propia

En la tabla 66 se ve cuáles son los criterios de aceptación considerados para los

casos de prueba

Tabla 67: Suit de pruebas sprint 5 registro de gastos comunes

Suite de pruebas
Caso
Datos de Resultado Resultado
N° de Prioridad Precondiciones pasos
entrada esperado obtenido
prueba
-Tener el Datos del 1. 1. El 1. Se guardó
sistema gastos Solicitar ingreso a el registro
instalado en el común los datos la página correctamente
equipo. para la del es el 2. Se muestra
Registro
-Realizar el hora de gastos correcto. al usuario
de
1 Alta registro gastos realizar el comunes 2. se registrado con
gastos
comunes prorrateo que se generó el el rol asignado
comunes
dentro del va a registro
sistema registrar del gastos
al común
sistema

Fuente: Elaboración Propia

142-163
[Link] Caso de prueba de registro de cálculo de prorrateo

A continuación, en la tabla 68 se ve los criterios de aceptación que se verificaran en

el sprint 6 del módulo de registro de roles.

Tabla 68: Prueba de registro de cálculo de prorrateo

Script 6 registro de cálculo de prorrateo

Descripción del Script 6 Criterios de aceptación
Como Registrar el cálculo de prorrateo con Al crear el cálculo de prorrateo debe tener
un rol de asignado todos los datos correctos
Quiero Registrar el cálculo de prorrateo El cálculo del prorrateo sean definidos por el
administrador del edificio
Para Mantener el control de los cálculos No se puede prorratear más de un gasto
de prorrateos del sistema

Fuente: Elaboración Propia

En la tabla 68 se ve cuáles son los criterios de aceptación considerados para los

casos de prueba

Tabla 69: Suit de pruebas sprint 6 registro de cálculo de prorrateo

Suite de pruebas
Caso
Datos de Resultado Resultado
N° de Prioridad Precondiciones pasos
entrada esperado obtenido
prueba
-Tener el Datos del 1. 1. El 1. Se guardó
sistema gasto Solicitar ingreso a el registro
instalado en el para el los datos la página correctamente
Registro
equipo. cálculo del gasto es el 2. Se muestra
del
-Realizar el del el monto correcto. al usuario el
1 cálculo Alta
cálculo del prorrateo que se va 2. se cálculo del
del
prorrateo dentro a generó el prorrateo
prorrateo
del prorratear cálculo
sistema para el del
sistema prorrateo

Fuente: Elaboración Propia

143-163
[Link] Caso de prueba de registro de áreas comunes

A continuación, en la tabla 70 se ve los criterios de aceptación que se verificaran en

el sprint 7 del módulo de registro de áreas comunes.

Tabla 70: Prueba de registro de áreas comunes

Script 7 registro de áreas comunes

Descripción del Script 7 Criterios de aceptación
Como Registrar áreas comunes con un rol Al crear áreas comunes debe tener todos los
de asignado datos correctos
Quiero Registrar áreas comunes El rol y permisos sean definidos por el
administrador del edificio
Para Mantener el control de las áreas No se puede registrar áreas comunes con el
comunes en el sistema sin el rol del administrador

Fuente: Elaboración Propia

En la tabla 70 se ve cuáles son los criterios de aceptación considerados para los

casos de prueba

Tabla 71: Suit de pruebas sprint 7 registro de áreas comunes

Suite de pruebas
Caso
Datos de Resultado Resultado
N° de Prioridad Precondiciones pasos
entrada esperado obtenido
prueba
-Tener el Datos de 1. 1. El 1. Se guardó
sistema área Solicitar ingreso a el registro
instalado en el común los la página correctamente
equipo. para la datos es el 2. Se muestra
Registro -Realizar el asignación del área correcto. el registro de
1 de áreas Alta registro de que tendrá común 2. se las áreas
comunes áreas comunes dentro del que se generó el comunes
sistema va a registro
registrar de las
al áreas
sistema comunes

Fuente: Elaboración Propia

144-163
[Link] Caso de prueba de reservación de áreas comunes

A continuación, en la tabla 72 se ve los criterios de aceptación que se verificaran en

el sprint 8 del módulo de reservación de áreas comunes.

Tabla 72: Prueba de reservación de áreas comunes

Script 8 registro de reservación de áreas comunes

Descripción del Script 8 Criterios de aceptación
Como Registrar la reservación de áreas Al crear al usuario debe tener todos los datos
comunes con un rol de asignado correctos
Quiero Registrar la reservación de la área El rol y permisos sean definidos por el
común administrador del edificio
Para Mantener el control de las El administrador del edificio aprueba las
reservación en el sistema reservaciones de una rea comun

Fuente: Elaboración Propia

En la tabla 72 se ve cuáles son los criterios de aceptación considerados para los

casos de prueba

Tabla 73: Suit de pruebas sprint 8 de reservación de áreas comunes

Suite de pruebas
N Caso Priorida Precondicion Datos de Resultado Resultado
pasos
° de prueba d es entrada esperado obtenido
-Tener el Datos de 1. Solicitar 1. El 1. Se guardó
sistema la los datos ingreso a el registro
instalado en reservació de la la página correctamen
el equipo. n para reservació es el te
Reservació
-Realizar la para el n que se correcto. 2. Se
n de las
1 Alta reservación registro va a 2. se muestra al
áreas
de la área dentro del registrar al generó la usuario el
comunes
común sistema sistema reservació registro de la
n del área reservación
de la área
común

Fuente: Elaboración Propia

145-163
[Link] Caso de prueba de registro de visitantes

A continuación, en la tabla 74 se ve los criterios de aceptación que se verificaran en

el sprint 9 del módulo de registro de visitantes.

Tabla 74: Prueba de registro de visitantes

Script 2 registro de visitantes

Descripción del Script 2 Criterios de aceptación
Como Registrar al visitante Al crear al visitantes debe tener todos los datos
correctos
Quiero Registrar a los visitantes El rol y permisos sean definidos por el
administrador del edificio
Para Mantener el control de los accesos al Solo el administrador puede registrar a los
sistema visitantes

Fuente: Elaboración Propia

En la tabla 74 se ve cuáles son los criterios de aceptación considerados para los

casos de prueba

Tabla 75: Suit de pruebas sprint 9 registro de visitantes

Suite de pruebas
Caso
Datos de Resultado Resultado
N° de Prioridad Precondiciones pasos
entrada esperado obtenido
prueba
-Tener el Datos del 1. 1. El 1. Se guardó
sistema visitante Solicitar ingreso a el registro
instalado en el que los la página correctamente
equipo. tendrá datos es el 2. Se muestra
Registro -Realizar el dentro del del correcto. al visitante
1 de Alta registro de sistema visitante 2. se registrado
visitantes visitantes que se generó el
va a registro
registrar del
al visitante
sistema

Fuente: Elaboración Propia

146-163
[Link] Caso de prueba de revisión de reportes

A continuación, en la tabla 76 se ve los criterios de aceptación que se verificaran en

el sprint 10 del módulo de revisión de reportes.

Tabla 76: Prueba de revisión de reportes

Script 10 revisión de reportes

Descripción del Script 10 Criterios de aceptación
Como Registrar reportes para su Al crear el reporte debe tener todos los datos
visualización correctos para la visualización
Quiero Registrar el reporte con el rol El rol y permisos sean definidos por el
administrador administrador del edificio
Para Mantener el control de todos los Solo el administrador puede registrar los
reportes para su visualización reportes generados por el sistema

Fuente: Elaboración Propia

En la tabla 76 se ve cuáles son los criterios de aceptación considerados para los

casos de prueba

Tabla 77: Suit de pruebas sprint 10 revisión de reportes

Suite de pruebas
Caso Resultad
N Priorida Precondicione Datos de Resultado
de pasos o
° d s entrada obtenido
prueba esperado
-Tener el Datos del 1. Solicitar 1. El 1. Se guardó
sistema reporte los datos ingreso a el registro
instalado en el para la del reporte la página correctament
equipo. visualizació para la es el e
Registr
-Realizar el n del visualizació correcto. 2. Se
o de
1 Alta registro de reporte por n en el 2. se muestra al
reporte
reportes parte del sistema generó el residente el
s
residente registro registro del
dentro del del reporte por el
sistema reporte administrado
r

Fuente: Elaboración Propia

147-163
 IMPLEMENTACION DEL SISTEMA

El Sistema web para la administración de edificios, se encuentra en condiciones de

ser implementado en el servidor de un host de azure.

MANTENIMIENTO

El mantenimiento en el software es necesario para realizar cambios ocasionales o

bien para corregir errores o para introducir mejoras.

EVALUACION TECNICA

La norma ISO 9126, titulada "Evaluación de la calidad del producto de software",

proporciona un marco para evaluar la calidad del software en términos de
características específicas. Estas características incluyen funcionalidad, usabilidad,
mantenibilidad y portabilidad. Para alcanzar la mejor calidad necesaria bajo esta
norma, es importante realizar los cálculos y medidas correspondientes en cada una
de estas áreas.

Funcionalidad

La funcionalidad de un sistema se evalúa por su complejidad, la cual no se puede

medir directamente, por lo que corresponde a un resultado cuantificable, se
consideraran en el sistema. Al evaluar la funcionalidad de un sistema, se tienen en
cuenta diversos factores y sistemas de valores que pueden contribuir a su
complejidad.

 Número de entradas de usuario: Cada entrada externa origina en un usuario y

proporciona distintos datos orientados a la información de control.

 Número de salidas del usuario: Se cuenta cada salida orientada que

proporciona el usuario, en este contexto la salida se refiere a informes, etc.

148-163
 Número de peticiones del usuario: Una petición se define como una entrada
interactiva que produce una respuesta del software inmediata en forma de
salida Se cuenta cada petición por separado.

 Número de archivos lógicos internos: Se cuenta cada archivo maestro lógico

(un grupo lógico de datos que puede ser parte de una gran base de datos).

 Número de archivos de interfaz externos: Se cuentan todas las interfaces

legibles por la máquina.

A continuación, se asignará un nivel de complejidad para cada componente de

acuerdo a los puntos de función en la tabla 78 (Pressman, 2010) .

Tabla 78: Cálculo punto de función

Parámetros de medida Cuenta Factor de peso Total

Simple Medio Complejo
Número de entradas de Usuario 4 3 4 6 12
Número de Salidas de Usuario 4 4 5 7 16
Número de Peticiones de Usuario 3 3 4 6 9
Número de Archivos 1 7 10 15 28
Número de Interfaces 4 5 7 10 20
Total 85

Fuente: Pressman, 2010

La función del sistema se obtendrá en puntos de función basados en relaciones

empíricas entre medidas cuantitativas del dominio de información del software. El
valor de complejidad para el cálculo de los puntos de función teniendo como valores,
datos del ajuste y el valor que se le dará a ese ajuste se muestra en la tabla 79.

Tabla 79: Valores de ajuste de complejidad

Datos del Ajuste Valor de Ajuste

Sin influencia 0
Menor importancia 1
Moderado 2
Medio 3
Significativo 4
Esencial 5

Fuente: Prieto, 2003.

149-163
En la siguiente tabla 80 se aplicó los valores de ajuste de complejidad a los factores
de ajuste donde se realiza una serie de preguntas de acuerdo al sistema y así poder
calcular la función para el sistema web de administración de edificios utilizando la
ecuación ajustada de puntos con los valores de complejidad que se obtendrán.

Tabla 80: Ajuste de complejidad

Fi Factores de ajuste de complejidad Valor

2 ¿Se requiere comunicación de datos? 5
3 ¿Existe funciones de procesamiento distribuido? 5
4 ¿Es critico el rendimiento? 2
5 ¿Se ejecutará el sistema en entorno operativo existente y utilizado? 5
6 ¿Se requiere datos de entrada? 5
8 ¿Se utilizan los archivos maestros de forma interactiva? 5
9 ¿Son complejas las entradas, las salidas, los archivos o las peticiones? 4
10 ¿Es complejo el procesamiento interno? 4
11 ¿Se ha diseñado el código para ser reutilizable? 4
12 ¿Están incluidas en el diseño la conversión y la instalación? 3
13 ¿Se ha diseñado el sistema para soportar múltiples instalaciones en 5
diferentes organizaciones?
14 ¿Se ha diseñado la aplicación para facilitar los cambios y ser fácilmente 5
utilizada por el usuario?
Total ∑( 𝒇𝒊) = 𝟓𝟏

Fuente: Prieto, 2003.

Para calcular el punto de función (PF), para el (Sistema Web) se utiliza la siguiente
ecuación:

Ecuación de puntos de función ajustada.

𝑃𝑢𝑛𝑡𝑜 𝐹𝑢𝑛𝑐𝑖ó𝑛 (𝑃𝐹) = 𝐶𝑈𝐸𝑁𝑇𝐴_𝑇𝑂𝑇𝐴𝐿 ∗ (0.65 + 0.01 ∗ 𝑆𝑢𝑚(𝐹𝑖 )) (1)

Fuente: Pressman, 2010.

Empleando la fórmula para hallar el PF y PF (Máximo):

𝑃𝐹 = 85 ∗ (0.65 + 0.01 ∗ 51)

𝑃𝐹 = 107.1
𝑃𝐹(𝑀𝑎𝑥𝑖𝑚𝑜) = 85 ∗ (0.65 + 0.01 ∗ 70)
𝑃𝐹 = 114.75

Con los valores de ajuste de complejidad de punto función, se tiene el siguiente

resultado de funcionalidad real:
150-163
 𝑃𝐹 = (107.1 /114.75) ∗ 100
𝑃𝐹 = 93.33 %

Por lo tanto, la funcionalidad del Sistema Web, representa el 93.33%, teniendo en

cuenta el punto función máximo. Lo que nos indica que el sistema cumple con los
requisitos funcionales de forma satisfactoria.

Usabilidad

Es un factor qué se mide indirectamente, se espera que el Software sea de fácil

entendimiento y aprendizaje. Cabe resaltar que para la norma ISO 9126, la
usabilidad no es afectada por la funcionalidad y eficiencia. La usabilidad está
definida por los usuarios finales.

Para esto se utilizó un cuestionario que consta de 7 preguntas junto a la respectiva

valoración del usuario, donde se ve los valores máximos y mínimos obtenidos para
cada pregunta, el valor obtenido corresponde a un promedio de 4 usuarios. Para el
control de la usabilidad se tiene el siguiente cuestionario con los ajustes necesarios
que se pueden observar en la tabla 81:

Tabla 81: Escala de ajustes de usabilidad

Descripción Escala

Pésimo 1

Malo 2

Regular 3

Bueno 4

Muy bueno 5

Fuente: Elaboración Propia

151-163
Las preguntas utilizadas para medir la funcionalidad fueron las representadas en la
siguiente tabla 82 y preguntadas a un administrador como se muestra en el anexo
D
Tabla 82: Cuestionario de usabilidad

Factor usabilidad VALOR

¿Es entendible el sistema? 5
¿Puede utilizarlo fácilmente? 5
¿Es sencillo acceder a los datos? 5
¿El sistema responde rápido a sus solicitudes? 4
¿Los reportes que genera son útiles? 5
¿El sistema le proporciono las respuestas requeridas? 5
¿Está de acuerdo con el funcionamiento del software? 5
Total 34

Fuente: Elaboración Propia.

La usabilidad para el sistema, se calcula por medio de la siguiente ecuación:

Ecuación hallar la usabilidad del software.

∑𝑣𝑎𝑙𝑜𝑟
[( 𝑛 ) 𝑥 100]
𝑈𝑆𝐴𝐵𝐼𝐿𝐼𝐷𝐴𝐷 = (2)
5

Fuente: Prieto, 2003.

Donde:
𝑈𝑆𝐴𝐵𝐼𝐿𝐼𝐷𝐴𝐷: Usabilidad del sistema
∑𝑣𝑎𝑙𝑜𝑟: Sumatoria del total del cuestionario de usabilidad
𝑛: Cantidad de preguntas del cuestionario

∑𝑣𝑎𝑙𝑜𝑟
[( 𝑛 ) 𝑥 100]
𝑈𝑆𝐴𝐵𝐼𝐿𝐼𝐷𝐴𝐷 =
5
34
[( 7 ) 𝑥 100]
𝑈𝑆𝐴𝐵𝐼𝐿𝐼𝐷𝐴𝐷 =
5
𝑈𝑆𝐴𝐵𝐼𝐿𝐼𝐷𝐴𝐷 = 97.14 %
152-163
Por lo tanto, la usabilidad del software corresponde a un 97.14%, que se interpreta
como la facilidad del usuario al interactuar con las interfaces.

Mantebilidad

Es un conjunto de atributos relacionados con la facilidad de extender, modificar o

corregir errores en un sistema software. Para hallar el índice se usa la siguiente
formula:

Ecuación indice de madurez del software.

[𝑀𝑡 – (𝐹𝑎 + 𝐹𝑚 + 𝐹𝑒)]

𝐼𝑀𝐶 = (3)
𝑀𝑡
Fuente: Silicia, 2003.

Donde:
𝑀𝑡: Número de módulos de la versión actual.
𝐹𝑚: Número de módulos que se han modificado.
𝐹𝑎: Número de módulos en la versión actual que se han añadido.
𝐹𝑒: Número de módulos que se han borrado en la versión actual.

Tabla 83: Mantebilidad del sistema

Información Valor

Mt 5

Fm 0

Fa 0

Fe 0

Fuente: Elaboración Propia

[5 – (0 + 0 + 0)]
𝐼𝑀𝐶 =
5
𝐼𝑀𝐶 = 100%

153-163
Se tiene el 100% de mantenibilidad, esto quiere decir que el sistema tiene nivel de
mantenibilidad buena.

Portabilidad

Se refiere a la adaptabilidad del software de ser transferido de un ambiente a otro,

y considera los siguientes aspectos. Adaptabilidad evalúa la oportunidad para
adaptar el software a diferentes ambientes sin necesidad de aplicarle
modificaciones.

 Facilidad de Instalación: Es el esfuerzo necesario para instalar el software en

un ambiente determinado.

 Conformidad: Permite evaluar si el software se adhiere a estándares o

convenciones relativas a portabilidad.

 Capacidad de reemplazo: Se refiere a la oportunidad y el esfuerzo usado en

sustituir el software por otro producto con funciones similares.

Para el cálculo de la portabilidad se tomó en cuenta en la tabla 84 que contiene las

características que se mencionaron anteriormente.

Tabla 84: Portabilidad

Factor Valor %
¿El sistema puede ser transferido de un entorno a otro? 85
¿Se puede adaptar con facilidad? 90
¿Es fácil de instalar? 95
¿Es capaz de reemplazar a una aplicación similar? 100
Total 92.5

Fuente: Elaboración Propia

El sistema fue desarrollado con LARAVEL, y la base de datos MySQL, que se

ejecuta en todos los servidores web, se le da una calificación del 92.5% de
portabilidad.

154-163
 Calidad total

Para poder obtener la calidad total del Software, a media de todas las medidas
expresadas en porcentajes, como se muestra en la tabla 85.
Tabla 85: Resultados calidad total

Características Resultados Web

Funcionalidad 93.33 %
Usabilidad 97.14 %
Mantenibilidad 100 %
Portabilidad 92.5 %
Total 94.44%

Fuente: Elaboración Propia

La calidad total del Software corresponde al 94,44 %, lo que se interpreta como la

satisfacción que tiene el usuario al interactuar con el Software.

EVALUCION ECONOMICA

Para poder establecer los costos totales en los que se incurre durante la elaboración
e implementación del sistema, dividiremos los mismos en dos grupos principales,
costos fijos y variables, dentro de los cuales se concentran todos los existentes
como muestra en la tabla 86.

Tabla 86: Costos fijos y variables

Costo Total del Proyecto

Costos Fijos Costos Variables
Compra de equipo Material de escritorio
Licencias de software Recopilación de información
Desarrollo de software
.
Fuente: Elaboración Propia

Una vez determinados los costos del proyecto, se procede a detallar cada uno de
ellos. Cabe aclarar previamente que se considerarán solo aquellos costos que se
producirán en caso de implementarse el presente sistema.

155-163
 Costos fijos

Los costos fijos son aquellos que no son sensibles a pequeños cambios en los
niveles de actividad de una empresa, sino que permanecen invariables ante esos
cambios. Es decir que no dependen del nivel de producción de la empresa. Para el
presente Trabajo de Grado se tienen los siguientes.

 Compra de Equipo
 Licencia de software.
 Desarrollo de Software.

[Link] Compra de equipo

Para el funcionamiento del sistema se requieren el siguiente equipo.

 Computadora (PC)

Computadora:

La computadora (PC) será el equipo de cómputo que utilizarán el administrador del

edificio, para acceder al sistema, el mismo tiene las siguientes características:

 Procesador: Intel (R) Core i7-6500U CPU (4 núcleos, 2.50 GHz)

 Memoria: 8 GB
 Disco Duro: 1 TB

El equipo laptop “TOSHIBA” con las características mencionadas es utilizado para

diferentes tareas para los propietarios del edificio, por tanto, no se incurrirá en
ningún gasto.

[Link] Licencia de software

 Para publicar la el sistema web se deberá adquirir una cuenta de Azufre el

costo es de 80 Bs. Como pago por año.

156-163
[Link] Desarrollo de software

Para el presente Trabajo de Grado se empleará el Método de Puntos de Función

también llamado Análisis de Puntos de Función o FPA (Function Point Analysis).
FPA realiza las valoraciones a partir de la funcionalidad del sistema, primero
clasificándolas, luego asignando una complejidad y ponderación a cada una según
las tablas predefinidas, determinando así el valor de puntos de función.
Sumando los puntos de todas las funcionalidades se obtiene la valoración de todo
el proyecto y finalmente se puede aplicar un factor de ajuste, el cual puede depender
de características generales del sistema.

Los puntos de función permiten traducir el tamaño de funcionalidades de software

a un número, a través de la suma ponderadas de las características que este tiene.
Una vez que se cuenta con los puntos de función, los mismos son traducirlos en
horas hombre o días de trabajo, a partir de las cuales se determina el costo y
presupuesto de un proyecto.

a. Líneas de Código.

Para ello se emplea Correlación de Código Fuente por Punto de Función (LOC/FP),
donde el valor para PHP corresponde como se observa en la tabla 87:

Tabla 87: Factor LDC/PF de lenguajes de programación

Costo Total del Proyecto

Lenguaje de Programación Factor LDC/PF
Java 53
JavaScript 47
Visual Basic 46
PHP 12
C 150
Lenguajes de 4ta. Generación 20

Fuente: Factor LDC/PF de lenguajes de programación

157-163
El Punto función (para el sistema Web) PF=107.1 se toma del cálculo realizado en
la evaluación técnica en el subtítulo de funcionalidad.
Ahora se convierte los Puntos Función a miles de Líneas de Código (LDC) con la
siguiente ecuación:
Ecuación hallar líneas de código.

𝐿𝐷𝐶 = 𝑃𝐹 ∗ 𝐹𝑎𝑐𝑡𝑜𝑟 𝐿𝐷𝐶/𝑃𝐹 (4)

Fuente: Prieto, 2003.

Dónde:
𝑃𝐹: Medida de funcionalidad.
𝐹𝑎𝑐𝑡𝑜𝑟 𝐿𝐷𝐶/𝑃𝐹: Factor LDC/PF de lenguajes de Programación.

𝐿𝐷𝐶 = 𝑃𝐹 ∗ 𝐹𝑎𝑐𝑡𝑜𝑟 𝐿𝐷𝐶/𝑃𝐹

𝐿𝐷𝐶 = 107.1 ∗ 12
𝐿𝐷𝐶 = 1285.2

Las líneas de código en su totalidad son 1285.2 de las cuales se estima que
aproximadamente un 68% del Código es reutilizable, entonces el total del LCD es:

𝐾𝐿𝐶𝐷 = (𝑡𝑜𝑡𝑎𝑙 𝐿𝐶𝐷 − 𝐿𝐶𝐷 𝑅𝑒𝑢𝑡𝑖𝑙𝑖𝑧𝑎𝑏𝑙𝑒)/ 1000

𝐾𝐿𝐶𝐷 = (1285.2– 873.94)/1000
𝐾𝐿𝐶𝐷 = 0.41

KLDC: Número de líneas de código distribuidas.

Por lo tanto, existen 0.41 líneas de código distribuidas para el proyecto.

b. Esfuerzo.

Se estima el esfuerzo, con 8 horas por Punto de Fusión Promedio de trabajo, se

procede a calcular el esfuerzo representado en horas hombre con la siguiente
ecuación.

158-163
 Ecuación hallar el esfuerzo.

𝐸 = 𝑃𝐹 ∗ 𝐻𝑃𝐹𝑃 (5)

Fuente: Pressman, 2010.

Dónde:
𝐸: Esfuerzo (en horas – hombre)
𝑃𝐹: Puntos de Función
𝐻𝑃𝐹𝑃: Horas por Punto de Fusión Promedio

𝐸 = 𝑃𝐹 ∗ 𝐻𝑃𝐹𝑃
𝐸 = 107.1 ∗ 8
𝐸 = 856.8 (ℎ𝑜𝑟𝑎𝑠 − ℎ𝑜𝑚𝑏𝑟𝑒)

c. Tiempo.

Se obtiene el tiempo que requerido para desarrollar el software con la siguiente

ecuación:

Ecuación hallar el tiempo.

𝑇 = 𝐸/𝐻𝑇 (6)

Fuente: Pressman, 2010.

Dónde:
𝑇: Tiempo requerido para el desarrollo de Software (en meses)
𝐸: Esfuerzo (en horas – hombre)
𝐻𝑇: Horas de Trabajo al Mes (considerando que al mes se trabajaron 160 horas)

𝑇 = 𝐸/𝐻𝑇
𝑇 = 856.8/160
𝑇 = 5.35 (𝑚𝑒𝑠𝑒𝑠)

159-163
Para el presente proyecto consideramos la intervención de 1 programador, por lo
cual el tiempo se refleje (aproximadamente 2 mes), considerando que el sueldo de
cada desarrollador será de Bs. 2.164 por mes. Remplazando valores en la ecuación:

𝐶 = 2 ∗ 1 ∗ 2164 = 4.328 (𝐵𝑠)

El costo de desarrollo de software ascenderá a Bs.4.328 en un tiempo de 2 meses.

Costos variables

Los costos variables son aquellos que varían al modificar el volumen de producción
y se mueven en la misma dirección del nivel de producción, con el cambio en los
volúmenes de producción. Se procede a detallar y calcular los costos variables
identificados en el presente Trabajo de Grado.

[Link] Recopilación de la información

Los gastos generados para la realización del presente Trabajo de Grado se

evidencian en la tabla 73:

Tabla 88: Costo de recopilación de información (expresado en Bs.)

Ítem Unidad Cantidad Costo Unitario (Bs) Costo Total (Bs)

Internet Mes 5 198 990,00

Fotocopias hoja 180 0.20 36,00

transporte Pasaje 50 2 100,00

Total (Bolivianos) 1.126,00

Fuente: Elaboración Propia

[Link] Costo total del proyecto

Una vez detallados los costos variables y fijos del proyecto, se procede a determinar
los costos totales que el mismo genera en la tabla 89.

160-163
 Tabla 89: Costo total del proyecto (expresado en Bs)

DETALLE COSTO (BS.)

Costos Fijos
Compra de equipos 0,00
Licencias de software 208,80
Desarrollo de software (web) 8.656,00
Costos Variables
Recopilación de información 1.126,00
COSTO TOTAL (BS.) 11,582,00

Fuente: Elaboración Propia

Se concluye por tanto que el costo total del proyecto asciende a Bs 11, 582,00

161-163
 CAPÍTULO 4
CONCLUSIONES Y
RECOMENDACIONES
 CAPITULO 4
CONCLUSIONES Y
RECOMENDACIONES

CONCLUSIONES

Concluida la elaboración del presente proyecto, se pasa a detallar las conclusiones

a las que se llegó con relación a los objetivos planteados en el primer capítulo.

 Se identificó los procesos actuales que coadyuvaron a establecer los requisitos

del sistema y poder identificar a los actores que interactúan con el sistema,
para facilitar el manejo de la información, en la administración de un edificio

 Se observó los requerimientos específicos para determinar los procesos del

sistema a fin de suministrar información necesaria para el administrador del
edificio como los copropietarios.

 Se desarrolló el sistema de información para el seguimiento y control de la

administración de un edificio, que proporciona al usuario, información
actualizada permitiendo la ejecución de tareas en un tiempo mínimo y con una
interfaz amigable entendible y en tiempo real.

 Se obtuvo los resultados de las pruebas piloto, que ayudo a identificar fallas
existentes para la optimización del sistema al momento de su implementación.

162-163
 RECOMENDACIONES

Para que el sistema desarrollado cumpla con todos los requisitos solicitados por los
usuarios finales, se recomienda lo siguiente:

 Se recomienda realizar revisiones anuales, considerando que la actualización

conducirá a la mejora continua del sistema Web.

 Se debe agregar al sistema un módulo de pagos por cuenta bancaria para los
gastos comunes y sea más accesible para el residente como el administrador.

 Se debe agregar al sistema un módulo de generación de reportes anuales para

los ingresos y egresos

 Aprovechar el uso de herramientas de desarrollo, como el uso de frameworks

web que reduce el tiempo para agregar módulos en futuros desarrollos de
software.

163-163
BIBLIOGRAFIA
BIBLIOGRAFIA

Alejandra, V. R. (2019). modelo de gestión pública de administración de bienes y

servicios para incrementar la eficiencia en las direcciones administrativas del
ejército de bolivia.
Amazon web service. (2022). Amazon web service. Obtenido de Amazon web
service: [Link]
Bienes raices. (2022). Bienes raices. Obtenido de Bienes raices:
[Link]
administrador-de-edificios/
Britannica. (2022). Britannica. Obtenido de Britannica:
[Link]
Congreso nacional. (1949). Propiedad horizontal. Obtenido de PROPIEDAD
HORIZONTAL.
Daniel the wolf. (2015). Wordpress. Obtenido de Wordpress:
[Link]
IVAN, R. J. (2018). EFECTO DIGITAL. Obtenido de EFECTO DIGITAL:
[Link]
desarrollo-de-
software#:~:text=Especificaci%C3%B3n%3A%20lo%20que%20el%20siste
ma,a%20las%20demandas%20de%20cambio.
Javier, S. H. (2021). Lebschool. Obtenido de Lebschool:
[Link]
Jess, U. (2018). [Link]. Obtenido de [Link]: [Link]
types-of-testing-explained-1ljo
Junior, M. C. (2020). SISTEMA DE ADMINISTRACION PARA VENTA DE
PRODUCTOS ARTESANALES EMPLEANDO COMERCIO ELECTRONICO.
Koporcic, R. G. (2022). Develop. Obtenido de Develop: [Link]
calcula-el-prorrateo-de-los-gastos-
comunes/#:~:text=%C2%BFQu%C3%A9%20es%20el%20prorrateo%3F,in
mueble%20para%20los%20gastos%20comunes.
Laravel. (2022). [Link] Obtenido de
[Link]
[Link]
Lmu – ludwig-maximilians-universität münche. (2022). UWE - Ingeniería web
basada en UML. Obtenido de UWE - Ingeniería web basada en UML:
[Link]
Maida, P. (2015). Metodologia de Desarrollo.
MySQL. (2022). MySQL. Obtenido de MySQL: [Link]
Node,js. (2022). Node,js. Obtenido de Node,js: [Link]
Oracle. (2022). Oracle. Obtenido de Oracle:
[Link]
Php. (2022). [Link]. Obtenido de [Link]: [Link]
[Link]
Platzi. (2018). Platzi. Obtenido de Platzi: [Link]
backend/
Postgres. (2022). [Link] Obtenido de
[Link]
Propiedad horizontal o propiedad en condominios. (2022). Asesorate en bolivia.
Obtenido de Asesorate en bolivia:
[Link]
reglamentos-de-propiedad-horizontal-o-propiedad-en-condominio-precio-
por-unidad-conformada-
a7cq#:~:text=Un%20edificio%20(propiedad%20horizontal)%20o,calle%20o
%20a%20un%20elemento%20com%C3
Redhat. (2022). Redhat. Obtenido de Redhat:
[Link]
methodology#:~:text=En%20concreto%2C%20las%20metodolog%C3%ADa
s%20%C3%A1giles,equipo%20para%20ofrecer%20mejoras%20constantes
.
Roman, C. T. (2020). Aaplicacion web progresiva para identificacion de vehiculos.
Roman, M. J. (2022). Lenguajes. Obtenido de Lenguajes:
[Link]
[Link], E. -B. (2015). Analisis y Diseño de Sistemas de Información.
Schwaber, K., & Sutherland, J. (2020). La Guia de Scrum. Scrum Guides, 8.
Scrumstudy. (2013).
Seoestudios. (Octubre de 2020). Seoestudios. Obtenido de Seoestudios:
[Link]
Universidad tecnica del norte. (2015). Slidshare. Obtenido de Sildshare:
[Link]
Web empresa. (2022). Web empresa. Obtenido de Web empresa:
[Link]
Wild code school. (2021). Wild code school. Obtenido de Wild code school:
[Link]
programacion
GLOSARIO
GLOSARIO

 Framework

Es un marco o esquema de trabajo generalmente utilizado por programadores para

realizar el desarrollo de software. Usar un framework permite agilizar los procesos
de desarrollo ya que evita tener que escribir código de forma repetitiva, asegura
unas buenas prácticas y la consistencia del código.

 Sistema

Es un conjunto de elementos relacionados entre sí que funciona como un todo. Si

bien cada uno de los elementos de un sistema puede funcionar de manera
independiente, siempre formará parte de una estructura mayor. Del mismo modo,
un sistema puede ser, a su vez, un componente de otro sistema.

 Software: Software

Es un término informático que hace referencia a un programa o conjunto de

programas de cómputo, así como datos, procedimientos y pautas que permiten
realizar distintas tareas en un sistema informático.

 Prorrateo

Significa dividir proporcionalmente una cantidad. Por tanto, el prorrateo es el reparto

proporcional de una cantidad o un coste entre diferentes apartados o personas.

 Administración

La hemos definido en términos generales como el proceso que consiste en planear,

organizar, dirigir y controlar los recursos humanos, técnicos y financieros
encaminados al logro de los objetivos organizacionales.

 Condominio

Se refiere a un conjunto habitacional integrado por viviendas, departamentos, casas

u otros similares ubicados en un mismo predio.
 Propiedad horizontal

Se ejerce sobre uno o más pisos, viviendas o locales de un edificio, que han sido
adquiridos por distintos propietarios en forma separada pero que tienen ciertos
derechos y obligaciones en común.
ANEXOS
 ANEXOS A
ÁRBOL DE PROBLEMAS
ANEXOS

ANEXO A: Árbol de problemas

la comunicacion del No dispone de información oportuna

administrador hacia los referente al control de los pagos de
recidentes. los ingresos e egresos

El control del administrador a los ingresos y

egresos del edificio provoca una deficiencia en
los informes de los gastos realizados sobre los
bienes comunes y sus mantenimientos,

la falta de accebilidad a los informes de los No terner control sobre las reservaciones de la
ingresos y egresos que se hace en la areas comunes
administracion de un edificio
 ANEXO B
ÁRBOL DE OBJETIVOS
 ANEXO B: Árbol de objetivos

Analizar los procesos actuales de la Realizar las pruebas testing, para comprobar el
administración del edificio para determinar a correcto funcionamiento del sistema con el
los actores y sus características. control de la administración de un edificio..

Desarrollar un sistema web de administración de edificios para

centralizar la información con la finalidad de mejorar el control de
ingresos y egresos

Diseñar una interfaz gráfica amigable que

Identificar los requerimientos funcionales y no ayude de manera dinámica la
funcionales para determinar las necesidades del administración del edificio en el control de
proceso de la administración del edificio. los ingresos y egresos y sea accesible a la
información para los residentes.
 ANEXOS C
REQUERIMIENTOS DE DESARROLLO
DE SOFTWARE
 ANEXO C: Requerimientos de desarrollo de software

ACTA ESPECIFICACION DE REQUERIMIENTOS DE DESARROLLO

Fecha de Acta: 1 1 1 4 2 0 2 2
Unidad/Area Solicitante: Ubicación de la unid./area Sol:
Administrador Edifificio corba sopocachi plaza españa
Telefono/Interno: Nombres y Apellidos del (la) solicitante (StakerHolder):
76256079 Antonio Marcos Rodriguez Alvarez
Cargo: Celular o Coorp:

Referente funcional(Product Owner): Celular Coorporativo:

[Link]. Samuel Calle Condori 78595655
Tipo de Requerimiento: Sistema a modificar o Desarrollar:
Desarrollo: X Net Bank: X
Mantenimiento: Sai:

Modulo: ReNuevo: X
WebService: X
Otro:

INFORMACION DE PARTICIPANTES
Nombre y Apellidos Cargo Unidad
Antonio Marcos Rodriguez Alvarez Administrador dept N°2
Luis gabriel Machicado Residente dept N°3
Nicol Rodriguez Tarquiola Residente dept N°7
Hugo Alvaro Rodriguez Quispe Residente dept N°9
REQUERIMIENTO GENERAL
sistema web para la administración de edificios con la finalidad de mejorar el control de la información de ingresos y
egresos que componen las áreas comunes.

REQUERIMIENTOS ESPECIFICOS - PILA DE PRODUCTO (PRODUCT BACKLOG)

Proceso
Codigo Descripción/Enunciado Prioridad
Entrada Salida
R1 Gestión de usuario
Formulario de reservación de los espacios comunes Alta
R2
Elaboración de los informes de los ingresos y egresos de los gasto comunes 11-14-2022 Alta
R3 11-22-2022 Alta
Comunicado por vía gmail la reservación de los espacios comunes y envió de
los informes de los gastos comunes ordinarios que se brinda a cada residente
cada mes
Solicitante (Product Owner) Aprobado por (Scrum Master): Asignado a(Scrum Team):
 ANEXOS D
Cuestionario de usabilidad
 ANEXO D: Cuestionario de usabilidad

Nombre Apellido

Por favor califique del 1 al 5 donde 5 es mayor valor y 1 menor valor

¿Es entendible es sistema?

1 2 3 4 5

¿Puede utilizarlo fácilmente?

1 2 3 4 5

¿Es sencillo acceder a los datos?

1 2 3 4 5

¿El sistema responde rápido a sus solicitudes?

1 2 3 4 5

¿Los reportes que genera son útiles?

1 2 3 4 5

¿El sistema le proporciono las respuestas requeridas?

1 2 3 4 5

¿Está de acuerdo con el funcionamiento del software?

1 2 3 4 5