UNIVERSIDAD TECNOLOGICA PRIVADA DE SANTA CRUZ

FACULTAD DE CIENCIAS Y TECNOLOGÍA

Carrera Licenciatura en Ingeniería en Sistemas

PROYECTO FINAL DIRIGIDO

“SISTEMA DE INFORMACION
ADMINISTRATIVO PARA EL PARQUEO
CENTRAL PARK”

Rolando Callejas Arispe

Hans Jonathan Denker Ortiz
Ginner Rolando Sánchez Ruiz
Luis Guillermo Tejerina Vargas

Proyecto Final de Módulo

para la materia
Ingeniería en Software

Santa Cruz de la Sierra – Bolivia

2021

1
 Dedicatoria

Este trabajo está dedicado a nuestros padres y madres que con su esfuerzo nos
permiten seguir en nuestra formación académica.

2
 Agradecimientos

Agradecer al Ingeniero Rolando Gonzales por su ayuda en cada fase del proyecto,
por su paciencia, persistencia y amabilidad durante todo el desarrollo de esta
propuesta.

3
TÍTULO:
AUTOR:
PUBLICACIÓN:
UNIDAD PATROCINANTE:
PALABRAS CLAVES:
DESCRIPCIÓN:
del
Proceso
Software.
RESUMEN:
de
sistema de
parquero Central
controlar y realizar el
para poder brindarles
además de gestionar el espacio
Esto permitirá al negocio
necesidades de sus clientes, y
ser más competitivos en el
SISTEMA DE INFORMACION ADMINISTRATIVO
PARA EL PARQUEO CENTRAL PARK
CALLEJAS, Rolando; DENKER, Hans;
SÁNCHEZ, Ginner; TEJERINA, Luis.
Santa Cruz .UTEPSA. 2021. 198 p (Proyecto Final)
Universidad Tecnológica Privada de Santa Cruz
(UTEPSA)
<INGENIERIA DE SOFTWARE><CASOS DE
USO> <SISTEMAS DE INFORMACION>
<LENGUAJE DE PROGRAMACION> <LENGUAJE
DE MODELADO> <REQUERIMIENTOS>
La presente propuesta es sobre la implementación
de un Sistema de Información Administrativo
Parqueo “Central Park” en base al
Unificado de Desarrollo de
Este documento es el informe final de proyecto de
módulo, requisito para poder obtener la nota
Proyecto Final de la materia Ingeniería en
Software. Este proyecto consiste en un
información administrativo del
Park. Tiene como finalidad de
seguimiento de los clientes,
una mejor atención,
de los estacionamientos.
de ajustarse a las
por consiguiente,
mercado.
4
CONTENIDO
INTRODUCCIÓN...........................................................................................................8
CAPITULO I...................................................................................................................9
1. Aspectos Metodológicos .-........................................................................................9
1.1. Antecedentes.-....................................................................................................9
1.2. Planteamiento del problema.-.............................................................................9
1.2.1 Formulación del Problema.-........................................................................10
1.3. Justificación.-.....................................................................................................10
1.4. Objetivos.-.........................................................................................................11
1.4.1. Objetivo General.-.......................................................................................11
1.4.2. Objetivos Específicos.-...............................................................................11
1.5 Delimitaciones.-..................................................................................................11
1.5.2 Delimitación Espacial.-................................................................................11
1.5.3 Delimitación Temporal.-...............................................................................11
1.5.3 Delimitación de Contenido.-........................................................................12
1.6. Diseño Metodológico.-......................................................................................12
1.6.1. Tipos de Investigación.-..............................................................................12
1.6.2. Proceso Metodológico o Metodología utilizada.-........................................12
1.6.3. Métodos.-....................................................................................................12
1.6.4. Técnicas.-...................................................................................................13
1.6.5. Instrumentos / Herramientas Utilizadas.-...................................................13
1.6.6. Fuentes de Información.-............................................................................14
1.6.7. Procedimientos.-.........................................................................................14
1.7. Planificación de proyecto.-................................................................................16
1.7.1. Estimación de Costo Beneficio del proyecto.-............................................17
1.7.2. Planificación Temporal.-.............................................................................17
1.7.3. Visión del Software.-...................................................................................17
CAPITULO II................................................................................................................19
2. Marco Referencial.-.................................................................................................19
2.1. Marco teórico.-..................................................................................................19
2.1.1. Ingeniería de Software.-.............................................................................19
2.1.2. Ciclo de vida del software.-........................................................................19
2.1.3. Ingeniería de requisitos.-............................................................................19
2.1.4. Software.-....................................................................................................20

5
 2.1.5. Proceso Unificado de Desarrollo de Software.-.........................................20
2.1.6. UML.-..........................................................................................................22
2.1.7. Sistema Gestor de Base de Datos.-...........................................................22
2.1.8. Microsoft SQL Server.-...............................................................................23
2.1.9. Microsoft Visual Studio.-.............................................................................24
2.1.10. C#.-...........................................................................................................24
2.1.11. Windows 7.-..............................................................................................25
2.1.12. Sistemas de Información.-........................................................................26
2.1.13. Aplicaciones de Escritorio.-......................................................................26
CAPITULO III...............................................................................................................27
3. Modelo de Negocio.-................................................................................................27
3.1. Identificación de actores....................................................................................27
3.1.1. Administrador.-...........................................................................................27
3.1.2. Vendedor.-..................................................................................................27
3.1.3. Operador de la Caseta de Atención Entrada.-...........................................27
3.1.4. Operador de la Caseta de Atención Salida.-..............................................27
3.1.5. Cliente.-.......................................................................................................27
3.2. Clasificación de actores.-..................................................................................27
3.2.1. Primarios.-...................................................................................................27
3.2.2. Secundarios.-..............................................................................................27
3.3. Proceso de negocios.-.......................................................................................28
3.4. Diagrama de actividades.-.................................................................................28
3.4.1. P.N.1: Registro e inicio de uso de estacionamiento para abonado.-.........28
3.4.2 P.N.2: Asignación de espacio para abonado.-............................................30
3.4.3 P.N.3: Asignación de espacio para visitante.-.............................................31
3.4.4 P.N.4: Registro de salida de un vehículo abonado.-...................................33
3.4.5 P.N.5: Registro de salida de un vehículo visitante.-....................................34
CAPITULO IV...............................................................................................................36
4. Modelo de Requisitos.-............................................................................................36
4.1. Lista de requerimientos.-...................................................................................36
4.1.1. Requerimientos funcionales.-.....................................................................36
4.1.2. Requerimientos no funcionales.-................................................................36
4.2. Lista de casos de Usos del Sistema.-...............................................................37
4.3. Diagramas de caso de uso.-.............................................................................38
4.4. Descripción de los casos de uso.-....................................................................38

6
CAPITULO V................................................................................................................41
5. Modelo de Análisis.-.................................................................................................41
5.1.Modelo clases vista de análisis.-........................................................................41
5.2. Modelo de Comportamiento.-............................................................................41
5.3. Modelo Dinámico.-.............................................................................................41
CAPITULO VI...............................................................................................................42
6. Modelo de Diseño.-..................................................................................................42
6.1. Diagrama de clases.-........................................................................................42
6.2. Especificación de Casos de usos.-...................................................................42
6.3. Modelo de Comportamiento.-............................................................................42
6.3.1. Diagrama de Secuencia.-...........................................................................42
6.3.2. Diseño lógico de base de datos.-...............................................................42
6.3.3. Diseño físico de base de datos.-................................................................42
7.1. Diagrama de Componentes de ejecución.-.......................................................43
7.2. Diagrama de Nodos o de despliegue.-..............................................................43
7.3. Implementación de las clases de software.-.....................................................43
CAPITULO IX...............................................................................................................45
9. Conclusiones.-.........................................................................................................45
CAPITULO X................................................................................................................46
10. Recomendaciones.-..............................................................................................46
CAPITULO XI...............................................................................................................47
11. Bibliografía.-...........................................................................................................47
CAPITULO XII..............................................................................................................48
12. Anexos.-.................................................................................................................48

7
 INTRODUCCIÓN

Los proyectos de módulo son base fundamental para que los estudiantes culminen
satisfactoriamente la materia en desarrollo, por ende nació la necesidad de investigar
los procesos que se llevan a cabo en el Parqueo “Central Park” para la gestión de
sus clientes, facilitando así a la empresa el manejo de información de sus clientes,
teniendo en cuenta el estado actual de cada uno.

Por lo tanto se creará un sistema de información, que nos permitirá mejorar

procedimientos ordenados, que al ser ejecutados, proporcionan información para la
toma de decisiones y las mejoras en los procesos a través del seguimiento y el
control de los clientes.

8
 CAPITULO I.

1. Aspectos Metodológicos .-

1.1. Antecedentes.-

El parqueo Central Park se encuentra ubicado en el primer anillo de la

Ciudad de Santa Cruz de la Sierra y consta de un edificio de 5 pisos.
Actualmente el parqueo cuenta con un sistema que le permite registrar la
placa, el color, el modelo y la marca del vehículo que ingresa al
estacionamiento. Este sistema imprime el ticket que es entregado al usuario al
entrar y es devuelto por el cliente al salir para que se le imprima la factura.
Además, el sistema recuerda los datos de los vehículos que ya han ingresado
y después de ingresar la placa ayuda a rellenar los demás datos (modelo color
y marca de la movilidad).
El parqueo consta una caseta de atención en la entrada y en la salida, cada
caseta de atención es atendida por un personal que cobra por ticket de
estacionamiento. Al entrar una movilidad al estacionamiento, se registra la
movilidad anotando la placa, el color, modelo y marca de la movilidad, una
copia del ticket se le pasa al cliente y al salir esta muestra el ticket y paga para
que se le imprima una factura. Los tickets cuestan 15Bs y el parqueo es muy
solicitado.

1.2. Planteamiento del problema.-

Se ha hecho notar que en el parqueo Central Park existen clientes que

dejan su auto más de 5 horas al día su movilidad en el estacionamiento y otros
solo ocupan el estacionamiento media hora y retiran su movilidad. Por lo
consiguiente se podría mejorar el negocio si:
 Cobrar más a los que se quedan más tiempo.
 Cobrar menos a los que se quedan menos tiempo.
 Registrar usuarios que paguen un estacionamiento mensual.

9
  Generar más ganancias si se tuviera usuarios que estén dispuestos a
pagar extra para obtener prioridad sobre los lugares más cercanos a la
entrada y salida.
Se necesita entonces un sistema que registre a los clientes, sean estos:
‘visitantes’, ‘abonados’ o ‘abonados vip’ para realizar la tarea de asignarle un
espacio en el parqueo (según su prioridad) y para poder hacerle el cobro
respectivo (según su contrato).
• A los clientes ‘visitantes’, se les cobra 5bs si es que ocupa el
estacionamiento hasta 1 hora. Y se les asignara el espacio disponible más
cercano a partir del 2do piso hasta el 5to.
• A los clientes ‘abonados’, se les cobrara 200 bs al mes y podrán entrar
y salir las veces que quieran del estacionamiento (siempre y cuando estén al
día en sus pagos). Se les asignara el espacio disponible más cercano a partir
del 2do piso hasta el 5to.
• A los clientes ‘abonados vip’, se les cobrara 400 bs al mes y podrán
entrar y salir las veces que quieran del estacionamiento (siempre y cuando
estén al día en sus pagos). Se les asignara el espacio disponible más cercano
en el 1er piso.

1.2.1 Formulación del Problema.-

¿De qué manera el análisis, diseño, desarrollo e implementación de un
sistema de información administrativo para el control, seguimiento y
gestión de los clientes, mediante el uso de la metodología de Proceso
Unificado de Desarrollo de Software, influyen la mejora del negocio del
parqueo Central Park?

1.3. Justificación.-

En el ámbito social proporcionar un Sistema de Información al parqueo

Central Park que le permita a los socios obtener de manera rápida y confiable
la información acerca de los clientes que acceden al parqueo, les permitirá
gestionar mejor su negocio y a tener una mejor toma de decisiones a futuro

10
para generar mayores ganancias e inclusive ser más competitivos respecto a
otros negocios similares.
En el ámbito académico desarrollar el sistema de información nos permitirá
analizar y reconocer todo el proceso que conlleva el Desarrollo de Software
mediante el Proceso Unificado.
En el ámbito de la practica nos permitirá aplicar todos los conocimientos
adquiridos durante el proceso del desarrollo del software y su correcta
implementación.

1.4. Objetivos.-

1.4.1. Objetivo General.-

Desarrollar un Sistema de Información para la administración de
los clientes del parqueo Central Park mediante los casos de usos.

1.4.2. Objetivos Específicos.-

 Identificar los requerimientos funcionales del sistema de
información administrativo.
 Describir los requerimientos mediante los casos de uso.
 Analizar los casos de uso mediante una descripción ampliada.
 Implementar el software de acuerdo con el modelo lógico y físico
diseñado.

1.5 Delimitaciones.-

1.5.2 Delimitación Espacial.-

El presente proyecto se llevará a cabo en la empresa Parqueo
Central Park.

1.5.3 Delimitación Temporal.-

El presente proyecto se realizará durante el periodo comprendido
entre el mes de octubre del 2021 hasta diciembre de 2021.

11
 1.5.3 Delimitación de Contenido.-
El presente proyecto tiene como delimitación conceptual la
aplicación de la metodología del Proceso Unificado de Desarrollo de
Software.

1.6. Diseño Metodológico.-

1.6.1. Tipos de Investigación.-

Este tipo de investigación es cuantitativa porque se está
utilizando las características de deducción, verificación, enumeración y
es objetivo, adquirir conocimientos fundamentales y la elección de
modelo más adecuado que nos permita ver la realidad de manera
imparcial ya que se recogen y analizan los datos a través de los
conceptos y variables.

1.6.2. Proceso Metodológico o Metodología utilizada.-

En este proyecto se utilizará la metodología de Desarrollo
Unificado del proceso de Software ya que tiene el conjunto de
actividades necesarias para transformar los requisitos de un usuario en
un sistema de información.

1.6.3. Métodos.-
El Proceso Unificado de Desarrollo de Software es un marco de
trabajo genérico que puede especializarse para una gran variedad de
sistemas software. Está basado en componentes, lo que significa que el
sistema software en construcción está formado por componentes
software interconectados a través de interfaces. Las principales
características del Proceso Unificado son:
 Dirigido por casos de uso.
 Centrado en la arquitectura.
 Iterativo e incremental.

12
El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified
Modeling Language, UML) para preparar todos los esquemas de un
sistema software. UML es una parte esencial del Proceso Unificado –
sus desarrollos fueron paralelos.

1.6.4. Técnicas.-
El Proceso Unificado se repite a lo largo de una serie de ciclos que
constituyen la vida de un sistema. Cada ciclo concluye con una versión
del producto para los clientes y consta de cuatro fases:
 Inicio: Se identifican los casos de uso más críticos junto con un
plan de riesgo y estimación, se planifica en detalle la fase de
elaboración.
 Elaboración: Se presenta un modelo detallado de los casos de
uso y se diseña la arquitectura del sistema, esta se expresa en
forma de vistas de todos los modelos del sistema. Además, se
planifican las actividades posteriores y se estiman los recursos
para terminar el proyecto.
 Construcción: Se crea el producto, que contiene todos los casos
de uso que la dirección y el cliente han acordado para el
desarrollo de la versión. Sin embargo, es posible que no esté
libre de modificaciones. Muchos de estos defectos se
descubrirán u solucionarán durante la fase de transición.
 Transición: Cubre el período durante el cual el producto se
convierte en versión beta. En ese momento, un número reducido
de usuarios con experiencia prueba el producto, e informa de
defectos y deficiencias.

1.6.5. Instrumentos / Herramientas Utilizadas.-

UML es un lenguaje para especificar, construir, visualizar y
documentar los artefactos de un sistema de software orientado a
objetos (OO). Un artefacto es una información que es utilizada o
producida mediante un proceso de desarrollo de software.

13
1.6.6. Fuentes de Información.-
La captura de requisitos tiene dos objetivos: encontrar los
verdaderos requisitos (funcionales y no funcionales) y representarlos de
un modo adecuado para los usuarios, clientes y desarrolladores
(modelo de casos de uso). Es utilizado como documento de contrato
entre el cliente y los desarrolladores sobre qué debería y que no
debería hacer el sistema, por lo tanto se dice que la regla número uno
de la captura de requisitos es utilizar el lenguaje del cliente.

1.6.7. Procedimientos.-
Normalmente, un sistema tiene muchos tipos de usuarios. Cada
tipo de usuario se representa por un actor. Los actores utilizan el
sistema interactuando con los casos de uso. Un caso de uso es una
secuencia de acciones que el sistema lleva a cabo para ofrecer algún
resultado de valor para un actor. El modelo de casos de uso está
compuesto por todos los actores y todos los casos de uso del sistema
representando de esta manera los requisitos funcionales y no
funcionales, éstos últimos son específicos de cada caso de uso.
A continuación se describen los pasos a seguir (artefactos) para aplicar
la técnica con casos de uso, estos pasos no tienen por qué ser
ejecutados en ningún orden en particular y a menudo se hacen
simultáneamente:
 Identificación de los actores. Un actor es una agrupación de
personas, sistemas o máquinas que interactúan con el sistema.
De esta forma, este paso comprende identificar todos los tipos de
usuario del sistema. Es importante tener clara la diferencia entre
usuario y actor. Un actor es una clase de rol, mientras que un
usuario es una persona que, cuando usa el sistema, asume un
rol. De esta forma, un usuario puede acceder al sistema como
distintos actores. Los actores se representan con dibujos

14
 simplificados de personas, llamados en inglés “stick man”
(hombres de palo).
 Identificación y Descripción de los casos de uso de cada Actor.
Se deben enunciar los principales casos de uso (requerimientos
funcionales) de cada uno de los actores que se identificaron en el
paso anterior. Posteriormente se pueden identificar nuevos casos
a partir de los existente utilizando diversas técnicas que den
como resultado un modelo de casos de uso que permita cubrir
todos los requisitos del sistema.
 La notación UML permite representar relaciones entre casos de
uso con el fin de evitar redundancia y facilitar la comprensión del
modelo:
Relaciones de extensión: representan una parte de la
funcionalidad del caso de uso que no siempre ocurre
(opcional). En su libro, Jacobson ejemplifica los casos de
uso con ir a cenar a un restaurant. Para él, tomar café
después de cenar es un ejemplo de una extensión.
Relaciones de uso: útil cuando una funcionalidad del sistema es
accedida a partir de varios casos de uso, de esta manera, se
denota una sola vez el caso de uso (similar al concepto de
subrutina).
Relaciones de inclusión: es la relación inversa a la de extensión,
que proporciona una extensión explícita e incondicional a un
caso de uso (no opcional).
Finalmente se construye una breve descripción paso a paso de lo
que el sistema necesita hacer cuando interactúa con sus
actores. El objetivo principal de detallar cada caso de uso es
describir su flujo de sucesos en detalle, incluyendo cómo
comienza, termina e interactúa con los actores.
 Capturar Requisitos no Funcionales. Este tipo de requisitos
especifica propiedades del sistema, como restricciones del

15
 entorno o de la implementación, rendimiento, dependencias de la
plataforma, facilidad de mantenimiento, etc. La mayoría de los
requisitos de rendimiento afectan sólo a ciertos casos de uso y
por tanto deberían conectarse a ese caso de uso. También
pueden detallarse en una sección aparte de requisitos.
 Descripción del Modelo de Casos de Uso. Se describe el modelo
de casos de uso en su totalidad, el objetivo es describir cómo se
relacionan los casos de uso entre sí y con los actores.
 Priorizar Casos de Uso. Es conveniente definir las prioridades de
los distintos requerimientos con la finalidad de determinar cuáles
son necesarios para el desarrollo en las primeras iteraciones, y
cuáles pueden dejarse para más tarde. Para esto se consideran
tres categorías: imprescindible, importante y deseable.
Los requerimientos imprescindibles son aquellos que, si no se
implementan, hacen que el sistema no tenga sentido.
Los importantes son aquellos que harían que el usuario se sienta
decepcionado si no se implementan.
Los deseables son aquellos que el usuario querría tener, si
hubiese tiempo disponible.
Al evaluar un requerimiento se debe también analizar su costo o
complejidad.
Una vez hecha esta categorización, se debe tomar como
estrategia general incluir los imprescindibles, discutir los
importantes y descartar los deseables cuyo costo sea bajo.
 Crear Prototipos de Interfaces. Adicionalmente se puede crear un
prototipo de interfaz de usuario para algunos casos de usos,
habitualmente un prototipo por cada actor. La finalidad de este
artefacto es que el usuario tenga una idea de cómo se verá el
sistema.

16
1.7. Planificación de proyecto.-

1.7.1. Estimación de Costo Beneficio del proyecto.-

Factor de ponderación:
Factor de ponderación
Parámetro Cuenta Subtotal
Simple Medio Complejo
Número de entradas de usuario 5 3 4 6 20
Número de salidas de usuario 16 4 5 7 80
Número de peticiones de usuario 10 3 4 6 40
Número de archivos 5 7 10 15 50
Número de interfaces externas 1 5 7 10 7
Cuenta Total 197

Valores de Ajuste de Complejidad:

1.        ¿Requiere el sistema copias de seguridad y de recuperación fiables? 1
2.        ¿Requiere comunicación de datos? 3
3.        ¿Existen funciones de procesamiento distribuido? 2
4.        ¿Es crítico el rendimiento? 3
5.        ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente
utilizado? 2
6.        ¿Requiere entrada de datos interactiva? 2
7.        ¿Requiere la entrada de datos interactiva que las transacciones de entrada se
lleven a cabo sobre múltiples pantallas u operaciones? 2
8.        ¿Se actualizan los archivos maestros de forma interactiva? 2
9.        ¿Son complejas las entradas, las salidas, los archivos o las peticiones? 3
10.      ¿Es complejo el procesamiento interno? 2
11.      ¿Se ha diseñado el código para ser reutilizable? 0
12.      ¿Están incluidas en el diseño la conversión y la instalación? 0
13.      ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes
organizaciones? 0
14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente
utilizada por el usuario? 3
total 25

Puntos de Función Final: 197 * (0.65 + 0.01 * 25) = 177.3

17
Estimación de Costos:
Recursos Humanos 
Sueldo: 1200 USD
Tiempo: 3 Meses
Empleados: 3 Personas
Total: 10800 USD

Hardware      
Precio Computador: 800 USD
Cantidad:   3 Unidades
Total: 2400  
Depreciación
Maquinas: 22,22 USD
En tres meses: 199.98 USD

Software:        
Host de la Aplicación Web 840 USD
Dominio de la Aplicación Web 170 USD
Plantilla Web   60 USD

Logística
Material de Oficina 100 USD
Insumos y otros 80 USD

Servicios Básicos
Agua 70 USD
Luz 300 USD
Internet 500 USD

Estimación de Costos: 15519.98 USD = 16000 USD

18
 1.7.2. Planificación Temporal.-

1.7.2.1. Plan de iteraciones.-

1.7.2.2. Diagrama de Gantt.-

N. Octubre Noviembre Diciembre
Actividades
º 1 2 3 4 1 2 3 4 1 2 3 4
1 Recolección de datos de la empresa                        
2 Visita a la empresa                        
3 Entrevistas a funcionarios                        
4 Análisis del revelamiento de datos                        
5 Inicio de elaboración de manual de funciones                        
6 Determinación de los procedimientos                        
7 Finalización de los manuales                        
8 Corrección de errores                        
9 Implementación de los nuevos procedimientos                        
10 Retroalimentación                        

19
 1.7.3. Visión del Software.-
1.7.3.1. Propósito.-
Con la implementación del sistema de información para la
administración de clientes del Parqueo Central Park se tiene
como propósito realizar el seguimiento y control de los clientes
para brindarles un mejor servicio, mediante la aplicación de
todas las fases de desarrollo que tiene la metodología del
Proceso Unificado de Desarrollo de Software.
.
1.7.3.2. Alcance.-
Con la implementación de un sistema de información para
la administración de los clientes se trata de alcanzar el uso
optimo del Proceso Unificado de Desarrollo de Software en todas
sus fases.

1.7.3.3. Funcionalidad Básica del Sistema.-

El sistema debe permitir el registro del ingreso y salida de
todos los clientes, haciendo la identificación automática del tipo
de contrato que tiene mediante la verificación de la placa.

1.7.3.4. Descripción de Usuarios.-

Actor Clasificación Descripción
Administrador Primario Gestiona el sistema.
Vendedor Primario Registra a los nuevos abonados.
Operador Entrada Primario Opera en la caseta de entrada.
Operador Salida Primario Opera en la caseta de Salida
Cliente Secundario Interactúa con los operadores y el vendedor.

20
 CAPITULO II

2. Marco Referencial.-

2.1. Marco teórico.-

2.1.1. Ingeniería de Software.-

Según lo expresa Pressman (2010), la ingeniería del software es
la aplicación de enfoques sistemáticos, disciplinados y cuantificables al
desarrollo, operación y mantenimiento de software y el estudio de estos
enfoques.
De otra parte Sommerville (2005), define la ingeniería del software
como aquella que se refiere a los problemas prácticos de producir
software.
De acuerdo con lo anterior, se podría concebir la ingeniería del software
como el estudio del conjunto de técnicas, métodos o metodologías que
se aplican en el proceso de desarrollo de software.

2.1.2. Ciclo de vida del software.-

El ciclo de vida de desarrollo de software es "una aproximación
lógica a la adquisición, el suministro, el desarrollo, la explotación y el
mantenimiento de software".
Se define el ciclo de vida del software como "un marco de referencia
que contiene los procesos, las actividades y las tareas involucradas en
el desarrollo, la explotación y el mantenimiento de un producto de
software, abarcando la vida del sistema desde la definición de los
requisitos hasta la finalización de su uso".

2.1.3. Ingeniería de requisitos.-

Teniendo en cuenta la afirmación hecha por Quintero (2007), los
requisitos deben tener una alta prioridad dentro del proceso de

21
desarrollo de software, por lo que a continuación se hace una revisión
de este concepto.
Según Christel (1992), la ingeniería de requisitos es una aplicación
disciplinada de principios científicos, además de técnicas, para la
gestión de requisitos.
De igual manera Hsia (1993), relaciona la ingeniería de requisitos con la
actividad de identificar y documentar necesidades de clientes y
usuarios.
Otra definición planteada por Doe (2011), permite complementar la
definición de ingeniería de requisitos al relacionarla con el proceso del
estudio de las necesidades, de un usuario, para definir los
requerimientos de un entorno.

2.1.4. Software.-
Mucha gente iguala el término software con programas de
computadoras. De hecho, éste es un criterio demasiado restrictivo. El
software no es sólo los programas sino que también toda la
documentación asociada e información de configuración la cuál es
necesaria para hacer estos programas funcionar correctamente. Un
sistema de software usualmente consiste en varios programas
separados, archivos de
configuración los cuales son usados para instalar estos programas,
documentación del sistema la cuál describe la estructura del sistema y
documentación del usuario la cuál explica cómo usar el sistema y, los
sitios web de los productos de software para que los usuarios
descarguen información reciente del producto.

2.1.5. Proceso Unificado de Desarrollo de Software.-

El Proceso Unificado no es simplemente un proceso, sino un
marco de trabajo extensible que puede ser adaptado a organizaciones o
proyectos específicos.

22
El Proceso Unificado de Desarrollo Software o simplemente Proceso
Unificado es un marco de desarrollo de software que se caracteriza por
estar dirigido por casos de uso, centrado en la arquitectura y por ser
iterativo e incremental.

Iterativo e Incremental.-
El Proceso Unificado es un marco de desarrollo iterativo e
incremental compuesto de cuatro fases denominadas Inicio,
Elaboración, Construcción y Transición. Cada una de estas fases es a
su vez dividida en una serie de iteraciones (la de inicio puede incluir
varias iteraciones en proyectos grandes). Estas iteraciones ofrecen
como resultado un incremento del producto desarrollado que añade o
mejora las funcionalidades del sistema en desarrollo. Cada una de
estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clásico o en cascada:
Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas
las iteraciones suelen incluir trabajo en casi todas las disciplinas, el
grado de esfuerzo dentro de cada una de ellas varía a lo largo del
proyecto.
Dirigido por los casos de uso.-
En el Proceso Unificado los casos de uso se utilizan para
capturar los requisitos funcionales y para definir los contenidos de las
iteraciones. La idea es que cada iteración tome un conjunto de casos de
uso o escenarios y desarrolle todo el camino a través de las distintas
disciplinas: diseño, implementación, prueba, etc.
Centrado en la arquitectura.-
El Proceso Unificado asume que no existe un modelo único que
cubra todos los aspectos del sistema. Por dicho motivo existen múltiples
modelos y vistas que definen la arquitectura de software de un sistema.
La analogía con la construcción es clara, cuando construyes un edificio

23
existen diversos planos que incluyen los distintos servicios del mismo:
electricidad, fontanería, etc.
Enfocado en los riesgos.-
El Proceso Unificado requiere que el equipo del proyecto se
centre en identificar los riesgos críticos en una etapa temprana del ciclo
de vida. Los resultados de cada iteración, en especial los de la fase de
Elaboración deben ser seleccionados en un orden que asegure que los
riesgos principales son considerados primero.

2.1.6. UML.-
El lenguaje de modelado unificado (UML) es un estándar para la
representación visual de objetos, estados y procesos dentro de un
sistema. Por un lado, el lenguaje de modelado puede servir de modelo
para un proyecto y garantizar así una arquitectura de información
estructurada; por el otro, ayuda a los desarrolladores a presentar la
descripción del sistema de una manera que sea comprensible para
quienes están fuera del campo. UML se utiliza principalmente en el
desarrollo de software orientado a objetos. Al ampliar el estándar en la
versión 2.0, también es adecuado para visualizar procesos
empresariales.
Antes de que UML se introdujera en el desarrollo de software, el campo
de la programación orientada a objetos (OOP) había crecido. Este estilo
de programación se basa en el concepto de que todo es un objeto: los
bloques de construcción de un programa son objetos que interactúan
entre sí, los mensajes que se envían de un lado a otro entre los
componentes también constan de objetos. Cada objeto individual es un
ejemplo de su clase superior. La clase misma también actúa como un
objeto y también determina el comportamiento de las instancias de
objetos que contiene. Los objetos consisten en datos y código. El objeto
organiza los datos en campos, también llamados atributos. El código
determina su procedimiento o método.

24
2.1.7. Sistema Gestor de Base de Datos.-
Un sistema gestor de base de datos (SGBD), o también llamado
DBMS por sus siglas en inglés, es un software que se utiliza para
acceder, extraer y administrar datos almacenados en una fuente o base
de datos, los usuarios accedan a esta información usando herramientas
específicas de consulta y generalmente se accede a los datos mediante
lenguajes de consulta como lo es SQL (Structured Query Language). Es
importante saber que un SGBD y una base de datos no son lo mismo,
una base de datos está conformada de solo los mismos datos en forma
estructurada y el SGBD es una herramienta o elemento para
materializar la base de datos y su estructura.
Diariamente las empresas mueven y obtienen grandes cantidades de
datos y para ello existen diferentes tipos de almacenamiento y gestión
que se pueden adoptar según las necesidades de la empresa y los tipos
de datos que se utilizarán en diferentes aplicaciones:
 Data Warehouse, utilizado para datos estructurados y como
estrategia de BI.
 Data Lake, utilizado para almacenar datos no estructurados.
 Fast Data, referido al análisis de datos a menor escala y en
tiempo real.
 Gestión de datos híbridos, con capacidad para analizar datos
de cualquier tipo, fuente y estructura.

2.1.8. Microsoft SQL Server.-

Microsoft SQL Server es un sistema de gestión de base de datos
relacional, desarrollado por la empresa Microsoft.
El lenguaje de desarrollo utilizado (por la línea de comandos o mediante
la interfaz gráfica de Management Studio) es Transact-SQL (TSQL),
una implementación del estándar ANSI del lenguaje SQL, utilizado para
manipular y recuperar datos (DML), crear tablas y definir relaciones
entre ellas (DDL).

25
Dentro de los competidores más destacados de SQL Server están:
Oracle, MariaDB, MySQL, PostgreSQL. SQL Server ha estado
tradicionalmente disponible solo para sistemas operativos Windows de
Microsoft, pero desde 2016 está disponible para GNU/Linux,23 y a partir
de 2017 para Docker también.
Puede ser configurado para utilizar varias instancias en el mismo
servidor físico, la primera instalación lleva generalmente el nombre del
servidor, y las siguientes - nombres específicos (con un guion invertido
entre el nombre del servidor y el nombre de la instalación).

2.1.9. Microsoft Visual Studio.-

Microsoft Visual Studio es un entorno de desarrollo integrado
(IDE, por sus siglas en inglés) para Windows y macOS. Es compatible
con múltiples lenguajes de programación, tales como C++, C#, Visual
Basic .NET, F#, Java, Python, Ruby y PHP, al igual que entornos de
desarrollo web, como ASP.NET MVC, Django, etc., a lo cual hay que
sumarle las nuevas capacidades en línea bajo Windows Azure en forma
del editor Mónaco.
Visual Studio permite a los desarrolladores crear sitios y aplicaciones
web, así como servicios web en cualquier entorno compatible con la
plataforma .NET (a partir de la versión .NET 2002). Así, se pueden
crear aplicaciones que se comuniquen entre estaciones de trabajo,
páginas web, dispositivos móviles, dispositivos embebidos y
videoconsolas, entre otros.

2.1.10. C#.-
"C#" (pronunciado 'si sharp' en inglés) es un lenguaje de
programación multiparadigma desarrollado y estandarizado por la
empresa Microsoft como parte de su plataforma .NET, que después fue
aprobado como un estándar por la ECMA (ECMA-334) e ISO (ISO/IEC
23270). C# es uno de los lenguajes de programación diseñados para la
infraestructura de lenguaje común.

26
Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la
plataforma .NET, similar al de Java, aunque incluye mejoras derivadas
de otros lenguajes.
El nombre C Sharp fue inspirado por el signo ♯, el cual se lee como
sharp en inglés para notación musical. Es un juego de palabras, pues
'"C#" significa, musicalmente hablando, "do sostenido", donde el
símbolo # indica que una nota (en este caso do, representada por C)
debe ser un semitono más alta. Esto es una metáfora de la superioridad
de C# sobre su antecesor C++ y a su vez hace alusión a la misma
metáfora que se ideó para dar nombre a C++. Además, el símbolo #
puede ser imaginado como la unión de cuatro símbolos +, continuando
así con el sentido de progresión de los lenguajes C.
Aunque C# forma parte de la plataforma .NET, esta es una API,
mientras que C# es un lenguaje de programación independiente
diseñado para generar programas sobre dicha plataforma. Ya existe un
compilador implementado que provee el marco Mono - DotGNU, el cual
genera programas para distintas plataformas como Windows Microsoft,
Unix, Android, iOS, Windows Phone, Mac OS y GNU/Linux.

2.1.11. Windows 7.-

Windows 7 es una versión de Microsoft Windows, línea de
sistemas operativos producida por Microsoft Corporation. Se lanzó en
octubre de 2009. Esta versión estaba diseñada para uso en PC,
incluyendo equipos de escritorio en hogares y oficinas, equipos
portátiles, tabletas, netbooks y equipos multimedia. El desarrollo de
Windows 7 se completó el 22 de julio de 2009, siendo entonces
confirmada su fecha de venta oficial para el 22 de octubre de 2009 junto
a su equivalente para servidores Windows Server 2008 R2.
A diferencia del gran salto arquitectónico y de características que sufrió
su antecesor Windows Vista con respecto a Windows XP, Windows 7
fue concebido como una actualización incremental y focalizada de Vista

27
y su núcleo NT 6.0, lo que permitió mantener cierto grado de
compatibilidad con aplicaciones y hardware en los que este ya era
compatible. Sin embargo, entre las metas de desarrollo para Windows 7
se dio importancia a mejorar su interfaz para volverla más accesible al
usuario e incluir nuevas características que permitieran hacer tareas de
una manera más fácil y rápida, al mismo tiempo que se realizarían
esfuerzos para lograr un sistema más ligero, estable y rápido.
Diversas presentaciones ofrecidas por la compañía en 2008 se
enfocaron en demostrar capacidades multitáctiles, una interfaz
rediseñada junto con una nueva barra de tareas y un sistema de redes
domésticas simplificado y fácil de usar denominado «Grupo en el
hogar», además de importantes mejoras en el rendimiento general del
sistema operativo.

2.1.12. Sistemas de Información.-

Un sistema de información tiene como principal objetivo la
gestión, y administración de los datos e información que lo componen.
Lo importante es poder recuperar siempre esos datos, y que además se
tenga un fácil acceso a ellos con total seguridad.
Los componentes del sistema de información permiten una serie de
procesos que consisten en: la entrada de los datos, la gestión y el
procesamiento de estos, el almacenamiento y la salida para todos
aquellos interesados que deseen tener acceso a este tipo de
información.
Los elementos del sistema de información trabajan de manera conjunta
y con los mismos objetivos para conseguir el uso y la correcta
administración de cualquier información concreta.

2.1.13. Aplicaciones de Escritorio.-

Una aplicación de escritorio es aquella que se encuentra
instalado en el ordenador o sistema de almacenamiento y podemos
ejecutarlo sin internet en nuestro sistema operativo, al contrario que las

28
aplicaciones en la nube que se encuentran en otro ordenador al que
accedemos a través de la red o internet a su software.

29
 CAPITULO III

3. Modelo de Negocio.-

3.1. Identificación de actores.

3.1.1. Administrador.-
Es la persona que se encarga de registrar usuarios y roles de
acceso al sistema.

3.1.2. Vendedor.-
Es la persona encargada de la captación de nuevos abonados,
vender los abonos a los clientes y registrar a los nuevos abonados del
parqueo con sus datos personales y datos básicos de la movilidad.

3.1.3. Operador de la Caseta de Atención Entrada.-

Es la persona encargada de recepcionar al cliente, registrar los
datos básicos de la movilidad del cliente, registrar el ingreso del cliente
al parqueo, asignar un espacio de estacionamiento según su contrato y
generar un ticket de estacionamiento si fuera el caso.

3.1.4. Operador de la Caseta de Atención Salida.-

Es la persona encargada de recepcionar la copia del ticket de
estacionamiento del cliente para realizar el cobro y generar la factura
por el servicio brindado, además de registrar y autorizar la salida del
cliente según su contrato.

3.1.5. Cliente.-
Es la persona que utiliza el servicio de estacionamiento ya sea
abonado o visitante.

3.2. Clasificación de actores.-

3.2.1. Primarios.-
Administrador, Operador de la Caseta de Atención de Entrada y
Salida, Vendedor son quienes manejaran alguna funcionalidad del
sistema de forma directa.
3.2.2. Secundarios.-
El cliente tendrá acceso a alguna funcionalidad del sistema de
manera indirecta a través de los actores primarios.

30
3.3. Proceso de negocios.-
Proceso de Negocio
P.N.1: Registro e inicio de
uso de estacionamiento para
abonado.
P.N.2: Asignación de
espacio para abonado.
P.N.3: Asignación de
espacio para visitante.
P.N.4: Registro de salida de
un vehículo abonado
P.N.5: Registro de salida de
un vehículo visitante
Objetivos
Registrar los datos personales del cliente y los
datos básicos de la movilidad.
Registrar pago de abono según corresponda.
Verificar si el abonado no tiene deuda
pendiente para poder hacer la asignación de
un espacio en el estacionamiento según
corresponda la prioridad de su contrato.
Registrar el ingreso del vehículo del abonado.
En el caso de que no estuviera habilitado por
deuda pendiente se dará opción para que
pague y se pusiera al día, caso contrario se le
generara un ticket de visitante para poder
ingresar.
Registrar el ingreso mediante la placa del
automóvil del cliente visitante para poder
asignar espacio e imprimir un ticket para el uso
del estacionamiento
Verificar el numero de la placa para identificar
el tipo de cliente abonado y autorizar la salida
del mismo. Registrar la salida del vehículo del
cliente abonado. Si solo quedan dos días de
contrato se notificará para recordar al cliente el
pago de su abono.
Verificar el numero de la placa para identificar
el tipo de cliente visitante y proceder a realizar
el cálculo del importe de su estadía en el
estacionamiento para cobrar e imprimir la
factura. Registrar la salida del vehículo del
cliente visitante.

3.4. Diagrama de actividades.-

3.4.1. P.N.1: Registro e inicio de uso de estacionamiento para
abonado.-
Este proceso de negocio es el que inicia todas las actividades
siguientes en el parqueo “Central Park”, se encarga de registrar los
datos personales del cliente y los datos básicos de la movilidad,
además, registrar el pago de abono según corresponda el contrato
adquirido ya sea “abonado” o “abonado vip”.

31
Requisitos previos:
 El encargado ya debe estar logueado en el sistema y tener
acceso a la función de registro de abonados.
 Ya se deben tener registrados los tipos de abonados que existen
en el parqueo “Central Park”

Reglas de negocio:
 Los clientes que se registran en el plan de abonados deben
brindar sus datos personales y los datos básicos de la movilidad
al encargado.

Diagrama de actividad P.N.1: Registro e inicio de uso de

estacionamiento para abonado:

32
3.4.2 P.N.2: Asignación de espacio para abonado.-
Este proceso de negocios se encarga de verificar si el abonado no tiene
deuda pendiente en el pago del mes de su abono, para poder hacer la
asignación de un espacio en el estacionamiento según corresponda la
prioridad de su contrato ya sea “abonado” o “abonado vip”. En el caso
de que no estuviera habilitado por deuda pendiente se dará opción para
que pague en ese momento y se pusiera al día, caso contrario se le
generara un ticket de visitante para poder ingresar.

Requisitos previos:
 El operador de caseta de entrada se debe encontrar logueado en
el sistema y tener acceso a la función de asignación de espacios
para abonados.
 Los abonados ya se deben encontrar correctamente registrados
en el sistema.

Reglas de negocio:
 Los abonados no deben tener deudas pendientes para poder
hacer uso del estacionamiento.

33
Diagrama de actividad P.N.2: Asignación de espacio para abonado:

3.4.3 P.N.3: Asignación de espacio para visitante.-

En este proceso de negocio se registra la placa del automóvil del cliente
visitante para poder asignarle un espacio e imprimir un ticket para el
uso del estacionamiento. Además se encarga de detectar si el cliente
visitante es un cliente recurrente por lo cual mostrara una alerta para
que el encargado le ofrezca adquirir un plan de abonado del parqueo.

34
Requisitos previos:
 El operador de caseta de entrada se debe encontrar logueado en
el sistema y tener acceso a la función de asignación de espacios
de visitantes.
 El sistema debe contar con el registro de los clientes visitantes
recurrentes.

Reglas de negocio:
 Se debe tomar siempre el numero de la placa para llevar un
registro de las clientes visitantes.

Diagrama de actividad P.N.3: Asignación de espacio para visitante:

35
3.4.4 P.N.4: Registro de salida de un vehículo abonado.-
Este proceso de negocio se encarga de verificar el numero de la placa
para identificar el tipo de cliente abonado y autorizar la salida del
mismo. Si solo quedan dos días de contrato se notificará para recordar
al cliente el pago de su abono del próximo mes.

Requisitos previos:
 El operador de caseta de salida se debe encontrar logueado en
el sistema y tener acceso a la función de registro y asignación de
espacios para abonados.
 El cliente debe estar al día en sus cuotas mensuales.
 El cliente debe tener su espacio asignado.

Reglas de negocio:
 Se debe verificar el numero de la placa que coincida en el
sistema.
 Se debe estar pendiente de la notificación que recuerda al cliente
el pago de sus cuotas mensuales.

36
Diagrama de actividad P.N.4: Registro de salida de un vehículo
abonado:

3.4.5 P.N.5: Registro de salida de un vehículo visitante.-

Este proceso de negocio se encarga de verificar el numero de la placa
para identificar el tipo de cliente visitante y proceder a realizar el cálculo
del importe de su estadía en el estacionamiento para cobrar e imprimir
la factura.

Requisitos previos:
 El operador de caseta de salida se debe encontrar logueado en
el sistema y tener acceso a la función de asignación de espacio
para visitantes y a la función de cobro de servicios.
 El cliente visitante debe tener ya generado un ticket de
estacionamiento con su espacio asignado.

37
Reglas de negocio:
 Se debe verificar el número de placa de la movilidad del cliente
visitante que coincida con el ticket que se le género.

Diagrama de actividad P.N.5: Registro de salida de un vehículo

visitante:

38
 CAPITULO IV

4. Modelo de Requisitos.-

4.1. Lista de requerimientos.-

Después de realizar entrevistas y observar el contexto del

sistema se obtiene una lista de requisitos del sistema.
4.1.1. Requerimientos funcionales.-
Requisit
Descripción
o
El sistema debe permitir registrar usuarios para tener acceso al sistema
RF1
con sus respectivos roles.
El sistema debe permitir registrar los diferentes tipos de contratos de
RF2
abonados.
El sistema permitirá registrar las diferentes tarifas que se manejan dentro
RF3
del parqueo.
El sistema debe permitir registrar los espacios de estacionamiento
RF4
existentes dentro del parqueo.
RF5 El sistema permitirá registrar a los clientes con sus datos personales.
RF6 El sistema debe permitir registrar los datos básicos de la movilidad.
RF7 El sistema permitirá registrar el contrato de abonado del cliente.
RF8 El sistema debe permitir al usuario registrar el pago del abonado.
El sistema debe identificar automáticamente mediante el número de
RF9 placa el tipo de cliente que accederá al parqueo. Además mediante el
número de placa registrara el ingreso y salida del parqueo del cliente.
RF10 El sistema permitirá generar ticket de visitantes.
El sistema debe permitir asignar espacio de estacionamiento según la
RF11
prioridad de contrato del cliente.
RF12 El sistema debe alertar al usuario los contratos por finalizar.
RF13 El sistema permitirá alertar al usuario de los visitantes recurrentes.
El sistema debe permitir realizar el cálculo de la estadía en el parqueo de
RF14
los clientes visitantes.
RF15 El sistema debe registrar el pago de los clientes visitantes.
RF16 El sistema debe permitir generar facturas.

4.1.2. Requerimientos no funcionales.-

Requerimientos de software:

39
  La base de datos deberá ser implementada en el SGBD
Microsoft SQL SERVER 2014.
 El sistema deberá ser una aplicación de escritorio, para acceder
desde un SO Windows 7.
 El sistema deberá ser desarrollado sobre el IDE Microsoft Visual
Studio 2019.
 El sistema será desarrollado en el lenguaje de programación C#.
Requerimientos de Seguridad:
 El acceso al sistema deberá ser con un usuario y contraseña el
cual debe ser encriptado.
4.2. Lista de casos de Usos del Sistema.-

 C.U.1.- Gestionar Usuarios.

 C.U.2.- Gestionar Contratos de Abonos.
 C.U.3.- Gestionar Tarifa de Visitantes.
 C.U.4.- Gestionar Espacios de Estacionamiento.
 C.U.5.- Registrar Cliente.
 C.U.6.- Registrar Vehículo.
 C.U.7.- Registrar Contrato de Abonado.
 C.U.8.- Registrar Pago de Abonado.
 C.U.9.- Verificar Placa.
 C.U.10.- Generar Ticket de Visitante.
 C.U.11.- Asignar Espacio de Estacionamiento.
 C.U.12.- Alertar Contrato por Finalizar.
 C.U.13.- Alertar Visitante Recurrente.
 C.U.14.- Calcular Pago de Visitante.
 C.U.15.- Registrar Pago de Visitante.
 C.U.16.- Generar Factura.

4.3. Diagramas de caso de uso.-

40
.
4.4. Descripción de los casos de uso.-

Una vez identificados los casos de uso del sistema y su relación con los
requerimientos funcionales se procederá a realizar una descripción de cada
uno de ellos.

41
Nro. de Caso de uso: C.U.1.
Nombre: Gestionar Usuarios.
Actores: Administrador.
Tipo: Primario, Alto Nivel.
Referencias: C.U.5.
El sistema debe permitir al administrador registrar a
Descripción: los usuarios con sus respectivos roles para que
puedan acceder al sistema.

Nro. de Caso de uso: C.U.2.

Nombre: Gestionar Contratos de Abonos.
Actores: Administrador.
Tipo: Primario, Alto Nivel.
Referencias: C.U.7.
El sistema debe permitir al administrador registrar
Descripción: los diferentes tipos de contratos de abono a los que
podrán acceder a contratar los clientes del parqueo.

Nro. de Caso de uso: C.U.3.

Nombre: Gestionar Tarifa de Visitantes.
Actores: Administrador.
Tipo: Primario, Alto Nivel.
Referencias: C.U.14.
El sistema permitirá al administrador registrar las
Descripción: diferentes tarifas que se encuentran vigente para el
uso del parqueo por parte de los clientes visitantes.

42
Nro. de Caso de
C.U.4.
uso:
Nombre: Gestionar Espacios de Estacionamiento.
Actores: Administrador.
Tipo: Primario, Alto Nivel.
Referencias: C.U.11.
El sistema debe permitir al administrador registrar
Descripción: los diferentes espacios de estacionamiento
habilitados dentro del parqueo.

Nro. de Caso de uso: C.U.5.

Nombre: Registrar Cliente.
Actores: Vendedor.
Tipo: Primario, Alto Nivel.
Referencias: C.U.1.
El sistema permitirá al vendedor de registrar los
Descripción: datos personales del cliente que accederá a un
contrato de abonado.

Nro. de Caso de uso: C.U.6.

Nombre: Registrar Vehículo.
Actores: Vendedor, Operador Entrada.
Tipo: Primario, Alto Nivel.
Referencias: C.U.9.
El sistema permitirá al vendedor de registrar los
datos básicos de la movilidad del cliente que
accederá a un contrato de abonado. Además,
Descripción:
permitirá al operador de entrada de registrar el
vehículo del cliente visitante si es la primera vez
que visita el parqueo.

Nro. de Caso de uso: C.U.7.

Nombre: Registrar Contrato de Abonado.
Actores: Vendedor.
Tipo: Primario, Alto Nivel.
Referencias: C.U.2.
Descripción: El sistema permitirá al vendedor de registrar en el
sistema los términos del contrato con el cliente que

43
 accederá a un contrato de abonado.

Nro. de Caso de uso: C.U.8.

Nombre: Registrar Pago de Abonado.
Actores: Vendedor.
Tipo: Primario, Alto Nivel.
Referencias: C.U.2., C.U.16.
El sistema permitirá al vendedor de registrar el pago
Descripción:
del cliente que accederá a un contrato de abonado.

Nro. de Caso de
C.U.9.
uso:
Nombre: Verificar Placa.
Actores: Operador Entrada, Operador Salida.
Tipo: Primario, Alto Nivel.
Referencias: C.U.6.
El sistema debe permitir tanto al operador de
entrada como al operador de salida identificar
automáticamente mediante el número de placa el
Descripción:
tipo de cliente que accederá al parqueo.
Además mediante el número de placa registrara el
ingreso y salida del parqueo del cliente.

Nro. de Caso de
C.U.10.
uso:
Nombre: Generar Ticket de Visitante.
Actores: Operador Entrada.
Tipo: Primario, Alto Nivel.
Referencias: C.U.3., C.U.9.
El sistema permitirá al operador de entrada de
Descripción: generar un ticket de visitante para la estadía del
cliente dentro del estacionamiento.

Nro. de Caso de uso: C.U.11.

Nombre: Asignar Espacio de Estacionamiento.
Actores: Operador Entrada.
Tipo: Primario, Alto Nivel.
Referencias: C.U.4.
Descripción: El sistema permitirá al operador de entrada de

44
 asignar un espacio para la estadía del cliente
dentro del estacionamiento.

Nro. de Caso de uso: C.U.12.

Nombre: Alertar Contrato por Finalizar.
Actores: Operador Salida.
Tipo: Primario, Alto Nivel.
Referencias: C.U.7.
El sistema alertara al operador de salida el contrato
Descripción: por finalizar dentro de dos días para avisar al cliente
sobre la situación.

45
Nro. de Caso de uso: C.U.13.
Nombre: Alertar Visitante Recurrente.
Actores: Operador Entrada.
Tipo: Primario, Alto Nivel.
Referencias: C.U.9.
El sistema permitirá alertar al operador de entrada
Descripción: de visitante recurrente al cual podrá ofrecer un
contrato de abonado.

Nro. de Caso de uso: C.U.14.

Nombre: Calcular Pago de Visitante.
Actores: Operador Salida.
Tipo: Primario, Alto Nivel.
Referencias: C.U.3.
El sistema permitirá al operador de salida calcular el
Descripción: pago por la estadía en el parqueo del cliente
visitante.

Nro. de Caso de uso: C.U.15.

Nombre: Registrar Pago de Visitante.
Actores: Operador Salida.
Tipo: Primario, Alto Nivel.
Referencias: C.U.14.
El sistema permitirá al operador de salida de
Descripción:
registrar el pago por la estadía del cliente visitante.

46
Nro. de Caso de uso: C.U.16.
Nombre: Generar Factura.
Actores: Operador Entrada, Operador Salida. Vendedor.
Tipo: Primario, Alto Nivel.
Referencias: C.U.8., C.U.15.
Descripción: El sistema permitirá al usuario generar facturas.

47
 CAPITULO V

5. Modelo de Análisis.-
5.1. Modelo Conceptual.-

5.2.Modelo clases.-

48
5.3. Identificación de Objetos.-
Al menos 5 clases
5.4. Modelo de Comportamiento.-
Descripción de cada caso de uso más su diagrama de secuencia, de los tres
que se programen.
5.3. Modelo Dinámico.-
5.3.1. Diagramas de Estado
para los objetos que tienen diferentes estados. (Al menos una clase)
5.3.2. Diseño lógico de base de datos.-
ads
5.3.3. Diseño físico de base de datos.-
Ads

49
 CAPITULO VI
 6. Modelo de Implementación.-
6.1. Diagrama de Componentes de ejecución.-
(del software)
6.2. Diagrama de Nodos o de despliegue.-
(con nombre, software para su funcionamiento)
6.3. Implementación de las clases de software.-
de mayor importancia

50
CAPITULO VII
 7. Modelo de Pruebas.-
3 casos de uso
Indicar las técnicas utilizadas para realizar las pruebas
Escenarios de prueba para algunos casos de usos críticos

51
 CAPITULO VIII

8. Conclusiones.-
Este proyecto tuvo como objetivo desarrollar un sistema de información para la
administración de los clientes del parqueo Central Park. Con base en un análisis
cuantitativo, los análisis demuestran que la implementación de este sistema
ayudara a que el negocio mejore en el manejo y gestión de sus clientes dentro del
parqueo, además de ayudar en la toma de decisiones a futuro que mejoraran la
calidad y atención del servicio brindado.
Con la aplicación del proceso de desarrollo unificado de sistemas se identificaron
los requerimientos funcionales del sistema, describiendo y analizando los casos
de uso ampliamente, que ayudaron en la implementación correcta del software.

52
 CAPITULO IX

9. Recomendaciones.-

Trabajar en mejorar el diagrama de clases en este proyecto para tener un óptimo

funcionamiento del sistema en el futuro.
Extender los estudios sobre los casos de usos para que se complemente y sean
acorde al diagrama de clases.

53
 CAPITULO X

10. Bibliografía.-

 PRESSMAN. Roger S. Ingeniería del Software: Un enfoque Práctico. McGraw

Hill. USA. 2010.

 SOMMERVILLE, Ian. Ingeniería del Software. Pearson. USA. 2011.

 JACOBSON, Ivar; BOOCH, Grady; RUMBAUH, James. El Proceso Unificado

de Desarrollo de Software, Addison Wesley. USA. 2000.

54
 CAPITULO XI

11. Anexos.-

55