UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO

“SISTEMA DE INFORMACIÓN PARA EL CONTROL Y

SEGUIMIENTO DE RECURSOS FINANCIEROS
CASO: CONDOMINIO LA JOYA”

PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA

MENCIÓN: INGENIERÍA DE SISTEMAS INFORMÁTICOS

POSTULANTE: JUAN CARLOS OLIVARES CHIARA

TUTORA METODOLOGICA: Ph. D. FÁTIMA CONSUELO DOLZ SALVADOR
ASESOR: Lic. JUAN GONZALO CONTRERAS CANDIA

LA PAZ – BOLIVIA
2017

i
 UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

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

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.

LICENCIA DE USO

El usuario está autorizado a:

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

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
 DEDICATORIA.

Dedico este Proyecto de Grado A.

DIOS, A mis padres Silverio y Jesusa
quienes me dieron vida, educación,
apoyo y consejos.
A toda mi familia. Francisco, Rosmery,
Rafael, Luis, Carmen, Diana, Juana
Lidia y Rubén Arturo.

ii
AGRADECIMIENTOS

Primeramente agradecer a Dios por la hermosa vida, salud que me brinda, por guiarme
siempre en el camino correcto, por las lecciones, oportunidades y todo lo grandioso que me
tocó vivir, por permitirme llegar a este momento tan especial, y por poner en mi camino a
diferentes personas que me ayudaron a culminar esta etapa de mi vida.
Quiero agradecer a mi papá Silverio Olivares, a mi mamá Jesusa Chiara, por brindarme el
apoyo y cariño incondicional más allá del deber de padres.
Agradecerles por todo el esfuerzo que hicieron para darme, recursos necesarios para
estudiar, por los sacrificios y la paciencia que demostraron todos estos años, por
las palabras de aliento. Y al resto de mi familia, mis hermanos Francisco, quien me
transmitió sus conocimientos para formarme en mi profesión. a la perdida de mi padre, Luis
quien desde la distancia siempre estuvo dándome el apoyo moral, Juana Lidia por ser el
ejemplo de una hermana mayor, y como una madre, en los momentos más difíciles de mi
vida, Rubén Arturo por brindarme todo su apoyo y cariño. Los amo con todo mi corazón.
A la Universidad, un agradecimiento muy especial a la Universidad Mayor de San Andrés
que durante años me ha acogido en sus aulas, las cuales han sido como un segundo hogar
y en especial a la Carrera de Informática.
Un infinito agradecimiento a la : Ph. D. Fátima Consuelo Dolz Salvador, mi docente tutora,
por toda su colaboración, su enorme paciencia, por el tiempo brindado a lo largo de toda
la revisión y corrección del presente trabajo, por brindarme su ayuda y sabios
consejos en el planteamiento y estructura de este Proyecto de Grado. Su comprensión
y confianza fueron vitales para la culminación de este Proyecto de Grado
Un agradecimiento especial al Lic. Juan Gonzalo Contreras Candía, mi docente asesor, por
el asesoramiento, el tiempo brindado, la paciencia, por todos los consejos y revisiones,
desde el inicio hasta la culminación de este Proyecto de Grado, gracias por su colaboración.
A los señores: Fernando Arzabe I., Daniel Pérez P. y Willy Chuquimia T. Quienes me han
orientado y brindaron las herramientas necesarias, en toda la etapa de mi formación
académica.
A los responsables del Condominio La Joya, por su colaboración, confianza y apoyo en
el transcurso del desarrollo de este proyecto.
Por último, pero no menos importante, les doy las gracias a mis amigos que tiene el talento
de aparecer en momentos indicados, por sus consejos muchas gracias.
iii
 RESUMEN

El contar con un sistema de información es una necesidad inevitable en nuestro

contexto laboral, puesto que es esencial para la gestión de la información, el cual
nos ayuda generar datos confiables y oportunos, y estas nos permiten apoyar en la
toma de decisiones.

El desplazamiento de las distintas organizaciones hacia sitios web, ha traído en la

actualidad una constante evolución en las aplicaciones Web. La transferencia de
información confidencial y ejecución de procesos online, entre otros, exigen
funcionalidad, confiabilidad, usabilidad y eficiencia como algunas de las
características principales de calidad de Software.

Tomando en cuenta estas consideraciones, es necesario implementar un

“Sistema de Información para el Control y Seguimiento de Recursos Financieros
Condominio La Joya”. Este reto implica: ofrecer un servicio de información que
permita realizar seguimiento y generar reportes sobre deudas acumuladas por
concepto de mantenimiento y que los mismos sean confiables, pertinentes y
además que la información acerca del comportamiento del condominio esté
almacenada en una base de datos, segura en un servidor y protegida por un acceso
restringido para su posterior utilización.

Para la implementación del sistema de información se utilizaron los lenguajes de

Programación: Php, Html5, JavaScript, Css3, y los frameworks: Laravel, JQuery, y
una base de datos creada en Mysql, los cuales se adecuan a las necesidades y
requerimientos de la Institución.

La metodología utilizada para el desarrollo del sistema de información es, SCRUM.

Caracterizado en iteraciones y entregas inmediatas de desarrollo del producto. Para
el análisis y diseño en sus diferentes fases, se utilizó las historias de Usuario.

iv
Tabla de contenido
CAPITULO 1.............................................................................................................................................. 1

1.1 INTRODUCCIÓN. ....................................................................................................................................... 1

1.2 ANTECEDENTES. ....................................................................................................................................... 3
1.2.1 Tipos de ingreso percibidos. ............................................................................................................. 5
1.2.2 Tipos de egresos generados. ............................................................................................................ 7
1.3 PLANTEAMIENTO DEL PROBLEMA. ........................................................................................................ 10
1.3.1 Problema general. .......................................................................................................................... 10
1.3.2 Problemas específicos. ................................................................................................................... 11
1.4 OBJETIVOS. ............................................................................................................................................. 12
1.4.1 Objetivo general ............................................................................................................................. 12
1.4.2 Objetivos específicos. ..................................................................................................................... 12
1.5 JUSTIFICACIONES. .................................................................................................................................. 12
1.5.1 Justificación Social.......................................................................................................................... 12
1.5.2 Justificación técnica. ...................................................................................................................... 13
1.5.3 Justificación económica. ................................................................................................................ 13
1.6 ALCANCES. ............................................................................................................................................. 13
1.6.1 Alcance temporal. .......................................................................................................................... 13
1.6.2 Alcance temático............................................................................................................................ 14
1.7 METODOLOGÍA. ..................................................................................................................................... 15
1.7.1 Herramientas a utilizar. ................................................................................................................. 15
1.7.2 Técnicas para obtención de datos.................................................................................................. 16

CAPITULO 2............................................................................................................................................ 18

2.1 INTRODUCCIÓN........................................................................................................................................... 18
2.2 PROPIEDADES COMPARTIDAS. ....................................................................................................................... 18
2.3 CONCEPTO DE PROYECTO. ..................................................................................................................... 18
2.4 CONCEPTO DE METODOLOGÍA. ...................................................................................................................... 19
2.5 VENTAJAS DE USAR UNA METODOLOGÍA. ............................................................................................. 20
2.6 METODOLOGÍA ÁGIL. ............................................................................................................................. 21
2.7 METODOLOGIA SCRUM. ........................................................................................................................ 21
2.8 COMPONENTES SCRUM. ........................................................................................................................ 25
2.8.1 Planificación del Backlog................................................................................................................ 25

v
 2.8.2 Seguimiento del Sprint ................................................................................................................... 26
2.8.3 Revisión del Sprint .......................................................................................................................... 27
2.9 ROLES SCRUM. ....................................................................................................................................... 27
2.10 ELEMENTOS SCRUM. ............................................................................................................................ 29
2.11 PREPARACIÓN DEL PROYECTO. ............................................................................................................ 35
2.12 PLANIFICAR UN SPRINT. ....................................................................................................................... 36
2.13 DESARROOLLO SPRINT. ........................................................................................................................ 36
2.14 TECNOLOGIAS DE DESARROLLO WEB. .................................................................................................. 37
2.14.1 Mvc. ............................................................................................................................................. 37
2.14.2 Framework Laravel. ..................................................................................................................... 38
2.14.3 Estándar Html5 ............................................................................................................................ 39
2.14.4 Calidad del software .................................................................................................................... 41

CAPITULO 3............................................................................................................................................ 51

3.1 INTRODUCCIÓN. ..................................................................................................................................... 51

3.2 PREGAME PLANIFICACIÓN. .................................................................................................................... 52
3.2.1 Elaboración del Product-Backlog. .................................................................................................. 52
3.3 GAME Y FASE DE PRODUCCION. ............................................................................................................. 60
3.3.1 Desarrollo de los Sprints. ................................................................................................................ 60
3.4 POSTGAME PRUEBAS. ............................................................................................................................ 74
3.5 MANTENIMIENTO DEL SISTEMA. ........................................................................................................... 78
3.6 CALIDAD DE SOFTWARE. ........................................................................................................................ 79
3.6.1 Funcionalidad. ................................................................................................................................ 79
3.6.2 Confiabilidad. ................................................................................................................................. 83
3.6.3 Usabilidad. ..................................................................................................................................... 83
3.6.4 Eficiencia. ....................................................................................................................................... 85
3.6.5 Mantenibilidad. .............................................................................................................................. 86
3.6.6 Portabilidad. ................................................................................................................................... 87
3.7 SEGURIDAD DEL SOFTWARE. ................................................................................................................. 89
3.7.1 Políticas de seguridad (Usuarios). .................................................................................................. 89
3.7.2 Políticas de acceso de seguridad al sistema de información. ........................................................ 90

CAPITULO 4............................................................................................................................................ 92

4.1 CONCLUSIONES. ..................................................................................................................................... 92

4.2 RECOMENDACIONES. ............................................................................................................................. 93

BIBLIOGRAFÍA ............................................................................................................................................ 94

vi
ÍNDICE DE TABLAS
TABLA 3-1: REQUERIMIENTOS BÁSICOS DEL PROYECTO. ................................................................................................ 52
TABLA 3-2: PILA DE REQUERIMIENTOS ...................................................................................................................... 53
TABLA 3-3: ROLES POR ACTOR ................................................................................................................................. 54
TABLA 3-4: PLANIFICACIÓN DE LA PRIMERA ITERACIÓN ................................................................................................. 60
TABLA 3-5: PLANIFICACIÓN DE LA SEGUNDA ITERACIÓN ................................................................................................ 60
TABLA 3-6: PLANIFICACIÓN DE LA TERCERA ITERACIÓN.................................................................................................. 60
TABLA 3-7: PLANIFICACIÓN DE TAREAS DEL SPRINT ...................................................................................................... 61
TABLA 3-8: TAREAS POR USUARIO DEL SPRINT............................................................................................................. 62
TABLA 3-9: ÉXITOS Y FRACASOS DEL SPRINT ............................................................................................................... 67
TABLA 3-10: PLANIFICACIÓN DE TAREAS DEL SPRINT .................................................................................................... 68
TABLA 3-11: TAREAS POR USUARIO DEL SPRINT........................................................................................................... 68
TABLA 3-12: ÉXITOS Y FRACASOS DEL SPRINT ............................................................................................................. 70
TABLA 3-13: PLANIFICACIÓN DE TAREAS DEL SPRINT .................................................................................................... 71
TABLA 3-14: TAREAS POR USUARIO DEL SPRINT........................................................................................................... 72
TABLA 3-15: CASO DE PRUEBA INGRESO AL SISTEMA .................................................................................................... 75
TABLA 3-16: CASO DE PRUEBA REGISTRO DE USUARIOS ................................................................................................ 76
TABLA 3-17: CASO DE PRUEBA REPORTE DE USUARIOS. ................................................................................................ 76
TABLA 3-18: CASO DE PRUEBA REGISTRO DE PROPIEDADES............................................................................................ 77
TABLA 3-19: CASO DE PRUEBA REGISTRO DE USUARIOS. ............................................................................................... 77
TABLA 3-20: ARCHIVO LÓGICO INTERNO. ................................................................................................................... 80
TABLA 3-21: CÁLCULO DE PUNTOS POR FUNCIÓN SIN AJUSTAR. ..................................................................................... 80
TABLA 3-22: CÁLCULO DE FACTOR DE AJUSTE ............................................................................................................ 81
TABLA 3-23: VALORES PARA EVALUAR LA USABILIDAD .................................................................................................. 84
TABLA 3-24: TABLA DE PREGUNTAS. ......................................................................................................................... 84
TABLA 3-25: RANGOS PARA EVALUAR LA EFICIENCIA .................................................................................................... 85
TABLA 3-26: VALORACIÓN PARA LA EFICIENCIA ........................................................................................................... 86
TABLA 3-27: RANGOS PARA LA MANTENIBILIDAD. ....................................................................................................... 87
TABLA 3-28: VALORACIÓN PARA LA MANTENIBILIDAD. ................................................................................................. 87
TABLA 3-29: RANGOS PARA LA PORTABILIDAD. ........................................................................................................... 88
TABLA 3-30: VALORACIÓN PARA LA PORTABILIDAD. ..................................................................................................... 88
TABLA 3-31: RESUMEN DE RESULTADOS .................................................................................................................... 89

vii
 ÍNDICE DE FIGURAS

FIGURA 1-1: ORGANIGRAMA LA JOYA ......................................................................................................................... 5

FIGURA 1-2: DETERMINACIÓN DE INGRESOS ................................................................................................................. 8
FIGURA 1-3: COMPROBANTE DE INGRESO DE EFECTIVO................................................................................................... 8
FIGURA 1-4: COMPROBANTE DE PAGO ........................................................................................................................ 9
FIGURA 2-1: CICLO DE DESARROLLO ÁGIL ................................................................................................................... 24
FIGURA 2-2: CICLO PRINCIPAL DE SCRUM................................................................................................................... 25
FIGURA 2-3: PLANIFICACIÓN DEL BACKLOG ................................................................................................................ 26
FIGURA 2-4: SEGUIMIENTO DEL SPRINT ..................................................................................................................... 27
FIGURA 2-5: REVISIÓN DEL SPRINT ........................................................................................................................... 27
FIGURA 2-6: ROLES SCRUM .................................................................................................................................... 28
FIGURA 2-7: ELEMNTOS SCRUM .............................................................................................................................. 29
FIGURA 2-8: HISTORIA DE USUARIO .......................................................................................................................... 32
FIGURA 2-9: NORMA DE EVALUACIÓN ISO/IEC 9126 ................................................................................................. 42
FIGURA 2-10: EVALUACIÓN INTERNA, EXTERNA Y CALIDAD DE USO ISO/IEC 9126 ........................................................... 43
FIGURA 2-11: CARACTERÍSTICA DE FUNCIONALIDAD ..................................................................................................... 44
FIGURA 2-12: CARACTERÍSTICA DE CONFIABILIDAD ...................................................................................................... 45
FIGURA 2-13: CARACTERÍSTICA DE USABILIDAD .......................................................................................................... 46
FIGURA 2-14: CARACTERÍSTICA DE EFICIENCIA ............................................................................................................ 47
FIGURA 2-15: CARACTERÍSTICA DE MANTENIMIENTO................................................................................................... 48
FIGURA 2-16: CARACTERÍSTICA DE PORTABILIDAD ....................................................................................................... 49
FIGURA 3-1: FASES DE SCRUM PARA EL DESARROLLO DE SOFTWARE ................................................................................ 51
FIGURA 3-2: ARQUITECTURA MVC .......................................................................................................................... 54
FIGURA 3-3: CASO DE USO GENERAL ......................................................................................................................... 56
FIGURA 3-4: MODELO ENTIDAD RELACIÓN ................................................................................................................ 57
FIGURA 3-5: DIAGRAMA DE CLASES PARA EL SISTEMA ................................................................................................... 58
FIGURA 3-6: DIAGRAMA BASE DE DATOS ................................................................................................................... 59
FIGURA 3-7: GESTIÓN DE USUARIOS DE LA PÁGINA WEB................................................................................................ 64
FIGURA 3-8: GESTIÓN DE RESPONSABLES DE LA PÁGINA WEB ......................................................................................... 65
FIGURA 3-9: REGISTRO INGRESO DE EFECTIVO............................................................................................................. 66
FIGURA 3-10: REGISTRO EGRESOS DE EFECTIVO .......................................................................................................... 67
FIGURA 3-11: INGRESO CUOTA MENSUAL PROTOTIPO .................................................................................................. 69
FIGURA 3-12: INGRESO CUOTA MENSUAL .................................................................................................................. 70
FIGURA 3-13: REPORTE PLANILLA ............................................................................................................................ 73
FIGURA 3-14:CIERRE DE PLANILLA............................................................................................................................ 74

viii
 Capítulo I

Marco Introductorio
ix
 CAPITULO 1.
1.1 INTRODUCCIÓN.
Los sistemas de información se han ido convirtiendo con el tiempo, en otra área
funcional de una organización, tal como la de contabilidad, finanzas, mercadeo, o
producción. En la actualidad toda organización exitosa se ha concientizado de la
importancia del manejo de las tecnologías de información (TI) como elemento que
brinda ventajas comparativas con respecto a la competencia.

Es importante tener en cuenta que un sistema de información necesita justificar su

implementación desde el punto de vista - costo / beneficio, partiendo de la
concepción del valor que se le otorgue a la información dentro de una organización.

Los beneficios se pueden medir a nivel intangible y tangible de acuerdo a la

organización, pues es diferente hacer el análisis desde el punto de vista de una
organización comercial a una de tipo académico que pretende prestar un servicio
social como lo es la salud o educación pública.

Los beneficios que se pueden obtener usando sistemas de información son los
siguientes:

 Acceso rápido a la información y por ende mejora en la atención a los

usuarios.
 Mayor motivación en los mandos medios para anticipar los requerimientos
de las directivas.
 Generación de informes e indicadores, que permiten corregir fallas difíciles
de detectar y controlar con un sistema manual.
 Posibilidad de planear y generar proyectos institucionales soportados en
sistemas de información que presentan elementos claros y sustentados.
 Evitar pérdida de tiempo recopilando información que ya está almacenada
en bases de datos que se pueden compartir.
 Impulso a la creación de grupos de trabajo e investigación debido a la
facilidad para encontrar y manipular la información.

1
  Soluciona el problema de falta de comunicación entre las diferentes
instancias. A nivel directivo se hace más efectiva la comunicación.
 Organización en el manejo de archivos e información clasificada por temas
de interés general y particular.
 Generación de nuevas dinámicas, utilizando medios informáticos como el
correo electrónico, multimedia, teleconferencia, acceso directo a bases de
datos y redes nacionales e internacionales.
 Acceso a programas y convenios e intercambios institucionales.
 Aumento de la productividad gracias a la liberación de tiempos en
búsqueda y generación de información repetida.

(Leod, 2000)

Los sistemas de información (SI) son reconocidos como una herramienta básica
para usar y acceder a la información además de facilitar el proceso de toma de
decisiones en las organizaciones.

Según Arjonilla Domínguez.

“un sistema de información está formado por un conjunto de elementos integrados

e interrelacionados que persiguen el objetivo de capturar, depurar, almacenar,
recuperar, actualizar y tratar datos para proporcionar, distribuir y transmitir
información en el lugar y momento en el que sea requerido en la organización”

(Domínguez & Aurelio, 2009)

Andreu, Ricart y Valor, definen a los sistemas de información.

“como el conjunto formal de procesos que opera con un conjunto estructurado de

datos de acuerdo a las necesidades que una organización, recopila, elabora y
distribuye la información necesaria para la operación de dicha organización y para
las actividades de dirección de control correspondientes, apoyando al menos en
parte, la toma de decisiones necesaria para desempeñar las funciones y procesos
de negocio de acuerdo con su estrategia”

(Valor, R, & E., 1991)

2
Las organizaciones siempre utilizaron sistemas que les permitieron administrar el
manejo de su información, con lo cual no necesariamente debe existir una
computadora para reconocer la existencia de estos tipos de sistemas pues estos
pueden ser también del tipo manuales; por ejemplo, una organización pequeña que
no tenga informatizada la totalidad de sus esquemas de logística y comercialización.
Lo importante es que el sistema permita almacenar, recuperar, procesar y distribuir
información.

Sin embargo, es cada vez más necesario el disponer de sistemas de información

basados en computadoras por los beneficios que estos proporcionan: reducción de
errores provocados por las personas a través del control de las entradas, velocidad
en el procesamiento de datos, posibilidad de realizar tediosos análisis sobre los
mismos, reducción de espacio físico destinado a su almacenamiento, agilidad al
momento de buscar algún dato en particular, y otros tipos de ventajas que podrían
lograrse en caso de enfocarse en el uso estratégico de los mismos.

La implementación de un sistema de información, ayuda a tener respuestas

inmediatas y precisas en cualquier tipo de organización.

Un condominio es un conjunto de propiedades que residen en un mismo previo en

el cual se comparten los espacios comunes como: parques jardines, ambiente para
juegos, salones de eventos, parqueos e instalaciones deportivas etc. En el que
existen gastos en común como el mantenimiento de áreas verdes, cañerías, ductos
limpieza de los mismos, seguridad y otros que tienen que ser cancelados por todos
los copropietarios.

1.2 ANTECEDENTES.
La mayoría de las personas adultas, cada una en su momento, desean adquirir su
vivienda propia. Y hoy en día, una de las alternativas más buscadas, son los
denominados condominios. Principalmente por su seguridad. Esto, ya que al ser
unidades habitacionales que se encuentran dentro de un mismo terreno,
generalmente cercadas y con portones, para su ingreso o egreso, hace que las
personas se sientan más tranquilas. Cuando se habla de condominios,
generalmente el común de las personas tiende a asociarlo solamente a un edificio

3
de varios pisos. Por ello es importante que veamos el origen y significado de este
término. La primera forma registrada históricamente de lo que significó la
convivencia vecinal, el amor a la propiedad conjuntamente con un ambiente de
confraternidad, tipo condominio, se remonta exactamente al año 1720, en la ciudad
de Grenoble, localizada en el sureste de Francia, aproximadamente a 100
kilómetros de Lyon, producto de un gran incendio que dejó sin viviendas a
numerosas familias, que por decreto y diseño de su Corte para aquel entonces
fueron reunidas para vivir juntas, compartiendo la propiedad. Condominio, tomado
del inglés condominium, palabra de origen latina, formada con el prefijo con y el
sustantivo dominium, dominio, la cual significa propiedad en común. El Vocabulario
Jurídico de Henri Capitant, lo define como "Derecho de propiedad existente a favor
de varias personas sobre un bien mueble o inmueble, bajo la forma de cuotaspartes,
ideales o partes ideales, es decir, fracciones. Permite a cada propietario usar de la
cosa bajo la condición de respetar los derechos concurrentes de los otros, gozar de
ella y en principio disponer del bien libremente, en la medida de su cuotaparte."

La propiedad compartida “Condominio La Joya” se encuentra ubicada en la zona de

Sopocachi, Calle Melchor Pérez De Holguin Numero 2467, en este edificio conviven
un gran número de copropietarios e inquilinos, los cuales comparten servicios y
obligaciones.

Para una adecuada gestión de estas obligaciones se cuenta con un directorio que
se elige cada 3 años, este directorio contrata un administrador para llevar adelante
las tareas administrativas y un control adecuado del flujo de los ingresos y egresos
generados en este condominio. Asimismo, este convoca a las asambleas generales
y extraordinarias conforme a sus reglamentos.

4
 Figura 1-1: Organigrama La Joya
Fuente: [Condominio “La Joya”]

Para el directorio las obligaciones de los copropietarios e inquilinos vienen a

conformar ingresos mensuales y casuales. Los gastos erogados para el
mantenimiento de las áreas compartidas llegan a ser gastos o egresos.

1.2.1 Tipos de ingreso percibidos.

Existen ingresos mensuales, casuales y externos.

3.3.1.1 Ingresos internos Mensuales.

Mantenimiento Departamento.
El monto base es diferenciado, para copropietarios de 119 Bs. E inquilinos
Bs. 200, a este monto se incrementa el prorrateo del consumo de agua potable.
Este concepto tiene la finalidad de cubrir los siguientes gastos:

o Mantenimiento del ascensor.

o Cuidado y arreglo de los jardines.
o Sueldos para personal administrativo, portería y limpieza.
o Pago del agua potable (el agua es compartida ya que no es posible
medidores independientes).
5
 o Pago de energía eléctrica consumida en áreas comunes.
o Insumos varios para realizar mantenimiento de las áreas compartidas.

Mantenimiento Parqueo.
Para cubrir los gastos operativos del parqueo automotor. Tiene un costo fijo
de 20 bolivianos.

Mantenimiento Baulera.
Para cubrir los gastos de energía eléctrica y limpieza. Tiene un costo fijo de
7 bolivianos.

Alquiler Baulera Condominio.

Por el préstamo de ambiente para depósito. A los copropietarios o inquilinos,
tiene costo de 140 y 90 bolivianos.

Alquiler área común (parqueo motocicletas).

Monto diferenciado, para copropietarios monto 10 bolivianos e inquilinos
monto 90 bolivianos. (Corresponde a la suma del alquiler 80 Bs. y mantenimiento
10 Bs).

Área común minimarket.

El copropietario de esta área paga el concepto de mantenimiento de
departamento, con montos significativamente elevados por tratarse de un área
comercial. 140Bs.

3.3.1.2 Tipos de Ingresos internos casuales.

Que se realizan por actividades distintas, que son:

Alquiler de salón.
Monto diferenciado para copropietarios 150Bs. e inquilinos, 300Bs. por
concepto del alquiler del salón para la realización de eventos o relaciones
recreacionales.

Traslados ingreso/salida de personas.

Concepto que es cobrado sin existir diferencia ya sea un copropietario o
inquilino el cual deja o ingresa a la propiedad 140Bs.

6
 Cuotas extraordinarias.
Cobro exclusivamente copropietarios, para la compra o revisión que se
realizada en el inmueble, como ser: bombas y tanques de agua, construcciones de
obras, que traen beneficios a los copropietarios.

Otros ingresos.
Montos iguales sin existir diferencia, entre copropietarios e inquilinos, por concepto
de servicio de mantenimiento en las instalaciones para evitar problemas en el
alcantarillado, fugas de agua por el descuido de algunas personas.

3.3.1.3 Ingresos Externos.

Son generados por servicios proporcionados a empresas o particulares externas al
condominio.

Entel. Empresa Nacional de Telecomunicaciones. Por el servicio de alquiler de

azotea (antenas de telecomunicación) 35.708Bs.

1.2.2 Tipos de egresos generados.

Existen egresos mensuales y egresos variables.

3.3.1.1 Egresos generados fijos.

Sueldos a personal.
Administrador, seguridad, limpieza y portero.

Facturas por servicios básicos.

Agua, energía eléctrica y teléfono de portería

Mantenimiento de servicios.
Ascensor, tanques de agua, bombas de agua y garaje automático.

7
 Figura 1-2: Determinación de ingresos
Fuente: [Elaboración propia.]

Figura 1-3: Comprobante de ingreso de efectivo

Fuente: [Condominio “La Joya”]

8
 3.3.1.2 Egresos generados variables
Mantenimiento correctivo.
Ascensor, tanques de agua, bombas de agua y garaje automático.

Pago de servicios por reparación o refacción.

Plomero, pintor, electricista y albañiles.

Compra de insumos.
Utensilios de limpieza y material de escritorio.

Gastos de inversión.
Compra de equipos, muebles y otros activos fijos.

Gastos generales.
Gastos de menor costo y casuales (pasajes de transporte, tarjeta para
llamadas telefónicas).

Figura 1-4: Comprobante de pago

Fuente: [Condominio “La Joya”]
Todo el flujo de efectivo de ingresos y egresos, los gestiona el administrador de
acuerdo a las decisiones que toma el directorio.

El proceso de flujo de ingresos y/o egresos, es de forma manual, el administrador

llena los recibos de ingresos y los comprobantes de pago, estos son registrados en
una hoja de cálculo de Excel.

9
Por disposición del directorio, el administrador realiza un estado de cuenta cada fin
de mes, para verificar cuanto saldo a favor se tiene, como ya mencionamos
anteriormente este proceso se lo realiza de forma manual con la ayuda de hojas de
cálculo en Excel.

Si bien la mayor parte de los copropietarios e inquilinos cumplen con las cuotas
mensuales, existen otros que no lo hacen, acumulan deudas de hasta 24 meses.
Estos a su vez ocasionan problemas de gestión en la administración ya que
mensualmente se debe de cumplir con egresos generados, para el adecuado
funcionamiento de los servicios básicos.

1.3 PLANTEAMIENTO DEL PROBLEMA.

Como se mencionó en los antecedentes el condómino La Joya, toma decisiones por
medio del directorio, el cual toma las decisiones más importantes para el bienestar
de los copropietarios. Estas decisiones son ejecutadas y cumplidas por el
administrador.

Actualmente el administrador gestiona sus actividades de forma manual con la

ayuda de hojas de cálculo en Excel, para generar el estado de deuda de los
copropietarios e inquilinos, y realizar el cobro de mantenimiento respectivo al mes.

Existen demora a consultas sobre:

 Cuál será el monto de la cuota mensual para cada copropietario o

inquilino.
 Deudas acumuladas en meses pasados por parte de los
copropietarios e inquilinos.
 Cuanto será el efectivo que se tendrá a una determinada fecha, para
proyectar los gastos de mantenimiento del condominio.

Esto toma su tiempo por la forma de trabajo. Ya que existe una variedad de
propiedades: departamentos, parqueos y bauleras, y el costo de estos es variable.

1.3.1 Problema general.

Debido a que todo el flujo de efectivo (ingreso y egreso), que se genera
mensualmente, y estos son registrados de forma manual. Por una parte los ingresos
10
con las cuotas mensuales del mantenimiento de los departamentos, parqueos y
bauleras. Y los egresos debido al pago de servicios básicos y trabajos de
mantenimiento, refacción en las áreas compartidas del condominio.

Como estos registros son manuales existe demora en la elaboración de informes y

reportes ocasionado una deficiente gestión administrativa del condominio.

1.3.2 Problemas específicos.

Los problemas actuales por los que atraviesa el condominio “La Joya” en relación
al comportamiento y manejo del flujo de efectivo, son descritos a continuación.

 Vecinos que no cumplen los pagos de las cuotas mensuales, con la

excusa de que no cuentan con el monto detallado de la deuda.
 Demora para generar un reporte general de los deudores, sean
copropietarios o inquilinos.
 Registro manual de los comprobantes de pago y recibos de ingreso.
 Procesos manuales en los cálculos de cuotas mensuales:
1. La determinación del prorrateo de factura de agua en base
importe y total de personas del Condominio.
2. La determinación de cobro por mantenimiento figo de
Departamentos, parqueos, bauleras y alquileres de
propiedades comunes del mes o periodo en curso.
3. Calculo de deudas anteriores por concepto de prorrateo agua,
mantenimiento, alquiler de propiedades comunes e intereses,
si corresponde.
4. Calculo en orden descendente de deudores, para respectiva
notificación.
5. Estimación de gastos fijos y variables que deben realizarse en
base a los ingresos estimados.

11
 1.4 OBJETIVOS.
1.4.1 Objetivo general
Implementar un sistema de información, para un adecuado control y seguimiento
del flujo de efectivo y procesos relacionados en la administración de los recursos
económicos del Condominio “La Joya”.

1.4.2 Objetivos específicos.

 Analizar y evaluar la situación actual del Condominio.
 Clasificar la información recolectada.
 Definir los requerimientos del Directorio, Administrador,
Copropietarios e inquilinos, para el sistema de información.
 Analizar y diseñar, el sistema de información para mejorar los
procesos de flujo de efectivo en el Condominio. Usando técnicas de
ingeniería de software.
 Desarrollar la interfaz del nuevo sistema de información.
 Realizar pruebas al nuevo sistema de información.
 Implementar el sistema de información.

1.5 JUSTIFICACIONES.
El sistema de información, a desarrollar, permitirá mejorar el desempeño de los
usuarios a cargo con la posibilidad de obtener información oportuna e instantánea,
dicha información ayudará a un buen control en el proceso de flujo de efectivo del
Condominio “La Joya”.

1.5.1 Justificación Social.

Con el uso de los sistemas de información se logran importantes mejoras, pues se
automatizan los procesos operativos y suministran una plataforma de información
necesaria.

Con la implementación del “SISTEMA DE INFORMACIÓN PARA EL CONTROL Y

SEGUIMIENTO DE RECURSOS FINANCIEROS” para el condominio La Joya, el
directorio, personal administrativo, copropietarios e inquilinos. Tendrán mayor
facilidad para realizar sus actividades en lo que respecta a temas económicos. Así
mismo ayudara a controlar los ingresos, egresos y ver cantidad de deudores,
12
generando reportes de forma inmediata, colaborando de una manera efectiva y así
poder tomar mejores decisiones.

1.5.2 Justificación técnica.

A falta de un buen control en los procesos de ingreso y egreso, estos ocasionaron
pérdidas económicas al condominio, es por eso que se ve la necesidad de la
implementar un sistema de información.

El condominio “La Joya” por el momento cuenta con un equipo de computación,

para registrar las planillas de cobro. Que podría ser utilizada para la implementación
de forma local del sistema de información. Y así se tendría un ahorro en la compra
de otro, posteriormente se pretende implementar el sistema en un servidor externo
(hosting), que esté disponible desde cualquier lugar y en cualquier momento.

1.5.3 Justificación económica.

Por tratarse de la realización manual de los procesos de flujo de efectivo, estos
ocasionan perjuicios y pérdidas económicas al condominio.

Con la automatización de los procesos se pretende minimizar el esfuerzo laboral del

administrador reducir los errores, tiempo y material de escritorio. Para reducir costos
operativos en las gestiones administrativa del Condominio.

1.6 ALCANCES.
1.6.1 Alcance temporal.
De acuerdo al análisis previo se requiere de tiempos considerables especialmente
en las fases de: obtención de requerimientos, análisis y diseño, pruebas e
implementación debido a la complejidad y la cantidad de variables que existen. En
la administración del condominio.

Una vez implementado el sistema de información, este proveerá resultados exactos

y así facilitará para la toma de decisiones del directorio.

Para la conclusión del proyecto y la implementación del sistema de información

puesta en producción, se estima un tiempo de seis meses.

13
 1.6.2 Alcance temático.
Como se estudió, los procesos que traen problemas en la gestión de administración
son deudas y cobros retrasados. Para la implementación del sistema de información
se cubrirán los siguientes aspectos:

 Registro de usuarios y roles.

 Registro de copropietarios
 Registro de inquilinos
 Registro de propiedades.
 Registro de cuotas mensuales de mantenimiento propiedades.
 Registro pago de servicios básicos
 Registro pago de personal.
 Registro de pago de proyectos (impermeabilización azotea, pintado
general del inmueble).
 Registro de pago de manteniendo preventivo.
 Registro de gastos administrativos (pago de honorarios profesionales,
viáticos, material de escritorio).
 Registro de compras de insumos eléctricos, insumos de limpieza y
plomería.
 Registro de gastos Varios (servicios casuales).
 Calculo del prorrateo del agua.
 Calculo de la cuota mensual por mantenimiento de departamento,
parqueo y baulera
 Calculo de la cuota mensual por alquiler por áreas comunes.
 Calculo de deudas anteriores por parte de copropietarios e inquilinos,
incorporando el interés si corresponde para todas las propiedades.
 Resumen estimado de ingresos.
 Reporte de deudas de copropietarios en forma descendente (el que
tiene mayor deuda al principio).

14
 1.7 METODOLOGÍA.
En el presente proyecto y desarrollo de sistema se implementará la metodología
SCRUM.

SCRUM, es aplicable a proyectos con tiempo y recursos limitados. Algunas

consideraciones a tener en cuenta cuando se usa esta metodología son:

 La entrega del proyecto debe realizarse a tiempo, no sobrepasando

los costes estimados y entregando software de calidad.
 Solo es necesario que un paso del desarrollo esté lo suficientemente
completo como para poder pasar al siguiente, así la siguiente iteración
podrá ser comenzada sin retrasos.
 La metodología incluye técnicas de desarrollo y gestión de proyectos.
 Puede ser aplicado tanto a proyectos nuevos como a proyectos ya
existentes para su ampliación.
 La evaluación de riesgos se debe centrar en los entregables y no en
el proceso de desarrollo ni en la documentación o requisitos.
 Las estimaciones se deben realizar según las funcionalidades y no
según las líneas de código.

1.7.1 Herramientas a utilizar.

Las herramientas que utilizaremos para el desarrollo del proyecto y la
implementación del sistema son:

 SCRUM.
 Bizagi Modeler
 Edraw Max
 Herramientas para ingeniería de software asistida por computadora
(CASE). Power Designer, Navicat, Navicat Data Modeler.
 Standar HTML5
 Lenguaje de programación PHP5.
 Laravel framework desarrollado en PHP.

15
  Gestor de base de datos MySQL.

1.7.2 Técnicas para obtención de datos.

Las técnicas que se emplearán serán las siguientes:

 Técnica para la Recopilación de Datos

 Técnica de Costo-Beneficios
 Técnica de planificación y control de proyectos.

16
 Capítulo II

Marco Teórico
17
 CAPITULO 2.

2.1 Introducción.
El propósito de este capítulo es de fundamentar toda la teoría para el desarrollo
de software, un sistema de información computacional.

2.2 Propiedades Compartidas.

Los condominios forman parte de lo que el derecho civil conoce como comunidad
de bienes. Esta figura legal encuadra a aquellos casos en los que un patrimonio
es compartido por diversas personas jurídicas o físicas.

La noción de condominio suele aplicarse a los inmuebles de propiedad horizontal.

En estos casos, una persona es la propietaria de la unidad que compra (un
departamento o apartamento dentro de un edificio, por ejemplo) y co-propietaria
de los espacios comunes (pasillos, ascensores, etc.). Los gastos que se
producen en estos espacios comunes se reparten entre todos los copropietarios.
Para facilitar la administración, es frecuente que los copropietarios del
condominio contraten los servicios de alguien externo que se encargue de
liquidar los gastos.

En este caso, esa persona encargada de dichas tareas por los copropietarios es
la que se denomina administrador. Entre las principales funciones que tendrá que
acometer se encuentran el fomentar la buena convivencia de todos aquellos, el
informarles de todo cuanto acontece, el atenderles en todas las consultas o
aportaciones que le quieran realizar o el medir el grado de satisfacción que tienen
los citados con respecto a su trabajo y al propio condominio.

(Porto & Merino, 2012)

2.3 CONCEPTO DE PROYECTO.

El termino proyecto es de uso común casi en toda la sociedad, pero, puede tomar
significados diferentes y no siempre se emplea en el mismo sentido. La palabra
proviene del latín proiectus que a su vez deriva de proiicere, que significa dirigir algo
o una cosa hacia adelante.

18
 (Sapag Chain & Sapag Chain, 2008)

Según la definición que nos proporciona El Project Management Institute (PMI),

en su guía Project Management Body of Knowledge (PMBOOK), un proyecto se
podría definir como “un servicio temporal que se lleva a cabo para crear un producto,
servicio o resultado único”.
(Institute, 2013)

Podemos decir entonces que un proyecto tiene un inicio y un fin, este fin se tiene
que alcanzar dentro de un tiempo fijado.

2.4 Concepto de metodología.

Según Kaplan (1964, citado por José Touriñan 2006) El término metodología se
define como el conjunto de técnicas o procedimientos racionales, empleados para
alcanzar un objetivo, teóricamente valido.
(Touriñan López, 2008)
Definiremos la metodología como aquella disciplina que indicara que métodos y
técnicas hay que usar en cada fase del ciclo de vida de desarrollo del proyecto.

Los elementos que compone una metodología son:

 Las fases: en este punto se marcarán las diferentes actividades que

hay que realizar por cada fase.

 Los métodos: se tendrá que identificar el modo, en el que se

realizará el proceso de desarrollo del producto software.
Generalmente se suele descomponer los procesos en tareas más
pequeñas, en estas tareas se definen los valores que recibirá cada
fase, así como los que generará y la técnica que se tendrá que usar.

 Técnicas y herramientas: indicaran como se debería de resolver

cada tarea y que herramientas podríamos usar. Existe diferentes tipos
de técnicas algunas de ellas son:

 Recopilación de datos. Uso de entrevistas, formularios,

etc.

19
  Técnicas gráficas. Diagramas, organigramas,
diagrama de matrices, etc.

 Técnica de modelado. Desarrollo estructurado y

orientado a objetos.

 Documentación: es necesario indicar que documentación se va a

entregar durante todas las fases, esa documentación se debería de
realizar de una manera exhaustiva y completa usando todos los
valores de entrada y salida que van generando, esto servirá para
recoger los resultados y tomar decisiones de las diferentes
situaciones planteadas.

 Control y evaluación: el control y la evaluación también se debe de

realizar a lo largo de todo el ciclo de vida. Consistirá en comprobar y
aceptar y/o denegar rodos los resultados que se vayan obteniendo y
poder plantear, si es necesario, una nueva planificación de las tareas
asignadas, la meta será lograr el objetivo.

2.5 VENTAJAS DE USAR UNA METODOLOGÍA.

Mencionaremos algunas ventajas que aporta el uso de una metodología para crear
un producto.

 Al inicio del proyecto, facilita de gran manera la planificación.

 Gestión del proyecto, facilita el control y el seguimiento adecuado

del proyecto.

 Mejora el uso de recursos.

 La retroalimentación del proyecto, permite evaluar de forma más

fácil los resultados obtenidos y valorar los objetivos conseguidos.

 Comunicación de actores en el proyecto, mejora la comunicación

entre el cliente y las personas que llevan a cabo el proyecto

20
 2.6 METODOLOGÍA ÁGIL.
The Agile Alliance, es una organización, sin ánimo de lucro, dedicada a promover
los conceptos relacionados con el desarrollo ágil de software y fue creada en el
2001.

Durante el transcurso de los años 90 el ambiente cambiante y turbulento era cada

vez más dinámico. Por lo tanto, surgió la necesidad de desarrollar metodologías
livianas y maniobrables que pudieran operar en ese ambiente turbulento. Estas
metodologías son conocidas colectivamente hoy en día como “metodologías ágiles”.

Lo ágil se define (por los mismos agilistas) como la habilidad de responder de forma
versátil al cambio para maximizar los beneficios. Las metodologías ágiles varían en
su forma de responder al cambio, pero en general comparten las siguientes
características:

 Los individuos y sus interacciones son más importantes que los

procesos y las herramientas.

 El software que funciona es más importante que la documentación

exhaustiva.

 La colaboración con el cliente en lugar de la negociación de

contratos.

 La respuesta al cambio en lugar de aferrarse a un plan.

(Jeff Gothelf, 214)

2.7 METODOLOGIA SCRUM.

En el año 1986 Takeuchi y Nonaka publicaron el artículo “The New Product
Developroent Game” el cual dio a conocer una nueva forma de gestionar proyectos
en la que la agilidad, flexibilidad, y la incertidumbre son los elementos principales.

Nonaka y Takeuchi se fijaron en empresas tecnológicas que, estando en el mismo

entorno en el que se encontraban otras empresas, realizaban productos en menos
tiempo, de buena calidad y menos costes.

21
Observando a empresas como Honda, HP, Canon… etc., se dieron cuenta de que
el producto no seguía unas fases en las que había un equipo especializado en cada
una de ellas, si no que se partía de unos requisitos muy generales y el producto lo
realizaba un equipo multidisciplinar que trabajaba desde el comienzo del proyecto
hasta el final.

Se comparó esta forma de trabajo en equipo, con la colaboración que hacen los
jugadores de Rugby y la utilización de una formación denominada SCRUM.

Scrum aparece como una práctica destinada a los productos tecnológicos y será en
1993 cuando realmente Jeff Sutherland aplique un modelo de desarrollo de
Software en Ease/Corporation.

En 1996, Jeff Sutherland y Ken Schwaber presentaron las prácticas que se

usaban como proceso formal para el desarrollo de software y que pasarían a
incluirse en la lista de Agile Alliance.

Scrum es adecuado para aquellas empresas en las que el desarrollo de los

productos se realiza en entornos que se caracterizan por tener:

 Incertidumbre: Sobre esta variable se plantea el objetivo que se

quiere alcanzar sin proporcionar un plan detallado del producto.
Esto genera un reto y da una autonomía que sirve para generar una
“tensión” adecuada para la motivación de los equipos.

 Auto-organización: Los equipos son capaces de organizarse por

sí solos, no necesitan roles para la gestión, pero tienen que reunir
las siguientes características:

 Autonomía: Son los encargados de encontrar la

solución usando la es encuentren adecuada.

 Autosuperación: Las soluciones iniciales sufrirán

mejoras.

22
  Auto-enriquecimiento: Al ser equipos
multidisciplinares se ven enriquecidos de forma
mutua, aportando soluciones que puedan
complementarse.

 Control moderado: Se establecerá un control suficiente para

evitar descontroles. Se basa en crear un escenario de “autocontrol
entre iguales” para no impedir la creatividad y espontaneidad de
los miembros del equipo.

 Transmisión del conocimiento: Todo el mundo aprende de todo

el mundo. Las personas pasan de unos proyectos a otros y así
comparten sus conocimientos a lo largo de la organización.

Scrum al ser una metodología de desarrollo ágil tiene como base la idea de creación
de ciclos breves para el desarrollo, que comúnmente se llaman iteraciones y que
en Scrum se llamarán “Sprints”.

Para entender el ciclo de desarrollo de Scrum es necesario conocer las 5 fases,

que definen el ciclo de desarrollo ágil:

 Concepto: Se define de forma general las características del

producto y se asigna el equipo que se encargará de su desarrollo.

 Especulación: en esta fase se hacen disposiciones con la

información obtenida y se establecen los límites que marcarán el
desarrollo del producto, tales como costes y agendas.
Se construirá el producto a partir de las ideas principales y se
comprueban las partes realizadas y su impacto en el entorno.
Esta fase se repite en cada iteración y consiste, en rasgos
generales, en:
o Desarrollar y revisar los requisitos generales.
o Mantener la lista de las funcionalidades que se esperan.

23
 o Plan de entrega. Se establece las fechas de las
versiones, hitos e iteraciones. Medirá el esfuerzo
realizado en el proyecto.
 Exploración: Se incrementa el producto en el que se añaden las
funcionalidades de la fase de especulación.

 Revisión: El equipo revisa todo lo que se ha construido y se

contrasta con el objetivo deseado.

Concepto
Concepto

Cierre Especulación
Cierre Especulación

ITERACCIONES
ITERACCIONES

Revisión Exploración
Revisión Exploración

Figura 2-1: Ciclo de desarrollo ágil

Fuente: [Elaboración propia]
Cierre: Se entregará en la fecha acordada una versión del
producto deseado. Al tratarse de una versión, el cierre no indica
que se ha finalizado el proyecto, sino que seguirá habiendo
cambios, denominados “mantenimiento”, que hará que el
producto final se acerque al producto final deseado.

Ciclo de desarrollo ágil

Scrum gestiona estas iteraciones a través de reuniones diarias, uno de los

elementos fundamentales de esta metodología.

24
 Figura 2-2: Ciclo principal de Scrum
Fuente: [Kenneth S. Rubin 2013]

2.8 COMPONENTES SCRUM.

Para entender todo el proceso de desarrollo del Scrum, se describirá de forma
general las fases y los roles. Estas fases y roles se detallarán de forma más concisa
más adelante.

Scrum se puede dividir de forma general en 3 fases, que podemos entender como
reuniones. Las reuniones forman parte de los artefactos de esta metodología junto
con los roles y los elementos que lo forman.

2.8.1 Planificación del Backlog

Se definirá un documento en el que se reflejarán los requisitos del
sistema por prioridades.

En esta fase se definirá también la planificación del Sprint 0, en la que

se decidirá cuáles van a ser los objetivos y el trabajo que hay que realizar
para esa iteración.

Se obtendrá además en esta reunión un Sprint Backlog, que es la lista

de tareas y que es el objetivo más importante del Sprint.

25
 Figura 2-3: Planificación del Backlog
Fuente: [Kenneth S. Rubin 2013]

2.8.2 Seguimiento del Sprint

En esta fase se hacen reuniones diarias en las que las 3 preguntas
principales para evaluar el avance de las tareas serán:
o ¿Qué trabajo de se realizó desde el trabajo anterior?
o ¿Qué trabajo se hará hasta una nueva reunión?
o ¿inconvenientes que hayan surgido y qué hay que
solucionar para poder continuar?

26
 Figura 2-4: Seguimiento del Sprint
Fuente: [Kenneth S. Rubin 2013]

2.8.3 Revisión del Sprint

Cuando se finaliza el Sprint se realizará una revisión del incremento que
se ha generado. Se presentarán los resultados finales y una demo o
versión, esto ayudará a mejorar el feedback con el cliente.

Figura 2-5: Revisión del Sprint

Fuente: [Kenneth S. Rubin 2013]

2.9 ROLES SCRUM.

Los roles se dividen en 2 grupos: cerdos y gallinas, esto surge en el chiste sobre un
cerdo y una gallina y su intención de poner un restaurante.
 LOS CERDOS, Son las personas que están comprometidas con el proyecto y el
proceso de Scrum.

27
 a) Product Owner: Es la persona que toma las decisiones, y es la que
realmente conoce el negocio del cliente y su visión del producto. Se
encarga de escribir las ideas del cliente, las ordena por prioridad y las
coloca en el Product Backlog.
b) ScrumMaster: Es el encargado de comprobar que el modelo y la
metodología funciona. Eliminará todos los inconvenientes que hagan
que el proceso no fluya e interactuará con el cliente y con los gestores.
c) Equipo De Desarrollo: suele ser un equipo pequeño de unas 5-9
personas y tienen autoridad para organizar y tomar decisiones para
conseguir su objetivo. Está involucrado en la estimación del esfuerzo
de las tareas del Backlog.

Figura 2-6: Roles Scrum

Fuente: [Kenneth S. Rubin 2013]

 LAS GALLINAS, Aunque no son parte del proceso de Scrum, es necesario

que parte de la retroalimentación dé la salida del proceso y así poder revisar
y planear cada sprint.
a. Usuarios: Es el destinatario final del producto.

28
 b. Stakeholders: Las personas a las que el proyecto les producirá un
beneficio. Participan durante las revisiones del Sprint.
c. Managers: Toma las decisiones finales participando en la selección
de los objetivos y de los requisitos.
2.10 ELEMENTOS SCRUM.
Los elementos que forman a Scrum son:

o Product Backlog: lista de necesidades del cliente.

o Sprint Backlog: lista de tareas que se realizan en un
Sprint.
o Incremento: parte añadida o desarrollada en un Sprint, es
una parte terminada y totalmente operativa.

Figura 2-7: Elemntos Scrum

Fuente: [www. platzi.com/blog/guia-scrum/]

 Product Backlog. Es el inventario en el que se almacenan todas

las funcionalidades o requisitos en forma de lista priorizada. Estos
requisitos serán los que tendrá el producto o los que irá
adquiriendo en sucesivas iteraciones.
La lista será gestionada y creada por el cliente con la ayuda del
Scrum Master, quien indicará el coste estimado para completar

29
un requisito, y además contendrá todo lo que aporte un valor final
al producto.
Las tres características principales de esta lista de objetivos
serán:
o Contendrá los objetivos del producto, se suele usar para
expresarlos las historias de usuario.
o En cada objetivo, se indicará el valor que le da el cliente y
el coste estimado; de esta manera, se realiza la lista,
priorizando por valor y coste, se basará en el ROI.
o En la lista se tendrán que indicar las posibles iteraciones
y los releases que se han indicado al cliente.
o La lista ha de incluir los posibles riesgos e incluir las
tareas necesarias para solventarlos.
Es necesario que antes de empezar el primer Sprint se definan
cuáles van a ser los objetivos del producto y tener la lista de los
requisitos ya definida. No es necesario que sea muy detallada,
simplemente deberá contener los requisitos principales para que
el equipo pueda trabajar. Realizar este orden de tareas tiene como
beneficios:
o El proyecto no se paraliza simplemente por no tener claro
los requisitos menos relevantes, y el cliente podrá ver
resultados de forma más rápida.
o Los requisitos secundarios aparecerán a medida que se
va desarrollando el proyecto, por lo tanto, no se pierde
tanto tiempo en analizarlos al principio y el cliente será
más consciente de sus necesidades.
o Los requisitos secundarios puede que no se lleguen a
necesitar porque se han sustituido o porque no reportan
un retorno ROI interesante.
Una vez definidos los requisitos se tendrá que acordar cuándo se
tiene que entender un objetivo como terminado o completado.

30
 Se entiende que un producto está completado si:
o Asegura que se puede realizar un entregable para realizar
una demostración de los requisitos y ver qué se han
cumplido.
o Incluirá todo lo necesario para indicar que se está
realizando el producto que el cliente desea.
Como complemento a la definición de completado, se debería de
asociar una condición de aceptación o no aceptación a cada
objetivo en el mismo momento en el que se crea la lista.
Finalmente, el Product Backlog irá evolucionando mientras el
producto exista en el mercado. Esta es la forma para evolucionar
y tener un valor de producto para el cliente suficiente para ser
competitivo.
o Las historias de Usuario. Son las descripciones de las
funcionalidades que va a tener el software.
Estas historias de usuario, serán el resultado de la
colaboración entre el cliente y el equipo, e irán
evolucionando durante toda la vida del proyecto.
Las historias de usuario se componen de tres fases
denominadas “Las 3 C”:
Card: Será una breve descripción escrita que servirá
como recordatorio.
Conversation: Es una conversación que servirá para
asegurarse de que se ha entendido bien todo, y concretar
el objetivo.
Confirmation: Tests funcionales para fijar detalles que
sean relevantes e indicar cuál va a ser el límite.
En cuanto al formato, un modelo podría ser como el que se muestra en la siguiente
imagen:

31
 Figura 2-8: Historia de usuario
Fuente: [www.agile-spain.com]

PRIORIDAD: Prioridad en la implementación de la historia de usuario

respecto al resto de las historias de usuario. A mayor número, mayor
prioridad. Otra aproximación a la priorización de tareas se hace a través del
método MoSCoW:
M – Must, se debe completar este requerimiento para finalizar el
proyecto.
S – Should, se debe completar este proyecto por todos los medios,
pero el éxito del proyecto no depende de él.
C – Could, se debería completar este requerimiento si su
implementación no afecta a la consecución de los objetivos
principales del proyecto.
W – Would, se puede completar este requerimiento si sobra tiempo
de desarrollo (o en futuras versiones del mismo)

32
Las historias de usuario se suelen expresar mediante la fórmula:
“Yo como…
Quiero…
Qué/para que… “
Por ejemplo:
Yo como usuario quiero que la aplicación tenga una opción exportar que me
permita obtener los informes en csv.
La cláusula yo como representa quién necesita la historia o a quién aporta
valor, quiero describe la funcionalidad deseada y que/para que describe por
qué se quiere la funcionalidad o el valor aportado.
Cabría pensar que el yo siempre representará al usuario final de la aplicación
pero puede ser cualquier tipo de rol:
Yo como cliente quiero que los usuarios puedan acceder fácilmente a las
web de otros productos míos para que se potencien las ventas cruzadas.

Yo como desarrollador quiero que se despliegue un entorno web hotfix para

que se puedan hacer correcciones rápidas sin que afecte a los usuarios
finales.

Los criterios de aceptación: Están compuestos por la descripción del

contexto, evento y consecuencia, definen los requerimientos del dueño de
producto sobre cómo deben comportarse el sistema para ejecutar la acción.
Representan el inicio de la definición del cómo. No están diseñados para ser
tan detallados como una especificación de diseño tradicional.
Si una historia de usuario tiene más de 4 criterios de aceptación, debe
evaluarse subdividir la historia.
Puede añadirse un número de escenario para identificar al criterio, asociado
a la historia de usuario en cuestión.
DEPENDENCIAS: Una historia de usuario no debería ser dependiente de
otra historia, pero a veces es inevitable. En este apartado se indicarían los
IDs de las tareas de las que depende una tarea.

33
 o Formato de la Pila Del Producto (Product Backlog). En
Scrum, la preferencia por tener documentación en todo
momento es menos estricta. Se encuentra más necesario
el mantener una comunicación directa con el equipo, por
eso se usa como herramienta el Backlog.
Aunque no hay ningún producto especial a la hora de confeccionar
la lista, es conveniente que incluya información relativa a:
- Identificador para la funcionalidad.
- Descripción de la funcionalidad.
- Sistema de priorización u orden.
- Estimación.
 Sprint Backlog. Es la lista de tareas que elabora el equipo
durante la planificación de un Sprint. Se asignan las tareas a cada
persona y el tiempo que queda para terminarlas.
De esta manera el proyecto se descompone en unidades más
pequeñas y se puede determinar o ver en qué tareas no se está
avanzando e intentar eliminar el problema.
Cómo funciona la lista:
- Es una lista ordenada por prioridades para el cliente.
- Puede haber dependencias entre una tarea y otra, por
tanto, se tendrá que diferenciar de alguna manera.
- Todas las tareas tienen que tener un coste semejante que
será entre 4-16 horas.
Formato de la lista:
- Hojas de cálculo.
- Pizarras.
- Herramientas colaborativas.

 Incremento. Representa los requisitos que se han completado en

una iteración y que son perfectamente operativos.

34
 Según los resultados que se obtengan, el cliente puede ir
haciendo los cambios necesarios y replanteando el proyecto.

2.11 PREPARACIÓN DEL PROYECTO.

Conocida como Sprint 0, es la fase inicial en la que se intenta comprender el caso
de negocio con la finalidad de tomar decisiones que agreguen valor al producto.

Durante esta fase se producen gran número de inexactitudes con las estimaciones,
pero es lógico, debido a que se hacen a alto nivel, por lo tanto es aconsejable no
perder tiempo en buscar las estimaciones exactas, es mejor invertir ese tiempo en
el desarrollo del producto. De esta manera el Backlog del producto usará como
unidad de tiempo “días”.

Las tareas a realizar en el sprint 0 son:

a. Definir el proyecto: Se debería de indicar de forma clara el propósito

del proyecto, no es necesario entrar en detalle pero sí que todo el
equipo sea capaz de entender cuáles son las necesidades del
producto y del cliente.

b. Definir “terminado”: Marcará el punto en el que se va a considerar que

la tarea está terminada.

c. Definición del Backlog inicial: Se comienza la creación del Backlog del

producto para que el Sprint siguiente contenga elementos de la lista
suficientes para comenzar a trabajar. Esta lista de elementos será
marcada por el Product Owner, que tendrá como responsabilidad
priorizar las funcionalidades que, al desarrollarlas e implementarlas
cumplan las especificaciones consiguiendo además que su beneficio
supere a su coste.

d. Definición de los entregables: Una vez que se tiene el Backlog con las
funcionalidades, es necesario establecer criterios para hacer
pequeñas entregas “entregables” del producto y así obtener su valor
y un feedback temprano.
35
 2.12 PLANIFICAR UN SPRINT.
Denominado también “Sprint Planning Meeting”, tiene como finalidad realizar una
reunión, en la que participarán el Product Owner, el Scrum Master y el equipo, con
la intención de seleccionar de la lista Backlog del producto las funcionalidades sobre
las que se va a trabajar, y que darán valor al producto.

Antes de comenzar la reunión el Product Owner tendrá que preparar el Backlog.

La reunión se realiza en con time-box de ocho horas que se divide en 2 partes de 4

horas.

a. Primera parte de la reunión:

1. El equipo selecciona los items para transformarlos en

entregables.

2. El equipo hace sugerencias, pero es el Product Owner

el que decidirá si formarán parte del Sprint.

3. El equipo seleccionará el elemento a implementar, de los

seleccionados por el Product Owner para ese Sprint

b. Segunda parte de la reunión:

1. El equipo hará las preguntas necesarias que tengan sobre

el Product Baklog al Product Owner

2. El equipo se encargará de encontrar la solución adecuada

para transformar la parte seleccionada de una funcionalidad
entregable.

2.13 DESARROOLLO SPRINT.

En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas

(iteraciones de un mes natural y hasta de dos semanas). Cada iteración tiene que
proporcionar un resultado completo, un incremento de producto que sea

36
potencialmente entregable, de manera que cuando el cliente (Product Owner) lo
solicite sólo sea necesario un esfuerzo mínimo para que el producto esté disponible
para ser utilizado. Para ello, durante la iteración el equipo colabora estrechamente
y se llevan a cabo las siguientes dinámicas:

 Cada día el equipo realiza una reunión de sincronización, donde cada

miembro inspecciona el trabajo de los otros para poder hacer las
adaptaciones necesarias, comunica cuales son los impedimentos con que se
encuentra, actualiza el estado de la lista de tareas de la iteración (Sprint
Backlog) y los gráficos de trabajo pendiente (Burndown charts).
 El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con
su compromiso y de que no se merme su productividad.
o Elimina los obstáculos que el equipo no puede resolver por sí mismo.
o Protege al equipo de interrupciones externas que puedan afectar su
compromiso o su productividad. (Rubin, 2012)

2.14 TECNOLOGIAS DE DESARROLLO WEB.

2.14.1 Mvc.
El Modelo-Vista-Controlador o mejor conocido como MVC, por sus siglas en inglés,
Model View Controller, es más que un patrón de diseño, un patrón de arquitectura
de aplicaciones. Se refiere a un flujo de trabajo dentro de una aplicación y, aunque
no es el único, es uno de los cuales ha adquirido mayor popularidad desde hace
años. Es un patrón utilizado en diversos ámbitos de "software" y las aplicaciones
web no son la excepción. Más específicamente en el ámbito de desarrollo web con
PHP, el patrón sigue el siguiente flujo de trabajo. Hay un punto de entrada a la
aplicación, en muchos casos es un'index. php' y de ahí sigue las rutas hacia los
controladores. El controlador es –digamos– el gerente y obtiene datos del modelo.
Pregunta si algo se adecúa a las normas del negocio establecidas y, finalmente,
cuando el controlador ya obtuvo los datos, se los presenta al usuario mediante una
vista visualizada en el navegador. Al mencionar el modelo, nos referimos a una capa
que engloba la parte de datos y negocios de una aplicación. Aquí se construye un
puente entre alguna fuente datos externa a la aplicación y nuestra aplicación. Estas

37
fuentes externas podrían ser API, bases de datos o alguna otra fuente.
Generalmente, más no invariablemente, se lidia con bases de datos como MySQL,
PostgreSQL, etc. Esta capa también se encarga de imponer las reglas de negocio
establecidas. Es decir, si nosotros establecemos que, por ejemplo, un usuario debe
tener un correo único, podemos ya sea dejar que la base de datos imponga esta
regla o nosotros, de manera programática, podemos verificar que se está llevando
a cabo esta regla. En cualquiera de los casos, estas reglas se imponen mediante el
modelo y no en ningún otro lado. La vista es la capa que se le presenta al mundo
exterior de la aplicación. Al ser una aplicación web, se tiene que hablar en el dialecto
web y, por ende, ser comprendido por un navegador web. Por ello, el lenguaje tiene
que ser HTML, JSON, XML o algún otro lenguaje que comprenda el navegador.
Puede ser hasta formatos como, por ejemplo, imágenes, PDF, etc. La vista tiene
que tener lo menos posible de lógica, es decir, es simplemente una plantilla con la
que se muestra uno u otro dato. Y finalmente está el controlador, el cual coordina
entre la vista y el modelo. Es el director de la orquesta gestionando a todos, no le
importa de dónde vienen los datos, si de una API o una base de datos, sino más
bien dirige esos datos hacia la vista. También decide qué vista es la que se debe
mostrar.
(cakephp, s.f.)

2.14.2 Framework Laravel.

Laravel es un framework de código abierto para desarrollar aplicaciones y servicios
web con PHP 5 y PHP 7. Su filosofía es desarrollar código PHP de forma elegante
y simple, evitando el "código espagueti". Fue creado en 2011 y tiene una gran
influencia de frameworks como Ruby on Rails, Sinatra y ASP.NET MVC.

Laravel tiene como objetivo ser un framework que permita el uso de una sintaxis
elegante y expresiva para crear código de forma sencilla y permitiendo multitud de
funcionalidades. Intenta aprovechar lo mejor de otros frameworks y aprovechar las
características de las últimas versiones de PHP.

38
Laravel propone en el desarrollo usar 'Routes with Closures', en lugar de un MVC
tradicional con el objetivo de hacer el código más claro. Aun así permite el uso de
MVC tradicional

Modelo
Laravel incluye un sistema de mapeo de datos relacional llamado Eloquent ORM
que facilita la creación de modelos. Este ORM se funda en patrón active record y su
funcionamiento es muy sencillo. Es opcional el uso de Eloquent, pues también
dispone de otros recursos que nos facilitan interactuar con los datos, o
específicamente la creación de modelos.

Vista
Laravel incluye de paquete un sistema de procesamiento de plantillas llamado
Blade. Este sistema de plantillas favorece un código mucho más limpio en las Vistas,
además de incluir un sistema de Caché que lo hace mucho más rápido. El sistema
Blade de Laravel, permite una sintaxis mucho más reducida en su escritura. Por
ejemplo, en vez pintar la vista usando el código PHP

Controlador
Los controladores contienen la lógica de la aplicación y permiten organizar el código
en clases sin tener que escribirlo todo en las rutas. Todos los controladores deben
extenderse de la clase BaseController.
Gran parte de Laravel está formado por dependencias, especialmente de Symfony,
esto implica que el desarrollo de Laravel dependa también del desarrollo de sus
dependencias.
(laraveles.com, 2017)
2.14.3 Estándar Html5
Html5
Es un lenguaje markup (de hecho, las siglas de HTML significan Hyper Text Markup
Language) usado para estructurar y presentar el contenido para la web. Es uno de
39
los aspectos fundamentales para el funcionamiento de los sitios, pero no es el
primero. Es de hecho la quinta revisión del estándar que fue creado en 1990. La
W3C la recomendó para transformarse en el estándar a ser usado en el desarrollo
de proyectos venideros. Por así decirlo, qué es HTML5 está relacionado también
con la entrada en decadencia del viejo estándar HTML 4, que se combinaba con
otros lenguajes para producir los sitios que podemos ver hoy en día. Con HTML5,
tenemos otras posibilidades para explotar usando menos recursos. Con HTML5,
también entra en desuso el formato XHTML, dado que ya no sería necesaria su
implementación.
HTML5. Se trata de un sistema para formatear el layout de nuestras páginas, así
como hacer algunos ajustes a su aspecto. Con HTML5, los navegadores como
Firefox, Chrome, Explorer, Safari y más pueden saber cómo mostrar una
determinada página web, saber dónde están los elementos, dónde poner las
imágenes, dónde ubicar el texto. En este sentido, el HTML5 no se diferencia
demasiado de su predecesor, un lenguaje del cual hablamos hace algunos meses
en nuestra guía básica de HTML. La diferencia principal, sin embargo, es el nivel de
sofisticación del código que podremos construir usando HTML5.

Css3
Mientras que HTML nos permite definir la estructura una página web, las hojas de
estilo en cascada (Cascading Style Sheets o CSS) son las que nos ofrecen la
posibilidad de definir las reglas y estilos de representación en diferentes
dispositivos, ya sean pantallas de equipos de escritorio, portátiles, móviles,
impresoras u otros dispositivos capaces de mostrar contenidos web.
Las hojas de estilo nos permiten definir de manera eficiente la representación de
nuestras páginas y es uno de los conocimientos fundamentales que todo diseñador
web debe manejar a la perfección para realizar su trabajo.
La primera versión de CSS fue publicada a fines del año 1996 y fue logrando
popularidad y aceptación hasta llegar a la versión 2.1, estándar actual que ofrece
gran compatibilidad con la mayoría de los navegadores del mercado.
A partir del año 2005 se comenzó a definir el sucesor de esta versión, al cual se lo
conoce como CSS3 o Cascading Style Sheets Level 3. Actualmente en definición,

40
esta versión nos ofrece una gran variedad de opciones muy importantes para las
necesidades del diseño web actual. Desde opciones de sombreado y redondeado,
hasta funciones avanzadas de movimiento y transformación, CSS3 es el estándar
que dominará la web por los siguientes años.
Javascript
Es un lenguaje con muchas posibilidades, utilizado para crear pequeños programas
que luego son insertados en una página web y en programas más grandes,
orientados a objetos mucho más complejos. Con Javascript podemos crear
diferentes efectos e interactuar con nuestros usuarios.
Este lenguaje posee varias características, entre ellas podemos mencionar que es
un lenguaje basado en acciones que posee menos restricciones. Además, es un
lenguaje que utiliza Windows y sistemas X-Windows, gran parte de la programación
en este lenguaje está centrada en describir objetos, escribir funciones que
respondan a movimientos del mouse, aperturas, utilización de teclas, cargas de
páginas entre otros.
Es necesario resaltar que hay dos tipos de JavaScript: por un lado está el que se
ejecuta en el cliente, este es el Javascript propiamente dicho, aunque técnicamente
se denomina Navigator JavaScript. Pero también existe un Javascript que se ejecuta
en el servidor, es más reciente y se denomina LiveWire Javascript.
2.14.4 Calidad del software
NORMA DE EVALUACIÓN ISO/IEC 9126
Esta norma Internacional fue publicada en 1992, la cual es usada para la evaluación
de la calidad de software, llamado “Information technology-Software product
evaluation-Quality characteristics and guidelines for their use”; o también conocido
como ISO 9126 (o ISO/IEC 9126). Este estándar describe 6 características
generales: Funcionalidad, Confiabilidad, Usabilidad, Eficiencia, Mantenibilidad, y
Portabilidad.
La norma ISO/IEC 9126 permite especificar y evaluar la calidad del software desde
diferentes criterios asociados con adquisición, requerimientos, desarrollo, uso,
evaluación, soporte, mantenimiento, aseguramiento de la calidad y auditoria de
software. Los modelos de calidad para el software se describen así:

41
Calidad interna y externa: Especifica 6 características para calidad interna y externa,
las cuales, están subdivididas. Estas divisiones se manifiestan externamente
cuando el software es usado como parte de un sistema Informático, y son el
resultado de atributos internos de software.

Calidad en uso: Calidad en uso es el efecto combinado para el usuario final de las
6 características de la calidad interna y externa del software. Especifica 4
características para la calidad en uso.

Al unir la calidad interna y externa con la calidad en uso se define un modelo de

evaluación más completo, se puede pensar que la usabilidad del modelo de calidad
externa e interna pueda ser igual al modelo de calidad en uso, pero no, la usabilidad
es la forma como los profesionales interpretan o asimilan la funcionabilidad del
software y la calidad en uso se puede asumir como la forma que lo asimila o maneja
el usuario final. Si se unen los dos modelos, se puede definir que los seis indicadores
del primer modelo tienen sus atributos y el modelo de calidad en uso sus 4
indicadores pasarían hacer sus atributos, mirándolo gráficamente quedaría así:

Figura 2-9: Norma de Evaluación ISO/IEC 9126

Fuente: [González et al., 2002]

Se establecen categorías para las cualidades de la calidad externa e interna y

calidad en uso del software, teniendo en cuenta estos 7 indicadores (funcionalidad,
confiabilidad, utilidad, eficiencia, capacidad de mantenimiento, portabilidad y calidad

42
en uso), que se subdividen a su vez en varios indicadores; estas se pueden medir
por métrica interna o externa.
(iso.org, iso.org, 2017)

Figura 2-10: Evaluación Interna, externa y Calidad de Uso ISO/IEC 9126

Fuente: [González et al., 2002]

Las definiciones se dan para cada característica y subcaracterística de calidad del

software que influye en la calidad. Para cada característica y subcaracterística, la
capacidad del software es determinada por un conjunto de atributos internos que
pueden ser medidos. Las características y subcaracterísticas se pueden medir
externamente por la capacidad del sistema que contiene el software.
(iso.org, iso.org, 2017)
FUNCIONALIDAD
Funcionalidad es la capacidad del software de cumplir y proveer las funciones para
satisfacer las necesidades explícitas e implícitas cuando es utilizado en condiciones
específicas. A continuación se muestra la característica de Funcionalidad y las
subcaracterísticas que cubre.

43
 Figura 2-11: Característica de funcionalidad
Fuente: [González et al., 2002]

La funcionalidad se divide en 5 criterios:

Adecuación: La capacidad del software para proveer un adecuado conjunto de

funciones que cumplan las tareas y objetivos especificados por el usuario.

Exactitud: La capacidad del software para hacer procesos y entregar los resultados
solicitados con precisión o de forma esperada.

Interoperabilidad: La capacidad del software de interactuar con uno o más

sistemas específicos.

Seguridad: La capacidad del software para proteger la información y los datos de

manera que los usuarios o los sistemas no autorizados no puedan acceder a ellos
para realizar operaciones, y la capacidad de aceptar el acceso a los datos de los
usuarios o sistemas autorizados

Conformidad de la funcionalidad: La capacidad del software de cumplir los

estándares referentes a la funcionalidad.

CONFIABILIDAD
La confiabilidad es la capacidad del software para asegurar un nivel de
funcionamiento adecuado cuando es utilizando en condiciones específicas. En este

44
caso la confiabilidad se amplía sostener un nivel especificado de funcionamiento y
no una función requerida.

Figura 2-12: Característica de Confiabilidad

Fuente: [González et al., 2002]
La confiabilidad se divide en 4 criterios:

Madurez: La capacidad que tiene el software para evitar fallas cuando encuentra
errores. Ejemplo, la forma como el software advierte al usuario cuando realiza
operaciones en la unidad de CD vacía, o cuando no encuentra espacio suficiente el
disco duro donde esta almacenando los datos.

Tolerancia a errores: La capacidad que tiene el software para mantener un nivel

de funcionamiento en caso de errores.

Recuperabilidad: La capacidad que tiene el software para restablecer su

funcionamiento adecuado y recuperar los datos afectados en el caso de una falla.

Conformidad de la fiabilidad: La capacidad del software de cumplir a los

estándares o normas relacionadas a la fiabilidad.

USABILIDAD
La usabilidad es la capacidad del software de ser entendido, aprendido, y usado en
forma fácil y atractiva. Algunos criterios de funcionalidad, fiabilidad y eficiencia
afectan la usabilidad, pero para los propósitos de la ISO/IEC 9126 ellos no clasifican
como usabilidad. La usabilidad está determinada por los usuarios finales y los
usuarios indirectos del software, dirigidos a todos los ambientes, a la preparación
del uso y el resultado obtenido.

45
 Figura 2-13: Característica de Usabilidad
Fuente: [González et al., 2002]
La usabilidad se divide en 5 criterios:

Entendimiento: La capacidad que tiene el software para permitir al usuario

entender si es adecuado, y de una manera fácil como ser utilizado para las tareas y
las condiciones particulares de la aplicación. En este criterio se debe tener en
cuenta la documentación y de las ayudas que el software entrega.

Aprendizaje: La forma como el software permite al usuario aprender su uso.

También es importante considerar la documentación.

Operabilidad: La manera como el software permite al usuario operarlo y controlarlo.

Atracción: La presentación del software debe ser atractiva al usuario. Esto se

refiere a las cualidades del software para hacer más agradable al usuario, ejemplo,
el diseño gráfico.

Conformidad de uso: La capacidad del software de cumplir los estándares o

normas relacionadas a su usabilidad.

EFICIENCIA

La eficiencia del software es la forma del desempeño adecuado, de acuerdo a al

número recursos utilizados según las condiciones planteadas. Se debe tener en
cuenta otros aspectos como la configuración de hardware, el sistema operativo,
entre otros.

46
 Figura 2-14: Característica de Eficiencia
Fuente: [González et al., 2002]
La eficiencia se divide en 3 criterios:

Comportamiento de tiempos: Los tiempos adecuados de respuesta y

procesamiento, el rendimiento cuando realiza su función en condiciones
específicas. Ejemplo, ejecutar el procedimiento más complejo del software y esperar
su tiempo de respuesta, realizar la misma función pero con más cantidad de
registros.

Utilización de recursos: La capacidad del software para utilizar cantidades y tipos

adecuados de recursos cuando este funciona bajo requerimientos o condiciones
establecidas. Ejemplo, los recursos humanos, el hardware, dispositivos externos.

Conformidad de eficiencia: La capacidad que tiene el software para cumplir con

los estándares o convenciones relacionados a la eficiencia.

CAPACIDAD DE MANTENIMIENTO
La capacidad de mantenimiento es la cualidad que tiene el software para ser
modificado. Incluyendo correcciones o mejoras del software, a cambios en el
entorno, y especificaciones de requerimientos funcionales.

47
 Figura 2-15: Característica de Mantenimiento
Fuente: [González et al., 2002]

El mantenimiento se divide en 5 criterios:

Capacidad de ser analizado: La forma como el software permite diagnósticos de

deficiencias o causas de fallas, o la identificación de partes modificadas.

Cambiabilidad: La capacidad del software para que la implementación de una

modificación se pueda realizar, incluye también codificación, diseño y
documentación de cambios.

Estabilidad: La forma como el software evita efectos inesperados para

modificaciones del mismo.

Facilidad de prueba: La forma como el software permite realizar pruebas a las

modificaciones sin poner el riesgo los datos.

Conformidad de facilidad de mantenimiento: La capacidad que tiene el software

para cumplir con los estándares de facilidad de mantenimiento.

PORTABILIDAD
La capacidad que tiene el software para ser trasladado de un entorno a otro.

48
 Figura 2-16: Característica de portabilidad
Fuente: [González et al., 2002]

La usabilidad se divide en 5 criterios:

Adaptabilidad: Es como el software se adapta a diferentes entornos especificados

(hardware o sistemas operativos) sin que implique reacciones negativas ante el
cambio. Incluye la escalabilidad de capacidad interna (Ejemplo: Campos en
pantalla, tablas, volúmenes de transacciones, formatos de reporte, etc.).

Facilidad de instalación: La facilidad del software para ser instalado en un entorno

específico o por el usuario final.

Coexistencia: La capacidad que tiene el software para coexistir con otro o varios
software, la forma de compartir recursos comunes con otro software o dispositivo.

Reemplazabilidad: La capacidad que tiene el software para ser remplazado por

otro software del mismo tipo, y para el mismo objetivo. Ejemplo, la remplazabilidad
de una nueva versión es importante para el usuario, la propiedad de poder migrar
los datos a otro software de diferente proveedor.

Conformidad de portabilidad: La capacidad que tiene el software para cumplir con

los estándares relacionados a la portabilidad.

49
 Capítulo III

Marco Aplicativo

50
 CAPITULO 3.
3.1 INTRODUCCIÓN.
En este capítulo se desarrolla el proyecto de forma práctica y detallada, apoyado y
guiado en los conceptos de la metodología ágil Scrum.

Es una metodología clara y concisa, pero que exige de un gran esfuerzo y trabajo
duro si se quiere lograr un producto de calidad.

Cabe mencionar que Scrum, es un marco de trabajo adaptativo a las necesidades

durante el proceso de desarrollo del proyecto.

Se utiliza un proceso ágil iterativo e incremental que respeta las cinco etapas
tradicionales de un proyecto que facilitan su gestión y control; ellas son:
planificación, análisis, diseño, construcción y prueba, e implementación. Cómo el
objetivo final de la metodología es llegar al éxito del proyecto se definen, en forma
clara, los entregables de cada etapa y el alcance global, reflejando estos puntos en
la planificación de todas las tareas involucradas.

Figura 3-1: Fases de Scrum para el desarrollo de software

Fuente: [www.scrummanager.net/bok/index.php?title=Modelo_original_de_Scrum_para_desarrollo]
Este tipo de proceso de desarrollo permite hacer entregas parciales que se van
complementando según avanza el proyecto. De esta manera se reducen los riesgos
y a la vez el cliente va experimentando los resultados de su proyecto.

51
 3.2 PREGAME PLANIFICACIÓN.
En la metodología Scrum la fase inicial es la más importante, en esta fase inicial
denominada Pregame es construir el Product-Baclog.

En esta fase se aplica la ingeniería de requerimientos, la cual se encarga de la

realización de actividades en el intento de entender las necesidades de los usuarios
de un sistema.

3.2.1 Elaboración del Product-Backlog.

En esta fase con la ayuda del Product Owner (Cliente), definiremos el Product-
Backlog, en el cual se detallan todos los requerimientos del producto final.

Esta información se recopilo en reuniones realizadas con el personal administrativo

del condominio Presidente, Vicepresidente, Administrador e inquilinos. En la Tabla
1, se describen los requerimientos básicos del proyecto, a partir de los mismos,
se realizara un análisis y se construirá la lista de requerimientos funcionales,
que viene a ser el Product-Backlog del proyecto así como también la lista de
requerimientos no funcionales.

Tabla 3-1: Requerimientos básicos del proyecto.

REQUERIMIENTOS DEL CLIENTE
Nro. Descripción
1. Gestión de usuarios.
2. Gestión de copropietarios e inquilinos.
3. Gestión de propiedades.
4. Registro de ingresos.
5. Registro de egresos.
6. Calculo de la cuota mensual de mantenimiento.
7. Calculo de la cuota mensual por alquiler de áreas comunes.
8. Calculo de deudas anteriores por parte de copropietarios e inquilinos,
adicionado el interés del 3%, si corresponde.
9. Resumen estimado de ingresos.
10. Reporte de deudas de copropietarios e inquilinos, en forma descendente.
Fuente: [Condominio “La Joya”]

52
A partir de la tabla de requerimientos básicos descrita en la Tabla 3.1, se realizó el
análisis correspondiente en coordinación con el personal administrativo del
condominio, se construyó el Product-Backlog como se observa en la Tabla 3.2

Tabla 3-2: Pila de Requerimientos

PRODUCT-BACKLOG
ID DESCRIPCION PRIORIDAD
R1 Gestión de usuarios. Alta
R2 Gestión de copropietarios. Alta
R3 Gestión de inquilinos. Alta
R4 Gestión de propiedades. Alta
R5 Registro de ingresos de efectivo Alta
R6 Registro de egresos de efectivo Alta
R7 Calculo del prorrateo del agua. Media
R8 Calculo de la cuota mensual de mantenimiento de propiedades. Media
R9 Calculo de la cuota mensual por alquiler de áreas comunes. Media
R10 Calculo de deudas anteriores por parte de copropietarios e inquilinos. Baja
Adicionando el interés del 3%, si corresponde.
R11 Resumen estimado de ingresos. Baja
R12 Reporte de deudas de copropietarios e inquilinos, en forma descendente. Baja
Fuente: [Elaboración propia]

En el Product-Backlog se describen la lista de requerimientos para el inicio de

desarrollo del sistema

3.3.1.1 Especificación.
En esta fase se define la arquitectura de la plataforma, la cual está basada
en la arquitectura MVC, donde iremos independizando las clases del sistema a
desarrollar, el controlador se encargara de unificar o unir las relaciones entre las
vistas y el modelo, en las vistas, es donde el usuario interactuara con el sistema,
realizando las peticiones, al controlador y este a su vez verificara si son admitidas
o rechazadas, en el caso de ser aceptadas, se pedirá toda la información al modelo
para que pueda ser procesada, así mismo se encarga de almacenar y gestionar la
lógica del negocio.

Para el BackEnd se utilizara el sistema de gestión de bases de datos MySql, así

mismo el sistema de información o aplicativo web será desarrollado con el
framework de Laravel; Para la conexión entre el aplicativo web y la base de datos
se utiliza el controlador de Laravel, que ya viene configurado por defecto para este
gestor de base de datos.

53
En cuanto a Front-end, las peticiones para el despliegue de la aplicación web son
desarrolladas utilizando el estándar htm5 el cual contempla las siguientes
tecnologías: html5, Css3 y Javascript. Sin dejar de lado y mencionar algunos
componentes de Query y Bootstrap, de esa manera la aplicación se ejecutara del
lado del cliente, es decir en sus navegadores, mientras se mantiene una
comunicación asíncrona con el servidor en segundo plano, como se observa en la
Figura 3.2.

Figura 3-2: Arquitectura MVC

Fuente: [www. ajaxcolombia.blogspot.com]

3.3.1.2 Inicialización.
Esta fase se define el Product-Backlog, como también la arquitectura del
sistema, se procede a definir los actores que harán uso de la plataforma, así también
se describen los objetivos que cumplen los mismos como se observa en la Tabla
3.3

Tabla 3-3: Roles por actor

FUNCION DE ACTORES
Actor Objetivos
Administrador del Acceso a todos los módulos del sistema de información.
sistema
Gestionar usuarios.
Administrar y calcular la cuota mensual de mantenimiento.

54
 Generar reportes de los responsables, y las propiedades a su cargo.
Generar reportes de copropietarios e inquilinos. Con deudas por el
concepto de mantenimiento de gestiones pasadas.
Monitorea el estado de las deudas de las propiedades (departamento,
parqueo y baulera).
Directorio Generar reportes de los responsables (copropietarios e inquilinos), y las
propiedades a su cargo.
Generar reportes de copropietarios e inquilinos. Con deudas por el
concepto de mantenimiento de gestiones pasadas.

Responsable Gestionar su cuenta.

Verificar sus deudas pendientes.

Verificar el monto a cancelar por el servicio de mantenimiento del mes

actual.
Fuente: [Elaboración propia]

Casos de Uso.

Un caso de uso es un diagrama que nos ayuda a describir lo que debe de

hacer un sistema desde el punto de vista de quien lo va a utilizar. Captura algunas
de las acciones y comportamientos del sistema y como los actores interactúan con
él.

Con los actores definidos en la Tabla 3.3, se procede a describir de forma

general, los casos de uso del sistema como se observa en la Figura 3.3.

55
Figura 3-3: Caso de uso general
Fuente: [Elaboración propia]

56
Figura 3-4: Modelo Entidad Relación
Fuente: [Elaboración propia]

57
Figura 3-5: Diagrama de clases para el sistema
Fuente: [Elaboración propia]

58
 Figura 3-6: Diagrama base de datos
Fuente: [Elaboración propia]

En la Figura 3.4 se pueden observar el diagrama de clases de la base de datos,

contemplando la base de datos en su totalidad incluidas las tablas destinadas a
almacenar los históricos de la tabla “pago_detalle” y la tabla “propiedad”, también

59
se contempla las tablas para la navegación y permisos de los usuarios basado en
roles y accesos.

3.3 GAME Y FASE DE PRODUCCION.

En esta fase se describe el desarrollo del sistema web, donde se desarrolla cada
uno de los Sprints, en cada una de sus iteraciones para lograr los requerimientos
funcionales.

3.3.1 Desarrollo de los Sprints.

El proceso de desarrollo se sujetará a la presentación de 3 Sprints, en las
siguientes tablas, se detalla la planificación de los Sprints.

Tabla 3-4: Planificación de la primera iteración

PRIMER SPRINT
ID DESCRIPCION PRIORIDAD
R1 Gestión de usuarios. Alta
R2 Gestión de copropietarios. Alta
R3 Gestión de inquilinos. Alta
R4 Gestión de propiedades. Alta
R5 Registro de ingresos de efectivo Alta
R6 Registro de egresos de efectivo Alta
Fuente: [Elaboración propia]

Tabla 3-5: Planificación de la segunda iteración

SEGUNDO SPRINT
ID DESCRIPCION PRIORIDAD
R7 Calculo del prorrateo del agua. Media
R8 Calculo de la cuota mensual de mantenimiento de propiedades. Media
R9 Calculo de la cuota mensual por alquiler de áreas comunes. Media
Fuente: [Elaboración propia]

Tabla 3-6: Planificación de la tercera iteración

TERCER SPRINT
ID DESCRIPCION PRIORIDAD
R10 Calculo de deudas anteriores por parte de copropietarios e inquilinos. Baja
Adicionando el interés del 3%, si corresponde.
R11 Resumen estimado de ingresos. Baja
R12 Reporte de deudas de copropietarios e inquilinos, en forma descendente. Baja
Fuente: [Elaboración propia]

60
 3.3.1.1 Primer Sprint: Desarrollo de la interfaz de gestión de
usuarios, propiedades, copropietarios e inquilinos.
En este punto se detalla el desarrollo del primer Sprint, siguiendo la
metodología Scrum se realiza las siguientes 3 tareas: Planeación del Sprint,
Desarrollo y Revisión del Sprint.

 Planeación. a partir del primer Sprint, con las historias de usuarios

previamente seleccionadas se realizara la planificación de las tareas
a realizar por historia de usuario, en la tabla 3.7 se observan las
historias de usuario seleccionadas y las tareas que componen
terminar cada historia de usuario.

Tabla 3-7: Planificación de tareas del sprint

LISTA DE TAREAS
ID DESCRIPCION TAREA
T1 Gestión de usuarios. - Creación de tabla de usuarios en la base de
datos.
- Desarrollo del módulo login.
- Desarrollo del módulo sesiones.
T2 Gestión de copropietarios. - Creación de la tabla copropietarios en la base
de datos.
- Desarrollo del módulo altas de copropietarios.
- Desarrollo del módulo bajas de copropietarios.
- Desarrollo del módulo cambios de
copropietarios.

T3 Gestión de inquilinos. - Creación de la tabla inquilinos en la base de

datos.
- Desarrollo del módulo altas de inquilinos.
- Desarrollo del módulo bajas de inquilinos.
- Desarrollo del módulo cambios de inquilinos.
T4 Gestión de propiedades. - Creación de la tabla propiedades en la base de
datos.
- Desarrollo del módulo altas de propiedades.
- Desarrollo del módulo bajas de propiedades.
- Desarrollo del módulo cambios de propiedades.
T5 Registro de cuota mensual de - Desarrollo del módulo registro de cuota de
mantenimiento. mantenimiento.
T6 Registro pago de servicios básicos. - Desarrollo del módulo registro pago de
servicios básicos.
T7 Registro pago de personal. - Creación de tabla personal en la base de
datos.
- Desarrollo del módulo pago personal.
- Validación de formulario mediante Laravel.
T8 Registro pago de mantenimiento - Creación de la tabla mantenimiento en la base
preventivo. de datos.

61
 - Desarrollo del módulo pago mantenimiento.
- Validación de formulario mediante Laravel.
T9 Registro pago de proyectos Desarrollar modulo para el registro de pago de
proyectos.
T10 Registro gastos administrativos. - Desarrollo del módulo pago administrativos.
- Validación de formulario mediante Laravel.
T11 Registro de compras de insumos de - Creación de la tabla compras en la base de
limpieza, eléctricos, plomería. datos.
- Desarrollo del módulo compra insumos.
- Validación de formulario mediante Laravel.
T12 Registro de gastos varios. Desarrollo del módulo pago varios.
Fuente: [Elaboración propia]

Historias de usuario.

A continuación se redacta las historias de usuario que comprenden el Product-

Backlog del producto. Dada la naturaleza evolutiva del alcance de un proyecto Ágil,
las historias de usuario de mayor prioridad estarán más detalladas que las historias
de usuario de menor prioridad.

Tabla 3-8: Tareas por usuario del sprint

HISTORIAS DE USUARIO
P Historia de Como… Necesito… Para… Criterio de
usuario aceptación
1 Gestión de Usuario Crear usuarios Que estos En el caso de que
usuarios. administrador en el sistema usuarios se un usuario, dese
puedan ingresar al
autentificar en el sistema, este
sistema validara las
credenciales y sin
son correctas
ingresará, caso
contrario muestra
un mensaje datos
incorrectos.
2 Gestión de Usuario Poder crear a Que estos Cuando el
copropietarios. administrador copropietarios usuarios puedan copropietario
en el sistema ver el detalle de ingrese al
sus deudas. sistema, este
podrá ver sus
datos personales.
3 Gestión de Usuario Crear a Para poder En el caso de
inquilinos. administrador inquilinos en el verificar cuando existir inquilinos y
sistema. ingresaron al cuando se intente
condominio visualizar, el
sistema mostrara
cuando ingreso
dicho inquilino al
condominio.
4 Gestión de Usuario Poder crear Poder saber Cuando realice la
propiedades. administrador propiedades. quién es el acción ver en la

62
 responsable de propiedad, el
es propiedad. sistema mostrara
quien es el
responsable de la
propiedad.
5 Registro de Usuario Registrar los Saber cuánto Cuando se
ingresos de administrador ingresos. efectivo ingresa. requiera ver el
efectivo. registro de
ingresos, el
sistema mostrará
los tipos de
ingresos.
6 Registro de Usuario Registrar las Controlar el Cuando se
cuotas administrador cuotas estado de su requiera registrar
mensuales mensuales de deuda. el ingreso, el
mantenimiento sistema mostrara
opciones de qué
tipo de propiedad
se desea registrar
7 Registro alquiler Usuario Registrar el Calcular los El sistema
salón de administrador alquiler del ingresos mostrara la opción
eventos salón de generados. de copropietario o
eventos inquilino, para
dicho registro
8 Registro cuota Usuario Registrar la Calcular los El sistema deberá
de ingreso o administrador cuota de ingresos mostrar los datos
salida del ingreso o salida generados del responsable
condominio del condominio
9 Registro pago Usuario Registrar el Tener un detalle Cuando se quiera
de servicios administrador pago de de cuanto se ver los registros
básicos. servicios gasta por de pago, el
básicos. concepto de sistema mostrara
servicios un detalle de los
básicos. gastos realizados.
10 Registro pago Usuario Registrar pagos Tener un Cuando se quiera
de personal. administrador al personal adecuado visualizar el
control de los detalle, el sistema
egresos que se mostrara el monto
generan por y la persona.
pagos al
personal.
11 Registro pago Usuario Registrar pagos Obtener El sistema
mantenimiento administrador de información de mostrara detalles
preventivo. mantenimiento los gastos agrupados por
preventivo generados por cada concepto.
mantenimiento
preventivo.
12 Registro pago Usuario Registrar pago Tener un control El sistema
de proyectos administrador de proyectos de los egresos mostrara el monto
que se generan y el concepto por
por pago de lo que se efectuó
proyectos dicho pago.
13 Registro gastos Usuario Registrar los Tener El sistema
administrativos. administrador gatos información mostrara gastos
administrativos. detallada de

63
 gastos por administrativos
administración. efectuados.
14 Registro Usuario Registrar las Ver a cuanto El sistema
compras administrador compras de suman los mostrara los
insumos de insumos gastos registros
limpieza, detallados por
eléctricos, concepto y valor.
plomería.
15 Registro gastos Usuario Registrar a Saber de El sistema
varios. administrador detalle los manera mostrara de
gastos varios detallada los manera detallada
gastos varios los ítems y su
concepto.
Fuente: [Elaboración propia]

Se realizó el diseño de las interfaces como prototipo de la plataforma web

institucional y la página principal del sistema, donde se gestionara a los usuarios y
responsables, el diseño de muestra a continuación en la siguiente figura:

Figura 3-7: Gestión de usuarios de la página web

Fuente [Elaboración propia]

64
En la siguiente interfaz abstracta se gestionara a los responsables, los cuales
pueden ser copropietarios o inquilinos, estos son responsables de alguna
propiedad, a continuación la interfaz para los responsables.

Figura 3-8: Gestión de responsables de la página web

Fuente [Elaboración propia]

La interfaz de registro de ingresos de efectivo.

65
 Figura 3-9: Registro ingreso de efectivo
Fuente [Elaboración propia]

 Desarrollo. En esta etapa trabajamos en base a las historias de

usuario de nuestro sprint backlog siguiendo los pasos de la
metodología de desarrollo Scrum, para el diseño y maquetación de la
página web, se utilizará html5, css y bootstrap, el diseño realizado es
responsivo, es decir tiene adaptabilidad para todo tipo de dispositivos
(desde una PC hasta un Smartphone).

66
 Figura 3-10: Registro egresos de efectivo
Fuente: [Elaboración propia]

 Revisión. luego de realizar las tareas del primer Sprint, se hizo la

revisión correspondiente, Cada vez que se acabe un módulo y/o
módulos se realizara la presentación al administrador o a los
miembros del directorio.
En la siguiente tabla detallaremos los aspectos más sobresalientes en
este sprint.

Tabla 3-9: Éxitos y fracasos del Sprint

Resumen
Aciertos en el desarrollo del • Modelo lógico desarrollado.
sprint. • Inicio de desarrollo de aplicación utilizando el
framework Laravel.
• Servidor web y de aplicaciones instalado y
configurado.
Desaciertos en el desarrollo del - La base de datos sigue en proceso de construcción.
sprint. - Problemas en el modelado Base de datos.

En que debemos prepáranos Organización y planificación adecuada del proyecto.

Aspectos que se tienen que El cumplimiento en las fechas establecidas.
mejorar

67
 Fuente: [Elaboración propia]

3.3.1.2 Segundo Sprint: Desarrollo de la interfaz, cálculo del

prorrateo del agua, cálculo de la cuota mensual de
mantenimiento para copropietarios e inquilinos.
Después de realizar la planificación de la iteración, se establece que en el
SEGUNDO SPRINT cubrirá los requerimientos: R7, R8, y R9 del Product Backlog,
con lo que se da continuidad al desarrollo de los requerimientos del Backlog del
Producto, para obtener la segunda versión funcional del software. Las tareas se
detallan a continuación.

 Planeación. a partir del Segundo Sprint, con las historias de usuarios

previamente seleccionadas se realizará la planificación de las tareas
a realizar por historia de usuario, en la tabla 3.8 se observan las
historias de usuario seleccionadas y las tareas que componen
terminar cada historia de usuario.

Tabla 3-10: Planificación de tareas del sprint

LISTA DE TAREAS
ID DESCRIPCION TAREA
T1 Calcular ajuste de agua Desarrollar el modulo que realice el ajuste de la
factura del agua incrementado en un 10% al total
del importe.
T2 Calcular del factor o prorrateo del Desarrollar el modulo que realice el cálculo de
agua. factor de agua, con relación al número total de
personas que habitan en el condominio.
T3 Calcular la cuota mensual de Desarrollar el modulo que realice la suma de
mantenimiento de propiedades. todas las propiedades que están a cargo de un
responsable
T4 Calcular la cuota mensual por Desarrollar el modulo que realice el cálculo de
alquiler de áreas comunes. áreas comunes.
Fuente: [Elaboración propia]

Historias de usuario para la segunda iteración.

Tabla 3-11: Tareas por usuario del sprint

HISTORIAS DE USUARIO
P Historia de Como… Necesito… Para… Criterio de
usuario aceptación

68
 1 Calcular el Usuario Realizar el Adicionar a la Cuando se quiera
prorrateo del administrador cálculo del cuota de ver el factor de
agua. prorrateo o mantenimiento agua, el sistema
factor del agua a cada mostrar el monto del
departamento factor agua.
2 Calcular la - Usuario Calcular la Saber cuánto En el caso de ver la
cuota mensual administrador cuota mensual debe de cuota mensual de
de - Usuario de cancelar, el mantenimiento, el
mantenimiento directorio. mantenimiento responsable sistema mostrara
de por que tiene a cuanto debe de
propiedades. propiedades. cargo cancelar cada
propiedades. responsable por
cada propiedad que
está a su cargo.
3 Calcular la - Usuario Calcular la Conocer cuánto El sistema mostrara
cuota mensual administrador cuota mensual es el ingreso cual es el monto a
por alquiler de - Usuario por alquiler de percibido por cobrar por
áreas directorio. áreas comunes. este concepto mencionado
comunes. mensualmente. concepto.
Fuente: [Elaboración propia]

Desarrollo del prototipo, para la página web.

Figura 3-11: Ingreso cuota mensual prototipo

69
 Fuente: [Elaboración propia]

 Desarrollo. El módulo, calcular la cuota mensual de mantenimiento

de propiedades, es el que permite al administrador calcular la cuota
mensual de mantenimiento de distintas propiedades.
En el módulo calcular prorrateo o factor agua, es donde se realizará
los cálculos para obtener el monto del factor agua, para esta operación
es necesario la factura de agua ya que en ella está el importe del
consumo de agua.

Figura 3-12: Ingreso cuota mensual

Fuente: [Elaboración propia]

 Revisión. Luego de realizar las tareas del Sprint Backlog, se hizo la

revisión al módulo cálculo de cuotas mensuales de mantenimiento,
para los responsables que se muestra a continuación:

Tabla 3-12: Éxitos y fracasos del Sprint

Resumen

70
 Aciertos en el desarrollo del Búsqueda de responsables, copropietarios e inquilinos
sprint. mediante C.I.
Desaciertos en el desarrollo del - Los formularios de validación requieren algunas
sprint. mejoras.
- Registro de pago por periodo no es exacto.

En que debemos prepáranos Componentes de autovalidación y otras herramientas.

Aspectos que se tienen que Validación de formularios y manejo de fechas o
mejorar calendarios.
Fuente: [Elaboración propia]

3.3.1.3 Tercer Sprint: Desarrollo de la interfaz de reporte.

Resumen y reportes En este punto se detallará el desarrollo del Tercer Sprint,
siguiendo la metodología Scrum se realizará las siguientes 3 tareas: Planeación del
Sprint, Desarrollo y Revisión del Sprint.

 Planeación, a partir del Tercer Sprint, con las historias de usuarios

previamente seleccionadas se realizará la planificación de las tareas
a realizar por historia de usuario, en la tabla 3.9 se observan las
historias de usuario seleccionadas y las tareas que componen
terminar cada historia de usuario.

Tabla 3-13: Planificación de tareas del sprint

LISTA DE TAREAS
ID DESCRIPCION TAREA
T1 Calculo de deudas anteriores por - Desarrollo del módulo calcular deudas.
parte de copropietarios e inquilinos. - Desarrollo del módulo interés.
Adicionando el interés del 3%, si
corresponde.
T2 Resumen estimado de ingresos. Desarrollar el módulo estimación de ingresos en
el mes.
T3 Reporte de deudas de - Creación de la tabla pago detalle en la base
copropietarios e inquilinos, en forma de datos.
descendente. - Desarrollo del módulo deuda mantenimiento.
- Desarrollar en el Back-end módulo de
impresión.
T4 Reporte de copropietarios. Desarrollar módulo para listar copropietarios.
T5 Reporte de inquilinos. Desarrollar módulo para listar inquilinos.
T6 Reporte de propiedades, por - Desarrollar módulo para listar departamentos,
responsable. bauleras y parqueos
- Desarrollar modulo para listar propiedades, e
indicar quien es el responsable de la propiedad.
T7 Gestionar perfil de cuenta. Desarrollar modulo para poder configurar
cuentas personales, actualizar información
personal.

71
 T8 Reporte perfil de cuenta. Desarrollar módulo para mostrar información
personal.
Fuente: [Elaboración propia]

Historias de usuario para la tercera iteración.

Tabla 3-14: Tareas por usuario del sprint

HISTORIAS DE USUARIO
P Historia de Como… Necesito… Para… Criterio de
usuario aceptación
1
2 Reporte de - Usuario Realizar Generar una El sistema mostrara
copropietarios. administrador nóminas de nómina de en pantalla una lista
- Usuario todos los todos los de todos los
directorio. copropietarios. copropietarios, copropietarios.
para tomar
mejores
decisiones.
3 Reporte de - Usuario Obtener Generar una El sistema mostrara
inquilinos. administrador nóminas de nómina de un listado de todos
- Usuario todos los todos los los inquilinos.
directorio. inquilinos. inquilinos.
4 Reporte de - Usuario Obtener que Poder identificar El sistema mostrara
propiedades, administrador propiedades el responsable el listado de
por - Usuario están a cargo a de cada responsables y las
responsable. directorio. cierto propiedad. propiedades que
responsable. están a su cargo
5 Gestionar - Usuario Poder modificar Actualizar mis El sistema aceptara
perfil de administrador mi cuanta del datos los cambios
cuenta. - Usuario sistema. realizados por el
directorio usuario.
- usuario
invitado
6 Reporte perfil - Usuario Poder ver la Poder saber si El sistema mostrar
de cuenta. administrador información de mi información la información
- Usuario mi cuenta. es la correcta personal del usuario
directorio en el sistema. en su perfil de
- usuario cuenta.
invitado
7 Calculo de - Usuario Poder calcular Obtener El sistema mostrar
deudas administrador deudas información de en pantalla la cuota
anteriores por - Usuario anteriores de cuanto es la mensual, en caso
parte de directorio departamento, cuota de existir interés
copropietarios - usuario baulera y acumulada por realizara el
e inquilinos. parqueos. concepto de respectivo cálculo
Adicionando el mantenimiento. del 3%.
interés del
3%, si
corresponde.
8 Resumen - Usuario Obtener un Tener una El sistema mostrara
estimado de administrador resumen de estimación de una estimación de
ingresos. - Usuario ingresos ingresos, que ingresos para el
directorio estimados para serán próximo mes.
el próximo mes monetizados.

72
 9 Reporte de - Usuario Generar reporte Saber El sistema mostrara
deudas de administrador de aquellos específicamente en pantalla, los
copropietarios - Usuario copropietarios e porque meses y periodos
e inquilinos, directorio inquilinos con conceptos tiene por el cual se tiene
en forma deudas mayores deudas y a deudas.
descendente. a 24 meses. cuanto suma.
Fuente: [Elaboración propia]

Desarrollo del prototipo

Figura 3-13: Reporte Planilla

Fuente: [Elaboración propia]

 Desarrollo, En estos módulos contempla todos los reportes como ser:

reporte de copropietarios, inquilinos, departamentos, bauleras y
parqueos, en el cual se tiene la información necesaria requerida por él
cliente. Y además los usuarios invitados podrán realizar
configuraciones personalizadas a sus cuentas.

73
 Figura 3-14:Cierre de Planilla
Fuente: [Elaboración propia]

En esta tercera iteración se finaliza el desarrollo del sistema con el cierre de las
historias de usuario.

3.4 POSTGAME PRUEBAS.

Post-Game es la última fase de la Metodología Scrum denominada “clousure o
cierre”, que consta en la prueba final del proyecto, uniendo todos los elementos
unitarios.

La etapa de pruebas de un sistema de información presenta un elemento crítico

para la garantía de la calidad de software, y representa una revisión final de las
especificaciones del diseño y la codificación (Pressman, 2012).

En un proyecto de desarrollo de un sistema de información pueden aparecer errores

en cualquiera de las etapas del ciclo de vida, algunos de ellos incluso permanecen
sin ser descubiertos, de ahí la importancia de las pruebas en desarrollo del sistema.

74
Hay una gran probabilidad de que el código final tenga errores tanto de
requerimientos, como de diseño o de funcionalidad. Para identificar estos problemas
antes de que ocurran en un entorno crítico, es necesario realizar pruebas de
software, una parte muy importante del proceso, pero también muy costosa; sin
embargo, debemos tener en cuenta que el coste debido a un fallo mientras está el
software en funcionamiento puede llegar a ser mucho mayor.

Para realizar las pruebas del sistema de información se hizo pruebas, donde se
centra en una representación de aquellos aspectos del sistema que serán visibles
para el cliente o el usuario final. Gracias a esto se refinan los requisitos del sistema
que se desarrolló. La interacción ocurrirá hasta que el sistema se ajuste para
satisfacer las necesidades del cliente. Esto permite que al mismo tiempo, él
desarrollador entienda lo que debe hacer y el cliente vea resultados en corto plazo.

A continuación se muestra el caso de prueba correspondiente al ingreso al sistema,

el cual tiene por objetivo la funcionalidad de la verificación del usuario y contraseña.

Tabla 3-15: Caso de prueba ingreso al sistema

INGRESO AL SISTEMA
Descripción El sistema debe realizar el control de ingreso de
usuarios al sistema.
Tipo Funcional.
Precondiciones El usuario no debe estar autenticado en el sistema.
Postcondiciones El usuario ingresa a la página principal del sistema.
Procedimiento de prueba
Actor Respuesta sistema
1. El usuario introduce su usuario y 2. El sistema verifica el nombre de usuario y
clave. contraseña.
3. El usuario selecciona la opción 4. El usuario ingresa a la página principal.
ingresar.
Resultado obtenido
Intentos Observaciones
Primeros intentos Sin observaciones
Cumple No se encontraron fallas
Fuente: [Elaboración propia]

Posteriormente al haber realizado el caso de prueba de ingreso al sistema, ya se

toma en cuenta que el administrador del sistema realizara los registros de los
Copropietarios e inquilinos, dicho registro se lo realiza con la información requerida,
este registro se lo realiza para tener la información completa de los Usuarios.

75
Tabla 3-16: Caso de prueba registro de usuarios
REGISTRO DE USUARIOS
Descripción El sistema debe realizar el registro de usuarios al
sistema.
Tipo Funcional.
Precondiciones El usuario debe estar autenticado en el sistema
con el rol de administrador para poder gestionar
usuarios.
Postcondiciones El usuario registrado podrá ingresar al sistema.
Procedimiento de prueba
Actor Respuesta sistema
1. El usuario administrador introduce la 2. El sistema verifica que la información ingresada
información del nuevo usuario al sea correcta el nombre de usuario y contraseña.
sistema.
4. El sistema registra al nuevo usuario con la
3. El usuario administrador selecciona la información introducida.
opción registrar.
Resultado obtenido
Intentos Observaciones
Primeros intentos Sin observaciones
Cumple No se encontraron fallas
Fuente: [Elaboración propia]

Posteriormente al caso de prueba registro de usuarios, se realiza el caso de prueba

reporte de los usuarios.

Tabla 3-17: Caso de prueba reporte de usuarios.

REPORTE DE USUARIOS
Descripción El sistema debe realizar el reporte de usuarios del
sistema.
Tipo Funcional.
Precondiciones El usuario debe estar autenticado en el sistema con
el rol de administrador para poder realizar el reporte
de usuarios.
Postcondiciones El usuario administrador podrá realizar el reporte de
usuarios del sistema.
Procedimiento de prueba
Actor Respuesta sistema
1. El usuario administrador consulta 2. El sistema verifica o valida la consulta.
al sistema por los usuarios de la
4. El sistema muestra la información del usuario
misma.
seleccionado.
3. El usuario administrador selecciona
al usuario por el cual está interesado.
Resultado obtenido
Intentos Observaciones
Primeros intentos Sin observaciones
Cumple No se encontraron fallas
Fuente: [Elaboración propia]

76
Obteniendo resultados satisfactorios del caso de prueba de registro y reporte de
usuarios, se realiza el registro de propiedades. A continuación se muestra el caso
de prueba de registro de propiedades, con la finalidad de que los registros sean
satisfactorios.

Tabla 3-18: Caso de prueba registro de propiedades.

REGISTRO DE PROPIEDADES
Descripción El sistema debe realizar el registro de
propiedades al sistema.
Tipo Funcional.
Precondiciones El usuario debe estar autenticado en el sistema
como administrador para poder gestionar las
propiedades.
Postcondiciones El usuario administrador podrá gestionar las
propiedades registradas.
Procedimiento de prueba
Actor Respuesta sistema
1. El usuario administrador introduce la 2. El sistema valida que la información ingresada
información de la nueva propiedad al sea correcta para una propiedad.
sistema.
4. El sistema registra la nueva propiedad con la
3. El usuario administrador selecciona la información introducida.
opción registrar.
Resultado obtenido
Intentos Observaciones
Primeros intentos Sin observaciones
Cumple No se encontraron fallas
Fuente: [Elaboración propia]

Ya que se hiso el caso de prueba registro de propiedad, ahora de realizar el caso

de prueba reporte de propiedad.

Tabla 3-19: Caso de prueba registro de usuarios.

REPORTE DE PROPIEDAD
Descripción El sistema debe realizar el registro de usuarios al
sistema.
Tipo Funcional.
Precondiciones El usuario debe estar autenticado en el sistema con
el rol de administrador para poder gestionar las
propiedades.
Postcondiciones El usuario administrador podrá gestionar las
propiedades registradas en el sistema.
Procedimiento de prueba
Actor Respuesta sistema

77
 1. El usuario administrador 2. El sistema genera un reporte con todas las
seleccionara propiedades. propiedades.
3. El usuario administrador selecciona 4. El sistema muestra a detalle la propiedad
la propiedad para poder ver a detalle. seleccionada.
Resultado obtenido
Intentos Observaciones
Primeros intentos Sin observaciones
Cumple No se encontraron fallas
Fuente: [Elaboración propia]

• Perfectivo: son las acciones llevadas a cabo para mejorar la calidad

interna de los sistemas en cualquiera de sus aspectos: reestructuración
del código, definición más clara del sistema y optimización del
rendimiento y eficiencia.
• Evolutivo: son las incorporaciones, modificaciones y eliminaciones
necesarias en un producto para cubrir la expansión o cambio en las
necesidades del personal.
• Adaptativo: son las modificaciones que afectan a los entornos en los
que el sistema opera, por ejemplo, cambios de configuración del
hardware, software de base, bases de datos, comunicaciones, entre
otros.

• Correctivo: son aquellos cambios precisos para corregir errores del

producto de software.

3.5 MANTENIMIENTO DEL SISTEMA.

Existe un gran desbalance entre el desarrollo y el mantenimiento de sistemas de
información. Paradójicamente la inversión en mantenimiento es del 40% al 70% del
valor total del ciclo de vida del software (tomado Software Maintenance, Concepts
and Practice). Adicionalmente, algunos autores sugieren que la mayor parte de
nuestro tiempo (90%) como desarrolladores lo gastamos manteniendo códigos
escritos por otros.

A continuación mencionamos por que el sistema de información tendrá un fácil

mantenimiento ya que se da a conocer los siguientes puntos:

78
 • Perfectivo, el código es fácil de reestructurar ya que la lógica del sistema
se encuentra en los Controladores y las consultas en los Modelos de la
arquitectura. El sistema se hace más amigable y entendible al usuario para
que este tenga un alto rendimiento y eficiencia al momento de interactuar.
• Evolutivo, los cambios que se podrían realizar en un tiempo futuro serán
seguros, de acuerdo a modificaciones, eliminaciones o incorporaciones de
nuevos módulos, ya que la arquitectura es entendible y ordenada para poder
proseguir con los cambios.

• Adaptativo, si los usuarios finales cambian de sistema operativo, de

equipos, no se verá afectado al sistema por ser una WebApp. Para el lado
de la arquitectura: este soporta el cambio de base de datos a Postgres,
SqlLite y SQLServer; configuraciones de red: permisos ya establecidos con
el administrador de servidores.
• Correctivo, el sistema en su fase de desarrollo presenta la información
necesaria en caso de algún error o falencia que ocurra, para poder prevenir
ya en su fase de implementación.

3.6 CALIDAD DE SOFTWARE.

Las métricas de calidad y seguridad, indican un análisis de cómo se ajusta el
sistema a los requerimientos de los interesados y la seguridad que se implementa
en el sistema.

La calidad de un sistema es lo más necesario y el principal requerimiento del cliente

quien busca la mejor calidad de software a sus propios intereses, al mismo tiempo
ningún sistema de información llega a la perfección absoluta, para que cumpla todas
las expectativas del cliente, por lo que se realiza un análisis de calidad, en el cual
se utilizara la norma iso 9126.

3.6.1 Funcionalidad.
Esta métrica lo que pretende es medir el software de acuerdo a los requerimientos
funcionales de los usuarios finales. Para realizar dicha tarea se utilizara los puntos
por función y así podremos medir la funcionalidad del sistema de información.

79
A continuación detallamos los cálculos:

Tabla 3-20: Archivo lógico interno.

FUNCIONALIDADES DEL SISTEMA DE INFORMACION
FUNCIONALIDAD TIPO
Registro de usuarios y roles. Entrada externa (EI).
Registro de copropietarios Entrada externa (EI).
Registro de inquilinos Entrada externa (EI).
Registro de propiedades. Entrada externa (EI).
Registro de cuotas mensuales de mantenimiento. Entrada externa (EI).
Registro pago de servicios básicos Entrada externa (EI).
Registro pago de personal. Entrada externa (EI).
Registro de pago de proyectos. Entrada externa (EI).
Registro de pago de manteniendo preventivo. Entrada externa (EI).
Registro de gastos. Entrada externa (EI).
Registro de compras de insumos. Entrada externa (EI).
Registro de gastos Varios Entrada externa (EI).
Listado de usuarios. Consulta externa (EQ).
Listado de propiedades. Consulta externa (EQ).
Listado de copropietarios. Consulta externa (EQ).
Listado de inquilinos. Consulta externa (EQ).
Calculo del prorrateo del agua. Salida externa (EO).
Calculo de la cuota mensual por mantenimiento Salida externa (EO).
Calculo de cuota por alquiler por áreas comunes. Salida externa (EO).
Calculo de deudas anteriores copropietarios e inquilinos Salida externa (EO).
Reporte de resumen estimado de ingresos Salida externa (EO).
Reporte de deudas de copropietarios en forma desc. Salida externa (EO).
Fuente: [Elaboración propia]

Ahora detallaremos el cálculo de los puntos por función sin ajustar.

Tabla 3-21: Cálculo de Puntos por función sin ajustar.

PUNTOS POR FUNCION SIN AJUSTAR
Valor de dominio Cuenta Complejidad Total
Entradas del usuario 12 X3 36
Salidas del usuario 6 X4 24
Peticiones del usuario 4 X3 12
Archivos 13 X7 91

80
 Interfaces externas 0 X5 0
TOTAL PUNTOS POR FUNCION SIN AJUSTAR 163
Fuente: [Elaboración propia]

Calculamos el factor de ajuste.

Tabla 3-22: Cálculo de Factor de Ajuste

N° Facto de ajuste de valor Valor
1 ¿El sistema requiere respaldo y recuperación confiables? 3
2 ¿Se requieren comunicaciones de datos especializadas para transferir información 3
hacia o desde la aplicación?
3 ¿Existen funciones de procesamiento distribuidas? 0
4 ¿El desempeño es crucial? 3
5 ¿El sistema correrá en un entorno operativo existente enormemente utilizado? 5

6 ¿El sistema requiere entrada de datos en línea? 3

7 ¿La entrada de datos en línea requiere que la transacción de entrada se construya 3
sobre múltiples pantallas u operaciones?
8 ¿Los ALI se actualizan en línea? 3
9 ¿Las entradas, salidas, archivos o consultas son complejos? 3
10 ¿El procesamiento interno es complejo? 2
11 ¿El código se diseña para ser reutilizable? 4
12 ¿La conversión y la instalación se incluyen en el diseño? 3
13 ¿El sistema se diseña para instalaciones múltiples en diferentes organizaciones? 4

14 ¿La aplicación se diseña para facilitar el cambio y su uso por parte del usuario? 3

Total ΣFi 42
Fuente: [Elaboración propia]

Con la obtención de los anteriores datos y considerando un grado de confiabilidad

mínimo del 65%, procedemos al calculamos el valor de Punto Función Ajustado
PFA:

Donde:

PFSA: Puntos de función sin ajustar

PFA: Puntos de función ajustado

PFA= PFSA *(GRADO_DE_CONFIABILIDAD+[TASA_DE_ERROR*ΣFi])

PFA=163*(0.65+[0.01*42])

81
PFA=174.41

PFA=174

Para el cálculo del valor de la funcionalidad se hace comparación con el valor

máximo qué se podría tener qué seria 70, con lo que se tiene la siguiente
relación:

PFAmax=163*(0.65+[0.01*70])

PFAmax=220.05

Entonces, el valor de la funcionalidad es:

.
= = = 0.7925
.

Por lo tanto, la funcionalidad es:

= 79.25%

Entonces la funcionalidad es de un casi 80%. Y además se tomó los siguientes

puntos:

 Adecuación: El sistema es capaz de ejecutar las tareas requeridas por los

usuarios.
 Exactitud: Los cálculos efectuados por el sistema son correctos.
 Interoperabilidad: No se aplica
 Seguridad de acceso: El sistema cuenta con autentificación y roles de
usuarios. También tiene protección de inyecciones SQL.
 Cumplimiento funcional: Para la implementación se analizó la mayoría de
los parámetros susceptibles a cambios, debido a determinaciones que se
puedan tomar en las reuniones de los copropietarios.

De acuerdo a los características del sistema mencionados podemos afirmar que el

sistema es funcional.
82
 3.6.2 Confiabilidad.
La confiabilidad del software es la precisión con la que una aplicación proporciona,
sin errores, los servicios que se establecieron en las especificaciones iniciales.

Usando la fórmula de tiempo medio entre fallos tenemos:

( = + = 8ℎ + 1.2ℎ = 9.2ℎ)

Calculando la probabilidad con relación a:

= = = 0.8695 = 86.95%
.

Por lo tanto la confiabilidad es:

= 86.95%

Cabe mencionar que además cuenta con las siguientes características:

 Madurez: Se realizó la validación de entrada de datos en los diferentes

formularios. Además el sistema genera copias de respaldo diarias para que
periódicamente el administrador del sistema pueda grabarlos en medios de
almacenamiento externo.
 Tolerancia a fallos: En caso de no contar con el servicio de internet, se
cuenta con una PC con el sistema instalado, donde se procederá a restaurar
la última versión de la base de datos solo para consultas. Ya que
principalmente el sistema se usa para consultas.
 Recuperabilidad: Las consultas se realizan mediante una copia que se
realiza de manera automática, así teniendo una copia de seguridad, el
Administrador recupera la información anterior y así puede realizar sus
actividades sin interrupciones.

3.6.3 Usabilidad.
Es un factor qué solo se puede medir indirectamente, y está relacionado
plenamente con los usuarios finales, y con lo amigable qué puede ser el sistema
con el usuario. Para esto se utilizó un cuestionario y un rango de valores para
la calificación.

83
Tabla 3-23: Valores para evaluar la usabilidad
USABILIDAD
Escala Valor
Excelente 5
Bueno 4
Aceptable 3
Deficiente 2
Pésimo 1
Fuente: [Elaboración propia]

La realización de un cuestionario que consta de 10 preguntas, donde se ve los

valores máximos y mínimos obtenidos para cada pregunta, el valor obtenido
corresponde a un promedio de 10 usuarios finales.

Tabla 3-24: Tabla de preguntas.

N° Pregunta Min Max Promedio
1 ¿Es fácil de recordar las órdenes y aprender las operaciones 3 5 3.6
básicas?
2 ¿Cómo considera los mensajes qué genera el sistema, son 3 4 3.2
entendibles?
3 ¿Considera usted qué el sistema es una herramienta útil? 3 4 3.6
4 ¿Los reportes qué genera son útiles para su trabajo? 3 5 4.3
5 ¿El sistema le sirve de ayuda para la toma de decisiones? 4 5 4.5
6 ¿Recomendaría el sistema a otras instituciones similares? 4 5 4.6
7 ¿Le es fácil orientarse respecto a las acciones qué tiene a su 3 5 3.9
disposición, en un determinado instante?
8 ¿El sistema le proporciona suficiente información para realizar sus 3 5 4.2
tareas?
9 ¿La velocidad de respuesta del sistema es óptima? 3 5 4.1
10 ¿El sistema llego a cumplir con todas sus expectativas? 3 5 3.9
Fuente: [Elaboración propia]

Tabla 3.19 Tabla de preguntas.

. . . . . . . . . .
= x = 0.798

= 79.8%

Así mismo, estas características son parte del sistema.

 Entendimiento: fácil de comprender al momento de generar los reportes por

mes. el sistema ofrece toda la información para realizar el procedimiento de
manera segura.
 Aprendizaje: el sistema es de fácil de aprender ya que brinda una interfaz
amigable para el usuario final.
84
  Operabilidad: por ser una WebApp es fácil de operarlo y controlado
mediante un navegador actualizado en cualquier plataforma de sistema
operativo.
 Atracción: el sistema brinda la presentación al usuario en un entorno
responsivo, es decir se adapta a todo tipo de pantalla.

3.6.4 Eficiencia.
La eficiencia es la capacidad del sistema de información, para hacer buen uso de
los recursos que manipula. Lo importante es mantener un balance adecuado entre
eficiencia y corrección.

 Comportamiento temporal: el sistema trabaja con vistas donde se

muestran las solicitudes a las bases de datos mediante Ajax, y los datos son
mostrados sin tener que recargar toda la página, y asi no tener demora en
los procesos que se está realizando.
 Utilización de recursos: en cuanto al hardware necesario es el mínimo que
se tiene, en el Condominio se cuenta con una PC Core 2Duo, con el sistema
operativo Windows 7 que cuentan con una red de Internet o Intranet. Del lado
del Servidor cuentan con la versión de PHP y MySql, apropiada para puesta
en producción.

Para obtener el cálculo de la eficiencia, se tomara distintas escalas y asignarles un

valor.

Tabla 3-25: Rangos para evaluar la eficiencia

EFICIENCIA
Escala Valor
Excelente 5
Bueno 4
Aceptable 3
Deficiente 2
Pésimo 1
Fuente: [Elaboración propia]

Haciendo la valorización del sistema, se tienen las siguientes apreciaciones, tal

como se muestra en la siguiente tabla:

85
Tabla 3-26: Valoración para la eficiencia
Preguntas de valoración Valor
¿Procesa rápidamente las deudas acumuladas? 4

¿Procesa rápidamente los responsables por propiedad? 3

¿Procesa rápidamente el registro de algún usuario? 5

¿Procesa rápidamente la búsqueda de algún usuario? 4

¿Responde adecuadamente cuando realiza alguna consulta? 4

Fuente: [Elaboración propia]

En base a esto, se puede tener una idea cuantitativa de la eficiencia.

= x = 80 = 80%

3.6.5 Mantenibilidad.
Esta característica representa la capacidad del producto software para ser
modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas
o perfectivas. El sistema cuenta con las siguientes características:

 Capacidad para ser analizado: por ser un sistema bajo la arquitectura

Modelo, Vista y Controlador es de fácil rastreo de código para permitir
diagnósticos de deficiencias, causas de fallas o la identificación de partes
modificadas.
 Capacidad para ser cambiado: los cambios que se vayan a realizar es
independiente del funcionamiento de las otras partes del sistema, entonces
estos cambios no tendrían que perjudicar el funcionamiento del sistema.
 Estabilidad: el sistema ofrece la información necesaria, en caso de que surja
modificación, para no realizar errores irreversibles en el sistema.
 Facilidad de Prueba: la arquitectura del sistema ofrece, cambios y que luego
puedan ser probados.

Ahora calcularemos la mantenibilidad del sistema de información.

86
Tabla 3-27: Rangos para la mantenibilidad.
MANTENIBILIDAD
Escala Valor
Excelente 5
Bueno 4
Aceptable 3
Deficiente 2
Pésimo 1
Fuente: [Elaboración propia]

Valorando el mantenimiento del sistema, se tienen las siguientes apreciaciones,

tal como se muestra en la siguiente tabla:

Tabla 3-28: Valoración para la mantenibilidad.

Preguntas de valoración Valor
¿Es fácil de analizar una falla o un error? 3
¿Se puede identificar las partes qué deben ser modificados? 3

¿Existe la facilidad de realizar cambios? 4

¿Los cambios permiten una mejor estabilidad? 4
¿Los cambios mejoran la facilidad de pruebas? 4
Fuente: [Elaboración propia]

Tabla 3.23 Valoración para la mantenibilidad.

En base a esto se puede tener una idea cuantitativa de la portabilidad, como

sigue:

= x= = 72%

3.6.6 Portabilidad.
La portabilidad es la característica que posee un software para ejecutarse en
diferentes plataformas, el código fuente del software es capaz de reutilizarse en vez
de crearse un nuevo código cuando el software pasa de una plataforma a otra.

Por otra parte debemos de mencionar estos puntos:

 Adaptabilidad: por ser una WebApp el sistema se adapta a todo tipo de

plataforma a nivel de sistema operativo, a nivel de hardware necesita lo
mínimo en cuestión de memoria RAM y procesador sin que implique

87
 reacciones negativas ante el cambio, al nivel de diseño por ser responsivo
de adapta a todo tipo de pantallas.
 Instalabilidad: por ser un sistema, WebApp no necesita de instalación solo
contar con una red de Internet o Intranet y su funcionamiento será inmediata.
 Coexistencia: las consultas que se realicen en el Modelo generan objetos
de tipo Json lo cuales son útiles para un WebService.
 Capacidad para reemplazar: la arquitectura del sistema trabaja con
migraciones para las bases de datos en caso de una nueva versión del
sistema, así sería fácil migrar los datos del anterior a la nueva versión.

Se valoró a cada sub-atributo con el rango de valores de la siguiente tabla.

Tabla 3-29: Rangos para la portabilidad.

PORTABILIDAD
Escala Valor
Excelente 5
Bueno 4
Aceptable 3
Deficiente 2
Pésimo 1
Fuente: [Elaboración propia]

Valorando la portabilidad del sistema, se tienen las siguientes apreciaciones, tal

como se muestra en la siguiente tabla:

Tabla 3-30: Valoración para la portabilidad.

Valoración para la portabilidad Valor
Facilidad de instalación 3
Facilidad de ajuste 4
Facilidad de adopción al cambio 3
Soporte en los diferentes sistemas operativos 5
Fuente: [Elaboración propia]

En base a esto se puede tener una idea cuantitativa de la portabilidad, como

sigue:

= x= = 75%

88
En resumen, los resultados de las características de las normas ISO/IEC 9126
son:

Tabla 3-31: Resumen de resultados

RESUMEN
Escala Valor
Funcionalidad 79.26 %
Confiabilidad 86.95 %
Usabilidad 79.8 %
Eficiencia 80 %
Mantenimiento 72 %
Portabilidad 75 %
Promedio 78.84 %
Fuente: [Elaboración propia]

Se puede observar que el usuario tendrá una satisfacción de 78.84 % al momento

de utilizar el sistema

3.7 SEGURIDAD DEL SOFTWARE.

3.7.1 Políticas de seguridad (Usuarios).
Estas políticas protegen los recursos de información de la entidad y la tecnología
utilizada para su procesamiento de una amplia gama de amenazas, internas o
externas, a fin de garantizar la integridad de los recursos informáticos que el
Condominio “La Joya” pone a disposición de los usuarios para el cumplimiento de
sus responsabilidades.

A continuación se detalla las funciones y los accesos a los usuarios finales.

 Administrador: Puede acceder a la información de toda la Base de Datos

del Sistema, modificar, eliminar, registros, administrar la información y las
sesiones de los usuarios y es el encargado de gestionar sistema
proporcionado.
 Usuario Directorio: de igual manera que el administrador tiene acceso a
todas las opciones del sistema, para realizar consultas y generar reportes
que sean de la importancia para el directorio.

89
  Usuario: el usuario común solo puede acceder a la información, a la cual es
responsable o está a cargo de propiedades como ser, departamento,
parqueo y baulera.

3.7.2 Políticas de acceso de seguridad al sistema de información.

El sistema verifica la autenticidad del usuario y su contraseña. Los usuarios deben
guardar de forma segura tanto su contraseña como su nombre de usuario, en caso
de olvido se debe solicitar la información correspondiente al Administrador del
Sistema. El acceso a la Base de Datos es restringido para usuarios no autorizados
mediante roles por usuario, así mismo está protegido por Laravel para las
inyecciones SQL.

Laravel 5.2 implementa Middleware, que tienen una utilidad similar a un filtro de
acceso que nos permiten proteger rutas y acciones de acceso no autorizado. El
Middleware, como el nombre lo indica, se sitúa en el medio entre la petición del
usuario (Request) y las acciones del controlador que arman y envían la respuesta
(Response).

90
 Capítulo IV

Conclusiones
Recomendaciones
91
 CAPITULO 4.
4.1 CONCLUSIONES.
Una vez concluido el presente proyecto, realizado el análisis, desarrollo e
implementación del sistema de información, destacamos lo siguiente.

• Se desarrolló el sistema de información, con herramientas útiles, que hicieron

posible conclusión de la misma y se puso funcionamiento, en el condominio “La
Joya” el cual facilitara los procesos de cobros mensuales de la Cuota de
mantenimiento.

• Se logró desarrollar los módulos requeridos por los miembros del Directorio
y personal administrativo. Estos módulos se detallan a continuación:

o Se logró centralizar la información del proceso diario de recibo de

ingresos por concepto de mantenimiento, a una base de datos.
o Se tiene control de quienes y cuanto deben por concepto de
manteniendo.
o Se mejoró el manejo de cobro de mantenimiento.
o Se facilitó el proceso de generar listas de deudores con deudas
mayores a los 24 meses.
o Se puede dar seguimiento a las deudas de los Copropietarios e
inquilinos.
o Se mejoró el cobro a los Copropietarios e inquilinos, generando
recibos con información detallada sobre que conceptos de les hace el
cobro.

De esta forma, se alcanzó el objetivo general de lograr la informatización de los

procesos de ingresos y egresos, de manera que la información ahora se encuentra
a disposición de los miembros del directorio y del administrador para hacer el control
adecuado a dichos procesos.

Esto se logró mediante la ejecución de las fases propuestas por la metodología

Scrum.

92
El personal encargado, está llenando de forma gradual la Base de Datos, ya que
cuentan con una extensa lista de deudores.

Actualmente el sistema está imprimiendo recibos sin detalle, esto por la falta de
información en la base de datos.

4.2 RECOMENDACIONES.
Ahora que se ha puesto en funcionamiento la solución desarrollada para el
Condominio “La Joya”, se tropezaron con ciertos inconvenientes relacionados a las
tecnologías utilizadas en la capa de la interfaz de usuario. El problema radica en
que no se lograron manipular ciertos eventos de los componentes del Framework
LARAVEL; sin embargo, ello no fue un obstáculo para el funcionamiento normal de
los procesos, ya que son subsanados con el uso correcto de la herramienta.

Sin embargo, se sugiere usar una tecnología que sea más flexible en la definición

de sus eventos, la cual podría ser CodeIgniter o Yii, ya que su curva de

aprendizaje es bastante corta, en la codificación, aseguraría contar con todas
las funciones y eventos bien definidos y controlados.

En la capa de la base de datos surge la curiosidad de probar Oracle por la gran

capacidad que Oracle, tiene de almacenar grandes cantidades de datos, además
de su afamada estabilidad; pero al no contar con la disponibilidad de un servidor
adecuado que soporte este sistema de gestión, ameritaría previamente que el
cliente adquiera una mejor infraestructura de hardware. En la experiencia adquirida,
son muy pocos los servidores que aceptan Java; muchos en la generalidad
están diseñados para soportar PHP y MySQL exclusivamente. Esto merece un
examen sobre los servidores disponibles que existen para alojar la tecnología que
se pretende emplear. En el caso del presente proyecto, se está en la búsqueda de
un servidor que aloje Weblogic.

93
BIBLIOGRAFÍA

C., D. (2000). Sistema de información para los negocios. Mexico: Mc. Graw Hill 3ra
ed.

cakephp. (s.f.). Modelo - Vista - Controlador. Obtenido de

https://book.cakephp.org/2.0/es/cakephp-overview/understanding-model-
view-controller.html

Cyment, A., & Mayer, T. (2014). Por un Scrum Popular. Dymaxicon.

Domínguez, A., & Aurelio, J. (2009). La gestión de los sistemas de información en

la empresa. Pirámide 3ra. ed.

Eduardo, G. (2008). Espejos. Mexico: Trillas.

Institute, P. M. (2013). Fundamentos para la dirección de proyectos. Guide to the

Project Management Body of Knowledge.

iso.org. (11 de 2017). iso.org. Obtenido de https://www.iso.org/standard/22891.html

iso.org. (11 de 2017). iso.org. Obtenido de https://www.iso.org/standard/39752.html

Jeff Gothelf, J. S. (214). Lean UX. Unir Editorial.

Jose, S. (2006). Ensayo sobre la ceguera. Buenos Aires: Estrada.

laraveles.com. (3 de 11 de 2017). Laravel. Obtenido de

https://docs.laraveles.com/docs/5.5

Leod, M. (2000). Sistema de informacion gerencial. Mexico: Prentice Hall 7ma. ed.

Porto, J. P., & Merino, M. (2012). Definicion.de. Obtenido de

https://definicion.de/condominio/

94
Rubin, K. S. (2012). Essential Scrum. Pearson.

Sapag Chain, N., & Sapag Chain, R. (2008). Preparacion y evaluacion de proyectos.
bogota: McGraw-Hill.

Schwaber, K., & Sutherland, J. (2010). Scrum Guide; Scrum Alliance.

Touriñan López, J. M. (2008). Teoría de la educación investigación disciplinar y

retos. Bogotá, Colombia: Magis. Revista Internacional de Investigación.

Valor, J., R, A., & E., R. J. (1991). Estrategia y sistemas de información. Madrid:
McGraw-Hill 2da. ed.

95
96
 MATRIZ DE INVOLUCRADOS
GRUPOS INTERES PROBLEMAS PERCIBIDOS RECURSOS Y MANDATOS
Financieros (dinero por el
cobro de los servicios de
Deudas pendientes, por
Una buena administración de mantenimiento, ingresos
Miembros del Directorio parte de los copropietarios
todos los recursos externos).
(integrados por los mismos llegando hasta incluso hasta
disponibles (dinero, personal Personal de trabajo
Copropietarios) los dos años.
de trabajo) (administrador, porteros,
limpieza).

Vecinos irresponsables ante

el cuidado de sus mascotas,
Vivir en completa
Copropietarios (personas vecinos que realizan fiestas
que habitan en el edificio tranquilidad, donde exista el Llevar quejas orales ante la
que son propietarios de su cualquier día de la semana y
respeto mutuo. administración.
departamento). hasta
altas horas de la madrugada.

1
 Reclamos sobre vecinos que
regulen sus deudas
Que se disminuya la cantidad Recursos financieros,
pendientes, quejas sobre el
de reclamos, respecto al humanos previa
Administrador. directorio en cuanto a la
personal de portería, como al autorización del Directorio.
administración en esa
de limpieza.
gestión, información respecto
a los recursos financieros.

2
3
4
 MATRIZ MARCO LOGICO
DESCRIPCION INDICADORES VERIFICACION SUPUESTOS

Mayor información de
recursos financieros
para la toma de De acuerdo a la satisfacción y la
FIN Con la ayuda del Correcto uso del sistema de
decisiones. aceptabilidad de los miembros del
administrador información.
readecuando, directorio
organizando el flujo de
dinero
Lograr una adecuada
administración (Cobro
del servicio de
Revisión docente tutor
mantenimiento). Necesariamente tiene que ser
PROPOSITO Respuestas inmediatas a Revisión docente revisor
“Condominio La Joya” consultas realizadas por implementado e instalado para
Usuarios Revisión administrador
automatizando ser puesta en producción.
(condominio)
procesos, el cual
facilitara los reportes.
Observación el número total de
COMPONENTES / -Clasificación de copropietarios e inquilinos que Que los miembros del directorio
ingresos/egresos Realizando esquemas, y la
RESULTADOS
Determinar el flujo viven en el edificio. no sean cambiados ya que
obtención de datos.
adecuado dinero La revisión de los registros ellos tienen entendido
contables del administrador

5
 Estudiar el flujo de Autorización por parte del
información de los
directorio para la revisión dela
grupos(copropietarios
e inquilinos) documentación a detalle.
ACTIVIDADES Revisión de talonarios Verificación de talonarios de
pagos de copropietarios e Obteniendo datos para la
de pagos
inquilinos. alimentación de la base de
Verificación de los Verificación de registros de
datos.
bienes de los propiedad
copropietarios

6
1