CAPSTONE PROJECT

PROFESSIONAL SCHOOL OF SYSTEMS ENGINEERING

INFRASTRUCTURE MANAGEMENT SYSTEM AT UCSM

PARTICIPANTS

ESQUIEROS HERMOZA, PERCY ALEJANDRO

CASAS BRAVO, KEVIN ANSELMO
MAMANI ALFARO, FERDINAN JHOAQUIN
VILLAVICENCIO VICHATA, KIMBERLY EMMA

2019-1

Standards:

ISO/IEC 12207:2017 Systems and software engineering -- Software life cycle processes

ISO/IEC 16085:2006 Systems and software engineering -- Life cycle processes -- Risk
management.

ISO/IEC/TR 19759:2015 Software Engineering -- Guide to the software engineering body of

knowledge (SWEBOK)

ISO/IEC/IEEE 42010:2011 Systems and software engineering -- Architecture description

 PROYECTO CAPSTONE
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

SISTEMA DE GESTIÓN DE INFRAESTRUCTURA EN LA UCSM

INTEGRANTES

CASTRO DELGADO, GUSTAVO

ESQUIEROS HERMOZA, PERCY ALEJANDRO
CASAS BRAVO, KEVIN ANSELMO
MAMANI ALFARO, FERDINAN JHOAQUIN
VILLAVICENCIO VICHATA, KIMBERLY EMMA

2019-1
Estándares:

ISO/IEC 12207:2017 Procesos del ciclo de vida de software

ISO/IEC/IEEE 16326:2009 Sistemas e ingeniería de software - Procesos del ciclo de vida -

Gestión de proyectos

ISO/IEC TR 19759:2015 IS - Guía para el Cuerpo de Conocimiento de Ingeniería de

Software (SWEBOK).

ISO/IEC/IEEE 42010:2011 Sistemas e ingeniería de software - Descripción de la

arquitectura.
 <UCSM - EPIS>

CASTRO ESQUIEROS CASAS BRAVO, MAMANI VILLAVICENCIO

DELGADO, HERMOZA, KEVIN ALFARO, VICHATA,
GUSTAVO PERCY ANSELMO FERDINAN KIMBERLY
ALEJANDRO JHOAQUIN EMMA
2015200721 2015241201 2015241021 2015247501 2015246522
Grupo 4 Grupo 5 Grupo 4 Grupo 3 Grupo 4

SISTEMA DE GESTIÓN DE INFRAESTRUCTURA

Desarrollo de un sistema de gestión de infraestructura
de la UCSM
Versión 2.0
Table of Contents

1. Chapter 1: Vision 7
1.1.Introduction 7
1.1.1. Objectives
7
1.1.2. Scope
7
1.1.3. Definitions, Acronyms, and Abbreviations
7
1.1.4. References
8
1.1.5. General view
8
1.2.Positioning 8
1.2.1. Business Opportunity
8
1.2.2. Statement of Problem
8
1.2.3. Declaration of the Positioning of the Product
8
1.3.Descriptions of the stakeholders and the user 9
1.3.1. Market demographics
9
1.3.2. Summary of the interested part
10
1.3.3. User summary
11
1.3.4. User environment
11
1.3.5. Profiles of the interested part
11
1.3.6. User profiles
13
1.3.7. Key needs of the interested part or the user
13
1.3.8. Alternatives and competition
14
1.4Product description 15
1.4.1. Product Perspective 15
1.4.2. Capabilities summary 16
1.4.3. Assumptions and dependencies 16
1.4.4. Cost and prices 16
1.4.5. Licensing and installation 16
1.5. Product Characteristics 16
1.5.1. Agile and correct administration
17
1.5.2. Complete familiarization and teaching
17
1.5.3. It covers the greatest number of requirements
17
1.5.4. Scalable
17
1.6. Restrictions 17
1.7. Quality Ranks 19
1.8. Precedence and Priority 20
1.9. Other Product Requirements 21
1.10. Documentation Requirements 30
1.11. Feasibility Analysis 34

2. Chapter 2: Software Development Plan 36

2.1.Introduction 36
2.2.General View of the Project 37
2.3.Project Organization 39
2.4.Project Management 40

3. Chapter 3: Analysis 44
3.1.Requirements Analysis 44
3.2.View of Use Cases 51
3.3.Logical View 55

4. Chapter 4: Design 65
4.1.Physical architecture 65
4.2.Technologies used 65
4.3.Logical architecture 66

5. Chapter 5: Implementation 81
5.1.Initial configuration of the application 81
5.2.Development of communication libraries 81
5.3.Development of main functionalities 86
5.4.Graphic design 88
5.5.Development of main functionalities 90

6. Chapter 6: Tests 91
6.1.System Test Plan 91

7. Chapter 7: Results and Conclusions 93

Tabla de Contenidos

1. Capítulo 1: Visión 7
1.1.Introducción 7
1.1.1. O
bjetivos 7
1.1.2. Al
cance 7
1.1.3. D
efiniciones, Acrónimos, y Abreviaciones 7
1.1.4. R
eferencias 8
1.1.5. Vi
sión General 8
1.2.Posicionamiento 8
1.2.1. O
portunidad de Negocio 8
1.2.2. D
eclaración del Problema 8
1.2.3. D
eclaración del Posicionamiento del Producto 8
1.3.Descripciones de la parte interesada (Stakeholder) y del usuario 9
1.3.1. D
atos demográficos del mercado 9
1.3.2. Re
sumen de la parte interesada 10
1.3.3. Re
sumen de usuario 11
1.3.4. Ent
orno de usuario 11
1.3.5. Per
files de la parte interesada 11
1.3.6. Per
files de usuario 13
1.3.7. Ne
cesidades clave de la parte interesada o del usuario 14
1.3.8. Alt
ernativas y competencia 14
1.4Descripción del producto 15
1.4.1. Perspectiva del Producto 15
1.4.2. Resumen de capacidades 16
1.4.3. Suposiciones y dependencias 16
1.4.4. Coste y precios 16
1.4.5. Concesión de licencia e instalación 16
1.5. Características del Producto 17
1.5.1.
Ágil y correcta administración 17
1.5.2.
Completa familiarización y didáctica 17
1.5.3.
Cubre la mayor cantidad de requerimientos 17
1.5.4.
Escalable 17
1.6. Restricciones 17
1.7. Rangos de Calidad 19
1.8. Precedencia y Prioridad 20
1.9. Otros Requisitos del Producto 21
1.10. Requerimientos de Documentación 30
1.11. Análisis de Factibilidad 34

2. Capítulo 2: Plan de desarrollo de software 36

2.1.Introducción 36
2.2.Vista General del Proyecto 37
2.3.Organización del Proyecto 39
2.4.Gestión del Proyecto 40

3. Capítulo 3: Análisis 44
3.1.Análisis de Requisitos 44
3.2.Vista de Casos de Uso 51
3.3.Vista Lógica 55

4. Capítulo 4: Diseño 65
4.1.Arquitectura física 65
4.2.Tecnologías utilizadas 65
4.3.Arquitectura lógica 66

5. Capítulo 5: Implementación 81
5.1.Configuración inicial de la aplicación 81
5.2.Desarrollo librerías de comunicación 81
5.3.Desarrollo de funcionalidades principales 86
5.4.Diseño gráfico 88
5.5.Desarrollo de funcionalidades principales 90

6. Capítulo 6: Pruebas 91
6.1.Plan de pruebas del sistema 91

7. Capítulo 7: Resultados y Conclusiones 93

1. Capítulo 1: Visión
1.1. Introducción
El presente documento tiene como objetivo describir un sistema de gestión de
infraestructura para el uso de los docentes fuera de sus propios horarios, como punto de
base el sistema de muestra de aulas libres que actualmente posee la universidad, para
lo que ofreceremos una opción con la que los docentes puedan separar dichos
ambientes sin tener que ir a la oficina de Infraestructura de la universidad para poder
solicitar un ambiente o esperar a que alguno de los inspectores les habilite un espacio.

Se utilizará un Aplicativo Web para el acceso por parte de los usuarios administradores
los cuales darán la aprobación para el uso de los encargados (docentes o
administrativos). Se utilizará un Aplicativo Móvil para que los docentes puedan solicitar
los ambientes de forma más sencilla y a su vez este aplicativo servirá para el personal
de servicio para ser utilizado como una forma de validar para que el ambiente sea
preparado minutos antes de la hora de solicitud. El sistema tendrá una arquitectura
básica de 3 capas: La Aplicación Web/Móvil - interfaz, los procesos de negocio
soportados por el Servidor de la Universidad Católica de Santa María, ya sea dividiendo
los servicios del actual sistema de asignación de aulas libres en un módulo
relativamente independiente, donde se encontrará la funcionalidad principal del sistema.

1.1.1. Objetivos:

- Mejorar la funcionalidad del sistema actual ofreciendo una forma más efectiva
de solicitar los ambientes.
- Facilitar la petición de ambientes para los docentes.
- Optimizar el manejo de ambientes en la universidad ofreciendo al detalle el
contenido de cada uno de los que existen en la universidad.
- Ofrecer una opción muy sencilla para pedir y aprobar el uso de ambientes en la
universidad.
- Ofrecer una completa información sobre el contenido de cada ambiente existente
en la universidad.
- Hacer una interfaz visualmente intuitiva y rápida pensando en que no todos los
docentes tienen mucha habilidad con los smartphones.

1.1.2. Alcance
El proyecto incluye su uso por parte del personal administrativo y docentes del
plantel académico de la Universidad Católica de Santa Maria. Se tiene en cuenta el
uso de dispositivos electrónicos con conexión a internet como teléfonos celulares,
computadoras personales, laptops para el uso de una Aplicación Web que permite
un gran alcance de uso y también la facilidad de este. Es necesario contar con las
credenciales autorizadas por la Universidad para poder ingresar al sistema.

Áreas implicadas:
- Oficina de Infraestructura de la UCSM
- Docentes y personal administrativo de la UCSM

1.1.3. Definiciones, Acrónimos, y Abreviaciones

- Aplicación Web (Web App): Aplicación software ejecutada a través de algún
navegador web o alguna conexión principalmente web a través de la internet,
para un mayor alcance a usuarios variados.[1]
- Aplicación Móvil: Aplicación software ejecutada a través de algún teléfono
inteligente través de la internet, para un mayor alcance a usuarios variados.[2]

1.1.4. Referencias
[1]J. Castejón Garrido, "Arquitectura y sistemas web modernos", Pegaso.ls.fi.upm.es, 2019.
 [Online]. Available:
http://pegaso.ls.fi.upm.es/~sortega/html_css/files/Arquitectura_y_disenyo_de_sistemas_web_
modernos.pdf. [Accessed: 10- Apr- 2019].
[2]"Aplicación móvil", Es.wikipedia.org, 2019. [Online]. Available:
https://es.wikipedia.org/wiki/Aplicacion_movil . [Accessed: 10- Apr- 2019].
Estándares de Desarrollo:
[3] International Organization for Standardization. (2017). ISO/IEC/IEEE 12207: 2017 . [Online].
Available: https://www.iso.org/standard/63712.html [Accessed 12- Apr- 2019].
[4] International Organization for Standardization. (2006). ISO/IEC 16085:2006 Systems and
software engineering -- Life cycle processes -- Risk management . [Online]. Available:
https://www.iso.org/standard/40723.html [Accessed 12- Apr- 2019].
[5] International Organization for Standardization. (2015). ISO/IEC TR 19759: 2015 Software
Engineering -- Guide to the software engineering body of knowledge (SWEBOK) . [Online].
Available: https://www.iso.org/standard/67604.html [Accessed 12- Apr- 2019].
[6]International Organization for Standardization. (2011). ISO/IEC/IEEE 42010: 2011
Systems and software engineering -- Architecture description . [Online]. Available:
https://www.iso.org/standard/50508.html [Accessed 12- Apr- 2019].

1.2. Posicionamiento
1.2.1. Oportunidad de Negocio
El uso de un sistema interno en las universidades es una característica
fundamental que debería tener cualquier universidad en el mundo ya que se puede
observar que en los países de primer mundo, la mayoría de empresas o
universidades no pueden subsistir sin tener un sistema que les permita administrar
sus activos.

Actualmente los sistemas tienen la opción de que pueden ser utilizados desde
cualquier dispositivo ya sea móvil, web o desktop para brindar mayor alcance al
producto y no sólo cerrarse a un canal de interacción entre el usuario y el sistema,
debido a que esto no generaría la misma productividad a comparación de que el
sistema tenga un gran alcance.
La Universidad Católica de Santa María posee una variedad de sistemas en sus
distintas áreas pero algunas de estas sólo se limitan al uso de aplicaciones desktop
y no tanto para móvil o web, por lo que sería una gran ventaja que estas se
adapten a ese modelo.

1.2.2. Declaración del Problema

En la universidad la forma en la que los docentes o el personal administrativo
solicitan un ambiente para su uso es muy ineficiente, por lo cual hace que las
personas que necesiten este servicio terminan descartando la opción de solicitarlo
en la oficina de infraestructura y tomen la decisión de pedirla a uno de los
inspectores.
Actualmente existen muchos sistemas que permiten gestionar los ambientes de
una institución pero no es muy común buscar espacios disponibles y reservarlos.
Entonces, ¿Cómo ahondar y resolver el problema constante necesidad de solicitar
espacios disponibles y equipados en la universidad?
El equipo de trabajo decidió implementar una solución basada en aplicativos
móviles y web lo cual le permita a un operador aprobar una solicitud de ambiente
requerido (por parte de un usuario), teniendo claro que existirán diversas formas de
solicitarlo por lo que una busqueda podra ser muy general o en su defecto tan
personalizada como le sea necesario.

1.2.3. Declaración del Posicionamiento del Producto

Para docentes y personal administrativo , que participan de las actividades
académicas dentro de una universidad. El sistema es un aplicativo de carácter web
que ayuda a visualizar y separar horarios de los salones que forman parte de la
infraestructura de la universidad adecuándose de la mejor manera a las
 necesidades de los usuarios.

1.3. Descripciones de la parte interesada (Stakeholder) y del usuario

1.3.1. Datos demográficos del mercado
El mercado principal para este producto de software son las instituciones que
poseen algún proceso de negocio relacionado a la solicitud de ambientes fuera de
un horario diario establecido. Específicamente va dirigido a todo usuario que desee
solicitar ambientes mediante este sistema para poder tener el menor trámite
posible y así automatizar ciertos procesos a los que se ve afectado el solicitante.
● Notaremos dentro de los ambientes de nuestra universidad tienen
una disponibilidad fuera de su programación regular pre establecida
para el semestre de entre un 10 a 30% de horas hábiles del día. (Esto
es únicamente para salones de clases).
● Notaremos los auditorios y SUM de nuestra universidad tienen una
disponibilidad fuera de su programación regular pre establecida para
el semestre de entre un 60 a 70% de días hábiles del mes.
● Los talleres tienen una disponibilidad fuera de su programación
regular pre establecida para el semestre de entre un 15 a 25% de
horas hábiles del día. (Esto es únicamente para salones de clases).

Ambiente Disponibilidad Sede

% prom

Aulas 10 - 30% /día Principal / Huasacache / Majes

Auditorios 60- 70% /mes Principal

Sum 60- 70% /mes Principal

Talleres 10 - 30% /día Principal / Huasacache/ Parq.

Industrial

Tabla 1: Porcentajes de disponibilidad de ambientes fuera de un

horario preestablecido

1.3.2. Resumen de la parte interesada

Las partes interesadas identificadas en el desarrollo de este proyecto son las
siguientes:

Usuarios:
● Docentes.
Representa al usuario central del sistema, ya que es el que más utilizará
esta herramienta de separación de salones.

● Alumnos.
Representa al usuario subcentral, debido a que en la mayoría de casos se
más que los docentes separen salones a no ser que sean alumnos
encargados por algún docente o con motivos académicos de enseñanza.

Agentes Administrativos:
● Rectorado.
Representa la parte inversora y que además tiene cierta participación en la
aprobación de la separación de los salones. No posee una intervención
mayor dentro del proyecto, a excepción de dar la aprobación durante el
 avance en los pasos del proyecto.

● Infraestructura.
Representa la parte que se encargará de recibir la mayor parte de las
solicitudes de los alumnos o docentes que separen los salones.

Personal de Proyecto:
● Desarrolladores.
Representa a la parte dedicada a poner el proyecto en marcha y es
encargada de seguir los pasos definidos en el proyecto y aprobados por el
asesor.

1.3.3. Resumen de usuario

● Usuario 1:
○ Nombre: Docente/Usuario.
○ Descripción: Usuario principal, tiene la posibilidad de consultar la
disponibilidad de las aulas, laboratorios, etc. para poder solicitar el
uso en un horario determinado disponible.
○ Parte interesada: Docentes.

● Usuario 2:
○ Nombre: Administrador.
○ Descripción: Encargado de gestionar y administrar los pedidos de
solicitud de las aulas, teniendo la posibilidad de aprobar o no, los
pedidos de los docentes y/o usuarios.
○ Parte interesada: Docentes.

1.3.4. Entorno de usuario

Dentro de nuestro sistema podemos definir dos tipos de usuarios: Usuarios y
administrador. Por parte de los usuarios tendríamos a los docentes que son los
principales los cuales realizarán las solicitudes de ambientes y el personal de
servicio que estará a cargo de verificar que su solicitud es validar y poder abrir el
ambiente solicitado.

Por parte de los administradores tenemos a las personas encargadas de realizar la

aprobación requerida sea aula, laboratorio o auditorio.
Tenemos entendido que se pueden aplicar restricciones de tiempo por parte de los
administradores para que cuando al pasar cierta cantidad de tiempo se apruebe o
deniegue automáticamente la solicitud de dicho ambiente. El acceso a este
aplicativo es únicamente para personas en específico designadas por el jefe del
área de Infraestructura.

Finalmente, este sistema será adicionado al ERP de la universidad lo cual no solo

les permitirá realizar solicitudes y aprobarlos si no también que podrán encontrar el
contenido de dicho ambiente con solo revisar en los detalles de muestra siendo
esta opción únicamente para personal muy específico determinado por el jefe del
área de Infraestructura.
 Imagen 1: Diagrama de Contexto del sistema de gestión de la infraestructura

1.3.5. Perfiles de la parte interesada

Representante Fredy Ramiro Delgado Delgado

Descripción Director de operación

Tipo Experto

Responsabilidade ● Aprobar la visión y el alcance del sistema

s ● Aprobar entregas del proyecto

Representante Marco Llaza

Descripción Jefe de Infraestructura

Tipo Experto

Responsabilidades ● Proporcionar el acceso instalaciones y a

procedimientos existentes

Representante Castro Delgado, Gustavo

Descripción Desarrollador de Software

Tipo Usuario casual

Responsabilidade ● Proveer requerimientos

s ● Validar requerimientos
● Validar prototipos
 Representante Esquieros Hermoza, Percy Alejandro

Descripción Desarrollador

Tipo Experto

Responsabilidade ● Proporcionar y validar requerimientos con

s respecto a la administración del sistema y sus
necesidades.

Representante Casas Bravo, Kevin Anselmo

Descripción Líder de proyecto

Tipo Experto

Responsabilidade ● Coordinar el proyecto

s ● Representar al equipo de desarrollo

Representante Mamani Alfaro, Ferdinan Jhoaquin

Descripción Administrador de la base de datos

Tipo Administrador

Responsabilidade ● Brindar información y datos

s ● Brindar acceso a la base de datos

Representante Villavicencio Vichata, Kimberly Emma

Descripción Representante de Infraestructura

Tipo Experto

Responsabilidade ● Validar la arquitectura del sistema

s ● Apoyar en la implementación de la
arquitectura de sistema

1.3.6. Perfiles de usuario

- Docentes: Son usuarios principales, que se encargan de realizar la
solicitud de un ambiente previamente calificado como disponible y siendo
esta la que el docente a buscado y seleccionado.
- Administrativo: Son usuarios que pueden ser principiantes, que deben
aprobar o rechazar la solicitud de pedido de aula analizando el tipo de
usuario
- Servicio: El personal de servicio estará en la disposición de poder verificar
si es que el aula fue solicitado o no que podrá ser fácilmente comprobable.

1.3.7. Necesidades clave de la parte interesada o del usuario

 El problema que tiene el usuario del sistema actualmente es que el docente para
solicitar un ambiente debe ir a la oficina de infraestructura y solicitar un espacio
para un día en específico o en el caso de ambientes designados específicamente
como los SUM de los cuales se encarga la facultad de administrarlos, teniendo que
ir a su respectiva ubicación ya que no se puede hacer una reservación vía móvil
con notificación a un administrador web. El sistema muestra la disponibilidad, pero
no está disponible para todos los usuarios descritos anteriormente.

Id Necesidad Prioridad Problema Solución Actual Solución

Propuesta

01 Mostrar Alta Dificultad para Generar un Implementación

ambientes verificar la documento que en el nuevo
disponibles disponibilidad muestre sistema
disponibilidad actual

02 Generar Alta Dificultad que genera Dirigirse a la oficina Implementación

solicitud tener que ir a la de Infraestructura a en el nuevo
oficina realizar una solicitud sistema

03 Aprobar Alta Generar el Solicitar a la Implementación

solicitud documento con encargada el en el nuevo
disponibilidad actual ambiente deseado sistema
y trámite de
aprobación

04 Notificación de Media Saber cuando se han Atención personal Implementación

solicitud generado las en el nuevo
solicitudes sistema

05 Auto Media Saber si la Atención personal Implementación

aprobación por separación ha sido en el nuevo
tipo de usuario aprobada sistema
Tabla 2: Necesidades de la parte interesada

1.3.8. Alternativas y competencia

La universidad Católica de Santa María actualmente cuenta con una aplicación
web muestra los horarios de los ambientes disponibles y a su vez podría verse que
horarios estarán disponibles. Se tiene que ir a consultar en la oficina y se realiza la
solicitud. Para realizar una reserva el proceso por el cual se debe pasar es el
siguiente: Solicitar un identificador de usuario registrado dentro de la universidad y
posteriormente solicitar el ambiente deseado según se verifique la disponibilidad de
este.

1.4. Descripción del producto

1.4.1. Perspectiva del producto
El sistema que se desarrollará se encargará de proporcionar una opción para
poder solicitar aulas fuera de los horarios establecidos para el semestre para lo
cual los administradores realizarán la aprobación o negación requerida en el
sistema. Por ejemplo, Un docente desea reservar el auditorio Santa María y no
sabe cuál es el horario o los días que estará ocupado dicho ambiente por lo cual
mediante el aplicativo se podrá ver cuál es su disponibilidad y a su vez el
equipamiento y su capacidad para así verificar si ese auditorio es el adecuado para
sus necesidades, realizar la solicitud y dependiendo del administrador encargado
de dicho ambiente se realizará la respectiva aprobación o rechazo de la solicitud.
1.4.2. Resumen de capacidades

Beneficio de Usuario Características de soporte

El personal docente podrá El uso de las bases de datos existentes

ver la disponibilidad de ofrecerá la opción de solicitar un
ambientes en cualquier ambiente dependiendo de la necesidad
momento que tenga.

El personal administrativo Las bases de datos existentes ofrecen la

podrá ver a detalle el opción de verificar el contenido que tiene
contenido de cada cada ambiente.
ambiente existente en la
universidad
La satisfacción mejora con Al no tener que ir a la oficina
respecto a la mejora del correspondiente para verificar o reservar
proceso. el ambiente necesario se puede
gestionar mejor otras actividades
Los problemas Cuando se produzca un error en el
pueden sistema, esté será informado
identificarse más automáticamente y al instante
rápidamente.
Tabla 3: Beneficios y características

1.4.3. Suposiciones y dependencias

Físicas:
- Problemas de trabajo conjunto con el resto del sistema de matrículas.
Digitales:
- Integración con módulos específicos y los datos de la Base de Datos de la
Universidad Católica de Santa María.
- Uso del Servidor de la Universidad, implementación de Servicios.

1.4.4. Coste y precios

Se podría considerar el costo de material que se usará para la confección del
proyecto. Sin embargo, al ser éste de naturaleza académica, ni el costo ni el precio
influyen en gran medida en su éxito.
Para estimar los costos en base al esfuerzo y dificultad del proyecto utilizaremos
COCOMO II por lo cual presentaremos los reportes obtenidos con respecto a los 2
módulos presentados y detallados en el software COCOMOII-2000:
Imagen 2: Costo de proyecto
Imagen 3: Costo del Módulo 1 del proyecto
 Imagen 4: Costo del módulo 2 del proyecto

Estimación Final
Descripción Costo Final
(s/.)
Costo Usando COCOMO II 6,558.45

PRESUPUESTO TOTAL s/. 6,558.45

Tabla 4: Costo de servicios ocupados durante los 4 meses

1.4.5. Concesión de licencia e instalación

● Gestor de Base de Datos PostgreSQL, licencia gratuita.
● Servicios Web del Servidor de la UCSM.
● Aplicativo Play Store Android 4.4 a superior, licencia Gratuita de
Desarrollador.

1.5. Características del Producto

ID Descripción

CAR-01 Capacidad de solicitar un ambiente libre.

CAR-02 Capacidad de enviar notificaciones de aviso de solicitud a administradores.

CAR-03 Capacidad de realizar búsquedas personalizadas de ambientes teniendo

como criterios: capacidad, ubicación, equipamiento.

CAR-04 Capacidad de generar reportes de uso de ambientes.

CAR-05 Capacidad de verificar la legitimidad de la solicitud.

CAR-06 Capacidad de visualizar el equipamiento de todos los ambientes

registrados en la universidad.

CAR-07 Capacidad de realizar Modificaciones a los ambientes existentes.

 CAR-08 Capacidad habilitar o inhabilitar un ambiente.

CAR-09 Capacidad de personalizar el diseño de la aplicación según las

preferencias del usuario.

CAR-10 Ágil y correcta administración.

CAR-11 Escalable para el mantenimiento y documentación.

Tabla 5: Costo de servicios ocupados durante los 4 meses

1.6. Restricciones
Tiempo:
● El planeamiento del proyecto acabará 1 mes después de haberse
llegado a un acuerdo con respecto al arrendamiento del servicio.
● Se brindarán reportes y pruebas según requerimientos del cliente de
cada avance con un tiempo máximo entre cada reporte de 2 semanas.
● Se brindarán reportes y pruebas según requerimientos del cliente de
cada avance con un tiempo mínimo entre cada reporte de 3 días.
Alcance:
● Está restringido a los docentes y personal administrativo de la
universidad.
Costos:
● El costo tendrá una posibilidad de variación y este puede ser de hasta
un 15% más o un 5% menos con respecto al valor de trabajo del
personal que se requiera como límite a partir de la estimación.
● Toda característica solicitada posterior a la finalización se encontrará
fuera del acuerdo y estas tendrán un costo de hasta el 1% del valor
final del sistema.
● La frecuencia de las pruebas puede ser más acotada lo cual genera
costos extras equivalentes a horas extras del a las horas de trabajo
requeridas por el personal requerido.
Calidad:
● Cada avance concreto pasará por un proceso de pruebas de
usabilidad y accesibilidad en caso sea interfaz gráfica.
● Cada avance concreto pasará por un proceso de pruebas de
optimización y rendimiento, en caso sean módulos en concreto con una
funcionalidad básica o compleja.
● Se asegura la optimización del código generado y de existir problemas
se procederá a la refactorización del método en cuestión o de su
replanteamiento (de ser necesario), esto es enteramente
responsabilidad del equipo de programación.

Satisfacción del cliente:

● Evaluado por el cliente en base a lo planteado y siendo aplicado los
estándares pertinentes.

Riesgo:
● Degradación de este al realizar pruebas constantes
● Una de las principales limitantes que se encontró al investigar con
personas relacionadas con el uso constante no directamente, pero si
por parte de sus respectivos jefes de área viene a ser la oposición que
presentan estos usuarios al cambio que conlleva a la implementación
de un sistema de estas características.

● La segunda de las causas importantes es la validación de un código o

 encriptación de seguridad para validar documentos que permiten
registrar la solicitud de ambientes que albergan eventos de mayor
envergadura, como lo son los auditorios o laboratorios de nuestra
universidad.

1.7. Rangos de Calidad

Métrica Aplicación

Técnica El sistema es un subsistema que trabaja y requiere de módulos

del sistema.

Calidad Será dada cuando se cumplan los requisitos especificados en el

documento y se cuente con la aceptación del usuario final

Productividad Se verá en la evaluación de los resultados logrados mediante la

aplicación del sistema

Costo Los costos no deben exceder de ninguna manera lo

presupuestado en el documento.

Tamaño El sistema será desarrollado por un equipo de 5 personas en un

plazo no mayor a 6 meses contando con las pruebas e
implementación.
Tabla 6: Rangos de Calidad
1.8. Precedencia y Prioridad

ID Descripción Prioridad

CAR-01 Capacidad de solicitar un ambiente libre. Alta

CAR-02 Capacidad de enviar notificaciones de aviso de solicitud a Alta

administradores.

CAR-03 Capacidad de realizar búsquedas personalizadas de Alta

ambientes teniendo como criterios: capacidad, ubicación,
equipamiento.

CAR-04 Capacidad de generar reportes de uso de ambientes. Media

CAR-05 Capacidad de verificar la legitimidad de la solicitud. Media

CAR-06 Capacidad de visualizar el equipamiento de todos los Alta

ambientes registrados en la universidad.

CAR-07 Capacidad de realizar Modificaciónes a los ambientes Baja

existentes.

CAR-08 Capacidad habilitar o inhabilitar un ambiente. Baja

CAR-09 Capacidad de personalizar el diseño de la aplicación según Alta

las preferencias del usuario.
 CAR-10 Ágil y correcta administración. Media

CAR-11 Escalable para el mantenimiento y documentación. Media

Tabla 7: Características del Sistema
1.9. Otros Requisitos del Producto
1.9.1. Estándares, Metodologías, Modelos, Lenguajes Aplicables
El proyecto cumple con los siguientes estándares:
● ISO/IEC 12207: Procesos del ciclo de vida de software.
● ISO/IEC 16085:2006 Sistemas e ingeniería de software - Procesos del ciclo de
vida - Gestión de riesgos.
● ISO/IEC TR 19759:2015 Ingeniería de software - Guía para el Cuerpo de
Conocimiento de Ingeniería de Software (SWEBOK).
● ISO/IEC/IEEE 42010:2011 Sistemas e ingeniería de software - Descripción de la
arquitectura.
Además, se usará el lenguaje de modelado UML y el proyecto será desarrollado
bajo la metodología RUP - Rational Unified Process (Proceso Unificado de Rational)
de desarrollo de software.

1.9.2. Requisitos del sistema

● Plataformas de Red: Conexión a Internet publica de forma abierta sin restricciones
mayores de tráfico.
● Sistemas Operativos: Servidor en PostgreSQL 9.5. Uso de aplicativo web en
Windows (Cualquiera), Linux (14.00), Unix (Cualquiera), MacOS (Sierra), Android
5.0.0 en adelante
● Configuraciones: Acceso a red local, redes públicas de internet.
● Memoria: Espacio de memoria aproximadamente de 50 mbps para guardado de
archivos de Configuración locales y registros caches en dispositivos de usuario.
Espacio de almacenamiento mayor a 50 TBs (variable) por parte del Servidor para el
almacenamiento de datos del sistema de matrículas y sistema experto de
programación de horarios.
● Dispositivos Periféricos: Computadora de escritorio: uso de teclado, mouse,
monitor y opcionalmente impresora; Dispositivos móviles: uso de touchscreen.
● Software: Navegadores de internet que soporten versiones superiores de HTML5,
CSS y PHP para el aplicativo web: Mozilla Firefox, Google Chrome, Opera, Vivaldi,
Safari, Internet Explorer, Internet Edge, entre otros.

1.9.3. Requisitos de rendimiento

● Ancho de Banda: Uso de 1mbs a mayor para optimo uso del aplicativo web por
navegadores web.
● Capacidad de Comunicación: Libertad de comunicación entre servidor y cliente
usuario desactivando restricciones de red.
● Rendimiento: Recomendaciones óptimas de uso de dispositivos electrónicos con
un procesador igual o mayor a 1.2 GHz de procesamiento.
● Fiabilidad: Resistencia a fallo y robustez de uso continuo por parte de dispositivos
de usuario y en especial del Servidor principal brindado por la Universidad Católica
de Santa María para el Sistema de Matrículas.
● Tiempo de Respuesta: Tiempo de respuesta considerable no mayor a al menos
10 segundos de espera entre cualquier tipo de acciones realizadas dentro del
aplicativo web.
 1.9.4. Requisitos de Entorno
Hardware:
● Temperatura: Temperatura promedio de servidor entre 18 ⁰C y 23 ⁰C,
Temperatura promedio de dispositivos móviles entre 20 ⁰C y 30 ⁰C, temperatura
promedio de computadoras personales entre 45 ⁰C y 60 ⁰C
● Humedad: La humedad del aire debe de oscilar entre el 40% y 55% para
funcionalidad óptima sin altercados.
● Voltaje: No superar el voltaje eléctrico del corriente máximo hasta 230V, no menor
a 100V para normal funcionamiento.
Software:
● Condiciones de Uso: Por parte del Desarrollo y Mantenimiento de la Aplicación y
Servidor Principal solo personal autorizado puede ingresar a equipos.
● Disponibilidad de los Recursos: Conexión a internet público sin restricciones
mayores de tráfico para mantenimiento y uso del aplicativo web del sistema de
programación de matrículas.
● Problemas de Mantenimiento: Feedback y comunicación inmediata entre el
equipo de desarrollo y mantenimiento, así como también feedback proporcionado
por los alumnos a través de la oficina de informática o redes sociales para ponerse
en contacto con la Universidad.
● Manejo de Errores: Reporte de errores y fallos dentro del equipo de desarrollo y
mantenimiento según políticas de trabajo de la Universidad y en específico del
departamento de Informática.

1.9.5. Requisitos medioambientales

La aplicación o producto desarrollado cumple con las normas específicas sobre
protección del Medio Ambiente, reciclaje de materiales degradados, desecho
adecuado de materiales no reciclables, consumo responsable de electricidad.

1.10. Requerimientos de Documentación

● La documentación del proyecto estará de acuerdo con las indicaciones dadas en la
ISO 27001
● Incluir los enunciados del SGSI
● Se debe describir el alcance del proyecto, así como la metodología para la evaluación
del riesgo, un reporte de la evaluación del riesgo anexado a la presente
documentación.
● Enunciados de la aplicabilidad del proyecto.
● Evitar el uso indebido de documentos obsoletos
● Mantener un control de los registros, modificaciones y versiones del documento.

1.11. Análisis de Factibilidad

Económica Tiempo del análisis

Costo del estudio del sistema
Costo del tiempo del personal
Costo estimado de los equipos
Costo de software

Tecnológica Mejora del sistema actual

Disponibilidad de la tecnología que
satisfaga las necesidades del usuario

Operativa El sistema estará operable en la web

 El sistema será utilizado por personal
Tabla 8: Factibilidad del sistema

1.11.1, Factibilidad Operacional:

La factibilidad se calculó evaluando a los implicados en el alcance del proyecto y el
impacto que proporcionará en su trabajo y sus beneficios para la organización.
Primeramente, se formó a una opinión por parte del solicitante sobre la necesidad y
posteriormente al realizar pequeñas entrevistas con diversos involucrados se pudo
recabar. Posteriormente se descubrió que en las etapas en las que más se requieren de
estas solicitudes en la semana de exámenes. Este es un sistema con una funcionalidad
básica y de bajo consumo de recursos, pero bastante útil.

1.11.2. Factibilidad Tecnológica:

Esta factibilidad está condicionada más por el uso de la herramienta Android Studio, y que
consume una cantidad generosa de recursos a lo que los programadores que se verán
expuestos, posteriormente al final del desarrollo del aplicativo cualquier computadora
puede realizar las tareas de programación y pruebas de los módulos creados. Debido a
que la UCSM cuenta con un servidor se puede permitir alojar el aplicativo y agregar la
funcionalidad sin ningún problema. Aunque también se tiene que hacer mención de las
herramientas open source como PHP, HTML, FLASK, PYTHON y otras herramientas.

1.11.3. Factibilidad Económico-Financiera:

Como vimos en la sección 1.4.4 en la que especificamos costos, veremos que el costo es
bajo y a la larga mejoran la imagen de la universidad como entidad que ofrece un sistema
lo suficientemente colaborativo para con sus empleados.

Presupuesto

Descripción Costo Final

(s/.)
Costo Usando COCOMO II 6,558.45

Total Estimado: s/. 6,558.45

Tabla 9: Factibilidad del sistema

1.11.4. Los Beneficios Tangibles e Intangibles Esperados:

Beneficios tangibles:
- Reducción de tareas administrativas.
- Mejor manejo de la infraestructura
Beneficios intangibles:
- Facilitar la ejecución de los procesos relacionados a la preservación de ambientes.
- Mayor satisfacción de trabajadores y usuarios que emplearán el sistema.

2. Capítulo 2: Plan de desarrollo de software

2.1. Introducción:
Este plan de Desarrollo de Software es la versión preliminar para ser incluida en la
actual propuesta del Capstone Project desarrollado a lo largo del presente año
académico.
El documento provee una visión global del enfoque de desarrollo propuesto. Se basa en
la metodología RUP (Rational Unified Process) donde se cumpliran las 4
correspondientes fases: Inicio, Elaboración de una Iteración, fase de construcción y las
iteraciones de la fase de transición.
El presente documento es un artefacto de RUP de acuerdo a las características
planteadas del propio Sistema de Programación de Horarios a Presentar.
 2.1.1. Propósito:
El propósito del Plan de Desarrollo de Software es proporcionar la información necesaria
para controlar el proyecto. En él se describe el enfoque de desarrollo del software. Los
usuarios del Plan de Desarrollo del Software son:
- El jefe del proyecto lo utiliza para organizar la agenda y necesidades de recursos, y
para realizar su seguimiento.
- Los miembros del equipo de desarrollo lo usan para entender lo qué deben hacer,
cuándo deben hacerlo y qué otras actividades dependen de ello.
2.1.2. Alcance:
● El sistema de búsqueda y solicitud de ambientes ofrecerá una opción web
para quienes no deseen usar la opción de descargar la aplicación o para
sistemas IOS.
● El sistema se unirá al ERP de la universidad.
● El sistema es acoplado al servidor de la universidad lo cual le permitirá
ocupar sus recursos.
● Los componentes de su arquitectura son: EL aplicativo web, servidor central,
el proceso del Negocio, la base de datos específicamente datos de registro
de usuarios y horarios de ocupación durante el semestre, nuevas tablas se
incluirán dentro de la base de datos para poder unirlas con las que se
necesiten.
2.1.3 Resumen:
El documento estará compuesto de la siguiente forma:
● Vista general del proyecto, donde se describe el propósito, alcance y
objetivos.
● Organización, donde se describe la estructura organizacional del equipo de
trabajo.
● Gestión de procesos, donde se explican los costos y planificación
definiendo hitos y describiendo el seguimiento de este.
● Planes y guías, donde se proporciona vistas en general del proceso de
desarrollo de software.

2.2. Vista General del Proyecto

2.2.1. Propósito, Alcance y Objetivos
- Objetivo general:
• Proporcionar un sistema sencillo que permita a los usuarios realizar
solicitudes de ambientes deseados para cualquier propósito que intervenga
en las actividades de la universidad.
- Objetivo específico:
• Eliminar el trámite administrativo para solicitar ambientes en ciertas áreas.
• Administrar mejor los recursos de infraestructura de la universidad.
• Crear una cultura de respeto hacia la propiedad de la universidad al enseñar
a solicitar y no solo ocupar un espacio que puede que no esté disponible por
el momento, pero posteriormente si lo esté.
2.2.2. Suposiciones y restricciones
● Deberá respetarse la normativa de la oficina de Infraestructura para realizar la
aprobación de la solicitud correspondiente.
● Se deberá determinar un criterio de reservación para que no existan cruces
entre usuarios que deseen solicitar y estén al mismo tiempo usando el
aplicativo.
● Se deberá considerar los criterios de la oficina de Infraestructura para otorgar
aprobaciones automáticas según el cargo del usuario solicitante.
2.2.3. Entregables del proyecto
Mediante el ISO/IEC 16085-2006 este punto será descrito en la sección 2.4.3
mediante la Administración de riesgos.
2.2.4. Evolución del Plan de desarrollo del software
El plan de desarrollo se revisa cada semana y este se refina antes de iniciar una
iteración.
2.3. Organización del Proyecto
2.3.1. Participantes en el Proyecto

Iteración Puesto Nomb

re
Fase de Analista de Sistemas Alejandro Esquieros
Inicio 1 Ferdinan Mamani
Analista - Programador Kevin Casas
Responsable de Kimberly Villavicencio
pruebas
Ingeniero de Software Gustavo Castro

Fase de Jefe de Proyecto

Elaboració Analista de Sistemas Ferdinan Mamani
n
1 Analista - Programador Kevin Casas
Responsable de Kimberly Villavicencio
pruebas
Ingeniero de Software Gustavo Castro

Fase de Jefe de Proyecto

Construcci Analista de Sistemas Ferdinan Mamani
ó
1, 2, 3 Analista - Programador Kevin Casas
Responsable de Kimberly Villavicencio
pruebas
Ingeniero de Software Gustavo Castro

Fase de Jefe de Proyecto

Transición Analista de Sistemas Ferdinan Mamani
1,2 Analista - Programador Kevin Casas
Responsable de Kimberly Villavicencio
pruebas Gustavo Castro
Ingeniero de Software
Tabla 10: Factibilidad del sistema
2.3.2. Interfaces Externas
La aplicación contará con las siguientes pantallas:
- Pantalla de login: Es la primera pantalla que se muestra, donde se requiere
el nombre del usuario y la clave asociada al mismo, también contará con un
botón para ejecutar el proceso de autentificación.
- Pantalla de inicio: Es la pantalla principal del sistema, se presentará un
menú de opciones donde se puede redireccionar a otras pantallas.
- Pantalla de solicitud de ambientes: Esta pantalla permitirá al usuario
solicitar un ambiente. También se darán opciones para buscar el ambiente
según el requerimiento del usuario.
- Pantalla de visualización de aulas disponibles: Esta pantalla mostrará al
usuario todos los ambientes disponibles según su requerimiento.
- Pantalla de generación de reportes: Esta pantalla permitirá generar reportes
del uso de ambientes.

2.3.3. Roles y Responsabilidades

Nombre Rol Responsabilidades
 Gustavo Castro Desarrollador/ Tester Elaboración del
documento e
implementación de la
aplicación.
Alejandro Esquieros Arquitecto Elaboración del
documento e
implementación de la
aplicación.
Kevin Casas Analista de Elaboración del
requerimientos documento e
implementación de la
aplicación.
Ferdinan Mamani Tester Elaboración del
documento e
implementación de la
aplicación.

Kimberly Villavicencio Analista de Datos Elaboración del

documento e
implementación de la
aplicación.
Tabla 11: Roles y Responsables

2.4. Gestión del Proyecto

2.4.1. Estimaciones del Proyecto
Como se vio en el punto 1.4.4 la estimación del proyecto que tendríamos sería
la siguiente:

Estimación Final

Descripción Costo Final

(s/.)
Costo Usando COCOMO II 6,558.45

Total Estimado: s/. 6,558.45

Tabla 12: Estimaciones del proyecto

Asumiendo que se realizó un recargo por diversos factores inherentes a las

pruebas y desarrollo de módulos extras que permiten que el sistema sea lo
más robusto posible y el recargo sería de un 15% obtendremos finalmente:

Estimación Final

Descripción Costo Final

(s/.)
Costo Usando COCOMO II 6,558.45

Total Estimado: s/. 6,558.45

Tabla 13: Estimaciones finales
2.4.2. Plan del Proyecto
2.4.2.1. Plan de las Fases
El desarrollo se llevará a cabo en base a fases con una o más iteraciones en
cada una de ellas. La siguiente tabla muestra una la distribución de tiempos y el
número de iteraciones de cada fase.

Fase Nro. Duración

Iteraciones
Fase de Inicio 1 2 semanas

Fase de Elaboración 1 4 semanas

Fase de Construcción 3 8 semanas

Fase de Transición 2 2 semanas

Tabla 14: Plan de Fases

Los hitos que marcan el final de cada fase se describen en la siguiente tabla.

Descripción Hito

Fase de Inicio Los principales casos de uso serán identificados y se

hará un refinamiento del Plan de Desarrollo del
Proyecto. La aceptación del usuario académico y el
Plan de Desarrollo marcan el final de esta fase.

Fase de En esta fase se analizan los requisitos y se

Elaboración desarrolla un prototipo de arquitectura (se incluyen
las partes más relevantes y críticas del sistema).
Concluida esta fase, los casos correspondientes a
requisitos serán implementados en la primera
iteración de la Fase de Construcción, deben de
haberse analizado y diseñado. La revisión y
aceptación del prototipo de arquitectura del sistema
marca el final de esta fase.
Fase de La culminación de la iteración 3.0 marca el final de
Construcción esta fase, con la capacidad operativa parcial del
producto de software para entregarse a los usuarios.

Fase de Transición El hito que marca el fin de esta fase es la entrega de

toda la documentación del proyecto con los
manuales de instalación, material de apoyo al
usuario, manual de usuario, se culmina el
entrenamiento de los usuarios académicos y el
empaquetamiento del producto para subirse a la
tienda virtual de Google y estar disponible al plantel
estudiantil.
Tabla 15: Hitos del proyecto
 2.4.2.2. Calendario del Proyecto

Modo de tarea ED Nombre de tarea Duració Comienzo Fin Predecesor % Encargado

T n as complet
ado

Programada 1 Iniciación de 21 días lun lun 65% Castro

manualmente Proyecto 25/03/19 22/04/19 Delgado,
Gustavo

Programada 1.1 Entrevista de 10 días lun vie 70% Villavicenci

manualmente toma de 25/03/19 05/04/19 o Vichata,
Requerimientos Kimberly

Programada 1.2 Análisis de 3 días lun mié 2 60% Mamani

manualmente Requerimientos 08/04/19 10/04/19 Alfaro,
Ferdinan

Programada 1.3 Definición de 7 días jue vie 3 60% Casas

manualmente Proyecto 11/04/19 19/04/19 Bravo,
Kevin

Programada 1.4 Consolidación 0 días lun lun 4 100% Esquieros

manualmente del Análisis 22/04/19 22/04/19 Hermosa,
inicial Alejandro

Programada 2 Elaboración y 45 días mar lun 5 94% Mamani

manualmente Planeamiento 23/04/19 24/06/19 Alfaro,
 Ferdinan

Programada 2.1 Análisis de 6 días mar mar 70% Casas

manualmente Procesos 23/04/19 30/04/19 Bravo,
Principales Kevin

Programada 2.2 Definición de 5 días mié mar 7 90% Esquieros

manualmente Requerimientos 01/05/19 07/05/19 Hermosa,
Alejandro

Programada 2.3 Casos de Uso 7 días mié jue 8 80% Villavicenci

manualmente 08/05/19 16/05/19 o Vichata,
Kimberly

Programada 2.4 Definición y 5 días vie jue 9 90% Mamani

manualmente Diseño de Datos 17/05/19 23/05/19 Alfaro,
Ferdinan

Programada 2.5 Definición y 4 días vie mié 10 80% Esquieros

manualmente Diseño de 24/05/19 29/05/19 Hermosa,
Interfaces Alejandro

Programada 2.6 Estructurar 3 días jue lun 11 90% Castro

manualmente Soluciones 30/05/19 03/06/19 Delgado,
Técnicas Gustavo

Programada 2.7 Definición y 12 días mar mié 12 80% Mamani

manualmente Diseño de 04/06/19 19/06/19 Alfaro,
Arquitectura SW Ferdinan

Programada 2.8 Propuesta de 2 días jue vie 13 90% Villavicenci

manualmente Proyecto con 20/06/19 21/06/19 o Vichata,
Dirección EPIS Kimberly
Programada 2.9 Aprobación de 0 días lun lun 14 100% Casas
manualmente Implementación 24/06/19 24/06/19 Bravo,
del Proyecto Kevin

Programada 3 Construcción 30 días lun vie 15 20% Castro

manualmente 12/08/19 12/09/19 Delgado,
Gustavo

Programada 3.1 Gestión de 5 días lun vie 16 10% Esquieros

manualmente recursos 12/09/19 17/09/19 Hermosa,
Alejandro

Programada 3.2 Implementaci 14 días lun vie 17 50% Casas

manualmente ón de 18/09/19 1/10/19 Bravo,
Componentes Kevin

Programada 3.3 Pruebas 2 días lun vie 18 40% Esquieros

manualmente internas de 2/10/19 03/10/19 Hermosa,
Componentes Alejandro

Programada 3.4 Recojo de 2 días lun vie 19 0% Castro

manualmente Feedback 04/10/19 05/10/19 Delgado,
Gustavo

Programada 3.5 Análisis y 2 días lun vie 20 0% Casas

manualmente refactorización 06/10/19 07/10/19 Bravo,
Kevin

Programada 3.6 Consolidar 1 días lun vie 21 0% Mamani

manualmente Versión de 08/10/19 08/10/19 Alfaro,
usuario Ferdinan

Programada 4 Transición del 10 días lun vie 22 0% Villavicenci

manualmente Proyecto 09/10/19 18/10/19 o Vichata,
Kimberly
Programada 4.1 Ejecución de 3 días lun mar 22 0% Castro
manualmente planes de 19/10/19 21/10/19 Delgado,
implantación Gustavo

Programada 4.2 Finalizar 2 días mié vie 24 0% Esquieros

manualmente material de 22/10/19 23/10/19 Hermosa,
soporte Alejandro

Programada 4.3 Pruebas en 8 días lun jue 25 0% Villavicenci

manualmente entorno de 24/10/19 31/10/19 o Vichata,
usuario Kimberly

Programada 4.4 Ajustar 6 días vie jue 26 0% Mamani

manualmente producto según 01/11/19 07/11/19 Alfaro,
Feedback Ferdinan

Programada 4.5 Consolidar y 7 días vie vie 27 0% Casas

manualmente lanzar Software 08/11/19 15/11/19 Bravo,
Kevin

Tabla 14: Calendario de proyecto

 Imagen 6: Diagrama de Gantt del proyecto

2.4.3. Administración de Riesgos

Riesgos Técnicos

ID Riesgo Descripción Causa Probabilidad Impacto Respuesta Estrategia

Raiz Planificada De
Respuesta

R1 Fallas Hw Retraso en Falta de Baja Alto Solicitud de Evasión

el desarrollo mantenimi soporte
por falta de ento de técnico
materiales rutina

R2 Fallas Sw Retraso en Errores de Media Alto Restauració Mitigación

el desarrollo escritura n de
por errores en disco o sistema,
de sistema posibles Limpieza de
atacantes amenaza o
reinstalació
n de
paquetes

R3 Fallas de Retraso en Problemas Media Medio Usar el Mitigación

conectividad el desarrollo con el ISP servicio
técnico del
ISP
Riesgos de Gestión

R4 No Retraso en Mala Media Alto Reorganiza Evasión

completar actividades gestión o ción de
Actividades diarias seguimient esquema
o del de trabajo
proyecto

R5 Fuera de Entregas Tiempo no Media Media Reorganiza Mitigación

tiempo fuera de planificado ción de
fecha tiempos

Riesgos Internos

R6 Documentac Descoordina Mala Media Alto Analizar el Evasión

ión ción gestión seguimiento
inconclusa para
verificar
dónde se
produce el
error

Riesgos Externos

R7 Rechazo al Puede Falta de Alta Alta Dar charlas Evasión

cambio preferirse informació de
seguir de la n motivación
forma y
menos familiarizaci
optima ón
Tabla 15: Administración de riesgos del proyecto

2.4.4. Estimación de Costes:

Con el fin de intentar estimar las horas de dedicación que se van a realizar al
proyecto se ha empleado el método de Evaluación por un Experto. A través de
éste es posible obtener el esfuerzo que requerirá el desarrollo del proyecto,
estimar los costes y el tiempo necesario para cumplir con el correcto desarrollo
de cada fase de RUP.
 Imagen 7: Estimaciones de costes

2.4.4.1. Dedicación al Desarrollo

Con el fin de intentar estimar las horas de dedicación que se van a realizar al
proyecto se ha empleado el método de Evaluación por un Experto. A través de
éste es posible obtener el esfuerzo que requerirá el desarrollo del proyecto,
estimar los costes y el tiempo necesario para cumplir con el correcto desarrollo
de cada fase de RUP.

2.4.5. Seguimiento y Control del Proyecto

● Gestión de Requisitos
Los requisitos del sistema son especificados en el artefacto Visión. Cada
requisito tendrá una serie de atributos tales como importancia, estado,
iteración donde se implementa, etc.
Estos atributos permitirán realizar un efectivo seguimiento de cada requisito.
Los cambios en los requisitos serán gestionados mediante una Solicitud de
Cambio, las cuales serán evaluadas y distribuidas para asegurar la
integridad del sistema y el correcto proceso de gestión de configuración y
cambios.

● Control de Plazos
El calendario del proyecto tendrá un seguimiento y evaluación semanal por
el jefe de proyecto y por el Comité de Seguimiento y Control.

● Control de Calidad
Los defectos detectados en las revisiones y formalizados también en una
Solicitud de Cambio tendrán un seguimiento para asegurar la conformidad
respecto de la solución de dichas deficiencias para la revisión de cada
artefacto y su correspondiente garantía de calidad se utilizarán las guías de
revisión y checklist (listas de verificación) incluidas en RUP.

● Gestión de Riesgos
 A partir de la fase de Inicio se mantendrá una lista de riesgos asociados al
proyecto y de las acciones establecidas como estrategia para mitigarlos o
acciones de contingencia. Esta lista será evaluada al menos una vez en
cada iteración.

● Gestión de Configuración
Se realizará una gestión de configuración para llevar un registro de los
artefactos generados y sus versiones. También se incluirá la gestión de las
Solicitudes de Cambio y de las Modificaciónes que éstas produzcan,
informando y publicando dichos cambios para que sean accesibles a todos
los participantes en el proyecto.
Al final de cada iteración se establecerá una línea base (un registro del
estado de cada artefacto, estableciendo una versión), la cual podrá ser
modificada sólo por una Solicitud de Cambio aprobada.

3. Capítulo 3: Análisis

3.1. Análisis de Requisitos

Los requisitos funcionales y no funcionales que se detallan a continuación se realizaron
mediante el estándar ISO/IEC/IEEE 29148:2011 Sistemas e ingeniería de software -
Procesos del ciclo de vida - Ingeniería de requerimientos.

3.1.1. Requisitos funcionales

ID RF-1 Tipo de requerimiento Funcional Relacionado Caso de uso

Nombre Solicitar un ambiente disponible

Descripción Capacidad de solicitar un ambiente disponible

Autor Percy Esquieros

Responsable Ingeniero de software

Estabilidad Alta Modificación 29/05/2019 Estado 0%

Fuente Infraestructura

ID RF-2 Tipo de requerimiento Funcional Relacionado Caso de uso

Nombre Generar notificación de solicitud

Descripción Ofrecer notificaciones de pedido a los administradores

Autor Percy Esquieros

Responsable Ingeniero de software

Estabilidad Alta Modificación 29/05/2019 Estado 0%

Fuente Infraestructura
ID RF-3 Tipo de requerimiento Funcional Relacionado Caso de uso

Nombre Ofrecer búsquedas personalizadas

Descripción Búsquedas personalizadas de ambientes

Autor Gustavo Casto

Responsable Ingeniero de software

Estabilidad Media Modificación 29/05/2019 Estado 0%

Fuente Infraestructura

ID RF-4 Tipo de requerimiento Funcional Relacionado Caso de uso

Nombre Ofrecer información detallada del equipamiento del ambiente

Descripción Cada aula cuenta con un equipamiento, capacidad y ubicación específica

Autor Gustavo Casto

Responsable Ingeniero de software

Estabilidad Media Modificación 29/05/2019 Estado 0%

Fuente Infraestructura

ID RF-5 Tipo de requerimiento Funcional Relacionado Caso de uso

Nombre Autorización automática de solicitudes de bajo nivel de importancia

Descripción Ante la posibilidad de que no haya respuesta, esta se realizará automaticamente

Autor Ferdinan Mamani

Responsable Ingeniero de software

Estabilidad Alta Modificación 29/05/2019 Estado 0%

Fuente Infraestructura

ID RF-6 Tipo de requerimiento Funcional Relacionado Caso de uso

Nombre Generar reportes

Descripción Ofrecer reportes de uso, equipamiento y frecuencias de solicitud

Autor Kimberly Villavicencio

Responsable Ingeniero de software

Estabilidad Media Modificación 29/05/2019 Estado 0%

 Fuente Infraestructura

3.1.2. Requisitos no funcionales

Id requisito 01 Tipo requisito Fiabilidad Relacionado Ninguno

Descripción El sistema registrar una reserva con 1 semana de anticipación un auditorio

y las aulas con un dias de anticipacion

Origen/ Autor Fernando Paredes Marchena

Criterio de Reservar un aula y auditorio

aceptación /
Validación

Prioridad 1 Modificación 29/05/2019 Estado 0%

Comentarios Ninguno

Id requisito 02 Tipo requisito Seguridad Relacionado Ninguno

Descripción Los datos de la aplicación solo podrán ser modificados por aquellas
personas autorizadas para ello (Administrador, Recepcionista)
Origen/ Autor
Fernando Paredes Marchena

Criterio de Verificar que la identidad del usuario que intenta ingresar al sistema
aceptación /
Validación

Prioridad 1 Modificación 29/05/2019 Estado 0%

Comentarios Ninguno

Id requisito 03 Tipo requisito Fiabilidad Relacionado Ninguno

Descripción La recuperación frente a fallos del sistema no debe ser mayor a 2 minutos

Fernando Paredes Marchena

Origen/ Autor

Criterio de Medir el tiempo de recuperación en minutos ante una falla

aceptación /
Validación

Prioridad 1 Modificación 29/05/2019 Estado 0%

Comentarios Ninguno
Id requisito 04 Tipo requisito Seguridad Relacionado Ninguno

Descripción La información de los pedidos y servicios se almacena en una base de datos

Fernando Paredes Marchena
Origen/ Autor

Criterio de Almacenar todos los pedidos de reservas

aceptación /
Validación

Prioridad 1 Modificación 29/05/2019 Estado 0%

Comentarios Ninguno

Id requisito 05 Tipo requisito Usabilidad Relacionado Ninguno

Descripción Los colores de la aplicación van acordes con a los colores de las anteriores
páginas de la Universidad
Origen/ Autor Fernando Paredes Marchena

Criterio de Los colores estándares de acuerdo con la universidad

aceptación /
Validación

Prioridad 1 Modificación 29/05/2019 Estado 0%

Comentarios Ninguno

Id requisito 06 Tipo requisito Usabilidad Relacionado Ninguno

Descripción El software deberá funcionar online para visualizar los espacios libres
Marco Llaza
Origen/ Autor

Criterio de Visualizar aulas y auditorios disponibles

aceptación /
Validación

Prioridad 1 Modificación 29/05/2019 Estado 0%

Comentarios Ninguno

Id requisito 07 Tipo requisito Usabilidad Relacionado Ninguno

Descripción El sistema deberá contar con opciones de uso y orden en la muestra de
información.
Origen/ Autor Marco Llaza

Criterio de El sitio web deberá tener una estructura clara, ordenando el contenido y las
aceptación / funciones de la aplicación en pestañas o apartados que abarquen todas las
Validación
funcionalidades disponibles.
Prioridad 1 Modificación 29/05/2019 Estado 0%

Comentarios Ninguno

Id requisito 08 Tipo requisito Seguridad Relacionado Ninguno

Descripción Todos los datos almacenados serán mantenidos en secreto para personas
externas a la empresa, mediante las políticas de seguridad de la empresa
Origen/ Autor Fernando Paredes Marchena

Criterio de Políticas de seguridad

aceptación /
Validación

Prioridad 1 Modificación 29/05/2019 Estado 0%

Comentarios Ninguno

Id requisito 09 Tipo requisito Usabilidad Relacionado Ninguno

Descripción El sistema debe permitir al usuario crear, modificar, eliminar y hacer una
consulta sobre una reserva
Origen/ Autor Fernando Paredes Marchena

Criterio de Políticas de seguridad

aceptación /
Validación

Prioridad 1 Modificación 29/05/2019 Estado 0%

Comentarios Ninguno

3.2. Vistas de los Casos de Uso

3.2.1. Diagramas de los caso de uso
 Imagen 8: Diagrama de Casos de uso

Designación CU01

Nombre Consultar_reserva

Autores Percy Alejandro Esquieros Hermoza

Prioridad Alta

Criticidad El sistema la requiere

Fuente Sistema

Responsable Docente

Descripción El docente ingresa a su solicitud para mostrarla al inspector

Evento Gatillo Posterior a la aprobación de la solicitud

Actores Usuario

Precondiciones Solicitud, Aprobación

Postcondiciones Datos almacenados

Resultado

Escenario Principal Se muestra la información de la solicitud ya aprobada

Escenarios Alternativos 1.Se muestra la información de la solicitud por aprobar

2.Se muestra la información de la solicitud para editar

Escenarios de excepción Ninguno

Cualidades -

Designación CU02

Nombre Crear_reserva
Autores Gustavo Castro Delgado

Prioridad Alta

Criticidad El sistema la requiere

Fuente Sistema

Responsable Docente

Descripción El docente ingresa una solicitud

Evento Gatillo Posterior a la aprobación de inicio de sesión

Actores Usuario

Precondiciones Inicio de sesión

Postcondiciones A la espera de aprobación

Resultado 1. Aprobación
2. Denegación

Escenario Principal Se genera una solicitud de ambiente

Escenarios Alternativos 1.Se ingresa a verificar escenarios disponibles

Escenarios de excepción Ninguno

Cualidades -

Designación CU03

Nombre Modificar_reserva

Autores Kevin Casas Bravo

Prioridad Alta

Criticidad El sistema la requiere

Fuente Sistema

Responsable Docente

Descripción El docente modifica una reserva previamente solicitada

Evento Gatillo Edición de reserva

Actores Usuario

Precondiciones Generar solicitud

Postcondiciones -

Resultado La consulta será editada en cualquier día, hora.

Escenario Principal Se genera una solicitud y se puede editar

Escenarios Alternativos 1.Se cancela la edición

Escenarios de excepción Ninguno

Cualidades -

Designación CU04

Nombre Eliminar_reserva

Autores Ferdinan Mamani Alfaro

Prioridad Alta

Criticidad El sistema la requiere

Fuente Sistema

Responsable Docente

Descripción El docente elimina una reserva previamente solicitada

Evento Gatillo Eliminar reserva

Actores Usuario

Precondiciones Realizar solicitud

Postcondiciones -

Resultado Eliminar la solicitud realizada

Escenario Principal La solicitud está siendo mostrada y está en la espera a una acción

Escenarios Alternativos -

Escenarios de excepción Ninguno

Cualidades -

Designación CU05

Nombre Consultar_reserva

Autores Kimberly Villavicencio

Prioridad Alta

Criticidad El sistema la requiere

Fuente Sistema

Responsable Docente

Descripción El sistema verifica que el solicitante sea Docente o personal

administrativo
Evento Gatillo Posterior a al ingreso como usuario

Actores Usuario

Precondiciones Solicitud, Aprobación

Postcondiciones Si tiene un cargo alto ejm: Vicerector, La aprobación de solicitud es

automática

Resultado

Escenario Principal Se verifica el rango del usuario

Escenarios Alternativos 1.Si es vicerector tendra aprobación automática

2.Para todos los demás usuarios, la aprobación es manual

Escenarios de excepción Los alumnos no pueden solicitar un ambiente

Cualidades -

Designación CU06

Nombre Consulta_disponibilidad

Autores Percy Alejandro Esquieros Hermoza

Prioridad Alta

Criticidad El sistema la requiere

Fuente Sistema

Responsable Docente

Descripción El docente puede realizar una búsqueda y verificar la disponibilidad

del ambiente

Evento Gatillo Busqueda

Actores Usuario

Precondiciones Ingreso usuario

Postcondiciones Datos almacenados

Resultado Ambiente disponible

Escenario Principal Se muestra los ambientes disponibles

Escenarios Alternativos 1.Se muestran datos de ambiente disponible para el día siguiente

Escenarios de excepción Ninguno

Cualidades -

Designación CU07
Nombre Guardar_reserva

Autores Kevin Casas Bravo

Prioridad Alta

Criticidad El sistema la requiere

Fuente Sistema

Responsable Docente

Descripción El docente registra su solicitud

Evento Gatillo Finalización de búsqueda

Actores Usuario

Precondiciones Solicitar ambiente

Postcondiciones Datos almacenados

Resultado Datos almacenados

Escenario Principal Se muestra la información de la solicitud ya aprobada

Escenarios Alternativos -

Escenarios de excepción No se ha procesado su solicitud

Cualidades -

Designación CU08

Nombre Aprobación

Autores Ferdinan Mamani Alfaro

Prioridad Alta

Criticidad El sistema la requiere

Fuente Sistema

Responsable Administrador

Descripción Se aprueba la solicitud

Evento Gatillo Recepción de solicitud

Actores Administrador

Precondiciones Solicitud generada

Postcondiciones Aprobación o negación

Resultado Aprobación o negación

Escenario Principal Aprobación de solicitud

Escenarios Alternativos 1.Se deniega la solicitud
2.Se aprueba la solicitud
3.Se aprueba automaticamente la solicitud

Escenarios de excepción Se deniega la solicitud al no haber respuesta del administrador

Cualidades -

3.3. Vista Lógica

3.3.1. Diagrama de clases

Imagen 9: Diagrama de Clases

Descripción de las clases:
- Aulas: Representan a las aulas que tiene la universidad.
- Horario: Representa los horarios que tienen los alumnos y profesores.
- Cursos: Representan a todos los cursos existentes.
- Administradores: Representan a los administradores que manejan la
infraestructura de la universidad.
- Docentes: Representan a los docentes de la universidad.
- Historial de solicitudes: Solicitudes realizadas por el usuario
- Solicitud: contiene las funciones y enlaces con las otras clases

3.3.2. Diagrama de secuencia

El diagrama de secuencia modela el proceso de gestión de la infraestructura de la
universidad:
 Imagen 10: Diagrama de Secuencia

3.3.3. Diagrama de estado

El siguiente diagrama de estado indica los estados por los que puede pasar el
sistema para saber la disponibilidad de las aulas .

Imagen 11: Diagrama de estado

3.3.4. Diagrama de colaboración
El siguiente diagrama de colaboración modela el proceso de escoger las
preferencias del aula que se necesita y el envío la solicitud para apartar el aula.
 Imagen 12: Diagrama de Colaboración
4. Capítulo 4: Diseño
4.1. Arquitectura Física
En esta arquitectura se podrá trabajar con dispositivos móviles y con computadores, esto
nos permitirá trabajar de la misma forma en ambos. Los elementos son los siguientes:
● Móviles y navegadores: Como usuarios del aplicativo
● Nube: Acceso a internet
● Firewall: Contienen protección contra código malicioso
● Servidor: Proporcionan una conexión segura a la base de datos.
● Base de datos: Se conectará a la bd de la universidad pasando por diversos filtros de
seguridad.

Imagen 13: Arquitectura Física

4.2. Tecnologías utilizadas

Herramientas Descripción

PHP PHP, acrónimo recursivo en inglés de

PHP: Hypertext Preprocessor, es un
lenguaje de programación de propósito
general de código del lado del servidor
originalmente diseñado para el desarrollo
web de contenido dinámico.

SMARTY Smarty es un motor de plantillas para

PHP, es decir, separa el código PHP,
como lógica de negocios, del código
HTML, como lógica de presentación, y
genera contenidos web mediante la
colocación de etiquetas Smarty en un
documento. Se encuentra bajo la Licencia
Pública General Reducida de GNU.

PYTHON Python es un lenguaje de programación

interpretado cuya filosofía hace hincapié
en una sintaxis que favorezca un código
legible. Se trata de un lenguaje de
programación multiparadigma, ya que
soporta orientación a objetos,
programación imperativa y, en menor
medida, programación funcional.

FLASK Flask es un framework minimalista escrito

en Python que permite crear aplicaciones
web rápidamente y con un mínimo número
de líneas de código. Está basado en la
especificación WSGI de Werkzeug y el
motor de templates Jinja2 y tiene una
licencia BSD.

POSTGRESQL PostgreSQL es un sistema de gestión de

bases de datos relacional orientado a
objetos y de código abierto, publicado bajo
la licencia PostgreSQL, similar a la BSD o
la MIT.

JSON JSON es un formato de texto sencillo para

el intercambio de datos. Se trata de un
subconjunto de la notación literal de
objetos de JavaScript, aunque, debido a
su amplia adopción como alternativa a
XML, se considera un formato
independiente del lenguaje.

4.3. Arquitectura Lógica

 Imagen 14: Arquitectura Lógica
4.3.1. Presentación
En la capa de presentación tendremos:
● Para navegadores: TPL (HTML) que nos permite realizar colocar código
dentro de las etiquetas de HTML y poder darle mediante scripts diversas
órdenes o modificar los atributos de los elemento junto a un respectivo archivo
.PHP
4.3.2. Lógica del negocio
En la capa de negocio tendremos:
● La conexión con el servidor de la universidad basado en python usando Flask,
estas se conectan a otros archivos .PHP y transportan la petición desde el
archivo TPL.
● En esta sección se encuentra todo el lógico del programa y está segmentada
de forma en que sea complicado para un atacante llegue hacia ella.
4.3.3. Capa de datos
Tendremos una base de datos externa para respaldar archivos que lleguen
directamente desde el teléfono y posteriormente sean derivados hacia la base de
datos original de la universidad.
5. Implementación
5.1. Configuración Inicial de la Aplicación
5.1.1. Creación de Contenido
5.1.2. Permisos de usuario
5.1.3. Instalación y Configuración de los módulos
5.2. Desarrollo de librerías de comunicación
5.3. Desarrollo de funcionalidades principales
5.3.1. Aplicación web

5.4. Diseño Gráfico

5.4.1. Prototipo inicial

Búsqueda filtrada
Información detallada del ambiente y de la afluencia

Autorespuesta ante tiempo transcurrido

Reporte

Prototipo en la plataforma móvil

6. Pruebas
En esta sección se describen las pruebas que se plantean y se desarrollarán a lo largo del
proyecto antes y durante la misma fase de implementación. Se toma como referencia el estándar
ISO/IEC 29119.
6.1. Plan de Pruebas de Sistemas
Módulo Prueba Descripción

Interfaz Testing Unitario controles Testing individual de cada

control permisible en las
interfaces de usuario ya
sean docentes, alumnos o
administradores.

Interfaz Testing de Integración Testing integral de las

interfaz de usuario interfaces de cada tipo de
usuario para cerciorarse de
la correcta funcionalidad de
la capa de presentación.

Interfaz Testing de Sistema Testing de Sistema,

Interfaz - Procesos de conexión satisfactoria entre
Negocio el uso de la interfaz gráfica
y los procesos de negocio
usables.

Procesos de Negocio Testing Unitario Proceso Testing individual de los

Funcionalidad procesos funcionales de la
capa de procesos de
negocio del sistema de
separación de aulas.

Procesos de Negocio Testing de Integración Testing Integral de los

Procesos según roles conjuntos de procesos
según los roles de usuario.

Procesos de Negocio Testing de Integración Testing Integral de los

suites de usuario suites de procesos que se
utilizan para las
funcionalidades de cada
uno de los tipos de usuario:
docente, alumno o
administrador.

Servicios Principales Testing de Sistema Testing de Sistema,

Procesos de Negocio - conexión y buen uso entre
Servicios los procesos de negocio y
su funcionalidad concreta
con los servicios web
utilizando para el aplicativo.

Servicios Principales Testing Unitario llamada Testing Individual del

Servicio correcto funcionamiento de
llamada y respuesta de los
Servicios implementados
del Servidor Web.

Servicios Principales Testing Integración suite Testing integral de los

de Servicios suites de servicios para
cada rol de usuario:
docente, alumno o
administrador.

Base de Datos Testing Unitario CRUD Testing individual de

 operaciones de CRUD para
cada tabla de datos que se
utiliza y las tablas
transaccionales que
también se posee.

Base de Datos Testing Integración Testing de Integración

Transacciones Datos entres los datos
transacciones generados y
a generar según la
funcionalidad que se
necesite por las llamadas
de los servicios de la capa
de procesos de negocio del
sistema.

6.2. Informe de los resultados de las pruebas

6.3. Descripción de las pruebas
6.4. Resultados esperados
6.5. Resultado obtenido y acciones a tomar para corregir las desviaciones
6.6. Resultados de las pruebas y la documentación