Sistema de Administracion de Condominios basados en agentes de software

AÑO DE LA INTEGRACION NACIONAL Y EL RECONOCIMIENTO DE NUESTRA DIVERSIDAD
ANALISIS Y DISEÑO DE UN SISTEMA DE ADMINISTRACION DE
CONDOMINIOS BASADO EN AGENTES DE SOFTWARE E INTERFACES
MOVILES
ASESOR :Espejo Briceño, Hugo
ALUMNOS : De La Barra López, Arturo - 0921422
VelásquezRosazza, Leslie - 0921421

2 Centro de Investigación de Tesis en Ingeniería de Sistemas
INDICE
I. INTRODUCCION ...................................................................................................................... 9
1.1. Motivación y justificación ................................................................................................... 9
1.2. Antecedentes de la investigación...................................................................................... 10
1.2.1. Diagrama de Causo – Efecto..................................................................................... 14
1.3. Objetivos ........................................................................................................................... 14
1.4. Contribuciones del trabajo................................................................................................ 15
II. MARCO TEORICO.................................................................................................................. 15
2.1. Marco Metodológico......................................................................................................... 18
2.1.1. Metodología de análisis de software ......................................................................... 18
2.1.2. Metodología de desarrollo de software ..................................................................... 26
2.1.3. Agentes Inteligentes .................................................................................................. 27
2.2. Marco Tecnológico............................................................................................................ 29
2.3. Marco Metodológico del modelo de validación ............................................................... 31
2.3.1. Diagrama de Gantt .................................................................................................... 31
III. DISEÑO DE LA SOLUCION .............................................................................................. 31
3.1. Metodología a aplicar ....................................................................................................... 32
3.1.1. Análisis de la arquitectura......................................................................................... 32
3.2. Análisis del problema........................................................................................................ 34
3.3. Diseño de la propuesta ..................................................................................................... 38
3.3.1. Diagrama de Caso de Uso del Negocio..................................................................... 38
3.3.2. Objetivos del negocio................................................................................................ 39
3.3.3. Diagramas de Caso de Uso del sistema..................................................................... 39
3.3.4. Diagrama de Actividad (Realización de caso de uso)............................................... 67
3.3.5. Diagramas de Secuencia y Colaboración .................................................................. 68
3.3.6. Diagrama de Clases................................................................................................... 76
3.3.7. Diagrama de Componentes ....................................................................................... 78
3.3.8. Diagrama de Despliegue ........................................................................................... 79
IV. VALIDACIÓN DEL MODELO........................................................................................... 79

4.1. Instrumentos y técnicas .................................................................................................... 79
4.2. Diseño del prototipo ......................................................................................................... 80
4.2.1. Prototipo de acceso al portal ..................................................................................... 80
4.2.2. Página Principal del portal ........................................................................................ 81
4.2.3. Panel residente para dispositivos móviles................................................................. 82
4.2.4. Panel administrativo y asistente virtual..................................................................... 83
4.2.5. Prototipo de generación de cuotas por consumo de servicio de agua para móviles.. 85
4.2.6. Módulo de registro de ingreso individual.................................................................. 86
4.2.7. Módulo de registro de pagos de terceros................................................................... 87
4.2.8. Módulo de registro de adelantos o anticipos............................................................. 88
4.2.9. Módulo de registro de egresos................................................................................... 88
4.2.10. Módulo de consulta de estado de cuenta por apartamento........................................ 89
4.2.11. Módulo de registro de apartamentos ......................................................................... 90
4.2.12. Módulo de registro de empleados ............................................................................. 91
4.2.13. Módulo de registro de vehículos ............................................................................... 91
4.2.14. Registrar Instalación.................................................................................................. 92
4.3. Análisis costo – beneficio.................................................................................................. 93
4.3.1. Costos de Inversión................................................................................................... 93
4.3.2. Beneficios Esperados ................................................................................................ 95
4.3.3. Análisis Financiero.................................................................................................... 96
V. CONCLUSIONES Y RECOMENDACIONES........................................................................ 97
5.1. Conclusiones...................................................................................................................... 97
5.2. Recomendaciones ............................................................................................................. 98
ANEXOS........................................................................................................................................... 99

INDICE DE FIGURAS
CAPITULO I
Figura I. 1 N° de quejas de propietarios por año............................................................................... 11
Figura I. 2 Deuda acumulada pendiente por año............................................................................... 12
Figura I. 3 Número de propietarios por condominio......................................................................... 12
Figura I. 4 Diagrama de causa – efecto o diagrama de pescado........................................................ 14
CAPITULO II
Figura II. 1 Fases de la metodología RUP. ....................................................................................... 19
Figura II. 2 Agente basado en utilidad. ............................................................................................. 28
Figura II. 3 Diagrama de Gantt. ........................................................................................................ 31
CAPITULO III
Figura III. 1 Arquitectura del sistema. .............................................................................................. 32
Figura III. 2 Diagrama de caso de uso del negocio........................................................................... 39
Figura III. 3 Objetivos del negocio. .................................................................................................. 39
Figura III. 4 Diagrama de caso de uso del sistema............................................................................ 40
Figura III. 5 Diagrama de caso de uso acceder al sistema. ............................................................... 41
Figura III. 6 Diagrama de caso de uso Consultar asistente virtual.................................................... 43
Figura III. 7 Diagrama de caso de uso Registrar Ingreso.................................................................. 45
Figura III. 8 Diagrama de caso de uso Registrar Pago Individual..................................................... 45
Figura III. 9 Diagrama de caso de uso Registrar Pago Terceros....................................................... 49
Figura III. 10 Diagrama de caso de uso Registrar adelantos o anticipos. ......................................... 51
Figura III. 11 Diagrama de caso de uso Registrar Egreso................................................................. 53
Figura III. 12 Diagrama de caso de uso Consultar Estado de Cuenta............................................... 55
Figura III. 13 Diagrama de caso de uso Registrar Apartamento. ...................................................... 56
Figura III. 14 Diagrama de caso de uso Registrar Empleado............................................................ 58
Figura III. 15 Diagrama de caso de uso Registrar Vehículo. ............................................................ 60
Figura III. 16 Diagrama de caso de uso Registrar Instalación. ......................................................... 62
Figura III. 17 Diagrama de caso de uso Registrar Presupuesto......................................................... 64
Figura III. 18 Diagrama de caso de uso Publicar Articulo Portal. .................................................... 66
Figura III. 19 Diagrama de actividades del sistema. ......................................................................... 68
Figura III. 20 Diagrama de Secuencia Registrar Egreso................................................................... 69
Figura III. 21 Diagrama de Colaboración Registrar Egreso.............................................................. 70

Figura III. 22 Diagrama de Secuencia Registrar Apartamento. ........................................................ 70
Figura III. 23 Diagrama de Secuencia Registrar Empleado.............................................................. 71
Figura III. 24 Diagrama de Colaboración Registrar Empleado......................................................... 71
Figura III. 25 Diagrama de Secuencia Registrar Ingreso Individual................................................. 72
Figura III. 26 Diagrama de Secuencia Registrar Instalación............................................................. 73
Figura III. 27 Diagrama de Colaboración Registrar Instalación. ...................................................... 73
Figura III. 28 Diagrama de Secuencia Registrar Residente. ............................................................. 74
Figura III. 29 Diagrama de Secuencia Registrar Vehículo................................................................ 75
Figura III. 30 Diagrama de Colaboración Registrar Vehículo. ......................................................... 76
Figura III. 31 Diagrama de Clases. ................................................................................................... 77
Figura III. 32 Diagrama de componentes.......................................................................................... 78
Figura III. 33 Diagrama de Despliegue............................................................................................. 79
CAPITULO IV
Figura IV. 1 Prototipo de acceso al portal......................................................................................... 81
Figura IV. 2 Página principal del portal............................................................................................ 82
Figura IV. 3 Panel residente para dispositivos móviles. ................................................................... 83
Figura IV. 4 Panel administrativo y asistente virtual. ....................................................................... 84
Figura IV. 5 Prototipo de generación de cuotas por consumo de servicio de agua para móviles. .... 86
Figura IV. 6 Módulo de registro de ingreso individual..................................................................... 87
Figura IV. 7 Módulo de registro de pago de terceros........................................................................ 87
Figura IV. 8 Módulo de registro de adelantos o anticipos. ............................................................... 88
Figura IV. 9 Módulo de registro de egresos...................................................................................... 89
Figura IV. 10 Módulo de consulta de estado de cuenta por apartamento. ........................................ 90
Figura IV. 11 Módulo de registro de apartamentos........................................................................... 90
Figura IV. 12 Módulo de registro de empleados............................................................................... 91
Figura IV. 13 Módulo de registro de vehículos................................................................................. 92
Figura IV. 14 Módulo de registro Instalación................................................................................... 92
Figura IV. 15 Análisis Financiero..................................................................................................... 97

INDICE DE TABLAS
CAPITULO I
Tabla I. 1 N° de quejas promedio por año......................................................................................... 11
Tabla I. 2 Deuda acumulada pendiente por año................................................................................ 12
Tabla I. 3 Número de propietarios por condominio. ......................................................................... 13
CAPITULO III
Tabla III. 1 Diferenciación con otras investigaciones similares........................................................ 35
Tabla III. 2 Recursos de hardware requeridos................................................................................... 38
Tabla III. 3 Recursos de software requeridos.................................................................................... 38
CAPITULO IV
Tabla IV. 1 Costos de personal. ........................................................................................................ 93
Tabla IV. 2 Costos de equipo............................................................................................................ 94
Tabla IV. 3 Costos de software......................................................................................................... 94
Tabla IV. 4 Beneficios tangibles del proyecto. ................................................................................. 95

DEDICATORIA
A mi madre, quees mi ángel de la guarda que
me cuida desde el cielo y que es el combustible
que me impulsó para seguir adelante y
conseguir mis metas, por sus valores,
consejos y motivación constante que me
permitieron ser una persona de bien, pero
más que nada, por su amor.
A mi padre,por la confianza que deposito en
mí, por los ejemplos de perseverancia y
constancia que lo caracterizan, por ser mi
mayor confidente y mejor amigo.
Arturo
A mi madre por los consejos y el impulso
por seguir adelante y ser una persona de
bien, con valores.
A mi padre por el esfuerzo realizado que
está haciendo por mí, por los ejemplos que

me da para que pueda estudiar y
conseguir una profesión.
Leslie
AGRADECIMIENTOS
A dios, por permitirme llegar hasta este
punto y por no abandonarme a pesar de
haberle fallado en muchas ocasiones y
principalmente por permitirme hacer mi
sueño realidad.
A mis padres les agradezco por quererme tal
como soy, por todo su tiempo y llamadas de
atención espero ser su orgullo.
A mi pareja, ya que con ella inicie esta
aventura y tengo la suerte de terminarla
también junto a ella, por su gran apoyo y
compresión muchas gracias.
A mis tutores, ya que cada uno de ellos
colaboro conmigo para alcanzar este
objetivo.

Arturo
A nuestros profesores por todo lo que nos
han enseñado y aconsejado.
A mis padres por quererme tal como soy,
por su tiempo y brindarme su apoyo.
Leslie
I. INTRODUCCION
1.1. Motivación y justificación
Esta investigación surge a partir de la búsqueda de propuestas tecnológicas para resolver
los crecientes problemas vinculados a la administración de condominios y también por la
necesidad de las empresas administradoras de una herramienta que permita interactuar
con los propietarios de los condominios a su cargo, por lo que es necesario determinar
qué factores influyen parala aceptación y satisfacción de los vecinos de condominios en
el Perú, en beneficio de las empresas administradoras.
La administración de condominios contempla aspectos de gestión administrativa,
asesoría legal, sistema de recaudación, gestión de cobranza,así como la gestión contable
y financiera. Los propietarios de condominios exigen exactitud, prontitud, eficiencia y
transparencia en la gestión de las empresas administradoras siendo la ausencia de alguno
de estos factores determinante para el fracaso o éxito de un administrador.
La cobranza es un problema ya que al llevar un control rudimentario, poco ordenado y
poco eficiente de la información se utiliza mucho tiempo en el cálculode cuotas
haciéndose necesario el uso de más recursos puesto que se necesitan varias personas
para realizar estos procesos ocasionando mayores gastos administrativos y generando
desconfianza e insatisfacción en los propietarios del condominio.

La morosidad también es un problema ya que afecta directamente al presupuesto
necesario para cubrir los gastos generados de la administración por lo tanto bajar el
porcentaje de morosidad es un factor de solución del problema.
Un factor importante para maximizar la calidad de servicio y cuya importancia no es
tomada con la seriedad debida es la existencia de un asistente virtual permanente que
tenga la capacidad de brindar la información requerida, solucionar consultas, facilitar
accesos y realizar investigaciones en internet.
La solución propuesta combina las mejores características de sistemas similares en el
mercado además de permitir la interacción del usuario con el sistema a través de agentes
de software y también por medio de dispositivos móviles en cualquier momento y en
cualquier lugar donde éste se encuentre, optimizando la utilización de recursos y
satisfaciendo los requerimientos de los usuarios; convirtiéndose así en la mejor opción
para empresas administradoras de condominios.
1.2. Antecedentes de la investigación
a. Volúmenes de Información (del negocio, de los clientes, años anteriores,
mercado local, mercado global, si aplica, información estadística)
En la Figura I.1 se muestra un cuadro evolutivo de la cantidad de quejas de los
propietarios recibidas en la administración por año, desde el año 2009 que la
empresa Lares administra el condominio los viñedos, ubicado en la avenida
Roosevelt distrito de Santiago de Surco.

Figura I. 1 N° de quejas de propietarios por año.
N° DE QUEJAS
PROMEDIO POR AÑO
AÑO
153 2009
225 2010
251 2011
246 2012
Tabla I. 1 N° de quejas promedio por año.
Se estima que para finales del año 2013 el número de quejas de los propietarios en
el condominio se reduzcan en un %70(Representan las quejas relacionadas con la
administración, el 30% restante son quejas de convivencia entre propietarios) con el
uso del sistema de administración de condominios, basado en agentes de software.
En la Figura I.2 se muestra el monto de deuda acumulada pendiente por año desde
el año 2009 que la empresa lares asumió la administración del condominio los
viñedos de surco
0
50
100
150
200
250
300
2009 2010 2011 2012
N° de quejas de propietarios por año
N° de quejas de propietarios

Figura I. 2 Deuda acumulada pendiente por año.
Año Monto (S/.)
2009 12550
2010 18560
2011 19400
2012 3500
Tabla I. 2 Deuda acumulada pendiente por año.
La Figura I.3 indica el número de propietarios por condominio administrado por la
empresa lares.
Figura I. 3 Número de propietarios por condominio.
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
2009 2010 2011 2012
Monto(S/.)
0
50
100
150
Cantidad
Chart Title
Lelevage
Angel azul
Capelo
La mar
Parque

Condominio N° propietarios
Lelevage 136
Ángel azul 145
Capelo 226
La mar 119
Parque 99
Tabla I. 3 Número de propietarios por condominio.
Una administración deficiente disminuye la rentabilidad de este negocio. Si se deja
deteriorar el inmueble por falta de planes adecuados de mantenimiento, a la larga las
reparaciones y desperfectos fortuitos saldrán más caros, lo que también conduce a una mala
convivencia vecinal. El factor principal para brindar un manejo de calidad en la
administración de edificios de departamentos o de condominios es la cobranza.
En general, se tiene que llevar a cabo una supervisión constante de las instalaciones y áreas
comunes, reportando periódicamente el estado en que se encuentran. También se
recomienda elaborar un presupuesto de reparaciones y de las necesidades de mantenimiento
mayor. Además, es altamente aconsejable ofrecer diferentes formas de pago (efectivo,
cheque, depósito) y hasta descuentos por pago adelantado.
Las fechas de pago y el monto de las cuotas que cada residente debe cubrir tendrán que
quedar por escrito en el reglamento interno del condominio, edificio o conjunto residencial.
Además, es necesario sentar los acuerdos en cuanto al uso de áreas comunes (jardines,
salones de usos múltiples y alberca, entre otros), estacionamiento para las visitas de los
dueños, ruidos, invitados en ausencia del dueño, etc.
Al dividirse entre todos los ocupantes, también existe el inconveniente de que algunos
condóminos se quejan de las altas cuotas por el consumo de luz en áreas comunes como son
los pasillos, jardines, estacionamiento y caseta de vigilancia, por lo que en estos casos el
reglamento debe especificar también el ahorro de energía. En cuanto a las juntas breves que
se deben celebrar por lo menos cada uno o dos meses para informar a los inquilinos el
estado que guarda la administración, Mercedes explica que lo ideal es establecer una multa
por inasistencia (ella penaliza con $100 la falta), ya que hay algunas personas que no
asisten porque adeudan y tienen pena de que se les cobre frente a los demás.
Adicionalmente, los contratos que se firman con los condominios tienen una duración de
uno o dos años. Al final del ejercicio el Consejo de Administración -o Junta de Vecinos-
evaluará el desempeño de tu despacho; por eso es recomendable mantener informados a los
clientes respecto a la calidad en la prestación del servicio. Para hacerlo, entrega bitácoras o
reportes mensuales con las labores extras que se solicitaron durante el período de
administración, apoyos que valorarán los vecinos al momento de renovar el contrato.

1.2.1. Diagrama de Causo – Efecto
Figura I. 4 Diagrama de causa – efecto o diagrama de pescado.
1.3. Objetivos
Objetivo general:
 Diseñar un sistema de administración de condominios, que permita gestionar
las cobranzas, actualizar saldos de deuda, proponer pagos diferidos, según
casos particulares con diseño de interfaces móviles y basado entre otros
aspectos innovadores en el uso de agentes de software para negociaciones,
solución de problemas y dudas tanto de propietarios como de usuarios de
administración, demostrando que el uso de agentes de software para empresas
administradoras constituye una herramienta muy rentable que optimiza y
reduce costos tanto operativos como administrativos y que genera confianza y
satisfacción en los propietarios.
Objetivos específicos:
 Optimizar el proceso de generación de cuotas de residentes por medio de
interfaces móviles por internet.
 Diseñar un modelo de agente inteligente que sea capaz de facilitar información
y solucione problemas relacionados con la usabilidad del sistema, además de
negociar operaciones relacionadas con el cobro a propietarios deudores y/o
morosos definiendo intereses de mora, sanciones o plazos para el pago de
cuotas.

 Diseñar reportes detallados de ingresos, egresos, balance general, morosos,
cuentas por cobrar exportables a diferentes formatos para imprimirlos,
guardarlos o enviarlos por correo electrónico además de realizar proyecciones
de los estados financieros.
1.4. Contribuciones del trabajo
Esta investigación busca entregar a comunidades de edificios y condominios, una
herramienta de administración profesional, confiable, efectiva, rápida y exacta, basada
entre otros aspectos innovadores en el uso intensivo de tecnologías de información (TI)
atendiendo a un problema.
Para las empresas administradoras de condominios para las cuales fue diseñada la
solución que se presenta en esta tesis, las aportaciones que se obtienen se manifiestan en
los siguientes aspectos:
 Agilización de la gestión de cobranzas permitiendo a los propietarios consultar
recibos, estado de cuenta y notificar pagos realizados, desde cualquier parte del
mundo.
 Manejo transparente de las finanzas debido a que los miembros del
condominio pueden revisar en tiempo real los estados de Ingresos y de
Egresos.
 Reducción de gastos operativos gracias a los diseños de interfaces móviles y a
los agentes inteligentes incluidos de la solución.
 Garantizar la Integridad y disponibilidad en todo momento de la información
para administradores y propietarios.
II. MARCO TEORICO
Generalidades del Condominio
La palabra “Condominio”, en Derecho Civil, consiste en la situación en la que la propiedad de
una cosa es compartida por dos o más personas. Por extensión, algunos autores denominan así
a un inmueble bajo el régimen de propiedad horizontal.
En el condominio es importante regular la forma en que los copropietarios van a tomar las
decisiones con respecto a la propiedad que tienen en común. A tal efecto, pueden darse
relaciones de mancomunidad o de solidaridad. También es importante regular los casos de
extinción de la copropiedad y disolución de la comunidad de bienes.
La Propiedad Horizontal, en su origen, no deja de ser una especial forma de copropiedad que
se establece entre los propietarios de un inmueble dividido en pisos. En el mismo, coexisten
elementos privativos, propios (los pisos, las plazas de parking, los trasteros) con otros
elementos escaleras (escaleras, jardines, ascensores, portales, etc…). El modo en que se

regulan dichas relaciones de propiedad, de copropiedad y de vecindad, son los que se han dado
en denominar Propiedad Horizontal.
Así pues, junto con el piso, el derecho de propiedad horizontal incluye un porcentaje de
propiedad sobre los elementos comunes de todos los propietarios de pisos en el edificio en
cuestión. Tales elementos se consideran necesarios para el adecuado uso y disfrute del piso, y
la cuota que exista sobre ellos es completamente inherente a la propiedad del piso, siendo
inseparable de ésta.
A la propiedad horizontal también se le llama condominio y ley de residencia permanente.
Se entiende por:
ADMINISTRADOR CONDÓMINO: Es el condómino de la unidad de propiedad privativa,
que no siendo administrador profesional, sea nombrado Administrador por la Asamblea
General.
ADMINISTRADOR PROFESIONAL: Persona física o moral, que demuestre capacidad y
conocimientos en administración de condominios que es contratado por la Asamblea General.
ÁREAS Y BIENES DE USO COMUN: Son aquellos que pertenecen en forma proindiviso a
los condóminos y su uso estará regulado por esta Ley, su Reglamento, la Escritura Constitutiva
y el Reglamento Interno.
ASAMBLEA GENERAL: Es el órgano máximo del condominio, que constituye la máxima
instancia en la toma de decisiones celebrada en los términos de la presente Ley, su
Reglamento, Escritura Constitutiva y el Reglamento Interno, se expresan y discuten asuntos de
interés propio y de interés común.
CONDOMINIO: Inmueble cuya propiedad pertenece proindiviso a varias personas, que reúne
las condiciones y características establecidas en el Código Civil para el Distrito Federal.
CONDÓMINO: Persona física o moral, propietaria de una o más unidades de propiedad
privativa y, para los efectos de esta Ley, y su Reglamento, a la que haya celebrado contrato en
virtud del cual, de cumplirse en sus términos, llegue a ser propietario bajo el régimen de
propiedad en condominio.
COMITÉ DE VIGILANCIA: Órgano de control y vigilancia integrado por condóminos electos
en la Asamblea General, cuyo cometido entre otros, es vigilar, evaluar y dictaminar el puntual
desempeño de las tareas del Administrador, así como la ejecución de los acuerdos y decisiones
tomados por la Asamblea General en torno a todos los asuntos comunes del condominio.
COMITÉS: Están formados por condóminos o poseedores de unidades de propiedad privativa
que se organiza para realizar actividades que atienden algunos servicios complementarios
ambientales, preventivos contra siniestros y promueven la cultura condominal en beneficio de
la comunidad. Son instancias de autogestión, atemporales y no obligatorias, su número
integrante varía, y se conforman entorno a objetivos concretos.
CUOTA ORDINARIA: Cantidad monetaria acordada por la Asamblea General, para sufragar
los gastos de administración, mantenimiento, de reserva, operación y servicios no
individualizados de uso común.
CUOTA EXTRAORDINARIA: Cantidad monetaria acordada por la Asamblea General para
sufragar los gastos imprevistos o extraordinarios.
MOROSO: Es el condómino o poseedor que no ha cumplido con su obligación de pagar dos
cuotas ordinarias o una extraordinaria en el plazo establecido por la Asamblea General.
ALICUOTA: Es el porcentaje de contribución que posee una unidad en la comunidad como un
todo. Dicho porcentaje de prorrateo lo designa el arquitecto de la obra y en general sirve para
distribuir los gastos comunes para cada unidad.

Disposiciones que regulan los condominios
 Ley N° 27157 de regularización de edificaciones, del procedimiento para la declaratoria
de fábrica y del régimen de unidades inmobiliarias de propiedad exclusiva y de
propiedad común(Ver Anexo 1).
 Escritura constitutiva del régimen de propiedad en condominio.(Acta constitutiva)
 Reglamento interno del condominio. (Ver Anexo 2)
 Escritura traslativa de dominio.(Ver Anexo 4)
 Acuerdos de la asamblea de condóminos. (Ver Anexo 3)
¿Quién puede ser administrador?
Una persona o compañía externa que tenga experiencia en la administración de condominios.
¿Es obligatorio ser administrador?
La ley no establece que sea obligatorio ser administrador y por consecuencia no precisa
sanción alguna para aquel condómino que rechace el cargo. Sin embargo, los condóminos en
Asamblea pueden adoptar otras determinaciones sobre el particular e inclusive, establecer
disposiciones relativas en el reglamento interno.
Principales atribuciones del administrador
 Recaudar las cuotas que les corresponden a los condóminos.
 Representar jurídicamente a los condóminos en las controversias que se susciten por las
áreas comunes.
 Vigilar los bienes del condominio y servicios.
 Ejecutar los acuerdos de la asamblea de condóminos.
 Llevar el libro de actas de los acuerdos de la asamblea.
¿Cuánto dura el encargo del administrador?
En el caso del administrador externo, la ley no señala el tiempo del encargo.
¿Qué es el comité de vigilancia y como se elige al Presidente J.D.?
Es un grupo de diez condóminos titulares, que tiene como principal atribución, vigilar que el
administrador cumpla con sus funciones. Está conformada por la totalidad de Presidentes de
cada Edificio, en el condominio son 10 en total. El Presidente es elegido en Asamblea, el voto
es a mano alzado por parte del propietario expresando el candidato de su preferencia. El
candidato contendiente perdedor puede ocupar la vicepresidencia si el Presidente electo lo
autoriza y ratifica la Asamblea.
Destino de las cuotas

Las cuotas de administración y mantenimiento financian las obras necesarias para mantener el
condominio en buen estado, lo que incluye la operación cotidiana, reparación y conservación
de las instalaciones, servicios generales y áreas comunes, habida cuenta del agua y energía
eléctrica que se consuman en estas áreas, pago de planillas, pago a proveedores. El fondo de
reserva se constituye para cubrir los gastos derivados de la adquisición de implementos y
maquinaria que se necesiten.
¿Es obligatorio el pago de cuotas?
Sí. Al acordar la Asamblea de Condóminos la cuota, todos los condóminos están obligados a
pagar la que les corresponda de acuerdo al porcentaje de indiviso que represente su unidad de
propiedad exclusiva. Como cada Edificio es autónomo en designar esta cuota de
mantenimiento.
Pago de cuotas
Con la falta de pago de dos cuotas ordinarias o una cuota extraordinaria, podrá ser objeto de
sanciones establecidas en el Reglamento Interno del Condominio. Los tesoreros de cada
edificio son responsables de este cobro, como así de su depósito en una cuenta bancaria.
Cuando excede de un año es materia de un juicio ejecutivo civil. Recuerde que el
administrador deberá entregarle a su solicitud, un estado de cuenta de su departamento y usted
dispondrá de un plazo de ocho días para formular observaciones.
Documentación indispensable del condómino que debe poseer un vecino
 Copia simple del acta constitutiva del condominio.
 Copia del reglamento.
 Escritura traslativa de dominio. (Título de propiedad)
 Ley de Propiedad Horizontal para el Perú.
Documentación indispensable del condominio
 Libro de actas de asamblea
 Acuse de recibo de las convocatorias a asamblea.
 Escritura constitutiva (con anexos) del régimen de propiedad en condominio.
 Copias simples de los estados de cuenta del condominio.
 Actas circunstanciadas de la entrega-recepción de administradores.
 Informes del comité de vigilancia.
 Inventario actualizado de los muebles, aparatos e instalaciones de propiedad común.
 Página web del Condominio.
2.1. Marco Metodológico
2.1.1. Metodología de análisis de software
2.1.1.1. RUP

El Proceso Unificado de Rational (RationalUnifiedProcess en inglés, habitualmente
resumido como RUP) es un proceso de desarrollo de software y junto con el
Lenguaje Unificado de Modelado UML, constituye la metodología estándar más
utilizada para el análisis, implementación y documentación de sistemas orientados a
objetos.
RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización.
Principales características
 Forma disciplinada de asignar tareas y responsabilidades (quién hace
qué, cuándo y cómo)
 Pretende implementar las mejores prácticas en Ingeniería de Software
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
 Modelado visual del software
 Verificación de la calidad del software
Figura II. 1 Fases de la metodología RUP.
Fases

La estructura dinámica de RUP es la que permite que éste sea un proceso de
desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases
descritas anteriormente:
 Inicio (También llamado Incepción o Concepción)
 Elaboración
 Desarrollo (También llamado Implementación, Construcción)
 Cierre (También llamado Transición)
Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del
proyecto con los patrocinadores, identificar los riesgos asociados al proyecto,
proponer una visión muy general de la arquitectura de software y producir el plan
de las fases y el de iteraciones posteriores.
Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que
permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se
realiza la especificación de los casos de uso seleccionados y el primer análisis del
dominio del problema, se diseña la solución preliminar.
Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del
sistema, para ello se deben clarificar los requisitos pendientes, administrar los
cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.
Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible
para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas
de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se
debe verificar que el producto cumpla con las especificaciones entregadas por las
personas involucradas en el proyecto
2.1.1.2. UML
Lenguaje Unificado de Modelado (LUM o
UML, por sus siglas en inglés,
UnifiedModelingLanguage) es el lenguaje
de modelado de sistemas software más
conocido y utilizado en la actualidad; está
respaldado por el OMG (Object
Management Group). Es un lenguaje
gráfico para visualizar, especificar,
construir y documentar un sistema. UML
ofrece un estándar para describir un
"plano" del sistema (modelo), incluyendo aspectos conceptuales tales como
procesos de negocio, funciones del sistema, y aspectos concretos como expresiones
de lenguajes de programación, esquemas de bases de datos y compuestos
reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o
para describir métodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar
soporte a una metodología de desarrollo de software (tal como el Proceso Unificado
Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad
de una utilización en un requerimiento. Mientras que, programación estructurada, es
una forma de programar como lo es la orientación a objetos, sin embargo, la
programación orientada a objetos viene siendo un complemento perfecto de UML,
pero no por eso se toma UML sólo para lenguajes orientados a objetos.
 Casos de uso
Un caso de uso es una descripción de los pasos o las actividades que deberán
realizarse para llevar a cabo algún proceso. Los personajes o entidades que
participarán en un caso de uso se denominan actores.En el contexto de ingeniería
del software, un caso de uso es una secuencia de interacciones que se desarrollarán
entre un sistema y sus actores en respuesta a un evento que inicia un actor principal
sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la
comunicación y el comportamiento de un sistema mediante su interacción con los
usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación
entre los actores y los casos de uso en un sistema. Una relación es una conexión
entre los elementos del modelo, por ejemplo la especialización y la generalización
son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los
requerimientos del sistema al mostrar cómo reacciona a eventos que se producen en
su ámbito o en él mismo.
Los más comunes para la captura de requisitos funcionales, especialmente con el
desarrollo del paradigma de la programación orientada a objetos, donde se
originaron, si bien puede utilizarse con resultados igualmente satisfactorios con
otros paradigmas de programación.

Notación de Caso de uso
 Diagrama de clases
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de
un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los
diagramas de clases son utilizados durante el proceso de análisis y diseño de los
sistemas, donde se crea el diseño conceptual de la información que se manejará en
el sistema, y los componentes que se encargaran del funcionamiento y la relación
entre uno y otro.
Ejemplo de diagrama de clases
 Diagrama de colaboración
El diagrama de colaboración es un tipo de diagrama de interacción cuyo objetivo es
describir el comportamiento dinámico del sistema de información mostrando cómo

interactúan los objetosentre sí, es decir, con qué otros objetos tiene vínculos o
intercambia mensajes un determinadoobjeto.
Un diagrama de colaboración muestra la misma información que un diagrama de
secuenciapero de forma diferente. En los diagramas de colaboración no existe una
secuencia temporal en eleje vertical; es decir, la colocación de los mensajes en el
diagrama no indica cuál es el orden en elque se suceden. Además, la colocación de
los objetos es más flexible y permite mostrar de formamás clara cuáles son las
colaboraciones entre ellos. En estos diagramas la comunicación entreobjetos se
denomina vínculo o enlace (link) y estará particularizada mediante los mensajes
queintercambian.
Ejemplo de diagrama de colaboración
 Diagrama de secuencia
En un diagrama de secuencia se indicarán los módulos o clases que forman parte
del programa y las llamadas que se hacen en cada uno de ellos para realizar una
tarea determinada.
Se realizan diagramas de secuencia para definir acciones que se pueden realizar en
la aplicación en cuestión. Así, en el caso de una aplicación para jugar al ajedrez, se
podrían realizar diagramas de secuencia para “jugar una partida” o bien para
acciones más específicas como “mover pieza”.

Ejemplo de diagrama de secuencia
 Diagrama de componentes
Un componente es una unidad modular que puede reemplazarse en su propio
entorno. Sus elementos internos quedan ocultos, pero tiene una o varias interfaces
proporcionadas bien definidas a través de las cuales se puede obtener acceso a sus
funciones. Un componente también puede tener interfaces necesarias. En una
interfaz necesaria, se definen las funciones o servicios de otros componentes que
son necesarios. Mediante la conexión de las interfaces proporcionadas y las
interfaces necesarias de distintos componentes, puede construirse un componente
mayor. Un sistema de software completo se puede concebir como un componente.
El uso de diagramas de componentes tiene algunas ventajas:
Concebir el diseño atendiendo a los bloques principales ayuda al equipo de
desarrollo a entender un diseño existente y a crear uno nuevo.
Al pensar en el sistema como una colección de componentes con interfaces
proporcionadas y necesarias bien definidas, se mejora la separación entre los
componentes. Esto, a su vez, facilita la comprensión y los cambios cuando se
modifican los requisitos.
Puede utilizar un diagrama de componentes para representar el diseño con
independencia del lenguaje o plataforma que el diseño utiliza o va a utilizar.

Ejemplo de diagrama de componentes
 Diagrama de despliegue
El Diagrama de Despliegue es un diagrama que se utiliza para modelar el hardware
utilizado en las implementaciones de sistemas y las relaciones entre sus
componentes.
Describen la topología del sistema la estructura de los elementos de hardware y el
software que ejecuta cada uno de ellos.
Los diagramas de despliegue representan a los nodos y sus relaciones. Los nodos
son conectados por asociaciones de comunicación tales como enlaces de red,
conexiones TCP/IP, microondas, etc.
Ejemplo de diagrama despliegue

2.1.2. Metodología de desarrollo de software
2.1.2.1. Programación Orientada a Objetos
La programación orientada a objetos o POO es un paradigma de programación que
usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos.
Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y
encapsulamiento. En la actualidad, existe variedad de lenguajes de programación
que soportan la orientación a objetos.
Los objetos son entidades que tienen un determinado estado, comportamiento
(método) e identidad:
 El estado está compuesto de datos, será uno o varios atributos a los que
se habrán asignado unos valores concretos (datos).
 El comportamiento está definido por los métodos o mensajes a los que
sabe responder dicho objeto, es decir, qué operaciones se pueden realizar
con él.
 La identidad es una propiedad de un objeto que lo diferencia del resto,
dicho con otras palabras, es su identificador (concepto análogo al de
identificador de una variable o una constante).
Un objeto contiene toda la información que permite definirlo e identificarlo frente a
otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma
clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los
objetos disponen de mecanismos
de interacción llamados métodos,
que favorecen la comunicación
entre ellos. Esta comunicación
favorece a su vez el cambio de
estado en los propios objetos. Esta
característica lleva a tratarlos
como unidades indivisibles, en las
que no se separa el estado y el
comportamiento.
Los métodos (comportamiento) y atributos (estado) están estrechamente
relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase
requiere de métodos para poder tratar los atributos con los que cuenta. El
programador debe pensar indistintamente en ambos conceptos, sin separar ni darle
mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de
crear clases contenedoras de información por un lado y clases con métodos que
manejen a las primeras por el otro. De esta manera se estaría realizando una

programación estructurada camuflada en un lenguaje de programación orientado a
objetos.
2.1.2.2. PHP
PHP es un lenguaje de programación interpretado o framework para HTML,
diseñado originalmente para la creación de páginas web dinámicas. Se usa
principalmente para la interpretación del lado del servidor (server-side scripting)
pero actualmente puede ser utilizado desde una interfaz de línea de comandos o en
la creación de otros tipos de programas incluyendo aplicaciones con interfaz
gráfica.
Permite la conexión a diferentes tipos de servidores de bases de datos tales como
MySQL, PostgreSQL, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird y
SQLite.
PHP también tiene la capacidad de ser
ejecutado en la mayoría de los sistemas
operativos, tales como Unix (y de ese tipo,
como Linux o Mac OS X) y Microsoft
Windows, y puede interactuar con los
servidores de web más populares ya que
existe en versión CGI, módulo para Apache,
e ISAPI.
PHP es una alternativa a las tecnologías de Microsoft ASP y ASP.NET (que utiliza
C# y Visual Basic .NET como lenguajes), a ColdFusion de la empresa Adobe, a
JSP/Java y a CGI/Perl. Aunque su creación y desarrollo se da en el ámbito de los
sistemas libres, bajo la licencia GNU, existe además un entorno de desarrollo
integrado comercial llamado Zend Studio. CodeGear (la división de lenguajes de
programación de Borland) ha sacado al mercado un entorno de desarrollo integrado
para PHP, denominado 'Delphi for PHP. También existen al menos un par de
módulos para Eclipse, uno de los entornos más populares.
2.1.3. Agentes Inteligentes
Un agente inteligente(Ver anexo 6), es una entidad capaz de percibir su entorno,
procesar tales percepciones y responder o actuar en su entorno de manera racional, es
decir, de manera correcta y tendiendo a maximizar un resultado esperado. Es capaz de

percibir su medioambiente con la ayuda de sensores y actuar en ese medio utilizando
actuadores (elementos que reaccionan a un estímulo realizando una acción).
En este contexto la racionalidad es la característica que posee una elección de ser
correcta, más específicamente, de tender a maximizar un resultado esperado. Este
concepto de racionalidad es más general y por ello más adecuado que inteligencia (la
cual sugiere entendimiento) para describir el comportamiento de los agentes
inteligentes. Por este motivo es mayor el consenso en llamarlos agentes racionales.
Figura II. 2 Agente basado en utilidad.
Uso de Agentes Inteligentes
 Representación virtual. Se comunican en lenguaje natural y suplen a los
comerciales.
 Como asistentes personales. Nos ayudan como lo haría un ayudante.
 Negociador en mercados electrónicos. Localiza una subasta en internet,
aprende cómo va la oferta y realiza una compra por nosotros.
 Agente de búsqueda de información o rastreador. Rastrean en las redes de
ordenadores en busca de información solicitada. Son parametrizables por el
usuario aprenden de sus hábitos, rastrean la red e informan por correo
electrónico de novedades que consideran pueden ser de interés para el
usuario. Agente secreto o espía. Monitorizan una página Web identificada
previamente por el usuario e informan cuando se producen cambios en dicha
página
Tipos de Agentes Inteligentes

 Agente reactivo simple. Las acciones del agente se establecen en función a
una tabla de percepción - acción.
 Agentes basado en un modelo (estado interno.) Es un agente que almacena
sus percepciones anteriores, tiene memoria.
 Agentes basados en metas. Agente que combina propiedades de los dos
anteriores, pero que tiene una meta a la cual llegar. Necesita buscar el mejor
camino y planificar la secuencia de acciones.
 Agentes basados en utilidad. Son aquellos agentes que tienen múltiples
metas que cumplir, mide el grado de satisfacción del grado de cumplimiento
de sus metas.
Medio Ambiente
 Accesible y no accesible. Accesible, si los sensores detectan los aspectos que
requiere el agente para elegir una acción.
 Deterministas y no deterministas. Determinista, si el estado siguiente de un
ambiente se puede determinar completamente con el estado actual y las
acciones escogidas por el agente.
 Episódicos y no episódicos. Episódico, cuando la experiencia del agente se
divide en episodios, si es episódico, es más simple.
 Estáticos y dinámicos. Estático, si el medio ambiente no cambia mientras el
agente se encuentra deliberando.
 Discreto y continuo. Discreto, si existe una cantidad limitada de
percepciones y acciones distintas y distinguibles.
2.2. Marco Tecnológico
 Rational Rose Enterprise Edition
Rational Rose Enterprise Edition. Es una
herramienta CASE (Computer – Arded
Software Engineering), traducido al español
como Ingeniería Asistida por Computadora,
desarrollada por RationalCorporation
basada en el Lenguaje Unificado de
Modelación (UML), que permite crear los
diagramas que se van generando durante el
proceso de Ingeniería en el Desarrollo del
Software.
 Dreamweaver CS3

Adobe Dreamweaver CS3 es, por sobre todas las
cosas, la aplicación más utilizada para crear sitios
web, ya que cuenta con una serie de herramientas
muy completas y poderosas.
Básicamente, Adobe Dreamweaver CS3 puede
crear todo tipo de sitio y de aplicaciones web, ya
sea para ordenadores o dispositivos móviles y
portátiles. En sí, su integración con JavaScript es
un detalle no menor, debido a la integración
prácticamente total de este lenguaje con el HTML
y CSS (nativos en la Web).
Sin embargo, un aspecto que destaca a Adobe Dreamweaver CS3 del resto de los
editores es que resulta completamente personalizable en términos de entorno, ya
que el usuario tiene la chance de acomodarlo según sus gustos.
Requerimientos Indispensables para el Funcionamiento del Software:
Procesador de 64 bits.
512 MB de RAM.
 MysqlNavicat Premium
Navicat Premium es una herramienta de base
de datos con múltiples conexiones de
administración que le permite conectarse a
MySQL, SQL Server, SQLite, Oracle y
PostgreSQL simultáneamente en una única
aplicación, por lo que la administración de
base de datos para múltiples tipos de base de
datos es tan fácil.
Navicat Premium combina las funciones de
los miembros de otras Navicat y soporta la mayoría de las características de
MySQL, SQL Server, SQLite, Oracle y PostgreSQL incluyendo procedimientos
almacenados, Acontecimiento, Trigger, función, Ver, etc.
 WampServer
WampServer es un entorno de desarrollo
web para Windows con el que podrás crear
aplicaciones web con Apache, PHP y bases
de datos MySQLdatabase. También incluye
PHPMyAdmin y SQLiteManager para
manejar tus bases de datos rápidamente.

Provee a los desarrolladores con los cuatro elementos necesarios para un
servidor web: un Sistema Operativo (Windows), un manejador de base de datos
(MySQL), un software para servidor web (Apache) y un software de
programación script Web (PHP (generalmente), Python o PERL), debiendo su
nombre a dichas herramientas. Lo mejor de todo es que WAMP5 es
completamente gratuito. WAMP incluye, además de las últimas versiones de
Apache, PHP y MySQL, versiones anteriores de las mismas, para el caso de que
se quiera testear en un entorno de desarrollo particular.
2.3. Marco Metodológico del modelo de validación
2.3.1. Diagrama de Gantt
Figura II. 3 Diagrama de Gantt.
III. DISEÑO DE LA SOLUCION

3.1. Metodología a aplicar
Para el análisis, desarrollo e implementación de este sistema se utilizaran las
metodologías Proceso Unificado de Rational (RUP) junto con el lenguaje unificado de
modelado (UML), utilizando como herramienta de software el Rational Rose Enterprise
Edition.
Entre los diagramas a desarrollar podemos mencionar los siguientes:
 Diagrama de Casos de Uso
 Diagrama de Secuencia
 Diagrama de Colaboración
 Diagrama de Actividades
 Diagrama de Clases
 Diagrama de Componentes
 Diagrama de Despliegue
3.1.1. Análisis de la arquitectura
Figura III. 1 Arquitectura del sistema.

Cliente-Servidor.
Lo que podemos observar en primera instancia es que una aplicación Web sigueun
modelo cliente-servidor. Esto se debe a que se requiere un componente quehospede a
la aplicación y a todos sus componentes (servidor Web) y un componentecliente, en
nuestro caso un navegador Web. Una vez que tenemos estos doscomponentes
necesitamos un sistema de archivos en donde se van a almacenartodos los recursos
para la generación de contenido. El sistema de archivos puedealmacenar una gran
cantidad archivos multimedia (fotos, videos, audio, etc.),archivos XML y HTML,
necesarios para el funcionamiento de la aplicación.
Servidor de aplicaciones.
Para que podamos modelar aplicaciones Web dinámicas necesitamos agregar
componentes adicionales tales como un servidor de aplicaciones para permitir la
generación contenidos dinámicos tomando como base la arquitectura que estamos
proponiendo. Al agregar este nuevo componente necesitamos considerar las interfaces
que se necesitan incluir as como la relación con los componentes existentes.
Servidor de Bases de Datos.
Hasta ahora, con la arquitectura desarrollada podemos generar aplicacionesWeb con
contenido dinámico utilizando plantillas, archivos multimedia y recursosestáticos. Sin
embargo, apegándonos a las necesidades de las aplicacionesWeb que se desarrollan
actualmente, necesitamos considerar la gran cantidadde datos que se necesitan
manejar. Considerando esta necesidad agregamos anuestra arquitectura un servidor de
base de datos. Este componente nos permitira almacenar toda la información que la
aplicación necesita.
Servidor Multimedia.
Una de las características que consideramos importante es el manejo de contenidos
multimedia en las aplicaciones Web. Con el manejo de interfaces ricasy una mejora en
la presentación de las aplicaciones, se ha generado una enormedemanda de recursos
multimedia. Esta necesidad de las aplicaciones se haconvertido en un reto, debido a
que demandan el manejo de grandes cantidadesde recursos multimedia sin presentar
degradación en el rendimiento de laaplicación.
Servidor de Componentes.

Por otro lado, existen aplicaciones Web que necesitan permitir el acceso de terceros a
sus componentes Web de forma segura. La razón para permitir el acceso a los
componentes se debe a que muchas aplicaciones Web utilizan componentes
desarrollados por terceros.
Un Ejemplo muy común de este tipo de aplicaciones son los servicios de pronósticos
del clima. Una aplicación central es la encargada de obtener dichos datos y después
distribuirla a las demás aplicaciones por medio de un componente.
Otro ejemplo es el mercado de divisas, en donde solo la aplicación del banco central
tiene dicha información que posteriormente será distribuida a los demás por medio del
acceso a dicho componente.
La forma que hemos considerado más adecuada para cumplir con la necesidad de
brindar acceso a los componentes, es por medio de un servidor de componentes que se
encargara de hospedar solo los componentes que son utilizados por un tercero.
3.2. Análisis del problema
a. Análisis de la solución propuesta
i. Benchmarking
La solución comprende el análisis y diseño de un sistema que facilite realizar las
funciones administrativas inherentes a las empresas administradoras de
condominios, así como agilizar los procesos de cobranzas, facilitando el acceso a
sus servicios por medio del uso de asistentes virtuales y dispositivos móviles
ademásde recoger las características más resaltantes de los sistemas disponibles en
el mercado.
Diferenciación con otras investigaciones similares
Software Objetivo Diferencia
Valoriza2
(Venezuela)
Software para la
administración de
condominios.
El sistema propuesto además de tener la mayoría de las
características que presenta valoriza también podrá
actualizar la base de datos desde dispositivos móviles
además el sistema generara los asientos contables listos
para trabajar con sistemas como el concar o similares
facilitando así la contabilidad de la empresa. Finalmente
el sistema podrá actualizar la base de pagos en línea con
el banco con el que esté trabajando.
Infoven
(Venezuela)
Sistema administrativo que
permite auto Gestionar las
tareas administrativas de un
condominio de manera
sencilla, rápida y confiable.
Infoven es un sistema básico que registra el inventario
de las propiedades y calcula las cuotas por propietario,
el sistema que propongo añade utilidades de envió por
email o impresión de avisos de cobro, ofrece reportes
detallados de cobranza ingresos y egresos compatibles
con concar, actualización de la data a través de
dispositivos móviles, capacidad de actualizar la

información de pagos en línea con el banco con el que
se esté operando.
Habitaris Facilita la cobranza y
comunicación con tus
condóminos, manteniendo tu
información ordenada y
segura.
El sistema que se propone ofrece además la capacidad
de actualizar la información de pagos en línea con el
banco con el que se esté operando, además de la
herramienta para actualizar la información de consumo
de propietarios por medio de dispositivos móviles.
Vivook
(México)
Listo ya para manejar cuotas,
pagos, avisos, informes y
todo lo que un administrador
profesional necesita.
Vivook es uno de los sistemas para administración de
condominios más completos del mercado pero también
carece de alguna utilidad que le permita registrar la
información por medio de dispositivos móviles y no
utiliza agentes de software para maximizar tu
efectividad.
Siscond
(Venezuela)
Desarrollado para llevar de
una manera fácil la Gestión
de gastos y cobranzas de
condominios.
Siscond presenta casi las mismas características que el
sistema propuesto pero no optimiza el registro de la
información utilizando dispositivos móviles y tampoco
utiliza agentes de software para maximizar tu
efectividad.
Tabla III. 1 Diferenciación con otras investigaciones similares.
Entre las funciones que comprende este modelo se pueden mencionar las siguientes:
a) Registrar los egresospor período.
b) Generar los recibos de cada inmueble y enviarlos por correo electrónico,
c) Cálculo de Gastos Administrativos configurable
d) Impresión de Avisos de Cobro, Original y Copia
e) Estado de Cuenta de los residentes
f) Pagos Realizados
g) Obtener reportes detallados de cobranza, ingresos y egresos, exportables a
diferentes formatos para imprimirlos, guardarlos o enviarlos por correo
electrónico
h) Controlar cuotas, adeudos, pagos, ingresos y egresos del condominio o
edificio
i) Revisar el estado financiero real contra el presupuesto mensual y anual.
Además añade funciones exclusivas entre las cuales está el aprovechar la
tecnología de los dispositivos móviles para optimizar el cálculo y generación de
cuotas de los propietarios a través de la captura y actualización de la información
de consumo mensual de cada propietario. Adicionalmente permitirá controlar de
manera efectiva la contabilidad de la empresa ya que enviara la información
detallada de egresos e ingresos hacia el departamento de contabilidad lista para su
análisis.
ii. Alcances
El sistema de administración de condominios permitirá gestionar de manera eficaz:

 La información de los inmuebles y propietarios.
 Facilitar el acceso a la información, ya que también se creará un portal diseñado
para ser visualizado desde dispositivos móviles.
 Comunicación interactiva entre residentes y administración a través del portal
informativo del condominio.
 Acelerar el proceso de generación de cuotas de propietarios a través del uso de
dispositivos móviles
 Establecer el presupuesto anual y contrastarlo con el estado financiero real del
condominio.
 Información de egresos e ingresos tanto ordinarios como extraordinarios.
 Actualizar el estado de cuenta de cada cliente según lo recaudado.
 Control de gastos Administrativos del condominio.
 Impresión de documentos tales como avisos de cobro, estado de cuenta, pagos
realizados.
 Envío por correo electrónico de documentos tales como avisos de cobro, original
y copia, estados de cuenta, pagos realizados.
iii. Análisis funcional
El problema se da en el área de cobranzas de la empresa debido a la inexistente
automatización de procesos, se ven forzados a realizar de manera poco efectiva
produciendo demora en la gestión de cobranzas, generando así mayores gastos
administrativos y errores en el cálculo del presupuesto.
La solución propuesta permitirá administrar:
La información de los inmuebles y propietarios.
Cargar los gastos de un período, generar los recibos de cada inmueble.
Cálculo de Gastos Administrativos.
Impresión de Avisos de Cobro, Original y Copia, Estado de Cuenta, Pagos
Realizados.
Envío por correo electrónico de Avisos de Cobro, Original y Copia, Estados de
Cuenta, Pagos Realizados.
Cargar Gastos No Comunes.
iv. Etapas de la solución
Determinar el problema y plantear alternativas para su solución.
Análisis de requerimientos
Análisis y Diseño de la solución
Simular el uso del sistema con los usuarios involucrados. (Hasta aquí al final del
ciclo)
Desarrollo del software.
Pruebas en múltiples condominios.
Monitoreo y control de calidad del sistema.
b. Estudio de Viabilidad (Económica /Operativa / Técnica /Legal / Cultural / Política
/ Ética)

VIABILIDAD ECONOMICA
El estudio de viabilidad económica se analizara a detalle en el capítulo 4.3 en el análisis de
costo – beneficio.
VIABILIDAD OPERATIVA
La propuesta es viable operativamente, puesto que los usuarios directos e indirectos no
representan oposición al cambio, además mediante el uso del sistema los usuarios podrán
cubrir sus requerimientos y expectativas y tendrán la información exacta en forma oportuna y
confiable a través de interfaces amigables y fáciles de usar. Ello se encuentra sustentado en los
resultados de la simulación de uso del sistema por parte de los usuarios, quedando demostrado
que no tendrán inconvenientes para aprender a utilizarlo y si se da el caso tendrán la
posibilidad de recibir una capacitación más personalizada.
VIABILIDAD TECNICA
A continuación se realiza la caracterización con respecto al hardware, software y recursos
humanos que demanda la nueva aplicación con la finalidad de convertir al proyecto en algo
técnicamente factible.
Datos actuales disponibles
 Identificación del Sistema
Título: Análisis y diseño de un sistema de administración de condominios basado en
agentes de software e interfaces móviles.
 Recursos humanos involucrados
Número de Desarrolladores:Cuatro
Número de Asesores: Uno
Número de Usuarios: Indeterminado
 Recursos hardware
Número de computadoras de desarrollo:Cuatro
 Recursos Software
SistemaOperativo: Microsoft Windows XP, Microsoft Windows 2003 Server, Windows
7, Windows Vista.
Base de Datos: MYSQL
Recursos Hardware
El hardware requerido para la construcción del sistema de administración de condominios
basado en agentes de software e interfaces móviles son: 1 servidores Linux que aloje la
aplicación web, y dos computadoras personales para el desarrollo de la aplicación los mismos
que tendrán las siguientes características:

Nº CARACTERISTICAS S. OPERATIVO OBJETIVO RESPONSABLE
4
Pentium IV, Disco de
100 GB, Memoria
RAM 1GB.
Windows XP en
adelante
Documentación
Programación
Leslie Velásquez
Rosazza, Arturo De
La Barra López,
Mauricio Dávila,
Juan Castro
Tabla III. 2 Recursos de hardware requeridos.
Recursos Software
Nº PRODUCTO LICENCIAS TIPO
1
Servidor plataforma
Linux.
- Hosting
2 Mysql - Base de Datos
3 PHP - Programacion
4
Internet Explorer 8,
Mozilla Firefox,
Opera, Chrome.
- Navegador
5
Windows XP en
adelante
- SistemaOperativo
Tabla III. 3 Recursos de software requeridos.
VIABILIDAD LEGAL
La propuesta es viable legalmente ya que no atenta con ninguna norma legal vigente tanto en la
etapa de inversión como en la ejecución del proyecto ya que el software utilizado en la etapa de
desarrollo del proyecto al ser software de tipo open source (código abierto) no requiere de pago
de licencias.
3.3. Diseño de la propuesta
3.3.1. Diagrama de Caso de Uso del Negocio
En la “Figura III.2” se describen los procesos actuales del negocio, vinculados a su
campo de acción y como se benefician e interactúan los socios y clientes en estos
procesos.

Figura III. 2 Diagrama de caso de uso del negocio.
3.3.2. Objetivos del negocio
En la “Figura III. 3” se describen los objetivos de la empresa los cuales han sido
determinados previamente por los stakeholders y responsables del negocio.
Figura III. 3 Objetivos del negocio.
3.3.3. Diagramas de Caso de Uso del sistema

La “Figura III. 4” nos da una visión general de las funcionalidades del sistema
propuesto, en las que podemos visualizar a los actores principales del sistema y los
procesos que estos realizaran para la consecución de los objetivos propuestos.
Figura III. 4 Diagrama de caso de uso del sistema.
3.3.3.1. Diagrama de caso de uso Acceder al sistema

Figura III. 5 Diagrama de caso de uso acceder al sistema.
Caso de uso:Acceder al sistema
1. Nombre del Caso de Uso del Sistema Acceder_al_Sistema
2. Descripción del Caso de Uso
El Internauta (El administrador, residente o el empleado encargado del registro del consumo de
servicios de los propietarios) iniciará su ingreso validándosecomo Usuario y luego estará habilitado
para ingresar a visitar el portal, de acuerdo a su nivel de permisos podra ingresar en el panel
administrativo o en el panel residente. El administrador será el encargado de registrar a los usuarios y
empleados.
3. Actor(es)
Administrador, Residente, Empleado, Internauta.
4. Precondiciones
El administrador debe haber otorgado los accesos a los usuarios y empleados para el ingreso al portal.
5. Poscondiciones
El portal habilitara el panel informativo según los permisos de usuario logueado.
6. Flujo de eventos

Nro. Acción del Actor Respuesta del Sistema
1 El internauta entra a la dirección web del
portal.
Se muestra la página de acceso al portal.
2 El Internauta ingresa datos:
2.1.Código de residente o correo electrónico
de acceso.
2.2.Password.
El sistema valida los datos ingresados en cada
campo:
2.1.Valida el ingreso de caracteres numéricos.
2.2.Valida el ingreso de caracteres alfabéticos.
2.3.
3 El administrador presionará el botón
“Ingresar”.
Si el acceso es exitoso el sistema redirigirá a la
página principal del portal otorgando permisos
según sea el usuario logueado.
7. Requisito asociado (Funcional, No Funcional)
Funcional:
Acceso al portal.
No Funcional:
Disponibilidad del sistema.
3.3.3.2. Diagrama de caso de uso Consultar asistente virtual

Figura III. 6 Diagrama de caso de uso Consultar asistente virtual.
Caso de uso:Consultar asistente virtual
1. Nombre del Caso de Uso del Sistema Consultar_Asistente_Virtual
El Internauta (Administrador o residente del condominio) accede al sistema e inicia el asistente virtual
para solicitar alguna información.
3. Actor(es)
Administrador, Residente, Internauta.
4. Precondiciones
El Internauta deberá ingresar al portal usando su código de usuario o email y su contraseña.
5. Poscondiciones
El asistente virtual buscara coincidencias en su base de respuestas y posteriormente realizara una
acción.

6. Flujo de eventos
1 El internauta accede al sistema Se muestra la página de principal del portal.
2 El Internauta ingresa consulta y presiona
enviar.
El Asistente virtual buscara la información
solicitada en su base de datos y de encontrarla
mostrara la respuesta en el cuadro de
conversación, además dará la posibilidad de ver
más detalles acerca de la consulta o redirigirá al
usuario a la página consultada.
Funcional:
Acceso al portal.
No Funcional:
3.3.3.3. Diagrama de caso de uso Registrar Ingreso
La “Figura III. 7” menciona las distintas maneras de registrar un
ingreso o pago en el condominio, las cuales serán descritas
posteriormente.

Figura III. 7 Diagrama de caso de uso Registrar Ingreso.
3.3.3.4. Diagrama de caso de uso Registrar Pago individual
Figura III. 8 Diagrama de caso de uso Registrar Pago Individual.
Caso de uso: Registrar Pago Individual

1. Nombre del Caso de Uso del Sistema Registrar_Pago_Individual
El administrador va a registrar el pago por apartamento.
3. Actor(es)
Administrador
4. Precondiciones
El administrador debe de estar registrado en la BD.
5. Poscondiciones
Pago registrado.
6. Flujo de eventos
1 El administrador ingresa al módulo Registro
de Pago Individual.
El sistema muestra la interface del módulo.
2 El administrador ingresa datos:
2.3.Vivienda.
2.4.Monto.
2.5.Forma de pago
2.1.Referencia(Campo requerido en caso de
que la forma de pago sea diferente a
efectivo)
2.6.Fecha
2.7.Tipo de cuenta
2.8.Comentarios
campo:
“Registrar”.
El sistema registrará el pago de un apartamento
en la base de datos.
El sistema indicará que el registro fue exitoso.
Si faltara registrar algún campo, el sistema
alertará cual campo falta y no dejara registrar los
datos.

Funcional:
Registro de pago por apartamento.
No Funcional:
Caso de Uso: Registrar Pago Masivo
1. Nombre del Caso de Uso del Sistema Registrar_Pago_Masivo
El administrador va a registrar los pagos de diferente monto para cada apartamento.
3. Actor(es)
Administrador
4. Precondiciones
5. Poscondiciones
Pago registrado.
6. Flujo de eventos
1 El administrador ingresa al módulo Registro
de Pago diferente.
2.2.Importe.
2.3.Forma de pago
efectivo)
2.5.Fecha
2.6.Comentarios
2.7.Tipo de cuenta bancaria
campo:
2.2.Valida el ingreso de caracteres alfabético.

“Registrar”.
El sistema registrará el pago de un apartamento
en la base de datos.
datos.
Funcional:
No Funcional:
3.3.3.5. Diagrama de caso de uso Registrar Pago Terceros

Figura III. 9 Diagrama de caso de uso Registrar Pago Terceros.
Caso de Uso: Registrar Pago Terceros
1. Nombre del Caso de Uso del Sistema Registrar_Pago_Terceros
El administrador va a registrar los pagos por personas ajenas al condominio.
3. Actor(es)
Administrador
4. Precondiciones

5. Poscondiciones
Pago registrado.
6. Flujo de eventos
1 El administrador ingresa al módulo Agregar
pago a terceros.
2.8.Concepto.
2.9.Monto
2.10. Forma de pago
2.11. Referencia(Campo requerido en caso
de que la forma de pago sea diferente a
efectivo)
2.12. Fecha
2.13. Tipo de cuenta bancaria
2.14. Clasificación presupuestal
2.15. Fondo
2.16. Comentarios
campo:
“Agregar”.
El sistema registrará el pago a terceros en la base
de datos.
datos.
Funcional:
No Funcional:
3.3.3.6. Diagrama de caso de uso Registrar adelantos o anticipos

Figura III. 10 Diagrama de caso de uso Registrar adelantos o anticipos.
Caso de Uso: Registrar adelantos o anticipos
1. Nombre del Caso de Uso del Sistema Registrar_adelanto_anticipo
El administrador va a registrar los pagos adelantados o anticipos.
3. Actor(es)
Administrador
4. Precondiciones
5. Poscondiciones

6. Flujo de eventos
1 El administrador ingresa al módulo Registrar
adelanto o anticipo.
2.1.Selecciona torre. (Ej. Torre - 101)
2.2.Concepto.
2.3.Monto
2.4.Forma de pago
efectivo)
2.6.Fecha
2.7.Tipo de cuenta bancaria
2.8.Comentarios
campo:
“Aplicar”.
El sistema registrará el pago a terceros en la base
de datos.
datos.
Funcional:
No Funcional:
3.3.3.7. Diagrama de caso de uso Registrar Egreso

Figura III. 11 Diagrama de caso de uso Registrar Egreso.
1. Nombre del Caso de Uso del Sistema Registrar_Egresos
El administrador registrara los gastos del condominio. Ej.: Pagos de vigilancia, papelería, etc.
3. Actor(es)
Administrador
4. Precondiciones

5. Poscondiciones
6. Flujo de eventos
1 El Administrador ingresa al módulo Registrar
Egreso.
2 El Administrador ingresara datos (proveedor,
concepto, fecha, importe, forma de pago,
referencia, cuenta bancaria, clasificación
presupuestal, fondo, comentarios) y agregara
el egreso.
El sistema validara los datos ingresados y
mostrara en pantalla un mensaje diciendo que se
registró con éxito el egreso.
Funcional:
Registro de egreso.
No Funcional:
3.3.3.8. Diagrama de caso de uso Consultar Estado de Cuenta

Figura III. 12 Diagrama de caso de uso Consultar Estado de Cuenta.
1. Nombre del Caso de Uso del Sistema Consultar_Estado_Cta
El Residente va a consultar su Estado de Cuenta.
3. Actor(es)
Residente
4. Precondiciones
El Residente tiene que estar registrado en la BD.
5. Poscondiciones
6. Flujo de eventos
1 El Residente ingresa al módulo Consultar El sistema muestra la interface del módulo.

Estado de Cuenta.
2 El Residente selecciona el apartamento y año
y le da click en el botón “Consultar”.
El sistema le muestra el Estado de Cuenta (Saldo
inicial, Fecha, Tipo de pago, Concepto, Cargo,
Abono, Total, Saldo final).
Funcional:
No Funcional:
3.3.3.9. Diagrama de caso de uso Registrar Apartamento
Figura III. 13 Diagrama de caso de uso Registrar Apartamento.

Caso de uso: Registrar Apartamento
1. Nombre del Caso de Uso del Sistema Registrar_Apartamento
El Administrador va a registrar los apartamentos.
3. Actor(es)
Administrador
4. Precondiciones
El Administrador tiene que estar registrado en la BD.
5. Poscondiciones
6. Flujo de eventos
Apartamento.
2 El Administrador ingresara los datos
correspondientes.
El sistema valida los datos ingresados por
ejemplo: Si el campo es solo texto, el sistema
validara que el campo solo tenga caracteres
alfabéticos.
Si el campo es para ingresar números de teléfono,
el sistema validara que el campo solo tenga 7
caracteres numéricos.
3 El Administrador le da click en “Agregar”. El sistema grabara los datos ingresados en la BD.
Funcional:
Registro de apartamento.

No Funcional:
3.3.3.10. Diagrama de caso de uso Registrar Empleado
Figura III. 14 Diagrama de caso de uso Registrar Empleado.
Caso de uso: Registrar Empleado
1. Nombre del Caso de Uso del Sistema Registrar_Empleado
El Administrador va a registrar a los empleados(Vigilantes, personal de limpieza).
3. Actor(es)
Administrador

4. Precondiciones
5. Poscondiciones
6. Flujo de eventos
Empleados.
correspondientes del empleado.
El sistema valida los datos ingresados.
Funcional:
No Funcional:
3.3.3.11. Diagrama de caso de usoRegistrar Vehículo

Figura III. 15 Diagrama de caso de uso Registrar Vehículo.
Caso de uso: Registrar Vehículo
1. Nombre del Caso de Uso del Sistema Registrar_Vehiculo
El Administrador va a registrar los vehículos de los residentes.
3. Actor(es)
Administrador
4. Precondiciones
El Residente tiene que estar registrado en la BD.
5. Poscondiciones
6. Flujo de eventos

Empleados.
correspondientes del empleado.
Funcional:
No Funcional:
3.3.3.12. Diagrama de caso de uso Registrar Instalación

Figura III. 16 Diagrama de caso de uso Registrar Instalación.
Caso de uso: Registrar Instalación
1. Nombre del Caso de Uso del Sistema Registrar_Instalacion
El Administrador va a registrar una instalación (Cancha de Futbol, cancha de vóley, juegos para niños,
etc.).
3. Actor(es)
Administrador
4. Precondiciones
5. Poscondiciones

6. Flujo de eventos
Instalación.
2 El Administrador ingresara la descripción de
la instalación, el costo si el uso de la
instalación tiene algún costo, descripción,
reglamento y si esta en servicio o no esta en
servicio.
Funcional:
No Funcional:
3.3.3.13. Diagrama de caso de uso Registrar Presupuesto

Figura III. 17 Diagrama de caso de uso Registrar Presupuesto.
Caso de uso: Registrar Presupuesto
1. Nombre del Caso de Uso del Sistema Registrar_Presupuesto
El Administrador va a ingresar concepto, monto de cada mes y generar el total anual.
3. Actor(es)
Administrador
4. Precondiciones
5. Poscondiciones
6. Flujo de eventos

Presupuesto.
2 El Administrador ingresara el monto de cada
mes.
El sistema sumara el monto total de cada
concepto presupuestal.
Funcional:
No Funcional:
8. Prototipo
3.3.3.14. Diagrama de caso de usoPublicar Articulo Portal

Figura III. 18 Diagrama de caso de uso Publicar Articulo Portal.
Caso de uso: Publicar Articulo Portal
1. Nombre del Caso de Uso del Sistema Publicar_Articulo_Portal
El Internauta va a publica un artículoingresar título, descripción, adjuntar archivo, adjuntar imagen y
verificar opción de envío.
3. Actor(es)
Internauta
4. Precondiciones
5. Poscondiciones
6. Flujo de eventos

1 El Internauta ingresa al módulo Publicar
Articulo Portal.
2 El Internauta ingresara los datos
correspondientes.
El validara los datos ingresados.
3 El Internauta le da click en “Agregar”. El sistema grabara los datos ingresados en la BD.
Funcional:
No Funcional:
3.3.4. Diagrama de Actividad (Realización de caso de uso)

Figura III. 19 Diagrama de actividades del sistema.
3.3.5. Diagramas de Secuencia y Colaboración
3.3.5.1. Registrar Egreso

Figura III. 20 Diagrama de Secuencia Registrar Egreso.

Figura III. 21 Diagrama de Colaboración Registrar Egreso.
3.3.5.2. Registrar Apartamento
Figura III. 22 Diagrama de Secuencia Registrar Apartamento.

3.3.5.3. Registrar Empleado
Figura III. 23 Diagrama de Secuencia Registrar Empleado.
Figura III. 24 Diagrama de Colaboración Registrar Empleado.
3.3.5.4. Registrar Ingreso Individual

Figura III. 25 Diagrama de Secuencia Registrar Ingreso Individual.
3.3.5.5. Registrar Instalación

Figura III. 26 Diagrama de Secuencia Registrar Instalación.
Figura III. 27 Diagrama de Colaboración Registrar Instalación.

3.3.5.6. Registrar Residente
Figura III. 28 Diagrama de Secuencia Registrar Residente.

3.3.5.7. Registrar Vehículo
Figura III. 29 Diagrama de Secuencia Registrar Vehículo.

Figura III. 30 Diagrama de Colaboración Registrar Vehículo.
3.3.6. Diagrama de Clases

Figura III. 31 Diagrama de Clases.

3.3.7. Diagrama de Componentes
Figura III. 32 Diagrama de componentes.

3.3.8. Diagrama de Despliegue
Figura III. 33 Diagrama de Despliegue.
IV. VALIDACIÓN DEL MODELO
4.1. Instrumentos y técnicas
Como ya se definió en el capítulo III la metodología a utilizar para el análisis, desarrollo
e implementación de este sistema serán las metodologías Proceso Unificado de Rational
(RUP) junto con el lenguaje unificado de modelado (UML), utilizando como
herramienta de software el Rational Rose Enterprise Edition.
Además para realizar la validación del modelo utilizaremos el software Microsoft
Project 2010,que es un software de administración de proyectos desarrollado y
comercializado por Microsoft el cual está diseñado para asistir a administradores de
proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al
progreso, administrar presupuesto y analizar cargas de trabajo.En nuestro caso lo
utilizaremos para obtener los costos de personal a quienes se les asignara tiempos
aproximados con costo por horas.
Para medir los resultados de nuestro proyecto, es decir la rentabilidad del mismo, así
como su viabilidad utilizaremos como indicadores económicos al VAN (Valor Actual
Neto) y el TIR (Tasa Interna de Retorno).
Cuando se forma una empresa hay que invertir un capital y se espera obtener una
rentabilidad a lo largo de los años. Esta rentabilidad debe ser mayor al menos que una
inversión con poco riesgo. De lo contrario es más sencillo invertir el dinero en dichos

productos con bajo riesgo en lugar de dedicar tiempo y esfuerzo a la creación
empresarial.
Dos parámetros muy usados a la hora de calcular la viabilidad de un proyecto son el
VAN (Valor Actual Neto) y el TIR (Tasa Interna de Retorno). Ambos conceptos se
basan en lo mismo, y es la estimación de los flujos de caja que tenga la empresa
(simplificando, ingresos menos gastos netos).
4.2. Diseño del prototipo
4.2.1. Prototipo de acceso al portal
La Figura IV.1 nos muestra el prototipo para acceder al portal de administración de condominios,
donde el residente o administrador podrá acceder al sistema ingresando su usuario y su clave de
acceso. En el caso de que el residente no cuente con una clave de acceso para ingresar al sistema, el
residente podrá solicitarla ingresando su código de residente y su correo electrónico para queésta le
sea enviada por correo electrónico.

Figura IV. 1 Prototipo de acceso al portal.
4.2.2. Página Principal del portal
La Figura IV.2 nos muestra el prototipo de la página principal del residente, donde
éste podrá realizar consultas sobre pagos, cuotas, notificaciones o avisos,
publicaciones, contactar con el asistente virtual e incluso publicar artículos o pedir
prorrogas de pago.

Figura IV. 2 Página principal del portal.
4.2.3. Panel residente para dispositivos móviles
La Figura IV.3 nos muestra el prototipo del portal de residentes para dispositivos
móviles con las opciones que ofrece el sistema para dispositivos móviles.

Figura IV. 3 Panel residente para dispositivos móviles.
4.2.4. Panel administrativo y asistente virtual

Enla Figura IV.4 se visualiza el prototipo del panel administrativo con las diversas
funciones que ofrece el sistema y también se muestra el prototipo inicial del asistente
virtual que permitirá al internauta (Administrador o residente)realizar consultas,
pedidos o según sea el caso le ayudara a utilizar el sistema.
Figura IV. 4 Panel administrativo y asistente virtual.

4.2.5. Prototipo de generación de cuotas por consumo de servicio de agua para móviles
La Figura IV.5 nos muestra el prototipo de generación de cuotas por consumo de
servicio de agua para móviles donde el ayudante de administración ingresara los datos
generales como la descripción, costo por unidad, fecha de la lectura, fecha de
vencimiento, fondo de destino, clasificación presupuestal y decimales de redondeo.
También ingresara por cada apartamento la lectura anterior y la nueva lectura, luego de
guardada la información las cuotas serán generadas automáticamente.

Figura IV. 5 Prototipo de generación de cuotas por consumo de servicio de agua para móviles.
4.2.6. Módulo de registro de ingreso individual
La Figura IV.6 nos muestra el módulo de registro de ingreso individual por
apartamento donde el administrador ingresara el monto de cada apartamento, la forma
de pago, referencia, la fecha en que se recibió el pago, tipo de cuenta donde se
depositara el dinero y algún comentario si es necesario.

Figura IV. 6 Módulo de registro de ingreso individual.
4.2.7. Módulo de registro de pagos de terceros
La Figura IV.7 nos muestra el módulo de registro de pagos de terceros donde el
administrador llenara el formulario para capturar un pago por personas ajenas al
condominio.
Figura IV. 7 Módulo de registro de pago de terceros.

4.2.8. Módulo de registro de adelantos o anticipos
La Figura IV.8 nos muestra el módulo de registro de adelantos o anticipos donde el
administrador podrá registrar de manera separada los pagos adelantados de cada
residente e incluir un concepto o una destinación para el adelanto.
Figura IV. 8 Módulo de registro de adelantos o anticipos.
4.2.9. Módulo de registro de egresos
La Figura IV.9 nos muestra el módulo de registro de egresos donde el administrador
registrara los gastos del condominio por ejemplo: Consumo de luz, agua, jardinería,
limpieza, papelería y copias, etc.

Figura IV. 9 Módulo de registro de egresos.
4.2.10. Módulo de consulta de estado de cuenta por apartamento
La Figura IV.10 nos muestra el módulo de consulta de estado de cuenta por
apartamento donde el administrador podrá observar la información sobre el historial de
pagos y deudas de cada apartamento agrupadas por año.

Figura IV. 10 Módulo de consulta de estado de cuenta por apartamento.
4.2.11. Módulo de registro de apartamentos
La Figura IV.11 nos muestra el módulo de registro de apartamentos donde el
administrador registrara los distintos inmuebles del condominio a administrar
ingresando el nombre o número de apartamento, teléfonos, el número de torre a la cual
pertenezca, notas internas, estatus de la ocupación (si está ocupada o no) y el estatus de
actividad.
Figura IV. 11 Módulo de registro de apartamentos.

4.2.12. Módulo de registro de empleados
La Figura IV.12 nos muestra el módulo de registro de empleados donde el
administrador registrara los empleados que tiene el condominio por ejemplo: Personal
de vigilancia, personal de limpieza, personal de jardinería, etc.
Figura IV. 12 Módulo de registro de empleados.
4.2.13. Módulo de registro de vehículos
La Figura IV.13 nos muestra el módulo de registro de vehículos donde el
administrador registrara los vehículos de los residentes seleccionando el apartamento,
la clave (este campo se refiere al tipo de vehículo), la placa del vehículo y una
descripción del vehículo.

Figura IV. 13 Módulo de registro de vehículos.
4.2.14. Registrar Instalación
En la Figura IV.14 podemos apreciar el módulo de registro de instalacionesdel
condominio (ya sea piscina, cancha de futbol, sala de eventos, etc.), adicionalmente se
podrá asignar un costo por alquiler, descripción, reglamento y estado de servicio (si
está activa o inactiva la instalación).
Figura IV. 14 Módulo de registro Instalación.

Sistema de Administracion de Condominios basados en agentes de software

Sistema de Administracion de Condominios basados en agentes de software

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Sistema de Administracion de Condominios basados en agentes de software

Similar a Sistema de Administracion de Condominios basados en agentes de software (20)

Más de Pedro Chavez

Más de Pedro Chavez (20)

Último

Último (20)

Sistema de Administracion de Condominios basados en agentes de software