ESPECIFICACIÓN DE REQUERIMIENTOS

Proyecto GestSa
WaitPress

Diego Encina
Bastián Moya
Elder Núñez
Diego Villarroel
 Hoja de Control

Resumen documento La herramienta getsa es un sistema que tiene como finalidad

facilitar y optimizar la reservación de salas de estudio en el nuevo
edificio CIAE de la Universidad de Valparaíso, respondiendo a la
necesidad de la propia comunidad de crear una forma práctica y
eficiente para la utilización de éstas, en busca de una mayor
organización en cuanto a los periodos de uso necesarios para los
usuarios.
Lo que busca el proyecto es una implementación de una
plataforma tecnológica bajo criterios de ingeniería en software
adecuándose a distintos modelos de esta, bajo diagramas de
secuencia con el fin de explicar de forma gráfica y detallada cómo
se comporta dicho sistema.
Dando a conocer el problema puntual del sistema actual de la
reserva de salas y como se puede implementar una mejora.

Autor Elder Nuñez, Diego Villarroel, Diego Encina, Bastián Moya.

Versión 2.0 Fecha Versión 19/07

Revisado/Validado por: Diego Encina Fecha 19/07

Revisión/Validación
Aprobado por: Elder Nuñez Fecha Aprobación 20/07
REGISTRO DE CAMBIOS
Versión Causa del Cambio Responsable del Fecha del Cambio
Cambio
1.1 Renombrar y detallar Diagrama de Elder Nuñez /06
procesos
1.2 Descripción de procesos de Diego Villarroel 10/06
Storyboards
1.3 Diagrama de estados Elder Nuñez 13/06
1.4 Redefinición de restricción y Elder Nuñez 13/06
suposiciones generales
1.5 Descripción de usuarios Diego encina 14/06
1.6 Diagrama de casos de uso Bastián moya 14/06
1.7 Corrección de diagrama de uso 17/06
extendido
1.8 Rediseño de history board Diego Villarroel 19/06
1.9 definir glosario, falta de ortografía Elder Núñez 20/06
y problemas gramaticales
2.0 Modificar roles de participantes Diego Encina 19/07
dentro del sistema

GLOSARIO
término: definición:
Sistema Conjunto ordenado de normas y procedimientos que regulan el
funcionamiento de un grupo o colectividad.
Informática
Página web Conjunto de información que se encuentra en una dirección
determinada de internet.

Serie de viñetas que representan la acción y estructura que debe

Story board seguir una película, una serie televisiva o un anuncio.

Rol Función que una persona desempeña en un lugar o en una

situación
 Include Casos de uso que tienen una parte común en sus
funcionalidades. (carácter obligatorio)
Caso de uso Los Casos de Uso (Ivar Jacobson) describen,
bajo la forma de acciones y reacciones, el
comportamiento de un sistema
extend Comportamiento que es ejecutado solamente bajo ciertas
condiciones. (carácter opcional)

Introducción

Propósito​.

El proyecto GestSa ha enfocado sus recursos en crear una plataforma para la

reservación de salas de estudio en el edificio CIAE de la universidad de Valparaíso. A
través de esta, otorgar la información pertinente acerca de la disponibilidad de las
salas de estudio. De esta forma, el sistema facilitará y optimizará la función que
cumple el administrador en relación a la gestión de las salas que debe realizar, además
de brindar una herramienta eficaz para que los usuarios tengan un mejor uso de los
tiempos. Se medirá el éxito del sistema mediante una encuesta realizada en la misma
plataforma para, de esta forma, obtener la información de los usuarios que intervienen
en el sistema, dando a conocer las fallas o inconvenientes que nuestro sistema pueda
generar.

Identificación de las personas interesadas:

● Clientes : Universidad de Valparaíso
● Usuarios: Académicos, alumnos (pregrado-postgrado), administrador de salas,
auxiliar de mantenimiento de salas.
● Especialistas: Analista, programador, diseñador, administrador.

Alcance:
 Se establece que irá dirigido a alumnos de pregrado, postgrado y académicos que
formen parte de la comunidad de la universidad de Valparaíso. Tendrá un coste de
entrada en función a la recepción que el usuario aprecie en nuestra aplicación web,
que a su vez integrará los costos asociados a la implementación y mantenimiento de la
misma.
El servicio que ofrece esta plataforma en su primera fase de desarrollo, se limitará de
manera única al edificio CIAE, el cual se encuentra bajo el dominio de la Universidad
de Valparaíso. Este servicio contará con una revisión periódica de fallos y errores con
finalidad de mantener un sistema estable y eficiente.

Contexto (Descripción general).

Esta plataforma se sostendrá de forma integral con el apoyo de los servidores y la

base de datos de forma unificada con el fin de identificar al alumno para luego
entregar la información de este mismo, en relación al dominio de la universidad de
Valparaíso, de esta manera el proyecto contará con un respaldo de información. El
tamaño del sistema estará relacionado con el flujo de visitas relacionadas al CIAE, es
decir, en función a la cantidad de personas diarias que tiene el edificio, y para tener
mayor claridad respecto a este punto, se medirá por el casino que recibe en promedio
450 personas al día, gracias a esto se determinará cuantas consultas como mínimo
debe tener el sistema al día.
Como el enfoque estará fijado en relación al edificio CIAE, el servicio otorgado se
basará en la cantidad de salas de estudio disponibles. El edificio cuenta con 7 salas, las
cuales podrán ser visualizadas en la interfaz del sistema, que a su vez, mostrará los
diferentes estados que tendrá la sala, en relación a la concurrencia de usuarios tiempo real.
El sistema trabajará bajo la afirmación de reserva de salas por lo que el usuario
ingresara al sistema a pedir una sala

Análisis de Costos

El costo para realizar una página web es de aproximadamente $160.00. En la cual se

contempla el Dominio (.cl), el hosting por 1 año (100 Correos corporativos, 1Gb DD),
diseño del sitio web, links a redes sociales, posicionamiento SEO (a largo plazo),
formulario de Contacto, Sistema Responsive (Web compatible con: Celulares, tablets,
Ipad, Iphone, etc.), Botón llamado telefónico, sistema de administración para el
administrador del sistema además de realizar una capacitación online para aprender a
administrar el sitio. Este costo solo significa la página web.
 Sumado a esto, el costo de renovación anual del hosting y dominio tiene un valor de
$36.000. (Montos cotizado en tienda de páginas web, sitioswebchile.cl)
Además hay que considerar el equipo físico que se requiere para la implantación de
este sistema, entre los cuales se estiman necesarios:

-Computadores (2) se les asignará un presupuesto de $900.000 c/u (cotizado en retail

de nuestro país).

Por lo que, el costo presupuestado sumaría un monto total de: $1.996.000

aproximadamente.
Cabe destacar que el costo presupuestado podría tender a variar según lo requerido
por el sistema.

2. Definición de requerimientos 
 
Descripción del sistema actual:

El sistema de la gestión está compuesto por un conjunto de funciones que el administrador

debe accionar de manera íntegra y con ello, supervisar y controlar las salas para que tener
garantía del funcionamiento óptimo y con un orden predeterminado. Por ello, para que los
alumnos puedan solicitar una sala deben cumplir con las siguientes condiciones:

1.- Realizar una solicitud con 48 horas de antelación.

2.- Completar la solicitud de reserva y enviarla al correo designado (secretaría
administrativa) indicando los detalles a determinar, vale decir: hora, fecha, nombre,
teléfono, carrera, .Además de esto ir a CIAE el día y confirmarlo.
El sistema de tomas de salas empieza cuando el alumno pide una sala por medio de un
correo
electrónico el cual le llega a la secretaría de prorrectoría ​la cual desarrolla un archivo
Excel con los horarios correspondientes, seguido se lo envía a un ​“Administrador​”, ​el
cual hace los procedimiento correspondientes para gestionar de manera eficientes las
salas de estudio.
Se detectó un problema de visualización el cual se determinó ya que los alumnos al
momento de pedir una sala no saben si están desocupadas o no hasta que van al mismo
 edificio “CIAE” o manden un correo a secretaria de prorrectoria, tras transcurrir las 24
ella les responde si están disponibles o no.
Otro problema es que se topan los alumnos o se pasan de sus horarios correspondientes
teniendo como consecuencia que el desalojo de las salas sea ineficaz, dificultando las
funciones que debe realizar el administrador
desalojo de las salas sea más difícil, pese a que el administrador ​hace lo que está a su
disposición muchas veces se topan horarios por falta de un sistema que permita a los
alumnos comprobar la disponibilidad.

Que se espera con el nuevo sistema:

El sistema permitirá realizar reservas en el momento y con una anticipación, todo esto,
dependiendo la disponibilidad de las salas. Por lo que el sistema estará funcionando las
horas disponibles que se encuentre el edificio. En el sistema existirán 3 roles
fundamentales, los cuales son: el administrador, el usuario y la secretaria de la
Prorrectoría. Los cuales más adelante se les definirán sus respectivos roles.
El sistema dará inicio cuando el usuario pida una sala, ya sea en el momento o con una
reserva previa, se le enviará un mensaje al administrador para que verifique y apruebe la
reserva de la sala, la información de cada alumno se dará a conocer en la página la cual le
brindara al administrador la información necesaria para conocer al usuario registrado.
Para la reserva a largo plazo el administrador podrá ir a la reserva en cuestión y verificar
que la sala en el sistema esté desocupada para luego confirmar esta misma para que
cuando llegue el día verifique si el alumno asistió a dicha sala, si el usuario no asiste el
administrador podrá eliminar dicha reserva.
En el caso que el usuario pida la reserva el mismo día o momento al administrador como
en la reserva de días posteriores podrá determinar si la sala se encuentra disponible y
aceptar o rechazar la petición de la reserva.
El sistema permitirá al administrador en caso de que el usuario quiera una reserva por
medio presencial asignar una reserva al instante. Para esto verifica a través del sistema si
se encuentra disponible o no y hará los procesos correspondientes y normales del
sistema.
En el caso de que el usuario se equivoque al reservar una sala el sistema también brinda
 la opción de eliminar una reserva si es que el usuario se equivoca.
La muestra de tiempo real de las salas se verá reflejado en que el sistema dará a conocer
cuáles son las reservas en la hora actual para ello trabajará con las reservas que los
mismos usuarios han pedido.
elder

​ ​Suposiciones y Dependencias.

- Se asume que el sistema sabrá si el usuario pertenece o no a la universidad.

- El alumno pedirá una sala por el sistema.
- Se asume que los usuarios del sistema deben poseer conocimiento y habilidades
en el ámbito de sus funciones: conocimiento de los procedimientos definidos.
- Se ejecutará desde cualquier navegador.
- El usuario se conocerá como alumno de post y pregrado como también docente por
lo cual la distinción de cada uno de ellos es solo para comprobarlo en la base de
datos la distinción de ellos no es relevante en este caso.
- el sistema mandará un correo que avisara que su reserva ha sido exitosa.
- El administrador reconocerá al usuario por medio de una tarjeta de identificación
esta podrá ser tanto la “cédula de identidad” o “​Tarjeta Universitaria Inteligente”.
- se asume que el sistema o página web estará disponible las horas estipuladas por
el CIAE por lo que son 12 horas y contará con un funcionamiento del 97%.
- Se asume que el sistema guardará las reservas en la nube de la misma universidad.

Restricciones Generales.

1) Solo podrán ingresar al sistema alumnos y académicos de la universidad de

Valparaíso.
2) Trabajar bajo los cambios horarios de chile y las horas de disponibilidad del edificio
CIAE.
3) Para poder realizar la reservación de salas existe un número mínimo y máximo de
personas.
4) El usuario no podrá elegir dos salas a la vez.
5) el usuario solo podrá ocupar una sala por 40 minutos luego de eso se desocupara la
sala
6) las fechas deben tener como forma general “DD-MM-AAAA” “HH24:mi”.
7) El RUN al ser ingresado deberá ir escrito sin puntos y dígitos de verificación
 8) El sistema dependerá la base de datos de la universidad con el fin de determinar si
es alumno de pre y postgrado o profesor, por lo tanto tendrá dependencias.

Requisitos de implementación tecnológicas del sistema :

- Se requiere que el cliente cuente con un sistema Windows 98 o superior, así como con
los equipos de cómputo necesarios para el montaje del sistema de información

- Compatible con los navegadores más usados Chrome, Mozilla Firefox, safari.

- Compatible con los sistemas operativos más usados como Windows, Mac iOS, Linux.

Requerimientos funcionales.
 ID DESCRIPCIÓN ENTRADA PROCESAMIENTO SALIDA CLASIFICACI
ÓN
RF1 confirmar Rut El sistema busca la Si forma parte Obligatorio
usuario información de la base de
personal del usuario datos,
en la base datos de despliega menú
la de reservas.
Universidad de
Valparaíso.
RF2 Fecha actual el sistema Se visualiza las Obligatorio
actualizar calculará la fecha fechas y las
fecha y hora de hoy y la fecha horas.
de 1 semana
después de dicha
fecha
RF3 Buscar salas. El usuario el sistema buscara Se visualiza la Obligatorio
ingresa al menú las salas con y sin disponibilidad
de salas disponibilidad de las salas.
RF4 Modificar Número de sala, El sistema permitirá el Obligatorio.
estado salas fecha y hora modificar el estado administrador
de las salas podrá cambiar
el estado de las
salas
RF5 generar y El usuario El sistema creará un El sistema Obligatorio.
guardar registro generó la registro el cual se guardada el
de salas reserva de sala guardará registro
RF6 eliminar registro El usuario no se El sistema habilitará administrado obligatorio
de salas presentó eliminar un registro r podrá
presencialment eliminar el
e registro de
las salas
RF7 confirmación de El administrador El sistema dará Administrador obligatorio
reserva válido registro como válido la confirma el
de salas reserva registro
RF8 Generar secretaria pide El sistema generará El sistema obligatorio
historial de un registro registro de fecha generará un
reservas
 reservas de solicitada registro de un
salas rango de
fechas
RF9 Desplegar sala usuario El sistema buscará y El sistema obligatorio
selecciona la entregará las salas Permitirá ver
sala las salas
RF1 Mostrar Petición usuario El sistema buscará mensaje hacia obligatorio
0 del usuario. completa pedido la solicitud del el administrador
usuario.
RF1 Mostrar salas usuario El sistema compara visualización obligatorio
2 en tiempo real las salas con los del estado
horarios disponibles de las salas
,los ocupados y
reservados para
determinar y mostrar
las salas en tiempo
real
RF1 Generar administrador, El sistema creará Sala registrada obligatorio
3 reserva usuario una reserva.
de salas

RF1 cancelar Usuario. El sistema eliminará despliegue de obligatorio

4 reserva la sala reservada mensaje de
reserva de
sala eliminada
Requerimientos no-funcionales.

ID DESCRIPCIÓN ENTRADA PROCESAMIENTO SALIDA CLASIFICAC

IÓN
RNF multiplataforma navegador web El sistema debe ser Plataforma de usabilidad
1 compatible con los reserva
distintos sistemas
de
navegación y
sistemas operativos
RNF Tiempo ingreso de los el sistema procesa Ventana obligatoria
2 de datos en no más de 1 orientada a
respuesta segundo la formularios
eficiente. información
RNF seguridad administrador el sistema habilitará cambio de seguridad
3 el cambio de estado de
estado de las salas las salas
solo
para el administrador
RNF enviar mensajes usuario el sistema enviará la ventana de error usabilidad
4 de error razón del error al
usuario
RNF facilidad en el usuario, El sistema debe ser interfaz Portabilidad
5 sistema administrador entendible y atrayente
manejable
RNF capacidad usuario el sistema debe sistema eficiente rendimiento
6 mínima soportar cantidad
mínima de usuarios

personas

RNF soporte de administrador y El sistema deberá Estabilidad de Rendimiento.

7 página usuario ser capaz de estar la página
la mayor parte del
tiempo en
 funcionamiento

Diagrama de Proceso
 Casos de Uso extendidos Más Relevantes.

A continuación, se describen los principales Casos de Uso extendido asociado al

proyecto.

CU-01
Caso de uso Solicitar reserva
Actores Usuario.
Propósito Permite que el usuario complete la ficha de reserva con los
detalles establecidos
Precondición ● Autenticación de usuario
● Disponibilidad de sala
● Sala seleccionada
● Disponibilidad de detalles de reserva
Resumen El sistema debe desplegar una ventana con la ficha de
reserva en la cual se mostrará al usuario las fechas y
horas disponibles, para completar el envío de la solicitud.
Tipo Primario, esencial.
Referencias cruzadas RF1, RF2, RF3, RF9
Curso Normal de Eventos
1. Este caso de uso
comienza cuando usuario
selecciona la
opción reservar sala.
2. El sistema despliega la ficha de
reserva respectiva.
3. El usuario elige la fecha y la hora
óptimas y envía la solicitud
4. El sistema captura la solicitud
enviada.

curso alternativo de sistema

3.1 en caso de que el usuario no elije la fecha el sistema mostrará error
 CU-02
Caso de Uso Registrar reserva
Actores Administrador.
Propósito Permite que el administrador registre las solicitudes de
reserva entrantes.
Precondición ● Autenticación de usuario
● Completar ficha de reserva
● Autenticación de fecha y hora
● Confirmación del administrador

Resumen El sistema debe recibir las solicitudes de reserva entrantes

según los detalles establecidos por el usuario y desplegar
una ventana con los detalles respectivos para la
confirmación del administrador
Tipo Obligatorio - Esencial

Referencias Cruzadas RF4, RF5, RF7, RF10, RF13

Curso Normal de Eventos
Acción de Actor Acción de Sistema
1. Este caso de uso
comienza cuando el administrador
recibe la
solicitud de reserva entrante
2. El sistema debe desplegar la ventana
con los detalles adquiridos en la ficha de
reserva.
3. El administrador debe revisar la
solicitud entrante.
4. El Administrador acepta la
confirmación de la reserva
5. El sistema captura y registra la ficha
de reserva en la tabla de horarios.
Curso Alternativo de Eventos
LA.4: El administrador rechaza la confirmación de la reserva
 CU-03
Caso de Uso Cancelar reserva
Actores Usuario, administrador
Propósito Permite que el usuario y el administrador
puedan cancelar la reserva solicitada.
Precondición ● Autenticación del usuario
● Ficha de reserva completada

Resumen El sistema recibe la solicitud de cancelar y determina que

el usuario pueda o no eliminar una reserva congruente o
no deseada
Tipo Primario - Esencial.

Referencias Cruzadas RF14,RF06

Curso Normal de Eventos
Acción de Actor Acción de Sistema
1. Este caso de uso inicia cuando el
usuario selecciona cancelar
reserva
2.-El sistema
determina algorítmicamente que sala
quiere eliminar el usuario para luego
eliminar la reserva
3.-sistema despliega mensaje
de eliminación de reserva de sala
Curso Alternativo de Eventos
1.2 en caso que el usuario no haya eliminado una reserva no se ejecuta
Diagrama de estados
 Usuarios y Roles
PARTICIPANTES ROLES

Dentro del sistema este usuario registrará la debida reservación que

Administrador los académicos o alumnos realizarán sobre una determinada sala,
gestionando que no ocurran problemas con la reservación.

Existen 3 tipos de usuarios que participarán en el sistema:

Usuarios Académico​​: Como usuario tendrán que ingresar al sistema

registrándose para luego realizar la reservación de sala de estudio
en el horario disponible y que se requiera.

Auxiliar: ​Participará directamente con el mantenimiento adecuado

de las salas de estudio como limpieza, orden o algún imprevisto que
surja en estas.

Alumno: ​Como usuario tendrán que ingresar al sistema

registrándose para luego realizar la reservación de sala de estudio
en el horario disponible y que se requiera.
 Secretaria Registra el historial de las salas ya reservadas, ocupadas o
Prorrectoría disponibles para verificar que los horarios de los
alumnos/académicos no coincidan.

Usuarios\Conocimiento Conocimiento Experiencia Experiencia

Sist. del dominio Tecnológica con el
sistema

Administrador Experto Experto Experto

Académico Intermedio Experto Intermedio

Alumno Intermedio Experto Intermedio

 Auxiliar Intermedio Nada Novicio

Secretaria Prorrectoría Experto Experto Experto

Como comportamiento de los principales usuarios a utilizar el servicio de reservación podemos

encontrar los académicos y alumnos de la universidad de Valparaíso.

Mediante una pequeña encuesta abierta contestada por algunos alumnos de la carrera de
ingeniería en información y control de gestión podemos ver que es lo que quiere el usuario del
sistema y que cambios podría realizar al actual sistema de reservación de salas.

Según los datos arrojados por la encuesta, como primera impresión si bien más de la mitad de los
alumnos encuestados conoce cómo se realiza la reservación de salas de estudios, existe un
porcentaje de alumnos que desconoce este proceso, por lo que se debe realizar una mayor
información sobre cómo se realizan estos procesos. Cabe destacar que al usuario le gustaría un
nuevo sistema de reservación, visualizado en la encuesta.​2

Asimismo, se puede identificar un usuario con alto grado de experiencia tecnológica, demandando
un nuevo sistema de información que denominaron “más instantáneo”, con el objeto de poder
eliminar el proceso de reservación mediante la utilización de correos electrónicos como lo es
actualmente, además de aceptar un nuevo sistema de reservación de salas de estudio a través de
una página web.

2​
https://docs.google.com/forms/d/e/1FAIpQLSfll5gxnbchBod7DsRTsiDibCbbb0HfAOUicLbc5DhleM3tnw/viewan
alyti cs
Storyboards.

Al iniciar la página, se visualizará lo siguiente:

La interfaz de inicio muestra el estado de las salas en tiempo real, aún sin estar identificado.
Mediante el sistema de estados, se busca dar información rápida acerca de la concurrencia de gente en
las salas.
Para ingresar en el sistema, el usuario deberá identificarse en el botón de inicio de sesión, lo que lo
llevará a la siguiente pantalla.
Estos estados son:
Intermedio​​: Estado que muestra que la sala en cuestión cuenta con reservas, pero
todavía tiene periodos disponibles.
Llena​​: Estado que implica que la sala ya encuentra reservada para el periodo actual y
los siguientes.
Libre: ​Estado que muestra la total disponibilidad de la sala en el periodo actual y
siguiente.
Esta pantalla de identificación exigirá la Rut del usuario, registrado en la base de datos de la
universidad.

Si el usuario se encuentra registrado, avanzará a la siguiente pantalla, por el contrario, si el

usuario no pertenece a la base de datos, no podrá seguir con el proceso.

Cuando el usuario ya se encuentra identificado, vuelve a la pantalla de selección de salas para

posteriormente escoger cual será utilizada.
Al ingresar, se desplegará la siguiente ventana, en donde se muestran los periodos en uso que
tiene la sala y por ello también muestra el botón que permite realizar la inscripción a través de la
ficha de reserva.
La ficha de reserva identificará el nombre del usuario en relación al Rut. El usuario deberá seleccionar
la hora óptima en relación al registro de horarios de la sala.
Cuando se haga click en los iconos de fecha u horarios, se desplegará un listado de las horas
disponibles.
El listado permitirá visualizar las horas que se desea seleccionar en el día respectivo, lo que
permitirá completar la ficha de reserva.

Al momento de confirmar la reserva en el botón de “realizar inscripción”, se guardará y se ocupará

el periodo respectivo de la hora en la sala que se hizo la reserva.
Con la reserva ya registrada, se visualizará en el historial de la sala, además de habilitar el botón
que permite eliminar la reserva realizada.

De esta forma, se finalizará el proceso de reserva de salas bajo la mirada del usuario.
Por otro lado, el administrador luego de identificarse en la ventana de la imagen 2, podrá avanzar a
la siguiente pantalla.

A través de esta visualización avanzada del sistema, el administrador tendrá la función de aceptar
o rechazar las solicitudes de reserva entrantes que aparecerán al lado de las salas.
Si es que el administrador desea hacer una revisión a los listados de inscripciones de cada sala, la
plataforma le mostrará el registro pertinente.

De esta forma, el administrador puede enviar el historial a Prorrectoría asociando a las fechas que
le resulte necesario.
Además, el administrador podrá eliminar reservas en el caso de ausencia o cancelación, como
agregar sin necesidad de una solicitud, para quienes opten por ponerse en contacto directamente.
Agentes de riesgos:El porcentaje se dará en torno a el riesgo percibido por el proyecto por lo cual
se determinaron los siguientes porcentajes.
1. Requerimientos incompletos (20%)
2. incompatibilidad en la base de datos (50%)
3. Página inestable(10%)
4. Dependencia del personal(25%)
5. Desconocimiento de tecnologías(5%)
6. Deficiencia en la planeación(3%)
7. Interfaces poco atractivas. (20%)
8. Algoritmos de fuerza bruta(dificultades de lógica)( 5%)
9. Incompatibilidad de interfaces(30%)
10. Usabilidad ineficaz(6%)
11. problemas de rendimiento del equipo del proyecto(2%)
12. Protección insuficiente. (30%)
13. vulnerabilidad en la página.(10%)
14. Costos de adquisición de tecnologías(8%)
15. Baja aceptación del cliente(20%)
16. Bases de datos inestables (5%)
17. Políticas de información (12%)
18. Poca financiación (10%)

1. Pruebas

1.1. Tipos de pruebas a aplicar

Posibles pruebas a ejecutar: “pueden estar sujetas a cambios revisar porfavor”

Prueba unitaria​: Implementaremos las pruebas unitarias ya que ​buscan aislar cada parte del
programa y mostrar que las partes individuales son correctas. Nos referimos a las
partes individuales como a cada proceso que debe realizar el usuario y administrador lo
cual nos permite detectar los errores a tiempo, de forma que podamos reescribir el
código o corregir errores sin necesidad de tener que volver al principio y rehacer el
trabajo. Por último, esto nos ayudaría a disminuir el tiempo y el costo.

Pruebas de regresión​: Se requiere implementar una prueba de regresión para volver a

sistemas anteriores para tener un mejor soporte mientras se trabajan en nuevas
 actualizaciones o ejecutar un debugging1, con el objetivo de resolver problemas de
Programación o soporte.
El objetivo de la prueba de regresión en este sistema es disminuir el error del sistema de
reserva trabajando bajo criterios anteriores para dar un mejor soporte a las
integraciones futuras de diseño, programación, arquitecturas entre otras.

Pruebas de integración​: Se determinó implementar una prueba de integración con el objetivo

de cómo la base de datos de prueba será cargada,respondiendo al riesgo generado
con anterioridad el cual es menester responder,con las leyes actuales los datos para su
protección deberán ser trasladados de manera críptica bajo un código que solo el
software podría leer,con el fin de poder utilizar una base datos para identificar a los
usuarios correspondientes.
Es importante señalar que para no generar un error en la misma reservación de salas se
debe trabajar bajo un sistema de ip de llegada es decir integrar algoritmos capaces de
enumerar la llegada de cada usuario al reservar una sala.

Prueba de Sistemas:

Resistencia: El objetivo de ejecutar una prueba de resistencia es testear la capacidad de la

página con volúmenes altos de datos, conexiones, etc. Para conocer cuál es el
rendimiento frente a una gran masa de datos.
Rendimiento: Mediante esta prueba podemos calcular el tiempo de respuesta de la página
web frente a volúmenes medios de datos, con el objetivo de visualizar cómo está
respondiendo nuestra página cotidianamente.
Seguridad: La seguridad en la página es primordial en el efecto de que si el usuario deberá
pedir una sala y que esta no pueda ser modificada por agentes externos a el
administrador.
Recuperación: El objetivo de hacer pruebas de recuperación es llegar a implantar mejoras y
corregir errores del momento sin la necesidad de dejar inactiva la pagina esto con el fin
de desarrollar una página con una estructura más moldeable.

Pruebas de Aceptación: ​Con el objetivo de la conformidad del usuario la retroalimentación

en función de pruebas es fundamental para determinar el riesgo de las interfaces poco
atractivas con el propósito de generar una conformidad al usuario usando diferentes
interfaces de acuerdo a las necesidades del mismo usuario, como también en abordar
temáticas que el usuario domina.

1
​ ​“​Debugging is the process of detecting and removing of existing and potential
errors”,https://economictimes.indiatimes.com/definition/debugging
 1.2. Plan de pruebas por nivel (unidad, integración)

Tipo de Prueba: Unidad

ID: 1 Nombre: Ingresar al sistema

Probado por: Bastian Moya

Descripción: Se introduce el Rut del usuario para posteriormente asignar su reserva.

Condiciones de Entrada: Usuario registrado exitosamente como estudiante /

académico de la universidad de Valparaíso.

Resultado Esperado: El sistema confirma el ingreso del usuario mediante la base de

datos de la universidad.

Tipo de Prueba: Unidad

ID: 2 Nombre: Solicitar reserva.

Probado por: Bastian Moya

Descripción: El sistema solicita rellenar los datos requeridos para reservar la sala.

Condiciones de Entrada: Se introducen todos los datos requeridos para la reserva de

sala, tanto como fecha, hora y sala a ocupar.

Resultado Esperado: El sistema confirma la sala de reserva con la hora, dia y sala
estipulada por el usuario.
 Tipo de Prueba: Unidad

ID: 3 Nombre: Eliminar registro

Probado por: Diego Encina

Descripción: El administrador podrá eliminar o cancelar la reservación de la sala de

estudio si el usuario no llega a ocupar la sala.

Condiciones de Entrada: Usuario registrado exitosamente asignando su sala

correspondiente no asiste el día que era su reserva .

Resultado Esperado: El administrador por medio del sistema cancela la reservación,

eliminando esta reserva del historial y muestra la sala antes reservada como
“disponible”.

Tipo de Prueba: Unidad

ID: 4 Nombre: Visualización de salas en tiempo real

Probado por: Diego Encina

Descripción: El sistema arroja las salas con los horarios disponibles, ocupadas y
reservados para determinar y mostrar la situación de las salas en tiempo real.

Condiciones de Entrada: Usuario registrado exitosamente como

estudiante/académico de la universidad de Valparaíso mediante su rut,
solicitando la visualización en tiempo real de salas de estudio.
 Resultado Esperado: El sistema arroja la situación actualizada o “en tiempo real”
sobre las salas de estudio exitosamente.

2. Riesgos

2.1. Tabla estimación de Riesgos

Categorías Posibles:
Tamaño del producto​:Tamaño del SW a construir.
Impacto en el negocio:​Limitaciones impuestas por la gestión o por el mercado.
Características del cliente​.:Sofisticación del cliente.
Definición del proceso​:Grado de uso de metodologías de la organización.
Entorno de desarrollo​:Disponibilidad y calidad de herramientas de desarrollo de software.
Tecnología a construir:​Complejidad del sistema a construir.
Tamaño y experiencia de los desarrolladores​:Experiencia técnica y documentación anterior de los
ingenieros de SW que van a realizar el trabajo

​ En base a lo expuesto con anterioridad se expuso de acuerdo a nuestros factores de riesgos los
que son más importantes y en base a esos factores se determinó escoger los riesgos con los
factores más altos que se da a conocer en el siguiente orden.
1. 10% ! muy bajo
2. 10-25% ! bajo
3. 25-50%! moderado
4. 50-75% ! alto
5. >75% ! muy alto

Riesgo Categoría Probabi Magnitud de Exposición RSGR

lidad de la pérdida al riesgo
pérdida (semanas) (semanas)
Requerimientos TP 20% 2 0.4 A1
incompletos

Incompatibilidad ED 30% 3 0.9 A2

de interfaces

incompatibilidad ED 50% 3 1.5 A3

en la base de
datos

Interfaz de CC 20% 1 0.2 A4

usuarios poco
atractivas
vulnerabilidad TC 40% 4 1.6 A5
en la página

Dependencia IN 25% 1 0.25 A6

del personal

Baja CC 20% 2 0.4 A7

aceptación
del cliente

Se determinó que uno de los factores más importantes es la incompatibilidad de la base de datos
ya que producto de la ley de protección de datos será difícil el traspasar los datos de los usuarios
de la universidad por ende se les asignó un porcentaje mayor el cual es un 50%,seguido de eso
la vulnerabilidad de la página es un factor clave al igual que la seguridad de la misma ya que en
torno a la petición de salas debe estar bien restringido el rol de cada usuario por ende un usuario
deberá hacer su correspondido proceso y no cambiar el estado de las salas como lo haría el rol
de un administrador.
 En forma más gráfica se llegó a que uno de los factores claves a la hora de tener que enfrentar
el riesgo es un entorno de desarrollo como también tecnologías a construir esto es producto de
los altos valores correspondientes .

Al Se sumar todas las exposiciones al riesgo se llegó al siguiente valor :4.44 semanas lo que es
equivalente a 4.4 semanas aproximada.Siguiendo la lógica en semanas se estima el costo por el
trabajo asociado a este expresados en pesos chilenos por mes para luego hacer luego la
conversión
1. Encargado del proyecto: De $1 millón 200 mil a $1 millón 300 mil(universidad central de chile)
2. analista de software:
3. Dos Programadores(se de a entender como dos programadores ya que uno implicaría ser un
tester en esta suposición): De $1 millón 600 mil a $1 millón 700 mil a mes (univesidad de
santiago)
4. Arquitecto :De $800 mil a $900 mil Universidad Tecnológica Metropolitana.

Esta suposición se basa en un trabajo de inicio el cual busca desarrollar la página de

reserva de salas asumiendo el riesgo asociado a 4.44 semanas de retraso se concluyó
que aproximadamente representa un gasto de 5.250.000 pesos chilenos. por las 4
semanas concluyendo que estas se paguen a corde a 1 mes.

2.2. Supervisión de Riesgos más importantes:

 Retomando en las categorías anteriores se llegó a la conclusión de que los riesgo dentro de
estas era “incompatibilidad en la base de datos” como también “incompatibilidad de
interfaces” todo esto es producto de la poca experiencia que se genera muchas veces ya
sea por el hecho de una mala interpretación en los requerimientos como también la mal
ejecución en un algoritmo clave.
Estos problemas se consideran importantes ya que se trabajara con un sistema de cobertura
en tiempo real el cual necesita de exactitud para determinar qué sala se encuentra
disponible.
Se supuso que el riesgo de compatibilidad de interfaces puede determinar un error mucho
mayor en la ejecución del sistema en tiempo real haciendo que este error, lleve a un
error crítico en la toma de salas.

En una segunda categoría se encuentran “riesgos a construir” consecuentemente se

requeriría un análisis del riesgo de este mismo tomando en consideración el riesgo de
mayor ponderación,por lo que se tomó en cuenta la vulnerabilidad de la página ya que
la página deberá tener mecanismo de seguridad para no ocasionar entradas
malintencionadas como también la interconección de otros usuarios que lleve a atribuir
roles del administrador a los mismos , otro punto importante es la estabilidad de reserva
de salas es decir su permanencia en la red al planear ser una página en torno al servicio
de el edificio debe estar disponible la mayor parte del tiempo o el tiempo que requiera
estar conectada.

EL PLAN DE REDUCCIÓN, SUPERVISIÓN Y

GESTIÓN DEL RIESGO (RSGR).

HOJA DE
INFORMACIÓN DEL
RIESGO

Magnitud de
ID Riesgo:A3 Fecha Probabilidad pérdida Exposición al riesgo
Descripción:Se percató
este riesgo producto que 17/07/2018
la información de los 50% 3 1.5
usuarios no se puede
compartir información
privada.

Refinamiento/contexto:Dado el contexto externo de la ley de Derecho a la Privacidad; Ley no.

19.628, los datos no se pueden dar a conocer los datos de cada usuario.

Reducción/Supervisión

1-Se estima que la reducción de este riesgo se basa en compartir los datos por medio de datos
encriptados ,por lo que solo podrá leer o interpretar el código un algoritmo de la página de
reserva de salas .

Gestión/Plan de Contingencia:
Lo que se busca hacer es generar datos encriptados con el fin de que ningún usuario sea capaz
de averiguar o malversar datos de el mismo como ajenos a él mismo, todo esto con el fin de
poder identificar al usuario para poder determinar que el usuario en cuestión solicitó la sala

Estado Actual:
En estudio.

Asignado a: Programador.
Autor:Elder Nuñez

HOJA DE
INFORMACIÓN DEL
RIESGO
 Magnitud de
ID Riesgo:A2 Fecha Probabilidad pérdida Exposición al riesgo
Descripción:
Incompatibilidad de 17/07/2018
interfaces
tipo:ED 30% 3 0.9
Refinamiento/contexto: dada la condición de incompatibilidad de interfaces existe una
preocupación de no poder interactuar con algunas funciones por lo que provocaría un sistema
ineficaz en la toma de salas

Reducción/Supervisión
el plan para reducir el riesgo es crear backups como también pruebas que requieran de una
revisión constante.

Gestión/Plan de Contingencia:
si el riesgo se convierte en realidad utilizar los backups anteriores para poder regresar versiones
anteriores

Estado Actual:

Autor:
Asignado a:

HOJA DE
INFORMACIÓN DEL
RIESGO
 Magnitud de
ID Riesgo:A2 Fecha Probabilidad pérdida Exposición al riesgo
Descripción:
Incompatibilidad de
interfaces 17/07/2018
tipo:ED 30% 3 0.9
Refinamiento/contexto: dada la condición de incompatibilidad de interfaces existe una
preocupación de no poder interactuar con algunas funciones por lo que provocaría un sistema
ineficaz en la toma de salas

Reducción/Supervisión
el plan para reducir el riesgo es crear backups como tambien pruebas que requieran de una
revision constante.

Gestión/Plan de Contingencia:
si el riesgo se convierte en realidad utilizar los backups anteriores para poder regresar versiones
anteriores

Estado Actual:

En estudio.

Autor:
Asignado a:

HOJA DE
INFORMACIÓN DEL
RIESGO
 Magnitud de
ID Riesgo:A5 Fecha Probabilidad pérdida Exposición al riesgo
40% 4 1.6
Descripción: vulnerabilidad 17/07/2018
de la página
tipo:TC
Refinamiento/contexto:
dado que la página no se encuentra bajo protocolos de seguridad mucho mayor la pagina debe
tener mecanismos de control más eficientes como los son los controladores de captchas2 entre
otros

Reducción/Supervisión

Para evitar esta amenaza se debe hacer pruebas de testeo y definir parámetros de dominio
dependiendo del usuario.

Gestión/Plan de Contingencia: si se convierte en realidad regresar a las versiones anteriores

para poder determinar el error sin necesidad de bajar la página entera

Estado Actual:

En estudio.

Autor:
Asignado a:

3. Proceso de desarrollo:
- MODELO ESPIRAL:

2
Para complementar ingresar a
http://accesibilidadweb.dlsi.ua.es/?menu=que-es-un-captcha-problemas-accesibilidad
La metodología fundamental que fue utilizada para llevar a cabo el proyecto fue de espiral, puesto
que esta presenta un modelo más adaptable en relación a los factores importantes a considerar
respecto al negocio, es decir que las características que plantea permiten abordar los
componentes clave para implementar un modelo de desarrollo iterativo que a su vez conserve una
relación mucho más cercana a las necesidades del cliente a través de la evolución del producto,
dado que de esta manera, al ser una plataforma en constante uso, los riesgos asociados al
sistema pueden ser analizados, y por ende corregidos a través de la naturaleza iterativa de esta
metodología.

En conjunto con la realización del proyecto se establecieron cuatro pasos que funcionan como
pilares a la hora de analizar los puntos neurálgicos en los cuales es necesario enfocarse.

- Determinar los objetivos: De esta forma se deja establecido el público objetivo al cual está
dirigido la plataforma, y por consiguiente se procede a determinar las restricciones asociadas
al mismo. A su vez, para lograr definir el dominio...

- Análisis del riesgo: En función de los tipos de riesgos asociados, se efectuó una
categorización de los riesgos que presentan un mayor grado de daño, y de esta forma
analizar el entorno en donde el proyecto se desarrolla, para definir de manera más precisa
que requisitos abordar para disminuir la pérdida de recursos.

- Desarrollo: mediante distintas matrices se llegó a verificar que riesgos tenían un mayor rango
de probabilidad por medio de una hoja de información del riesgo con el fin de determinar cuál
sería su efecto

- Planificar: Se determinó a través de las pruebas, las formas más efectivas para mitigar los
distintos factores mencionados con anterioridad, aprovechando el modelo iterativo para que
la construcción de la plataforma fuera más eficiente, implementando interfaces de usuario de
enfocada en la usabilidad del usuario, consecuentemente se procedió a definir que procesos
era necesario mejorar y ajustando los detalles en relación a lo se quiere lograr. En
consecuencia el resultado permitió desarrollar un sistema que permite reservar salas por
medio de una página web, el cual será una forma rápida de acceder a ella sin la necesidad
de ser descarga para obtener una fidelización mucho más adaptable, siguiendo con un
modelo iterativo se quiere lograr que en iteraciones próximas la página web pueda ser
compatible con cualquier tipo de móvil esto asumiendo un riegos de un gasto mucho mayor
en el presupuesto ,tiempo y programación estos se irán combatiendo a medida de una
plática con el mismo cliente por medio de una definición de los mismos objetivo de interés de
este.
Se determinarán gracias al modelo tareas primordiales:

Comunicación con el cliente: para entablar una comunicación acorde con el cliente se determinó
dos modos los cuales son por medio de encuestas o Delphi de los mismos integrantes del
proceso para luego determinar qué procesos ir evolucionando.
Planificación: La planificación se determinará mediante los objetivos del cliente y los riesgos
asociados a sus objetivos
Ingeniería: en base a la iteración se crearán distintos moldes para llegar a una interfaz de usuario
mucho más atractiva.
Construcción y adaptación: el modelo permitirá ensayar y corregir los errores presupuestados con
anterioridad
Evaluación el cliente: la evaluación se determinará al final del proceso de la página de reservas
asumiendo que un “tester” determinará si los objetivos son cumplidos.
WebGrafía:
https://www.leychile.cl/Navegar?idNorma=141599
https://www.owasp.org/images/5/5e/OWASP-Top-10-2017-es.pdf
https://www.owasp.org/index.php/Main_Page
http://www.ojovisual.net/galofarino/modeloespiral.pdf
http://sofware1nathalygrijalva.blogspot.com/2012/10/modelo-espiral.html
https://www.iebschool.com/blog/app-sitio-web-movil-mobile-marketing/