TECNOLOGICO DE ANTIOQUIA

PROYECTO INTEGRADOR
NIVEL IV

FACULTAD DE INFORMATICA

πiensa

FICHA ENTREGA # 1

PABLO SALDARRIAGA
MATEO ZAPATA E

Semestre 02/2017
2 Entregable II

Contexto del Software

Área del problema.

Objetivos y Responsabilidades propias del Área.

Afianzar los conocimientos del alumnado por medio de una aplicación que
estimule y desarrolle las habilidades en el área de matemáticas de cada uno de
los alumnos al interactuar con ella y a un ritmo propio.
Es por esto que el temario del área en su respectivo curso estará a disposición
del alumnado en el aplicativo desde el primer uso de este.

Organigrama del Área.

Actores y sus Roles

Actor Alumno: Es a quien va dirigida la aplicación siendo este responsable de
prestar atención en clase, estudiar los temas y realizar las actividades
designadas en las respectivas materias de su grado.
Actor Profesor: Es quien establece el temario de cada una de las materias que
ve el alumnado a su vez que los instruye en estas, siendo este responsable por
el desarrollo del alumnado dentro de la institución
Actor Administrativo: Se encuentra encargado tanto de profesores como de
alumnos y es quien vela por el correcto funcionamiento y mantenimiento de la
institución. Se encarga de labores administrativas y de enlace entre la
institución y la comunidad
 Entregable II
3
Análisis del Problema.

Procesos del Área.

4 Entregable II
 Entregable II
5

Descripción del Problema

En base al diagrama de procesos anterior se evidencia que al usar métodos alternativos en la enseñanza se puede reforzar el
conocimiento adquirido en clase a la vez que el alumno podrá adelantar temas en el área que lo ayudaran más adelante en el
área.
6 Entregable II
 Propuestas de Solución

Introducción.

La aplicación Piensa se encuentra enfocada inicialmente como una herramienta interactiva que complementara el proceso de
enseñanza por parte de los profesores en el área de matemáticas al alumnado, siendo este instruido en el uso de la
aplicación y responsable por su progreso en esta.
Debido al alto número de alumnos por profesor se hace evidente la necesidad de apoyar la instrucción del área de matemáticas
mediante el uso de metodologías alternativas que faciliten el entendimiento de los alumnos.
Con esta aplicación se pretende abarcar todos los cursos del área de matemáticas de la institución Presbítero Bernardo Montoya
inicialmente y esperar un impacto positivo en el alumnado.

Alcance de la solución
El sistema está pensado para que logre acaparar a los alumnos de todos los cursos de la institución y así pueda presentar
soluciones a los problemas de los estudiantes a través de los temarios y ejercicios con fácil acceso que en este se exhiben
Casos de Uso.

Caso de uso
Inicio de sesión
Código caso de uso
 9

CU01
Código Requisito asociado
RF01
Descripción
Pantalla de inicio de sesión que permitirá ingresar a los usuarios registrados al
sistema para hacer uso de él condicionado al tipo de usuario que sea. También
cuenta con un registro para nuevos usuarios.
Diagrama del caso de uso

Actor Descripción de sus responsabilidades

Profesor / Estudiante Profesor / Estudiante: Brinda los datos
 pertinentes para autenticarse y entrar al
sistema si ya se encuentra registrado en
caso contrario podrá registrase en el
sistema ingresando su información
personal.
Brinda los datos pertinentes de
Administrador autenticarse y entrar en el sistema. Le
es posible crear nuevos usuarios

Precondiciones
El Administrador, profesor o estudiante que va a ingresar al sistema debe estar
registrado para su respectiva autenticación.
El Administrador, profesor o estudiante debe autenticarse.
Postcondiciones
Almacenamiento en base de datos
Los actores que hacen uso del registro de nuevo usuario serán incluidos en la
basa de datos del sistema provisionalmente y aparecerán en sus respectivos
listados para verificación tras 1 minuto.

Flujo primario
1. El actor (Administrador, Estudiante o Profesor) ingresa al sistema con su
respectiva clave y usuario, posteriormente se valida la existencia en el sistema de
este y se validan los permisos de acceso.
 11

Registro nuevo usuario

1. El actor se registra en el sistema proporcionando un nombre de usuario y
contraseña para uso personal.
2. El actor ingresara la información personal requerida por el sistema y necesaria
para su registro.
3. El actor recibirá un correo de validación tras ingresar los datos requeridos por el
sistema para su registro.
4. Tras validar el correo el usuario podrá ingresar al sistema con normalidad.

Flujos alternos
El usuario existe:
1. El actor ingresa al sistema con su respectiva clave y usuario.
2. El actor ingresa satisfactoriamente al sistema.

Relaciones de comunicación (include y extend):

Include: Validar existencia (Administrador, Estudiante o Profesor) en el sistema.
Include: Validar permisos de acceso (Administrador, Estudiante o Profesor).
Supuestos:
Debe haber una validación sobre el campo Usuario cuando se va a realizar el
registro, que permita determinar si ya existe o no.
Requerimientos Especiales
N/A.
Reglas de negocio
Se debe enviar un correo al Profesor, informando que se registró un nuevo alumno
en determinado grado a su cargo.
 13

Caso de uso
Registro de usuario
Código caso de uso
CU02
Código Requisito asociado
RF02
Descripción
Permitirá el registro de nuevos usuarios tras su posterior validación en la base de
datos del sistema al igual sus permisos de acuerdo al tipo de actor que se registra.
Diagrama del caso de uso

Actor Descripción de sus responsabilidades

Podrá crear nuevos usuarios de tipo
Administrador
administrador, profesor o estudiante
Profesor Podrá registrarse como profesor y registrar
estudiantes si dispone de los datos
correspondientes a cada uno de ellos por el
 15

sistema para su posterior verificación y

validación.
Podrá registrarse como alumno y deberá
Alumno ingresar la información requerida por el
sistema.

Precondiciones
El Administrador que va a manipular el sistema debe estar registrado.
El Administrador debe autenticarse.
Los Profesores que van a manipular el sistema deben estar registrados
Los profesores deben autenticarse.
Postcondiciones
Almacenamiento en base de datos
Los actores que hacen uso del registro de nuevo usuario serán incluidos en la basa de
datos del sistema y aparecerán en sus respectivos listados para verificación tras 1
minuto.
Flujo primario
1. El actor (Administrador) ingresa al sistema con su respectiva clave y usuario,
posteriormente se valida la existencia en el sistema de este, y se validan los permisos de
acceso.
2. El actor (Administrador) validara los permisos de nuevos usuarios tipo profesor de
haber alguno.
3. El actor (Administrador) Podrá crear nuevos usuarios del tipo profesor o alumno de
ser necesario.
4. El actor (Profesor) ingresara la información requerida para su posterior verificación y
validación de permisos.
5. El actor (Alumno) ingresara la información requerida para su registro para posterior
verificación vía correo electrónico.
Flujos alternos
El usuario existe:
1. El actor (Estudiante o Profesor) ingresa la información requerida de usuario.
2. Si el usuario ya se encuentra en el sistema se informará por pantalla que dicho usuario
ya se encuentra registrado.
Relaciones de comunicación (include y extend):
Include: Validar existencia (Administrador, Estudiante o Profesor) en el sistema.
Include: Validar permisos de acceso (Administrador o Profesor).
Include: Verificar existencia (Usuario) en el sistema.
Extend: Ingresar nuevo registro de usuario en la base de datos del sistema
Supuestos:
Debe haber una validación sobre el campo Usuario cuando se va a realizar el registro,
que permita determinar si ya existe o no.

Requerimientos Especiales
N/A.
Reglas de negocio
 17

Se debe enviar un correo al Administrador cada vez que se registra un nuevo profesor
para validar los respectivos permisos dentro del sistema.
Se debe enviar un correo al Profesor, informando que se registró un nuevo alumno en
determinado grado a su cargo.
Caso de uso
Validación de la información
Código caso de uso
CU03
Código Requisito asociado
RF03
Descripción
Se verificará la información suministrada en cada uno de los nuevos usuarios que se
registren en el sistema para su posterior inclusión en la base de datos del sistema.
Diagrama del caso de uso
 19

Actor Descripción de sus responsabilidades

Deberá verificar el tipo de usuario y otorgar
Administrador los respectivos permisos dentro del sistema de
tener alguno.
Deberá verificar que cada usuario estudiante
Profesor
nuevo se encuentre en su respectivo grado.
Precondiciones
El Administrador que va a manipular el sistema debe estar registrado.
El Administrador debe autenticarse.
El profesor que va a verificar un listado de estudiantes debe estar registrado.
El Profesor debe autenticarse.
Postcondiciones
Los profesores tras ser verificados por un administrador recibirán permisos dentro del
sistema para crear o modificar su contenido.
Flujo primario
1. El actor (Administrador) ingresa al sistema con su respectiva clave y usuario,
2. El actor (Administrador) verificara la información suministrada por parte de un nuevo
usuario.
3. El actor (Administrador) otorgara los permisos de nuevos usuarios tipo profesor de
haber alguno tras verificar la información.
3. El actor (Profesor) verificara la información suministrada por parte de un nuevo
usuario.
Flujos alternos
El usuario ya existe:
1. El actor (Administrador) contrastara la información ingresada con el personal de la
institución antes de validar un usuario.
2. El actor (Profesor) contrastara la información ingresada por el nuevo usuario con la
lista de estudiantes a su cargo.
Relaciones de comunicación (include y extend):
Include: Validar existencia (Administrador, Estudiante o Profesor) en el sistema
Include: Verificar existencia y tipo (Usuario) en el sistema por parte de un
administrador.
Include: Validar permisos de acceso (Profesor).
Extend: Ingresar nuevo registro de usuario en la base de datos del sistema
Supuestos:
El administrador debe estar en el sistema para otorgar los permisos correspondientes.
El profesor debe estar en el sistema para verificar la información de los estudiantes a
su cargo.
Requerimientos Especiales
Los permisos para el actor profesor deben ser validados por un administrador.
Reglas de negocio
Se debe enviar un correo a cada usuario nuevo tras la verificación de sus datos
informándole que tipo de usuario es en el sistema y con qué permisos cuenta.
 21

Caso de uso
Uso de la base de datos por parte del usuario
Código caso de uso
CU04
Código Requisito asociado
RF04
Descripción
Permitirá el registro de nuevos usuarios en la base de datos del sistema y otorgar
permisos de acuerdo al tipo de actor que sea.
Diagrama del caso de uso
 Actor Descripción de sus responsabilidades
Podrá crear nuevos usuarios de tipo
Administrador
administrador, profesor o estudiante
Podrá registrarse como profesor y deberá
Profesor ingresar su información requerida por el
sistema para su posterior validación.
Podrá registrarse como alumno y deberá
Alumno ingresar la información requerida por el
sistema/

Precondiciones
El Administrador que va a manipular el sistema debe estar registrado.
El Administrador debe autenticarse.
 23

Los Profesores y estudiantes que usaran el sistema deben estar registrados

Postcondiciones
Almacenamiento en base de datos
Los actores que hacen parte de la base de datos de usuarios del sistema tendrán
acceso a él desde la pantalla de inicio de sesión tras su autenticación y cada uno
con sus respectivos permisos y restricciones.
Flujo primario
1. El actor (Administrador, estudiante o profesor) ingresa al sistema con su
respectiva clave y usuario, posteriormente se valida la existencia en el sistema de
este, y se validan los permisos de acceso.
2. Tras el inicio de sesión exitoso los actores estarán interactuando con la base de
datos del sistema
Flujos alternos
El usuario no se encuentra:
1. El actor (Estudiante o Profesor) ingresa la información requerida de usuario.
2. Si el usuario no se encuentra en el sistema se informará por pantalla que dicho
usuario no se encuentra registrado.
Relaciones de comunicación (include y extend):
Include: Validar existencia (Administrador, Estudiante o Profesor) en el sistema.
Include: Validar permisos de acceso (Administrador o Profesor).
Supuestos:
Debe haber una validación sobre el campo Usuario cuando se va a realizar el
registro, que permita determinar si ya existe o no.
Requerimientos Especiales
N/A.
Reglas de negocio
Luego de un inicio de sesión exitoso el actor interactuara con la interfaz del
sistema y por consiguiente con la base de datos.

Caso de uso
Mostrar temario y actividades de acuerdo al usuario
Código caso de uso
 25

CU05
Código Requisito asociado
RU05
Descripción
Se permitirá a los usuarios autorizados ver e interactuar con el temario y las diferentes
actividades propuestas en mayor o menor medida de acuerdo a los permisos del
usuario.
Diagrama del caso de uso

Actor Descripción de sus responsabilidades

Podrá ver y crear nuevos contenidos en el
Administrador temario de cada grado y sus respectivas
actividades.
 Podrá ver y crear nuevos contenidos en el
Profesor temario de cada grado y sus respectivas
actividades.
Podrá ver e interactuar únicamente con el
Alumno temario y actividades del grado al que
pertenece.

Precondiciones
El Administrador que va a interactuar con el sistema deberá estar registrado y
autenticarse.
El Profesor que va a interactuar con el sistema deberá estar registrado y
autenticarse.
El Estudiante que va a interactuar con el sistema deberá estar registrado y
autenticarse.
Postcondiciones
Almacenamiento en base de datos
Las actividades realizadas junto con el progreso en el temario se guardaran en el
registro respectivo de cada usuario en la base de datos tras 1 minuto.
 27

Flujo primario
1. El actor (Administrador) ingresa al sistema con su respectiva clave y usuario,
posteriormente se valida la existencia en el sistema de este, y se validan los
permisos de acceso.
2. El actor (Administrador) validara los permisos de nuevos usuarios tipo profesor
de haber alguno.
3. El actor (Administrador) Podrá crear nuevos usuarios del tipo profesor o alumno
de ser necesario.
4. El actor (Profesor) ingresara la información requerida para su posterior
verificación y validación de permisos.
5. El actor (Alumno) ingresara la información requerida para su registro para
posterior verificación vía correo electrónico.
Flujos alternos
El usuario existe:
1. El actor (Estudiante o Profesor) ingresa la información requerida de usuario.
2. Si el usuario ya se encuentra en el sistema se informará por pantalla que dicho
usuario ya se encuentra registrado.
Relaciones de comunicación (include y extend):
Include: Validar existencia (Administrador, Estudiante o Profesor) en el sistema.
Include: Validar permisos de acceso (Administrador o Profesor).
Include: Verificar existencia (Temario) en el sistema.
Include: Verificar existencia (Actividades) en el sistema.
Supuestos:
Los usuarios tienen mayor o menor acceso a las funcionalidades del sistema de
acuerdo al tipo que este sea.
Requerimientos Especiales
N/A.
Reglas de negocio
Cada tipo de usuario tiene un menú de acciones con relación a sus permisos dentro
del sistema.

Caso de uso
Edición de temas y actividades.
Código caso de uso
CU06
Código Requisito asociado
RF06
Descripción
Se permitirá a los usuarios autorizados editar el temario y las actividades propuestas
para la aplicación permitiendo añadir o borrar el contenido.
Diagrama del caso de uso
 29

Actor Descripción de sus responsabilidades

Profesor / Administrador: Brinda la nueva
Administrador / Profesor
información, crea o modifica los datos.

Precondiciones
El Administrador o profesor que va a manipular el sistema debe estar registrado.
El Administrador o profesor debe autenticarse.
Postcondiciones
Almacenamiento en base de datos
El temario modificado o añadido debe ser almacenado en la base de datos y
dispuesto al público luego de 1 minuto.
Flujo primario
1. El actor (Administrador o Profesor) ingresa al sistema con su respectiva clave y
usuario, posteriormente se valida la existencia en el sistema de este, y se validan
los permisos de acceso.
2. El actor (Administrador o Profesor) verifica la existencia del temario.
3. El actor (Administrador o Profesor) ingresa al sistema los cambios o el nuevo
contenido que desea realizar.
4. El actor (Administrador o Profesor) guarda el nuevo temario.
Flujos alternos
El Temario existe:
1. El actor (Administrador o Profesor) ingresa al sistema con su respectiva clave y
usuario.
2. El actor (Administrador o Profesor) verifica la existencia del temario.
3. Si el temario se encuentra en el sistema se informará por su pantalla todo lo
relacionado con este.
Relaciones de comunicación (include y extend):
Include: Validar existencia (Administrador o Profesor) en el sistema.
Include: Validar permisos de acceso (Administrador o Profesor).
Include: Verificar existencia (Temario) en el sistema.

Supuestos:
Debe haber una validación sobre el campo Temario cuando se va a realizar la
edición, que permita determinar si existe o no.
Requerimientos Especiales
N/A.
 31

Reglas de negocio
Se debe enviar un correo al Administrador, informando que se realizó en el
sistema una modificación del temario.

Caso de uso
Edición de listas de usuarios por grado.
Código caso de uso
CU07
Código Requisito asociado
RF07
Descripción
Realizar modificación o eliminación de un usuario en su respectivo grado
Diagrama del caso de uso

Actor Descripción de sus responsabilidades

Administrador: Creación, modificación de
Administrador
datos

Precondiciones
El Administrador que va a manipular el sistema debe estar registrado.
 33

El Administrador debe autenticarse.

El Administrador debe contar con los permisos necesarios
Postcondiciones
Actualización de la base de datos.

Flujo primario
1. El actor (Administrador) ingresa al sistema con su respectiva clave y usuario,
posteriormente se valida la existencia en el sistema de este, y se validan los permisos de
acceso.
2. El actor (Administrador) verifica la existencia de la lista en el sistema.
3. El actor (Administrador) ingresa al formulario de modificación de la lista.
4. El actor (Administrador) realiza la actualización de los campos.
5. El actor (Administrador) puede eliminar un registro de usuario del sistema.
6. El actor (Administrador) guarda los cambios sobre el registro o eliminación del usuario.
Flujos alternos
El Usuario existe:
1. El actor (Administrador) ingresa al sistema con su respectiva clave y usuario.
2. El actor (Administrador) verifica la existencia del temario.
3. Si el usuario se encuentra en el sistema se informará por su pantalla todo lo relacionado
con este.
Relaciones de comunicación (include y extend):
Include: Validar la existencia (Administrador) en el sistema
Include: Validar Permisos de acceso (Administrador)
Include: Verificar existencia (Usuario) en el sistema.
Extend: Si es necesario se puede modificar (Usuario) del sistema
Extend: Si es necesario se puede eliminar (Usuario) del sistema
Supuestos:
El Usuario debe existir para realizar alguna modificación
Requerimientos Especiales
N/A
Reglas de negocio
Se realiza la eliminación o modificación si el Usuario abandona la institución, o este
cambia o asciende de grupo o grado.
 35

Caso de uso
Aprobación de los temarios
Código caso de uso
CU08
Código Requisito asociado
RF08
Descripción
El actor Sistema realiza un reporte (resumen) de los cambios más recientes del temario
que se encuentra en la base de datos y lo envía al Administrador para que este apruebe
o desapruebe el contenido.
Diagrama del caso de uso
 Actor Descripción de sus responsabilidades
Sistema Sistema: Creación de reportes.
Administrador: Brinda información a el
Administrador
sistema (aprobación), modifica los datos.

Precondiciones
El Administrador que va a recibir la información debe estar registrado.
El Sistema debe tener un horario pre-establecido para él envió de los reportes
Postcondiciones
Actualizar la base de datos.
Flujo primario
1. El actor (Sistema) realiza y envía un reporte de los cambios más recientes del temario en
la base de datos.
2. El actor (Administrador) ingresa al sistema con su respectiva clave y usuario,
posteriormente se valida la existencia en el sistema de este, y se validan los permisos de
acceso.
3. El actor (Administrador) aprueba o desaprueba cada uno de los cambios más recientes
del temario.
4. El actor (Sistema) elimina el contenido desaprobado de la base de datos.
5. El actor (Administrador) puede añadir nueva información para remplazar la eliminada.
Flujos alternos
El contenido del temario no es malo del todo:
 37

1. El actor (Administrador) ingresa al sistema con su respectiva clave y usuario.

2. El actor (Administrador) verifica la existencia del temario.
3. El actor (Administrador) modifica el contenido del temario.
Relaciones de comunicación (include y extend):
Include: Validar existencia (Administrador) en el sistema.
Include: Validar Permisos de acceso (Administrador).
Include: Verificar existencia (Temario) en el sistema.
Include: Reporte temario (Sistema).
Supuestos:
Se debe tener el conocimiento adecuado para juzgar el temario.
El temario se debe encontrar en la base de datos para realizar el reporte.
Requerimientos Especiales
N/A
Reglas de negocio
Se debe enviar un correo a todos los Administradores, informando que se realizó
en el sistema una modificación del temario.
Caso de uso
Actividades definidas por grados
Código caso de uso
CU09
Código Requisito asociado
RF09
Descripción
El actor Profesor realiza el proceso de asignar las actividades a sus respectivos grados
Diagrama del caso de uso
 39

Actor Descripción de sus responsabilidades

Profesor: Toma de datos, asigna los temarios a
Profesor tratar en sus grados y los sube a la base de
datos del sistema.
Alumno: Solicita el temario en el sistema y lo
Alumno
resuelve.

Precondiciones
El Profesor que va a manipular el sistema debe estar registrado.
El Profesor debe autenticarse.
El Alumno que va a manipular el sistema debe estar registrado
El Alumno debe autenticarse.
Postcondiciones
Actualizar la base de datos.
Flujo primario
1. El actor (Profesor) ingresa al sistema con su respectiva clave y usuario, posteriormente
se valida la existencia en el sistema de este, y se validan los permisos de acceso.
2. El actor (Profesor) verifica la existencia del temario
3. El actor (Profesor) agrega el temario a sus respectivos grados y alumnos
4. El actor (Alumno) solicita el temario en el sistema
5. El actor (Alumno) realiza el formulario y envía sus respuestas.
Flujos alternos
N/A
Relaciones de comunicación (include y extend):
Include: Validar existencia (Profesor).
Include: Validar permisos de acceso (Profesor).
Include: Verificar existencia (Temario).
Extend: Solicitar temario (Alumno).
Include: Validar permisos de acceso (Alumno).
Extend: Resolver y enviar (Alumno).

Supuestos:
 41

El Profesor debe tener permisos y estar asignado a un Grado.

Requerimientos Especiales
N/A
Reglas de negocio
Entregar la visualización de los temas correspondientes por grado a todos los alumnos.

Caso de uso
Habilitación de botones de acuerdo al tipo de usuario.
Código caso de uso
CU10
Código Requisito asociado
RF10
Descripción
Habilitar los botones e interfaces funcionales del sistema de acuerdo al tipo de usuario
que ingrese.
Diagrama del caso de uso

Actor Descripción de sus responsabilidades

Sistema: Valida la información de los
usuarios que ingresan al sistema,
Sistema
proporcionar una interfaz de acuerdo a los
permisos de los usuarios.
Alumno Alumno: Brinda información al sistema, al
 43

realizar su inicio de sesión

Profesor: Brinda información al sistema, al
Profesor
realizar su inicio de sesión
Administrador: Brinda información al
Administrador
sistema, al realizar su inicio de sesión

Precondiciones
Todos los usuarios deben estar registrados en el sistema.
Todos los usuarios deben autenticarse.

Postcondiciones
Actualizar la base de datos.
Flujo primario
1. El actor (Usuarios) ingresa al sistema con su respectiva clave y usuario, posteriormente
se valida la existencia en el sistema de este, y se validan los permisos de acceso.
2. El actor (Sistema) verifica la existencia del (Usuario).
3. El actor (Sistema) brinda la interfaz disponible para este usuario (Alumno, Profesor,
Administrador).
4. El actor (Usuario) hace uso del sistema habilitado en base a sus permisos.
Flujos alternos
N/A.
Relaciones de comunicación (include y extend):
Include: Validar existencia (Usuario) en el sistema.
Include: Validar permisos de acceso (Usuario).
Include: Verificar existencia (Usuario).
Include: Indicar permisos disponibles (Alumno) para el uso de la interfaz.
Supuestos:
El usuario debe estar creado en el sistema para realizar el proceso.
Requerimientos Especiales
N/A
Reglas de negocio
Entregar una interfaz funcional al usuario con sus respectivas funciones disponibles.
 45
1.
SOLUCIÒN
DIAGRAMA DE CLASES
47
DIAGRAMA DE ACTIVIDADES
DIAGRAMA DE ACTIVIDADES CU 01-05
49
DIAGRAMA DE ESTADO CU 06-07
51
DIAGRAMA DE ACTIVIDADES CU 08-09
53
DIAGRAMA DE ACTIVIDADES CU 10
55
DIAGRAMA DE ESTADOS

DIAGRAMA ESTADO CU01

DIAGRMA ESTADO CU02

 57

DIAGRAMA ESTADO CU03

DIAGRMA ESTADO CU04
 59
DIAGRAMA DE ESTADO CU05 Y CU06
 61
DIAGRAMA DE ESTADOS CU07
DIAGRAMA DE DESPLIEGUE
 63

VALIDACIONES Y VERIFICACIONES

1. Validar que la interfaz de inicio de sesión funcione correctamente y no permita el ingreso sin tener una cuenta (Pruebas unitarias)
2. Validar que el registro contenga la información suficiente para cada usuario y la información se guarde correctamente (Pruebas unitarias)
3. Validar que la base de datos logre almacenar toda la información sin que se pierda ningún dato, siendo eficiente las conexiones y la
velocidad de respuesta (Pruebas unitarias y pruebas de integración)
4. Validar que la interfaz gráfica realice correctamente las muestras de las diferentes consultas realizadas por los diferentes tipos de usuarios
(Pruebas unitarias)
5. Verificar que el sistema cumpla con todas las funcionalidades pedidas por el cliente y validar que estas tengan un correcto funcionamiento
dentro del prototipo de la interfaz (Pruebas unitarias, de integración. Alpha y beta).
 65
Gestión de la configuración:

Definición de versiones:
Fecha Versión Descripción Autor
12/12/2017 1.0 Aplicación matemática para Mateo Zapata Echeverry
reforzar conocimientos a través
Pablo Andrés Saldarriaga
de una plataforma interactiva

Propósito:
La aplicación tiene como objetivo proporcionar una herramienta de estudio a los estudiantes, para así reforzar el déficit de aprendizaje
matemático presentado en la institución.
Organización:
Actividad Rol responsable Otros roles involucrados
Desarrollar el plan de la gestión de Gestor de la configuración
la configuración
Asegurar que los elementos de la Responsable elementos de Gestor de la configuración
aplicación estén registrados en la configuración
base de datos y sigan los procesos
de cambio establecidos
Asegurar que la información de la Gestor del cambio
aplicación sea actualizada
correctamente
Responsabilidades:
Gestor de la configuración: Entregar un plan confiable de la gestión de la configuración, donde tenga en cuenta todos los cambios de las líneas
base.
Responsable de los elementos de configuración: Registrar los datos de la aplicación en la base de datos.
Checkear que los cambios sobre la documentación sigan los cambios definidos.
Gestor del cambio: Realizar un informe compacto de los riesgos de los cambios de la documentación de la aplicación.

Elementos de la configuración:
Nomenclatura Entregable
PI-1 Manuales de usuarios
PI-2 Requisitos de la app
PI-3 Diseño del software
PI-4 Planos de la base de datos
 67
Elementos de la línea base del proyecto:

Elemento Descripción
Base de datos de la App Espacio en el cual se almacenara toda la
información y actualizaciones que se usen en
la aplicación
Interfaz de la App Sistema encargado de la navegación y
utilización de la app para el usuario
Controladores Manejo interno de del código del
funcionamiento del software

Solicitud de cambios:
Una vez que los docentes y directivos de la institución se reúnan y tengan claro los cambios deseados a realizar se enviara un informe donde especifiquen
toda la información de la petición, luego de esto los desarrolladores aprobaran en caso de ser posible o rechazaran en caso de que la petición se salga de sus
límites.

Auditorias y revisiones:
Las auditorias serán programas para cada finalización del periodo estudiantil, se realizará una reunión presencial en donde se levantarán actas que informen
del rendimiento y las diferentes actualizaciones que sean necesarias para la aplicación, detectando igualmente los fallos que se tengan y sus posibles
soluciones.
Recursos:
Git y BitBucket, dos herramientas que combinadas hacen que el versionado del código fuente sea una tarea más organizada y fácil de controlar.
Se realizarán capacitaciones Presenciales y virtuales donde por medio de la interacción usuario – maquina se les dará a conocer el funcionamiento
básico a los directivos y profesores que harán uso de la app. Del mismo modo se dará conocimiento de las posibles actualizaciones del software
como nuevas funciones o actualizaciones de información

Mantenimiento:
Cada 2 o 3 meses se enviará al gestor de la configuración junto al gestor del cambio para revisar que la Gestión de la configuración este bien encaminada y
luego se harán visitas aleatorias donde se reusaran ciertos cambios específicos, por último, se harán reportes por cada tipo de vistas.

Cronograma:
Fecha Sprint
07/11/2017 Prototipo con funcionalidades básicas para
mostrar al consumidor
02/15/2018 Montaje de la base de datos y construcción de
la interfaz final de la app
04/20/2018 Llenado y actualización de las bases de datos
con toda la información a utilizar
05/30/2018 Entrega del proyecto finalizado y funcional
 69
DIEÑO DE LA ARQUITECTURA

Se usará una arquitectura modelo-vista controlador ya que permite separar los datos de la lógica del negocio, también nos permitiría facilitar la
forma en que el usuario realice las actividades propuesta por el docente en la página, también o permitirá una menor manipulación de la base de
datos.

PANTALLAZOS