Defensa Del Caso de Estudio de Examen de Grado para Optar Al Título de Licenciatura en Ingeniería en Sistemas
August 1, 2022 | Author: Anonymous | Category: N/A
Short Description
Download Defensa Del Caso de Estudio de Examen de Grado para Optar Al Título de Licenciatura en Ingeniería en Sistemas...
Description
UNIVERSIDAD TECNOLÓGICA PRIVADA DE SANTA CRUZ FACULTAD DE CIENCIA Y TECNOLOGÍA CARRERA: INGENIERÍA EN SISTEMAS ÁREA: BASE DE DATOS
CASO DE ESTUDIO: “SISTEMA DE GESTIÓN DE INFORMACÍON SOBRE COSTOS DE MANTENIMIENTOS DE LOS MÓDULOS EDUCATIVOS CONSTRUIDOS POR LA H.A.M. DE SANTA CRUZ”
AUTOR:
DEFENSA DEL CASO DE ESTUDIO DE EXAMEN DE GRADO PARA OPTAR AL TÍTULO DE LICENCIATURA EN INGENIERÍA EN SISTEMAS
SANTA CRUZ – BOLIVIA BOLIVIA
Sistema de gestión de información sobre costos costos de mantenimientos mantenimientos de los módulos educativos construidoss por la H.A.M. de Santa Cruz. construido 1
Índice Índice de tabla ............................................................................................................................... ............................................................................................................................... 3 Índice de ilustración ........................................................................................................... ...................................................................................................................... ........... 3 Capítulo I Aspecto Generales........................................................... ........................................................................................................ ............................................. 4 Introducción ........................................................... .............................................................................................................................. ................................................................... 4 Definición del problema............................................................... ............................................................................................................ ............................................. 5 Situación deseada ........................................ ........................................................................................................... .............................................................................. ........... 5 Delimitaciones.................................................................................................................... ............................................................................................................................... ........... 5 Delimitación espacial ........................................................ ................................................................................................................ ........................................................ 5 Delimitación temática ............................................................................................................... 5 Delimitación temporal................................................................... ............................................................................................................... ............................................ 5 Objetivo general y específicos ...................................................................................................... 6 Objetivo general ........................................................................................................................ ........................................................................................................................ 6 Objetivo especifico............................................................ .................................................................................................................... ........................................................ 6 Capitulo II marco teórico .............................................................................................................. .............................................................................................................. 6 Marco teórico metodología ........................................................................................................... ........................................................................................................... 6 Base de datos:............................................................................................................................ ............................................................................................................................ 6 Campo ....................................................................................................................................... ....................................................................................................................................... 6 Registro ..................................................................................................................................... ..................................................................................................................................... 6 Sistema de gestión de base de datos (SGBD )........................................................................... 6 Administrador de base de datos(DBA) ..................................................................................... ..................................................................................... 6 modelo de base de datos ............................................................................................................ ............................................................................................................ 7 Tipos de Modelos de base de datos .......................................................... ........................................................................................... ................................. 7 Modelo relacional.............................................................. ...................................................................................................................... ........................................................ 7 Modelo Jerárquico..................................................................................................................... ..................................................................................................................... 7 Modelo de Red .............................. .................................................................................................... ............................................................................................ ...................... 7 Modelo Orientado a Objetos .................................. ..................................................................................................... ................................................................... 7 Modelo entidad Relación .......................................................................................................... .......................................................................................................... 7 Relación (Tabla) ................. ....................................................................................... ....................................................................................................... ................................. 8 Tupla o registro ......................................................................................................................... ......................................................................................................................... 8 Grado de Relación ............................................................. ..................................................................................................................... ........................................................ 8 Dominio..................................................................................................................................... Dominio............................................................................................................... ...................... 8 Atributo ..................................................................................................................................... ..................................................................................................................................... 8 Primary Key .............................................................................................................................. .............................................................................................................................. 8 Foreign Key............................................................ ............................................................................................................................... ................................................................... 8 Integridad de Entidad ................................................................................................................ ................................................................................................................ 8
1
Integridad Referencial ............................................ ............................................................................................................... ................................................................... 9 Normalización .................................................................... ........................................................................................................................... ....................................................... 9 MARCO TEÓRICO DE LA METODOLOGÍ METODOLOGÍA A ................................................................... ........................................................................... ........ 9 PUD................................................................................................................................... ........................................................................................................................................... ........ 9 Características ........................................................................................................................... 9 Dirigido Por Casos De Uso ....................................................................................................... ....................................................................................................... 9 Centrado En La Arquitectura ......................................................................................... .................................................................................................. ......... 10 Iterativo E Incremental.................................................................. ............................................................................................................ .......................................... 10 Fases ............................................................................................................................................ ............................................................................................................................................ 10 Inicio ........................................................... .............................................................................................................................. ............................................................................ ......... 10 Elaboración ............................................................ ............................................................................................................................. ................................................................. 10 Construcción ........................................................................................................................... ........................................................................................................................... 10 Transición....................................................................................................................... ................................................................................................................................ ......... 10 Planificación Temporal ........................................................................................................... ........................................................................................................... 10 UML.................................................................................. ........................................................................................................................................ ...................................................... 10 Diagramas .............................................................. ............................................................................................................................... ................................................................. 11 Clasificación De Diagramas ........................................................................................................ ........................................................................................................ 11 Diagramas Estáticos .......................................................... ................................................................................................................ ...................................................... 11 Diagrama De Clase ................................................................................................................. 11 Diagrama De Objeto ............................................................................................................... 11 Diagrama De Componentes ................................................................................ .................................................................................................... .................... 11 Diagrama De Despliegue .................................................................................... ........................................................................................................ .................... 11 Diagramas Dinámicos ................................................................................................................. ................................................................................................................. 11 Diagrama De Casos De Uso ......................................................... .................................................................................................... ........................................... 11 Diagrama De Secuencia .......................................................................................................... .......................................................................................................... 11 Diagrama De Actividad........................................................................................................... ........................................................................................................... 11 Diagrama de colaboración............................................................ ....................................................................................................... ........................................... 11 Capitulo III ingeniería del proyecto ............................................................................................ ............................................................................................ 12 casos de uso ................................................................ ................................................................................................................................. ................................................................. 12 Modelo de requerimientos................................................................. ........................................................................................................... .......................................... 12 Requerimiento funcionales........................................................... ...................................................................................................... ........................................... 12 Requerimiento no funcionales.................................................................. ................................................................................................. ............................... 13 Requerimiento de performance ................... ...................................................................................... ............................................................................ ......... 13
Descripción de actores ................................................................................................................ ................................................................................................................ 13 Modelo de análisis....................................................................................................................... ....................................................................................................................... 14 Diagrama de caso de uso ............................................................................................................. ............................................................................................................. 14 Diagrama de clase conceptuales................................................................... .................................................................................................. ............................... 16 2
Modelo de dominio ............................................................... ..................................................................................................................... ...................................................... 17 Modelo de dominio relacional (Mapeo) .................................................................. ...................................................................................... .................... 20 Modelo de diseño ............................................................................................................... ........................................................................................................................ ......... 26 Arquitectura de la aplicación....................................................................................................... 26 MVC.................................................................................................................... ........................................................................................................................................ .................... 26 Diagrama de actividades ............................................................................................................. ............................................................................................................. 27 Diagrama de secuencia................................................................................................................ ................................................................................................................ 28 Registro de asignación ............................................................................. ............................................................................................................ ............................... 28 Diagrama físico ................................................................................. ........................................................................................................................... .......................................... 29 Modelo de implementación ......................................................................................................... ......................................................................................................... 30 Modelo de componentes............................... componentes..................................................................................................... ............................................................................... ......... 30 Gestión de asignación ............................................................................................................. ............................................................................................................. 30 Modelo de despliegue ........................................................................................................ ................................................................................................................. ......... 31 Modelo de prueba................................................................... ........................................................................................................................ ..................................................... 31 Prueba funcionalidad..................................................................... ............................................................................................................... .......................................... 32 Backup de base de datos.............................................................................................................. datos.............................................................................................................. 32 Diseño de reportes ....................................................................................................................... ....................................................................................................................... 34 Implementación de requerimientos ................. .................................................................................... ............................................................................ ......... 34 Formulario login...................................................................................................................... ...................................................................................................................... 34 Formulario Listado de solicitudes .... ....................................................................... ....................................................................................... .................... 35 Formulario nueva solicitud...................................................................................................... solicitud...................................................................................................... 35 Mensaje del formulario ................................................................. ........................................................................................................... .......................................... 36 Conclusión............................................................................................................... Conclusión............................................ ....................................................................................... .................... 37 Recomendación ........................................................................................................................... ........................................................................................................................... 37 Bibliografía ................................................................................................................................. ................................................................................................................................. 38 ANEXOS.......................................................................................... ANEXOS..................... ................................................................................................................ ........................................... 38
Índice de tabla Tabla 1 Requerimiento funcionales............................................................. ............................................................................................. ................................ 12
Tabla 2 Descripción de actores ................................................................................................... 13 Tabla 3 especificación de requisito ...... ......................................................................... ....................................................................................... .................... 15
Índice de ilustración Ilustración 1 Diagrama de caso de uso ........................................................................................ ........................................................................................ 14 Ilustración 2 Diagrama de clase ............................................ .................................................................................................. ...................................................... 16 Ilustración 3 Diagrama modelo de dominio ................................................................................ ................................................................................ 17 Ilustración 4 Diagrama de actividades .............................................. ........................................................................................ .......................................... 27 Ilustración 5 Diagrama de secuencia........................................................................................... ........................................................................................... 28 Ilustración 6 Diagrama Físico ................................................................................. ..................................................................................................... .................... 29 3
Ilustración 7 Modelo de componente ........................................................... .......................................................................................... ............................... 30 Ilustración 8 Diagrama de despliegue ....................................................................... ....................................................................................... .................... 31
Capítulo I Aspecto Generales Sistema de gestión de información sobre costos de mantenimientos de los módulos educativos construidos por la H.A.M. de Santa Cruz.
Introducción La Honorable Alcaldía Municipal de la ciudad de Santa Cruz de la Sierra, ha tenido un rol importante con la sociedad ya que ha invertido bastante en la construcción de nuevas infraestructuras educativas comúnmente llamadas módulos educativos, para brindar una mejor calidad de ambiente a los estudiantes. En Santa Cruz se han construidos más de 400 nuevos módulos y se han refaccionado más de 200 infraestructuras antiguas en estos últimos años, pero, con el pasar del tiempo la un unidad idad de presupuesto para mantenimientos de de la Honorable Alcaldía Municipal Municipal ha perdido el control del orden de los mantenimientos hechos a los l os módulos educativos. Una infraestructura o módulo educativo inicialmente es entregada en perfectas condiciones para su uso, con el pasar del tiempo la unidad de mantenimiento de la Honorable Alcaldía Municipal ha comenzado a recibir solicitudes de mantenimiento desde las direcciones escolares de las diferentes unidades educativas. Estas solicitudes llegan a través de cartas en papel iimpreso mpreso y son archivadas en folders apilados por N° de UV. La Honorable Alcaldía Municipal ha clasificado los diferentes tipos de mantenimientos que deben correr económicamente su cuenta: Pintado general dedeparedes, de verjas, Pintado de canchas deportivas,por Tapado de goteras, Barnizados puertas Pintado y Reposición de vidrios rotos de ventanas, Arreglos de problemas de electricidad, mantenimientos de la jardinería, Corredores públicos, etc. etc. Para el presente proyecto se desarrollará un sistema de gestión de información sobre costos de mantenimientos de los módulos educativos construidos por la Honorable Alcaldía Municipal de
Santa Cruz, utilizando la metodología de desarrollo “Proceso Unificado de Desarrollo de Software (P.U.D.S)” y UML (Lenguaje Unificado de Modelado) para el diseño de las tablas
relacionales. El mismo que tomara un tiempo planificado para su elaboración, lo cual se considera como inicio el 10 de marzo de 2020 y una duración de ocho meses para la conclusión del proyecto. El equipo de desarrollo estará conformado c onformado por tres personas: un analista de Sistemas y dos desarrolladores, elaborando el proyecto en la ciudad de Santa Cruz de la Sierra. Posteriormente para conseguir el objetivo planeado se se utilizará varias herramientas de software entre entre ellos: Architect para los diseñar los modelos y diagramas de datos, Visual Studio como entorno de desarrollo y MYSQL para la elaboración de la base de datos. Para el presente proyecto se desarrollará un de ventas de automóviles para la empresa HAM, utilizando la metodología PUD “Proceso Unificado de Desarrollo”.
4
Definición del problema La Honorable Alcaldía Municipal de Santa Cruz de la Sierra, en los últimos años ha tenido un crecimiento preocupante de solicitudes de mantenimiento de cada infraestructura educativa, de tal manera que ha perdido el control del orden de los mantenimientos a los módulos educativos. Los problemas se generan cuando las solicitudes son registradas u/o manejadas físicamente en folders apilados por N° de UV, generando una mala organización de los documentos tanto en orden y numeración de los mismos. La unidad de presupuesto para mantenimiento de la Honorable Alcaldía Municipal necesita atender las solicitudes de los diferentes módulos por orden de llegada. Además, precisa registrar todos los gastos que se han hecho en el mantenimiento de una determinada solicitud. Por otro lado, se necesita conocer el total de gastos por cada proyecto de mantenimiento durante cada gestión.
Situación deseada Se requiere conocer el listado de solicitudes de mantenimiento pendientes. Se requiere un listado de mantenimientos en proceso. Saber el costo total de mantenimiento por unidad educativa ordenado por la UV donde
está construido el modulo. Consolidado de costos por tipo de mantenimiento terminado por año.
Delimitaciones Delimitación espacial El presente Proyecto de la Honorable Alcaldía Municipal HAM, se elabora dentro del espacio
geográfico de Santa Cruz de la Sierra.
Delimitación temática El presenta proyecto se encuentra enmarcada en el área de Base de datos.
Delimitación temporal El proyecto se iniciará en el presente año desde el 10 mes de marzo a 20 de noviembre
5
Objetivo general y específicos Objetivo general Desarrollar un Sistema de gestión de información sobre costos de mantenimiento de los módulos educativos construidos por la H.A.M de Santa Cruz.
Objetivo especifico Conocer lo procesos administrativos para el sistema de gestión de información sobre
costos de mantenimientos de los módulos educativos construidos por la H.A.M de Santa Cruz. Identificar todos los requisitos funcionales en base a los procesos administrativos para la H.A.M de Santa Cruz. Realizar el modelo de requisitos, las capturas de requisitos funcionales y no funcionales Sintetizar un modelo de datos para la implementación de la base de datos para la H.A.M. Realizar un laboratorio de prueba de sistema
Capitulo II marco teórico Marco teórico metodología
Base de datos: Una base de datos es una colección disponible de datos estructurado según un modelo donde se reflejan las relaciones y restricciones que existe en el mundo real Una base de datos es un conjunto de datos relacionados entre sí. Por datos entendemos hechos conocidos que pueden registrarse y que tienen un significado implícito. (Ramez Elmasri, 2007)
Campo Un campo es la mínima -unidad de información a la que se puede acceder.
Registro Un registro también llamado fila o tupla, Conjunto de campos lógicamente relacionados.
Sistema de gestión de base de datos (SGBD ) Son software muy específico, dedicado a servir de interfaz entre la base de datos y las aplicaciones que utilizan. Software que gestiona y controla BD. Sus principales funciones son facilitar la utilización de la BD a muchos usuarios simultáneos y de tipos t ipos diferentes, independizar al usuario del mundo físico y mantener la integridad de los datos.
Administrador de base de datos(DBA) Es la persona o equipo de personas profesionales responsables del control y manejo del sist sistema ema de base de datos. Tipo de usuario especial que realiza funciones de administración y control de la BD, que aseguran que la explotación de la BD es correcta. 6
modelo de base de datos
Un modelo de base de datos es un tipo de modelo de datos que determina la estructura lógica de una base de datos y de manera fundamental determina el modo de almacenar, organizar y manipular los datos.
Tipos de Modelos de base de datos Hay muchos tipos de modelos de base de datos. Algunos de los más comunes incluyen:
Modelo relacional Siendo el modelo más común, el modelo relacional ordena los datos en tablas, ttambién ambién conocidas como relaciones, cada una de las cuales se compone de columnas y filas. El modelo también representa los tipos de relaciones entre esas tablas, incluidas las relaciones uno a uno, uno a muchos y muchos a muchos. Dentro de la base de datos, las tablas se pueden normalizar, es decir, hacer que cumplan las reglas de normalización que hacen a la base de datos flexible, adaptable y escalable. Al estar normalizada, cada porción de los datos es atómica, es decir, está dividida en partes útiles lo más pequeñas posibles.
Modelo Jerárquico El modelo jerárquico organiza los datos en una estructura de árbol, en la que cada registro tiene un único elemento o raíz. Los registros del mismo nivel se clasifican en un orden especifico. Ese orden se usa a manera de orden físico para almacenar la base de datos. El modelo es bueno para describir muchas relaciones del del mundo real.
Modelo El modelode deRed red se basa en el modelo jerárquico, permitiendo relaciones de muchos a muchos entre registros vinculados, lo que implica registros principales múltiples. Basado en la teoría matemática de conjuntos, el modelo se construye con conjuntos de registros relacionados. Cada conjunto consiste de un registro propietario o principal y uno o más registros miembros o secundarios. Un registro puede ser miembro o secundario en múltiples conjuntos, permitiendo que este modelo represente relaciones complejas. Modelo Orientado a Objetos Este modelo define una base de datos como una colección de objetos, o elementos de software reutilizables, con funciones y métodos relacionados. Incorpora todo el concepto importante del paradigma de objetos: Encapsulación Herencia Polimorfismo
Modelo entidad Relación Este modelo capta las relaciones entre entidades del mundo real de forma muy similar al modelo de red, pero no está directamente ligado a una estructura física de la base de datos. En cambio, con frecuencia se lo usa para diseñar una base de datos conceptualmente. Aquí, a las personas, lugares y cosas, acerca de las cuales se almacenan puntos de datos, se las denomina entidades, cada una de las cuales tiene ciertos atributos que en conjunto forman su dominio. La cardinalidad, o relaciones entre entidades, también se representa en diagramas.
7
Relación (Tabla) En bases de datos, una relación r elación o vínculo entre dos o más entidades describe alguna interacción entre las mismas. Las relaciones se describen en la estructura de la base de datos empleando un modelo de datos. El modelo relacional proporciona una manera simple de representar los datos: una tabla bidimensional llamada relación.
Tupla o registro Corresponde a una fila de la tabla. Representa cada una de las ocurrencias de la relación (equivale a lo que conocemos como ocurrencia de un registro, en ficheros clásicos). El número de tuplas se denomina cardinalidad, la cardinalidad varía con el tiempo.
Grado de Relación Numero de atributos o columnas columnas
Dominio Es el conjunto de todos los posibles valores que puede tomar un atributo de la relación. No es más que un tipo de datos. Ejemplo: Booleano, Entero, Cadena de Caracteres, etc. Los valores de un dominio se establecen con anterioridad a su utilización, utilizaci ón, expresando las posibles restricciones que se deseen deseen para los atributos.
Atributo Los atributos son las columnas de una relación y describen características particulares de ell ella. a. Existen varios tipos de atributos que son: Atributos Monovaluados: poseen un solo valoren particular Eje.: edad, sueldo,
marca. Atributos Multivaluados: pueden poseer varios valores para una entidad Eje.: Email, oficios, condecoraciones, teléfonos. Atributos Obligatorios: siempre tienen un valor asignado Eje.: fecha de nacimiento, carrera, marca, precio. Atributos Opcionales: pueden registrarse o no de la base de datos Eje.: religión, Partido político, etc. Atributos Calculables O Derivados: se dice calculable porque su valor se puede obtener de otros atributos almacenados en la base de datos.
Primary Key Las llaves primarias (Primary Key) son los que identifican de manera única cada fila o registro de una tabla, esto quiere decir que no se puede repetir en una tabla el valor de un campo o columna que se le es asignado como primary key.
Foreign Key Una llave foránea, externa o ajena, es un es un campo de una tabla “X” que sirve para enlazar o relacionar entre sí con otra tabla “Y” en la cual el campo de esta tabla es una llave primaria
(Primary Key). Para que sea una llave foránea un campo, esta tiene que ser una llave primaria en otra tabla.
Integridad de Entidad Pretende que cada entidad que se guarda en la base de datos sea identificable de un modo único, es decir, que evitemos la información redundante. La integridad de entidad define una fila como 8
entidad única para una tabla determinada. La integridad de entidad exige la integridad de las columnas de los identificadores o la clave principal de una tabla, mediante índices y restricciones UNIQUE, o restricciones PRIMARY KEY.
Integridad Referencial La integridad referencial garantiza que los valores de clave sean coherentes en las distintas tablas. Para conseguir esa coherencia, es preciso que no haya referencias a valores inexistentes y que, si cambia el valor de una clave, todas las referencias a ella se cambien en consecuencia en toda la base de datos.
Cualquier valor que tome un atributo en una relación del que es clave foránea, debe existir en la relación que es clave primaria.
Normalización El proceso de normalización de una base de datos relacional consiste en aplicar una serie de reglas para evitar a futuro realizar o consultas innecesariamente complejas. En otras palabras, están enfocadas en eliminar redundancias e inconsistencias de dependencia en el diseño de las tablas. (Castaño, 1993) Las bases de datos se normalizan para: Evitar la redundancia de datos. Proteger la integridad de los datos. Evitar problemas de actualización de los datos en las tablas.
Para poder decir que nuestra base de datos está normalizada deben respetarse 3 niveles
de normalización.
MARCO TEÓRICO DE LA METODOLOGÍA PUD Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un software. El proceso unificado es un marco de trabajo que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. (Sommerville, 2005)
Características Dirigido Por Casos De Uso Un caso de uso es una pequeña funcionalidad del sistema que devuelve al usuario un resultado importante. el conjunto de casos de uso de un sistema representa la funcionalidad total del producto. Los casos de uso uso no solo inician el proceso de de desarrollo, sino que brindan un hilo constructor a través de todo el proceso, los casos se analizan, diseñan se implementan y se construyen los modelos de prueba.
9
Centrado En La Arquitectura El Proceso Unificado asume que no existe e xiste 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 arquitectura del sistema es un modelo que permite ver al producto antes de que este haya sido construido. Es decir, los casos de uso representan la funcionalidad del sistema y la la arquitectura la forma.
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. Es práctico dividir al proyecto en pequeños mini proyectos. Estos mini proyectos o iteraciones incrementan la funcionalidad del sistema para cada mini proyecto se realizan 5 flujos de trabajo requisitos, análisis, diseño, implementación y prueba.
Fases Inicio En la fase de inicio se desarrolla una descripción del producto final, y se representa el análisis del negocio. En esta fase se identifican las principales funciones del sistema.
Elaboración Durante esta fase se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura, la resolución de riesgos altos, nuevos requisitos y se ajustan estimaciones.
Construcción El producto se crece hasta convertirse en un sistema completo preparados para ser empleado a la comunidad de usuarios, puede que no esté completamente libre de defectos. Muchos de esos defectos se descubrirán y solucionarán durante la fase de transición.
Transición Esta fase cubre el periodo de entrega del producto a la comunidad de usuarios. Se capacita al personal o usuario finales de de la aplicación, se crean los manuales o ayudas del sistema.
Planificación Temporal La planificación temporal tiene como objetivo evitar el retraso en la entrada del sistema. Un sistema de software general debe cumplir plazos o fechas de entrega impuestas por departamentos fuera del equipo de desarrollo en consecuencia pueden ser fechas irrealistas.
UML El Lenguaje Unificado de Modelado (UML - Unified Modeling Lenguaje) es un lenguaje gráfico para visualizar, especificar, construir y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema. (schmuller)-
10
Diagramas Un diagrama es una representación gráfica de un conjunto de elementos, se utilizan para ver al sistema de diferentes perspectivas. Como ningún sistema puede ser comprendido completamente desde una única perspectiva UML utiliza 9 diagramas que permiten centrase en diferentes aspectos del sistema independientemente.
Clasificación De Diagramas Se dispone dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que dan unadevisión dinámica.
Diagramas Estáticos Diagrama De Clase Este diagrama sirve para visualizar las l as relaciones entre las clases que involucran i nvolucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenido.
Diagrama De Objeto Un diagrama de objeto es esencialmente una instancia una instancia de un diagrama de clase o la parte estática de un diagrama de interacción, en un diagrama de objeto podremos encontrar objetos y enlaces.
Diagrama Componentes Un diagramaDe de componentes muestra la relación estructural de los componentes de un sistema de software. Los componentes se comunican entre sí mediante interfaces.
Diagrama De Despliegue Los Diagramas de Implementación se usan para modelar sólo componentes que existen como entidades en tiempo de ejecución; no se usan para modelar componentes solo de tiempo de compilación o de tiempo de enlazado.
Diagramas Dinámicos Diagrama De Casos De Uso Los diagramas de casos de uso ofrecen una visión general de los actores involucrados i nvolucrados en un sistema, las diferentes funciones que necesitan esos actores y cómo interactúan estas diferentes funciones.
Diagrama De Secuencia Los diagramas de secuencia muestran como los objetos interactúan entre si y el orden en que se producen esas interacciones. Es importante tener en cuenta que muestran muestran las interacciones para un escenario en particular.
Diagrama De Actividad Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema.
Diagrama de colaboración Este diagrama la interacción entreorganizadas varios objetos y los enlaces existen Representa las muestra interacciones entre objetos alrededor de los l os que objetos y susentre ellos. vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan información similar, pero en una forma diferente. 11
Capitulo III ingeniería del proyecto casos de uso Los siguientes casos de uso a tomar en cuenta para el modelado será el de gestión de gestión de las solicitud y gestión de oferta, gestión de asignación en donde se utiliza para la aprobación de brinda el trabajo de mantenimiento a la empresa establecida. establecida.
Modelo de requerimientos Requerimiento funcionales Son funciones que el software a desarrollar debe hacer, acciones que el software o producto tiene que tomar. Este tipo de requisitos describen todas las entradas y salidas del sistema y la forma en que se relacionan.
Nro. RF1
Requerimiento RF1 Gestionar Usuario
RF2
Gestionar Acceso
RF3
Gestionar Detalle Acceso
RF4
Gestionar Persona
RF5
Gestionar Funcionario
RF6
Gestionar Representante
RF7
Gestionar obra
RF8
Gestionar solicitud
RF9 RF11
Gestionar Tipo de Mantenimiento Gestionar Oferta
RF12
Gestionar Asignación
Tabla 1 Requerimiento funcionales
Descripción El administrador podrá gestionar los usuarios que tengan acceso al sistema. El administrador podrá gestionar los accesos al sistema. El administrador podrá gestionar los accesos de los usuarios que tienen acceso al sistema. El usuario podrá gestionar los datos de las personas para que sean registrados como como funcionarios El usuario administrador podrá gestionar todos los funcionario que están en la H.A.M El usuario representante podrá gestionar todos las ofertas de las solicitudes de la l a H.A.M El usuario de operaciones podrá gestionar todos las obras que fueron aprobados El usuario recepcionista podrá gestionar todas las solicitudes que llegan a la H.A.M El usuario recepcionista será capaz de gestionar los tipos de mantenimientos que existen en la H.A.M El representante será capaz de gestionar Los presupuesto que va a ser por por la solicitud El usuario será capaz de gestionar aprobar las ofertas realizadas por la empresa
12
Requerimiento no funcionales Bitácora Encriptación de password
Control de versiones
Requerimiento de performance Para el desarrollo de este sistema se requiere distintas herramientas como ser: Visual Studio Code 1.40 o superior PHP 7.2 o superior El sistema debe visualizarse y funcionar correctamente en cualquier navegador
ya sea internet Explorer, Chrome, otros. Y en cualquier dispositivo con conexión a Internet. El sistema se debe programar en el lenguaje PHP – Framework Framework Laravel 7 El sistema debe conectarse a una base de datos MYSQL.
El sistema debe tener una programación orientado a objetos. La interfaz del sistema debe ser de fácil utilización y agradable a la vista de los
usuarios. Se necesita contar con Bitácora. Para poder auditar el sistema.
Descripción de actores Operador Operador Administrador Recepcionista Es el encargado de Es el encargado de gestionar los usuarios registrar las de la empresa y todo asignaciones de la relevante a la oferta establecida por administración dentro la empresa. del sistema del personal, seguridad seguridad de los accesos , ver los informes proporcionadoss por el proporcionado sistema Tabla 2 Descripción de actores
Representante Es el encargado de
Ciudadano Es el encargado de crear una solicitud
de mantenimiento enviar una de la unidad propuesta de educativa presupuesto sobre el trabajo de la solicitud de mantenimiento
13
Modelo de análisis Diagrama de caso de uso uc Use Case Model
Caso de uso H.A.M
Gestion de clasificacion
Gestionar persona
Administrador
Gestion de Solicitud
Gestionar Funcionario
Gestion de Obra
Gestionar Asignacion Funcionario Gestion Tipo Mantenimiento
Gestion municipio
Administracion de Gestion
Mostrar listado de Solicitudes
Gestion de Oferta
Gestionar Presupuesto
Gestionar Control Mantenimiento
Gestionar Empresa Empresa
Ilustración 1 Diagrama de caso de de uso
Ciudadano
Represetante
Especificación del caso de uso seleccionado Caso de uso 14
Caso de uso aprobación oferta
ESPECIFICACIÓN ESPECIFICAC IÓN DE REQUISITO Nombre: Descripción: Dependencias: Actores: Flujo Normal
Interfaz de Gestionar Gastos la Muestra unavisualización interfaz paradel querequisito el usuario pueda gestionar información referente a los gastos de cada obra que hay en la H.A.M solicitudes registrados Funcionario operaciones Técnico Sistema 1.-El actor solicita ingreso al 2. el sistema muestra un sistema formulario de autentificación 3.- El actor ingresa su usuario y 4. el sistema valida los campos contraseña ingresados 5.- El actor va a la opción 6. muestra interfaz listado de administración de asignación 7.- el actor selecciona botón “nueva asignación”
11. el actor hace clic en el botón “Guardar ”
laselasignaciones realizadas 8. sistema muestra el panel “registro de totas las oferta de la solicitud”
9. el sistema muestra los detalles de la oferta que fue realizado 10. el sistema muestra el presupuesto total. 12. muestra un mensaje de guardado exitosamente 13 quita del listado de los solicitudes pendientes 14 actualizar a finalizado la asignación de la oferta
Flujo alterno 3.1 si el actor ingresa mal su usuario o contraseña no
ingresara al sistema Tabla 3 especificación de requisito
15
Diagrama de clase conceptuales class Class Model
perfil_persona
funcionario
persona
perfil_permiso
perfil
permiso
ciudadano
solicitud_imagen imagen represetante
obra_imagen
gestion
barrio
provincia
solicitud_tipo
municipio
obra
solicitud
tipomantenimiento
nivel tipoobra detalle_oferta
a si gna ci on
oferta
detalleasignacion
empresa
servicio_trabajo
Ilustración 2 Diagrama de clase
16
Modelo de dominio class Class Model
persona
funcionario -
codigo fechaingreso cargo
-
perfil_permiso
perfil_persona
nombre apellido ci correo username estado sexo tipousuario telefono celular
permiso perfil *
*
-
nombre tipo estado
*
*
-
*
nombre descripcion pantalla orden icono
0..1
ciudadano 0..1
solicitud_imagen imagen
*
-
represetante
1
filename: int src: int ancho: int alto: int estado: int
*
gestion
*
-
obra_imagen barrio -
nombre codigo zona estado
obra
nombre estado
municipio 1
1
solicitud_tipo -
1
cantidad disponible
*
provincia -
*
1
descripcion fechainicio fechafinal mes año estado
*
-
nombre estado
1
*
*
-
nombre nro uv distrito fecha lat lng telefono estado
solicitud *
1
tipomantenimiento
*
*
-
motivo estado status 1
*
*
-
nombre estado *
1
1
-
detalle_oferta
*
tipoobra
1
nombre estado
*
nivel -
oferta
nombre estado
asignacion -
-
comentario * estado status
*
-
cantidad precio obs
comentario obs estado status * fechainicio fechafinal preciototal
detalleasignacion *
empresa
*
-
nombre direccion correo estado
servicio_trabajo 1
*
-
precio estado
Ilustración 3 Diagrama modelo de de dominio
17
Modelo de dominio relacional (Mapeo) bitacora
bitacoraid personaid fechahora accion transaccion detalle PK
tipo
idimplicado
persona personaid nombre apellido ci correo username password estado sexo tipousuario telefono celular imagenid) PK FK permiso permisoid nombre estado PK perfil
descripcion permisopadreid pantalla FK
PerfilId Nombre Tipo Estado PK
perfil_persona perfilid personaid PK PK FK FK perfil_permiso perfilid permisoid PK PK FK
orden
iconomenu
FK ciudadano ciudadanoid estado PK FK 20
funcionario funcionarioid fechaingreso codigo cargo estado PK FK imagen imagenid PK
filename
src
ancho alto
estado
provincia provinciaid nombre PK
estado
municipio municipioid nombre PK
lat
lng
estado
zona
estado
barrio
barrioid PK
nombre
codigo
nivel
nivelid PK
nombre
estado
nombre
estado
tipo_obra tipoobraid PK
provinciaid provinciaid FK
21
gestion gestionid PK
obra
obraid PK
descripcion
estado
fechainicio
uv lat
obra_imagen id estado PK
status
fechafinal mes
anio
estado
lng direccion municipioid fecha gestionid nombre telefono tipoobraid nivelid barrioid nro distr distritomunicipal itomunicipal FK FK FK FK FK
obraid FK
tipomantenimientoid toid nombre tipomantenimiento tipomantenimien
imagenid FK
estado
usuariocreador usuariomodificado usuariomodificadorr fechacreacion fechamodificacion
PK
solicitud_mantenimiento solicitudid gestionid PK FK solicitudid PK FK
solicitud_tipomantenimiento
motivo
obraid FK
tipomantenimientoid tipomantenimientoid PK FK
status
ciudadanoid estado FK
cantidad
disponible
22
solicitud_imagen solicitudid imagenid PK FK PK FK oferta ofertaid PK
estado
detalle_oferta id PK
empresaid FK ofertaid FK
comentario
empresaid PK
nombre
representante representanteid PK FK
obs
tipomantenimientoid cantidad FK
servicio_trabajo serviciotrabajoid precio PK empresa
preciototal
direccion
solicitudid status FK
estado
fechafinalizada
precioactual obs
tipomantenimientoid tipomantenimientoid estado FK correo
fechaprogramada
empresaid FK
representanteid telefono FK
estado
PK = = primary key FK = Foreign key
23
Modelo de diseño Arquitectura de la aplicación MVC Model: este componente se encarga de manipular, gestionar y actualizar los datos.
Si se utiliza una base de datos aquí es donde se realizan las consultas, búsquedas, filtros y actualizaciones. View: este componente se encarga de mostrarle al usuario final las pantallas, ventanas, páginas y formularios; el resultado de una solicitud. Desde la perspectiva del programador este componente es el que se encarga del frontend ;
Controller: este componente se encarga de gestionar las instrucciones que se reciben, atenderlas y procesarlas. Por medio de él se comunican el modelo y la vista: solicitando los datos necesarios; manipulándolos para obtener los resultados; y entregándolos a la vista para que pueda mostrarlos. (García, 2017)
26
Diagrama de actividades
BPEL Diagrama Actividad
r epre sent ant e
Solicit ud
Asignacion
Inicio
Pedir Listado Solcitudes
Obtener solicitudes disponible
Procesar Proce sar solici tud
Env Enviar iar solici tud Informacion Detallada
Oferta solicitud
procesar la ofert oferta a Aceptar presupuesto
SI
NO
Informacion rechazo oferta Re Registrar gistrar asignacion la ofert oferta a
Informacion Obtenida Aprobado Obtenida
registra el control de mantenimiento
Enviaro fert ferta a aceptada
Actualizar status Oferta
Actualizar la solicitud como atendido
Registrar en el sistema finalizada sistema mantenimiento
Fin
Ilustración 4 Diagrama de actividades actividades
27
Diagrama de secuencia Registro de asignación sd Diagrama Secuencia
Representante Empresa Frm Ofe rt a
Ge st or solicit ud
BD solicit ud
Ge st or Ofert a
Bd Ofe rt a
Ge st or Asignacion
Bd Asignacion
Listado Solicitudes()
ObtenerSolicitud(nombre)
RegistrarOferta(fechai,fechaf,precio)
GuardarOferta()
Aprobar Oferta()
GuardarAsignacion()
Registrar concluida Asignacion()
RegistrarFinalizado Mantenimient Mantenimiento() o()
Ilustración 5 Diagrama de secuencia secuencia
28
Diagrama físico classDomainModel
perfilpersona
*PK * * * * * *
perfil_permiso
«column»
bitacora
«column»
*PK perfilid: BIGINT *PK personaid:BIGINT
«column»
bitacoraid: BIGINT personaid: BIGINT fechahora: a: DATETIME accion:NVARCHAR(25) transaccion: NVARCHAR(50) detalle: NVARCHAR(2000) tipo: INT idimplicado: BIGINT
*PK perfilid: BIGINT *PK permisoid:BIGINT
«index»
+ +
«index»
IXFK_perfilpersona_perfil(BIGINT) IXFK_perfilpersona_persona(BIGINT)
+ +
«PK»
+
IXFK_perfil_permiso_perfil(BIGINT) IXFK_perfil_permiso_permiso(BIGINT) «PK»
PK_perfilpersona(BI GINT, BIGINT)
+
PK_perfil_permis o(BIGINT, BIGINT)
«index»
+
IXFK_bitacora_persona(BIGINT)
permiso
«PK»
+
PK_bitacora(BIGINT)
«column»
*PK permisoid:BIGINT * * * FK * * * * * * *
perfil «column»
*PK * * * * *
persona «column»
*PK * * * * * * * * * * * FK
funcionario «column»
*PK * * * * * * *
funcionarioid: BIGINT fechaingreso: DATE codigo:NVARCHAR(50) cargo: INT estado: INT usuariocreador: eador:BIGINT usuariomodificador: BIGINT fechacreacion: DATETIME fechamodificacion: DATETIME
«index»
+
IXFK_funcionario_persona(BIGINT)
personaid:BIGINT nombre: NVARCHAR(35) 35) apellido: NVARCHAR(50) 50) ci: NVARCHAR(15) correo:NVARCHAR(100) username:NVARCHAR(40) password:NVARCHAR(300) estado: INT sexo: INT tipousuario: INT telefono: NVARCHAR(20) celular: NVARCHAR(15) usuariocreador: BIGINT usuariomodificador: BIGINT fechacreacion: DATETIME fechamodificacion: DATETIME imagenid: BIGINT
«PK»
+
nombre:NVARCHAR(150) estado: INT descripcion: NVARCHAR(120) 120) permisopadreid: BIGINT pantalla:NVARCHAR(100) orden: INT iconomenu: NVARCHAR(35) usuariocreador: eador:BIGINT usuariomodificador: BIGINT fechacreacion: DATETIME fechamodificacion: DATETIME
«FK»
PK_perfil(BIGINT)
+
FK_permiso_permiso(BIGINT) «index»
+
IXFK_permiso_permiso(BIGINT) «PK»
+
PK_permiso(BIGINT)
ciudadano «column»
*pfKciudada noid: BIGINT * estado: INT «FK»
«PK»
+
perfilid: BIGINT nombre:NVARCHAR(80) tipo: INT estado: INT usuariocreador: BIGINT usuariomodificador: BIGINT fechacreacion: DATETIME fechamodificacion: DATETIME
«FK»
PK_funcionario(BIGINT) +
+
FK_persona_imagen(BIGINT)
+
+
IXFK_persona_imagen(BIGINT)
IXFK_ciudadano_persona(BIGINT) «PK»
«PK»
+
FK_ciudadano_persona(BIGINT) «index»
«index»
+
PK_ciudadano(BIGINT)
PK_persona(BIGINT)
imagen «column»
obra_imagen
*PK imagenid: BIGINT * filename:NVARCHAR(100) * src: NVARCHAR(50) * ancho: INT * alto: INT * estado: INT * usuariocreador:BIGINT * usuariomodificador: BIGINT * fechacreacion: DATETIME * fechamodificacion: DATETIME
«column»
*PK id: BIGINT * estado: INT * status: INT *FK obraid: BIGINT *FK imagenid: BIGINT * usuariocreador: eador: BIGINT * usuariomodificador: BIGINT * fechacreacion: DATETIME * fechamodificacion: DATETIME
solicitud_imagen «column»
*pfKsolicitudid: BIGINT *pfKimagenid:BIGINT «FK»
+
«PK»
+
PK_imagen(BIGINT)
+ +
FK_solicitud_imagen_imagen(BIGINT)
+
«FK»
FK_solicitud_imagen_solicitud_mantenimiento(BIGINT) «index»
FK_obra_imagen_imagen(BIGINT) FK_obra_imagen_obra(BIGINT)
+ +
«index»
IXFK_solicitud_imagen_imagen(BIGINT) IXFK_solicitud_imagen_solicitud_mantenimiento(BIGINT) «PK»
+ IXFK_obra_imagen_imagen(BIGINT) + IXFK_obra_imagen_obra(BIGINT)
+
PK_ solicitud_imag en(BIGINT, BIGINT)
«PK»
+
PK_obra_imagen(BIGINT)
obra «column»
municipio «column»
provincia «column»
*PK provinciaid:BIGINT * nombre: NVARCHAR(50) 50) * estado: INT
*PK * * *FK
municipioid: BIGINT nombre:NVARCHAR(50) lat: NVARCHAR(25) lng: NVARCHAR(25) estado: INT provinciaid:BIGINT
«FK» «PK»
+
+
PK_pronvicia(BIGINT)
FK_municipio_provincia(BIGINT) «index»
+
IXFK_municipio_provincia(BIGINT) «PK»
+
*PK * * * * * * *FK * *FK * *FK *FK *FK * *
gestion
obraid: BIGINT estado: INT usuariocreador:BIGINT usuariomodificador: BIGINT fechacreacion: DATETIME fechamodificacion: DATETIME u v :I N T lat: NVARCHAR(25) lng: NVARCHAR(25) direccion: NVARCHAR(200) municipioid: BIGINT fecha: DATE gestionid: BIGINT nombre:NVARCHAR(120) telefono: NVARCHAR(12) tipoobraid: BIGINT nivelid: BIGINT barrioid: BIGINT nro: INT distritomunicipal: INT
«column»
*PK * * * * * * * * * *
gestionid: BIGINT descripcion: NVARCHAR(20) fechainicio: DATE fechafinal: DATE mes:INT anio: INT estado: INT usuariocreador:BIGINT usuariomodificador: BIGINT fechacreacion: DATETIME fechamodificacion: DATETIME
solicitud_tipomantenimiento «column»
*pfKsolicitudid: BIGINT *pfKtipoma ntenimientoid: BIGINT * cantidad: INT * disponible: INT «FK»
+ +
+
FK_solicitud_tipomantenimiento_solicitud_mantenimiento(BIGINT) FK_solicitud_tipomantenimiento_tipomantenimiento(BIGINT) «index»
«PK»
+ +
PK_gestion(BIGINT)
IXFK_solicitud_tipomantenimiento_solicitud_mantenimiento(BIGINT) IXFK_solicitud_tipomantenimiento_tipomantenimiento(BIGINT) «PK»
solicitud_mantenimiento +
PK_s olicitud_tipomantenimi ento(BIGINT, BIGINT)
«column»
PK_municipio(BIGINT)
barrio
*PK *FK *FK * FK * * * * *
«FK»
+ + + + +
FK_obra_barrio(BIGINT) FK_obra_gestion(BIGINT) FK_obra_municipio(BIGINT) FK_obra_nivel(BIGINT) FK_obra_tipo_obra(BIGINT) «index»
«column»
*PK * * *
barrioid:BIGINT nombre:NVARCHAR(50) codigo:NVARCHAR(12) zona: INT estado: INT
IXFK_obra_barrio(BIGINT) IXFK_obra_gestion(BIGINT) IXFK_obra_municipio(BIGINT) IXFK_obra_nivel(BIGINT) IXFK_obra_tipo_obra(BIGINT)
tipomantenimiento «column»
*PK * * * * * *
«FK»
«PK»
+
«PK»
+
+ + + + +
solicitudid: BIGINT gestionid: BIGINT motivo: NVARCHAR(50) obraid: BIGINT status: u s: INT ciudadanoid: BIGINT fechacreacion: DATETIME fechamodificacion: DATETIME usuariocreador:BIGINT usuariomodificador: BIGINT estado: INT
+ + +
PK_obra(BIGINT)
PK_barrio(BIGINT)
FK_solicitud_mantenimiento_ciudadano(BIGINT) FK_solicitud_mantenimiento_gestion(BIGINT) FK_solicitud_mantenimiento_obra(BIGINT)
«PK»
«index»
+ + +
tipomantenimientoid: BIGINT nombre:NVARCHAR(150) estado: INT usuariocreador:BIGINT usuariomodificador: BIGINT fechacreacion: DATETIME fechamodificacion: DATETIME
+
IXFK_solicitud_mantenimiento_ciudadano(BIGINT) IXFK_solicitud_mantenimiento_gestion(BIGINT) IXFK_solicitud_mantenimiento_obra(BIGINT)
PK_tipomantenimiento(BIGINT)
«PK»
+
PK_solicitudmantenimiento(BIGINT)
nivel tipo_obra «column»
*PK nivelid: BIGINT * nombre:NVARCHAR(50) * estado: INTEGER
«column»
*PK tipoobraid: BIGINT * nombre:NVARCHAR(50) * estado: INT
«PK»
+
«PK»
PK_nivel(BIGINT) +
PK_tipo_obra(BIGINT) detalle_oferta oferta «column»
*PK * *FK * *FK * * * * * * *
asignacion «column»
*PK * * * * * *
asignacionid:BIGINT status: INT estado: INT usuariocreador: eador: BIGINT usuariomodificador: BIGINT fechacreacion: DATETIME fechamodificacion: DATETIME comentario: NVARCHAR(100)
ofertaid: BIGINT estado: INT empresaid: BIGINT comentario: NVARCHAR(100) preciototal: DOUBLE obs: NVARCHAR(120) solicitudid:BIGINT status: INT fechaprogramada:DATETIME usuariocreador:BIGINT usuariomodificador: BIGINT fechacreacion: DATETIME fechamodificacion: DATETIME fechafinalizada: DATETIME
«column»
*PK id: BIGINT *FK ofertaid: BIGINT *FK tipomantenimientoid: BIGINT cantidad: INT * precioactual: DOUBLE * obs: NVARCHAR(100) «FK»
+ +
FK_detalle_oferta_oferta(BIGINT) FK_detalle_oferta_tipomantenimiento(BIGINT) «index»
+ +
IXFK_detalle_oferta_oferta(BIGINT) IXFK_detalle_oferta_tipomantenimiento(BIGINT) «PK»
+
PK_asignacion(BIGINT)
«PK»
«PK»
+
PK_oferta(BIGINT)
«column»
*pfKasignacionid: BIGINT *pfKofertaid:BIGINT empresa
«FK»
+ +
FK_detalleasignacion_asignacion(BIGINT) FK_detalleasignacion_oferta(BIGINT) «index»
+ +
IXFK_detalleasignacion_asignacion(BIGINT) IXFK_detalleasignacion_oferta(BIGINT) «PK»
representante
+
PK_deta lleasigna cion(BIGINT, BIGINT)
«column»
*PK empresaid: BIGINT * nombre:NVARCHAR(100) * direccion: NVARCHAR(200) * correo:NVARCHAR(40) * estado: INT *FK representanteid:BIGINT * telefono: NVARCHAR(50) 50)
«column»
*pfKrepresentanteid: BIGINT * estado: INT «FK»
+
FK_representante_persona(BIGINT) «index»
+
IXFK_representante_persona(BIGINT) «PK»
+
PK_representante(BIGINT)
Ilustración 6 Diagrama Físico
«index»
+
«index»
+ IXFK_oferta_empresa(BIGINT) + IXFK_oferta_solicitud_mantenimiento(BIGINT) detalleasignacion
«FK»
+ IXFK_servicio_trabajo_empresa(BIGINT) + IXFK_servicio_trabajo_tipomantenimiento(BIGINT)
«FK»
+
serviciotrabajoid:BIGINT precio:DOUBLE tipomantenimientoid: BIGINT estado: INT empresaid: BIGINT
+ FK_servicio_trabajo_empresa(BIGINT) + FK_servicio_trabajo_tipomantenimiento(BIGINT)
PK_detalle_oferta(BIGINT)
+ FK_oferta_empresa(BIGINT) + FK_oferta_solicitud_mantenimiento(BIGINT)
«PK»
servicio_trabajo «column»
*PK * *FK * *FK
«FK»
+ +
FK_empresa_representante(BIGINT) «index»
IXFK_empresa_representante(BIGINT)
«PK»
+
PK_empresa(BIGINT)
PK_servicio_trabajo(BIGINT)
29
Modelo de implementación Modelo de componentes Gestión de asignación cmp Component Model
Gestor LOferta
Gestor LRepresetante Frm Asignacion
Capa Model
Gestor LSolicitud
FrmOferta
Gestor LEmpresa
Base de Datos Gestorr Presupuesto Gesto
Ilustración 7 Modelo de compone componente nte
30
Modelo de despliegue deployment Deployment Model
Aplicacion Web Aplicacion Negocio
Gestor Solicitud
FrmOferta
Gestor control de mantenimiento
gestor Tipo
Ubuntu 18
mantenimiento
Apache
Servidor Datos
SO Ubuntu Server 18.04
Ilustración 8 Diagrama de despliegue despliegue
Base de datos Mysql
capa modelo
Modelo de prueba 31
Prueba funcionalidad En las pruebas de funcionalidad se buscó verificar si el funcionamiento de cada uno de los métodos, procedimientos y estados del sistema, era correcto y si se obtenían los resultados esperados. Los escenarios de las pruebas están basados en posibles casos de uso y en la mayor cantidad de acciones posibles que un usuario potencial pudiera realizar.
Caso 1: en el formulario de oferta es validado el formato de la fecha programada
Caso 2: en el formulario de solicitud es validado solo numero la cantidad de tipo mantenimiento y no acepta nulo
Backup de base de datos Se realizará una copia de seguridad completa “Backup Full” para mantener un modelo de
recuperación a la importancia de los datos de los datos de la H.A.M. 32
El Backup estará guardar en un disco duro fuera de la l a empresa, en un lugar seguro para prevenir la perdida de la información en caso de desastres naturales, incendio u otros tipos de riegos. Las programaciones de los Backup estarán programados para guardarse semanalmente en las horas donde los encargados y trabajadores no estén ocupando el sistema.
33
Diseño de reportes
Implementación de requerimientos Formulario login
34
Formulario Listado de solicitudes
Formulario nueva solicitud
35
Mensaje del formulario
36
Conclusión Luego de haber realizado la planeación, diseño, implementación de los requerimientos funcionales del sistema, se afirma que los objetivos planteados al inicio del estudio del proyecto fueron alcanzados: Se identificaron los procesos de negocio para el sistema de gestión de información sobre costos
de mantenimientos de los módulos educativos construidos por la l a H.A.M. de Santa Cruz. Se realizó el modelo de requisitos, las capturas de requisitos funcionales y no funcionales Se priorizaron losasignación casos de uso y se seleccionaron los siguientes: gestión de solicitudes, gestión de oferta, gestión Se construyó el modelo de análisis dando como resultado las especificaciones. de los casos de uso que previamente se seleccionaron. Se realizaron el modelo de dominio del sistema. Se desarrollaron los casos de uso priorizados. Se realizaron pruebas del Sistema de gestión de información sobre costos de mantenimientos de los módulos educativos construidos por la H.A.M. de Santa Cruz.
Recomendación
Las recomendaciones para el sistema de gestión de información sobre costos de mantenimientos de los módulos educativos construidos por la H.A.M. de Santa Cruz., se describen a continuación para que sirvan a futuras modificaciones del software.
Recomendaciones Generales. El software presenta toda la documentación necesaria sobre el negocio, requerimientos, el esquema de la base de datos e implementación de casos de uso permitiendo la implementación de los demás modelos y funcionalidades. Se recomienda hacer una copia de seguridad “Backup” semanal para evitar pérdidas de información de datos.
Recomendaciones para el usuario Se recomienda al usuario participar en la elaboración del “Manual de usuario” para que el
manual este descrito usando su misma terminología. ter minología. Se puede planificar una capacitación previa con los casos de uso implementados, i mplementados, para familiarizar a los usuarios con la nueva forma de trabajo en el nuevo sistema.
37
Bibliografía
Castaño, A. D. (1993). Concepción y Diseño de Bases de Datos: Del Modelo E/R al Modelo. RA-MA S.A. García, M. (27 de 10 de 2017). codingornot . Obtenido de https://codingornot.com/mvc-modelovista-controlador-que-es-y-para-que-sirve Ramez Elmasri, S. B. (2007). Fundamentos de sistema de Base de datos. datos. Madrid: Pearson Adisson Wesley. schmuller, J. (s.f.). Aprendie Aprendiendo ndo UML en 24 horas. horas. Mexico: Pearson Education Latinoamerica. Sommerville, I. (2005). Ingenieria de de Software. Madrid: Pearson Adisson Wesley.
ANEXOS Software SuperPutty Para tener una conexión SSH con el servidor Ubuntu Server 18.04
38
Aplicación web cliente web min para acceder configuración con mayor facilidad alternativa a la configuración por comandos de la terminal algunas funcionalidades son: FTP, DNS, Backup de archivos, base de datos y otras.
39
CASO DE ESTUDIO DE EXAMEN DE GRADO FACULTAD DE CIENCIA Y TECNOLOGÍA CARRERA AREA
CODIGO
Ingeniería de Sistemas Base de Datos y Sistemas de Información
EG-S-BD-06-20
Período :
2 /2020
CASO #6
SISTEMA DE GESTIÓN DE INFORMACIÓN SOBRE COSTOS DE MANTENIMIENTOS DE LOS MÓDULOS EDUCATIVOS CONSTRUIDOS POR LA H.A.M. DE SANTA CRUZ. I.
SITUACIÓN PROBLEMÁTICA En los últimos años ha Honorable Alcadia Municipal de nuestra ciudad ha invertido bastante en la construccion de nuevas infraestructura educativa comumente llamadas módulos educativos. En Santa Cruz se han construidos más de 400 nuevos módulos y se han refaccionado más de 200 infraestructuras antiguas en estos últimos años, pero, con el pasar del tiempo la unidad de presupuesto para mantenimientos de la H.A.M ha perdido el control del orden de los mantenimientos hechos a los módulos educativos. Una infraestructura o módulo educativo inicialmente es entregada en perfectas condiciones para su uso, con el pasar del tiempo la unidad de mantenimiento de la H.AM ha comenzado a recibir solicitudes de mantenimiento desde las direcciones escolares de las diferentes unidades educativas.enEstas solicitudes llegan a través de cartas en papel impreso y son archivadas folders apilados por N° de UV. Esta organización manual (folders) ha ocasionado que ciertas solicitudes se hallen en folders diferentes diferentes al de la UV que que le corresponde.
La H.A.M: ha clasificado los diferentes tipos de mantenimientos que deben correr económicamente por su cuenta: Pintado general de paredes, Pintado de verjas, Pintado de canchas deportivas, Tapado de goteras, Barnizados de puertas y ventanas, Reposición de vidrios rotos de ventanas, Arreglos de problemas de electricidad, mantenimientos de la jardinería, Corredores públicos, etc. La unidad de presupuesto para mantenimiento de la H .A.M desea atender las solicitudes de los diferentes módulos por orden de llegada. Además, precisa registrar todos los gastos que se han hecho en el mantenimiento de una determinada solicitud. Por otro lado, se necesita conocer el total de gastos por cada proyecto de mantenimiento durante cada gestión.
40
También se precisa reportes de gastos totales por cada tipo de mantenimiento (Pintado, Barnizado…) por año.
II II..
CO CONS NSID IDER ERAC ACIO IONE NES SD DE ED DIS ISEÑ EÑO OD DE EL LA AB BD D En base a la descripción de la sección anterior use sentido común para generar las consideraciones de diseño de la base de datos sin distorsionarse la esencia del problema Recuerde que la base de datos debe estar modelada con diagrama de clases orientado a objetos respetando l multiplicidad de las respectivas asociaciones entre las clases. ROLES Administrativo: Encargado de operar el subsistema de mantenimiento de unidades educativas
III.
IV.
V.
CASOS D DE E US USO B BA ASICOS Debe generar los casos de uso pertinentes a la solución del sistema requerido. REPORListado TES de solicitudes de mantenimiento pendientes (no se han empezado
todavía) Listado de mantenimiento en proceso Costo total de mantenimiento por unidad educativa ordenado por la UV donde está construido el modulo Consolidado de costo por tipo de mantenimiento terminado por año. CONS CONSID IDER ERAC ACIO IONE NES S DE SE SEGU GURI RIDA DAD D La aplicación deberá tener acceso por niveles para los diferentes roles, caducidad de contraseña y una bitácora de las l as operaciones hechas sobre las tablas de la base de datos.
VI VI..
VII II.. ARTEF EFA ACTO TOS S SOL OLIICITA TAD DOS a) Mo Mode delo lo de Re Requ quis isito itoss
Listado de de requerimientos funcionales y no funcionales
b) Mo Mode delo lo de An Anál ális isis is
Modelo de datos
Especificación de requerimientos requerimientos funcionales del softw software are (SRS)
c) Mo Mod del eloo d dee D Dis iseñ eñoo
Arquitectura de la aplicación,
Diseño de la base de datos: Lógico y físico
View more...
Comments
