MEMORIA PFC GESTIÓN COMERCIAL DE …upcommons.upc.edu/bitstream/handle/2099.1/5410/Memòria.pdf · Inmobiliaria: Una parte del proyecto ha sido buscar y analizar qué productos se

MEMORIA PFC

GESTIÓN COMERCIAL DE PROMOCIONES INMOBILIARIAS

INGENIERÍA TÉCNICA INFORMÁTICA DE GESTIÓN

JULIO 2008

Gestión Comercial de Promociones Inmobiliarias

PFC – Ingeniería Informática de Gestión Página 2

Tabla de contenido

1 Introducción ........................................................................................................................ 4

2 Contexto del proyecto ......................................................................................................... 4

3 Productos Relacionados en el Mercado ............................................................................... 5

3.1 Herramientas Software Relacionadas con la comercialización Inmobiliaria: ............. 5

4 PFCs de EPSEVG relacionados. ......................................................................................... 6

5 Toma de Requisitos ............................................................................................................. 8

5.1 Proceso de Toma de Requisitos ................................................................................... 8

5.2 Documento de Toma de Requisitos ............................................................................. 8

5.3 Requisitos Funcionales ................................................................................................ 9

5.4 Requisitos Previos No Funcionales ........................................................................... 10

6 Tecnología Aplicada ......................................................................................................... 11

7 Metodología utilizada ........................................................................................................ 12

7.1 El Proceso Unificado ................................................................................................. 12

8 Análisis y Especificación .................................................................................................. 15

8.1 Modelo Conceptual ................................................................................................... 15

8.2 Diagrama de Estados Piso ......................................................................................... 16

8.3 Casos de Uso ............................................................................................................. 17

8.3.1 Diagrama de Casos de Uso .................................................................................. 19

8.3.2 Añadir Clientes .................................................................................................... 20

8.3.3 Seleccionar Pisos ................................................................................................. 22

8.3.4 Generar Reserva .................................................................................................. 25

8.3.5 Generar Operación de Venta ............................................................................... 27

8.3.6 Anular Reserva .................................................................................................... 29



8.3.7 Confirmar Operación de Venta ............................................................................ 31

8.3.8 Anular Operación de Venta ................................................................................. 33

8.3.9 Asignar Contrato Piso .......................................................................................... 35

9 Diseño ............................................................................................................................... 37

9.1 Diagrama de Clases ................................................................................................... 39

9.2 Diseño de Clases ........................................................................................................ 43

9.3 Diagramas de Secuencia ............................................................................................ 49

9.3.1 Seleccionar Pisos Operación................................................................................ 49

9.3.2 Acción Crear Reserva .......................................................................................... 50

9.3.3 Acción Anular Reserva ........................................................................................ 51

9.3.4 Acción Crear Venta ............................................................................................. 52

9.3.5 Acción Confirmar Venta...................................................................................... 53

9.3.6 Acción Anular Venta ........................................................................................... 54

9.3.7 Asignar Contrato Venta ....................................................................................... 55

9.3.8 Añadir Cliente ...................................................................................................... 56

9.3.9 Rellenar Encuesta ................................................................................................ 57

9.4 Diseño de la Capa Gestión de Datos ......................................................................... 58

10 Análisis de Recursos y Costos........................................................................................... 60

10.1 Análisis de Recursos .................................................................................................. 60

10.1.1 Informe de resumen de trabajo de los Recursos .................................................. 61

10.2 Análisis de Costos ..................................................................................................... 62

10.2.1 Costos por Recurso .............................................................................................. 62

10.2.2 Tabla de costes por tipo de Recurso .................................................................... 62

10.2.3 Informe de costo previsto por fase ....................................................................... 63

11 Conclusiones ..................................................................................................................... 64



1 Introducción Este aplicativo es un caso real. Se crea para cubrir una necesidad de gestión de la empresa Mixta África que es la filial de una de las grandes promotoras inmobiliarias catalanas, Renta Corporación.

Mixta África enfoca su negocio a la construcción y venta de promociones inmobiliarias de carácter social en países africanos con economías poco desarrolladas.

Mi relación con la empresa cliente empezó a mediados de 2007 y desde entonces colaboro con ellos realizando software a medida para cubrir su proceso de negocio.

2 Contexto del proyecto La compañía cliente tiene como principal actividad la compra de terrenos para edificar bloques de viviendas encargándose también del proceso de venta de las mismas (comercialización). En este proceso de comercialización también pueden participar otras agencias externas a la empresa a cambio de una comisión en las ventas que consigan.

Este aplicativo se desarrollo con objetivo de cumplir las especificaciones tomadas en las reuniones mantenidas con los directivos de diferentes departamentos del cliente.

A esta compañía en un momento dado les surge la necesidad de disponer de una herramienta para la gestión centralizada de la comercialización de las promociones. Esta necesidad viene provocada por los problemas con los que se encontraban con las herramientas de gestión que utilizaban hasta ese momento (Listados de Papel, Hojas de Cálculo) dado que no eran centralizadas y se daban casos como vender un mismo piso a varios clientes, perdida e inconsistencia de datos, falta de sincronización entre los usuarios, imposibilidad de disponer de la información en tiempo real, etc.

Una vez finalizado el desarrollo, (septiembre de 2007) estuvo en producción y posteriormente evolucionó a una segunda versión donde se le añadieron funcionalidades de Post-Venta y Seguimiento Comercial, así como mejoras en la interfaz y usabilidad nacidas de la experiencia en el uso por parte de los usuarios.

Actualmente la evolución del aplicativo se encuentra en producción y es usado desde 5 países (Marruecos, Senegal, Mauritania, Egipto, España), implementado en 3 idiomas (Español, Francés, Inglés) y gestionando varias promociones en cada país.



3 Productos Relacionados en el Mercado Antes de iniciar el proceso de desarrollo a medida, el cliente realizó una búsqueda de productos en el mercado con las características funcionales y los requisitos no funcionales que se demandaban.

Una de las opciones que se barajó fue la que ofrece la empresa Habitania (www.habitania.com). Ésta ofrece una solución en modo SAS (Sofware As a Service) tanto para promotores como para constructores.

Después de usar un acceso de demostración a esta herramienta desistieron de adquirir esta solución; argumentando varios inconvenientes como la elevada curva de aprendizaje, que no aportaba los idiomas que se demandaban junto con la dificultad de adaptabilidad a los procesos de la compañía y la rigidez del sistema, así como la desconfianza de que los datos de sus operaciones se encontraran en un tercero.

3.1 Herramientas Software Relacionadas con la comercialización

Inmobiliaria:

Una parte del proyecto ha sido buscar y analizar qué productos se encuentran en el mercado relacionados con el proceso de comercialización en el sector inmobiliario.

http://www.gruposhebel.com/

Es una Suite completa de gestión para promociones inmobiliarias es un producto muy parecido que incluso presenta más funcionalidades.

Como inconvenientes podemos encontrar que únicamente se encuentra en inglés y castellano. Como requisito funciona sobre un ERP (Enterprise Resource Planning) de propietario de esta misma compañía, lo que supondría un cambio “traumático” de toda la infraestructura de software en la empresa cliente.

http://www.inmocomputer.com/

Es una aplicación enfocada a pequeñas inmobiliarias “de barrio” para gestionar su stock de inmuebles, no para la comercialización de promociones.

Como inconvenientes encontramos que no cubre el mismo modelo de negocio, con lo que no es una alternativa a considerar. Se trata de un Software de escritorio, enfocado a pequeñas inmobiliarias para gestionar un stock de pisos, no cubre la comercialización de una promoción completa de obra nueva.

http://www.newlar.com

Se trata de un Portal de internet enfocado al público general donde se pueden buscar promociones de obra nueva.

No es un software de gestión comercial sino un buscador de promociones de obra nueva.



Podemos encontrar en le mercado muchos más productos relacionados con la comercialización de productos inmobiliarios pero todos se clasifican en uno de los tres tipos anteriormente citados.

4 PFCs de EPSEVG relacionados. Antes de comenzar este proyecto he realizado una búsqueda de proyectos con temática similar en el catálogo de la biblioteca y he encontrado un proyecto que trata de la gestión del stock de pisos de una agencia inmobiliaria.

Datos del proyecto:

• Projecte de fi de carrera: 1999/474. • Engìnyeria tècnica en Informàtica de Gestió. • InmoComp: Gestió Inmobiliaria. • Projecte de gestió d’una inmobiliaria. • Autora: Guiomar Giralt Cañabate.

• Juny 1999.

Este proyecto es una Aplicación de escritorio implementada en visual Basic 5.0 usando como almacén de datos Access 97.

Se trata de un programa para gestionar la comercialización de pisos de una pequeña inmobiliaria. Existe una diferenciación entre clientes Vendedores que son los clientes que acuden a la agencia para vender o alquilar un piso de su propiedad y clientes Compradores que son los que acuden a la agencia para consultar los pisos y comprar alguno que les interese.

Las diferencias que encontramos entre este PFC y el que presento es tanto la tecnología aplicada como el objeto de negocio que se cubre.

Tecnológicamente InmoComp es una aplicación de escritorio, como repositorio de datos utiliza Access 97 que no es propiamente un servidor de bases de datos (No admite conexiones remotas nativas, sino que siempre se tiene que acceder mediante el acceso al sistema de ficheros), el código no está implementado usando la metodología orientada a objetos.

Por otra parte la presente aplicación se divide en tres capas lógicas (igual que físicas) ya que la capa de presentación se encarga de la interfaz de usuario y se construye como una aplicación Web ASP .NET 2.0 que se procesa mediante llamadas http a un servidor IIS y se presenta la respuesta en el navegador del cliente. La capa lógica de negocio está programada en C# 2.0 y se compila en una librería aparte.

Por último el repositorio de datos es SQL Server 2005 que sí es un servidor de base de datos propiamente dicho. Aloja las reglas que garantizan la integridad de los datos así como algún proceso de negocio implementado como disparador que realiza volcados a históricos como la actualización del histórico de tarifas cada vez que éstas cambian, con objetivo de su posterior seguimiento.



En referencia al enfoque del sector de negocio que cubren tiene en común que los dos pertenecen a la comercialización de productos del sector inmobiliario.

Como diferencias mientras InmoCorp está orientada a la gestión del stock de viviendas de una inmobiliaria intermediaria (Agencia inmobiliaria), GesPromo está orientada a cubrir la gestión comercial de una empresa inmobiliaria promotora. Diferenciándose en que en GesPromo maneja una o varias promociones completas, pueden participar en el proceso de comercialización más de una Agencia Inmobiliaria, pudiendo reservarse pisos a vender exclusivamente por alguna de las agencias, la posibilidad de realizar la venta de varios pisos al mismo tiempo (Muy útil, por ejemplo para compras de inversores).

Como diferencia también podemos señalar la cuestión de que el interfaz está desarrollado para soportar varios idiomas y culturas (formatos de moneda, fechas, etc.)

Así como la restricción de las operaciones que puede realizar un usuario en base al rol que tome en la aplicación, siendo estos roles totalmente parametrizables en base a dar acceso o restringir las diferentes funcionalidades para cada uno de los roles, pudiendo crear nuevos roles directamente desde la aplicación en caso de ser necesarios más perfiles que los aportados por defecto.



5 Toma de Requisitos

5.1 Proceso de Toma de Requisitos

La toma de requisitos se realizó en dos reuniones donde participaron por parte del cliente: el responsable del área comercial, el departamento legal, el del departamento de construcción y el responsable de TIC.

El proceso de toma de requisitos se basa en recoger los objetivos e intenciones que tienen los usuarios. No hay ningún diagrama que pueda substituir la redacción de estos objetivos. Con ello el proceso de toma de requisitos se basa en escribir los requisitos.

En la toma de requisitos es importante centrarnos en el objetivo del usuario y la intención con la que se usa el sistema. Es común cometer el error de contemplar la interfaz de usuario en la toma de requisitos.

Como ejemplo simple podemos abordar la funcionalidad de validarse en la aplicación. Podríamos pensar en:

“Se presenta al usuario la pantalla de validación donde introduce su nombre de usuario y su contraseña para identificarse en la aplicación”.

En el caso anterior se hace referencia a la interfaz de usuario como “Pantalla de validación”. Es mejor describir la intención del usuario;

“El usuario se identifica en la aplicación”.

Podría ser que una vez analizada la funcionalidad necesaria se propusiese un sistema de lector de huellas dactilares como interfaz de validación de identidad y no una pantalla.

Es importante centrarse en los objetivos del usuario para entender las motivaciones y los resultados que espera.

5.2 Documento de Toma de Requisitos

(Ver anexo: Toma Requisitos - Gestión Comercial Promociones).



5.3 Requisitos Funcionales

Teniendo presente que el objetivo es crear una aplicación para la gestión de la comercialización, de la toma de requisitos podemos extraer la siguiente lista de requisitos funcionales.

1. Gestión Agencias 1.1. Alta Agencias 1.2. Modificación Agencias

2. Gestión Usuarios 2.1. Alta Usuarios 2.2. Modificación Usuarios

3. Gestión Roles 3.1. Alta Roles 3.2. Modificación Permisos Rol

4. Gestión Promociones 4.1. Alta Promociones 4.2. Modificación Promociones 4.3. Gestión Agencias Permitidas 4.4. Gestión Apartamentos

4.4.1. Alta Apartamentos 4.4.2. Modificación Apartamentos 4.4.3. Adjuntar Ficheros e Imágenes

5. Gestión Tarifas 5.1. Alta Tarifas 5.2. Modificación Tarifas 5.3. Histórico de Tarifas

6. Gestión de Clientes 6.1. Alta Clientes 6.2. Modificación Clientes 6.3. Encuesta Marketing

7. Gestión de Operaciones Comerciales 7.1. Selección de Apartamentos 7.2. Reservas

7.2.1. Realizar Reservas 7.2.2. Anulación Automática Reservas



7.3. Ventas

7.3.1. Realizar Ventas 7.3.1.1. Ventas Nuevas 7.3.1.2. Ventas de Reservas

7.3.2. Cambio Tarifa Venta 7.3.3. Gestión Pagos

7.3.3.1. Alta Pagos 7.3.3.2. Modificación Pagos

7.3.4. Confirmar Venta 7.3.5. Anular Venta 7.3.6. Cambiar Cliente Venta 7.3.7. Gestión de Contratos Arras

7.3.7.1. Asignar Tipo Contrato Arras 7.3.7.2. Impresión Contrato Arras

8. Listados e Informes 8.1. Resumen Estado Comercial Promoción 8.2. Listado Ventas 8.3. Listado Pagos por Fecha 8.4. Listado Reservas

5.4 Requisitos Previos %o Funcionales

• Desarrollo Web: Por la dispersión geográfica de los usuarios es la forma más útil de acceso al aplicativo. Posibilitando en un futuro la adaptación de la interfaz para dispositivos móviles provistos con navegador web.

• Multi-Cultura: El interfaz del aplicativo, textos en pantalla, literales descriptores, calendarios, monedas, usos horarios debían de adaptarse a varios idiomas y países, lo que entendemos por globalizar y localizar.

• Facilidad de uso y auto-guía: La aplicación se usa en países donde el usuario medio tiene poca formación y experiencia en el uso de aplicaciones informáticas, se incide en la facilidad de uso y la auto-guía del usuario por parte de la aplicación en los procesos de negocio.

• Accesibilidad mediante permisos: Se necesitaba un sistema que permitiese flexibilidad máxima en cuanto a restringir o autorizar a los diferentes usuarios a realizar unas acciones y no otras.

• Flexibilidad en Ampliación de funcionalidades y modificaciones rápidas: Debido a que era la primera vez que usaban una herramienta de gestión no tenían la experiencia para proporcionar todos los detalles funcionales de la aplicación. Por ello necesitaban añadir y modificar funcionalidades según se iban encontrando con casos de uso no previstos.



6 Tecnología Aplicada Plataforma Tecnológica: MICROSOFT .NET FRAMEWORK 2.0

• Lenguaje de programación: Se usa ASP .NET 2.0 para la interfaz web y C# 2.0 para el desarrollo de la capa de lógica de negocio y de comunicación con la base de datos.

• Base de datos: SQL SERVER 2005 en su versión Express (Gratuita) para desarrollo y SQL SERVER 2005 ENTERPRISE en el entorno de producción.

• Servidor Web: Internet Information Server 6 o 7.

• Seguridad: Se utiliza acceso seguro usando el protocolo https implementado mediante un certificado de servidor SSL (Secure Sockets Layer) con objetivo de proporcionar autenticación y privacidad mediante el uso de criptografía. La Autenticación se obtiene sobre el servidor (garantizando su identidad y evitando el phishing) y la privacidad se consigue mediante los protocolos SSL de comunicación cliente–servidor que están diseñados para prevenir escuchas. Esta implementación de seguridad es casi obligada ya que la aplicación maneja datos personales sensibles. Así mismo las contraseñas de usuario se guardan cifradas en la base de datos para impedir el acceso a la aplicación aun cuando se pudiese acceder a ver el contenido de la tabla usuarios en la base de datos. Para intentar minimizar la posibilidad de que un intruso realice operaciones usando la conexión ya abierta de un usuario legítimo, la caducidad de la sesión se establece a 20 minutos.

Motivos de la elección a usar la plataforma .NET son:

• Integración de todas estas tecnologías bajo una herramienta común para el diseño, Visual Studio .NET 2005, lo que permite reducir el tiempo de codificación.

• Experiencia previa del equipo de desarrollo en esta tecnología con lo que la curva de aprendizaje es muy suave.

• La infraestructura de TI de la empresa cliente está basada completamente en los productos de Microsoft.



7 Metodología utilizada

7.1 El Proceso Unificado

Para el desarrollo de este proyecto se ha seguido la metodología conocida como Proceso Unificado que es un ejemplo de proceso iterativo.

Este es un proceso de desarrollo de software; describe un enfoque para la construcción, desarrollo y mantenimiento del software.

El Proceso Unificado es un ejemplo que utiliza un proceso iterativo para proyectos que utilizan el Análisis y Diseño Orientado a Objetos (A/DOO). Este se ha convertido en un proceso de desarrollo de software de gran éxito en la construcción de sistemas orientados a objetos.

El UP combina las prácticas comúnmente aceptadas como “buenas prácticas”, tales como el ciclo de vida iterativo y desarrollo dirigido por el riesgo, en una descripción consistente y bien documentada.

El UP fomenta muchas buenas prácticas, pero una destaca sobre las demás: el desarrollo iterativo. En este enfoque el desarrollo se organiza en una serie de mini-proyectos cortos, de duración fija (por ejemplo 4 semanas) llamados iteraciones. Cada iteración incluye sus propias actividades de análisis de requisitos, diseño, implementación y pruebas. Dando como resultado un sistema ejecutable, pero incompleto; no está preparado para ser puesto en producción. El sistema no podría estar listo para su puesta en producción hasta después de muchas iteraciones; dependiendo de la complejidad del mismo.

El ciclo de vida iterativo se basa en la ampliación y refinamiento sucesivos del sistema mediante múltiples iteraciones, con retroalimentación cíclica y adaptación como elementos primordiales que dirigen para converger hacia un sistema adecuado al problema que se está tratando. El sistema crece incrementalmente a lo largo del tiempo, iteración tras iteración, y por ello este enfoque también se conoce como desarrollo iterativo e incremental.

Aunque en general cada iteración aborda nuevos requisitos y amplía el sistema incrementalmente, una iteración podría, ocasionalmente, volver sobre el software que ya existe y mejorarlo; por ejemplo mejorando el rendimiento de un subsistema en lugar de extenderlo con nuevas características.

Las primeras ideas sobre procesos iterativos se conocieron como desarrollo en espiral y desarrollo evolutivo [Boehm88, Gilb88].

En este proceso iterativo la idea clave es fijar la duración de las iteraciones, generalmente cortas (entre 2 y 6 semanas). El sistema parcial en desarrollo durante la iteración debería integrarse, probarse y estabilizarse en la fecha planificada. Si parece que será difícil cumplir con el plazo fijado, la respuesta recomendada es eliminar tareas o requisitos de la iteración, en incluirlos en una iteración posterior, más que retrasar la fecha de terminación prevista.

Los beneficios del desarrollo iterativo incluyen:



• Mitigación tan pronto como sea posible de riesgos altos (técnicos, requisitos, objetivos, usabilidad y demás)

• Progreso visible en las primeras etapas.

• Una temprana retroalimentación, compromiso de los usuarios y adaptación, que nos lleva a un sistema refinado que se ajusta más a las necesidades reales del personal involucrado.

• Gestión de la complejidad; el equipo no se ve abrumado por la “parálisis del análisis” o pasos muy largos y complejos.

• El conocimiento adquirido en una iteración se puede utilizar metódicamente para mejorar el propio proceso de desarrollo, iteración a iteración.

Conceptos y buenas prácticas del UP adicionales

• Abordar cuestiones de alto riesgo y muy valiosas en las primeras iteraciones.

• Involucrar continuamente a los usuarios para evaluación, retroalimentación y requisitos

• Construir en las primeras iteraciones una arquitectura que constituya un núcleo central consistente

• Verificar la calidad continuamente; pruebas muy pronto, con frecuencia y de manera realista.

• Aplicar casos de uso.

• Modelar Software visualmente con UML.

• Gestionar los requisitos con cuidado.

• Manejar peticiones de cambio y gestión de configuraciones.



Un proyecto que utiliza la metodología UP organiza el trabajo y las iteraciones en cuatro fases fundamentales.

1. Inicio: Visión aproximada, análisis de negocio, alcance, estimaciones imprecisas.

2. Elaboración: visión refinada, implementación iterativa del núcleo central de la arquitectura, resolución de los riesgos altos, identificación de más requisitos y alcance, estimaciones más realistas.

3. Construcción: implementación iterativa del resto de requisitos de menor riesgo y elementos más fáciles, preparación para el despliegue.

4. Transición: pruebas beta, despliegue.

Esto no corresponde con el antiguo ciclo de vida en cascada o secuencial, en el que primero se definían todos los requisitos y, después, se realizaba todo, o la mayoría del diseño.

La fase de Inicio no es una fase de requisitos; sino una especie de fase de viabilidad, donde se lleva a cabo sólo el estudio suficiente para decidir si continuar o no.

De igual modo, la fase de Elaboración no es la fase de requisitos o de diseño; sino que es una fase donde se implementa, de manera iterativa, la arquitectura que constituye el núcleo central y se mitigan las cuestiones de alto riesgo.

Referencias: UML y Patrones. LARMAN, C. ISBN: 84-205-3438-2



8 Análisis y Especificación

8.1 Modelo Conceptual

Piso

Promocion

Bloque Planta

1

*

Contiene

1

*

Contiene

Estado

* 1

Se aplica

Categoría

*

1

Pertenece

Tarifa

Cliente

Venta

UsuarioAgencia

Agencias_Promocion

Rol

0..1

*

0..1

1

1 *

Contiene

* 1

1

*

Realiza

*

1

A nombre

Reserva

*

1

A nombre

*

1

Realiza

Pago

1 *

Pagada Mediante

Moneda

*

1

Se realiza

DetalleVentaDetalleReserva

1..*

1

Contenida En

1

1

Registra Reserva De

1..*

1

Contenida En

1

1

Registra Venta De

1

*

Se aplica

1

*

Contiene



8.2 Diagrama de Estados Piso



8.3 Casos de Uso

Los casos de uso son un artefacto de la especificación UML, desempeñan un papel importante en cuanto nos dan la visibilidad de las operaciones que se requiere que realice el sistema desde el punto de vista de los actores. Los casos de uso se extraen del texto donde hemos recogido los requisitos durante las reuniones con el cliente, identificando las operaciones que realizan los actores junto con la intención u objetivo con el que lo hacen. Nos permite identificar las interacciones con el sistema y los límites del mismo.

Un actor es cualquier cosa con comportamiento, incluyendo el sistema que se está estudiando cuando solicita los servicios de otros sistemas. Los actores no son solamente roles que juegan personas, sino también organizaciones, software y máquinas. Se pueden clasificar en tres tipos.

• Actor Principal: Tiene objetivos de usuario que se satisfacen mediante el uso de los servios del Sistema en Discusión (SeD).

• Actor de Apoyo: Proporciona un servicio al SeD como por ejemplo información (Podría ser un servicio de información en tiempo real de las cotizaciones de las divisas, para calcular los importes en diferentes monedas). Normalmente se trata de un sistema informático, pero podría ser una organización o una persona.

• Actor Pasivo: está interesado en el comportamiento del caso de uso pero no participa activamente. No es principal ni de apoyo, por ejemplo podría ser la Agencia Tributaria del Estado.

Los actores que correspondan con usuarios los indicaremos con el dibujo de un muñeco, mientras que los Sistemas Externos los identificaremos situando el nombre del sistema dentro de un rectángulo indicando el estereotipo <<actor>>.

En el sistema en desarrollo no existe ningún actor que sea un sistema externo. Pero si diferenciaremos entre dos tipos de usuarios.

• Actor Usuario: El actor usuario es el que usa la aplicación como herramienta para desarrollar su actividad comercial.

• Actor Administrador: Es el usuario que configura la aplicación creando nuevas promociones, administrando los usuarios y las agencias comerciales, etc.

Realizando la extracción desde el texto buscamos los verbos que denotan uso, o interacción con el sistema. Así tenemos la siguiente lista de casos de uso.



Usuario Comercial

• Añadir Clientes

• Realizar Encuesta

• Seleccionar Pisos

• Generar Reserva

• Generar Operación de Venta

• Anular Reserva

• Confirmar Operación de Venta

• Anular Operación de Venta

• Asignar Contrato

Actor Administrador

• Gestionar Promociones

• Gestionar Usuarios

• Gestionar Agencias

• Gestionar Roles



8.3.1 Diagrama de Casos de Uso

Generar Operación

de Venta

Usuario

Administrador

Gestionar Agencias

Gestionar

Promociones

Sistema

Añadir Cliente

Generar Reserva

Seleccionar Pisos

«uses»

«uses»

Anular Reserva

Confirmar

Operación Venta

Anular Operacion

Venta

Asignar Contrato

Piso

«uses»

Encuesta

«uses»

Gestionar Usuarios

Gestionar Roles



8.3.2 Añadir Clientes

Caso de Uso: Añadir Clientes

Actores: Usuario

Tipo: Primario

Descripción: Este caso de uso corresponde con el proceso de creación y mantenimiento de los datos de los posibles clientes.

Requisitos: En caso de Alta de Cliente, disponer de los datos obligatorios referentes al cliente.

Escenario principal de Éxito:

Acciones de los Actores Respuesta del Sistema

1. El usuario indica que desea crear un nuevo cliente.

2. El sistema le muestra el formulario de introducción de los datos del cliente.

3. El usuario introduce los datos del cliente.

4. El sistema comprueba que se han introducido los datos obligatorios.

5. El sistema registra el nuevo cliente.

6. El sistema le muestra al usuario el formulario de la encuesta de marketing.

7. El usuario rellena el formulario de encuesta con las respuestas del cliente.

8. El Sistema registra los datos de la encuesta.

9. El sistema muestra un listado de clientes.



Diagrama Secuencia de Sistema

Sistema

Usuario

crearCliente()

IntroducirDatosCliente(datosCliente)

RellenarEncuesta()

Lista de clientes

presentar Encuesta

Formulario nuevo Cliente



8.3.3 Seleccionar Pisos

Caso de Uso: Seleccionar Pisos

Actores: Usuario

Tipo: Primario

Descripción: Este caso de uso corresponde con el proceso de seleccionar los pisos (llenar la Cesta) con los que se quiere realizar una operación de compra o de reserva. Solo se pueden seleccionar los pisos que estén en estado Disponible y que no tengan agencia propietaria asignada, en caso de que tengan una agencia propietaria asignada ésta debe ser a la que pertenezca el usuario que está realizando la selección. El funcionamiento debe ser como una “cesta de la compra” Pudiendo agregar y quitar de la selección y cancelar la cesta en cualquier momento.

Requisitos: Este caso de uso requiere tener permisos para seleccionar pisos. No tener ninguna selección en curso.



1. El usuario le indica al Sistema que desea iniciar una selección de pisos para una operación de Reserva o Pre-Venta.

2. El sistema muestra al usuario un listado con todos los pisos de la promoción.

3. El usuario selecciona el piso que desee el cliente. (debe estar en estado disponible de la lista y que no tenga agencia propietaria o bien si la tiene sea a la que pertenece el usuario)

4. Se añade el piso a la cesta. El usuario repite los pasos 3 y 4 hasta completar la selección con todos los pisos que formarán parte de la operación.

5. El Sistema muestra un resumen de los pisos seleccionados y le pide al usuario que escoja el cliente para el cual se realiza la operación.

6. El usuario pide el listado de clientes 7. El sistema muestra un listado de clientes y permite la selección de cualquiera de ellos.

8. El usuario selecciona el cliente al que se le reservan o realizan la operación de venta de los pisos seleccionados

9. El sistema le muestra los datos detallados del cliente para que complete los datos obligatorios y repase que sean correctos, en .



10. El usuario completa y valida los datos del cliente seleccionado.

11. El sistema muestra un resumen de los datos del cliente validado y pide que se escoja la operación a Realizar. [Reserva, Pre-Venta]

12. El usuario introduce las observaciones que crea oportunas y escoge la operación que desea realizar con los pisos seleccionados.

Extensiones:

8a. Creación del cliente en el momento de la elección de los pisos.

1. El cliente no está introducido en el sistema y el usuario le pide al sistema crear un nuevo cliente.

2. El sistema le muestra al usuario el formulario para introducir un nuevo cliente.

3. El Usuario rellena el formulario con los datos del cliente y acepta los datos.

4. El sistema registra el nuevo cliente y le muestra al usuario el listado de clientes en el que aparecerá el nuevo cliente.

5. El usuario selecciona el cliente recién creado al que se le van a reservar o pre-vender los pisos.

11a. Introducción del Comercial que realiza la venta.

1. El Sistema muestra un resumen de los datos del cliente validado y pide que se indique el comercial que ha realizado la operación.

2. El usuario escoge la agencia y el usuario al que se le atribuirá la operación de Reserva o Pre-venta que se va a realizar.



Diagrama de Secuencia del Sistema

Sistema

Usuario NuevaCesta()

añadirPisoCesta()

descripcion, totales

aceptarCesta()

Resumen Cesta

seleccionarClienteCesta()

formulario datos cliente

validarDatosCliente()

escoge Operacion



8.3.4 Generar Reserva

Caso de Uso: Generar Reserva

Actores: Usuario

Tipo: Primario

Descripción: Este caso de uso corresponde con el proceso de realizar una reserva de pisos a nombre de un cliente a espera de que aporte el comprobante de pago de las arras.

Requisitos: Este caso de uso requiere tener permisos para reservar pisos. Es necesario haber realizado el caso de uso Seleccionar pisos.



10. El usuario le indica al Sistema que desea realizar una reserva con la selección de pisos en curso y a nombre del cliente indicado.

11. El sistema registra la reserva de los pisos seleccionados a nombre del cliente indicado en la selección.

12. Cambia el estado de los pisos a Reservado.

13. Muestra los datos de la reserva registrada.

Escenario Alternativo:

2a. Se produce un error por el cambio de estado de uno de los pisos seleccionados.

1. El sistema detecta que uno de los pisos de la cesta han cambiado.

2. El sistema muestra un mensaje de error en la operación de reserva y cancela la selección de los pisos.

3. Vuelve a la pantalla del listado de pisos de la promoción




Sistema

Usuario

generarReserva(Cesta,Cliente)

mostrar reserva



8.3.5 Generar Operación de Venta

Caso de Uso: Generar operación de Venta.

Actores: Usuario

Tipo: Primario

Descripción: Este caso de uso corresponde con el proceso de crear una operación de venta de pisos a nombre de un cliente donde se deben registrar los datos del pago de arras.

Requisitos: Este caso de uso requiere tener permisos para Pre-Vender pisos. Es necesario disponer de una Cesta de pisos con uno o más pisos.



1. El usuario le indica al Sistema que desea realizar una operación de Venta con la selección de pisos en curso y a nombre del cliente indicado.

2. El sistema pide los datos del pago por cantidad correspondiente a la suma del importe de las arras de cada uno de los pisos que forman parte de la operación de venta a realizar.

3. El usuario introduce los datos del pago de las arras de la operación y los acepta.

4. El Sistema registra la operación de venta de los pisos a nombre del cliente seleccionado.

5. Se cambia el estado de los pisos que han participado en la operación a Pre-Venta.

6. Muestra los datos de la pre-venta recién realizada.

Escenario Alternativo:

2a. Se produce un error por el cambio de estado de uno de los pisos seleccionados.

4. El sistema detecta que uno de los pisos de la cesta ha cambiado.

5. El sistema muestra un mensaje de error en la operación de pre-venta y cancela la selección de los pisos.

6. Vuelve a la pantalla del listado de pisos de la promoción.




Sistema

Usuario

OperacionVenta()

Calcular total pago arras

introducirPago()

mostrar operación Venta

generarOperaciónVenta(Cesta,Cliente,Pago)



8.3.6 Anular Reserva

Caso de Uso: Anular Reserva

Actores: Usuario

Tipo: Primario

Descripción: Este caso de uso corresponde con el proceso cancelar una reserva ya formalizada.

Requisitos: Este caso de uso requiere tener permisos para Anular Reserva. Es necesario que la reserva esté realizada anteriormente.



1. El usuario accede a la reserva realizada.

2. El sistema muestra la reserva.

3. El usuario cancela la reserva. 4. El sistema marca la reserva como anulada.

5. El sistema cambia el estado de los pisos reservados en la operación de reserva a su estado inicial.

6. El sistema muestra la reserva como anulada.



Diagrama de Secuencia de Sistema



8.3.7 Confirmar Operación de Venta

Caso de Uso: Confirmar operación de venta

Actores: Usuario

Tipo: Primario

Descripción: Este caso de uso corresponde con el proceso de formalizar una operación de venta que se encuentra en estado de Pre-Venta una vez se ha comprobado que el pago de las arras se ha hecho efectivo, de este modo la operación de venta pasa de estado Pre-Venta a Venta.

Requisitos: Este caso de uso requiere tener permisos para Confirmar Operaciones de Venta. Es necesario que la operación de venta esté realizada anteriormente y se encuentre en estado de Pre-Venta.



1. El usuario accede a la operación de venta que desea confirmar.

2. El sistema muestra la operación de Venta.

3. El usuario Confirma que se ha recibido el pago de parte del cliente con el importe de las arras de la operación de Venta.

4. El sistema Registra el movimiento de Confirmación de la operación de venta.

5. El sistema cambia el estado de los pisos reservados en la operación Pre-venta a Venta.

6. El sistema muestra la operación de venta como confirmada.




Sistema

Usuario

seleccionarVenta(Venta)

mostrar operacion Venta

confirmarVenta(Venta)

mostrar operacion Venta confirmada



8.3.8 Anular Operación de Venta

Caso de Uso: Anular operación de venta

Actores: Usuario

Tipo: Primario

Descripción: Este caso de uso corresponde con el proceso de anular una operación de venta.

Requisitos: Este caso de uso requiere tener permisos para Anular Operaciones de Venta. Es necesario que la operación de venta esté realizada anteriormente y no esté anulada.



1. El usuario accede a la Operación de Venta que desea anular.


3. El usuario Confirma que desea anular esta operación de Venta.

4. El sistema Registra el movimiento de anulación de la operación de venta.

5. El sistema cambia el estado de los pisos reservados en la operación de Venta a su estado inicial.

6. El sistema muestra la operación de venta como anulada.




Sistema

Usuario


mostrar operacion Venta

anualarVenta(Venta)

mostrar operacion Venta Anulada



8.3.9 Asignar Contrato Piso

Caso de Uso: Asignar Contrato Piso

Actores: Usuario

Tipo: Primario

Descripción: Este caso de uso corresponde con la acción de Asignar el tipo de contrato de Arras al piso vendido y confirmado.

Requisitos: Este caso de uso requiere tener permisos para Asignar Contratos. Es necesario que la operación de venta esté realizada anteriormente y esté en estado Venta Confirmada.



1. El usuario accede a la Operación de Venta donde se encuentra el piso a asignar contrato.


3. El usuario selecciona el piso de la venta al que desea asignar el contrato.

4. El sistema muestra los tipos de contrato existentes para la promoción.

5. El usuario escoge el tipo de contrato que desea asignar al piso y añade las observaciones oportunas.

6. El sistema asigna o cambia el contrato al que haya asignado el usuario a este piso.

7. El sistema muestra el tipo de contrato en la operación para este piso y permite su impresión.

8. El usuario pide la impresión del contrato asignado.

9. El sistema devuelve el modelo del contrato rellenado con los datos referentes a la operación.




Sistema

Usuario


muestra detalle venta

seleccionarContrato(DetalleVenta)

tipos de contrato promoción

asignarContrato(DetalleVenta,Contrato)

muestra detalle venta

imprimirContrato(DetalleVenta)

contrato impreso cumplimentado



9 Diseño La fase de diseño se encarga de trasladar desde el enfoque centrado en los requisitos del Análisis a un enfoque centrado en el diseño de una solución que satisfaga estos requisitos.

Para llegar a obtener un diseño que hace lo correcto se desarrolla una solución lógica basada en el paradigma orientado a objetos. Lo esencial de esta solución es la creación de los diagramas de interacción que representan el modo en que los objetos colaboran para satisfacer los requisitos.

En paralelo con la creación de los diagramas de interacción (diagramas de secuencia y diagramas de colaboración), se creará el diagrama de clases. Éstos resumen la definición de las clases software que se van a implementar en el software.

La creación de los diagramas de interacción requiere la aplicación de los principios para la asignación de responsabilidades y el uso de los principios y patrones de diseño.

La asignación de responsabilidades nos indica que clases se tienen que encargar de realizar que acciones y no otras. Así como los patrones de diseño nos aportan soluciones bien conocidas a problemas recurrentes durante el diseño de aplicaciones software.

En cuanto a los diagramas de interacción tenemos dos tipos:

• Diagramas de colaboración: Ilustran las relaciones entre objetos en una forma de grafo o red, en el cual los objetos se pueden colocar en cualquier lugar del diagrama.

• Diagramas de secuencia: ilustran las interacciones en un tipo de formato con el aspecto de una valla, en el que cada objeto se añade a la derecha.



Cada uno de estos dos tipos de diagramas tienen sus puntos fuertes y sus puntos débiles:

Tipo Puntos fuertes Puntos débiles

Secuencia Muestra claramente la secuencia u ordenación en el tiempo de los mensajes.

Notación simple.

Fuerza a extender por la derecha cuando se añaden nuevos objetos; consume espacio horizontal.

Colaboración Economiza espacio, flexibilidad al añadir nuevos objetos en dos dimensiones.

Es mejor para ilustrar bifurcaciones complejas, iteraciones y comportamiento concurrente.

Difícil ver la secuencia de los mensajes.

Notación más compleja.

Dado que en este proyecto no se dan bifurcaciones complejas ni demasiadas iteraciones se opta por usar los diagramas de secuencia.

9.1

Dia

gra

ma d

e C

lase

s

Ge

stió

n C

om

erc

ial

de

Pro

mo

cio

ne

s In

mo

bil

iari

as

PF

C –

In

ge

nie

ría

In

form

áti

ca d

e G

est

ión

P

ág

ina

40

-usuario

-agencia

-rol

-cod_idioma

-nombre

-email

-apellido

-login

-password

-telefono1

-telefono2

-fax

-fecha_alta

-fecha_baja

-activo

+permisos

USUARIOS_VO

-agencia

-rol

-nombre

-telefono

-email

-fax

-persona_contacto

-telefono2

-fechaalta

AGENCIAS_VO

-rol

-nombre

-descripcion

ROLES_VO

-permiso

-nombre

-descripcion

PERMISOS_VO

-permisos_rol

-rol

-permiso

-concedido

PERMISOS_ROL_VO

-cod_idioma

-nombre

CULTURAS_VO

10..*

Entiende

0..*

1

Accede Como

1

1..*

Tiene Acceso

1..* 1

Se configura

1..* 1Pertenece

Ge

stió

n C

om

erc

ial

de

Pro

mo

cio

ne

s In

mo

bil

iari

as

PF

C –

In

ge

nie

ría

In

form

áti

ca d

e G

est

ión

P

ág

ina

41

Ge

stió

n C

om

erc

ial

de

Pro

mo

cio

ne

s In

mo

bil

iari

as

PF

C –

In

ge

nie

ría

In

form

áti

ca d

e G

est

ión

P

ág

ina

42

9.2 Diseño de Clases



#Adapter() : CULTURASTableAdapter

+GetCulturas() : CULTURASDataTable

-_culturasAdapter : CULTURASTableAdapter = null

Culturas

#pisosViewAdapter() : PISOS_VIEWTableAdapter

#pisosAdapter() : PISOSTableAdapter

#reservasAdapter() : RESERVASTableAdapter

#detalleReservaAdapter() : DETALLE_RESERVATableAdapter

#ventasAdapter() : VENTASTableAdapter

#movVentasAdapter() : MOV_VENTASTableAdapter

#detalleVentaAdapter() : DETALLE_VENTATableAdapter

#tarifaPisoAdapter() : TARIFAS_PISOSTableAdapter

#adjuntosPisosAdapter() : ADJUNTOS_PISOSTableAdapter

+GetPisosViewByPromocion(entrada Promocion : long, entrada Idioma : string) : PISOS_VIEWDataTable

+GetPisosViewByPromocionBloque(entrada Promocion : long, entrada Bloque : string, entrada Idioma : string) : PISOS_VIEWDataTable

+GetPisosViewByPiso(entrada Piso : long, entrada Idioma : string) : PISOS_VIEWDataTable

+GetPisosViewByPisoRow(entrada Piso : long, entrada Idioma : string) : PISOS_VIEWRow

+GetPisos() : PISOSDataTable

+GetPisoByPiso(entrada Piso : long) : PISOSRow

+ReservarPiso(entrada Reserva : RESERVAS_VO, entrada Piso : long) : bool

-RellenarFila(entrada reserva : RESERVAS_VO, entrada reservaRow : RESERVASRow) : RESERVASRow

-RellenarFila(entrada venta : VENTAS_VO, entrada ventaRow : VENTASRow) : VENTASRow

-RellenarFila(entrada movVenta : MOV_VENTAS_VO, entrada movVentaRow : MOV_VENTASRow) : MOV_VENTASRow

+CrearReserva(entrada reserva : RESERVAS_VO, entrada pisos : PISOS_VIEWRow[]) : RESERVAS_VO

+GetPisosViewByReserva(entrada Reserva : long, entrada Idioma : string) : PISOS_VIEWDataTable

+GetTarifaPisoActiva(entrada Piso : long) : TARIFAS_PISOSRow

+CrearVenta(entrada venta : VENTAS_VO, entrada movVenta : MOV_VENTAS_VO, entrada pisos : PISOS_VIEWRow[]) : VENTAS_VO

+CrearVentaDeReserva(entrada Reserva : long, entrada venta : VENTAS_VO, entrada movVenta : MOV_VENTAS_VO, entrada pisos : PISOS_VIEWRow[]) : VENTAS_VO

+confirmarVenta(entrada Venta : long, entrada usuario : USUARIOS_VO, entrada Observaciones : string) : bool

+anularVenta(entrada Venta : long, entrada usuario : USUARIOS_VO, entrada Observaciones : string) : bool

+cambiarClienteVenta(entrada Venta : long, entrada nuevoCliente : long, entrada usuario : USUARIOS_VO, entrada Observaciones : string) : bool

+cambiarContratosVenta(entrada Venta : long, entrada nuevasTarifas : ArrayList, entrada usuario : USUARIOS_VO, entrada Observaciones : string) : bool

+cambiarTarifaVenta(entrada Venta : long, entrada nuevasTarifas : ArrayList, entrada usuario : USUARIOS_VO, entrada Observaciones : string) : bool

+EscriturarPiso(entrada Piso : long) : bool

+EscriturarParcialVenta(entrada Venta : long, entrada usuario : USUARIOS_VO, entrada Pisos : ArrayList, entrada Observaciones : string) : bool

+ObtenerAdjuntosPiso(entrada Piso : long) : ADJUNTOS_PISOSDataTable

-TraspasarAdjuntoPisoAAdjuntoPisoRow(entrada adjunto : ADJUNTOS_PISOS_VO, entrada adjuntoRow : ADJUNTOS_PISOSRow) : ADJUNTOS_PISOSRow

+CrearAdjuntoPiso(entrada AdjuntoPiso : ADJUNTOS_PISOS_VO) : bool

+EliminarAdjuntoPiso(entrada AdjuntoPiso : ADJUNTOS_PISOS_VO) : bool

+CrearVenta(entrada venta : VENTAS_VO, entrada movVenta : MOV_VENTAS_VO, entrada pisos : PISOS_VIEWRow[], entrada pago : MOV_PAGOS_VO) : VENTAS_VO

+CrearVentaDeReserva(entrada Reserva : long, entrada venta : VENTAS_VO, entrada movVenta : MOV_VENTAS_VO, entrada pisos : PISOS_VIEWRow[], entrada pago : MOV_PAGOS_VO) : VENTAS_VO

+CambiarEstadoPiso(entrada Estado : ESTADOS_VO) : Pisos

-_pisosViewAdapter : PISOS_VIEWTableAdapter = null

-_pisosAdapter : PISOSTableAdapter = null

-_reservasAdapter : RESERVASTableAdapter = null

-_detalleReservaAdapter : DETALLE_RESERVATableAdapter = null

-_ventasAdapter : VENTASTableAdapter = null

-_detalleventaAdapter : DETALLE_VENTATableAdapter = null

-_tarifaPisoAdapter : TARIFAS_PISOSTableAdapter = null

-_movVentasAdapter : MOV_VENTASTableAdapter = null

-_adjuntosPisosAdapter : ADJUNTOS_PISOSTableAdapter = null

Pisos

#Adapter() : USUARIOSTableAdapter

+GetUsuarios() : USUARIOSDataTable

+GetUsuarioByLogin(entrada Login : string, entrada Pass : string) : USUARIOSRow

+GetUsuarioByPrimaryKey(entrada Usuario : long) : USUARIOSRow

+GetUsuarioByUsuario(entrada Usuario : long) : USUARIOSDataTable

+GetUsuario_ViewByPrimaryKey(entrada Usuario : long) : USUARIOS_VIEWRow

+GetUsuarioViewByPrimaryKey(entrada Usuario : long) : USUARIOS_VIEWDataTable

+GetUsuarios_ViewByAgencia(entrada Agencia : long) : USUARIOS_VIEWDataTable

-traspasarUsuarioAUsuarioRow(entrada usuario : USUARIOS_VO, entrada usuarioRow : USUARIOSRow)

-traspasarUsuarioRowAUsuario(entrada usuarioRow : USUARIOSRow, entrada usuario : USUARIOS_VO)

+UpdateUsuario(entrada Original_Usuario : USUARIOS_VO, entrada Usuario : USUARIOS_VO) : bool

+InsertUsuario(entrada Usuario : USUARIOS_VO) : long

+ChangeUsuarioActivo(entrada Usuario : USUARIOS_VO) : bool

+validarLogin(entrada login : string, entrada password : string) : USUARIOS_VO

-_usuariosAdapter : USUARIOSTableAdapter = null

Usuarios

#bloquesAdapter() : BLOQUESTableAdapter

#promocionesAdapter() : PROMOCIONESTableAdapter

#promocionesViewAdapter() : PROMOCIONES_VIEWTableAdapter

#totalPisosPromocionViewAdapter() : TOTAL_PISOS_PROMOCION_VIEWTableAdapter

+GetBloquesByPromocion(entrada Promocion : long) : BLOQUESDataTable

+GetPromociones() : PROMOCIONESDataTable

+GetPromocionesPermitidasByAgenciaAsignada(entrada Agencia : long) : PROMOCIONESDataTable

+GetPromocionesByAgenciaAsignadaActiva(entrada Agencia : long) : PROMOCIONESDataTable

+GetPromocionesByAgenciaAsignada(entrada Agencia : long) : PROMOCIONESDataTable

+NumeroDePromocionesParaAgencia(entrada Agencia : long) : int

+GetPromocion(entrada Promocion : long) : PROMOCIONESDataTable

+GetPromocionesView(entrada Idioma : string) : PROMOCIONES_VIEWDataTable

+GetPromocionView(entrada Idioma : string, entrada Promocion : long) : PROMOCIONES_VIEWDataTable

-RellenarFila(entrada Promocion : PROMOCIONES_VO, entrada PromocionRow : PROMOCIONESRow) : PROMOCIONESRow

+ActualizarPromocion(entrada Promocion : PROMOCIONES_VO) : bool

+InsertarPromocion(entrada Promocion : PROMOCIONES_VO) : bool

+TotalPisosPromocion(entrada Promocion : long) : long

-_bloquesAdapter : BLOQUESTableAdapter = null

-_promocionesAdapter : PROMOCIONESTableAdapter = null

-_promocionesViewAdapter : PROMOCIONES_VIEWTableAdapter = null

-_totalPisosPromocionViewAdapter : TOTAL_PISOS_PROMOCION_VIEWTableAdapter = null

Promocion

#reservasAdapter() : RESERVASTableAdapter

#reservasViewAdapter() : RESERVAS_VIEWTableAdapter

#detalleReservaViewAdapter() : DETALLE_RESERVA_VIEWTableAdapter

+CalcularCaducidad(entrada hoy : DateTime, entrada dias : double) : DateTime

+GetReservasViewByPrimaryKey(entrada Reserva : long) : RESERVAS_VIEWDataTable

+GetReservasViewByAgenciaPromocion(entrada Agencia : long, entrada Promocion : long) : RESERVAS_VIEWDataTable

+GetReservasViewByPromocion(entrada Promocion : long) : RESERVAS_VIEWDataTable

+anularReserva(entrada Reserva : long)

+GetDetalleReservaViewByPisoActiva(entrada Piso : long) : DETALLE_RESERVA_VIEWDataTable

-_reservasAdapter : RESERVASTableAdapter

-_reservasViewAdapter : RESERVAS_VIEWTableAdapter

-_detalleReservaViewAdapter : DETALLE_RESERVA_VIEWTableAdapter

Reservas



9.3 Diagramas de Secuencia

9.3.1 Seleccionar Pisos Operación

: Cesta

Cesta

AddPiso

: Pisos

GetPisosViewByPiso

: Clientes

ObtenerClientes

Cliente

: Usuario

Mostrar Detalle Cesta

Seleccionar Cliente



9.3.2 Acción Crear Reserva



9.3.3 Acción Anular Reserva



9.3.4 Acción Crear Venta

: Cesta

Cesta

AddPiso

: Pisos

GetPisosViewByPiso:=GetPisosViewByPiso(Piso, Idioma)

: Clientes : Pagos

ObtenerClientes:=ObtenerClientes()

NuevoPagoVenta:=NuevoPagoVenta(pago)

: Ventas

CrearVenta:=CrearVenta(venta, movVenta, pisos, pago)

ObtenerClienteByPrimaryKey:=ObtenerClienteByPrimaryKey(Cliente)

: Usuario

Mostrar Detalle Venta



9.3.5 Acción Confirmar Venta

: Usuario

: Pisos: Ventas

GetVentasViewByPrimaryKey:=GetVentasViewByPrimaryKey(Idioma, Venta)

CambiarEstadoPiso:=CambiarEstadoPiso(Estado)

GetMovimientosVentasView:=GetMovimientosVentasView(Idioma)

confirmarVenta:=confirmarVenta(Venta, usuario, Observaciones)

Venta Confirmada



9.3.6 Acción Anular Venta



9.3.7 Asignar Contrato Venta



9.3.8 Añadir Cliente

: Clientes

NuevoCliente()

: Usuario

Mostrar Detalle Reserva

InsertarCliente:=InsertarCliente(Cliente)

Mostrar Formulario Cliente

traspasarClienteAClienteRow:=traspasarClienteAClienteRow(Cliente, ClienteRow)



9.3.9 Rellenar Encuesta



9.4 Diseño de la Capa Gestión de Datos

El diseño de la capa de gestión de datos se ha realizado utilizando los servicios de persistencia que ofrece el Framework de Visual Studio 2005. Este se basa en objetos “DataSet” fuertemente tipados (un “DataTable” por cada tabla y vista). Estos objetos no ofrecen el acceso a datos utilizando el paradigma de Orientación a Objetos sino que usan un acceso tabular a los mismos.

Estos DataSet fuertemente tipados se generan automáticamente mediante el diseñador de objetos de acceso a datos que provee Visual Studio 2005. En este diseñador se arrastran las entidades (Tablas y Vistas) desde una conexión a la base de datos y este genera automáticamente una clase que hereda de DataTable que contiene métodos con las funciones CRUD (Create, Read, Update and Delete), crear un nuevo registro en la entidad, seleccionar todos los registros de la entidad, actualizar un registro y borrar el registro. Se pueden ampliar los métodos de selección, creando nuevos métodos a partir de sentencias de SQL con las clausulas de filtrado que convengan.

Estos DataTable tipados contienen una colección de objetos que heredan de DataRow que representan las filas de la tabla o vista y proporcionan acceso a los atributos de cada fila de forma individual.

Al tratarse de un entorno multiusuario tenemos que controlar los posibles accesos concurrentes a los datos. Para este propósito existen 2 métodos:

1. Concurrencia Optimista: Se comprueba que los datos que se van a modificar no los han modificado antes otros usuarios.

2. Concurrencia Pesimista: Se bloquean las filas para impedir que los usuarios modifiquen los datos y que otros usuarios queden afectados.

En este caso hemos elegido el método de Concurrencia Optimista debido a que no existe una alta contención de datos, y se estima que los casos de conflicto no se producirán recurrentemente, Además, al contrario que el método por concurrencia pesimista, no necesita conexiones permanentes a la base de datos con el consiguiente ahorro de recursos y ahorrando complejidad en el desarrollo.



Como alternativas a esta implementación existen otros frameworks de acceso a datos integrados con la tecnología .Net que si que cumplen el paradigma de orientación a objetos y se conocen como OR/M (Object Relational Mapping), como muestra podemos encontrar una amplia comparativa realizada sobre distintos OR/M disponibles para la plataforma .NET de Microsoft en http://c2.com/cgi/wiki?ObjectRelationalToolComparisonDotNet .

Como ejemplo citaremos dos de ellos:

• NHibernate (http://nhibernate.sourceforge.net): Es Open Source y es una portabilidad a .Net del conocido OR/M de Java Hibernate.

• LLBLGen Pro (http://www.llblgen.com). Es un OR/M de código cerrado y de pago en su versión Professional. Existe una versión recortada gratuita.

• LINQ to SQL (http://msdn.microsoft.com/en-us/library/bb425822.aspx): Este OR/M está disponible con la versión 3.5 del Framework .NET y completamente integrado con las herramientas de diseño de aplicaciones Visual Studio 2005 (mediante un plugin) y de forma nativa en el reciente Visual Studio 2008.



10 Análisis de Recursos y Costos

10.1 Análisis de Recursos

Dado que se usa una metodología iterativa donde en cada iteración es necesario retomar y extender las tareas tanto de análisis como de diseño, implementación y pruebas, vamos a tener que usar los recursos especializados en cada tarea de forma recurrente durante la vida del proyecto.

En los proyectos que siguen la metodología del Proceso Unificado existen estudios sobre la dedicación de los recursos en cada una de las tareas (Análisis, diseño, implementación y pruebas) para cada una de las fases que componen el desarrollo del proyecto.

En el gráfico podemos apreciar el nivel de uso que se suele tener de media en los proyectos que usan la metodología Proceso Unificado.

Vemos que el mayor esfuerzo en las tareas de Modelado y Análisis se sitúan en las primeras fases del proyecto, así como las tareas de implementación se mantienen bastente estables durante toda la duración del proyecto.

Para este proyecto, que no es demasiado complejo, se han utilidado los siguientes recursos humanos: un Jefe de proyecto, un Analista Funcional, un Analista Orgánico y un programador; junto con un técnico de sistemas que realizará la implantación y configuración de los sistemas en el entorno de producción.

La duración del proyecto se planifica para un total de 57 días laborables.

(Ver Anexo: Planificación Temporal Fases y Recursos)

10.1.1 Informe de resumen de trabajo de los Recursos

Este informe se ha realizado considerando una disponibilidad de 8 horas diarias por recurso y teniendo en cuenta toda la duración del proyecto.

10.2 Análisis de Costos

Una vez llevada a cabo la estimación de tiempos y recursos necesarios para el diseño, implementación y despliegue del proyecto debemos calcular el coste del mismo con objetivo de presentarle al cliente un plan de actuación, unas fechas de entrega y una volaración económica del coste que le va a suponer.

Para realizar la estimación se va a utilizar el metodo de valorar el precio por hora de cada recurso y multiplicarlo por el tiempo en horas que está previsto que invertirá en el proyecto.

10.2.1 Costos por Recurso

Se han estimado los costos por recurso en relación al precio ofertado a los clientes por empresas consultoras. El coste sería menor en caso de que el proyecto lo realizase un equipo FreeLancer o una pequeña empresa.

10.2.2 Tabla de costes por tipo de Recurso

Tipo Recurso Coste Hora Coste Hora Extra

Jefe de Proyecto 100,00 €/hora 120,00 €/hora

Analista Funcional 90,00 €/hora 105,00 €/hora

Analista Orgánico 80,00 €/hora 95,00 €/hora

Programador 60,00 €/hora 70,00 €/hora

Admin. Sistemas 80,00 €/hora 95,00 €/hora

Se han estimado las siguientes horas totales por recurso:

Jefe de Proyecto: 68 horas * 100 €/hora = 680 €

Analista funcional: 130 horas * 90 €/hora = 11.700 €

Analista organico: 128 horas * 80 €/hora = 10.240 €

Programador: 320 horas * 60 €/hora = 19.200 €

Sistemas: 16 horas * 80 €/hora = 1.280 €

Coste total del proyecto = 43.100 €

10

.2.3

Info

rme

de

cost

o p

revi

sto

por

fas

e

11 Conclusiones Una vez finalizado el desarrollo y puesto en producción se detectan áreas del proceso de comercialización que claramente que se pueden incluir en las funcionalidades de la misma.

Como ampliaciones se proponen:

• Gestión de las reclamaciones que puedan surgir por parte de los clientes o de la propia promotora en cuanto a los acabados o defectos detectados en los apartamentos.

• Gestión más detallada del proceso de venta una vez se ha formalizado el contrato de Arras; como un seguimiento de la documentación que debe aportar el cliente, citas con el notario y el banco en caso de tratarse de una financiación hipotecaria. Reclamaciones comerciales del cliente.

• Realizar un almacén de datos DatawareHouse para explotarlos desde el punto de vista de la directiva, lo que se conoce como Business Intelligence.

• Implementar la reserva de pisos desde dispositivos móviles.

• Integración con otros sistemas empresariales como el de contabilidad mediante estándares de la industria.

He de indicar que desde el proceso de modelado de dominio, diseño e implementación se ha utilizado una metodología aplicada al paradigma de Orientación a Objetos. Estos métodos y sus herramientas no son los que se impartían en la carrera de Informática de Gestión cuando cursaba las asignaturas relacionadas. Para la confección de este proyecto he utilizado los conocimientos sobre A/DOO que he adquirido por auto-formación durante el desarrollo de mi carrera profesional.

Documents

MEMORIA PFC GESTIÓN COMERCIAL DE …upcommons.upc.edu/bitstream/handle/2099.1/5410/Memòria.pdf · Inmobiliaria: Una parte del proyecto ha sido buscar y analizar qué productos se