UNIVERSIDAD TECNOLÓGICA PRIVADA DE SANTA CRUZ

COD: PO-DFG-100-4
SOCIEDAD ANÓNIMA
VER: 2
CASO DE ESTUDIO – EXAMEN DE GRADO
VIGENTE: 05-07-2017

CÓDIGO <EG-S-BD-02-20>

ÁREA: Bases de datos y sistemas de información

CASO: Sistema de gestión administrativo para la venta de lotes de terrenos de la urbanización

“SacaGuazu” para la empresa “Penta Solución”

Se necesita un sistema de información que gestione los terrenos que se tienen disponibles para la venta, los
interesados en comprar un terreno, los clientes que compraron un lote y las cuotas de los mismos si es que lo
están pagando a crédito.
La empresa de venta de terrenos “Penta Solución”, ha recibido los planos autorizados para la para la urbanización
“SacaGuazu” y ahora tiene que vender los lotes de terreno que están disponibles.
Cada lote de terreno está definido por 4 puntos que conforman el tamaño y posición del lote. Cada punto está
conformado por latitud y longitud (geoposicionamiento), ya que el diseño de cada terreno en la urbanización fue
dibujado con ayuda de imágenes satelitales.
Cuando una persona se acerca a preguntar por los lotes, es política de la empresa registrarlo como posible cliente,
alguien a quien se le podrá ofrecer otros terrenos en el futuro. La persona que quiere comprar un lote puede hacerlo
de dos maneras, al contado y al crédito.
Cuando una persona compra el lote, este es asignado en el sistema con el nombre del propietario del lote dejando
de estar disponible. El sistema debe ser capaz de mostrar un plano de los lotes indicando cuales están disponibles y
cuáles no.
Cuando una persona compra un lote al crédito se generan de manera automática, como no pagadas, todas las cuotas
asignadas a un mes y una gestión, que este deberá cancelar.
El sistema debe estar desarrollado para un entorno web, ya que hay varias formas de ofrecer lotes: desde el
teléfono celular, computadora de escritorio o tableta, desde donde se puede mostrar la disponibilidad de
terrenos.
De manera adicional si una persona está interesada en un lote, pero todavía no se decide a comprarlo puede
reservarlo con un pago de 100$. Esta reserva dura 2 meses. Después de este periodo la reserva queda anulada, el
dinero de la reserva es devuelto al cliente y este tiene la opción de volver a reservarlo o no.
Al ser consultado el encargado de sistemas, indico que lo más importante para poder iniciar la venta de los
terrenos es poder mostrarlos en una interface grafica. De esta manera se puede mostrar a los potenciales
clientes los lotes que están disponibles, los reservados y los que ya han sido vendidos. Para poder hacer esto en
el sistema ya deberían tener registrados los lotes con los 4 puntos cartesianos ya antes mencionados.

Página 1 de 4
 UNIVERSIDAD TECNOLÓGICA PRIVADA DE SANTA CRUZ
COD: PO-DFG-100-4
SOCIEDAD ANÓNIMA
VER: 2
CASO DE ESTUDIO – EXAMEN DE GRADO
VIGENTE: 05-07-2017

ESTRUCTURA DE PRESENTACION DEL TRABAJO

CARÁTULA
ÍNDICE
ENUNCIADO DEL CASO DE ESTUDIO
I. ASPECTOS GENERALES
• Título del proyecto
• Introducción
• Planteamiento del problema
• Delimitaciones
• Objetivo General
• Objetivos Específicos

II. MARCO TEORICO

XP + SCRUM PUDS
El manifiesto ágil Lenguaje Unificado de Modelado (UML)
Metodología XP  Diagramas más usados
 Fases de XP Proceso unificado de Modelado (PUDS)
Los valores de XP Fases del PUDS
Ciclo de vida de XP Dirigido por casos de uso
 Fases de XP  Caso de uso
Marco de trabajo SCRUM Centrado en la arquitectura
Historias de usuario  Modelos o vistas del PUDS
 Elementos de una historia de usuario Iterativo e incremental
El Product Owner  Ciclo de vida del PUDS
El Scrum Master
Product backlog
Planning Poker
Ambas metodologías
Arquitectura del sistema y/o patrones de desarrollo
 N capas, MVC, etc
Lenguajes
 Java, C#, Php, Python, etc.
Frameworks
 Java, .net, Laravel, etc.

Página 2 de 4
 UNIVERSIDAD TECNOLÓGICA PRIVADA DE SANTA CRUZ
COD: PO-DFG-100-4
SOCIEDAD ANÓNIMA
VER: 2
CASO DE ESTUDIO – EXAMEN DE GRADO
VIGENTE: 05-07-2017

Plataforma
Mobil, Escritorio, embebido, etc. Base de datos
Sqlserver, sqlite, mysql, etc.
IDE
Eclipse, NetBeans, VisualStudio

III. INGENIERIA DEL PROYECTO

XP + SCRUM PUDS
Fase de exploración Modelo de Requisitos
 Requisitos no funcionales  Diagrama de clases conceptuales
 Diagrama de clases conceptuales (modelo de dominio)
 Product Backlog - Historias de usuario  Requerimientos no funcionales
Fase de planificación de la entrega (Release Plan)  Requerimientos funcionales
 Priorización de las historias de usuario  Descripción de los actores
 Estimación de esfuerzo por puntos Modelo de Análisis
Fase de Iteraciones: (para cada sprint)  Diagrama general de los casos de uso
 Sprint Backlog (todos)
 Burn Down Chart  Especificación del o los casos de uso
 Pruebas de aceptacion seleccionados.
 Incremento Modelo de Diseño
Fase de producción:  Diagrama de secuencia
 Diagrama de clases de diseño  Diagrama de clases de diseño
 Normalización de la base de datos
 Normalización de la base de datos
o Modelo de datos relacional o Modelo de datos relacional
(modelo de base de datos (modelo de base de datos
lógico/físico) lógico/físico)
 Diseño de reportes  Diseño de reportes
 Triggers  Triggers
 Consultas más complejas  Consultas más complejas
 Procedimientos almacenados  Procedimientos almacenados
Fase de mantenimiento Modelo de Implementación
 Plan de backup de base de datos  Diagrama de Componentes
 Diagrama de Despliegue
Fase de muerte del proyecto
 Plan de backup de base de datos
 Rendimiento del sistema
Modelo de pruebas
 Confiabilidad del sistema
 Caso de pruebas

Página 3 de 4
 UNIVERSIDAD TECNOLÓGICA PRIVADA DE SANTA CRUZ
COD: PO-DFG-100-4
SOCIEDAD ANÓNIMA
VER: 2
CASO DE ESTUDIO – EXAMEN DE GRADO
VIGENTE: 05-07-2017

IV. CONCLUSIONES
V. RECOMENDACIONES
VI. BIBLIOGRAFIA
VII. ANEXOS

Página 4 de 4
MODELO DE REQUISITOS
Diagrama de clases conceptuales (modelo de dominio)

Requerimientos no funcionales

Número Descripción
El sistema debe contar con una interfaces fácil e intuitiva.
RNF-01
El sistema debe soportar el manejo de gran cantidad de información durante
RNF-02
su proceso.
Se debe realizar un Backup lógico completo en horas específicas.
RNF-03
El sistema tiene que ser web y estar a disposición del cliente desde cualquier
RNF-04
dispositivo con un navegador web.
Requerimientos funcionales

Número Requisitos Descripción

El sistema debe permitir autenticar usuario con su

Autenticación de
RF-01 respectiva credencial para la correcta seguridad del
usuario
sistema.
El sistema debe permitir agregar, quitar o modificar un
RF-02 Gestión de usuario
usuario del sistema.
El sistema debe permitir agregar, quitar o modificar
RF-03 Gestión de terrenos
terrenos del sistema.
El sistema debe permitir agregar, quitar o modificar lotes
RF-04 Gestión de lotes
del sistema.
El sistema debe permitir agregar, quitar y modificar los
RF-05 Gestión de pagos
pagos.
El sistema debe permitir mostrar una interfaz grafica de
RF-06 Ver terrenos
los terrenos disponibles.
El sistema debe permitir el registro de usuarios en la base
Registro de
RF-07
usuarios de datos.
El sistema debe permitir el registro de pagos por método
Realizar pago
RF-08
online online.

Descripción de los actores

ACTOR DESCRIPCIÓN OBJETIVO

Es quien mantiene segura y Tiene como objetivo el
actualizada la información del gestionar usuarios, terrenos,
sistema. lotes y pagos.
Es el principal encargado de la
gestión y asignación, de
información en la empresa.
 Es quien es registrado en el Tiene como objetivo ser el
sistema como cliente o propietario de un lote de
interesado. terreno.

Diagrama general de los casos de uso (todos)

 Especificación de los casos de uso seleccionados.

Caso de uso: Gestión de usuario

Caso de Uso: 01 Administrador gestiona usuario

Actor Principal: Administrador
Descripción: permite agregar, quitar, modificar, los datos del usuario en el sistema.

Precondiciones: El usuario no esta registrado o no se han modificado sus datos.

Flujo Normal: El administrador, procede a gestionar usuario.

Acción del Actor Responsabilidad del Sistema
1.- El administrador, ingresa al sistema. 2.- El sistema mostrará el formulario de login.
3.- El administrador ingresara su usuario y 4.- El sistema verificara, validara sus datos de ser
contraseña. correctos y mostrara la interfaz del sistema.
5.- El administrador procederá a seleccionar 6.- El sistema habilitara los campos necesarios
una acción ya sea (agregar, quitar o modificar) para el intercambio de información deseada por
un puesto. el administrador.
7.- El administrador ingresara los datos que 8.- El sistema procesara los datos y guardara la
corresponden a su opción de selección información proporcionada en la base de datos.
previamente dicha (agregar, quitar o
modificar).
Flujo Alterno: El administrador intento agregar un usuario sin completar el campo de número telefónico.
Acción del Actor Responsabilidad del Sistema
1.- El Administrador, procederá a ingresar el 2.- Si el campo de número telefónico esta con los
número telefónico correspondiente en el campo números necesarios se guardara la información en la
vacío. base de datos.

Postcondiciones: El puesto es (agregado, quitado o modificado) con

éxito y se guardan la información en la base de datos.

Frecuencia: Media
 Caso de uso: Gestión de lotes

Caso de Uso: 02 Gestión de lotes

Actor Principal: Administrador
Descripción: permite agregar, modificar, los datos del lote en el sistema.

Precondiciones: El lote no está registrado o no se han modificado sus datos a estado borrado.

Flujo Normal: El administrador, modifica el estado de un lote.

Acción del Actor Responsabilidad del Sistema
1.- El administrador, ingresa al sistema. 2.- El sistema mostrará el formulario de login.

3.- El administrador ingresara su usuario y 4.- El sistema verificara, validara sus datos de ser
contraseña. correctos y mostrara la interfaz del sistema.
5.- El administrador seleccionara modificar el 6.- El sistema mostrara la modificación al estado
estado de un lote (reserva, disponible, del puesto y mostrara un botón de confirmar.
ocupado).
7.- El administrador dará click en el botón 8.- El sistema procesara los datos y guardara la
confirmar. información proporcionada en la base de datos.
Flujo Alterno: El Administrador intento poner un estado ocupado a un lote disponible por error.
Acción del Actor Responsabilidad del Sistema
1.- El Administrador, cambiara el estado del lote 2.- El sistema verificara si el estado asignado es
nuevamente. correcto.
Si un lote no esta con un pago no puede cambiarse su
estado ha ocupado o en reserva. De lo contrario se
manda un mensaje de pago no realizado.

Postcondiciones: Se modifico de manera correcta el estado de un lote y

se guardó la información en la base de datos.

Frecuencia: Media
 Caso de uso: Ver terrenos

Caso de Uso: 03 Usuario ve terrenos

Actor Principal: Usuario
Descripción: Permite ver los terrenos y los lotes disponibles en la página web.

Precondiciones: El sistema debe tener previamente ingresado los terrenos y lotes disponibles.

Flujo Normal: el usuario, procede a ver los lotes de terreno.

Acción del Actor Responsabilidad del Sistema
1.- El usuario ingresa a la página web. 2.- El sistema mostrara la interfaz web.
3.- El usuario seleccionara ver lotes de terreno. 4.- El sistema mostrara los lotes de terreno
disponibles.
Flujo Alterno: El usuario quiere reservar un lote.
Acción del Actor Responsabilidad del Sistema
1.- El usuario procede a dar click a sobre el lote de 2.- el sistema mostrara el costo del lote y un botón que
interés. dice me “interesa”.
3.- el usuario dará click al botón me interesa. 4.- el sistema le pedirá registrarse.

Postcondiciones: El usuario visualiza los terrenos disponibles.

Frecuencia: Alta