Sistema de Reportes (ENTREGA 3)

UNIVERSIDAD DEL BÍO-BÍO
FACULTAD DE CIENCIAS EMPRESARIALES

ESCUELA DE INGENIERÍA CIVIL EN INFORMÁTICA
__________________________________________________________________
DESARROLLO DE SISTEMA WEB PARA REPORTES EN

LÍNEA DEL COLEGIO PARTICULAR ANDRES BELLO DE
CHIGUAYANTE.
FORMULACIÓN DE PROYECTO Nº3
Integrantes:
Sebastián Fuentealba
Francisca Martínez
Rodrigo Oliva Troncoso
Jordy Romero
Docente:
Dr. Pedro G. Campos
Concepción, Diciembre 2017
RESUMEN EJECUTIVO 4
FORMULACIÓN 6
DESCRIPCIÓN DE PROBLEMAS GENERALES 6
PROPUESTA GENERAL 6
METODOLOGÍA DE TRABAJO 8
OBJETIVO GENERAL 8
OBJETIVOS ESPECÍFICOS 8
AMBIENTE DE INGENIERÍA DE SOFTWARE 9
ESTUDIO DE FACTIBILIDAD 13
FACTIBILIDAD TÉCNICA 13
RECURSOS DEL SOFTWARE 13
RECURSOS DEL HARDWARE 14
ESPECIFICACIONES DEL SERVIDOR: 15
HARDWARE MÍNIMO REQUERIDO PARA EL DESARROLLO DEL SISTEMA:
15
RECURSOS HUMANOS 15
FACTIBILIDAD OPERATIVA 18
EFECTOS NEGATIVOS: 19
CONCLUSIÓN SEGÚN FACTIBILIDAD OPERATIVA: 19
FACTIBILIDAD ECONÓMICA 19
TABLA DE COSTOS EN EL DESARROLLO 20
TABLA DE BENEFICIOS MENSUALES. 22
REQUISITOS DEL PROYECTO 25

TABLA DE REQUISITOS FUNCIONALES 25
TABLA DE REQUISITOS NO FUNCIONALES 28
DEFINICION Y DESCRIPCION DE CASOS DE USO 31
MODELAMIENTO DE DATOS 49
MODELO FÍSICO DE DATO 51
MÓDULOS DEL SISTEMA. 70

MÓDULOS DE GESTIÓN DE PERSONAL. 70
MÓDULO GESTIÓN DE HISTORIAL 74
MÓDULO GESTIÓN DE REPORTES 75
MÓDULO GESTIÓN DE USUARIOS 77
MATRIZ DE TRAZABILIDAD 81
BUSINESS PROCESS MODEL AND NOTATION (BPMN) 83
CONCLUSIÓN 85
WORKS CITED 86
1. RESUMEN EJECUTIVO
El presente proyecto está dirigido al departamento de informática del Colegio
Andrés Bello de la comuna de Chiguayante, como una futura propuesta para
mejorar su proceso de registro de reportes, tal como un tipo de bitácora diaria
por los funcionarios del departamento.
Las etapas de un reporte son variadas, éste nace a partir de una necesidad
de algún funcionario del establecimiento, luego él pide ayuda al área de
informática y se designa a algún miembro del departamento para que vaya en
apoyo a esa necesidad. Luego de solucionar por completo, o una parte de
ese problema vendría la etapa de registro del reporte donde se clasifican a
partir de la tarea realizada y del servicio prestado. El departamento,
actualmente cuenta con una gran cantidad de reportes registrados y
compartidos en una planilla excel dentro de Google Drive, organizados y
clasificados de acuerdo al tipo de reporte, donde algunos pueden ser:
Soporte & Sistemas, Gestión, Apoyo a usuarios, entre otros. Pero el grupo de
trabajo no cuenta con un sistema de comunicación efectiva y producente a la
actualidad, esto provoca que en ocasiones existan problemas al momento de
registrar reportes, o inclusive haya pérdida de información de las actividades
realizadas. Por lo que se hace necesario un sistema que centralice toda la
información y que a la vez permita una mayor organización al momento de
realizar nuevos registros.
2. INTRODUCCIÓN
Uno de los grandes desafíos de todas las instituciones, ha sido la búsqueda

de administrar eficientemente la información, la sostenibilidad o
mantenimiento y actualización de los datos. Comúnmente el mal manejo de
estos objetivos lleva a generar problemas de inconsistencia y errores en la
realización de reportes de los eventos realizados.
El Colegio Andrés Bello de Chiguayante se ha ganado el prestigio y

satisfacción de parte de la comunidad, con sus metodologías de enseñanza
únicas, una infraestructura implementada con todo lo necesario para llevar a
cabo las clases diarias, y siempre invirtiendo con nuevas tecnologías en
cuanto a servidores, softwares, e implementos de computación. Y esto se ve
reflejado en la cantidad de matrículas que tiene, ya que cuentan con
alrededor de 1700 alumnos distribuidos en enseñanza pre básica, básica y
media.
Se pretende trabajar en conjunto con el área informática de dicho

establecimiento, reuniéndose y realizado actividades para abordar de la
mejor forma posible una solución a la problemática actual de inconsistencias
en los registros de reportes por parte de los funcionarios. Tomando en cuenta
lo que significa realizar este servicio, se aseguran distintas estimaciones
tanto técnicas como reales, estimando tiempos y recursos para la
planificación de un buen desarrollo de software que mantenga satisfechos a
nuestros clientes.
Como bien sabemos los sistemas de información son un factor clave a la
hora de contar con una ventaja competitiva y diferenciadora según los
estudios de mercado modernos, por esta razón se prefiere utilizar esta
ventaja creando un sistema web diseñada bajo arquitectura Modelo-Vista-
Controlador, de la que se hablará más adelante.
La aplicación pretende entregar información relevante y fácil de obtener

mediante el sistema, para todos aquellos funcionarios del departamento
informático.
Los alcances de este proyecto pueden ayudar en gran medida en un futuro

de esta organización, puesto que servirán de base para algo más sofisticado
y con mejores recursos.
Este documento se estructurará desde lo más general, que serían los análisis
y estudios de factibilidad, analizando los riesgos y requisitos del proyecto,
hasta plasmar lo requerido por el usuario en casos de usos.
3. FORMULACIÓN
“Desarrollo de sistema web para reportes en línea del Colegio Particular
Andres Bello de Chiguayante”.
● Equipo y responsables del proyecto:
○ Sebastián Fuentealba
○ Francisca Martínez
○ Rodrigo Oliva
○ Jordy Romero
● Fecha de inicio: Lunes 28 Agosto 2017
● Fecha final aproximada: Lunes 11 de Diciembre 2017
3.1. DESCRIPCIÓN DE PROBLEMAS GENERALES

Actualmente el área de Soporte y Sistema en el departamento de informática
del Colegio Particular Andres Bello lleva sus reportes por medio de una
planilla compartida a la cual tienen acceso el personal correspondiente y las
jefaturas, quienes revisan la información para su adecuado manejo. El
problema con esta manera de trabajar es que la información es difícil de
comprender por la cantidad de reportes que se han generado y la duplicidad
de información (más de un empleado asisten el mismo problema y estos
generan cada uno un reporte).
Captura de Pantalla del Funcionamiento Actual (Planilla compartida por funcionarios)
3.2. PROPUESTA GENERAL

Debido a los problemas anteriormente mencionados se propone la
implementación de un sistema de reportes en línea, el cual permite registrar
la bitácora de los empleados de la oficina de Soporte y Sistemas de manera
ordenada y organizada, facilitando así el ingreso y la revisión de los datos,
ayudando a la toma de decisiones por parte de la jefatura del departamento
de informática.
Determinamos esta solución como la adecuada porque permite que los
Reportes ingresados por el usuario puedan ser visualizados de manera
ordenada y filtrada según lo requerido por el solicitante. No existirá duplicidad
en los Reportes porque se generará un sistema que diferencie cada uno de
estos mediante un código y se limitará el acceso de qué Usuario realice
cambios sobre este.
Los beneficios que nuestro Software otorgará será el correcto ingreso de
datos en el proceso de Registro de Reportes porque se eliminará el actual
problema de duplicidad en la Información, y además la efectividad en el
proceso de Visualización de Reportes, ambos beneficios aportan una
disminución sustancial en el tiempo requerido en el manejo de éstos.
ALCANCE DEL PROYECTO

Formular un sistema web de reportes en línea para los funcionarios del
establecimiento de forma automática y segura, evitando confusiones en los
detalles de la realización de reportes, mejorando los procesos administrativos
y operativos del Colegio Andrés Bello de Chiguayante.
El costo asociado se evaluará de acuerdo los recursos humanos y las

licencias de las herramientas de desarrollo, que en gran medida serán
basadas en software libre.
El sistema contará con un super usuario encargado de la administración del

sistema y la creación de nuevos usuarios, también permitirá el ingreso de los
empleados del establecimiento mediante un rut y una clave preestablecida
por el administrador del sistema, donde podrá hacer registro de las
actividades diarias.
Esta herramienta aportará, entre otros, beneficios con la optimización de la

información, facilitando el trabajo en equipo y aumentando la cohesión de
grupo. Se desarrollará en un plazo máximo de 1 semestre académico, según
las normas vigentes y el calendario académico 2017 de la Universidad del
Bío-Bío.
El Sistema permite la identificación de los distintos tipos de Usuarios del

Sistema (SuperUsuario-Usuario), junto con esto se diferenciará los permisos
que tendrá cada Usuario en las diversas tareas que permita realizar el
Sistema.
Las Tareas que el Sistema proveerá será Almacenar y Manejar (Crear,
Modificar, Eliminar y revisar) la información de los respectivos reportes que
se realicen.
El Sistema no Permite
● Adjuntar imágenes en los reportes

● Eliminar reportes si no cuenta con el permiso de usuario necesario.
● Acceso sin una coneccion a internet
● Acceso sin estar registrado en el Sistema
● Generar datos estadísticos de Reportes
● Ingresar un nuevo item de campo de llenado
● Personalización de la página de inicio (tema principal de la
web,Tamaño de Fuente,Colores)
● La instalación del Sistema en el escritorio (solo página web)
Todos los Reportes dispondrán de los mismos ítems:

● Código Reporte
● Descripción
● Fecha
● Grupo
● Estado
● Funcionario
● Email
● Tipo
● Categoría
● Recurso & Servicio
● Ubicación Responsable
Cada uno con sus respectivos campos de llenado.
4. METODOLOGÍA DE TRABAJO
4.1. OBJETIVO GENERAL

Desarrollar un sistema de información que permita automatizar registros de
reportes de las tareas realizadas por el departamento de informática del
Colegio Andrés Bello.
4.2. OBJETIVOS ESPECÍFICOS

O.E.1 Analizar el actual proceso de reportes y manejo de la información en el
departamento.
O.E.2 Investigar e Identificar las principales tareas que puedan ser

automatizadas en el sistema web.
O.E.3 Reducir costos de operación del sistema de reportes en línea con

respecto al actual sistema de planilla compartida.
O.E.4 Diseño, implementación de módulos de registro de reportes por parte
del departamento de Informática y así agilizar el actual proceso actual del
Colegio.
O.E.5 Realizar pruebas (testing) del software desarrollado en base a los

requerimientos tanto específicos como no-específicos.
5. AMBIENTE DE INGENIERÍA DE SOFTWARE
El desarrollo del Sistema web para los reportes en línea del Colegio Andrés
Bello, contempla la elaboración y entrega incremental del sistema a
desarrollar, permitiendo entregas de valor al usuario distribuidas en dos
Incrementos. Se plantea la construcción del sistema siguiendo estándares
para la elaboración de un código fuente homogéneo que facilite las tareas
futuras de mantenimiento y escalabilidad del sistema.
Para el desarrollo del sistema se utiliza una arquitectura de 3 Capas (Modelo
- Vista - Controlador). Utilizando el Framework Yii2.
A lo largo del desarrollo del proyecto utilizaremos diversas técnicas y

herramientas que nos facilitarán el proceso, tales como:
● Modelos de procesos de negocio, BPMN (Business Process Model

and Notation) utilizando la herramienta online Draw.io.
● Modelos de funcionalidad como casos de uso, además de diagramas
de casos de uso, para modelar estos últimos utilizaremos la
herramienta online Draw.io.
● Modelos de datos y modelos físicos de datos, como lo son los
Modelos Entidad-Relación y los Modelos Relacionales
respectivamente, utilizados para representar los datos a almacenar
para cada entidad de nuestro proyecto. En este caso utilizaremos la
herramienta Draw.io.
● Generamos los distintos mockups necesarios para comprender el
diseño general del sistema.
6. PLAN DE TRABAJO
La planificación de las tareas realizadas en este informe que contemplan la
documentación y un comienzo al desarrollo del proyecto, se representan a
través de la siguiente diagrama de Gantt.
● Breve descripción del Modelo Incremental:
Consiste en un desarrollo inicial de la arquitectura completa del sistema,

seguido de sucesivos incrementos funcionales. Cada incremento tiene su
propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni
sus interfaces. Una vez entregado un incremento, no se realizan cambios
sobre el mismo, sino únicamente corrección de errores. Dado que la
arquitectura completa se desarrolla en la etapa inicial, es necesario conocer
los requerimientos completos al comienzo del desarrollo.
● ¿Porque utilizar esta metodología?
Dentro de las ventajas que podemos ver al ocupar el Modelo Incremental

son:
- Genera software operativo de forma rápida y en etapas tempranas del
ciclo de vida del software.
- Es un modelo más flexible, por lo que se reduce el costo en el cambio

de alcance y requisitos.
- Es más fácil probar y depurar en una iteración más pequeña.
- Es más fácil gestionar riesgos.
- Cada iteración es un hito gestionado fácilmente.
Debido al escaso tiempo con el que se contará para llevar a cabo nuestro
proyecto y el hecho de ser un software a la medida en el que posiblemente
los requerimientos cambien en el transcurso del desarrollo del mismo, lo que
llevará a la necesidad de mantener una comunicación continua con el cliente,
es que hemos decidido trabajar con la metodología de desarrollo incremental
iterativo para la implementación del Sistema web para reportes en línea del
Colegio Particular Andres Bello de Chiguayante.
● Esquema de Metodología de desarrollo según Incrementos
Nota: El proyecto a desarrollar cuenta de 2 incrementos funcionales para el

cliente como se puede apreciar en la imagen, siendo el último la entrega final
del proyecto de acuerdo a los requisitos solicitado por el cliente.
● Carta Gantt (Desarrollo de Proyecto)
7. ESTUDIO DE FACTIBILIDAD
7.1. FACTIBILIDAD TÉCNICA

Este estudio se evalúa si es que se cuenta con la tecnología y recursos
tecnológicos necesarios, tanto de software como de hardware, para poder
desarrollar el sistema. Además, se evalúa la capacidad técnica de los
participantes del proyecto para llevar a cabo el desarrollo correcto del
sistema.
7.1.1. RECURSOS DEL SOFTWARE

El software que se utilizará en la realización del proyecto son los
siguientes:
Software Licencia Descripción
Windows 7 Microsoft Sistema Operativo utilizado como

CLUF plataforma base para interactuar
con las herramientas de software.
Wampserver GNU General Conjunto de herramientas de

Public software para trabajar desde un
License servidor de aplicaciones local.
PostgreSQL PostgreSQL Sistema de gestión de base de

9.3 license datos relacional orientado a
objetos, para almacenar los datos
de forma segura.
Yii2 Licencia BSD Framework PHP de código abierto

utilizado para crear aplicaciones
web de alto rendimiento.
Sublime text 3 Software Editor de texto sofisticado para

Propietario código de programación en
múltiples lenguajes.
Ganttproject GNU General Aplicación multiplataforma para la

Public programación y gestión de
License proyectos, mediante diagramas
Gantt.
Github GNU General Software de control de versiones

Public pensado en la eficiencia y
License v2 confiabilidad del mantenimiento de
versiones en un repositorio remoto.
Composer MIT license Gestor de paquetes PHP a nivel de

aplicación, que gestiona las
dependencias del software y las
librerìas necesarias.
Enterprise Software Herramienta de modelado de

Architect Propietario sistemas utilizado para la creación
de modelos UML, Modelo Entidad
Relación y Modelo Relacional.
Google Drive EULA Servicio de alojamiento de archivos

en la nube, utilizado para compartir
documentación y colaborar en
ellas.
Microsoft Software Herramienta para la elaboración de

office 360 Propietario informes y documentación.
FilleZilla Licencia Cliente FTP multiplataforma para

Pública trabajar con el servidor.
General de
GNU
PuTTY Licencia MIT Cliente SSH y Telnet para el

manejo del servidor.
SoapUI Software Herramienta para la realización de
Propietario pruebas al sistema
Nota: Se debe considerar las licencias de pago son proporcionadas por la

Universidad del Bío-Bío, principalmente los software que se encuentran
distribuidos en la Facultad de Ciencias Empresariales y los laboratorios de
especialidad para el libre uso de los estudiantes.
7.1.2. RECURSOS DEL HARDWARE

Para que el proyecto pueda realizarse de forma correcta, se debe contar con
un servidor de datos que permita almacenar todo el sistema a implementar,
además del uso de ordenadores, en este caso, cada integrante del grupo
cuenta con su propio equipo portátil (notebook) con las características
mínimas requeridas para la elaboración exitosa del proyecto y poder
desempeñar plenamente su rol en el equipo de trabajo. Además, siempre se
cuenta con los laboratorios de computación de la universidad.
El servidor ha sido proporcionado previamente por el docente de la

asignatura junto con el encargado de los laboratorios de especialidad Sr.
Marco Iturra Mella, ambos docentes pertenecen al Departamento de
Sistemas de Información de la Universidad del Bío-Bío.
ESPECIFICACIONES DEL SERVIDOR:
- Procesador Intel Xeon Quad core E5504

- 2 Discos duros de 450GB
- 8 GB de RAM
HARDWARE MÍNIMO REQUERIDO PARA EL DESARROLLO DEL

SISTEMA:
- Procesador Intel core 2 duo 1.8 GHZ

- Memoria RAM 1 GB
- Disco duro 250 GB
- Tarjeta de Red
- Tarjeta de video 256 MB
Se debe tener en consideración que se cuenta con el software necesario para

la elaboración del proyecto que cubrirá las etapas de análisis del sistema,
diseño del sistema, programación y pruebas, también con las herramientas
que facilitarán el desarrollo, gestión y mantención de versiones. En su
mayoría las licencias de dichos programas son de uso libre o versiones de
evaluación gratuitas, en cambio los softwares de pago son proporcionados
por la Universidad del Bío-Bío. Cada uno de los integrantes cuenta con el
hardware mínimo requerido para el desarrollo del sistema, además el servidor
proporcionado satisface plenamente el objetivo de alojar la aplicación. Se
puede concluir que dado lo anterior el proyecto es factible técnicamente.
7.2. RECURSOS HUMANOS

En la elaboración de este proyecto se necesitan lo siguientes roles:
- Jefe de proyecto
- Analista
- Diseñador
- Programador
- Tester
Nuestro grupo de trabajo cuenta con los conocimientos necesarios para

afrontar cada uno de los roles que se necesitan para el desarrollo del
proyecto, esto por los conocimientos adquiridos por cada uno de los
integrantes del grupo de trabajo en la carrera Ingeniería Civil en Informática,
al encontrarse cada integrante en sus últimos años de carrera. Cada uno de
los integrantes del grupo aportará activamente en cada uno de los roles del
proyecto.
Podemos concluir entonces, que, desde un punto de vista técnico, es factible
la realización del software ya que se cuentan con todas las tecnologías
necesarias para desarrollar el proyecto de manera correcta, además, se
cuenta con el personal adecuado para dirigir, analizar, diseñar, programar y
realizar las pruebas de testeo necesarias.
Nota: Se puede obtener las horas estimadas en el desarrollo del proyecto,
según calendario universitario y de acuerdo a la asignatura, se llega a la
conclusión que dicho proyecto tendrá un tiempo de desarrollo
correspondiente a 303 horas entre los 5 integrantes del grupo de trabajo.
7.3. FACTIBILIDAD OPERATIVA

La Factibilidad de sistemas Operativa, tiene como objetivo comprobar que la
empresa u organización será capaz de darle uso al sistema, que cuenta con
el personal capacitado para hacerlo o tiene los recursos humanos necesarios
para mantener el sistema.
El software será lo más intuitivo posible, de fácil manejo y la forma de
ingresar los datos será lo más similar posible a como se hacía con el sistema
anterior, además se debe tener en cuenta que los usuarios tienen
conocimientos informáticos, existen muy pocos efectos negativos que
aminore una buena experiencia a los usuarios del sistema. Por el contrario se
espera una serie de sucesos positivos tras la implementación del sistema, los
que se detallaran a continuación.
● El tiempo de aprendizaje para el uso del SW será el mínimo.

(36 hrs de inducción)
● Se espera que la resistencia al cambio sea mínima. (40 horas
correspondientes a 1 semana laboral de acuerdo a lo
consultado a los usuarios)
● Los datos serán almacenados en una base de datos lo cual
permitirá un mejor orden y una mayor accesibilidad. (reportes
estarán almacenados en servidor web)
● Se generan reportes diarios de las actividades registradas en el
SW lo que permitirá a la jefatura una mejor toma de decisiones.
EFECTOS NEGATIVOS:
● La información obtenida por la plantilla excel compartida
(Sistema anterior) no será guardada en la base de datos, por
ende éstos datos eventualmente se perderán.
● Requiere una inversión inicial por parte del Colegio.
CONCLUSIÓN SEGÚN FACTIBILIDAD OPERATIVA:

Desde el punto de vista operativo y por lo acordado por el Colegio Andrés
Bello es completamente factible y totalmente favorable para los usuarios
del sistema la implementación de nuestro proyecto.
7.4. FACTIBILIDAD ECONÓMICA

En el estudio de la factibilidad económica, se han considerado los costos del
proyecto en torno al prototipo actual. A continuación, se detallaran los costos
que se deberán asumir en términos de pesos chilenos (CLP).
● ANÁLISIS DE LA REMUNERACIÓN DE LOS RECURSOS
HUMANOS.
Este análisis es necesario expresar la hora/Hombre en UF (Unidad de

Fomento). además de asumir que el sueldo mensual de mercado para
un Developer Junior corresponde a $600.000.- pesos chilenos (CLP)
de acuerdo a la ubicación geográfica y empleabilidad e ingresos
obtenidos del sitio web Mi Futuro (www.mifuturo.cl).
Como la cantidad de horas de trabajo mensual corresponde a 180

horas y los honorarios detallados anteriormente ($600.000 CLP), el
valor de Hora / Hombre estaría dado de la siguiente forma:
$600.000 (CLP) / 180 Horas = $3.334 pesos chilenos

(Valor de Hora / Hombre).
Actualmente el valor de la UF (Consultado el 04/10/2017) se encuentra

en $26.657 pesos chilenos (CLP), por lo cual el valor de Hora /
Hombre expresado en Unidad de Fomento corresponde a 0.13 UF
(Reajustado).
Se puede concluir con esto y el total de horas estimadas en la etapa

de Recursos Humanos, donde se obtuvo como resultado 303 horas en
el desarrollo del proyecto, el costo total de los Recursos Humanos
estaría dado por:
303 Horas x 0.13 UF (Hora / Hombre) = 39.5 UF => $1.066.280 Pesos

Chilenos.
● TABLA DE COSTOS EN EL DESARROLLO
Detalle valor
Recursos Remuneración de los 5 integrantes del $1.066.280

Humanos grupo de trabajo.
Google Drive Se cuenta con el proporcionado por la $0

universidad a cada alumno.
Microsoft Office Herramienta para la elaboración de $42.999

360 informes y documentación.
Windows 7 Sistema Operativo de cada integrante. $0
Wampserver Servidor de aplicaciones local. $0

Gratuito.
PostgreSQL 9.3 Sistema de gestión de base de datos. $0

Gratuito.
Yii2 Framework PHP. Gratuito. $0
Sublime text 3 Editor de texto sofisticado. Versión $0

gratuita de prueba.
Ganttproject Modelador de diagramas Gantt. $0

Gratuito.
Github Controlador de versiones. Versión $0

gratuita.
Composer Gestor de paquetes PHP. Gratuito. $0
Enterprise Modelado del sistema en UML, MER y $0

Architect MR. Disponible en los laboratorios de
la universidad.
FilleZilla Cliente FTP multiplataforma. Gratuito $0
PuTTY Cliente SSH. Gratuito $0
SoapUI Herramienta de testing. Código $0

abierto, Gratuito.
Total $1.109.279
Nota: El hardware necesario para la realización del proyecto

(terminales) no se incluye, debido a que, corresponden a los equipos
personales (notebooks) de cada uno de los integrantes del grupo.
El costo del servidor no se incluye, ya que, es proporcionado
gratuitamente por el Departamento de Sistema de Información de la
Facultad de Ciencias Empresariales Universidad del Bío-Bío.
● BENEFICIOS
Considerando el esfuerzo mayor y el tiempo empleado en generar el
proceso de registro de actividades, el tiempo del trabajador encargado
del actual sistema se reducirá a la mitad, de un total de 8 horas diarias
pasará a realizar dicha actividad en 4 horas. Será detallado en la
siguiente tabla:
Nota: La estimación será mensual, donde un trabajador normal tiene

180 horas que cumplir en 20 días hábiles y con un sueldo de
$430.200, correspondiente a $2390 (CLP) pesos de horas hombre,
podemos obtener una estimación en los beneficios del sistema para el
colegio.
● TABLA DE BENEFICIOS MENSUALES.
Beneficios Detalle Total

Estimación
mensual
Ahorro en tiempo del 2 horas $95.600

encargado de la diarias,
inscripción de 40 horas
reportes. mensuales.
Ahorro en tiempo en 1 Horas $47.800

revisar o evaluar los diarias,
reportes. 20 horas
mensuales.
Ahorro en tiempo por 1 Horas $47.800

problemas generados diarias,
en la inscripción del 20 horas
reporte. mensuales.
Ahorro en insumos de Libro de $8.400

oficinas usados en la reportes,
inscripción, revisión Hojas,
detallada y corrección lápices.
de los reportes.
Total $199.600
El valor total que acabamos de calcular en la tabla anterior

corresponde al beneficio tangible mensual, pero si sabemos que el
costo del proyecto fue de $1.109.279 y que mensualmente traería
beneficios de $199.600, se puede inferir mediante el cálculo de (costo
proyecto / beneficio mensual) que la inversión se puede recuperar en 5
meses y medio, una vez que esté funcionando completamente el
sistema.
Beneficio por año: $199.600 * 12 meses = $2.595.200

Costo de desarrollo: $1.109.279
Si calculamos el beneficio de funcionamiento del sistema durante el

primer año, menos el costo del proyecto, el beneficio sería de
$1.485.921. Este resultado, desde el punto de vista económico es
completamente factible de acuerdo a la inversión inicial que el
Colegio Andrés Bello nos propuso.
PROYECCIÓN EN EL TIEMPO
Para hacer una observación tangible en cuanto a los costos esperados
del proyecto realizamos una proyección de costos del proyecto en el
tiempo mediante la fórmula:
Valor Final=Valor Actual(1+i)n
Donde:
● Valor Actual (costo del proyecto)= $1.109.279
● i =2.24% Inflación media por 2017 de Chile
● n =5 años.
Un plazo de 5 años se propone a modo de referencia para obtener una
muestra del valor($) aproximado de desarrollo asociado a la inflación
actual de nuestro país.
La siguiente tabla nos muestra los resultados obtenidos en este

estudio:
Año Costos del proyecto($)
2017 1.109.279
2018 1.159.531,291
2019 1.185.504,792
2020 1.212.060,099
2021 1.239.210,246
En base a los valores registrados y realizando una diferencia entre

estos nos da como resultado un promedio de $25.986,25 que
corresponde al aumento anual promedio de los costos.
Representación gráfica:
Lo que en conclusión conjunta con el cliente significa que el aumento

en los costos será bajo y acorde a la inflación (aproximada) de nuestro
país en un periodo de 5 años.
El costo del desarrollo del sistema actual
Es aproximadamente de $25.000 (pesos chilenos) lo que corresponde

a una jornada laboral de 8 horas hombre, cabe recordar que el actual
sistema es una plantilla excel que no cumple con las expectativas de
nuestro Cliente puesto que no respalda la información de manera
segura, no tiene las facilidades de búsqueda de Reportes,no provee
un sistema de acceso limitado y seguro de usuarios del sistema.
8. REQUISITOS DEL PROYECTO
Esta sección contiene los requisitos a un nivel de detalle suficiente como para
permitir a los diseñadores diseñar un sistema que satisfaga estos requisitos,
y que permita al equipo de pruebas planificar y realizar las pruebas que
demuestren si el sistema satisface, o no, los requisitos. Todo requisito aquí
especificado describe comportamientos externos del sistema, perceptibles
por parte de los usuarios, operadores y otros sistemas.
8.1. TABLA DE REQUISITOS FUNCIONALES
RF REQUISITO FUNCIONAL ESPECIFICACIÓN
RF1 El sistema debe permitir RF 1.1 Al ingresar al login

identificar a los distintos principal con el rut y contraseña,
usuarios del sistema. el sistema verificará si el usuario
corresponde al registro de
usuarios en la Base de datos.
RF 1.2 Si el usuario corresponde

al registro de la base de datos
estará habilitado para realizar un
reporte en el sistema.
RF 1.3 Si el usuario no tiene

cuenta creada al la plataforma
web, se enviará un mensaje de
alerta indicando que no tiene
permisos para acceder al
sistema.
RF2 El sistema debe diferenciar los RF 2.1 Al ingresar como usuario

permisos para los diferentes registrado al sistema web, se
tipos de usuarios verificará los distintos beneficios
de cada usuario por medio de los
privilegios que tenga en la base
de datos.
RF 2.2 Si el usuario corresponde

a un “Superusuario” (mayor
privilegios en el sistema), podrá
gestionar a los usuarios y al
personal para que puedan
acceder al sistema web, y todos
los permisos de un “usuario
normal”.
RF 2.3 En caso contrario si el
usuario corresponda un un
“usuario normal” (menor
privilegios en el sistema), solo
podrá gestionar reportes e
Historial en el sistema web,
además de poder enviar correo
de aviso al supervisor del
sistema.
RF3 El sistema debe permitir RF 3.1 Cuando se realiza un

almacenar y manejar (Crear, determinado reporte, el sistema
Modificar, Eliminar y revisar) la almacenará dicha información en
información de los respectivos todos los campos solicitados al
reportes que se realicen. momento del llenado de la
planilla web.
RF 3.2 Esta informacion será

almacenada en la
correspondiente base de datos
que tendrá el respaldo de todos
los reportes realizados.
RF 3.3 Si el reporte realizado no

fue llenado con éxito no será
almacenada dicha información en
la base de datos.
RF3.4 el sistema permitirá revisar

(sólo permiso de ver) los reportes
ya creados.
RF3.5 Podrán ser modificados

los reportes sólo por la persona
que los creó y/o un
“superusuario”.
RF3.6 El sistema debe permitir

eliminar reportes realizados por
cualquier usuario a todo quien
tenga permiso de “superusuario”
RF3.7 Al momento de realizar el

reporte el sistema debe permitir
dar un aviso al funcionario
atendido del estado de su
solicitud (reporte).
RF4 Gestión de cuentas de RF 4.1 El sistema debe permitir
usuarios(ingresar, modificar, ingresar nuevos usuarios al
eliminar y buscar). sistema con sus respectivos
permisos de acceso.
RF 4.2 El sistema debe permitir

cambiar tanto los datos
(contraseña y nombre de usuario)
como los permisos del usuario.
RF 4.3 El sistema debe ser capaz

de eliminar cuentas de usuarios
en caso de que se desvinculen
del establecimiento o del
departamento.

de Buscar cuentas de usuarios
dentro de los registros de la base
de datos.
RF5 Gestión de Historial (ingresar, RF 5.1 El sistema debe permitir

modificar, eliminar y buscar). ingresar nuevos Historiales a los
registros de la base de datos con
su respectivo estado y
descripción de ser necesario.

modificar los datos del historial,
tanto como la descripción como
el estado definido anteriormente.

de eliminar historiales desde los
registros de la base de datos.

de Buscar historiales dentro de
los registros de la base de datos.
RF6 Gestión de cuentas de RF 6.1 El sistema debe permitir

Personal(ingresar, modificar, el ingreso del nuevo personal al
eliminar y buscar). sistema con sus respectivos
datos personales y cargo en la
organización.

cambiar tanto los datos
personales como el cargo del
personal en el colegio.

de eliminar a un personal en caso
de que se desvinculen del
establecimiento o del
departamento.

de Buscar los registros del
personal dentro de la base de
datos.
8.2. TABLA DE REQUISITOS NO FUNCIONALES
RNF Requisitos No Funcionales Especificación
RNF1 El sistema debe ser RNF 1.1 El sistema debe

implementado en forma de desarrollarse en PHP v(5.6),
plataforma web. trabajará con el gestor de bases de
(Requerimiento del datos PostgreSQL.
Producto)
RNF2 El sistema debe brindar RNF 2.1 El sistema debe presentar

facilidad de uso. una plataforma intuitiva y amigable
(Requerimiento de para el usuario (debe presentar
Usabilidad) tamaño de fuente, imagenes, logo
etc, en un tamaño estándar donde
todos puedan leer y ver sin
problemas).
RNF 2.2 El tiempo de aprendizaje

de uso del sistema no debe superar
las 3 horas por un usuario promedio
(con conocimientos básico de uso
de computadores).
RNF 2.3 La tasa de errores

cometidos por el usuario deberá ser
menor del 1% de las transacciones
totales ejecutadas en el sistema.
RNF 2.4 El sistema deberá

proporcionar mensajes de error que
sean informativos y orientados al
usuario final.
RNF3 Disponibilidad del sistema RNF 3.1 El sistema debe tener una
(Requerimiento del disponibilidad del 99,99% de las
Producto,Eficiencia, veces en que un usuario intente
Rapidez, etc) acceder.
RNF 3.2 El tiempo para iniciar o

reiniciar el sistema no podrá ser
mayor a 5 minutos.
RNF 3.3 La tasa de tiempos de falla

del sistema no podrá ser mayor al
0,5% del tiempo de operación total.
RNF 3.4 El promedio de duración

de fallas no podrá ser mayor a 15
minutos.
RNF 3.5 La probabilidad de falla del

Sistema no podrá ser mayor a 0,05.
RNF4 El sistema debe trabajar RNF 4.1 Estas ventanas serán

con ventanas emergentes programadas por medio de
de validación de acciones. JavaScript.
(Requerimiento de
usabilidad) RNF 4.2 Serán utilizadas al
momento de guardar, modificar o
eliminar datos del sistema.
RNF5 El sistema debe permitir RNF 5.1 El sistema debe ser capaz
Eficiencia al momento de de procesar N transacciones por
procesar información. segundo. Esto se medirá por medio
(Requerimiento del de la herramienta SoapUI aplicada
producto, eficiencia) al software Testing de Servicios
web.
RNF 5.2 Toda funcionalidad del

sistema y transacción de negocio
debe responder al usuario en
menos de 5 segundos.
RNF 5.3 El sistema debe ser capaz

de operar adecuadamente con
hasta 300 usuarios con sesiones
concurrentes.
RNF 5.4 Los datos modificados en

la base de datos deben ser
actualizados para todos los usuarios
que acceden en menos de 2
segundos.
9. DEFINICION Y DESCRIPCION DE CASOS DE USO
9.1 MODELADO DEL SISTEMA
Nota: En el sistema implementado el usuario será nombrado como personal y

super usuario como administrador.
9.2 DESCRIPCIÓN DE LOS ACTORES

Todo usuario debe loguearse antes de ingresar en el sistema, y
dependiendo de sus permisos se le asignan ciertas tareas que pueda
realizar.
Usuario (personal): Dentro de ésta categoría se encuentran

los trabajadores de Soporte y Sistema encargados de asistir a
los llamados de ayuda por parte del personal del colegio. Sus
permisos constan de crear y modificar reportes, además podrá
enviar correo al personal que hizo la llamada en caso de ser
necesario, y por último podrá revisar los reportes del sistema.
Super Usuario (administrador): En ésta categoría se

encuentra la jefatura del departamento de informática y del área
de Soporte y Sistemas. Éste tipo de usuario tiene todos los
permisos de un usuario normal y además podrá eliminar
reportes, crear y eliminar usuarios.
9.3 DESCRIPCIÓN DE LOS CASOS DE USO
Nombre del Caso de Uso: Inicio de Sesión (Login)

Desarrollado por: Sebastian Fuentealba
ID-caso de Uso:CU1.0
Objetivo:Identificar, autentificar e ingresar en el sistema. (Ya sea
usuario o superusuario)
Precondiciones: El usuario deberá tener un nombre de usuario y
password previamente inscritos en el sistema para identificarlo y
autenticarlo por parte del administrador.
Post-condiciones: El usuario quedará autenticado como
Usuario normal o Superusuario dependiendo de su información en la
base de datos. Según el tipo de usuario el sistema redirigirá a la
plataforma correspondiente.
Escenario Principal:
Acción del Actor Acción del Sistema
1. Este caso de uso 2. El sistema solicita nombre de usuario

comienza cuando un y contraseña.
usuario desea acceder al
sistema.
3. Ingresar nombre de 4. El sistema verifica que el nombre de

usuario y contraseña al usuario y contraseña correspondan a un
sistema. usuario registrado.
5. El sistema verifica el tipo de usuario y

se arroja el menú principal
correspondiente.
Escenario alterno:
Ítem 3: En caso que la autenticación del usuario indique que éste no

se encuentra registrado o que la contraseña es incorrecta el sistema
enviará una alerta indicando dicho error.
Nombre del Caso de Uso: Enviar correo de aviso.

Desarrollado por: Samuel Morales
ID-caso de Uso: CU2.0.
Objetivo: Enviar correo de aviso de un reporte realizado o con otro
propósito a un funcionario en particular.
Precondiciones: Estar logueado en el sistema ya sea como usuario o
superusuario.
Post-condiciones: Almacenarlo en el sistema.
Acción del actor Acción del sistema
1. Ir a la opción enviar 2.Guarda el reporte realizado en

reporte realizado una base de datos.
4. Llenar los datos pedidos por el 3.Desplegar ventana de envío de

sistema y seleccionar enviar. Correo de aviso
5.enviar datos al correo del

funcionario seleccionado.
Escenario alterno:
ítem 4: Si no están completados los campos no se podrá enviar el

reporte.
Ítem 4: Si no es enviado el mensaje la información no será

guardada.
Nombre del Caso de Uso: Crear reporte

Desarrollado por:Jordy Romero
ID-caso de Uso: CU3.1
Objetivo: Obtener información necesaria para el sistema.
Precondiciones: El usuario deberá estar autenticado en el sistema ya
sea como usuario o superusuario para acceder a éste punto.
Post-condiciones: El reporte queda guardado correctamente en el
sistema
Acción de Actor Acción del Sistema
1.Ir a la opción de crear 2.Desplegar ventana de creación de

reporte. reportes.
3.Llenar los campos de: 4.Mostrar mensaje de validación para

servicio, recurso/concepto, guardar los datos.
lugar,descripción, solución,
personal atendido,
correo,responsable de la
solución, hora y fecha, y
guardar.
5.Validar la realización de 6.Guardar la información ingresada al

un reporte. sistema en la base de datos.
7.Volver al menú principal
Escenario alterno:
Ítem 3: los campos de llenado obligatorio

serán:Responsable,Grupo,Estado,Fecha,Descripción,Codigo
Responsable (el cual será asignado automáticamente por el sistema)
en caso de no ser llenados se desplegará una ventana de alerta que
indique la necesidad de completarlos para continuar.
Ítem 3: La fecha será capturada automáticamente por el sistema

pero además podrá ser modificada por el usuario.
Ítem 5: En caso de que la validación sea cancelada los datos no

serán guardados en el sistema.
Nombre del Caso de Uso: Modificar reporte

Desarrollado por: Jordy Romero
Objetivo: Modificar un reporte ya creado en el sistema.
Precondiciones: El usuario deberá estar autenticado en el sistema
para acceder a éste punto ya sea como usuario o superusuario, el
reporte debe estar creado y almacenado en la base de datos.
Post-condiciones: El reporte es modificado y actualizado en el
sistema.
1.Ir a la opción de 2.Desplegar ventana de los reportes

modificar reporte. creados y que pueden ser modificados.
3.Seleccionar el reporte a 4.Mostrar mensaje de validación para

modificar en el sistema. actualizar los datos del reporte.
5.Validar la operación, 6.Se actualiza toda la información

seleccionar y modificar los almacenada en la base de datos del
datos deseados. reporte.
Escenario alterno:
Ítem 3: En caso de no existir reportes, el sistema indicará que “no

existen reportes para modificar”.

Nombre del Caso de Uso: Revisar reporte

Objetivo: Visualizar en pantalla un reporte realizado.
Precondiciones: Estar logueado en el sistema ya sea como usuario o
superusuario, tener reportes guardados previamente.
Postcondiciones:No aplica.
1.Ir a la opción de Revisar 2.Desplegar ventana de los reportes

Reporte. creados previamente.
3.Seleccionar código de 4.Mostrar en pantalla registro de datos
Reporte a Revisar en el del reporte seleccionado (Codigo
Sistema. Reporte, Descripción, Fecha, Grupo,
Estado, Funcionario, Email, Tipo,
Categoria, Recurso & Servicio,
Ubicación, Responsable).
Escenario alterno:
Ítem 3: En caso de no existir reportes, el sistema indicará que “no

existen reportes para revisar”.
Ítem 4: Acceder al botón Actualizar que redirija al caso de uso

correspondiente, ya que la función principal del Módulo es Revisar
reportes.
Ítem 4: Acceder al botón Eliminar que redirija al caso de uso

correspondiente, ya que la función principal del Módulo es Revisar
reportes.
Nombre de Caso de Uso: Buscar reporte

ID-Caso de uso: CU3.4
Objetivo: Buscar un reporte dentro del sistema.
Precondiciones: Estar logueado en el Sistema ya sea como usuario
o superusuario.
Post-condiciones:No Aplica.
Acción del actor Acción del Sistema
1. Ir a la opción de buscar 2. Desplegar ventana para

reporte. buscar un reporte en particular.
3. Se selecciona el código del 4. Genera el detalle del reporte

reporte a buscar. buscado en el sistema.
Escenario alterno:
Ítem 4: El reporte buscado no se encuentra en la base de datos del
sistema, se despliega ventana emergente con “Error reporte no
encontrado”.
Nombre del Caso de Uso: Eliminar reporte

Objetivo: Eliminar datos de un reporte realizado
Precondiciones: Estar logueado en el sistema como usuario o
superusuario,el reporte a eliminar debe estar creado anteriormente.
Post-condiciones: El reporte es eliminado de la base de datos y no
quedan registros de aquello.
1.Ir a la opción de eliminar 2.Desplegar ventana de de los reportes

reporte creados y que puede ser eliminado.
3.Seleccionar el reporte a 4.Mostrar mensaje de validación para

ser eliminado y una breve eliminar los datos del reporte.
descripción por el motivo a
eliminar.
5.Validar que quiere 6.Se elimina toda la información

eliminar reporte. almacenada en la base de datos del
reporte.
Escenario alterno:

Nombre del Caso de Uso: Crear usuario

Desarrollado por: Rodrigo Oliva
Objetivo: Crear un nuevo usuario o SuperUsuario en el sistema de
reportes.
Precondiciones: Estar logueado como super usuario.
Post-condiciones: El usuario es creado y almacenado en la base de
datos del sistema.
1.Ir a la opción de crear 2.Desplegar ventana con los campos a

usuario. ser llenados para crear usuario.
3.Se llena lo solicitado por 4.Mostrar mensaje de validación para

parte del sistema. crear un usuario.
5.Validar que quiere crear 6.Se crea un nuevo

un nuevo usuario / usuario/superusuario en el sistema y en
superusuario. la base de datos.
Escenario alterno:
Ítem 3: los campos de llenado son obligatorios , en caso de no ser

llenados se desplegará un aviso de alerta que indique la necesidad
de completarlos para continuar.

Nombre de Caso de Uso: Modificar Usuario

Objetivo: Modificar los datos del usuario en el sistema.
Precondiciones: Estar logueado en el Sistema como superusuario y
buscar usuario registrado en la Base de Datos del sistema
previamente.
Post-condiciones: Se realiza la modificación de un Usuario.
1.Ir a la opción de Modificar 2.Desplegar ventana con los

Usuario campos a ser llenados para
Modificar Usuario.
3.Se llena lo solicitado por 4.Mostrar mensaje de validación

parte del sistema. para Modificar un usuario.
5.Validar que quiere Modificar 6.Se crea la modificación

un usuario / superusuario. usuario/superusuario en el
sistema y en la base de datos.
Escenario alterno:


Nombre del Caso de Uso: Eliminar usuario

Objetivo: Eliminar un usuario registrado en el sistema de reportes.
Precondiciones: El usuario deberá estar autenticado como
superusuario en el sistema para acceder a este punto, buscar a un
usuario creado en la Base de datos del sistema previamente.
Post-condiciones: Se elimina el usuario por completo del sistema
junto a reportes creados.
1.Ir a la opción de eliminar 2.Desplegar ventana de de los usuarios

usuario del sistema. creados en el sistema y que puede ser
eliminado.
3.Seleccionar el usuario a 4.Mostrar mensaje de validación para

ser eliminado. eliminar el usuario y los reportes
realizados por el.

eliminar el usuario almacenada en la base de datos del
seleccionado. usuario.
Escenario alterno:

Nombre de Caso de Uso: Buscar Usuario

Objetivo: Buscar a usuario registrado en el sistema previamente.
Precondiciones: Estar logueado en el Sistema como SuperUsuario y
buscar usuario registrado en la Base de Datos del sistema
previamente.
.
Post-condiciones: No aplica.
1.Ir a la opción de Buscar 2.Desplegar ventana con el

usuario. campo (Id Usuario) a ser
llenados para Buscar usuario.
3.Se llena lo solicitado por 4.Mostrar información de

parte del sistema. Usuario.
Escenario alterno:
Ítem 3: El campo de llenado es obligatorio, en caso de no ser

llenado se desplegará un aviso de alerta que indique la necesidad de
completarlos para continuar.
Ítem 5: En caso de que la Búsqueda sea cancelada los datos no
Ítem 6: Si el id de usuario ingresado no es válido mostrará una

ventana de alerta que indique que el id ingresado no es válido.
Nombre de Caso de Uso: Crear Personal

Objetivo: Crear un nuevo Personal en el sistema de reportes.
Precondiciones: Estar logueado en el Sistema como SuperUsuario.
.
Post-condiciones: Se crea Personal en el sistema.
1.Ir a la opción de Crear 2.Desplegar ventana con los

Personal. campos a ser llenados para crear
Personal.

parte del sistema. para crear un Personal.
5.Validar que quiere crear un 6.Se crea un nuevo Personal en

nuevo Personal. el sistema y en la base de datos.
Escenario alterno:
Ítem 3: El campo de llenado es obligatorio , en caso de no ser

llenado se desplegará un aviso de alerta que indique la necesidad
Ítem 5: En caso de que la creación de personal sea cancelada los

datos no serán guardados en el sistema.
Ítem 6: Si los datos de personal ingresado no son válidos mostrará

una ventana de alerta que indique que los datos ingresado no son
válidos.
Nombre de Caso de Uso: Modificar Personal

Objetivo: Modificar un Personal existente en el sistema de reportes.
Precondiciones: Estar logueado en el Sistema como Superusuario.
Post-condiciones: Se realiza la modificación de los datos de un
Personal.

Personal. campos a ser llenados para
Modificar Personal.

parte del sistema. para Modificar un Personal.

Personal.. Personal en el sistema y en la
base de datos.
Escenario alterno:


Nombre de Caso de Uso: Eliminar Personal

Objetivo: Eliminar los datos de un personal ya registrado en el
sistema de reportes.
Precondiciones: Estar logueado en el Sistema como super usuario y
.
Post-condiciones:
1.Ir a la opción de eliminar 2.Desplegar ventana de Personal

Personal del sistema. creados en el sistema y que puede ser
eliminado.
3.Seleccionar el Personal 4.Mostrar mensaje de validación para

a ser eliminado. eliminar el Personal y los reportes
realizados por el.

eliminar el Personal almacenada en la base de datos del
seleccionado. Personal.
Escenario alterno:

Nombre de Caso de Uso: Buscar Personal

Objetivo: Mostrar los datos registrados en el Sistema de Reportes
de un Personal.
Precondiciones: Estar logueado en el Sistema como superusuario.
Post-condiciones:No aplica.

Personal. campo (Id Personal) a ser
llenados para Buscar Personal.
parte del sistema. Personal.
Escenario alterno:


Ítem 6: Si el id de Personal ingresado no es válido mostrará una

Nombre de Caso de Uso: Crear Historial

Desarrollado por: Francisca Martínez
Objetivo: Ingresar en el Sistema el registro del estado del desarrollo
de un trabajo.
Precondiciones: Estar logueado en el Sistema como usuario.
1.Ir a la opción de Crear Historial. 2.Desplegar ventana con los

campos a ser llenados para crear
Historial.

parte del sistema. para crear un Historial.
5.Validar que quiere crear un 6.Se crea un nuevo Historial en

nuevo Historial. el sistema y en la base de datos.

Escenario alterno:
Ítem 3: El campo de llenado es obligatorio , en caso de no ser

llenado se desplegará un aviso de alerta que indique la necesidad
Nombre de Caso de Uso: Modificar Historial

Objetivo: Modificar los datos de Historial en el sistema.
Precondiciones: Estar logueado en el Sistema como usuario o
superusuario .

Historial. campos a ser llenados para
Modificar Historial.

parte del sistema. para Modificar un Historial.

un Historial. Historial en el sistema y en la
base de datos.
Escenario alterno:


Nombre de Caso de Uso: Eliminar Historial

Objetivo: Borrar del Sistema de Reportes los datos del Historial
seleccionado.
Precondiciones: Estar logueado en el Sistema como usuario. Post-
condiciones:Se borra del sistema de reportes y de la base de datos el
historial seleccionado.
1.Ir a la opción de eliminar 2.Desplegar ventana de los Historiales

Historial del sistema. creados en el sistema y que puede ser
eliminado.
3.Seleccionar el Historial a 4.Mostrar mensaje de validación para

ser eliminado. eliminar el Historial.

eliminar el Historial almacenada en la base de datos del
seleccionado. Historial.
Escenario alterno:

Nombre de Caso de Uso: Buscar Historial

Objetivo: Buscar información de un historial previamente registrado en
el Sistema de Reportes.
Precondiciones: Estar logueado en el Sistema como usuario .
Post-condiciones: Estar logueado en el Sistema como usuario y
buscar Historial registrado en la Base de Datos del sistema
previamente.
.
Post-condiciones: No aplica.

Historial. campo (Id Historial) a ser
llenados para Buscar Historial.

parte del sistema. Historial.
Escenario alterno:


Ítem 6: Si el id de Historial ingresado no es válido mostrará una

10. MODELAMIENTO DE DATOS
El siguiente modelo de datos representa la información que se maneja en torno a la

obtención de información por parte de los reportes. Cabe decir que estos mismos
datos son utilizados para la generación de reportes por el sistema.
Atributo Entidad(es) Descripción

ID_Reporte Reporte Representa el identificador único de cada
reporte, que permite diferenciar un reporte de
otro.
Nombre_Reporte Reporte Es el nombre que tiene asociado el reporte.
Fecha_Reporte Reporte Representa la fecha de inicio del reporte.
Grupo Reporte Identifica a cuál grupo de trabajo o de

desarrollo dentro del colegio pertenece el
reporte.
Tipo_Reporte Reporte Representa al tipo de actividad del reporte

dentro del grupo.
Categoría Reporte Representa una categoría única dentro de la
organización dependiendo del tipo asignado
en el reporte.
Recuso_Servicio Reporte Son los recursos o servicios que son

ocupados desarrollando la actividad detallada
en el reporte.
Ubicación Reporte Representa una ubicación dentro de las

instalaciones del colegio.
ID_Historial Historial Representa el identificador único de cada

Historial, que permite diferenciar un estado de
otro.
Estado Historial Es el nombre que tiene asociado cada estado.
Descripción Historial Descripción del historial y datos relevantes
ID_Personal Personal Representa el identificador único de cada

Empleado, que permite diferenciar un
Empleado de otro.
Nombre_Personal Personal Es el nombre de cada empleado.
ApellidoP_Persona Personal Representa el apellido paterno de cada

l empleado.
ApellidoM_Person Personal Representa el apellido materno de cada

al empleado.
Cargo_Personal Personal Representa el cargo jerárquico asociado a

cada empleado.
Correo_Personal Personal Representa al correo de contacto de cada

empleado.
Rut_Personal Personal es el RUT de cada empleado.
Tipo Personal Representa al tipo de permiso que tiene cada

empleado dentro del sistema.
ID_Usuario Usuario Identificador único de las cuentas de usuario
Nombre_Usuario Usuario Nombre asignado a la cuenta de usuario del

personal
Password Usuario Variable única y secreta de acceso a la cuenta

de usuario
11. MODELO FÍSICO DE DATO
Se presentará el modelo físico de datos que está descrito por 11 tablas las cuales servirán
de estructura a nuestro modelo de base de datos:
Diccionario de datos del Modelo Físico:
Atributo Tabla Descripción Tipo/tamaño
ID_Personal Personal Identificador único del personal <pk> INT4
Nombre_Perso Personal Nombre del personal CHAR(15)

nal
ApellidoP_Pers Personal Apellido Paterno del personal CHAR(15)

onal
ApellidoM_Pers Personal Apellido Materno del personal CHAR(15)

onal
Cargo_Persona Personal Cargo que tiene el personal en la organización CHAR(15)

l
Correo_Person Personal Correo electrónico del personal CHAR(50)

al
Rut_Personal Personal Rut según norma chilena del personal CHAR(11)
Tipo Personal Es el tipo de permiso que tiene cada empleado CHAR(10)

dentro del sistema.
ID_Usuario Personal Identificador único del usuario <fk> INT4
ID_Reporte A_Cargo Identificador único de los reportes <pk,fk1> INT4
ID_Personal A_Cargo Identificador único del personal <pk,fk2> INT4
ID_Historial Historial Identificador único del Historial <pk> INT4
Estado Historial Estado del reporte (terminado, en proceso) CHAR(15)
Descripción_Ub Historial Descripción del Historial CHAR(500)

icación
ID_Reporte Historial Identificador único del reporte <fk> INT4
ID_Reporte Reporte Identificador único de los reportes <pk> INT4
Nombre_Repor Reporte Nombre del reporte realizado CHAR(15)

te
Fecha_Reporte Reporte Fecha en la cual se realiza el reporte DATE
Grupo Reporte Identifica a cuál grupo de trabajo o de VARCHAR(15)

reporte.
Tipo_Reporte Reporte Representa al tipo de actividad del reporte VARCHAR(15)

dentro del grupo.
Categoría Reporte Representa una categoría única dentro de la VARCHAR(15)

organización dependiendo del tipo asignado en
el reporte.
Recurso_Servic Reporte Son los recursos o servicios que son ocupados VARCHAR(15)
io desarrollando la actividad detallada en el
reporte.
Ubicación Reporte Representa una ubicación dentro de las VARCHAR(15)

ID_Usuario Usuario Identificador único de las cuentas de usuario INT4

<pk>
Nombre_Usuari Usuario Nombre asignado a la cuenta de usuario del VARCHAR(15)

o personal.
Password Usuario Variable única y secreta de acceso a la cuenta VARCHAR(50

de usuario 0)
12. ARQUITECTURA
Dado las características que presenta el proyecto, se propone la construcción

del sistema web utilizando una arquitectura Modelo Vista Controlador. De
esta forma se plantea un desarrollo modular de cada capa.
Las ventajas que se pueden apreciar al momento de ocupar estar
arquitectura son:
- La implementación se realiza de forma modular.
- Seguridad (comunicación entre capas restrictiva).
- Toda modificación en el sistema, generalmente se deben modificar las

vistas y no el sistema en general, ya que se permite trabajar en
distintos archivos.
- Escalabilidad del sistema a desarrollar.
- Simplicidad
- El mantenimiento es mucho más sencillo al tener una buen

organización en el sistema.
● DESCRIPCIÓN DE CÓMO FUNCIONA EL MVC.
1. Un usuario en particular realiza una solicitud a nuestro sitio web. Esa solicitud
le llega al controlador.
2. El controlador se comunica tanto con modelos como con vistas. A los

modelos les solicita datos o les manda realizar actualizaciones de los datos y
a las vistas les solicita la salida correspondiente.
3. El controlador será el responsable de solicitar todos los datos a los modelos y

de enviarlos a las vistas, haciendo de puente entre unos y otros.
4. Las vistas envían al usuario la salida. Aunque se debe tener en consideración

que a veces la salida puede ir de vuelta al controlador.
(Miguel Angel Alvares. (2014). Que es MVC. 2017, de Modelo Sitio web:
https://desarrolloweb.com/articulos/que-es-mvc.html)
Representación gráfica del MVC
● DESCRIPCIÓN DE CAPAS
Modelo Es la capa se encuentran los datos y se encarga de la

comunicación en la base de datos. En esta capa como se
señaló, se almacena los scripts SQL de nuestra Base de
Datos.
Vista Como hace relación al nombre, las vistas es la presentación

y visualización de las interfaces de usuario. Principalmente
en esta capa se alojan los archivos JavaScript.
Controlador Esta capa sirve de intermediario entre las vistas y los

modelos, dando respuestas a las peticiones del usuario, en
esta capa en particular se comunica con las vistas y los
modelos, solicitando al modelo los datos y a las vistas la
respectiva salida. En esta capa se alojan nuestros archivos
PHP.
● ¿PORQUÉ UTILIZAMOS MVC?

En vista de los articulos leidos y al conocimiento que obtuvimos de estos pudimos
concluir que dada la sensibilidad de la información que se almacena en la base de
datos es muy importante mantener un alto nivel de seguridad y restricción de acceso
a esta información, por ello abstracción de capas que presenta esta arquitectura es
bastante apropiada a utilizar en el proyecto descrito en este informe. El diseño MVC
nos permite independizar la lógica y la parte visual del sistema usando para eso un
controlador que administra los procesos sirviendo como puente entre estos.
13. INTERFAZ Y NAVEGACIÓN
El diseño de este sitio web fue diseñado de la forma más sencilla y accesible para el
personal del Colegio Andrés Bello, dando facilidad al momento de su
funcionamiento con sus respectivas categorías.
A continuación se describirán cada sección del sistema web a desarrollar.
Modulo Usuario:
● Descripción Sección Usuario
En esta captura identificamos la visualización de los usuarios registrados en el

sistema, los cuales están identificados por un id usuario, dentro de estos usuarios
podemos realizar las operaciones básica de todo formulario, crear, eliminar,
modificar y actualizar. Cada funcionalidad está detallada de la siguiente forma:
Id usuario: En este cuadro se identifican los usuarios registrados en el sistema, los

cuales están ingresados de forma ascendente al momento de ser registrados.
Personal: En este cuadro se encuentran los id del personal registrado en el sistema

y que están asociado a un usuario en particular.
Nombre Usuario: En este cuadro se encuentran los nombre de los usuarios

registrados en el sistema, cada id usuario va a corresponder a un usuario en
particular.
Tipo usuario: En este cuadro se divide en solo dos opciones, los cuales podemos
tener un usuario de tipo administrador o un usuario de tipo personal.
Módulo Personal:
● Descripción sección Personal
En esta representación del módulo personal se identifican los principales requisitos

funcionales y casos de usos asignados a Personal, donde se puede crear, modificar,
eliminar, buscar y visualizar al Personal. Cada posible acción de un usuario del
sistema está representada por una amigable interfaz y botones de acción en el
módulo. Además se pre visualiza detalles importantes que serán detallados a
continuación.
Id Personal: Es el identificador en la base de datos asignado de forma automática y

serial dentro del sistema.
Nombre Personal: Campo de nombre del personal en que será registrado en el

sistema.
Apellido Paterno: En este campo se asigna el apellido paterno del personal con el
cual es registrado en el sistema.
Apellido Materno: En este cuadro se encuentra el apellido materno del personal

con el cual es registrado en el sistema.
Cargo: En este cuadro se encuentra el cargo del personal en la organización que

fue guardado en el sistema.
Sección Generar Reporte:
● Descripción Sección Reporte
En esta captura identificamos 8 combobox (cuadro combinado o cuadro de lista) que

permiten generar un reporte sin inconsistencia de datos en el llenado del formulario,
un campo de texto y la fecha actual. Cada funcionalidad está detallada de la
siguiente forma:
Funcionario: En este cuadro combinado se encuentran los funcionarios disponibles

en el colegio para llevar a cabo el proceso o actividad que detalla este reporte.
Responsable: Este muestra la lista de posibles responsables del proceso o
actividad en la que participará el funcionario, los responsables son administrativos o
supervisores del colegio.
Grupo: En este cuadro se muestra las áreas o grupos de trabajo en la que se divide
la organización.
Tipo: En esta lista están presentes los tipos de trabajos, cada tipo de trabajo
depende del grupo de trabajo.
Categoría: En este cuadro van las posibles categorías del trabajo o acción
realizada, las categorías dependen del tipo de trabajo.
Recursos/servicios: Aquí están presentes los recursos disponibles para la

utilización en el caso de ser necesario por el funcionario que realizará la actividad.
Ubicación: Este cuadro combinado permite seleccionar la ubicación en la que se

generará la acción que detalla este reporte, las posibles ubicaciones están presente
dentro de las instalaciones del colegio.
Estado: Este combobox identifica el estado actual del reporte, si es que la acción
que detalla este reporte se encuentra completa y aún en estado activo, o terminada.
Descripción: Aquí se añaden los comentarios que describen el reporte en el caso

de ser necesario.
Fecha: Fecha del reporte que será generada automáticamente por el sistema (UTC-
4).
Crear: Botón que permite guardar y enviar el formulario de reporte al sistema, donde
podrá ser manipulado y visto desde otros módulos.
● Pantalla de Enviar correo de aviso

● Descripción
En esta captura se identifican todo los campos del formulario de contacto que estará
disponible en el sistema cuyo objetivo es enviar información respecto a un reporte a
un funcionario en específico que tengan relación con dicho reporte. Dando a conocer
el estado de la tarea realizada o por realizar, o cualquier otra información.
Nombre: Como los correos que se manden desde el sistema, siempre irán en
dirección de Mesa de Ayuda->funcionarios, el nombre será un campo que se llene
automaticamente con el nombre ya mencionado: “MESA DE AYUDA | CAB”.
Email: En este campo irá la dirección email del funcionario al que se le enviará el
correo electrónico.
Asunto: Aquí se debe describir un nombre identificativo para el email a enviar. Por
ejemplo: Reporte N° XXX recibido.
Cuerpo: Este Textbox tendrá un mensaje por defecto que se llenará

automáticamente cada vez de cargar la vista. Ya que es un mensaje que será
general para todos los funcionarios. Y a continuación del mensaje, se debe adjuntar
todo el detalle correspondiente al reporte que se informa. Teniendo en cuenta datos
como: fecha, ubicación, funcionario, descripción del problema y solución que se le
dio al reporte (en el caso que esté terminado), responsable a cargo de dicha tarea,
entre otros datos.
● Modulo Login/Ingreso al sistema.
● Descripción
En esta captura identificamos la interfaz de Ingreso al Sistema de Reportes, la cual
cuenta con dos campos de texto , un icono checkbox, botón de login.
1) Usuario: En este cuadro de texto se ingresa el nombre de usuario que le fue

asignado previamente por el administrador del sistema.
2) Contraseña:En este cuadro de texto se ingresa contraseña de usuario que le fue
asignado previamente por el administrador del sistema y/o la elegida por el usuario.
3) Checkbox Recordarme: Permite al usuario recordar sus datos de inicio de

sesión en los cookies del sistema.
4) Botón Login: Permitirá al usuario ingresar al sistema si los datos de inicio de

sesión fueron los correctos.
● Módulo Reportes
● Descripción
Este módulo servirá para registrar un nuevo reporte en línea. Los campos de
texto a completar por el usuario es el siguientes:
Descripción: Se espera que el usuario del sistema ingrese un resumen de lo

realizado durante su jornada laboral.
Fecha: Mediante un Combo Box el usuario podrá seleccionar la fecha del
reporte que se está registrando en el sistema (ya sea la actual o una
anterior).
Estado: Mediante un Combo Box el usuario podrá seleccionar el estado del

reporte que se está registrando en el sistema. Ejemplo: Completo,
incompleto, en curso.
Grupo: Mediante un Combo Box el usuario podrá seleccionar el Grupo del

reporte que se está registrando en el sistema. Ejemplo:
Soporte/Sistemas,Gestión,proyectos.
Responsable: Mediante un Combo Box el usuario podrá seleccionar el

Responsable del reporte que se está registrando previamente por el
administrador del sistema.
Código de reporte: Campo no editable por el usuario, es un código asignado

automaticamente por el sistema.
Módulo Historial
● Descripción
Este módulo servirá para registrar un nuevo Historial en línea el cual estará
enlazado a un reporte previamente creado. Los campos de texto a completar
por el usuario es el siguientes:
Id Historial: Es un campo que le completa automáticamente al momento de

Crear un Historial, es de tipo serial.
Id Reporte:Este campo mostrará el nombre del reporte al cual esta enlazado.
Descripción: Se espera que el usuario del sistema ingrese un resumen de lo

realizado durante su jornada laboral.
Estado: Mediante un Combo Box el usuario podrá seleccionar el estado del

reporte que se está registrando en el sistema. Ejemplo: en largo aliento,en
curso,terminado.
14. ESPECIFICACIÓN
● MÓDULOS
En las siguientes imágenes se adjuntan los módulos de la creación del

sistema a desarrollar.
Diagrama de clase:
● DICCIONARIO DE DATOS
Atributo Tabla Descripción Tipo/tamaño
ID_Personal Personal Identificador único del personal <pk> Int
Nombre_Perso Personal Nombre del personal String

nal
ApellidoP_Pers Personal Apellido Paterno del personal String

onal
ApellidoM_Pers Personal Apellido Materno del personal String

onal
Cargo_Persona Personal Cargo que tiene el personal en la organización String

l
Correo_Person Personal Correo electrónico del personal String

al
Rut_Personal Personal Rut según norma chilena del personal String
Tipo Personal Es el tipo de permiso que tiene cada empleado String

dentro del sistema.
ID_Usuario Personal Identificador único del usuario <fk> Int
ID_Reporte A_Cargo Identificador único de los reportes <pk,fk1> Int
ID_Personal A_Cargo Identificador único del personal <pk,fk2> Int
ID_Historial Historial Identificador único del Historial <pk> Int
Estado Historial Estado del reporte (terminado, en proceso) String
Descripción_Ub Historial Descripción del Historial String

icación
ID_Reporte Historial Identificador único del reporte <fk> Int
ID_Reporte Reporte Identificador único de los reportes <pk> Int
Nombre_Repor Reporte Nombre del reporte realizado String

te
Fecha_Reporte Reporte Fecha en la cual se realiza el reporte Date
Grupo Reporte Identifica a cuál grupo de trabajo o de String

reporte.
Tipo_Reporte Reporte Representa al tipo de actividad del reporte String

dentro del grupo.
Categoría Reporte Representa una categoría única dentro de la String

organización dependiendo del tipo asignado en
el reporte.
Recurso_Servic Reporte Son los recursos o servicios que son ocupados String
io desarrollando la actividad detallada en el
reporte.
Ubicación Reporte Representa una ubicación dentro de las String

ID_Usuario Usuario Identificador único de las cuentas de usuario Int

<pk>
Nombre_Usuari Usuario Nombre asignado a la cuenta de usuario del String
o personal.
Password Usuario Variable única y secreta de acceso a la cuenta String

de usuario
● IDENTIFICACIÓN DE LOS MÓDULOS DEL SISTEMA
ID Módulo Nombre Módulo Desarrollador

MS01.0 Inicio de sesión. Sebastián Fuentealba
MS02.1 Crear usuarios. Rodrigo Oliva
MS02.2 Modificar usuarios Rodrigo Oliva
MS02.3 Eliminar usuarios Rodrigo Oliva
MS02.4 Buscar usuarios Rodrigo Oliva
MS03.1 Crear reportes. Jordy Romero
MS03.2 Modificar reportes Jordy Romero
MS03.3 Eliminar reportes Jordy Romero
MS03.4 Buscar reportes Jordy Romero
MS04.1 Crear historial. Francisca Martinez
MS04.2 Modificar historial. Francisca Martinez
MS04.3 Eliminar historial. Francisca Martinez
MS04.4 Buscar historial. Francisca Martinez
MS05.1 Crear personal. Sebastián Fuentealba
MS05.2 Modificar personal Sebastián Fuentealba
MS05.3 Eliminar personal Sebastián Fuentealba
MS05.4 Buscar personal Sebastián Fuentealba
MS06 Comunicación con personal. Samuel Morales
Nota: El desarrollo del módulo MS06 fue realizado por programador que
actualmente no es parte del grupo de trabajo.
MÓDULOS DEL SISTEMA.
● MÓDULOS DE GESTIÓN DE PERSONAL.
○ Autor: Sebastián Fuentealba
Id módulo: MS01.0 Nombre Inicio de sesión

Módulo
Requisitos RF1.1- RF1.2- RF1.3 Casos de uso CU1.0

involucrados:
Subsistema / Inicio de sesión Clase / Usuario

paquete Archivo:
Descripción Módulo encargado de la autenticación de los permisos de entrada de

los usuarios del sistema, permite una seguridad integra a los módulos
siguientes donde solo permite validar a dos tipo de entidades
“usuario” y “super usuario” con sus respectivas autorizaciones.
● Parámetros de entrada
Nombre Tipo de dato
Nombre_Usuario varchar(15)
Password varchar(15)
● Parámetros de Salida.
Nombre Tipo de dato
Tipo_usuario varchar(30)
Id módulo: MS05.1 Nombre Creación de Personal

Módulo
Requisitos RF07.1 Casos de uso CU5.1

involucrados:
Subsistema / Gestión de Personal Clase / Personal

paquete Archivo:
Descripción Módulo encargado de la Creación del nuevo personal al sistema.
Los datos que se reciben mediante un formulario son insertados al
sistema mediante consultas a la base de datos (postgreSQL), donde
posteriormente pueden ser manipulados por otros módulos.
Nombre Tipo de dato
Nombre_Personal varchar(15)
ApellidoP_Personal varchar(15)
ApellidoM_Personal varchar(15)
Cargo_Personal varchar(15)
Correo_Personal varchar(50)
Rut_Personal varchar(11)
Tipo_Personal varchar(10)
Nombre Tipo de dato
ID_Personal int(4)
Id módulo: MS05.2 Nombre Modificar Personal

Módulo

involucrados:

paquete Archivo:
Descripción Módulo encargado de la Modificación del personal existente en el

sistema.
Los nuevos datos o cambios se reciben mediante un formulario y son
insertados al sistema mediante consultas a la base de datos
(postgreSQL), donde posteriormente pueden ser manipulados por
otros módulos.
Nombre Tipo de dato
Nombre Tipo de dato
Id módulo: MS05.3 Nombre Eliminar Personal

Módulo

involucrados:
paquete Archivo:
Descripción Módulo encargado de la Eliminación del personal existente en el

sistema.
El personal se selecciona en una lista o una vista del formulario y se
elimina mediante una consulta a la base de datos (postgreSQL) por
método cascada.
Nombre Tipo de dato
ID_Personal int(4)
Nombre Tipo de dato
ID_Personal int(4)
Id módulo: MS05.4 Nombre Buscar Personal

Módulo

involucrados:

paquete Archivo:
Descripción Módulo encargado de la Búsqueda del personal en el sistema.

El indicador de búsqueda se recibe mediante un cuadro de texto que
recibe el dato y realiza la búsqueda en el sistema mediante consultas
a la base de datos (postgreSQL), donde posteriormente pueden ser
manipulados por otros módulos.
Nombre Tipo de dato
ID_Personal int(4)
Nombre Tipo de dato
ID_Personal int(4)
● MÓDULO GESTIÓN DE HISTORIAL
○ Autor: Francisca Martinez
Id módulo: MS4.1 Nombre Módulo Crear Historial
Requisitos RF5 Casos de uso C.U6.1

involucrados:
Subsistema / Gestión de Historial Clase/Archivo: Historial

paquete
Descripción Módulo encargado de la Creación del nuevo Historial en el sistema.

Nombre Tipo de dato
ID_HISTORIAL INTEGER
ID_REPORTE INTEGER
ESTADO CHAR(15)
DESCRIPCIÓN CHAR(15)
Nombre Tipo de dato
ID_REPORTE INTEGER
ESTADO CHAR(15)
DESCRIPCION CHAR(500)
Id módulo: MS4.2 Nombre Módulo Modificar Historial

involucrados:
paquete
Descripción Módulo encargado de la Modificación de un Historial existente en el

sistema.
otros módulos.
Nombre Tipo de dato
ID_REPORTE INTEGER
ESTADO CHAR(15)
Nombre Tipo de dato
ID_REPORTE INTEGER
ESTADO CHAR(15)
Id módulo: MS4.3 Nombre Módulo Eliminar Historial

involucrados:

paquete
Descripción Módulo encargado de la Eliminación de Historiales que existentes en

el sistema.
El Historial se selecciona en una lista o una vista del formulario y se
método cascada.
Nombre Tipo de dato
ID_REPORTE INTEGER
ESTADO CHAR(15)
Nombre Tipo de dato
ID_REPORTE INTEGER
ESTADO CHAR(15)
Id módulo: MS4.4 Nombre Módulo Buscar Historial

involucrados:

paquete
Descripción Módulo encargado de la Búsqueda de Historiales en el sistema.

Nombre Tipo de dato
ID_REPORTE INTEGER
ESTADO CHAR(15)
Nombre Tipo de dato
ID_REPORTE INTEGER
ESTADO CHAR(15)
● MÓDULO GESTIÓN DE REPORTES
○ Autor: Jordy Romero
Id módulo: MS03.1 Nombre Creación de Reporte

Módulo
Requisitos RF03-RF03.1-RF03.2- Casos de uso CU3.1

involucrados: RF03.3
Subsistema / Gestión de Reporte Clase / Reporte
paquete Archivo:
Descripción Módulo encargado de la Creación del nuevo reporte al sistema.

Nombre Tipo de dato
Nombre_Reporte varchar(30)
Fecha_Reporte date
Grupo varchar(30)
Tipo_Reporte varchar(30)
Categoria varchar(30)
Recurso_Servicio varchar(30)
Ubicacion varchar(30)
Nombre Tipo de dato
ID_Personal int(4)
Fecha_Reporte date
Grupo varchar(30)
Id módulo: MS03.2 Nombre Modificar Reporte

Módulo
Requisitos RF03-RF03.2-RF03.3- Casos de uso CU3.2

involucrados: RF03.5
paquete Archivo:
Descripción Módulo encargado de la Modificación del reportes existente en el

sistema.
otros módulos.
Nombre Tipo de dato
Fecha_Reporte date
Grupo varchar(30)
Nombre Tipo de dato
Fecha_Reporte date
Grupo varchar(30)
Id módulo: MS03.3 Nombre Eliminar Reporte

Módulo
Requisitos RF03-RF03.4-RF03.7 Casos de uso CU3.3

involucrados:

paquete Archivo:
Descripción Módulo encargado de la Eliminación de reportes que existente en el

sistema.
El Reporte se selecciona en una lista o una vista del formulario y se
método cascada.
Nombre Tipo de dato
ID_Reporte int(4)
Nombre Tipo de dato
ID_Reporte int(4)
Id módulo: MS03.4 Nombre Buscar Reporte

Módulo

involucrados:

paquete Archivo:
Descripción Módulo encargado de la Búsqueda de reportes en el sistema.

Nombre Tipo de dato
ID_Reporte int(4)
Fecha_Reporte date
Grupo varchar(30)
Nombre Tipo de dato
ID_Reporte int(4)
Id módulo: MS03.5 Nombre revisión de Reporte

Módulo

involucrados:

paquete Archivo:
Descripción Módulo encargado de la revisión de reporte al sistema.

Los reportes listados en un formulario son revisados en el sistema
mediante consultas a la base de datos (postgreSQL), estos datos no
pueden ser manipulados,sólo vistos.
Nombre Tipo de dato
ID_Reporte int(4)
Nombre Tipo de dato
ID_Reporte int(4)
● MÓDULO GESTIÓN DE USUARIOS
○ Autor: Rodrigo Oliva
Id módulo: MS02 Nombre Gestión de Usuarios

Módulo
Requisitos RF05 Casos de uso CU4.1

involucrados:
Subsistema / Gestión de Usuarios Clase/Archivo: Usuario

paquete
Descripción Módulo encargado de la Creación del nuevo usuario al sistema.

Nombre Tipo de dato
NOMBRE_REPORTE VARCHAR(15)
NOMBRE_USUARIO VARCHAR(15)
PASSWORD VARCHAR(15)
TIPO_USUARIO VARCHAR(15)
Nombre Tipo de dato
ID_USUARIO INTEGER
ID_REPORTE INTEGER

Módulo
involucrados:

paquete
Descripción Módulo encargado de la modificación del usuario al sistema.

Nombre Tipo de dato
NOMBRE_REPORTE INTEGER
Nombre Tipo de dato
ID_USUARIO INTEGER
ID_PERSONAL INTEGER

Módulo

involucrados:

paquete
Descripción Módulo encargado de la eliminación del usuario al sistema.
Nombre Tipo de dato
ID_USUARIO INTEGER
ID_REPORTE INTEGER
Nombre Tipo de dato
ID_USUARIO INTEGER
ID_REPORTE INTEGER

Módulo

involucrados:

paquete
Descripción Módulo encargado de la búsqueda del usuario al sistema.

Nombre Tipo de dato

ID_USUARIO INTEGER
ID_REPORTE INTEGER
Nombre Tipo de dato
ID_USUARIO INTEGER
ID_REPORTE INTEGER
● MATRIZ DE TRAZABILIDAD
En la siguiente imagen se adjunta la matriz de trazabilidad de acuerdo al

sistema a desarrollar, esta matriz fue realizada de acuerdo a los Casos de
uso del proyecto y de los requisitos funcionales a completar. El objetivo de la
matriz es verificar si los casos de uso abarcan cabalmente todos los
requerimientos funcionales del sistema, además de ver las dependencias
entre sí. Esto útil resultará particularmente al momento de realizar
modificaciones en el sistema ya sea a pedido del usuario o por mantenciones
o mejoras a criterio del grupo de desarrollo.
.
● BUSINESS PROCESS MODEL AND NOTATION (BPMN)
● Sistema actual (As is).
El presente diagrama representa qué procesos está llevando a cabo por cada
tipo de empleado dentro del departamento de soporte y sistema, como se
puede apreciar al momento de ingresar los datos se debe corregir errores ya
que el ingreso de manera manual produce la posibilidad de incurrir en errores
de sintaxis en datos que son importantes para la consistencia de los mismos,
además el jefe de departamento solo puede ver la planilla como datos en
bruto lo cual no permite un adecuado manejo de la información.
Propuesta de sistema (To be).
El presente diagrama representa qué procesos serán llevados a cabo por

cada tipo de empleado dentro del departamento de soporte y sistema , como
se puede observar al momento de ingresar los reportes la tarea ya no es tan
extensa puesto que el sistema se encargará de revisar que la información
necesaria sea requerida en su totalidad.
● PRUEBAS DE SOFTWARE
PRUEBA N°1 Test Crear Usuario
TIPO DE PRUEBA CAJA NEGRA
CASO DE USO CORRESPONDIENTE CU4.0 - 4.1
AUTOR Rodrigo Oliva
FECHA REALIZADA 19/12/2017
FUNCIONALIDAD QUE CORRESPONDE Crear Usuario
DATOS DE ENTRADAS
Personal: Camila
Nombre Usuario: csoto
Password: 1234
Tipo Usuario: personal
DATOS DE SALIDA
Id usuario: 23
Personal: 20
Nombre Usuario: csoto
DESCRIPCIÓN
- La presente prueba consiste en la creación de un nuevo usuario,

insertando datos válidos para el sistema de acuerdo a los mencionados
anteriormente, cada uno de ellos es validado antes del ingreso al
sistema y a nuestra base de datos.
RESULTADOS DE EJECUCIÓN
- Captura de pantalla (Creacion usuario)
Creación de un nuevo usuario en el sistema
- Captura de pantalla (Base de datos antes de ingresar datos)

Verificamos los datos actuales de la base de datos antes de la inserción
- Captura de pantalla (Usuario ya creado en el sistema)
Usuario ya creado en el sistema
- Captura de pantalla (Base de datos realizada la inserción)

Verificamos nuevamente la base de datos y comprobamos la correcta
inserción del nuevo usuario (csoto).
CONCLUSION
- De acuerdo a lo realizado podemos verificar la correcta inserción de

datos en nuestro sistema y asi mismo lo comprobamos en nuestra base
de datos al consultar los datos ingresados.
PRUEBA N°2 Test Crear Usuario Invalido
AUTOR Rodrigo Oliva
FUNCIONALIDAD QUE CORRESPONDE Crear Usuario
DATOS DE ENTRADAS
Personal: Sebastian
Nombre Usuario: Campo nulo
Password: 1234
DATOS DE SALIDA
Mensaje de alerta
“Nombre de usuario no puede estar vacío”
DESCRIPCIÓN
- La presente prueba consiste en la creación de un nuevo usuario

invalido para el sistema, insertando datos que no sean permitidos por
el sistema de acuerdo a los mencionados, ya que cada campo llenado
antes de su inserción en validado por el sistema antes de ser
ingresados a nuestra base de datos.

Base de datos con el registro de los actuales usuarios en el sistema
- Captura de pantalla (Creacion usuario invalido)
Se da click en el botón crear y se comprueba que no deja insertar datos en el

sistema al tener un campo vacío.
- Captura de pantalla (Comprobación de NO inserción)

Verificamos nuevamente la base de datos del sistema para comprobar que no
se haya realizado la inserción de usuario.
CONCLUSION
- De acuerdo a lo realizado podemos verificar que el sistema antes de

ingresar los datos a nuestra base de datos, se verifican y se validan,
para así evitar posibles conflictos en la inserción de datos invalidos.
PRUEBA N°3 Test Eliminar Usuario
AUTOR Rodrigo Oliva
FUNCIONALIDAD QUE CORRESPONDE Eliminar Usuario
DATOS DE ENTRADAS
Id usuario: 20
DATOS DE SALIDA
Id usuario: 20
DESCRIPCIÓN
- La presente prueba consiste en la eliminación de un nuevo usuario, ya

almacenado en nuestro sistemas y base de datos, se puede verificar al
término su eliminación completa del sistema.
- Captura de pantalla (Base de datos actual antes de eliminar)
Base de datos actual antes de eliminar un usuario en particular.
- Captura de pantalla (Datos del usuario a Eliminar)
Datos del usuario a eliminar del sistema

- Captura de pantalla (Ventana emergente de eliminación)
Ventana emergente de confirmación del usuario a eliminar
- Captura de pantalla (Base de datos después de la eliminación)
Verificamos la base de datos que se haya eliminado el usuario
CONCLUSION
- De acuerdo a lo realizado podemos verificar la correcta eliminación de

datos de un usuario en nuestro sistema y asi mismo lo comprobamos
en nuestra base de datos al consultar los datos que se tienen
almacenados.
PRUEBA N°4 Test Crear Personal
AUTOR Sebastián Fuentealba

FUNCIONALIDAD QUE CORRESPONDE Crear Personal
DATOS DE ENTRADAS
Nombre: Javier
Apellido Paterno: Gonzales
Apellido Materno: Alveal
Cargo: Administrativo
Correo: javgonz@mail.com
Rut: 10957920-3
Tipo: Sistemas
DATOS DE SALIDA
Id Personal: 24
Nombre: Javier
Apellido Paterno: Gonzales
Apellido Materno: Alveal
Cargo: admin
Correo: javgon@mail.com
Rut: 109579203
DESCRIPCIÓN
- La presente prueba consiste en la creación de un nuevo personal,

insertando datos válidos para el sistema de acuerdo a los
anteriormente mencionados, cada uno de ellos es validado antes del
ingreso al sistema y a nuestra base de datos.
- Captura de pantalla (Creación Personal)

Creación de un nuevo personal en el sistema
Verificamos los datos actuales de la base de datos antes de la inserción
- Captura de pantalla (Personal ya creado en el sistema)

Creación de un Personal en el sistema
Verificamos nuevamente la base de datos del sistema para comprobar que

se haya realizado la inserción del nuevo Personal.
CONCLUSION
- De acuerdo a la prueba realizada podemos comprobar la correcta

inserción de datos en nuestro sistema y así mismo lo verificamos en
nuestra base de datos al consultar los datos ingresados.
PRUEBA N°5 Test Crear Personal Invalido
FUNCIONALIDAD QUE CORRESPONDE Crear Personal
DATOS DE ENTRADAS
Nombre: Campo nulo

Apellido Paterno: Campo nulo
Apellido Materno: Campo nulo
Cargo: Operativo
Correo: correo
Rut: 121212
Tipo: Sistemas
DATOS DE SALIDA
Mensaje de alerta
“Nombre Personal no puede estar vacío”
Mensaje de alerta
“Apellido Paterno no puede estar vacío”
Mensaje de alerta
“Apellido Materno no puede estar vacío”
Mensaje de alerta
“Correo no es una dirección de correo válida”
Mensaje de alerta
“Rut inválido”
DESCRIPCIÓN
- La actual prueba consiste en la creación de un nuevo Personal

inválido para el sistema, insertando datos que no sean permitidos por
antes de su inserción es validado por el sistema antes de ser
Verificamos la base de datos del sistema para verificar los datos antes de la
inserción
- Captura de pantalla (Creación Personal inválido)

Al presionar el botón verde con la opción de Crear nos impide la inserción de
los datos con mensajes de alertas bajo los campos de texto.
Verificamos nuevamente la base de datos del sistema para comprobar que

no se haya realizado la inserción del Personal con datos erróneos.
CONCLUSION
- Según las pruebas realizadas podemos verificar que el sistema antes

de ingresar los datos a nuestra base de datos, se comprueban y se
validan, para así evitar posibles conflictos en la inserción de datos
invalidos.
PRUEBA N°6 Test Eliminar Personal
FUNCIONALIDAD QUE CORRESPONDE Eliminar Personal
DATOS DE ENTRADAS
Id Personal: 26
DATOS DE SALIDA
Id Personal: 26
DESCRIPCIÓN
- La presente prueba consiste en la eliminación de un personal que ya

fue almacenado en nuestro sistema y base de datos, se puede verificar
al término su eliminación completa del sistema.

Base de datos actual antes de eliminar un personal en particular.
- Captura de pantalla (Datos del personal a Eliminar)
Datos del personal a eliminar del sistema
Ventana emergente de confirmación del personal a eliminar

Verificamos en la base de datos que se haya eliminado el personal
CONCLUSION

de datos al consultar los datos ingresados con anterioridad donde no
se hace presente el que eliminamos del sistema.
PRUEBA N°7 Test Crear Reporte
AUTOR Jordy Romero
FUNCIONALIDAD QUE CORRESPONDE Crear Reporte
DATOS DE ENTRADAS
Nombre Reporte: Reporte 3

Fecha Reporte: 2017-12-20
Grupo: Proyecto
Tipo Reporte: Redes
Categoría: Computadores
Recurso Servicio: Revisión
Ubicación: Biblioteca
DATOS DE SALIDA
Id Reporte: 10
Nombre Reporte: Reporte 3
Grupo: Proyecto
Tipo Reporte: Redes
DESCRIPCIÓN
- La presente prueba consiste en la creación de un nuevo reporte,

insertando datos válidos para el sistema de acuerdo a los mencionados
anteriormente, cada uno de ellos es validado antes del ingreso al
sistema y a nuestra base de datos.
- Captura de pantalla (Creacion usuario valido)
Los datos de entrada son ingresados al sistema y se presiona el botón Crear.

Aquí se puede observar la base de datos antes de ejecutarse la creación del

Aquí se puede observar la base de datos luego de ejecutarse la creación del

- Captura de pantalla (Usuario ya creado en el sistema)
A ésta pantalla redirecciona el sistema al presionar el botón crear, mostrando

los datos del reporte ya creado en el sistema.
CONCLUSION

de datos al consultar los datos ingresados.
PRUEBA N°8 Test Crear Reporte Invalido
AUTOR JordyRomer
FUNCIONALIDAD QUE CORRESPONDE Crear Reporte
DATOS DE ENTRADAS
Nombre Reporte: Campo Nulo

Grupo: Proyecto
Tipo Reporte: Redes
DATOS DE SALIDA
Mensaje de alerta
“Nombre Reporte no puede estar vacío.”
DESCRIPCIÓN
- La presente prueba consiste en la creación de un nuevo reporte

invalido para el sistema, insertando datos que no sean permitidos por
antes de su inserción en validado por el sistema antes de ser
Base de datos con el registro de los actuales reportes en el sistema
- Captura de pantalla (Creacion usuario invalido)

Se da click en el botón crear y se comprueba que no deja insertar datos en el
sistema al tener el campo Nombre Reporte vacío.

se haya realizado la inserción del reporte.
CONCLUSION
- De acuerdo a lo realizado podemos verificar que el sistema antes de

ingresar los datos a nuestra base de datos, se verifican y se validan,
para así evitar posibles conflictos en la inserción de datos invalidos.
PRUEBA N°9 Test Eliminar Reporte
AUTOR Jordy Romero
FUNCIONALIDAD QUE CORRESPONDE Eliminar Reporte
DATOS DE ENTRADAS
Id Reporte: 10
DATOS DE SALIDA
Id Reporte: 10
DESCRIPCIÓN
- La presente prueba consiste en la la eliminación de un reporte del

sistema, al momento de realizar esta acción el reporte deberá ser
eliminado a su vez de la base de datos de manera automática.

Base de datos actual antes de eliminar el reporte con Id Reporte igual a 10.
- Captura de pantalla (Datos del usuario a Eliminar)
Datos del reporte a eliminar del sistema
Ventana emergente de confirmación del reporte a eliminar

Verificamos la base de datos que se haya eliminado el reporte
CONCLUSION

datos de un reporte en nuestro sistema y asi mismo lo comprobamos
almacenados.
------------------
PRUEBA N°10 Test Crear Historial
AUTOR Francisca Martínez
FUNCIONALIDAD QUE CORRESPONDE Crear Historial
DATOS DE ENTRADAS
Reporte: Reporte2
Estado: Largo aliento
Descripción: Esta es una prueba de caja negra
DATOS DE SALIDA
Id_Historial: 13
Id_Reporte: 5
Estado: Largo aliento
Descripción: La presente prueba consiste en la creación de un nuevo
Historial, insertando datos válidos para el sistema:
1. Todos los campos a completar (Reporte,Estado,Descripcón)
fueron llenados
2. Se cumplió con el máximo de caracteres permitidos (500) en
la Descripción.
Cada uno de ellos es validado antes del ingreso al sistema y a nuestra base
de datos.
● Captura de pantalla (Creación de un Historial)
Creación de un nuevo Historial el Sistema

- Captura de pantalla (Historial ya creado en el sistema)
Historial ya creado en el sistema
● Captura de pantalla (Base de datos realizada la inserción del

Historial)
Verificamos nuevamente la base de datos y comprobamos la correcta
inserción del nuevo Historial
CONCLUSION

datos en nuestro sistema y así mismo lo comprobamos en nuestra
base de datos al consultar los datos ingresados.
222222222
PRUEBA N°11 Test Crear Historial Invalido
FUNCIONALIDAD QUE CORRESPONDE Crear Historial
DATOS DE ENTRADAS
Reporte: No se seleccionó un Reporte

Estado: En Curso
Descripción: Verificar cables de red sala de computación.
DATOS DE SALIDA
El sistema deberá mostrar un mensaje de alerta: “Seleccione un elemento de la lista”
DESCRIPCIÓN
- La presente prueba consiste en la creación de un Nuevo Historial sin

seleccionar un Reporte, el cual es un dato obligatorio al momento de
Crear un Historial, el fin de esta prueba es verificar la respectiva
validación del sistema antes de ser ingresados a nuestra base de
datos.
● Captura de pantalla (Base de datos antes de ingresar datos)
Base de datos con el registro de los actuales Historiales en el sistema
•Captura de pantalla (Creación Historial invalido)

Se da click en el botón crear se comprueba que efectivamente el sistema no
permite insertar datos en éste ni en la Base de Datos al tener un campo
vacío.

se haya realizado la inserción de un Nuevo Historial.
CONCLUSION
- De acuerdo a lo realizado podemos observar que el sistema antes de

guardar los datos verifica correctamente que ningún campo de llenado
quede vacío, para así evitar posibles conflictos en la inserción en la
Base de Datos.
PRUEBA N°12 Test Eliminar Historial
FUNCIONALIDAD QUE CORRESPONDE Eliminar Historial
DATOS DE ENTRADAS
Id_historial: Clave primaria que nos permitirá borrar un Historial.
DATOS DE SALIDA
Id_historial: Se borra del sistema y de la Base de Datos.
DESCRIPCIÓN
- La presente prueba consiste en la Eliminación de un Historial

previamente creados con datos válidos para el sistema los cuales
fueron mencionados anteriormente. Verificaremos que los datos hayan
sido borrados del sistema y de la Base de Datos.
Base de datos actual antes de eliminar un Historial en particular.
● Captura de pantalla (Historial a Eliminar)
Historial a eliminar del sistema

Ventana emergente de confirmación del Historial a eliminar
Verificamos la base de datos que se haya eliminado el Historial
CONCLUSION

datos de un Historial en nuestro sistema y así mismo lo comprobamos
almacenados, además verificamos el mensaje que nos alerta antes de
borrar un Historial.
● BITÁCORA DE PRODUCTIVIDAD / ESFUERZO
- Equipo y responsables del proyecto:
- Sebastián Fuentealba
- Francisca Martínez
- Rodrigo Oliva
- Jordy Romero
- Primera iteración del proyecto
Datos: Días Trabajados
04 de Septiembre 2017 (Minuta de Reunion Nº1)

04 de Octubre 2017 (Minuta de Reunion Nº8)
Tiempo trabajado: 720 Minutos

Mínimo Tiempo trabajado: 30 Minutos
Máximo Tiempo trabajado: 120 Minutos
Observaciones: Se dieron a conocer futuras reglas como equipo de trabajo, para no

comenter los mismos errores que se vieron expuesto en la primera entrega.
- Segunda iteración del proyecto

03 de Noviembre 2017 (Minuta de Reunion Nº17)

Observaciones: En esta segunda iteración se tuvo que desvincular del equipo de

trabajo a Samuel Morales por tener poco interés y responsabilidad en el proyecto.
Cabe señalar que el resto del equipo de trabajo realizó el proyecto en conjunto,
resolviendo dudas para finalizar el proyecto final.
- Tercera iteración del proyecto

01 de Diciembre 2017 (Minuta de Reunion Nº26)

Observaciones: Trabajo en conjunto como equipo, finalizando de buena manera el

proyecto final a presentar.
Total Horas Proyecto: 2610 minutos

● ESTIMACIÓN DE ESFUERZO
Integrante: Rodrigo Oliva Troncoso
Actividades/fases Minutos
Definición de proyecto 150
Especificación de Requerimientos 100
Análisis 200
Diseño del Modelo y Base de Datos 200
Diseño de Interfaz 100
Capacitación en Framework 250
Desarrollo y Codificación del Sistema 600
Pruebas de Sistema 400
Documentación Proyecto 610
TOTAL 2610
Integrante: Sebastián Fuentealba
Análisis 200
TOTAL 2610
Integrante: Jordy Romero

Análisis 200
TOTAL 2400
Integrante: Francisca Martinez
Análisis 150
TOTAL 2400
15. CONCLUSIÓN
Con este proyecto se desarrolló una solución web que nació del esfuerzo e iniciativa
de la unidad de informática del colegio Andrés Bello de Chiguayante, por modernizar
y optimizar el sistema actual de reportes, utilizado durante años al interior del
establecimiento.
La principal motivación del colegio fue integrar en una solución las herramientas y
los recursos que le den al colegio las bases para combatir de forma rigurosa y
controlada los conflictos generados por la información mal registrada e
inconsistencias en los reportes de los funcionarios .
Con la solución planteada se espera lograr facilitar el trabajo y el flujo de datos al

interior del establecimiento haciendo que las actividades de los funcionarios sean
administradas más eficientemente. El colegio contará con una base de datos en
PostgreSQL que almacenará a todos los funcionarios y las actividades realizadas en
el sistema, permitiendo la administración de los datos de forma más especializada y
controlada al antiguo sistema de reportes del colegio.
El impacto que la aplicación web tiene sobre el proceso interno de gestión

cambiará radicalmente el trabajo que los funcionarios realizan diariamente. El éxito
de un proyecto de este tipo puede verse reflejado en la calidad y el tipo de
información que el nuevo sistema almacena para futuros conflictos y nuevas
necesidades del sistema.
El desarrollo del proyecto de software bajo estándares de calidad, soportan el

desarrollo de trabajos futuros para evolucionar el sistema cada vez más y llevarlo a
otro nivel de complejidad es un valor agregado fruto del proceso ingenieril de
desarrollo de software, que asegure realmente la trascendencia y el uso del sistema
en el colegio.
WORKS CITED
Media, Triami. “Inflacion De Chile En 2017.” Inflacion De Chile En 2017
Inflacion IPC Chile 2017, es.inflation.eu/tasas-de-inflacion/chile/inflacion-
historica/ipc-inflacion-chile-2017.aspx.
ANEXOS
● Código de Formulario (Prototipo)

ANEXO 2: Script SQL

Sistema de Reportes (ENTREGA 3)

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistema de Reportes (ENTREGA 3)

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DEL BÍO-BÍO

FACULTAD DE CIENCIAS EMPRESARIALES

DESARROLLO DE SISTEMA WEB PARA REPORTES EN

Concepción, Diciembre 2017

AMBIENTE DE INGENIERÍA DE SOFTWARE 9

REQUISITOS DEL PROYECTO 25

DEFINICION Y DESCRIPCION DE CASOS DE USO 31

MODELO FÍSICO DE DATO 51

MÓDULOS DEL SISTEMA. 70

Uno de los grandes desafíos de todas las instituciones, ha sido la búsqueda

El Colegio Andrés Bello de Chiguayante se ha ganado el prestigio y

Se pretende trabajar en conjunto con el área informática de dicho

La aplicación pretende entregar información relevante y fácil de obtener

Los alcances de este proyecto pueden ayudar en gran medida en un futuro

● Equipo y responsables del proyecto:

● Fecha de inicio: Lunes 28 Agosto 2017

● Fecha final aproximada: Lunes 11 de Diciembre 2017

3.1. DESCRIPCIÓN DE PROBLEMAS GENERALES

Captura de Pantalla del Funcionamiento Actual (Planilla compartida por funcionarios)

3.2. PROPUESTA GENERAL

ALCANCE DEL PROYECTO

El costo asociado se evaluará de acuerdo los recursos humanos y las

El sistema contará con un super usuario encargado de la administración del

Esta herramienta aportará, entre otros, beneficios con la optimización de la

El Sistema permite la identificación de los distintos tipos de Usuarios del

● Adjuntar imágenes en los reportes

Todos los Reportes dispondrán de los mismos ítems:

4.1. OBJETIVO GENERAL

4.2. OBJETIVOS ESPECÍFICOS

O.E.2 Investigar e Identificar las principales tareas que puedan ser

O.E.3 Reducir costos de operación del sistema de reportes en línea con

O.E.5 Realizar pruebas (testing) del software desarrollado en base a los

5. AMBIENTE DE INGENIERÍA DE SOFTWARE

A lo largo del desarrollo del proyecto utilizaremos diversas técnicas y

● Modelos de procesos de negocio, BPMN (Business Process Model

● Breve descripción del Modelo Incremental:

Consiste en un desarrollo inicial de la arquitectura completa del sistema,

● ¿Porque utilizar esta metodología?

Dentro de las ventajas que podemos ver al ocupar el Modelo Incremental

- Es un modelo más flexible, por lo que se reduce el costo en el cambio

- Es más fácil probar y depurar en una iteración más pequeña.

- Es más fácil gestionar riesgos.

- Cada iteración es un hito gestionado fácilmente.

Nota: El proyecto a desarrollar cuenta de 2 incrementos funcionales para el

7.1. FACTIBILIDAD TÉCNICA

7.1.1. RECURSOS DEL SOFTWARE

Software Licencia Descripción

Windows 7 Microsoft Sistema Operativo utilizado como

Wampserver GNU General Conjunto de herramientas de

PostgreSQL PostgreSQL Sistema de gestión de base de

Yii2 Licencia BSD Framework PHP de código abierto

Sublime text 3 Software Editor de texto sofisticado para

Ganttproject GNU General Aplicación multiplataforma para la

Github GNU General Software de control de versiones

Composer MIT license Gestor de paquetes PHP a nivel de

Enterprise Software Herramienta de modelado de

Google Drive EULA Servicio de alojamiento de archivos

Microsoft Software Herramienta para la elaboración de

FilleZilla Licencia Cliente FTP multiplataforma para

PuTTY Licencia MIT Cliente SSH y Telnet para el

Nota: Se debe considerar las licencias de pago son proporcionadas por la

7.1.2. RECURSOS DEL HARDWARE

El servidor ha sido proporcionado previamente por el docente de la

- Procesador Intel Xeon Quad core E5504