SGT - Documentación de proyecto

DOCUMENTACIÓN DE PROYECTO
Juan López Godoy
Julio Javier Gámez Ríos

José Antonio Jiménez Ruiz

SGT – Sistema de Gestión de Tutorías

Índice

Control de versiones Página 3

Oportunidad de Negocio Página 4

Riesgos Página 5

Obligaciones Página 6

StakeHolders: Miembros Página 7

StakeHolders: Iteración de Comienzo Página 8

• Requisitos funcionales Página 9
• Requisitos no funcionales Página 14
• Análisis coste-tiempo
tiempo Página 15
• Reparto de tareas y priorización Página 17
• Casos de uso: Nivel [0/1] Página 20

StakeHolders: Iteración de Elaboración Página 21

• Nomenclatura de requisitos funcionales Página 22
• Priorización de casos de uso Página 23
• Casos de uso: Tutorías Página 24
• Matriz de trazabilidad: Tutorías Página 31
• Diagramas de secuencia Tutorías
secuencia: Página 32
• Diagrama de clases Tutorías
clases: Página 41
• Diagrama Entidad-R Relación: Tutorías Página 42
• Diagrama de tablas BBDD Tutorías
BBDD: Página 43
• Diagramas de actividades Tutorías
actividades: Página 44
• Tarjetas CRC: Tutorías Página 50
• Repositorio documental: DropBox Página 51
• Cuestionario de calidad Primera parte
calidad: Página 52

2


StakeHolders: Iteración de Construcción Página 53

• Casos de uso: Consultas Página 54
• Matriz de trazabilidad: Consultas Página 65
• Diagramas de secuencia: Consultas Página 66
• Diagrama de clases: Patrón MVC Página 77
• Diagrama Entidad-Relación: Consultas
Relación: Página 96
• Diagrama de tablas BBDD: Consultas Página 43
• Diagramas de actividades: Consultas Página 99
• Tarjetas CRC: Consultas Página 108
• Correos tipo: Mensajería SGT Página 109
• Cuestionario de calidad Segunda parte
calidad: Página 119

3


CONTROL DE VERSIONES
Tipo de operación:

R: Realización acorde normal al desarrollo del proyecto en el tiempo.
E: Eliminación de contenido respecto a la versión anterior.
M: Modificación de contenido respecto a la versión anterior.
D: Toma de decisión.
AE: Aportación extra.

Fecha Iteración Producto Versión Oper. Contenido
18-10-10 Doc. de Visión 1.0. R Oportunidad de negocio
Requisitos funcionales
Cero
(0)

Riesgos
Obligaciones
StakeHolders
18-10-10 Doc. de Visión 1.1. E Moderación queja
Cero (0)

M Publicación de tutorías.
D Java Swing
M StakeHolders
07-11-10 Doc. SRS 1.0. R Requisitos funcionales
Comienzo

Casos de uso
(1)

Análisis coste-tiempo
tiempo
Reparto de tareas
08-12-10 Doc. de Análisis 1.0. M Requisitos funcionales
R Nomenclatura de req. funcionales
D Requisitos no funcionales
AE Control de versiones
Tabla salarial
Repositorio documental: DropBox
ocumental:
Elaboración

Matriz de trazabilidad Tutorías
trazabilidad:
(2)

Diagramas de actividad
actividades: Tutorías
Tarjetas CRC: Tutorías
Cuestionario de calidad – 1era parte
R Casos de uso: Tutorías
Diagramas de secuencia: Tutorías
Diagrama de clases UML: Tutorías
Diagrama ER: Tutorías
Diagrama de tablas MySQL: Tutorías
e
17-01-11 Doc. de Análisis 1.0. AE Matriz de trazabilidad: Consultas
Diagramas de actividades: Consultas
Tarjetas CRC: Consultas
Construcción

Correos Tipo
Cuestionario de calidad – 2da parte
(3)

R Casos de uso: Consultas
Diagramas de secuencia: Consultas
Diagrama de clases: MVC
Diagrama ER: Consultas
Diagrma de tablas MySQL: Consultas

4


OPORTUNIDAD DE NEGOCIO PARA EL PROYECTO
Propósito
En este punto se pretende acercar de una forma rápida y sencilla al cliente la
aplicación a desarrollar por nuestro equipo. Este acercamiento se realizará definiendo
acercamiento
tanto las necesidades de alto nivel como las características del software a implantar.
En otras palabras, explicaremos que hace el programa y cuál es su finalidad y
explicaremos
funcionalidad pero sin profundizar en aspectos técnicos y/o informáticos. Será un
documento cercano a los conocimientos de cualquier usuario medio de las tecnologías
informáticas y de la comunicación.

Alcance
El presente apartado tiene como objetivo explicar y determinar el funcionamiento
general de la aplicación a desarrollar. No se pretende con él que el usuario final
adquiera conocimientos técnicos y/o informáticos sino todo lo contrario. El fin del punto
actual es plasmar en la mente del usuario una imagen clara y concisa de lo que la
aplicación va a realizar y la mejora que supone para su labor diaria y laboral.

El principal alcance será la satisfacción profesional del cliente o usuario en lo referente
a requisitos funcionales del software a desarrollar. Cualquier duda o inconformidad en
lo acordado o entendido anteriormente debe ser disipada o eliminada mediante estas
líneas.

Oportunidad de negocio
La Universidad Pablo de Olavide de Sevilla nos comunica su necesidad de gestionar
telemáticamente las peticiones de tutoría y realización de consultas por parte de los
áticamente
alumnos. Se pretende crear una plataforma mediante la cual los profesores y alumnos
accedan a ella para ver y gestionar las tutorías y consultas a las que deben dar cita o
consultas
respuesta y las asignaturas y temas sobre los cuales se desea profundizar y obtener
explicaciones y nuevos conocimientos respectivamente.

Para la petición de una tutoría será necesario elegir un tema concreto de una lista
dependiente de una asignatura. El tema elegido tendrá una lista de profesores
diente
asociados y la tutoría podrá ser celebrada por cualquiera de estos que publicaran el
lugar, fecha y hora de ésta mediante una gestión automática que realizará la
aplicación. Respecto a la realización de consultas, los alumnos publicarán consultas
eligiendo tema concreto de una lista dependiente de una asignatura y teniendo como
elemento consultado a un único profesor. Tanto las tutorías como las consultas
contarán con un sistema de valoración que influirá en la puntuación de los profesores
valoración
siendo posible además, publicar una queja en la parte de consultas que conllevará una
puntuación negativa para éstos
éstos.

Se pretende además, que la aplicación cuente con un sistema de mensajería (vía
correo electrónico) mediante el cual se realice notificación de, casi la totalidad de
reo
funcionalidades del sistema.

5


RIESGOS
Debido a que es un proyecto software de cierta duración (aproximadamente 4 meses)
nuestro trabajo se verá expuesto a los siguientes riesgos:

• Políticos
Ya que el cliente y usuario de la aplicación será la propia universidad nos veremos
universidad,
expuestos a los riesgos que implican las diferentes opiniones y necesidades de
todos los organismos de ésta.

• Recursos
Debido a que debemos desarrollar una aplicación que funcione para la universidad
por medio de la red de Internet nos vemos en la necesidad de contar con
numerosos equipos donde realizar las pruebas de concurrencia y servidores donde
alojar la base de datos del sistema. Además de esto se quiere implantar un
eficiente sistema de correo electrónico para lo cual, necesitamos un servidor de
esta tecnología.

• Habilidad
Nuestro equipo de programadores posee grandes conocimientos de los lenguajes
de programación y de base de datos a utilizar, java y sql respectivamente. No
java
obstante, prevemos que en el futuro necesitaremos utilizar otras tecnologías para
las cuales será necesario un curso o estudio sobre sus características.
Aunque en la actualidad nos bastemos con la tecnología que conocemos para dar
viabilidad al proyecto, de todos es sabido que conforme se avanza siempre es
necesario un reciclaje o aprendizaje de nuevas herramientas para solucionar los
problemas que éste presenta.

• Requisitos
Creemos que este tipo de riesgos no se debe ignorar aunque los requisitos estén
aunque
supuestamente claros. Se entiende que al tener establecidas numerosas y
sucesivas reuniones con los stakeholders del proyecto los requisitos pueden
cambiar en cualquier momento. Es por ello, que somos previsores en este tema.

• Tiempo
Tenemos establecidas todas las reuniones y entregas con el cliente. En cada una
de ellas debemos hacer entregas sucesivas del proyecto para que se pueda
observar nuestro correcto avance e impecable trabajo. Puede ser uno de los
riesgos más presentes en nuestro proyecto.

6


OBLIGACIONES
En este apartado estudiaremos las obligaciones a las que debe responder nuestro
proyecto. Son unas pautas a las que tiene que atenerse la aplicación a desarrollar
para así cumplir lo deseado en los requisitos funcionales y, por consiguiente,
conseguir la plena satisfacción del cliente.

• Plataforma de desarrollo
La plataforma para la que desarrollaremos la aplicación no está del todo clara ya
que, por un lado, nuestro equipo de desarrollo no es experto en desarrollo Web y,
por otro, no sabemos la viabilidad de una aplicación de escritorio con
funcionamiento en la red de Internet.

• Tecnología
A priori, podemos establecer varias obligaciones para esta categoría.
Los diagramas de diseño deberán hacerse en lenguaje UML mientras qu el que
código de programación utilizado para la implementación del sistema será JAVA.
En cuanto a la base de datos escogeremos la tecnología que nos ofrece MySQL.

En lo referente a la interfaz gráfica escogemos la plataforma que nos brinda el
sistema operativo Windows así pues, utilizaremos la tecnología de JAVA SWING.
ivo Windows,

• Fechas de entrega y fecha tope
Como hemos dicho anteriormente, las fechas de entrega y fecha tope será uno de
los temas con mayor presencia en el desarrollo de nuestro proyecto.

Semana Objetivo Descripción
11-10-2010 Entrega Entrega del Documento de Visión
07-11-2010 Proyecto Iteración de Comienzo
07-12-2010 Proyecto Iteración de Elaboración
13-01-2011 Proyecto Iteración de Construcción
01-01-2011 Proyecto Iteración de Transición
07-02-2011 Presentación Entrega

• Interacción con sistemas externos
En efecto, nuestra aplicación tendrá que comunicarse con una base de datos que
estará instalada en un servidor externo. Necesitaremos pues, conexión constante a
Internet por tratarse de una aplicación en red.

7


STAKEHOLDERS:
STAKEHOLDERS Miembros
Serán los organismos o elementos que podrán influir en el desarrollo de nuestro
proyecto ya sea por ser los que lo financian o por ser los usuarios finales de la
aplicación. A continuación exponemos los principales stakeholders de nuestro
proyecto.

• Jesús Salvador Aguilar Ruiz
Director Escuela Superior Politécnica
Capacidad de maniobra en el proyecto: Alta (Financiación)

• Norberto Díaz Díaz
Coordinador ISG2
Capacidad de maniobra en el proyecto: Alta (Usuario Final)

• Roberto Ruiz Sánchez
Profesor ISG2

• Francisco Antonio Gómez Vela
Profesor ISG2

8


STAKEHOLDERS:
STAKEHOLDERS ITERACIÓN de COMIENZO
Tras la primera reunión mantenida con los responsables y stakeholders de la
Universidad Pablo de Olavide, se decide seguir para adelante con el proyecto SGT
(Sistema de Gestión de Tutorías) y profundizar así, sobre todo, en los requisitos
funcionales del sistema.

En esta parte del documento nos centraremos en explicar de una forma más completa
el funcionamiento de la aplicación, como sería el uso por parte del usuario. Nos
servimos además, de diagramas de casos de usos de nivel 0 y 1 para hacer más
comprensible ésta explicación. Se espera pues, que sin tener el sistema construido,
diseñado e implementado, el lector de éste documento pueda hacerse una idea
aproximada de lo que será la aplicación en su estado final.

9


Requisitos funcionales
Exponemos a continuación y en mayor detalle, los requisitos funcionales de la
continuación
aplicación a desarrollar, el SGT, Sistema de Gestión de Tutorías. Cabe destacar que,
si en al anterior documento denominábamos la división de estos requisitos como
módulos, ahora utilizaremos el término sistema por ser más preciso y técnico para
término
nuestro estudio.

Antes de nada, consideramos oportuno exponer unas consideraciones generales y
comunes a todos los sistemas de nuestra aplicación. Son las siguientes:

• La totalidad de profesores que presenta la aplicación viene de unas tablas en
la base de datos que no son gestionadas por el sistema más que a modo
informativo. El alta o inserción de estos datos será un proceso ajeno a nuestro
sistema.

• La totalidad de alumnos que presenta la aplicación viene de unas tablas en la
base de datos que no son gestionadas por el sistema más que a modo
informativo. El alta o inserción de estos datos será un proceso ajeno a nuestro
sistema.

• Tanto la lista de asignaturas como sus correspondientes temas vienen de unas
tablas en la base de datos que no son gestionadas por el sistema más que a
as
modo informativo. El alta, inserción y relación de estos datos será un proceso
ajeno a nuestro sistema.

• La disponibilidad semanal y horaria de los profesores para celebrar una tutoría
viene de unas tablas en la base de datos que no son gestionadas por el
sistema más que a modo informativo. El alta, inserción o relación de estos
datos será un proceso ajeno a nuestro sistema.

• La disponibilidad horaria de las aulas de la universidad para la celebración de
una tutoría viene de unas tablas en la base de datos que no son gestionadas
por el sistema más que a modo informativo. El alta o inserción de estos datos
será un proceso ajeno a nuestro sistema.

10


SISTEMA DE TUTORÍAS: Gestión de tutoría
tutorías
Propósito
Este módulo o división del sistema se encargará de responder a la petición de tutorías
por parte de cualquier alumno o grupo de alumnos. Se puede apreciar que esta
gestión de tutorías tiene dos elementos principales, la petición y la proporción de
éstas.

Descripción
Para entender el funcionamiento de este sistema de tutorías debemos exponer antes
unas premisas a tener en cuenta:

• Una tutoría nunca va dirigida a un profesor en concreto, sino al conjunto de
profesores asociados a un tema, por lo cual, la notificación de petición de
cual,
tutoría es enviada a dichos profesores por igual.

• La lista de profesores anteriormente mencionada corresponde a los profesores
asociados a un tema, el cual pertenece a una asignatura concreta.

• Una tutoría no puede dar lugar a una queja. Se considera innecesario puesto
toría lugar
que la celebración de la tutoría es algo real y físico por lo que las quejas
podrán realizarse en el momento por cualquier alumno.

Expuesto esto, pasamos a describir el funcionamiento del sistema que nos o
ocupa.

Para la realización o celebración de una tutoría es necesaria la solicitud de ésta por
parte de, al menos, un alumno. Cuando éste alumno desea disfrutar de una tutoría
tiene dos opciones, solicitar una nueva tutoría o suscribirse a una ya existente. Hecho
esto, se enviará automáticamente un correo electrónico a todos los profesores
asociados al tema del que trate la tutoría (uno por cada alumno suscrito). Este correo
contendrá la siguiente información:

• Datos del alumno que solicita nueva tutoría o se suscribe a una ya existente.
• Datos de los profesores suscritos a la tutoría por asociación al tema elegido.
• Lista en orden cronológico con la totalidad de alumnos suscritos a dicha tutoría.

Cuando uno de los profesores lo considere oportuno, podrá cerrar y publicar la fecha
cerrar
de la celebración bajo su docencia. En este momento, el sistema generará
automáticamente la fecha, hora y lugar de dicha celebración y la publicará en la
aplicación. Además de esto, se enviará un correo electrónico a todos los alumno y
todos alumnos
profesores suscritos restantes para dejar constancia del proceso. Este correo
contendrá la siguiente información:

• Datos del profesor que imparte la tutoría.
• Fecha, hora y lugar de la tutoría.
• Lista en orden cronológico con la totalidad de alumnos suscritos a dicha tutoría.
suscritos

Celebrada la tutoría, será el turno de realizar las valoraciones al profesor.

Veamos ahora y con más detenimiento, aspectos importantes sobre los cuales se
hace interesante un mayor detalle y explicación.

11


• Solicitud de tutoría
Un alumno podrá solicitar una nueva tutoría del tema deseado. Para ello
lumno
deberá comenzar filtrando por la asignatura madre de ese tema, eligiendo
dicho tema y confirmando la solicitud de tutoría. Para dicho alumno, esto será
un proceso transparente pero para el sistema constituirá una serie de cálculos
y procesos internos que harán posible que la petición quede registrada en el
sistema. De estos procesos, el más importante es el concerniente a la
concurrencia de solicitudes. Lo explicamos a continuación.

A la hora de solicitar una tutoría el alumno siempre realizará el mismo proceso
ora
de filtrado por asignatura y tema. Hecho esto será el sistema el que compruebe
la existencia de tutorías de dicho tema. Si no existiese ninguna, se generaría
una nueva petición mientras que, si por el contrario, hubiese una ya existente
mientras
de la cual aún no existiese publicada fecha de celebración alguna, el alumno
simplemente se suscribiría a ella. De ésta última frase se puede deducir que un
alumno nunca podrá suscribirse a una tutoría con fecha de celebración
publicada. En este caso, se generaría pues, una nueva solicitud. Este requisito
funcional realizará el envío de un correo informativo a la lista de profesores
asociados al tema objeto de la tutoría.

• Baja de solicitud de tutoría
olicitud
Para realizar una baja de una solicitud de tutoría, el alumno deberá acceder a
su perfil y seleccionar una en concreto. Seleccionada ésta, el alumno
expresará su intención de darse de baja de dicha solicitud y el sistema
realizará los correspondientes proc
procesos.
Estos procesos darán de baja automáticamente a dicho alumno de la solicitud y
comprobarán a su vez si existen más alumnos suscritos a dicha tutoría. Si
existiesen, la solicitud quedaría tal cual y en caso contrario, al estarse
realizando la baja del único alumno con el que cuenta la presente solicitud,
ésta se eliminaría. En todos los casos, este proceso enviará un correo
electrónico para avisar a la lista de profesores suscritos a la tutoría.

• Publicación de celebración de tutoría
Este proceso también será transparente para todos los usuarios del sistema.
también
Los procesos internos de la aplicación generarán automáticamente la fecha de
celebración de la tutoría en base a la disponibilidad del profesor que haya
aceptado impartirla. La fecha generada será la más próxima posible para el
profesor docente. Hecho esto, se enviarán los anteriormente mencionados
correos a todos los alumnos y al resto de profesores asociados al tema objeto
de la tutoría.

• Cierre de tutoría
Llegado el momento de la celebración de la tutoría, el profesor deberá acceder
a ésta y ejecutar su cierre. Este cierre conllevará el envío de un correo
informativo a los alumnos suscritos, sobre la disponibilidad de valoración de la
tutoría.

• Valoración de tutoría
Una vez que la tutoría se haya celebrado y, posteriormente cerrado, el alumno
celebrado
podrá emitir una valoración sobre la calidad de la docencia del profesor que ha
impartido ésta.

12


SISTEMA DE CONSULTAS: Gestión de consultas
Propósito
Este módulo o división del sistema se encargará de establecer una comunicación
r
entre la parte que establece una consulta y la parte que responde a ésta, alumno y
profesor, respectivamente.

Descripción
Para entender el funcionamiento de este sistema de consulta debemos exponer antes
unas premisas a tener en cuenta:

• Una consulta siempre va dirigida a un profesor en concreto.

• Una consulta siempre tendrá como solicitante a un único alumno.

• La consulta podrá dar lugar a una queja. Dicha queja cerrará automáticamente
la consulta y otorgará una valoración negativa sobre el profesor consultado.

Expuesto esto, pasamos a describir el funcionamiento del sistema que nos ocupa.

Para la realización de una consulta el alumno deberá filtrar nuevamente por asignatura
y elegir posteriormente un tema asociado a ésta. A continuación se presentará una
continuación
lista con los profesores asociados a este tema, de los cuales se deberá elegir a uno
para establecer la consulta. Hecho esto, se enviará automáticamente un correo
electrónico al profesor consultado con la siguiente información:

• Datos del alumno que realiza la consulta.
• Texto descriptivo de la consulta.

Cuando la consulta llega al profesor, si éste decide responder, se genera una
conversación con el alumno que girará en torno al motivo de ésta. Ya sea por
satisfacción con las respuestas del profesor o por deseo de finalizar la conversación,
el alumno podrá cerrar la consulta para terminar el proceso de la forma normal. Ésta
forma normal conllevará una posterior valoración referente a la implicación del
profesor sobre la consulta establec
establecida.

Decimos forma normal puesto que existe otra forma de finalizar una conversación de
consulta por parte del alumno. Ésta forma será la correspondiente cuando el alumno
no se sienta satisfecho por la actitud del profesor (ya sea por ignorancia de éste o por
falta de competitividad) y conllevará la publicación de una queja que generará
automáticamente una valoración negativa sobre el profesor consultado.

Expuesto el funcionamiento de éste sistema, exponemos a continuación una serie de
aspectos que se antojan ser explicados con más detalle.
an

13


• Solicitud de consulta
Similar al proceso de solicitud de tutoría, el alumno deberá escoger una
asignatura y posteriormente filtrará por uno de sus temas hijos. Hecho esto,
finalmente elegirá a uno de los profesores asociados para establecer la
asociados
consulta. Este establecimiento de consulta conllevará el envío de un correo
informativo al profesor consultado.

• Réplica de consulta
Tanto un alumno como un profesor pueden publicar una réplica a una consulta
o respuesta del otro, respectivamente. Ésta réplica conllevará el envío de un
correo informativo al usuario respondido, alumno o profesor.

• Modificación de consulta
Para que tanto un alumno, como un profesor, puedan modificar una consulta,
ésta deberá tener como último mensaje, uno de la propiedad del individuo que
mensaje,
desea modificarla, es decir, si un alumno desea modificar uno de sus
mensajes, solo podrá hacerlo sobre el último de su firma y si, a su vez, es el
último de la conversación en la actualidad y viceversa. Si esta con
condición no se
cumple, no se podrá ejecutar tal modificación.

• Baja o anulación de consulta
Bien porque el alumno ya no necesite respuesta a la consulta o porque se
desee finalizar la conversación éste podrá anular dicha consulta si, y solo si, el
conversación,
profesor consultado aún no ha respondido, en caso contrario solo se podrá
proceder al cierre de ésta. Ésta baja no conllevará valoración alguna por parte
del alumno. Este proceso enviará un correo electrónico al profesor consultado
para ponerle al tanto del abandon del alumno.
abandono

• Cierre de consulta
El cierre de una consulta sólo será posible en el caso de que exista una
conversación entre alumno y profesor, es decir, que el profesor haya
contestado, al menos una vez a la consulta formulada por el alumno. En esta
menos,
situación, se efectuará el cierre y pasará a formar parte de los históricos del
uación,
sistema. Éste cierre conllevará una valoración de la consulta y la actitud del
profesor consultado por parte del alumno, además del envío de un correo
informativo con el estado de la consulta (cerrada) al profesor.

• Valoración de consulta
Una vez cerrada la consulta, el alumno tendrá la posibilidad de valorar la
calidad de la docencia del profesor qu responde a ésta.
que

• Publicación de una queja
En cualquier momento y por cualquier motivo que el alumno considere
procedente, éste podrá publicar una queja sobre la actitud del profesor
consultado. Ésta queja conllevará un cierre automático de la consulta (exista o
no exista conversación entre alumno y profesor) junto con una valoración
negativa para el profesor consultado. Dicho profesor será notificado de esta
circunstancia mediante un correo electrónico.

• Valoración negativa de consulta
Siendo un proceso automático del sistema, vendrá provocada por el cierre de
una consulta que haya dado lugar a la publicación de una queja. Esta
dado
valoración otorgará una puntuación negativa para el profesor consultado.

14


Requisitos no funcionales
Como se pudo observar en la presentación realizada en la anterior iteración, la
aplicación necesita de una serie de requisitos de naturaleza no funcional para
desarrollar su cometido. Estos requisitos son de varios tipos, carga de datos inicial en
el modelo relacional, lenguaje o plataforma de programación y desarrollo, equipos
informáticos a nivel de hardware, etc. Exponemos estas necesidades a continuación:

• Existencia de tabla relacional con la información de cada profesor.

• Existencia de tabla relacional con la información de cada alumno.

• Existencia de tabla relacional con la información de cada asignatura.

• Existencia de tabla relacional con la información de cada tema.

• Existencia de tabla relacional con la información sobre la disponibilidad horaria
de profesores y aulas.

• Plataforma de desarrollo: Java con Java Swing en la interfaz gráfica.

• Tecnología MySQL para el modelo relacional.
ySQL

• Equipo informático. Ordenador personal con conexión permanente a internet.

• Servidor de correo para la gestión de los envíos informativos a alumnos y/o
profesores.

15


Análisis coste-tiempo
tiempo
Se expone a continuación tanto el listado de tareas en las que se va a realizar el
proyecto como la temporalidad de las mismas. También se va a ver una ordenación
por prioridades de las tareas y un presupuesto orientativo del coste del proyecto con
los recursos asignados.

Para el coste del mencionado presupuesto estipulamos los honorarios de nuestro
personal en función de la tabla salarial oficial publicada según convenio colectivo.

Nuestro equipo está compuesto por un analista programador y por dos programadores
analista-programador
Junior, Julio Javier Gámez Ríos Juan López Godoy y José Antonio Jiménez Ruiz,
Ríos,
respectivamente. Según los salarios a 2009 en su total mensual y considerando las
horas totales de un mes estándar como 160 podemos deducir cuánto serán los
160,
honorarios por hora de cada trabajador.

• Analista-programador:
programador: 1.642,41 / 160 horas = 10,26 €/hora ()
• Programador Junio: 1.057,19 / 160 horas = 6,61 €/hora ()

Y las siglas de cada trabajador presentes en el diagrama de tareas son:

• Julio Javier Gámez Ríos - JJ
• Juan López Godoy - JL
• José Antonio Jiménez Ruiz - JA

En la siguiente página puede apreciarse el informe presupuestario de todo el proyecto
SGT.

16


17


Reparto de tareas y priorización
A continuación se exponen las tareas cuya prioridad se considera lo suficientemente
alta para desarrollar en esta parte del proyecto. Se pretende realizar en primera
instancia el sistema de tutorías para ir viendo una primera funcionalidad de la
aplicación.

Dichas tareas se exponen divididas en función de la iteración a la que corresponda
correspondan.
Se hace así debido a la gran extensión del documento y el amplio número de ellas
que, no olvidemos, van aumentando a medida que avanzamos en el desarrollo de
nuestro proyecto.

Documento de Visión

Esta primera planificación corresponde a la realización del documento de visión que
constituye el inicio de nuestro proyecto. Con este documento se pretende acercar de
forma simple y sencilla al cliente el propósito de nuestra aplicación.

Además del mencionado acercamiento al cliente, con el documen de visión se
documento
decide si desarrollar la aplicación o no ya que son los stakeholders los que decidirán y
no,
darán su opinión sobre nuestro trabajo. Serán éstos los que tengan la última palabra y
permitan, dar el pistoletazo de salida y delegar en J3 Developers durante el transcurso
Developers
del proyecto.

18


Iteración de Comienzo - (1)

Iteración de Elaboración - (2)

19


Iteración de Construcción - (3)

Iteración de Transición - (4)

Se omite toda planificación sobre la presentación del proyecto debido a la inexistencia
de dichas fechas.

20


Diagrama de casos de uso
SGT – Sistema de Gestión de Tutorías (
(Nivel 0)

SGT – Sistema de Gestión de Tutorías (Nivel 1)

Como se puede observar, se presentan dos diagramas de casos de uso.
Centrándonos en el segundo, el de nivel 1, podemos ver que lo más llamativo es que
el actor profesor, interactúa muy poco con el sistema. Sus únicas participaciones
consisten en la publicación de la tutoría, el cierre de ésta y la réplica a la consulta de
ión a
un alumno. Se entiende pues, que es una aplicación totalmente destinada para el
beneficio de éste último.

21


STAKEHOLDERS:
STAKEHOLDERS ITERACIÓN de ELABORACIÓN
Tras la segunda reunión con los stakeholders del proyecto SGT, decidimos dar un giro
olders
importante en la orientación y rumbo de nuestro producto. Con la anterior iteración y el
documento SRS como resultado hemos apreciado una disconformidad y descontento
resultado,
por parte de ellos. Así pues, decidimos paliar estas carencias reorganizando el reparto
de tareas y su distribución en el tiempo. Además, de esto se incluyen aportaciones
extra para complementar todo nuestro trabajo.

A continuación, se muestra el diagrama de casos de uso de nivel 1 correspondiente al
Sistema de tutorías.

22


Nomenclatura de re
requisitos funcionales
Como bien se sabe, nuestra aplicación se puede dividir en dos sistemas claramente
diferenciados, el Sistema de Tutorías y el Sistema de Consultas. Observado esto se
.
considera necesario de una nomenclatura sistemática para referirnos a los distintos
requisitos funcionales.

De esta forma, a cada uno de los sistemas se les dará un código acrónimo que estará
compuesto por las siglas del proyecto (SGT) seguido de otro código acrónimo que
distinguirá al sistema al que se refiere. Formado este código, a cada requisito
funcional dentro de un sistema se le otorgará un número precedido de éste que
terminará por dar una diferenciación única en cuanto a requisitos funcionales se
itos
refiere.

La mencionada nomenclatura es la siguiente:

Se detecta una parte común a nivel de aplicación y otra a nivel de sistema.

• SGT – Sistema de Gestión de Tutorías. Siglas a nivel de aplicación
• ST – Sistema de Tutorías. Siglas a nivel de sistema
• SC – Sistema de Consultas. Siglas a nivel de sistema

Siglas Núm. requisito Requisito Código
SGT/ST 1 Solicitud de tutoría SGT/ST-01
2 Publicación de tutoría SGT/ST-02
3 Baja de tutoría SGT/ST-03
4 Cierre de tutoría SGT/ST-04
5 Envío correo solicitud de tutoría SGT/ST-05
6 Envío correo publicación de tutoría SGT/ST-06
7 Envío correo baja de tutoría SGT/ST-07
8 Envío correo cierre de tutoría SGT/ST-08
9 Valoración de tutoría SGT/ST-09
SGT/SC 1 Solicitud de consulta SGT/SC-01
2 Réplica de consulta SGT/SC-02
3 Modificación de consulta SGT/SC-03
4 Anulación de consulta SGT/SC-04
5 Cierre de consulta SGT/SC-05
6 Publicación de una queja SGT/SC-06
7 Envío correo solicitud de consulta SGT/SC-07
8 Envío de correo réplica de consulta SGT/SC-08
9 Envío correo modificación de consulta SGT/SC-09
10 Envío correo anulación de consulta SGT/SC-10
11 Envío correo cierre de consulta SGT/SC-11
12 Envío correo publicación de queja SGT/SC-12
13 Valoración de consulta SGT/SC-13
14 Valoración de negativa de consulta SGT/SC-14
15 Cierre automático de consulta SGT/SC-15

23


Priorización de casos de uso
riorización
En función de la planificación de nuestro trabajo, se establece una priorización de
requisitos para el correcto desarrollo del proyecto. Dicha priorización es la siguiente:

1. Solicitud de tutoría (Iteración de Elaboración)
2. Publicación de tutoría (Iteración de Elaboración)
3. Baja de tutoría (Iteración de Elaboración)
4. Cierre de tutoría (Iteración de Elaboración)
5. Envío de correo solicitud de tutoría (Iteración de Elaboración)
6. Envío de correo publicación de tutoría (Iteración de Elaboración)
7. Envío de correo baja de tutoría (Iteración de Elaboración)
8. Envío correo cierre de tutoría (Iteración de Elaboración)
9. Valoración de tutoría (Iteración de Elaboración)
10. Solicitud de consulta (Iteración de Construcción)
11. Réplica de consulta (Iteración de Construcción)
12. Modificación de consulta (Iteración de Construcción)
13. Anulación de consulta (Iteración de Construcción)
ción
14. Cierre de consulta (Iteración de Construcción)
15. Publicación de queja (Iteración de Construcción)
16. Envío correo solicitud de consulta (Iteración de Construcción)
17. Envío correo réplica de consulta (Iteración de Construcción)
18. Envío correo modificación de consulta (Iteración de Construcción)
19. Envío correo anulación de consulta (Iteración de Construcción)
20. Envío correo cierre de consulta (Iteración de Construcción)
21. Envío correo publicación de consulta (Iteración de Construcció
Construcción)
22. Valoración de consulta (Iteración de Construcción)
23. Valoración negativa de consulta (Iteración de Construcción)

24


Casos de uso: Sistema de tutorías
Para ir modelando el sistema y conseguir un mejor entendimiento de la aplicación a
ara
desarrollar, realizamos unos diagramas denominados casos de uso. Estos diagramas
amos
representan la interacción de un actor con una parte del sistema, normalmente, un
requisito funcional.

Cada caso de uso suele corresponderse con un único requisito funcional aunque, por
circunstancias excepcionales, puede representar y satisfacer a varios. Esta situación
ancias
se da en dos de nuestros casos de uso para uno de los sistemas de la aplicación: el
sistema de tutorías. Los casos de uso multifuncionales son los siguientes:

• Valoración: cuyo propósito y realización representa y satisface a:
o Valoración de tutoría - SGT/ST-09
SGT/ST
o Valoración de consulta - SGT/SC-13
SGT/SC

NOTA: El requisito de valoración negativa de consulta ( GT/SC-14) se realiza
(SGT/SC
por el sistema de forma automática y será el resultado la publicación de una
queja. Así pues, no queda satisfecho por este caso de uso.

• Envío de correo: cuyo propósito y realización representa y satisface a:
:
o Envío de correo solicitud de tutoría - SGT/ST-05
SGT/ST
o Envío de correo publicación de tutoría - SGT/ST-06
SGT/ST
o Envío de correo baja de tutoría - SGT/ST-07
SGT/ST
o Envío de correo cierre de tutoría - SGT/ST-08
SGT/ST
o Envío de correo solicitud de consulta - SGT/SC-07
SGT/SC
o Envío de correo réplica de consulta - SGT/SC-08
SGT/SC
o Envío de correo modificación de consulta - SGT/SC-09
SGT/SC
o Envío de correo anulación de consulta - SGT/SC-10
SGT/SC
o Envío de correo cierre de consulta - SGT/SC-11
SGT/SC
o Envío de correo publicación de queja - SGT/SC-12
SGT/SC

25


Nombre: Solicitud de tutoría
Requisito funcional: SGT/ST- -01
Precondiciones:
1. Usuario previamente logado con perfil “alumno”.
Postcondiciones:
1. Solicitud de tutoría por parte del alumno.
Flujo normal:
1. El alumno selecciona una asignatura.
2. Elegida la asignatura, el gestor de carga proporciona la lista de temas asociados a ésta. Para esta
operación hará uso del Agente.
3. El alumno elige un tema y confirma la solicitud de tutoría mediante el botón “Solicitar tutoría”.
4. Este botón lanza el gestor de solicitud que comprueba la existencia de alguna tutoría que responda
al tema elegido. Si existe, se suscribe al alumno y si no, se crea una nueva. Para esta operación
hará uso del Agente.
5. En la ventana de solicitud se muestra un mensaje informativo al usuario sobre el estado de la
solicitud.
6. Se ejecuta el caso de uso “Envío de correo” que enviará notificación a los profesores suscritos a la
tutoría con los detalles de la solicitud del alumno.
Flujo Alternativo:

Descripción:
El alumno, mediante la ventana de solicitud, puede solicitar una tutoría correspondiente al tema deseado.
Entidades de análisis:

Boceto de pantalla:

26


Nombre: Publicación de Tutoría
Precondiciones:
1. Usuario previamente logado con perfil “Profesor”.
Flujo normal:
1. El profesor accede a la ventana “Mis tutorías” pestaña “Tutorías solicitadas”.
tutorías”,
2. Al cargarse dicha ventana, el gestor de carga habrá comprobado cuales de las tutorías están en
estado para posibilitar su publicación. Para esta operación hará uso del Agente.
3. El profesor confirma su publicación pulsando en el botón “Publicar tutoría” que deberá estar activo.
en
4. Este botón lanza el gestor de publicación que comprueba la disponibilidad de publicación de esa
tutoría. Para esta operación hará uso del Agente.
Agente.*
5. Se observa que dicha tutoría no tiene publicada su fec de celebración y se procede a publicar
fecha
dicha fecha mediante el gestor de publicación. Para esta operación hará uso del Agente.
6. En la ventana “Mis tutorías” se muestra un mensaje informativo al profesor con los datos de la
publicación de fecha de la tuto
tutoría.
7. Se ejecuta el caso de uso “Envío de correo” que enviará notificación a alumnos y profesores
suscritos a la tutoría con los datos de su publicación.

*Se realiza una segunda comprobación sobre la disponibilidad de publicación ya que puede darse que un profesor decida
instantes antes publicar dicha fecha. Esta comprobación, es la que da origen al flujo alternativo.
Flujo Alternativo:
1. El profesor accede a la ventana “Mis tutorías”.
estado para posibilitar su publicación. Para esta operación hará uso del Agente.
3. El profesor confirma su publicación pulsando en el botón “Publicar tutoría” que deberá estar activo.
4. Este botón lanza el gestor de publicación que comprueba la no disponibilidad de publicación de esa
tutoría. Para esta operación hará uso del Agente.
Agente.*
5. Se observa que dicha tutoría tiene publicada su fecha de celebración.
e
6. En la ventana “Mis tutorías” se muestra un mensaje informativo al profesor con la imposibilidad de
utorías”
impartir la tutoría.
*Se realiza una segunda comprobación sobre la disponibilidad de publicación ya que puede darse que un profesor decida
instantes antes publicar dicha fecha. Esta comprobación, es la que da origen al flujo alternativo.
a.
Descripción:
Lugar de la aplicación donde el profesor podrá elegir que tutorías desea impartir.

Boceto de pantalla:

27


Nombre: Baja o anulación de tutoría
Precondiciones:
1. Usuario previamente logado con perfil “alumno”.
2. La tutoría debe estar creada.
Flujo normal:
1. El alumno accede a la ventana “Mis tutorías” pestaña “Tutorías solicitadas”.
tutorías”,
estado para posibilitar su baja o anulación. Para esta operación hará uso del Agente.
3. El alumno confirma su baja pulsando en el botón “Baja de tutoría” que deberá estar activo.
4. Este botón lanza el gestor de baja o anulación que comprueba que dicha tutoría no tenga publicada
za
fecha de celebración. Para esta operación hará uso del Agente.
Agente.*
5. Se observa que dicha tutoría no tiene publicada su fecha de celebración. Se comprueba si existen
más alumnos suscritos a la tutoría además del que solicita la baja. Si existen, se procede
únicamente a realizar la mencionada baja. Si no existen, además de la baja, se elimina la tutoría que
queda sin alumnos suscritos. Para esta operación hará uso del Agente.
6. En la ventana “Mis tutorías” se muestra un mensaje informativo sobre el estado de la baja.
a
7. Se ejecuta el caso de uso “Envío de correo” que enviará notificación a los profesores suscritos a la
tutoría con los detalles de la baja del alumno.

*Se realiza una segunda comprobación sobre la publicación de la fecha de celebración de la tutoría ya que puede darse que un
unda
profesor decida instantes antes publicar dicha fecha. Esta comprobación, es la que da origen al flujo alternativo.
Flujo Alternativo:
1. El alumno accede a la ventana “Mis tutorías”.
3. El alumno confirma su baja pulsando en el botón “Baja de tutoría” que deberá estar activo.
4. Este botón lanza el gestor de baja o anulación que comprueba que dicha tutoría no tenga publicada
fecha de celebración. Para esta operación hará uso del Agente.
Agente.*
5. Se observa que dicha tutoría tiene publica su fecha de celebración.
publicada
8. En la ventana “Mis Tutorías” se muestra un mensaje informativo sobre la imposibilidad de baja de la
tutoría.

*Se realiza una segunda comprobación sobre la publicación de la fecha de celebración de la tutoría ya que puede darse que un
profesor decida instantes antes publicar dicha fecha. Esta comprobación, es la que da origen al flujo alternativo.
Descripción:
Aquí, el alumno podrá desvincularse de las tutorías seleccionadas.

Boceto de pantalla:

28


Nombre: Cierre de tutoría
Precondiciones:
1. Usuario previamente logado con perfil “profesor”.
2. Tutoría ya celebrada (fecha actual igual o posterior a fecha de celebración de tutoría).
Postcondiciones:
1. Disponibilidad de valoración de tutoría por parte del alumno.
Flujo normal:
1. El profesor accede a la ventana “Mis tutorías” pestaña “Tutoría a cerrar”.
tutorías”,
estado para posibilitar su cierre. Para esta operación hará uso del Agente.
3. El profesor confirma su cierre pulsando en el botón “Cerrar tutoría” que deberá estar activo.
4. Este botón lanza el gestor de cierre que cerrará dicha tutoría. Para esta operación hará uso del
Agente.
5. Se ejecuta el caso de uso “Envío de correo” que enviará notificación a los alumnos suscritos a la
tutoría para notificarles de la disponibilidad de su valoración.
Flujo Alternativo:

Descripción:
Llegada la hora de celebración de la tutoría, el profesor deberá ejecutar su cierre.

Boceto de pantalla:

29


Nombre: Envío de correo
Requisito funcional: SGT/ST--05
SGT/ST--06
SGT/ST--07
SGT/ST--08
Precondiciones:
1. Ejecución de llamada desde otro caso de uso.
sde
Flujo normal:
1. El gestor de envío confecciona el mensaje y lo envía a todos sus destinatarios, alumnos y/o
profesores.
Flujo Alternativo:

Descripción:
Caso de uso común para otros que realizan una llamada con el objetivo de enviar correo de notificación a
determinados destinatarios.

Boceto de pantalla:
Sin pantalla.

30


Nombre: Valoración
Requisito funcional: SGT/ST-09
SGT/ST
Precondiciones:
1. Usuario previamente logado con perfil “a “alumno”.
2. Tutoría cerrada o consulta cerrada sin publicación de queja.
onsulta
Postcondiciones:
1. Tutoría o consulta valoradas.
onsulta
Flujo normal:
1. El alumno accede a la ventana “Mis tutorías” pestaña “Tutorías a valorar”.
entana tutorías”,
carga
estado para posibilitar su valoración. Para esta operación hará uso del Agente.
aloración.
3. El alumno otorgará valores a una serie de parámetros evaluadores y confirmará su valoración
lumno
pulsando el botón “Emitir valoración” que deberá estar activo.
aloración”
4. El gestor de valoración registrará la valoración emitida por el alumno y calculará la media actual de la
oración lumno
valoración que tiene el profesor. Para esta operación hará uso del Agente.
5. En la ventana “Mis tutorías” se muestra un mensaje informativo al usuario sobre el estado de la
valoración.
Flujo Alternativo:

Descripción:
El alumno podrá opinar y emitir una valoración sobre la implicación y calidad del profesor en una tutoría o
consulta.

Boceto de pantalla:

31


Matriz de trazabilidad Sistema de tutorías
trazabilidad:
Mediante esta aportación extra podemos comprobar si los casos de uso que hemos
realizado satisfacen todos los requisitos funcionales del sistema de tutorías.

Dicha matriz consistirá en una tabla que enfrentará a casos de uso contra requisitos
funcionales. En la unión de cada elemento de una dimensión con el de la otra,
podremos ver si ese caso de uso satisface a ese requisito funcional concreto.

De esta manera podemos llevar un correcto control de nuestro trabajo para enmendar
posibles errores.

Casos de uso – Sistema de tutorías
SGT/ST
Nombre Requisito 01 02 03 04 05 06 07 08 09
Solicitud de tutoría
Publicación de tutoría
Baja de tutoría
Cierre de tutoría
Envío de correo
Valoración

32


Diagramas de Secuencias: Sistema de tutorías
Para ir diseñando el sistema y seguir contribuyendo a un mejor entendimiento de toda
la aplicación, se realizan los diagramas de secuencia que siguen la traza estipulada en
cada flujo de un caso de uso.

Así pues, realizaremos un diagrama de secuencia por cada flujo que contenga un caso
flujo
de uso pero, ¿Qué entendemos por flujo normal y flujo alternativo de un caso de uso
uso?
Para disipar tal duda damos respuesta a la anterior pregunta.

Un caso de uso siempre tiene, al menos, un flujo normal. Por flujo normal entendemos
todo aquel que cumpla el cometido del caso de uso, tenga o no tenga bifurcaciones en
su interior siempre y cuando no afecten al resultado del proceso. Por tanto, flujo
alternativo será todo aquel resultante de alguna decisión que haga obligatoria una
bifurcación e imposibilite el cometido del caso de uso.
cación

EJEMPLO: si un alumno decide darse de baja de una tutoría se comprobará antes
:
que ésta no tenga dicha fecha publicada.

• Flujo normal: la tutoría no tiene fecha de celebración publicada y se continúa
:
comprobando si el alumno que solicita la baja es el último suscrito a ésta. Sea
ando
o no el último y llegados a este punto, el alumno se va a dar de baja, lo que
cambia es si se elimina la tutoría o no. Es por tanto, flujo normal ya que cumple
el objetivo del caso de uso relacionado.

• Flujo alternativo: la tutoría tiene fecha de celebración publicada. Es por tanto,
flujo alternativo ya que el alumno no puede darse de baja de la tutoría. Este
flujo no cumple el objetivo del caso de uso relacionado.

Dicho esto, se entiende que estos diagramas mostrarán a veces decisiones en su
interior, las cuales, forman parte del flujo y no pueden, ni ser aisladas, ni dar lugar a un
nuevo flujo alternativo.

NOTA: Puede apreciarse que en casi todos los casos aparece un controlador llamado
“Gestor de carga” ya que se necesita para cargar los datos iniciales para que el
usuario pueda interactuar con la pantalla y realizar las acciones descritas en los casos
de uso relacionados con los diagramas de secuencia.

33


Diagrama: Solicitud de tutoría
Flujo: Normal
Caso de uso relacionado: Solicitud de tutoría
Requisitos funcionales: SGT/ST-01
Diagrama:

34


Diagrama: Publicación de tutoría
Flujo: Normal
Caso de uso relacionado: Publicación de tutoría
Diagrama:

35


Flujo: Alternativo
Diagrama:

36


Diagrama: Baja de tutoría
Flujo: Normal
Caso de uso relacionado: Baja de tutoría
Diagrama:

37


Flujo: Alternativo
Diagrama:

38


Diagrama: Cierre de tutoría
Flujo: Normal
Diagrama:

39


Diagrama: Envío de correo
Flujo: Normal
Caso de uso relacionado: Envío de correo
SGT/ST-06
SGT/ST-07
SGT/ST-08
Diagrama:

En este caso puede apreciarse que se necesita la llamada de otro para entrar en
acción.

40


Diagrama: Valoración de tutoría
Flujo: Normal
Caso de uso relacionado: Valoración
Diagrama:

41


Diagramas Entidad
Entidad-Relación: Sistema de tutorías
El siguiente diagrama es el de Entidad Relación que dará origen a la posterior
Entidad-Relación
construcción de la base de datos.

En dicho diagrama se omite la inclusión de entidades de disponibilidad horaria de
profesor y de aulas por deseo de realizar puramente el modelo relacional que compete
a nuestro trabajo. Por el contrario se exponen las entidades de asignatura y tema por
estar presente en los flujos de los casos de uso.

Por otro lado, se expone la cardinalidad entre las entidades Profesor y Tutoría
indicando que una tutoría puede ser impartida por uno o más profesores.
Esto es así para poder expresar que una tutoría, antes de ser publicada su fecha de
celebración, tiene suscrito un grupo de profesores. Cuando uno de los profesores
suscritos decida impartirla, implementaremos algún mecanismo que la asocie
unívocamente a dicho profesor.
ocamente

42


Diagramas de tablas Sistema de tutorías
tablas:
Como dijimos anteriormente la realización del diagrama Entidad-Relación daría lugar
anteriormente, Relación
a la construcción de la base de datos. El siguiente diagrama es el propio que ofrece
nuestro administrador de MySQL para visionar de forma gráfica el modelo relacional
dor
que hemos creado. Es ahora cuando incluimos todas las tablas de disponibilidades por
ser necesarias en nuestro sistema. El código generador de las tablas se adjunta
aparte como anexo en la ca
carpeta del proyecto.

43


Diagramas de Actividades Sistema de tutorías
Actividades:
Como aportación extra y para seguir complementando toda la información sobre el
sistema de tutorías, exponemos los diagramas de actividades. Un diagrama de
actividades representa los flujos de trabajo paso a paso de negocio y operacionales de
los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de
control general.

Se realiza un diagrama de actividades por cada caso de uso, quedando patente en
cada uno de ellos, los flujos normales y alternativos que pueda presentar cada caso.

Diagrama: Solicitud de tutoría
Diagrama:

44


Diagrama:

45


Diagrama:

46


Diagrama: Cierre de tutoría
Caso de uso relacionado: Cierre de tutoría
Diagrama:

47


Diagrama: Envío de correo
Caso de uso relacionado: Envío de correo
SGT/ST-06
SGT/ST-07
SGT/ST-08
Diagrama:

48


Diagrama: Valoración de tutoría
Caso de uso relacionado: Valoración
Diagrama:

49


Tarjetas CRC: Sistema de tutorías
Las tarjetas CRC (clase, responsabilidad y colaboración) son una metodología para el
diseño de software orientado por objetos creada por Kent Beck y Ward Cunningham.
Esta aportación extra permite ver las clases como algo más que depositorio de datos,
sino conocer el comportamiento de cada una en un alto nivel.
rtamiento

Entidades con responsabilidad definida

TUTORIA
Responsabilidades Colaboraciones
Alta tutoría (crea tutoría) Tutoría
Publicación de tutoría (asigna lugar, fecha y hora) Profesor
Cierre tutoría ( pone disponible la tutoría para su valoración) Profesor
Baja tutoría (el alumno se borra de la tutoría) Alumno

PROFESOR
Publicar tutoría Tutoría
Cerrar tutoría Tutoría

ALUMNO
Solicitar tutoría Tutoría
Valorar tutoría Valoraciones tutorías
Baja tutoría Tutoría

VALORACIÓN
Valorar tutoría Tutoría
Asigna nota media al profesor Profesor

MENSAJE
Envío de correo Profesor
Alumno
Tutoría

Entidades sin responsabilidad definida
Asignatura
Tema

50


Repositorio Documental DropBox
Documental:

Debido al gran número de ficheros que vamos generando a medida que el proyecto
avanza y la necesidad de sincronización entre cada miembro del grupo para poder
estar al tanto de todos los cambios, observamos una importante necesidad de trabajar
mediante un repositorio de documental que nos permita acceder en cualquier
momento a la totalidad del proyecto.

Elegimos Dropbox (además de por su funcionamiento en Internet) por contar con una
aplicación para dispositivos móviles de última generación. Como los 3 inte
integrantes de
J3 Developers contamos que teléfonos móviles con tal servicio, se hace sumamente
interesante establecer un exhausto control en cualquier lugar donde nos encontremos.

Además de esto, la verdadera aportación extra es la invitación a dos de los
stakeholders a las instalaciones de SGT en DropBox. Así pues, podrán acceder
keholders
remotamente a nuestro sitio y supervisar e trabajo que vamos realizando.

Los stakeholders a los que decidimos invitar son:

• Norberto Díaz Díaz
Coordinador ISG2

• Roberto Ruiz Sánchez
Profesor ISG2

51


Cuestionario de calidad – Primera parte
A continuación se exponen algunas preguntas que los integrantes de J3 Developers
nos hemos planteado durante la realización de la presente iteración, la de elaboración.
Ésta es la última de las aportac
aportaciones extra.

1. ¿Muestra el control de versiones todo el desarrollo y correcciones que se
realizan en el proyecto?
Todo el trabajo que vamos re lizando se plasma en la tabla de control de
realizando
versiones y se detallan las tareas a realizar en la iteración actual.

2. ¿El avance del proyecto sigue fiel con la idea inicial expuesta en el apartado
El
“Oportunidad de negocio”?
Totalmente. Solo se está profundizando y explotando dicha idea. La aplicación
otalmente.
será, lo que Universidad desea.

3. ¿Están contemplados todos los riesgos a los que se somete el proyecto
proyecto?
Hasta el momento entendemos que sí.

4. ¿Están los requisitos funcionales claramente definidos? ¿Se necesita
alguno más?
A medida que vamos avanzando en el desarrollo del proyecto vamos cambiando
los requisitos de la aplicación. Llegadas a esta iteración, la de elaboración,
observamos que no serán necesarios más cambios en los requisitos.

5. ¿Cuántos requisitos funcionales tie la aplicación?
tiene
Tras los últimos cambios, 24
os 24.

6. ¿La nueva reorganización y el reparto de tareas contempla todas las tareas
necesarias hasta el final del proyecto?
El reparto de tareas y el fichero proyect es algo que va cambiando en cada
iteración. Para la presente consideramos que hemos plasmado fielmente lo que
resta de proyecto

7. ¿Los casos de uso son claros y fáciles de entender? ¿Puede el lector
hacerse a la idea del funcionamiento del requisito funcional que satisfacen?
Siguen al pie de la letra el texto de su requisito funcional relacionado.

8. ¿Satisfacen las entidades de análisis a los objetos nombrados en los flujos
de los casos de uso?
Todo lo mencionado en los flujos de los casos de uso aparece en el diagrama
como una entidad de análisis.

9. En los diagramas de secuencia, ¿siguen una perfecta trazabilidad en función
iguen
del caso de uso relacionado?
Precisamente en eso es lo que hemos hecho un mayor hincapié. El lector podrá
saber cómo funciona un requisito funcional sin leer el caso de uso relacionado.

10. En los diagramas de secuencia, ¿están recogidos todos los flujos
stán
pertenecientes a un caso de uso?
Existe un diagrama de secuencia por cada flujo del caso de uso relacionado.

52


11. En los diagramas de secuencia, ¿está expresada la llamada a un segundo
stá
caso de uso dentro de un primero?
Mediante una línea dirigida a un objeto tipo “Nota”.

12. En los diagramas de secuencia, ¿ayudan y complementan el entendimiento
yudan
de un requisito funcional
funcional?
Como hemos dicho anteriormente, el lector puede saber el funcionamiento y
desempeño de un requisito funcional sin leer el caso de uso. Si la lectura es de los
sempeño
dos diagramas, la complementación al entendimiento está servida.

13. En los diagramas de actividades, ¿se expresan los flujos existentes en el
caso de uso relacionado?
Se realiza un diagrama de actividades por cada caso de uso y en cada uno de
ellos se expresan los diferentes flujos a los que da lugar dicho caso.

53


STAKEHOLDERS:
STAKEHOLDERS ITERACIÓN de CONSTRUCCIÓN
Posteriormente a la reunión correspondiente a la entrega de la segunda iteración,
destacamos y advertimos correcciones en nuestro trabajo para así conseguir evitar el
descontento de los stakeHolders.

En esta tercera iteración se incluye la parte restante del diseño de la aplicación. El
diseño del patrón MVC para la parte del sistema de consultas del SGT. Además de
del
esto, se incluye el patrón MVC genérico de toda la aplicación junto con su
implementación del patrón DAO.

Ya que en esta iteración nos centraremos en profundizar en el análisis y diseño del
sistema de consultas. A continuación, se muestra el diagrama de casos de uso de
nivel 1 correspondiente al dicho sistema.

54


Casos de uso: Sistema de consultas
Siguiendo con el modelado del sistema y para mejorar el entendimiento de éste,
volvemos a recurrir a los diagramas de caso de uso, esta vez, concernientes al
sistema de consultas.

NOTA: Exponemos (de nuevo) los casos de uso multifuncionales de “Envío de correo”
:
y “Valoración” ya que consideramos mejor opción duplicar información que
arriesgarnos a un mal entendimiento de nuestro objetivo debido a la omisión de ésta.

55


Nombre: Solicitud de consulta
Requisito funcional: SGT/SC-01
SGT/SC
Precondiciones:
Postcondiciones:
1. Solicitud de consulta por parte del alumno.
Flujo normal:
1. El alumno selecciona una asignatura.
2. Elegida la asignatura, el gestor de carga proporciona la lista de temas asociados a ésta. Para esta
3. Elegido el tema, el gestor de carga proporcionará la lista de profesores asociados a éste. Para esta
4. El alumno elige un profesor, introduce el texto correspondiente a su consulta y confirma la solicitud
mediante el botón “Solicitar consulta”.
5. Este botón lanza el gestor de solicitud que relacionará la actual consulta del alumno con el profesor
l
consultado.
6. En la ventana de solicitud se muestra un mensaje informativo al usuario sobre el estado de la
solicitud.
7. Se ejecuta el caso de uso “Envío de correo” que enviará notificación al profesor consultado con los
á
detalles de la solicitud del alumno.
Flujo Alternativo:

Descripción:
El alumno, mediante la ventana de solicitud, puede solicitar una consulta correspondiente al tema
deseado.

Boceto de pantalla:

56


Nombre: Réplica de consulta
SGT/SC
Precondiciones:
1. Consulta existente, con al menos, un mensaje.
Postcondiciones:
1. Consulta replicada.
Flujo normal:
1. El usuario (alumno o profesor) accede a la ventana “Mis consultas”, pestaña “Consultas solicitadas”.
2. Al cargarse dicha ventana, el gestor de carga habrá comprobado cuales de las consultas están en
estado para posibilitar su réplica. Para esta operación hará uso del Agente.
3. El usuario introduce el texto correspondiente a su réplica y la confirma pulsando en el botón “Publicar
troduce
réplica” que deberá estar activo.
4. Este botón lanza el gestor de réplica que complementa la consulta del alumno con el nuevo mensaje
del usuario.
5. En la ventana de “Mis consultas” se muestra un mensaje informativo al usuario sobre el estado de la
s
réplica.
6. Se ejecuta el caso de uso “Envío de correo” que enviará notificación al usuario respondido con los
datos de la réplica.
Flujo Alternativo:

Descripción:
Lugar de la aplicación donde el usuario podrá replicar la consulta de otro.

Boceto de pantalla:

57


Nombre: Modificación de consulta
SGT/SC
Precondiciones:
1. Consulta existente, con último mensaje propiedad del usuario que desea modificar la consulta.
Postcondiciones:
1. Consulta modificada por el usuario.
Flujo normal:
1. El usuario (alumno o profesor) accede a la ventana “Mis consultas”, pestaña “Consultas solicitadas”.
estado para posibilitar su modificación. Para esta operación hará uso del Agente.
3. El usuario introduce el texto correspondiente a su modificación y la confirma pulsando en el bot
botón
“Modificación consulta” que deberá estar activo.
4. Este botón lanza el gestor de modificación que realizará la modificación correspondiente.
5. En la ventana “Mis consultas” se muestra un mensaje informativo al usuario sobre el estado de la
modificación.
6. En la ventana “Mis consultas se muestra un mensaje informativo sobre el estado de la modificación
consultas” nformativo modificación.
Flujo Alternativo:

Descripción:
Aquí, el alumno podrá cerrar las consultas seleccionadas.

Boceto de pantalla:

58


Nombre: Baja o anulación de consulta
SGT/SC
Precondiciones:
1. Usuario previamente logado con perfil “a
“alumno”.
2. La consulta debe estar creada.
Postcondiciones:

Flujo normal:
1. El alumno accede a la ventana “Mis consultas”, pestaña “Consultas solicitadas”.
3. El alumno confirma su baja pulsando en el botón “Baja de consulta” que deberá estar activo.
4. Este botón lanza el gestor de baja o anulación que comprueba que dicha consulta no tenga réplica
por parte del profesor consultado. Para esta operación hará uso del Agente.*
5. Se observa que dicha consulta no tiene réplica alguna por parte del profesor, se procede pues, a su
no
baja o anulación. Para esta operación hará uso del Agente.
6. En la ventana “Mis consultas” se muestra un mensaje informativo sobre el estado de la baja.
detalles de la baja del alumno.

*Se realiza una segunda comprobación sobre la réplica de la consulta ya que puede darse que un profesor decida instantes
antes replicarla. Esta comprobación, es la que da origen al flujo alternativo.
.
Flujo Alternativo:
3. El alumno confirma su baja pulsando en el botón “Baja de consulta” que deberá estar activo.
”
4. Este botón lanza el gestor de baja o anulación que comprueba que dic consulta no tenga réplica
dicha
por parte del profesor consultado. Para esta operación hará uso del Agente.
Agente.*
5. Se observa que dicha consulta tiene réplica por parte del profesor.
6. En la ventana “Mis consultas” se muestra un mensaje informativo sobre la imposibilidad de baja de
consultas”
la consulta.

* Se realiza una segunda comprobación sobre la réplica de la consulta ya que puede darse que un profesor decida instantes
antes replicarla. Esta comprobación, es la que da origen al flujo alternativo.
.
Descripción:
Aquí, el alumno podrá desvincularse de las consultas seleccionadas.

Boceto de pantalla:

59


Nombre: Cierre de consulta
SGT/SC
Precondiciones:
1. Consulta existente, con réplica por parte del profesor.
Postcondiciones:
1. Consulta cerrada por parte del alumno y posibilitada para su valoración.
Flujo normal:
estado para posibilitar su cierre. Para esta operación hará uso del Agente.
3. El alumno confirma su cierre pulsando en el botón “Cierre de consulta” que deberá estar activo.
4. Este botón lanza el gestor de cierre que realizará el cierre correspondiente.
otón
5. En la ventana “Mis consultas” se muestra un mensaje informativo sobre el estado del cierre.
detalles de la baja del alumno.
Flujo Alternativo:

Descripción:

Boceto de pantalla:

60


Nombre: Publicación de queja
SGT/SC
Precondiciones:
“alumno”.
2. Consulta no cerrada.
Postcondiciones:

Flujo normal:
estado para posibilitar la publicación de una queja. Para esta operación hará uso del Agente.
3. El alumno pulsará el botón “Publicar queja” y acto seguido observará la nueva pantalla para exponer
observará
el motivo de dicha queja. Rellenos los campos de la queja, ésta se hará efectiva pulsando otro botón,
también llamado, “Publicar queja”.
4. El gestor de publicación de queja gestionará la queja emitida por el alumno y cerrar
cerrará
automáticamente la consulta propietaria de ésta. Llamada al caso de uso “Cierre automático de
consulta”.
queja.
6. Se ejecuta el caso de uso “Cierre automático de consulta” que cerrará automáticamente la
Cierre
consultada formulada por el alumno.
detalles de la queja del alumno.
8. Se ejecuta el caso de uso “Valoración negativa” donde quedará reflejada la insatisfacción del alumno
negativa”
para/con el profesor consultado.
Flujo Alternativo:

Descripción:
El alumno podrá publicar una queja sobre la implicación y calidad del profesor en una consulta.

Boceto de pantalla:

61


Nombre: Envío de correo
SGT/SC
SGT/SC-08
SGT/SC
SGT/SC-09
SGT/SC
SGT/SC-10
SGT/SC
SGT/SC-11
SGT/SC
SGT/SC-12
SGT/SC
Precondiciones:
1. Ejecución de llamada desde otro caso de uso.
sde
Postcondiciones:

Flujo normal:
1. El gestor de envío confecciona el mensaje y lo envía a todos sus destinatarios, alumnos y/o
profesores.
Flujo Alternativo:

Descripción:
Caso de uso común para otros que realizan una llamada con el objetivo de enviar correo de notificación a
determinados destinatarios.

Boceto de pantalla:
Sin pantalla

62


Nombre: Valoración
SGT/SC
Precondiciones:
2. Tutoría cerrada o consulta cerrada sin publicación de queja.
onsulta
Postcondiciones:
1. Consulta o tutoría valoradas.
Flujo normal:
1. El alumno accede a la ventana “Mis consultas”, pestaña “Consultas a valorar”.
estado para posibilitar su valoración. Para esta operación hará uso del Agente.
3. El alumno otorgará valores a una serie de parámetros evaluadores y confirmará su valoración
pulsando el botón “Emitir valoración” que deberá estar activo.
4. El gestor de valoración registrará la valoración emitida por el alumno y calculará la media actual de la
valoración que tiene el profesor. Para esta operación hará uso del Agente.
valoración.
Flujo Alternativo:

Descripción:
El alumno podrá opinar y emitir una valoración sobre la implicación y calidad del profesor en una tutoría o
consulta.

Boceto de pantalla:

63


Nombre: Valoración negativa de consulta
SGT/SC
Precondiciones:
“alumno”.
2. Ejecución de llamada desde el caso de uso “Publicación de queja”.
sde
Postcondiciones:
1. Valoración negativa emitida sobre profesor.
Flujo normal:
1. Como consecuencia de la publicación de una queja sobre una consulta, el gestor de valoración
negativa atenderá dicha valoración negativa por parte de un alumno y sobre el profesor consultado
asignándole la nueva media a éste.
Flujo Alternativo:

Descripción:
Caso de uso que se realiza de forma automática presentando la necesidad de ser llamada por otro CU.

Boceto de pantalla:
Sin pantalla

64


Nombre: Cierre automático de consulta
SGT/SC
Precondiciones:
1. Ejecución de llamada desde el caso de uso “Publicación de queja”.
sde
Postcondiciones:
1. Consulta cerrada automáticamente.
Flujo normal:
1. La consulta propietaria de la queja que ejecuta la llamada a este caso de uso, se cerrará
automáticamente mediante el gestor de cierre automático.
Flujo Alternativo:

Descripción:

Boceto de pantalla:
Sin pantalla

65


Matriz de trazabilidad Sistema de consultas
trazabilidad:
Para comprobar la eficacia de los casos de uso anteriormente expuestos, recurrimos
de nuevo y como aportación extra a la siguiente matriz de trazabilidad.
extra,

Casos de uso – Sistema de consultas
SGT/SC
Nombre Requisito 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
Solicitud de
consulta
Réplica de
consulta
Modificación de
consulta
Anulación de
consulta
Cierre de consulta
Publicación de
queja
Envío de correo
Valoración
Valoración
negativa
Cierre automático
de consulta

66


Diagramas de Secuencias: Sistema de consultas

Diagrama: Solicitud de consulta
Flujo: Normal
Caso de uso relacionado: Solicitud de consulta
Requisitos funcionales: SGT/SC-01
Diagrama:

67


Diagrama: Réplica de consulta
Flujo: Normal
Caso de uso relacionado: Réplica de consulta
Diagrama:

68


Diagrama: Modificación de consulta
Flujo: Normal
Caso de uso relacionado: Modificación de consulta
Diagrama:

69

SGT - Documentación de proyecto

SGT - Documentación de proyecto

Recomendados

Recomendados

Más contenido relacionado

Similar a SGT - Documentación de proyecto

Similar a SGT - Documentación de proyecto (20)

Último

Último (20)

SGT - Documentación de proyecto