Especificación inicial de requisitos de Software

Informe técnico de especificación inicial de requisitos de Software
versión 1.9
“DIVware un sistema Software para la gestión de actividades de docencia,
investigación y vinculación académica”
Autores:
Luis Gonzalo Espejo Tapia
Ignacio Sebastian Pizarro Díaz
Profesor:
John Castro Llanos
Departamento de ingeniería civil informática y ciencias de la computación
Universidad De Atacama
Copiapó, Chile.
Página 1
TABLA DE REGISTROS DE CAMBIOS DEL DOCUMENTO
Fecha
Versión
24 - febrero - 2020
1.0
25 - febrero - 2020
27 - febrero - 2020
27 - febrero - 2020
29 - febrero - 2020
29 - febrero - 2020
Modificación
Proposito
Autor/es
L. Espejo y I.
Pizarro
1.1
Titulo cambia de
“Adquisición de Software
para organizar actividades
de docencia,
investigación y
Para mejor
vinculación” por
definición del titulo
“Adquisición de Software
del documento
para la gestión de
actividades de docencia,
investigación y
vinculación académica”
1.2
Se mejoran y extienden
los siguientes ítems:
resumen, descripción del
proyecto, introducción.
Para mejorar
definición y lograr
una mejor
explicación de los
ítems: resumen,
descripción del
proyecto e
introducción.
L. Espejo y I.
Pizarro
1.1
Titulo cambia de
“Adquisición de Software
para la gestión de
actividades de docencia,
investigación y
vinculación” a “Sistema
Software para la gestión
de actividades de
docencia, investigación y
vinculación”.
Para mejor
definición del titulo
del documento
L. Espejo y I.
Pizarro
1.3
Se mejoran y extienden
los siguientes ítems:
Objetivos y funcionalidad.
Faltaba el alcance
y se mejora la
explicación de las
funcionalidades.
I. Pizarro
1.3
Se cambia la disposición
del documento,
espaciados, identificación
de títulos y estilos de
tablas.
Para mejorar el
orden y
visualización del
documento.
L. Espejo
L. Espejo
Página 2
Fecha
1 - Marzo - 2020
2 - Marzo - 2020
3 - Marzo - 2020
5 - Marzo - 2020
6 - Marzo - 2020
8 - Marzo - 2020
Versión
Modificación
Proposito
Autor/es
1.4
Se mejoran y extienden
los siguientes ítems:
Resumen y conclusiónes.
Mejorar la
explicación de
dichos ítems para
mejor
comprension.
I. Pizarro
1.5
Se agregaron mas
requisitos y se modifica el
requisito 4.0
Mejorar redacción
y encontrar
requisitos
relevantes al
sistema.
L. Espejo y I.
Pizarro
1.6
Se agregaron mas
requisitos.
Encontrar
requisitos
relevantes al
sistema.
L. Espejo
Se agregaron referencias.
Indicar material de
apoyo para la
creación del
documento.
L. Espejo
Se generan y enlazan
anexos al documento.
Mejor
entendimiento
para el lector y
cumplimiento con
el formato
propuesto.
L. Espejo y I.
Pizarro
Se anexa matriz de
trazabilidad.
Mejor
entendimiento de
los requisitos y
cumplimento con
el formato
propuesto.
L. Espejo y I.
Pizarro
1.7
1.8
1.9
ANEXOS
- Anexo A - Matriz de trazabilidad.
- Anexo B - Primer prototipo de baja fidelidad (correspondiente a segunda entrevista)
- Anexo C - Segundo prototipo de baja fidelidad (versión mejorada del primero, correspondiente a tercera
entrevista).
- Anexo D - Síntesis de primera entrevista con el Cliente.
- Anexo E - Imagenes del prototipo de alta fidelidad.
Página 3
RESUMEN
Un académico universitario se desarrolla en el área de docencia; esto implica preparar clases, materiales necesaria
para desarrollarla, organizar talleres, ejercicios. También en el área de investigación; aquí el académico debe
formular proyectos de investigación, leer artículos, reportar resultados, realizar publicaciones, hacer conferencias,
entrevistas y revisiones. Además del área de vinculación: debe dirigir tesis, asistir a congresos. Para gestionar
dichas actividades el académico recurre a diversos elementos, como notas, calendarios, cuadernos, carpetas y
recordatorios.
El proyecto de un Software para la gestión de actividades de docencia, investigación y vinculación académica
permitirá la creación de recordatorios para todas las áreas, la planeación de clases o talleres, generación de
reportes de actividades además de tener compatibilidad con otras plataformas institucionales académicas como
Moddle y U+.
Presentando al académico un sistema amigable para el usuario e intuitivo, siendo compatibles con las diferentes
capacidades de los académicos en las diversas áreas de la universidad. Para su desarrollo, se emplearon diferentes
procedimientos y metodologías para adquirir la información suficiente para comprender de manera clara la
problemática y necesidades de parte del académico. Presentando según la información recopilada mediante
reuniones, tablas y modelos para que el académico tenga mayor entendimiento y haga retroalimentación a lo
presentado.Teniendo en cuenta hasta el mas mínimo detalle para entregar un proyecto final lo mas cercano a la
visión del usuario final. El proyecto final tiene en cuenta la creación, revisión y notificación de las distintas
actividades que tenga el académico, sin excederse en su horas laborales. Planificar clases, con su respectivo
horario, material necesario y la lista de asistencia para que esta sea desarrollada, una lista de contactos de trabajo y
por último, una sección de soporte para que el académico pueda tener información con respecto a la funcionalidad
del sistema y reportar en caso de fallas.
Página 4
ÍNDICE
TABLA DE REGISTROS DE CAMBIOS DEL DOCUMENTO ...............................................2
ANEXOS ................................................................................................................................3
RESUMEN .............................................................................................................................4
1. INTRODUCCIÓN .............................................................................................................6
2. DEFINICIÓN DEL PROYECTO .......................................................................................7
2.1 OBJETIVOS Y FUNCIONALIDADES ..........................................................................7
2.1.1 Objetivo principal del proyecto .........................................................................7
2.1.2 Objetivos detallados del proyecto ....................................................................7
2.1.3 Alcance ................................................................................................................7
2.1.4 Descripción y funcionalidades del Sistema Software .....................................7
2.2 CATÁLOGO INICIAL DE REQUISITOS ......................................................................8
2.2.1 REQUISITOS FUNCIONALES .............................................................................8
2.2.1.1 Requisitos funcionales del módulo inicio ............................................8
2.2.1.2 Requisitos funcionales en el módulo Consultar actividades .............9
2.2.1.3 Requisitos funcionales en el módulo Crear actividad ......................10
2.2.1.4 Requisitos funcionales en el módulo Reportes ................................ 11
2.2.1.5 Requisitos funcionales en el módulo Contactos .............................. 12
2.2.1.6 Requisitos funcionales en el módulo Soporte .................................. 13
2.2.2 REQUISITOS NO FUNCIONALES ....................................................................14
2.2.2.1 Eficiencia: .............................................................................................14
2.2.2.2 Seguridad: ............................................................................................14
2.2.2.3 Usabilidad: ............................................................................................14
3. DISEÑO CONCEPTUAL Y VISTA DE LA INTERACCION DEL SISTEMA ....................15
3.1 Concepto del sistema................................................................................15
3.2 Interfaz de usuario e interacción del usuario con el sistema................ 15
4. CONCLUSIONES ............................................................................................................29
5. LISTA DE REFERENCIAS ...............................................................................................30
Página 5
1. INTRODUCCIÓN
Un académico universitario se desenvuelve en tres áreas distintas, docencia, investigación y vinculación.
Lo que conlleva un gran trabajo y preocupación al momento de gestionar y organizar las diversas actividades que
puedan surgir en estas áreas. Mantener un orden de las actividades, planear clases, ejercicios, revisión de
proyectos, asistencias a reuniones, a congresos, conferencias, logra llegar a ser un problema de organización
muchas veces, sin mencionar el hecho de recordar dichas actividades.
Es de gran importancia para el académico tener una buena gestión de todas las actividades, para así desarrollarlas
de manera óptima de acuerdo al tiempo laboral disponible, además de que se le notifique las fechas y plazos para
cumplir dichas actividades. También es importante para el académico un espacio donde pueda organizar clases,
listas de asistencias, talleres y ejercicios.
Debido al problema, este documento presenta al académico una explicación de requisitos y funciones que
facilitarán de manera óptima la gestión de actividades.
El objetivo de este proyecto es; dar a conocer un sistema software completo junto a toda la información necesaria,
desde los requisitos básicos hasta un prototipo, parar lograr una solución al problema. El sistema a desarrollar tiene
como objetivo principal la gestión de actividades de un académico que se desenvuelve en las áreas de docencia
(permite al académico gestionar clases, asistencias y material de apoyo), vinculación (Gestionar asistencia a
congresos, conferencias y recordatorios para revisiones de proyectos) e investigación (Gestionar reportes, trabajos
y talleres), en una institución de educación superior.
Es por esto que para obtener la información suficiente y tener una mejor visión de la problemática se utilizaron
métodos como la entrevista con preguntas abiertas y cerradas, las cuales mostraban una visión objetiva y subjetiva
de la problemática. Se desarrolló una matriz de trazabilidad (Anexo A) para estudiar los requisitos que debe cumplir
el sistema software, la creación de un modelo de baja fidelidad presentado al académico (Anexo B), corroborando
las preferencias del usuario, también se le presento una versión mejorada de dicho modelo de baja fidelidad (Anexo
C).
Dada esta problemática y explicación del contenido del documento, además de las funcionalidades del sistema
software se procederá a dar a conocer objetivos, requisitos, diseño y conclusiones.
Página 6
2. DEFINICIÓN DEL PROYECTO
Una vez identificando los requisitos esenciales del sistema tales como; la planificación de clases, notificar
al usuario de actividades próximas actividades, vincular otras plataformas institucionales, revisión de actividades en
un determinado periodo de tiempo, creación de actividades según el área (docencia, investigación o vinculación),
generar reportes, tener una lista de contactos de trabajo y un soporte completo; se establecieron sub-sistemas o
módulos para conformar el sistema software implementando todos los requisitos esenciales, a continuación se
explicarán los objetivos y funcionalidades.
2.1 OBJETIVOS Y FUNCIONALIDADES
2.1.1 Objetivo principal del proyecto
El objetivo principal del proyecto es diseñar un sistema software para la gestión de actividades de docencia,
investigación y vinculación, de un Académico que trabaja en una institución de educación superior
2.1.2 Objetivos detallados del proyecto
• Realizar la descripción detallada del problema a resolver.
• Aplicar correctamente los conceptos y principios relacionados a la ingeniería de Software en la resolución de
casos prácticos para la gestión de proyectos de Software.
• Utilizar herramientas para el modelado de proyectos de Software.
• Identificar requisitos funcionales y no funcionales del sistema Software.
• Describir casos de usos y matriz de trazabilidad.
2.1.3 Alcance
El proyecto “Sistema Software para la gestión de actividades de docencia, investigación y vinculación académica”
es aplicable a todos los trabajadores Académicos de cualquier área de especialización profesional, que se
desenvuelvan en alguna institución de educación superior y que se desarrolle en las áreas de docencia,
investigación y vinculación.
2.1.4 Descripción y funcionalidades del Sistema Software
Eriksson (2012) señala que “Los requisitos de cualquier proyecto deben estar bien pensados, equilibrados y
claramente entendidos”, es por esto que una vez identificados y entendidos los principales requisitos, fueron
organizados de tal manera que el usuario logre identificarlos fácilmente dentro del sistema. El sistema Software
DIVware contiene en su interior 6 sub-sistemas o módulos, que fueron divididos de esa manera para identificar mas
fácilmente los principales requisitos del Cliente, y a su vez sean fáciles de reconocer por el usuario, los subsistemas son:
1. Inicio: En este módulo se muestran las principales actividades, se muestran organizadamente separadas por
‘Expiradas’, ‘Activas’ o ‘Próximas’.
2. Consultar actividades: En este módulo se muestran todas las actividades con opción de ser visualizadas por
día, semana y mes. Mostrando la actividad un Título, una hora y una reseña de la actividad agregada.
3. Crear actividad: En este módulo se permite la creación de una actividad identificándola de acuerdo al área
(Docencia, investigación o vinculación), se solicita rellenar los campos; Título actividad, Fecha, Hora, Lugar
Actividad, Comentario.
Página 7
4. Reportes: En este módulo se encuentra la opción de generar un reporte de las actividades de acuerdo al área
(Docencia, investigación o vinculación), se solicita elegir un tipo de reporte según un periodo de tiempo, este
puede ser diario, semanal o mensual. Además se ofrece la herramienta de compartir dicho reporte generando un
PDF, compartir vía Bluetooth o Airdrop, imprimir reporte.
5. Contactos: En este módulo se muestran la información de los contactos del área de trabajo del usuario. Además
se permite agregar un nuevo contacto.
6. Soporte: En este módulo se ofrece una ayuda en caso de falló del sistema software, agrupado por tipo de
problema (problemas con: Login, vinculación, contactos, eventos, reportes), mostrando algunos posibles
problemas de cada tipo. Muestra además una sección de sugerencias y reportar errores en caso de ser
necesario. También en este módulo se encuentra una barra de búsqueda para ser utilizada por palabra clave.
2.2 CATÁLOGO INICIAL DE REQUISITOS
Los requisitos fueron identificados previamente a este documento utilizando como metodología la
entrevista con el Cliente, de tal manera se iba logrando seleccionar y mejorar cada requisitos que debía cumplir el
sistema software, los requisitos son separados por el módulo (inicio, consultar actividades, crear actividad,
reportes, contactos o soporte) al que pertenece dicho requisito, y a su vez clasificado en requisito funcional o
requisito no funcional:
2.2.1 REQUISITOS FUNCIONALES
2.2.1.1 Requisitos funcionales del módulo inicio
En el módulo ‘Inicio’ (Ver sección 2.1.4, página 7) se encuentran los siguientes requisitos funcionales:
Requisito: 1.0 Entrada mediante un Login
Descripción de
requisito:
Al entrar al software, el sistema debe mostrar al docente una sección que
solicita un usuario y una clave.
Entrada:
Dirección en donde se encuentre el sistema software.
Proceso
Una vez abierto el software, para poder ingresar al mismo, el sistema
mostrará una sección de login para identificar al usuario dentro de la
plataforma.
Salida:
Mostrar sección Login con los campos a llenar de ‘usuario’, ‘contraseña’ y
una opción de ‘ingresar’.
Error:
Tabla 1: Requisito funcional 1.0
Requisito: 1.1 No permitir el ingreso a académicos que no sean de la institución.
Descripción de
requisito:
El sistema no deberá permitir a académicos no pertenecientes a la
institución el ingreso al sistema.
Entrada:
Usuario y contraseña del docente.
Página 8
Requisito: 1.1 No permitir el ingreso a académicos que no sean de la institución.
Proceso:
El docente que no pertenezca a la institución, al momento que ingrese sus
datos para el inicio de sesión, el proceso de verificación de identidad no
permitirá el ingreso al sistema.
Salida:
No ingresar al sistema.
Error:
Tabla 2: Requisito funcional 1.1
Requisito: 1.2 Iniciar sesión en el sistema.
Descripción de
requisito:
Una vez iniciada la sesión en el sistema, este deberá mostrar al docente, un
resumen semanal de las actividades ordenadas según ‘Expiradas’, ‘Activas’
o ‘Próximas’.
Entrada:
Usuario y contraseña del docente
Proceso:
Al ingresar el usuario y contraseña de docente y sea validado por el sistema,
este deberá mostrar el módulo Inicio, el cual mostrará un resumen semanal
de las actividades del docente.
Salida:
Mostrar las actividades del docente de la semana presente.
Error:
El docente al introducir su usuario incorrecto, contraseña incorrecta o
cambas incorrectas, el sistema debe notificarlo con un mensaje;
“Credenciales erróneas, intente nuevamente”.
Tabla 3: Requisito funcional 1.2
2.2.1.2 Requisitos funcionales en el módulo Consultar actividades
En el módulo ‘Consultar actividades’ (Ver sección 2.1.4, página 7) se encuentran los siguientes requisitos
funcionales:
Requisito: 2.0 Resumen de actividades.
Descripción de
requisito:
Al seleccionar el módulo ‘Consultar actividades’, el sistema deberá mostrar
al docente un calendario con el mes, semana o día actual con sus
respectivas actividades previamente creadas.
Entrada:
Seleccionar la opción ‘Consultar actividades’.
Proceso
El sistema despliega un módulo donde se muestra el mes presente de
acuerdo a la fecha actual del momento, además se ofrecerá la opción de
visualizar las actividades desplegando un calendario mensual, semanal o
diario.
Salida:
Mostrar las actividades ya programadas
Error:
Tabla 4: Requisito funcional 2.0
Página 9
Requisito: 2.1 Visualizar actividades a detalle.
Descripción de
requisito:
Al seleccionar una actividad dentro del calendario de la opción ‘Consultar
actividades’, el sistema deberá mostrar al docente una sección con los
detalles de la actividad; Título de la actividad, día, hora, lugar y comentario.
Entrada:
Seleccionar una actividad dentro del calendario.
Proceso:
Una vez seleccionada una actividad (previamente creada en el módulo
‘Crear actividad’) dentro del calendario, el sistema le mostrará al docente
una sección con información detallada de la actividad seleccionada.
Salida:
Mostrar la información de la actividad seleccionada.
Error:
Tabla 5: Requisito funcional 2.1
Requisito: 2.2 Programar recordatorio.
Descripción de
requisito:
Al seleccionar la opción ‘Crear recordatorio’, el sistema deberá mostrar al
docente una sección solicitándole; seleccionar la actividad, una fecha y una
hora de recordatorio.
Entrada:
Seleccionar la opción ‘Crear recordatorio’.
Proceso:
El sistema le mostrará al docente una sección en la cual el usuario debe
seleccionar la actividad que desea recordar, una fecha y una hora en la cual
desea que se cree el recordatorio.
Salida:
Recordatorio creado.
Error:
El docente al no seleccionar una fecha y/o una hora, el sistema no permitirá
crear el recordatorio.
Tabla 6: Requisito funcional 2.2
2.2.1.3 Requisitos funcionales en el módulo Crear actividad
En el módulo ‘Crear actividad’ (Ver sección 2.1.4, página 7) se encuentran los siguientes requisitos
funcionales:
Requisito: 3.0 Creación de actividades.
Descripción de
requisito:
Al seleccionar el módulo ‘Crear actividad’, el sistema deberá mostrar al
docente una sección en la cual se le solicite la información necesaria para la
creación de una actividad.
Entrada:
Al seleccionar el módulo ‘Crear actividad’.
Proceso:
El sistema solicitará al usuario; mediante un menú desplegable el tipo de
actividad (docencia, investigación o vinculación), Título de actividad, fecha
de actividad, hora de la actividad, lugar a desarrollarse la actividad, un
comentario o reseña, y de ser necesario adjuntar archivos. Una vez llenado
los campos el sistema creará una actividad.
Página 10
Requisito: 3.0 Creación de actividades.
Salida:
Actividad creada.
Error:
El docente al no rellenar cualquiera de los campos de Título de actividad,
fecha, hora, lugar y comentario, o en su defecto no rellenar ninguno de los
campos, el sistema no creará la actividad.
Tabla 7: Requisito funcional 3.0
Requisito: 3.1 Limpiar campos.
Descripción de
requisito:
Al seleccionar la opción ‘Limpiar Campos’, el sistema deberá mostrar al
docente los campos sin escritura ni selecciones.
Entrada:
Al seleccionar la opción ‘Limpiar Campos’.
Proceso:
El sistema automáticamente borrará toda selección y/o escritura de los
campos; Título de la actividad, fecha, hora lugar, comentario y adjuntar
archivo, dejándolos en blanco.
Salida:
Campos sin llenar.
Error:
Tabla 8: Requisito funcional 3.1
2.2.1.4 Requisitos funcionales en el módulo Reportes
En el módulo ‘Reportes’ (Ver sección 2.1.4, página 8) se encuentran los siguientes requisitos funcionales:
Requisito: 4.0 Reporte de actividades
Descripción de
requisito:
Al seleccionar el módulo ‘Reportes’, el sistema deberá mostrar al docente
una sección en la cual se le solicite la información necesaria para la
generación de un reporte de actividades.
Entrada:
Al seleccionar el módulo ‘Reportes’.
Proceso:
El sistema solicitará al usuario el tipo de actividad del cual desea hacer el
reporte (docencia, investigación o vinculación), además de seleccionar una
opción si el usuario desea un reporte diario, semanal o mensual de dicho
tipo de actividad. El sistema finalmente generará un reporte en formato PDF
el cual podrá ser compartido mediante correo electrónico, Bluetooth,
Airdrop o imprimir el reporte.
Salida:
Reporte de actividades.
Error:
El docente al no seleccionar la fecha que desea, el sistema no permitirá
generar un reporte.
Tabla 9: Requisito funcional 4.0
Requisito: 4.1 Generación de reporte.
Descripción de
requisito:
Al llenar los campos solicitados seleccionando una fecha, y el tipo de
actividad, el sistema deberá generar al usuario un reporte con toda la
información detallada de las actividades de la fecha seleccionada.
Página 11
Requisito: 4.1 Generación de reporte.
Entrada:
Fecha, tipo de actividad.
Proceso:
El sistema a traves de la fecha y el tipo de actividad, generará un
documento en formato PDF que contiene el detalle de las actividades
realizadas en el periodo de tiempo seleccionado.
Salida:
Reporte generado.
Error:
No seleccionar tipo y/o fechas validas.
Tabla 10: Requisito funcional 4.1
2.2.1.5 Requisitos funcionales en el módulo Contactos
En el módulo ‘Contactos’ (Ver sección 2.1.4, página 8) se encuentran los siguientes requisitos funcionales:
Requisito: 5.0 Agenda de contactos
Descripción de
requisito:
Al seleccionar el módulo ‘Contactos’, el sistema deberá mostrar al docente
una lista completa con todos sus contactos vinculados a la plataforma.
Entrada:
Al seleccionar el módulo ‘Contactos’.
Proceso:
El sistema desplegará una lista de todos los contactos vinculados a la
institución y/o agregados previamente de forma manual.
Salida:
Mostrar lista de contactos.
Error:
Tabla 11: Requisito funcional 5.0
Requisito: 5.1 Agregar contacto
Descripción de
requisito:
Al seleccionar la opción ‘Agregar contacto’, el sistema deberá mostrar al
docente una sección en la cual se le solicita la información necesaria para la
creación de un nuevo contacto.
Entrada:
Al seleccionar la opción ‘Agregar contacto’.
Proceso:
El sistema mostrará una sección en la cual se le solicitará al docente;
Nombre, institución, correo, teléfono y foto del contacto que desea agregar.
Una vez completado los campos correctamente el sistema agregará a la
lista de contactos, el recién creado.
Salida:
Contacto creado.
Error:
El docente al no rellenar cualquiera de los campos de Nombre, institución,
correo y teléfono, o en su defecto no rellenar ninguno de los campos, el
sistema no creara el contacto.
Tabla 12: Requisito funcional 5.1
Requisito: 5.2 Búsqueda de contacto
Descripción de
requisito:
Al escribir un nombre en la barra de búsqueda, el sistema deberá mostrar al
docente la información del contacto con el nombre escrito.
Página 12
Requisito: 5.2 Búsqueda de contacto
Entrada:
Nombre en la barra de busqueda
Proceso:
El sistema mostrará la información del nombre del contacto escrito en la
barra de búsqueda de contactos.
Salida:
Información del contacto
Error:
El nombre del contacto si no está agregado a la lista de contactos, el
sistema no mostrará información.
Tabla 13: Requisito funcional 5.2
2.2.1.6 Requisitos funcionales en el módulo Soporte
En el módulo ‘Soporte’ (Ver sección 2.1.4, página 8) se encuentran los siguientes requisitos funcionales:
Requisito: 6.0 Guía de soporte
Descripción de
requisito:
Al seleccionar el módulo ‘Soporte’, el sistema deberá mostrar al docente
una sección ordenada por tipo de pregunta de soporte, opción de
sugerencia y reportar error.
Entrada:
Al seleccionar el módulo ‘Soporte’.
Proceso:
El sistema mostrará una lista ordenada por tipo de pregunta de soporte,
ademas de mostrar una opción para generar una sugerencia y un reporte de
error.
Salida:
Mostrar soporte
Error:
Tabla 14: Requisito funcional 6.0
Requisito: 6.1 Generar sugerencia.
Descripción de
requisito:
Al seleccionar la opción ‘Sugerencia’, el sistema mostrará al docente una
sección solicitando un correo y un comentario.
Entrada:
Correo y comentario.
Proceso
El sistema mediante el correo indicado y el comentario describiendo la
sugerencia, enviará una notificación a los desarrolladores de la sugerencia.
Salida:
Sugerencia generada.
Error:
El docente al no completar los campos de correo y/o comentario, el sistema
no generará la sugerencia.
Tabla 15: Requisito funcional 6.1
Requisito: 6.2 Generar reporte de error.
Descripción de
requisito:
Al seleccionar la opción ‘Reportar error’, el sistema mostrará al docente una
sección solicitando un correo, un comentario y fotos del error.
Entrada:
Correo, comentario y fotos.
Página 13
Requisito: 6.2 Generar reporte de error.
Proceso
El sistema mediante el correo indicado, el comentario describiendo el error y
las fotos adjuntadas, enviará una notificación a los desarrolladores del error
reportado.
Salida:
Error reportado.
Error:
El docente al no completar los campos de correo y/o comentario, el sistema
no generará el reporte de error.
Tabla 16: Requisito funcional 6.2
Requisito: 6.3 Búsqueda de error por palabra clave.
Descripción de
requisito:
Al escribir una palabra clave en la barra de búsqueda, el sistema deberá
mostrar al docente todos los posibles errores relacionados a la palabra
escrita.
Entrada:
Palabra en la barra de búsqueda.
Proceso
El sistema buscará todos los posibles errores relacionados que coincidan
con la palabra descrita en la barra de búsqueda.
Salida:
Lista de posibles errores.
Error:
1.- Si la palabra clave no coincide con las listas de errores insertas en el
sistema software, no se mostrará información.
2.- Si la palabra clave está mal escrita, no se mostrará información.
Tabla 17: Requisito funcional 6.3
2.2.2 REQUISITOS NO FUNCIONALES
2.2.2.1 Eficiencia:
- Toda funcionalidad del sistema debe ser de respuesta inmediata.
- Las actividades agregadas deben ser guardadas para que cada vez que se utilice el sistema,
se muestren correctamente.
- El sistema debe ser capaz de ser usado con cualquier red.
2.2.2.2 Seguridad:
- El acceso debe ser restringido solamente para docentes de la institución.
- El sistema debe contar con un sistema de registro para ingresar.
2.2.2.3 Usabilidad:
- El tiempo de aprendizaje del sistema por un usuario debe ser el menor posible.
- El sistema debe tener facilidad de uso.
- El sistema debe poseer un diseño “Responsive” a fin de garantizar la adecuada visualización
en múltiples computadores personales y dispositivos tabletas.
Página 14
3. DISEÑO CONCEPTUAL Y VISTA DE LA INTERACCION DEL SISTEMA
3.1 Concepto del sistema
El sistema está basado en un concepto sencillo y de fácil manejo, cubriendo los
requisitos descritos por el Cliente, fue separado por 6 módulos principales para que cubriera
cada módulo un requisito esencial. Además basándose en las plataformas como Moddle e
intranet, usadas comúnmente en las instituciones de educación superior, se desarrollará
DIVware, un sistema software con la idea de que sea rápido, sencillo y cubra con todas las
necesidades acorde a su funcionalidad.
3.2 Interfaz de usuario e interacción del usuario con el sistema
A continuación se mostrarán imágenes de las diferentes interfaces del sistema y su interacción
con el usuario, la imágenes serán mostradas por módulos:
Interfaz Login:
Al iniciar el sistema software DIVware, se mostrará la siguiente interfaz:
Imagen 1: Interfaz de Login.
En caso de seleccionar la opción “Olvidaste la Contraseña?”, se mostrará la siguiente interfaz:
Imagen 2: Olvido de contraseña.
Página 15
Interfaz de módulo Inicio
Al iniciar sesión correctamente, se mostrará el módulo ‘Inicio’ (Ver sección 2.1.4, página 7):
Imagen 3: Módulo Inicio.
Al seleccionar en la parte superior el ícono de una herramienta, se desplegará el siguiente
menú:
Imagen 4: Menú de herramientas
Página 16
Al presionar la opción ‘Editar Perfil’, el sistema mostrará la siguiente imagen, mostrando la
información personal del usuario:
Imagen 5: Editar perfil parte 1.
Al presionar el botón azul ‘Editar Perfil’, el sistema mostrará la siguiente imagen, permitiendo
editar la información personal del usuario:
Imagen 6: Editar perfil parte 2.
Página 17
En la imagen 4, se puede apreciar la opción ‘Vincular cuentas’, al seleccionar la opción se
mostrará la siguiente imagen, permitiendo al usuario vincular sus cuentas de redes sociales y
profesionales institucionales:
Imagen 7: Vincular cuentas.
Interfaz de modulo Consultar actividades
Al seleccionar en la parte izquierda el módulo ‘Consultar actividades’ (Ver sección 2.1.4,
página 7), se desplegará la siguiente imagen, permitiendo ver al usuario un resumen de sus
actividades (Ver sección 2.2.1.2, Tabla 5, página 10):
Imagen 8: Consultar actividades de forma mensual.
Página 18
Al seleccionar en la parte superior derecha del calendario mensual, se encuentra la opción de
ver las actividades de manera semanal:
Imagen 9: Consultar actividades de forma semanal
A su vez, al seleccionar la opción de ver las actividades de manera diaria:
Imagen 10: Consultar actividades de forma diaria
Página 19
En el caso que se seleccione una actividad visualizada, se mostrará el detalle de la actividad
(Ver sección 2.2.1.2, Tabla 5, página 10):
Imagen 11: Detalle de actividad.
En la imagen 10, se puede apreciar la opción de ‘Crear recordatorio’ (Ver sección 2.2.1.2, Tabla
6, página 10) en la parte inferior. Al seleccionarla el sistema mostrará lo siguiente:
Imagen 12: Programar recordatorio.
Página 20
Si desplegamos la lista en ‘Seleccione una actividad’ de la imagen 12, se mostrará la siguiente
lista:
Imagen 13: Lista en programar recordatorio.
Interfaz de módulo ‘Crear Actividad’
Al seleccionar el módulo ‘Crear actividad’ el sistema mostrará’ la siguiente interfaz; ofreciendo
al usuario un formulario agregar una actividad.
Imagen 14: Crear Actividad
Página 21
Al seleccionar ‘Tipo de actividad’ se desplegará una lista de opciones con los tipos de
actividades (docencia, vinculación o investigación) de la siguiente manera:
Imagen 15: Seleccionar tipo de actividad
Al seleccionar el campo de ‘Fecha’ se desplegará un calendario del mes actual, como se
muestra en la siguiente imagen:
Imagen 16: Selección de fecha
Página 22
Al seleccionar la opción ‘Hora’ se permitirá al usuario que escriba la hora deseada, cabe
mencionar que esta hora esta validada en formato de 24 horas, es decir, el usuario solo puede
escribir una hora lógica (Hora: 00:00 - 24:00). También se le permite al usuario desplazarse a
través de flechas que aumentan o disminuyen la hora indicada.
Imagen 17: Selección de hora.
Interfaz módulo ‘Reportes’
Al seleccionar el módulo ‘Reportes’, el sistema mostrará la siguiente interfaz; ofreciendo al
usuario la opción la generación de un informe de acuerdo a las fechas deseadas:
Imagen 18: Generación de Reportes.
Página 23
Al seleccionar la opción de ‘Tipo de Actividad’ se desplegará una lista de opciones con los
tipos de actividades (Docencia, vinculación, investigación u otra):
Imagen 19: Seleccionar tipo de actividad en módulo Reportes.
Al seleccionar la opción ‘Semanal’, se desplegará un calendario del mes actual en el cual el
usuario solo podrá seleccionar una semana del mes:
Imagen 20: Selección de semana.
Página 24
En la imagen 18; al seleccionar la opción ‘Compartir’ se desplegará la siguiente lista con
acciones por hacer:
Imagen 21: Selección compartir.
Interfaz módulo ‘Contactos’
Al seleccionar el módulo ‘Contactos’; el sistema desplegará la siguiente interfaz, ofreciéndole
al usuario la visualización de una lista con sus contactos, una barra de búsqueda, y la opción
de agregar contactos:
Imagen 22: Selección modulo Contactos.
Página 25
Al seleccionar la opción ‘Ver’ que se encuentra al costado de cada nombre de contacto de la
lista, el sistema desplegará la información de contacto al lado derecho, de la siguiente manera:
Imagen 23: Selección de información de contacto.
En la imagen 23; al seleccionar la opción ‘Agregar Contacto’ se visualizará la siguiente
sección:
Imagen 24: Agregar contacto.
Página 26
Interfaz módulo ‘Soporte’
Al seleccionar el módulo ‘Soporte’, el sistema mostrará la siguiente interfaz ofreciendo al
usuario una sección de preguntas frecuentes, un apartado de sugerencias, un apartado de
reportar error y una barra de búsqueda por palabra clave:
Imagen 25: Selección de módulo soporte.
Al seleccionar cualquier opción de la sección ‘Preguntas Frecuentes’, se desplegará a la
derecha una lista con posibles soluciones al problema del área seleccionada.
Imagen 26: Lista preguntas frecuentes.
Página 27
En la imagen 26; al seleccionar la opción ‘Sugerencia’; el sistema ofrecerá la siguiente sección:
Imagen 27: Sugerencias.
En la imagen 26; al seleccionar la opción ‘Reportar Error’; el sistema ofrecerá la siguiente
sección:
Imagen 27: Reportar error.
Página 28
4. CONCLUSIONES
El desarrollo software es un proceso con una alta dificultad que va variando del proyecto. Para el
desarrollo de este documento se hace una simulación de cómo una empresa gestora de software
se le presenta un problema, hace la recopilación de antecedentes para su futuro análisis, del cual
se obtienen requisitos funcionales y no funcionales, se crean modelos y documentos para mostrar
el avance del proyecto al cliente gestionando el tiempo dispuesto para su entrega final. Indicando
funcionalidades del sistema e interacción de parte del usuario. Las interacciones de la propuesta
de parte del cliente o del equipo de trabajo hicieron que cada vez el proyecto final redujera la
ambigüedad, errores en el avance y adelantarse ante posibles fallas.
La división de responsabilidades durante el progreso del proyecto fue indispensable, ya que hacía
que la experiencia vivida fuera lo más cercana a un caso real de desarrollo software, se hicieron
discusiones, aportes, modificaciones de parte del equipo de trabajo los cuales tenían diferentes
puntos de vista ante la problemática dada, haciendo revisiones al informe dos veces a la semana.
Dividir roles de analista de requisitos, creación de bosquejos del sistema hasta la programación
del prototipo final.
Con el fin de resolver la problemática de gestionar las diversas actividades de un académico en
una determinada institución. La cual produjo una serie de restricciones tales como; el
conocimiento limitado del desarrollo software como conocer procesos o metodologías empleadas
para su avance, el poco manejo de lenguaje técnico para redactar el informe y por último la
experiencia necesaria para crear un prototipo de alta fidelidad no funcional para ser presentada en
el proyecto final. Como proyecto a futuro, el prototipo será desarrollado con mayor manejo
técnico y tiempos definidos, cuya finalidad es que el sistema esté completamente funcional.
Página 29
5. LISTA DE REFERENCIAS
[1] Durán, A., Bernárdez, B. (2002). Metodología para la Elicitación de Requisitos de Sistemas Software. España:
Sevilla.
[2] López, D., Villa, J. (2012). Proyecto de grado: Plantillas y artefactos personalización de RUP para proyectos
académicos de desarrollo de Software. Colombia: Medellín.
[3] Flores, D., Morales, J., Valenzuela, C. (2018). Objetivo del proyecto. Gestión de proyectos de Software.
Presentación de alumnos del Instituto Nacional de México. Rescatado de: https://es.slideshare.net/Jair_Valenz/
gestin-de-proyectos-de-software-subtema-31-objetivo-del-proyecto-120334660
[4] Siqueira, G., Vazquez, E. (2018), Ingeniería de Requisitos: Software orientado al negocio. Editorial: Kindle.
[5] Eriksson, U. (2012). Functional vs Non functional Requirements. Rescatado de: http://reqtest.com/requirementsblog/functional-vs-non-functional-requirements/
[6] Armin, B., Creemers, S. (2010) Organizational Requirements Engineering. Chapter 9.
Página 30