1

DESARROLLO DE UN APLICATIVO DE INMUEBLES – INMUEBLES WEB

ANA ISABEL COBO OSPINA

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE CIENCIAS DE LA INFORMACION PROGRAMA INGENIERÍA INFORMATICA

SANTIAGO DE CALI 2008

2

DESARROLLO DE UN APLICATIVO DE INMUEBLES – INMUEBLES WEB

ANA ISABEL COBO OSPINA

Pasantía para optar el titulo de Ingeniera Informática

Directora

SANDRA LUCIA GUAÑARITA FERNANDEZ

UNIVERSIDAD AUTONOMA DE OCCIDENTE FACULTAD DE INGENIERIA

DEPARTAMENTO DE CIENCIAS DE LA INFORMACION PROGRAMA DE INGENIERIA INFORMATICA

SANTIAGO DE CALI 2008

3

Nota de aceptación: Aprobado por el Comité de Grado en cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar al título de Ingeniero Informático

ORLANDO ARBOLEDA --------------------------------------------

Jurado

LYDA PEÑA --------------------------------------------

Jurado

Santiago de Cali, Marzo de 2009

4

CONTENIDO

Pág.

RESUMEN 7

INTRODUCCIÓN 8

1. PLANTEAMIENTOS DEL PROBLEMA 9

2. MARCO TEÓRICO 10

3. ANTECEDENTES 22

4. OBJETIVOS 23

4.1 OBJETIVO GENERAL 23

4.2 OBJETIVOS ESPECÍFICOS 23

5. JUSTIFICACIÓN 24

6. METODOLOGÍA 25

7. DESARROLLO DEL PROYECTO 27

7.1 MODELADO DE NEGOCIO 27

7.2 ESPECIFICACIÓN DE REQUISITOS 28

7.3 ANÁLISIS Y DISEÑO 31

7.4 IMPLEMENTACIÓN 36

7.5 PRUEBAS 37

5

8. CONCLUSIONES 41

9. RECOMENDACIONES 42

BIBLIOGRAFÍA 43

ANEXOS 44

6

LISTA DE FIGURAS Pág.

Figura 1. Ejemplo Diagrama de clase 12

Figura 2. Ejemplo Diagrama de Despliegue 12

Figura 3. Proceso de Ingeniería de Requerimientos 13

Figura 4. Representación Entidad 17

Figura 5. Observación de Atributos 18

Figura 6. Ejemplo de Relaciones 19

Figura 7. Ejemplo de Cardinalidad 19

Figura 8. Ejemplo de Obligatoriedad 20

Figura 9. Ejemplo de Relaciones Recursiva 20

Figura 10. Ejemplo de Relaciones Excluyentes 20

Figura 11. Ejemplo de Relación de Exclusión 20

Figura 12. Ejemplo de Relaciones Identificantes 21

Figura 13. Diagrama de Casos de uso del Negocio 27

Figura 14. Diagrama de Caso de Uso del Sistema 28

Figura 15. Diagrama de Despliegue Sistema Bienes Inmuebles 29

Figura 16. Diagrama de Componentes Sistema Bienes Inmuebles 33

Figura 17. Esquema Entidad Relación 35

7

LISTA DE ANEXOS ADJUNTOS Anexo A. Modelado de negocio Anexo B. Especificación de requerimientos Anexo C. Análisis y diseño Anexo D. Interfaz de usuario Anexo E. Manual de usuario Anexo F. Pruebas

8

RESUMEN Para el desarrollo del proyecto “Desarrollo de un aplicativo para la administración de inmuebles” se inicia con diferentes reuniones para recolectar la información que nos permita analizar los proceso que se llevan a cabo en el área y proceseder a , diseñar e implementar una solución confiable para la organización, haciendo uso de la ingeniería de software, y del lenguaje unificado UML. Una vez entendido el proceso de la empresa se realizan los diferentes diagramas que nos permitirán continuar con las etapas de nuestra metodología, con estos resultados se implementaran cada uno de los formularios del aplicativo.

9

INTRODUCCIÓN El cambio y el movimiento son las características del mundo contemporáneo. Características que exigen a las instituciones, cooperativas y empresas mantener actualizada la información con el fin de brindar soluciones oportunas a sus clientes, empleados y usuarios, tanto externos como internos. Esta realidad exige a las organizaciones realizar actualizaciones permanentes de sus sistemas de información o a mejorar aplicaciones existentes con el fin de brindar un mejor servicio y obtener una información oportuna y actualizada. Por otro lado para las empresas es de suma importancia la administración de la información, para lograr confiabilidad. En la actualidad las empresas utilizan los sistemas que permiten almacenar toda su información, logrando una mejor eficiencia al momento de ingresar todos los datos con procesos computarizados. El proyecto “Desarrollo de un aplicativo para la administración de inmuebles” busca la administración de los bienes inmuebles propios y de las obras en curso en una entidad del sector Bancario, con el propósito de analizar, diseñar e implementar un aplicativo de inmuebles que maneja la información adecuadamente y que los informes sean confiables para la organización, haciendo uso de la ingeniería de software, y del lenguaje unificado UML, obteniendo una descripción correcta del sistema que se va a establecer. El presente documento presenta de manera general el proyecto anterior, permitiendo conocer aspectos tales como objetivos, alcance, impacto, duración, y financiación entre otros.

10

1. PLANTEAMIENTO DEL PROBLEMA En la actualidad mediante un aplicativo llamado SIDIM se realiza los procesos de almacenamiento de los inmuebles, este proceso empieza con el desarrollo de un presupuesto institucional anual, el cual es aprobado por la junta directiva, el cual se digita en el aplicativo para tener referencia para la utilización de las obras. Con este presupuesto se seleccionan las obras que se van a realizar y las que se deben culminar, esto también se debe digitar en el aplicativo. Para la elaboración de una obra se debe hacer lo siguiente, los encargados de la parte arquitectónica y de la parte eléctrica deben desplazarse hacia el lugar donde se realizará la obra y levantar los requerimientos, luego deben desarrollar un presupuesto detallado para cada obra con sus diferentes ítems. Si en la obra se necesita colocar algo en licitación, se debe hacer entrega a los licitantes de materiales que se van a utilizar en esta obra, por medio de un acta, en un tiempo definido deben entregar las propuestas y los documentos requeridos para ser analizados por los integrantes del comité de recepción de propuestas. Una vez conocida a quien se le dará, se cita a una reunión donde se realizará el contrato y se definirán fechas de entrega del material. Con estos elementos cubiertos se procede a aprobar el inicio de obra mediante un acta de inicio la cual debe ser generada en Word y en el aplicativo se debe cambiar el estado de la obra, en medio de la obra se realizan actas de avance. Al culminar la obra se debe realizar un acta de terminación y cambiar el estado de obra para no tenerla en cuenta en futuros procesos. El aplicativo se encuentra dividido por módulos pero actualmente algunos no son utilizados porque se tienen deficiencias en el diseño estructural de la base de datos y no permite obtener información de otros módulos, en algunas ocasiones al ser cerrada la obra, no permite cambiar el estado de la misma, y los usuarios tienen que comunicarse con el administrador del sistema para que él habilite la opción y a veces esta persona por sus múltiples ocupaciones se demora en contestar la solicitud. Cuando se desea generar los reportes, se encuentran con que la información no es la correcta o no genera lo que el usuario desea. En tal sentido, se está convirtiendo en una carga por la cantidad de problemas que presenta y los usuarios han optado por realizar sus labores en Excel y realizar los reportes manualmente. El sistema actual quedó obsoleto frente a los nuevas necesidades del área, ya que las obras se realizan por todo el país y deben esperar llegar a Cali para registrar los elementos necesarios para dar inicio. En estos momentos se requiere un manejo Web de la aplicación para poder ingresar desde cualquier sitio del país.

11

2. MARCO TEORICO 2.1 PROCESO UNIFICADO RATIONAL

El Proceso Unificado es un conjunto de actividades necesarias para transformar los requisitos del usuario en un sistema software. El RUP está dirigido por casos de uso, centrado en la arquitectura, y es iterativo e incremental. El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constas de cuatro fases: inicio, elaboración, construcción, y transición. Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos. Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un área específica dentro del proyecto total. Las más importantes son: Requerimientos, Análisis, Diseño, Codificación, y Prueba. Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están compuestos por artefactos. Los artefactos más importantes son los modelos que cada disciplina realiza: modelo de casos de uso, modelo de diseño, modelo de implementación, y modelo de prueba. El Proceso Unificado consiste en una serie de disciplinas o flujos de trabajo que van desde los requisitos hasta las pruebas. Los flujos de trabajo desarrollan modelos desde el modelo de casos de uso hasta el modelo de pruebas. Estos modelos se realizaran por medio de UML que es la herramienta usada para la descripción y construcción de software, y nos sirve como soporte a la metodología del proceso Unificado Racional(RUP) 1.

2.2 LENGUAJE UNIFICADO DE MODELADO

(Unified Modeling Language, UML)

Es un lenguaje estándar para escribir planos de software. Se puede utilizar como herramienta para visualizar, especificar, construir y documentar los artefactos de un sistema que involucra una gran cantidad de software. Este lenguaje es apropiado para el modelamiento de sistema de información en empresas hasta aplicaciones distribuidas basadas en la Web. UML es solo un lenguaje y por lo tanto es tan sólo una parte de un método de desarrollo de software. Es la evolución del las tres anteriores tecnologías orientadas a objetos lideres (Booch, OMT y OOSE). El UML es la unión de estos lenguajes de modelos y aún

1 SOMMERVILLE, Ian. Ingeniería del software, 7 ed. Madrid: pearson addison wesley, 2005, p. 200.

12

mas, ya que incluye expresiones adicionales para manejar problemas de modelaje que los métodos anteriores no cubrían plenamente. El desarrollo de el UML empezó en octubre de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation iniciaron su trabajo para unificar los métodos de Booch y OMT. Debido a que los métodos Booch y OMT ya habían madurado independientemente y eran reconocidos como métodos líderes en el desarrollo orientado a objetos, Booch y Rumbaugh unieron fuerzas para forjar una unificación completa de los dos métodos. Una versión preliminar 0.8 de el “método unificado” fue dad a conocer en octubre de 1995. Poco después, Ivar Jacobson y su compañía “Objectory” se unieron a Rational y a su trabajo de unificación, uniendo el método OOSE (Object Oriented software engineering). El Nombre de Objectory es ahora dado mayormente para describir a el Proceso que acompaña al UML el “Rational unified process” El UML posee varios tipos de diagramas y construcciones que pueden ser usadas para el diseño de sistemas, como diagramas de clases, diagramas de objetos diagramas de casos de uso, diagramas de secuencia, diagramas de colaboración, diagrama de estados, diagramas de actividades, diagramas de componentes y diagramas de despliegue. Un diagrama de clases muestra un conjunto de clases, interfaces y las relaciones entre ellas. Estos se utilizan para modelar la vista de diseño estática de un sistema. Booch dice que: “Una clase es una descripción de un conjunto de objetos que comparten los mismo atributos, operaciones, relaciones y semántica” 2. Una interfaz es una colección de operaciones que especifican un servicio de una clase. No pueden tener atributos. Estas se utilizan para visualizar, especificar, construir y documentar las líneas de separación dentro de un sistema. 3

2 BOOCH, Grady y JACOBSON Ivar, lenguaje unificado de modelado. Madrid: addison Wesley, 2000. p.105. 3 BOOCH, Op. cit.,p. 107

13

Figura 1. Diagrama de clase

Fuente: Osmosis Latina. Diagrama de clase [en línea]. Brasil: osmosislatina. 2008 [consultado Mayo 2008]. Disponible en Internet: www.osmosislatina.com Un diagrama de despliegue “muestra la configuración de nodos que participan en la ejecución y de los componentes que residen en ellos”4. Se utilizan para describir la vista de despliegue estática de una arquitectura. Contiene nodos y relaciones. Figura 2. Diagrama de Despliegue

Fuente: Diagrama de despliegue [en línea]. Chile: Universidad federico[consultado Mayo 2008]. Disponible en Internet: http://www.inf.utfsm.c

4 BOOCH, Op. cit., P.361

14

Un diagrama de casos de uso representa un conjunto de casos de uso, actores y sus relaciones. Son especialmente importantes para organizar y modelar el comportamiento de un sistema. “Los casos de uso proporcionan un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguen a una compresión común del sistema. Los casos de uso bien estructurados denotan solo comportamientos esenciales del sistemas o de un subsistema, y nunca deben ser excesivamente genéricos ni demasiado específicos”.5 Un diagrama de secuencia presenta un conjunto de objetos y los mensajes enviados y recibidos por ellos. Los objetos suelen ser instancias con nombre de clases, pero también pueden representar instancias de otros elementos, tales como colaboraciones, componentes y nodos. Se utilizan para describir la vista dinámica de un sistema. 2.3 INGENIERIA DE REQUERIMIENTOS Los requerimientos para un sistema son la descripción de los servicios proporcionados por el sistema. Aquí se refleja las necesidades de los clientes de un sistema. Ingeniería de requerimientos es el proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones.6 La meta es crear y mantener un documento de requerimientos del sistema. El proceso general corresponde a cuatro subprocesos: El estudio de viabilidad que consiste en evaluar si el sistema es útil para el negocio; La obtención y análisis que se trata en el descubrimiento de los requerimientos; Especificación se trata en la transformación de estos requerimientos en formularios estándar, y la verificación de los requerimientos. (ver figura 5).

5 BOOCH, Op. cit., p.400 6 PRESSMAN, Roger S. Ingeniería de Software: Un enfoque práctico 6 ed. Mexico D.F.: McGraw-Hill, 1998, p..54.

15

Figura 3. Proceso de Ingeniería de Requerimientos

Fuente: SOMMERVILLE ian, Ingeniería del software. 7 ed. Madrid: pearson addison wesley, 2005. 687 p. 2.3.1 Estudio de viabilidad. La entrada para esta etapa es un conjunto de requerimientos del negocio, una descripción del sistema. Los resultados de esta etapa es un informe que refleje si se merece o no continuar con la ingeniería de requerimiento y el proceso de desarrollo. 2.3.2 Obtención y análisis de requerimientos. Es la etapa donde se determina el dominio de la aplicación, los servicios a proporcionar, rendimiento del sistema, las restricciones. Para este proceso se debe trabajar con las siguientes actividades: � 1. Descubrimiento de requerimientos: Es el proceso para recopilar los requerimientos de los usuarios. � 2. Clasificación y organización de requerimientos: esta actividad toma la recopilación no estructurada de requerimientos, grupos relacionados de requerimientos y los organiza. � 3. Ordenación por prioridades y negociación de requerimientos: cuando existen muchas personas afectadas por el sistema, los requerimientos entraran en conflicto. Con esta actividad se refiere a ordenar según las prioridades los requerimientos, y a encontrar y resolver los requerimientos en conflicto a traves de la negociación. � 4. Documentación de requerimientos: se documentan los requerimientos. Se pueden producir documentos formales o informales

16

2.3.3 Descubrimiento de Requerimientos. Es el proceso de recoger información sobre el sistema propuesto y los existentes y extraer los requerimientos del usuario y del sistema de esta información. Las fuentes durante esta fase son los usuarios afectados, la documentación y la especificación de sistemas similares. 2.3.4 Validación de requerimientos. En esta etapa se mostrara si definen el sistema que el cliente desea. Se deben llevar a cabo verificaciones sobre requerimientos en el documento de requerimientos. Estas verificaciones comprenden: � Verificación de validez � Verificación de consistencia � Verificación de completitud � Verificación de realismo � Verificabilidad Hay diferentes técnicas de validación de requerimientos que se pueden utilizar en conjunto o en una forma individual: � Revisiones de requerimientos � Construcción de prototipos � Generación de casos de prueba Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado de no hacer clara la separación entre los diferentes niveles de descripción. Existen los denominados requerimientos del usuario y requerimientos del sistema. Los requerimientos del usuario son “declaraciones, en lenguaje natura y en diagramas, los servicios que se espera que el sistema proporciones y de las restricciones bajo las cuales debe funcionar”7. Los requerimientos del sistema ”establecen con detalle las funciones, servicios y restricciones operativas del sistema”.8 Casi siempre, los requerimientos de sistemas software se clasifican en funcionales y no funcionales.

7 PRESSMAN, Op. cit., p.400 8 Ibíd., p. 430.

17

� Requerimientos funcionales: “Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que este debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares.” � Requerimientos no funcionales. “son restricciones de los servicios o funciones ofrecidos por el sistema. Incluye restricciones de tiempo, sobre el proceso de desarrollo y estándares Los principales objetivos que se identifican en la especificación de requisitos softwares son: � Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software: El cliente debe participar activamente en la especificación de requisitos, ya que éste tiene una visión mucho más detallada de los procesos que se llevan a cabo. Asimismo, el cliente se siente partícipe del propio desarrollo. � Ayudar a los desarrolladores a entender qué quiere exactamente el cliente. � Servir de base para desarrollos de estándares de ERS particulares para cada organización. Una buena especificación de requisitos software ofrece una serie de ventajas entre las que destacan el contrato entre cliente y desarrolladores, la reducción del esfuerzo en el desarrollo, una buena base para la estimación de costos y planificación, un punto de referencia para procesos de verificación y validación, y una base para la identificación de posibles mejoras en los procesos analizados. La ERS es una descripción que debe decir ciertas cosas y al mismo tiempo debe decirlas de una determinada manera. En este documento se presentará una de las formas que viene especificada por el estándar IEEE 830. Una ERS forma parte de la documentación asociada al software que se está desarrollando, por tanto debe definir correctamente todos los requerimientos, pero no más de los necesarios. Esta documentación no debería describir ningún detalle de diseño, modo de implementación o gestión del proyecto, ya que los requisitos se deben describir de forma que el usuario pueda entenderlos. Al mismo tiempo, se da una mayor flexibilidad a los desarrolladores para la implementación. Las características deseables para una buena especificación de requisitos software son las siguientes: · Correcta · No ambigua · Completa

18

· Verificable · Consistente · Clasificada · Modificable · Explorable · Utilizable durante las tareas de mantenimiento y uso 2.4 BASES DE DATOS Conjunto de estructuras autodescriptivas, organizadas y relacionadas, cuyo fin es almacenar datos y facilitar el proceso, control y mantenimiento eficiente de los mismos. Entendiendo por dato todo aquello que se desea almacenar y recuperar en un futuro. Estos pueden ser texto, números, fechas, imágenes, entre otros. Una Base de datos está formada por diferentes objetos para conservar, almacenar y manipular la información. Estos son Tablas, consultas, formularios. Informes, Módulos, Macros. El sistema gestor de base de datos (SGBD), es aquel programa que actúa como un intermediario entre los usuarios y los datos. Debe cumplir con una serie de funciones como permitir la descripción de los datos, definición de sus propiedades y relaciones entre ellos, como también el insertar, suprimir y modificar los datos. Motor de la base de datos: es el encargado del manejo interno de los archivos de la base de datos, de la integridad, seguridad, estabilidad y correcto funcionamiento de la misma. Bases de datos relacionales. Una base de datos relacional es una base de datos en donde todos los datos visibles al usuario están organizados estrictamente como tablas de valores, y en donde todas las operaciones de la base de datos operan sobre estas tablas. Estas bases de datos son percibidas por los usuarios como una colección de relaciones normalizadas de diversos grados que varían con el tiempo. 2.4.1 Modelo Entidad – Relación. El modelo entidad relación se basa en una percepción de un mundo real que consiste en un conjunto de elementos básicos llamados entidades y relaciones entre estos elementos.

19

Entidades: Ente (objeto o proceso) del cual se desea mantener información. Deben ser Mutuamente excluyentes, Genéricas, Relativamente sencillo identificar los datos que se desean mantener. Representación Gráfica de una Entidad • Nombre en mayúscula y singular. • Cuadro con bordes redondeados. • Línea que separa el nombre de la entidad de sus atributos.

Figura 4. Representación Entidad

Atributos: Los Atributos son las características por las cuales puedo describir una Entidad y que a su vez no tienen características propias. Debe tener características de simplicidad, univaluados, exclusividad, no calculables. Figura 5. Observación de Atributos

Llaves o Claves � Atributo o atributos, que hacen que cada ocurrencia en una entidad sea única. Pasos para establecer la clave � Verifique si existen atributos en la entidad que sean candidatos para formar la clave. � Los atributos que forme la clave no pueden ser opcionales. � Evite ocurrencias con caracteres especiales: #, “, -, /, ‘, +, etc. � No existe clave: agréguela, autoincremental (secuencia).

ESTUDIANTE

VIDEO * código * titulo * numero copias

20

� Demasiados atributos, considere el caso anterior. Llaves o Claves alternas o secundarias � Dos o más conjuntos de atributos son candidatos a ser la clave principal, pero solo uno de ellos puede ser clave principal. Relaciones: Interacción que existe entre dos entidades. Siempre que se establece relación entre dos entidades, estas comparten un atributo o conjunto de atributos a través de esta relación. Figura 6. Ejemplo de Relaciones

Características Generales � Nombre. .Singular y minúsculas junto a la entidad que se establece como origen de la relación. � Cardinalidad. Número de veces que esta interacción se presenta. Una ocurrencia de la entidad origen y toda la vida del sistema con respecto a la entidad destino. Se dibuja junto a la entidad destino.

Relación de X a Y El origen es X, el destino es Y

X Y

Relación de Y a X El origen es Y, el destino es X

21

Figura 7. Ejemplo de Cardinalidad

Obligatoriedad. Si la interacción entre dos entidades (y dependiendo del sentido de la relación) se presenta siempre o por el contrario algunas veces no se presenta. Figura 8. Ejemplo de Obligatoriedad

Relaciones Recursivas. Relación que presenta de una entidad consigo misma. Figura 9. Ejemplo de Relaciones Recursiva

Relaciones Excluyentes. De un grupo de relaciones solo una de ellas se puede presentar. Figura 10. Ejemplo de Relaciones Excluyentes

uno varios

obligatoria opcional

PRODUCT

# referencia * descripcion * precio

genera

generado

• •

22

Relación de Exclusión. Si se da la ocurrencia de una relación, no se debe dar la ocurrencia de la(s) otra(s) relación(es) incluida(s) en la restricción, de forma simultánea. Ejemplo 11. Ejemplo de Relación de Exclusión

Relaciones Identificantes. Es aquella en la que el atributo o atributos que se comparten en la relación se requieren para identificar la clave en la entidad destino relacionada. Figura 12. Ejemplo de Relaciones Identificantes

Simbología del modelo entidad relación � Rectángulo: Se utiliza para representar las entidades. � Elipses: Se utiliza para representar los atributos. � Rombos: Se utiliza para representar relaciones entre entidades. � Líneas: Se utilizan para conectar atributos a entidades y entidades a relaciones. 2.4.2 Modelo Relacional de datos. Es un modelo de datos basado en la lógica de predicado y en la teoría de conjuntos. Los componentes son las tablas y sus campos( tipo de dato y su longitud, función(PK,FK), obligatoriedad(NN,N), dominio y restricciones).

2.5 BIENES INMUEBLES Son aquellos materiales que son imposibles de ser movidos o trasladados, ya que están formando parte de un terreno. Un ejemplo de este tipo de bienes, es una obra de la arquitectura civil, militar, domestica, una casa, un edificio, un puente,

23

una calle, etc. Los bienes inmuebles pueden ser hipotecados, pero, debemos de tener mucho cuidado con la empresa con quien negociemos, y debemos de ser responsable, ya que por cualquier incumplimiento nuestro o engaño de la otra parte, podemos perder el inmueble. Ahora, para darle mayor protección al propietario de sus bienes inmuebles pueden ser inscritos en un registro. Los bienes inmuebles se pueden clasificar en:

• Bienes inmuebles por naturaleza, como el suelo y subsuelo. • Bienes inmuebles por incorporación, como construcciones. • Bienes inmuebles por destino. Cuando se les unen cosas muebles. • Bienes inmuebles por analogía, como concesiones hipotecarias. • Bienes inmuebles por accesión, como las puertas, ventanas, etc. que en una fábrica, almacén o comercio son bienes muebles pero instaladas son inmuebles. • Bienes inmuebles por representación, como la escritura que otorga la titularidad registral al propietario.

24

3. ANTECEDENTES El desarrollo de un aplicativo de bienes inmuebles surge de la necesidad de actualizar el sistema actual, el cual fue desarrollado en el año 1997 (SIDIM) y cuya última actualización se realizó en el 2001. Por tal motivo no se realizó un estudio de mercado para observar que aplicativos podían mejorar lo inconvenientes presentados por el sistema actual como es la confiabilidad de la información que se maneja, el sistema de navegación dentro del aplicativo no es amigable para el usuario y la búsqueda de la información es bastante compleja, tiene problemas en el diseño de la base de datos. También se observa la necesidad de que los usuarios puedan ingresar al aplicativo vía Web y no instalar el sistema cada vez que se desee realizar una tarea en este, estas funcionalidades no se tienen en la actualidad. Por otra parte las políticas del banco y sus ultimas actualizaciones se desea que los desarrollos para los procesos críticos se inicien desde cero y no involucrar sistemas comerciales que puedan estar en otras entidades.

25

4. OBJETIVO

4.1 OBJETIVO GENERAL Desarrollar una aplicación para la administración de los inmuebles propios y/o alquilados en una entidad bancaria en particular. * 4.2 OBJETIVOS ESPECIFICOS • Estudiar los procesos de administración de inmuebles, presupuesto y licitación.

• Construir el documento de especificación de requerimientos para los procesos de administración de inmuebles.

• Diseñar los módulos de administración de inmuebles, presupuesto y licitación.

• Elaborar el plan de pruebas para los módulos de administración de inmuebles administración de inmuebles, presupuesto y licitación.

• Implementar los módulos de administración de inmuebles, presupuesto y licitación.

• Escribir el informe de pruebas de unidad e integración para los módulos de administración de inmuebles administración de inmuebles, presupuesto y licitación.

* por motivos de confidencialidad no se puede mencionar

26

5. JUSTIFICACIÓN El desarrollo del aplicativo inmueble busca transformar el manejo actual de la información en el área, que permite brindar datos oportunos, ágiles y actualizados, en un ambiente Web el cual nos permite acceder desde cualquier lugar, Con la aplicación se beneficiaran los empleados del área porque ya no deben esperar a regresar al sitio de trabajo sino que pueden registrar los datos desde cualquier lugar del país. Con esta propuesta se brindara mayor agilidad a los licitadores en el momento de recibir sus documentos. La documentación requerida la va encontrar en medios magnéticos facilitando la entrega oportuna para el trámite administrativo de sus licitaciones. Se estará brindándole nueva tecnología y se dejara a la vanguardia que nos permite hacerla competitiva a las necesidades del entorno, brindando mejores servicios a nuestros usuarios externos.

27

6. METODOLOGÍA Se aplicarán algunos aspectos de la metodología RUP, como los flujos de trabajo que servirán como etapas para nuestro proceso de desarrollo, igualmente se trabajará para el modelamiento del software el Lenguaje Unificado de Modelado. Este proceso permitirá generar artefactos que sirvan de entrada a otras etapas y se vaya modelando el software desde diferentes perspectivas. Las etapas o fases a desarrollar en el proyecto serán el modelado de negocios, especificación de requerimientos, análisis y diseño, implementación y pruebas. A continuación se explicarán las entregas en cada una de las fases del proyecto: � Fase de Requerimientos. En esta fase se seleccionará el instrumento por el cual se va a tomar los datos, luego se deberá aplicarlo con los usuario que van a utilizar la aplicación. Con estos datos se analizará y se generará el listado de requerimientos, el cual se debe socializar con los usuarios. � Fase de Análisis . Con el resultado de la fase de requerimientos se elaborará el documento ERS, Especificación de Requerimientos del Sistema. Teniendo los requerimientos establecidos se procederá a construir el modelo del dominio por módulo donde estarán los diagramas de casos de uso, diagramas de clase, diagramas de secuencia.

� Fase de Diseño. Se diseñará la arquitectura la cual estará basado nuestro aplicativo que permita ofrecer un mejor desempeño.

Se elaborará el Documento de Diseño del Software, que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.

� Fase de Implementación. En esta fase se realizará la codificación del modelo de diseño y se entregaría con su respetiva documentación, también se elaborará el diagrama de componentes y de despliegue los cuales serán entregados.

� Fase de Pruebas. Esta fase se elabora el plan de pruebas donde observamos los casos de pruebas para los casos de uso.

Inicialmente se realizan pruebas a cada uno de los módulos que conforman el sistema con el fin de evaluar que su funcionamiento. Una vez se integran los módulos, se realizan pruebas de integración para evaluar los componentes del sistema. Cuando el sistema completo presente un funcionamiento adecuado, se

28

realizará la valoración del sistema con los requerimientos iníciales. Se debe realizar un informe donde especificaremos los resultados de las pruebas.

29

7. DESARROLLO DEL PROYECTO 7.1 MODELADO DE NEGOCIO

Para conocer el funcionamiento del área de bienes inmuebles y las actividades desarrolladas manualmente por cada miembro se realizaron diferentes reuniones con el director de inmuebles, y cuando se consideró necesario profundizar en algún tema específico se involucró al ejecutor de dicho tema. Con la información suministrada en las reuniones se escribió un documento en cual se describe la empresa en cuanto a objetivo y estructura, igualmente se detalla el proceso del manejo de inmuebles, permitiendo conocer las funciones que podría llegar a tener el software. (Ver anexo A). El proceso de manejo de bienes inmuebles se representa en el diagrama de casos de uso del negocio. Ver figura 18. Figura 13. Diagrama de Casos de uso del Negocio

30

7.2 ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE Se observaron diferentes maneras de determinar las necesidades y requerimientos del área, se inicio con sesiones donde asistían los directores del área y expresaban lo que ellos esperaban del software pero se cayó en el error que a veces no asistían todos y cuando se realizaba la lectura de las especificaciones no estaban de acuerdo con lo discutido en sesiones anteriores. Por tal motivo se decidió trabajar únicamente con el director de bienes inmuebles que sería el usuario directo de la aplicación. Con la información arrojada se procedió a la escritura de los requerimientos del software, seguidamente se clasificaron en funcionales y no funcionales para darle una mayor organización y entendimiento por las partes involucradas. Los requerimientos funcionales se especificaron mediante la notación UML, generando en esta fase el diagrama de Casos de Uso del sistema como se puede observar a continuación: Figura 14. Diagrama de Caso de uso del Sistema Bienes Inmuebles Bancarios

31

7.3 ANALISIS Y DISEÑO

32

Dentro de la actividad de modelamiento la primera tarea es seleccionar el lenguaje y estilo del modelo y posteriormente se elabora los diagramas y modelos. Las fases a desarrollar fueron:

� Modelamiento del software � Arquitectura � Bases de Datos En proceso seguido se detallara cada una de las actividades: 7.3.1 Modelado del software. Se selecciono orientación objetos dado que la metodología que usamos de base era RUP porque permite mostrar varias perspectivas del software como su estructura con diagrama de clase, su comportamiento con el diagrama de secuencia, en las fases de análisis y diseño facilitando el proceso de codificación y modelado.

7.3.2 Arquitectura del software. Según los lineamientos del departamento de tecnología de la organización se debe asumir una arquitectura cliente – servidor de 3 capas cliente delgado.

Para la instalación del aplicativo se debe realizar en plataforma Windows 2000 en adelante. Requerimientos de software son para el servidor framework .net 1.1, framework .net 1.1, Internet information Server 6x, runtime fox 7.0, para el cliente son Internet Explorer 6.0x, J2SE Runtime Enviroment 5.0 update 2. Requerimientos del sistemas son procesador Pentium mayor o igual de 2GHZ y memoria mayor o igual a 512 MB. Requerimientos de almacenamiento en el servidor espacio libre en disco mayor o igual a 8 GB y para el cliente mayor o igual a 2GB.

Figura 15. Diagrama de Despliegue Sistema Bienes Inmuebles Bancarios

33

Servidor Datos

Servidor

Aplicación

Cliente

RED LAN

RED LAN

Figura 16. Diagrama de Componente del Sistema Bienes Inmuebles Bancarios

34

7.3.3 Modelado de la base de datos. Teniendo en cuenta los conocimientos de las diferentes bases de datos se opto por la base de datos relacional por sus ventajas y por la disminución de las relaciones que no sean necesarias mediante la normalización. Como modelo conceptual se utilizara el modelo entidad relación que nos permitirá visualizar detalladamente los objetos y características que harán parte del sistema. Una vez realizadas las etapas como: Identificar las entidades, Identificar las relaciones, Identificar los atributos y asociarlos a entidades y relaciones, Determinar los dominios de los atributos, Determinar los identificadores, Determinar las jerarquías de generalización (si las hay). Por último se plasmará el modelo para la aplicación. Ver figura 22. Figura 17. Esquema Modelo Entidad Relación

35

� Inmueble. En la entidad principal donde incluiremos los datos básicos del inmueble. Permitirá restringir la creación del inmueble con el mismo uso, propiedad y código ya que estos datos son la llave primaria. � Uso. Es la entidad donde se almacena los diferentes usos que se le desean dar a los inmuebles. � Propiedad. Se almacena los tipos de propiedad que se le puede asignar a un inmueble. � Información Técnica. Se almacena la información de las características y su tamaño en el inmueble � Característica. Son aspectos definidos que caracterizan a cada inmueble. � Ocupación. Es la distribución por centro de costos y las áreas que ocupan un bien inmueble. � Arrendamientos. Se almacena los contratos de Arrendamiento cuando un bien inmueble se encuentra alquilado. � Propietarios. Se incluyen todos los propietarios que ha tenido o tiene un inmueble. Se traen de un sistema el cual se encarga de hacerle la validación con las listas exigidas por el banco. � Arrendadores. Se incluyen todos los arrendadores que ha tenido o tiene un inmueble. Se traen de un sistema el cual se encarga de hacerle la validación con las listas exigidas por el banco. � Histórico canon. Se incluyen las actualizaciones del canon dependiendo la fecha que se ha establecido, al ipc que se maneje en el contrato. � Histórico plazo. Fechas que se manejan en cada contrato dependiendo la novedad de este.

36

� Histórico administración. Se incluyen las actualizaciones de las administraciones pagadas por un inmueble. � Áreas diseño. Son los datos de las áreas que comprenden el inmueble según los planos del mismo. � Avalúos. Se almacena la información del avaluador, fecha y valor del proceso de avaluó de un inmueble. � Áreas avaluó. Son los datos de las areas en que se realizo el proceso de avaluo con su respectivo valor. � Escrituras. Se almacena la información de las escrituras de cada inmueble � Matriculas. Se almacena los datos de codigo y fecha de la matricula. Cada matricula depende de una escritura. � Área jurídica. Son las diferentes divisiones que tiene el inmueble y su respectivo valor. 7.4 IMPLEMENTACION

7.4.1 Base de datos. El motor de base de datos que tiene licenciado la organización es SQL SERVER. 7.4.2 Lenguaje utilizado en la interfaz de usuario. El lenguaje para desarrollos web determinado por el banco es Visual Basic .net

37

7.5 PRUEBAS

El plan de pruebas se utilizará para observar la implementación del aplicativo con datos reales y que concuerde con lo estipulado en los requerimientos iniciales. Observar detalladamente que el software permite ingresar los datos necesarios para su funcionamiento, y al desarrollar las pruebas se puedan detectar inconvenientes antes de ser entregado y que permita cumplir con lo estipulado. Para el proyecto en curso se aplicara pruebas de unidad, integración, sistema y aceptación. Se comenzará con las pruebas de unidad para cada caso de uso, en las cuales se suministran los datos de entrada y se observara los datos de salida. Luego se realizará las pruebas de integración para observar la funcionalidad del software a la hora de tomar datos de otros casos de uso. Para finalizar realizaremos las pruebas de sistema para comprobar la compaginidad entre las interfaces de usuario Para mejor organización y ejecución de cada prueba mencionada anteriormente se especificaron los casos de prueba cada uno con sus respectivos pasos ver anexo F: • Iniciar Sesión • Agregar datos Inmuebles • Consultar Inmuebles • Modificar datos inmuebles. • Inhabilitar un inmueble del sistema. Los siguientes casos de pruebas se realizara para los datos de Información Tecnica, Area según diseño, Ocupación, Contrato de Arrendamiento, Arrendadores, Propietario, escritura, Matricula, Area Juridica, Predio, Avaluos Comerciales, Areas Avaluos.

• Agregar datos • Consultar • Modificar • Eliminar • Modificar Estado del Contrato • Inactivar Propietario y Arrendador

38

Para el control de las pruebas se diligenciaría el siguiente formato en el cual se observara los datos y procesos que el usuario realizó y que ocasiono el error en el aplicativo. Para finalizar las pruebas se recopilo todos los errores con sus fechas para realizar una ultima verificación y que el usuario observara la solución.

39

8. CONCLUSIONES El aplicativo para la administración de inmuebles ha permitido el manejo de la información, haciéndola confiable y permitiendo agilizar procesos jurídicos y de consulta dentro de la empresa. El lenguaje unificado UML, facilito la traducción a un lenguaje de programación de los resultados obtenidos en la etapa de análisis y diseño, ayudando al diseño de las interfaces y del software. El desarrollo en el proceso de pruebas permitió entender aspectos del aplicativo y corregir conceptos que se tenían a la hora de la programación.

40

9. RECOMENDACIONES

Darle una mayor importancia al plan de pruebas y que el usuario final sienta esta. Mantener documentado el sistema permitirá realizar modificación o nuevas versiones en forma más oportuna y eficiente, permitiendo ser adaptado a las necesidades de los clientes. Continuar con el estudio de algunas tareas para disminuir los trabajos manuales del área de bienes inmuebles, por ejemplo las obras, licitaciones, contratos que de una u otra manera se encuentran vinculados con el aplicativo. Desarrollar una consulta de los bienes inmuebles que se pueda ser para uso de cualquier persona o área interesada.

41

BIBLIOGRAFÍA BOOCH, grady y JACOBSON Ivar, El lenguaje unificado de modelado. Madrid: addison Wesley, 2006. 432 p.

C.J. Date, Introducción a los Sistemas de Bases de Datos. 7 ed. Madrid: Pretice Hall, 1993.860 p. GUADALUPE Viera, bases de datos relacionales. [en línea], Mexico 2008 [consultado mayo de 2008]. Disponible en Internet: http://www.fismat.umich.mx.

NAVATHE Elmasri, Sistemas de Bases de Datos. 5 ed. Madrid: Addison Wesley, 2007.988 p. OBJECT MANAGEMENT GROUP, Unified Modeling Language UML [en linea]. Estados Unidos: UML, 2008 [consultado mayo de 2008]. Disponible en Internet: http://www.uml.org/ PRESSMAN, Roger S, Ingeniería de Software: Un enfoque práctico. 6 ed. Mexico D.F.: McGraw-Hill, 1998.958 p. SILBERTSCHATZ, korth, Fundamentos de Bases de datos. 4 ed. Mexico: Mc. Graw Hill, 2002.585 p. SOMMERVILLE, Ian, Ingeniería del software, 7 ed. Madrid: pearson addison wesley, 2005, 687 p.