diff --git a/docs/anexos.pdf b/docs/anexos.pdf index 0a32df7..f31a169 100644 Binary files a/docs/anexos.pdf and b/docs/anexos.pdf differ diff --git a/docs/tex/A_Plan_proyecto.tex b/docs/tex/A_Plan_proyecto.tex index 80993c9..5def350 100644 --- a/docs/tex/A_Plan_proyecto.tex +++ b/docs/tex/A_Plan_proyecto.tex @@ -4,9 +4,9 @@ \section{Introducción} Desde el punto de vista de la planificación temporal, el proyecto sigue la metodología ágil \textit{Scrum}. Permitiendo definir cada uno de los objetivos que se desean alcanzar, los elementos que los componen y su respectiva prioridad. -\textit{Scrum}, de manera muy resumida, trabaja con un \textit{product backlog}, es una lista de prioridades en función del valor de cada tarea. Cuando comienza un \textit{sprint}, se empieza a trabajar en las tareas que se encuentren en el \textit{sprint backlog}, estas han sido extraídas del \textit{product backlog}. En el caso de este proyecto se realiza una reunión de planificación, \textit{sprint planning}, cada dos semanas inicialmente y posteriormente cada semana. +\textit{Scrum}, de manera muy resumida, trabaja con un \textit{product backlog}, es una lista de prioridades en función del valor de cada tarea. Cuando comienza un \textit{sprint}, se empieza a trabajar en las tareas que se encuentren en el \textit{sprint backlog}, estas han sido extraídas del \textit{product backlog}. En el caso de este proyecto se realiza una reunión de planificación, \textit{sprint planning}, cada dos semanas en un inicio y posteriormente cada semana. -Para el control y seguimiento se utiliza una herramienta externa, \textit{Zenhub}, la cual permite la definición de las tareas, el seguimiento de cada una de ellas en función de la planificación póker, seguimiento de cada \textit{sprint}, el versionado, etc. +Para el control y seguimiento se utiliza una herramienta externa, \texttt{ZenHub}, la cual permite la definición de las tareas, el seguimiento de cada una de ellas en función de la planificación póker, seguimiento de cada \textit{sprint}, el versionado, etc. Seguidamente se realizará un estudio de la viabilidad del proyecto, tanto a nivel económico como legal. \newpage @@ -36,7 +36,7 @@ \subsection{\textit{SCRUM}} \end{figure} \subsubsection{\textit{Sprints}} -Los \textit{sprints} son periodos breves de \textbf{tiempo fijo} en el que el equipo trabaja para completar una cantidad de trabajo pre-establecida. Si bien muchas guías asocian los \textit{sprints} a la metodología ágil, asociando la metodología ágil y la metodología seguida en \textit{scrum} como si fueran lo mismo, cuando no lo son. La metodología ágil constituye una serie de principios, y la metodología \textit{scrum} es un marco de trabajo con la única finalidad de conseguir resultados. +Los \textit{sprints} son periodos breves de \textbf{tiempo fijo} en el que el equipo trabaja para completar una cantidad de trabajo preestablecida. Si bien muchas guías asocian los \textit{sprints} a la metodología ágil, asociando la metodología ágil y la metodología seguida en \textit{scrum} como si fueran lo mismo, cuando no lo son. La metodología ágil constituye una serie de principios, y la metodología \textit{scrum} es un marco de trabajo con la única finalidad de conseguir resultados. A pesar de las similitudes los \textit{sprints} poseen un objetivo subyacente, entregar con frecuencia \textit{software} de trabajo. @@ -49,9 +49,9 @@ \subsubsection{\textit{Sprint meetings}} \end{itemize} \subsubsection{Artifacts} -Uno de los componentes más importantes de cara a la metodología \textit{scrum} son los artefactos, o \textit{artifacts} por su nombre en inglés. Éstos incluyen el \textit{product backlog}, el \textit{sprint backlog} y los \textit{burn down charts}. +Uno de los componentes más importantes de cara a la metodología \textit{scrum} son los artefactos, o \textit{artifacts} por su nombre en inglés. Estos incluyen el \textit{product backlog}, el \textit{sprint backlog} y los \textit{burn down charts}. \begin{itemize} -\item \textbf{\textit{Product backlog.}} Lista de trabajo ordenada por las prioridades para el equipo de desarrollo. Es generada a partir de las reuniones de planificación de los \textit{sprints}, contiene los requisitos. Se encuentra actualizado y clasificado en función de la periodicidad asignada a las tareas, pudiendo ser de corto o largo plazo. Aquellas tareas que se deban resolver a corto plazo deberán estar perfectamente descritas antes de asignarlas esta periodicidad, implicando que se han diseñado las historias de usuario completas así como el equipo de desarrollo ha establecido las estimaciones correspondientes. Los elementos a largo plazo pueden ser abstractos u opacos, conviene que estén estimados en la medida de lo posible para poder tener en cuenta el tiempo que llevará desarrollarla. +\item \textbf{\textit{Product backlog.}} Lista de trabajo ordenada por las prioridades para el equipo de desarrollo. Es generada a partir de las reuniones de planificación de los \textit{sprints}, contiene los requisitos. Se encuentra actualizado y clasificado en función de la periodicidad asignada a las tareas, pudiendo ser de corto o largo plazo. Aquellas tareas que se deban resolver a corto plazo deberán estar perfectamente descritas antes de asignarlas esta periodicidad, implicando que se han diseñado las historias de usuario completas, así como el equipo de desarrollo ha establecido las estimaciones correspondientes. Los elementos a largo plazo pueden ser abstractos u opacos, conviene que estén estimados en la medida de lo posible para poder tener en cuenta el tiempo que llevará desarrollarla. Los propietarios del producto dictan la prioridad de los elementos de trabajo en el \textit{product backlog}, mientras que el equipo de desarrollo dicta la velocidad a la que se trabaja el \textit{backlog}~\cite{danradigan2021}. @@ -80,7 +80,7 @@ \subsection{Planificación por \textit{sprints}} Inicialmente la \textit{sprint planning meeting} es realizada cada dos semanas, debido a una falta de costumbre de trabajo con esta metodología se combina junto con la \textit{sprint review meeting}, de forma que en una sola reunión se comenta tanto lo que se ha hecho como lo que está por realizarse en el siguiente \textit{sprint}. -La velocidad de desarrollo del proyecto es una incógnita, debido a la no existencia de referencias previas del equipo de desarrollo del proyecto, en proyectos de ésta índole. Por lo tanto, la duración de los \textit{sprints} puede que se vea ajustada a lo largo de la vida del proyecto. +La velocidad de desarrollo del proyecto es una incógnita, debido a la no existencia de referencias previas del equipo de desarrollo del proyecto, en proyectos de esta índole. Por lo tanto, la duración de los \textit{sprints} puede que se vea ajustada a lo largo de la vida del proyecto. No se utilizan \textit{daily meetings} puesto que a pesar de que se invierte una media de tres a cinco horas diarias en el desarrollo, no es considerada necesaria. Si bien en caso de problemas se acuerda una reunión para el día siguiente con el fin de mantener la agilidad y no retrasar el proyecto. @@ -114,9 +114,9 @@ \subsubsection{\textit{Sprint} 1: Chad} \caption{\textit{Burndown Chart Sprint 1.}}\label{fig:BD-Sprint1} \end{center} \end{figure} -Durante este \textit{sprint} el trabajo inicial comenzó ligeramente retrasado, motivos en el apartado \textit{sprint review meeting}, por lo tanto podemos observar en la Figura~\ref{fig:BD-Sprint1} como el trabajo completado dista del ideal o proyectado para este \textit{sprint}. +Durante este \textit{sprint} el trabajo inicial comenzó ligeramente retrasado, motivos en el apartado \textit{sprint review meeting}, por lo tanto, podemos observar en la Figura~\ref{fig:BD-Sprint1} como el trabajo completado dista del ideal o proyectado para este \textit{sprint}. -En el \textit{sprint backlog} habían sido incluidos todos los algoritmos a programar, es por ello que indica que se ha completado aproximadamente la mitad del trabajo. +En el \textit{sprint backlog} habían sido incluidos todos los algoritmos a programar, es por ello por lo que indica que se ha completado aproximadamente la mitad del trabajo. \item \textbf{\textit{Sprint review meeting}}\\ El trabajo en este primer \textit{sprint} ha salido adelante correctamente. Al ser el primer \textit{sprint} ha habido un pequeño error de configuración del repositorio junto con la herramienta ZenHub, de ahí que en el \textit{burndown chart} de esta semana, Figura~\ref{fig:BD-Sprint1}, aparezca como que la primera semana del \textit{sprint} no ha habido trabajo completado. @@ -151,7 +151,7 @@ \subsubsection{\textit{Sprint} 2: Holleyman} \item \textbf{\textit{Sprint review meeting}}\\ A lo largo de este \textit{sprint} se descubrió un problema en la forma de identificar los $k$-NN en el algoritmo \textit{Condensed Nearest Neighbor, CNN}~\cite{hart1968condensed}, retrasando el trabajo cuatro horas, entre identificación y re-codificación. Este error se descubrió mientras se investigaba otro error, en este caso el algoritmo \textit{Iterative Case Filtering, ICF}~\cite{brighton2002advances} terminaba en error buscando los \textit{k}-NN de las últimas instancias. -La implementación de los algoritmos \textit{Reduced Nearest Neighbor, RNN}~\cite{gates1972reduced} y \textit{Modified Selective Subset, MSS}~\cite{barandela2005decision} ha sido relativamente asequible una vez se comprendía el algoritmo en cuestión así como su funcionamiento (entradas, procesado, salidas...). +La implementación de los algoritmos \textit{Reduced Nearest Neighbor, RNN}~\cite{gates1972reduced} y \textit{Modified Selective Subset, MSS}~\cite{barandela2005decision} ha sido relativamente asequible una vez se comprendía el algoritmo en cuestión, así como su funcionamiento (entradas, procesado, salidas...). \end{itemize} \subsubsection{\textit{Sprint} 3: Manion} @@ -221,7 +221,7 @@ \subsubsection{\textit{Sprint} 5: Murph} \item Implementar los algoritmos anteriores como clases para poder ser utilizados con métodos \textit{fit} y \textit{predict}. \item Escribir la documentación de la memoria referente a los anteriores algoritmos. \item Escribir la planificación temporal relativa a los \textit{sprints} 4 y 5. -\item Añadir leyenda a la figuras generadas con \textit{self-training} en función de un \% de datos etiquetados. +\item Añadir leyenda a las figuras generadas con \textit{self-training} en función de un \% de datos etiquetados. \end{enumerate} Se espera que sea un \textit{sprint} muy productivo debido a las fechas en las que se realiza y la mayor disponibilidad del equipo de desarrollo. @@ -234,7 +234,7 @@ \subsubsection{\textit{Sprint} 5: Murph} \caption{\textit{Burndown Chart Sprint 5.}}\label{fig:BD-Sprint5} \end{center} \end{figure} -En este \textit{sprint}, y como vemos en la Figura~\ref{fig:BD-Sprint5}, referente al correspondiente \textit{Burndown report}; se ha realizado una gran cantidad de trabajo, habiendo siendo completados 77 puntos de historia, una cantidad muy superior a anteriores \textit{sprints}, esto es debido en gran parte a las fechas en las que nos encontramos, ya que el número de horas que se han podido invertir en el desarrollo del proyecto ha sido muy superior a lo que venían siendo habituales. En total han sido utilizadas cerca de 110 horas de trabajo, siendo repartidas en los 17 días que ha durado el \textit{sprint} y con una media de horas de trabajo de 6.5 horas diarias. +En este \textit{sprint}, y como vemos en la Figura~\ref{fig:BD-Sprint5}, referente al correspondiente \textit{Burndown report}; se ha realizado una gran cantidad de trabajo, habiendo sido completados 77 puntos de historia, una cantidad muy superior a anteriores \textit{sprints}, esto es debido en gran parte a las fechas en las que nos encontramos, ya que el número de horas que se han podido invertir en el desarrollo del proyecto ha sido muy superior a lo que venían siendo habituales. En total han sido utilizadas cerca de 110 horas de trabajo, siendo repartidas en los 17 días que ha durado el \textit{sprint} y con una media de horas de trabajo de 6.5 horas diarias. \item \textbf{\textit{Sprint review meeting}}\\ Todo el trabajo que se ha realizado en este \textit{sprint} podría haber sido realizado seguramente en tres cuartas partes del tiempo real invertido, pero debido al tiempo de lectura de los artículos de donde se extraían los algoritmos, así como su correcta comprensión, codificación y posterior resolución de problemas asociados a \textit{bugs} que se van descubriendo <>, ha sido un \textit{sprint} largo y en algunos momentos agotador. @@ -262,7 +262,7 @@ \subsubsection{\textit{Sprint} 6: Bert} \caption{\textit{Burndown Chart Sprint 6.}}\label{fig:BD-Sprint6} \end{center} \end{figure} -Tal y como se aprecia en la Figura~\ref{fig:BD-Sprint6} referente al sexto \textit{sprint}, el ritmo de trabajo ha sido constante a lo largo de la primera semana, torciéndose al final del \textit{sprint} debido a la complejidad sobrellevada de aprender la biblioteca \textit{Flask} y sus dependencias. Es por ello que dos \textit{issues} se cerraron un día más tarde de la planificación. +Tal y como se aprecia en la Figura~\ref{fig:BD-Sprint6} referente al sexto \textit{sprint}, el ritmo de trabajo ha sido constante a lo largo de la primera semana, torciéndose al final del \textit{sprint} debido a la complejidad sobrellevada de aprender la biblioteca \textit{Flask} y sus dependencias. Es por ello por lo que dos \textit{issues} se cerraron un día más tarde de la planificación. El número de horas aproximado que se han invertido han sido de 50h, permitido en gran medida con que todavía no hay clases del segundo cuatrimestre. \item \textbf{\textit{Sprint review meeting}}\\ @@ -323,12 +323,12 @@ \subsubsection{\textit{Sprint} 8: Jason} \caption{\textit{Burndown Chart Sprint 8.}}\label{fig:BD-Sprint8} \end{center} \end{figure} -Tal y como se aprecia en la Figura~\ref{fig:BD-Sprint8} se aprecia que el ritmo de trabajo en este \textit{sprint} ha sido muy escalonado, el número de \textit{issues} no ha sido muy elevado, pero la complejidad de estas sí que lo ha sido, es por ello que se planificó 90 puntos de historia. Seguidamente podemos apreciar como entre el cuatro y el siete de febrero, coincidiendo con el fin de semana, no ha habido trabajo finalizado, se debe a unas mini-vacaciones que se tomó el equipo de desarrollo. +Tal y como se aprecia en la Figura~\ref{fig:BD-Sprint8} se aprecia que el ritmo de trabajo en este \textit{sprint} ha sido muy escalonado, el número de \textit{issues} no ha sido muy elevado, pero la complejidad de estas sí que lo ha sido, es por ello por lo que se planificó 90 puntos de historia. Seguidamente podemos apreciar como entre el cuatro y el siete de febrero, coincidiendo con el fin de semana, no ha habido trabajo finalizado, se debe a unas mini-vacaciones que se tomó el equipo de desarrollo. \item \textbf{\textit{Sprint review meeting}}\\ Con el \textit{sprint} finalizado se ha visto como lo que parecía una planificación para una o dos semanas, ha quedado resuelta dentro del propio \textit{sprint}. El equipo de desarrollo comienza a familiarizarse con el \textit{backend} de UBUMLaaS propiciando un desarrollo más eficaz de las tareas que se van encomiando. -Destacar que no se finalizan todas las tareas en tiempo, sino que se finaliza una en la noche del martes ocho, ya casi de madrugada, entrando técnicamente en el siguiente \textit{sprint}. +Hay que destacar que no se finalizan todas las tareas en tiempo, sino que se finaliza una en la noche del martes ocho, ya casi de madrugada, entrando técnicamente en el siguiente \textit{sprint}. \end{itemize} @@ -359,11 +359,11 @@ \subsubsection{\textit{Sprint} 9: Lumberjack 20} Quedando el trabajo finalizado un par de días antes de la fecha de finalización del \textit{sprint}, dando al equipo de desarrollo tiempo para planear futuras tareas y aproximaciones a problemas conocidos. \item \textbf{\textit{Sprint review meeting}}\\ -En este \textit{sprint} se planificó <> en los puntos de historia, se debe a que se requería comprobar la implementación de los tres algoritmos de aprendizaje Semi-Supervisado, y en caso de que alguno (o todos) tuviera una implementación incorrecta, realizar los ajustes pertinentes para que fuera correcta. Debido a la experiencia del equipo de desarrollo un mes atrás con el filtro ICF, el cual tuvo que ser re-codificado y revisado en más de una ocasión debido a su inconsistencia, se aventuró un futuro similar con éstos algoritmos ya que son más grandes y con una complejidad superior. La realidad en este caso superó las expectativas del equipo de desarrollo, cuando los tres algoritmos tuvieron una desviación menor al 1\% en comparación con los de referencia. (En futuros \textit{sprints} se ha propuesto ser más críticos con la asignación de puntos de historia para no tener diferencias de este calibre). +En este \textit{sprint} se planificó <> en los puntos de historia, se debe a que se requería comprobar la implementación de los tres algoritmos de aprendizaje Semi-Supervisado, y en caso de que alguno (o todos) tuviera una implementación incorrecta, realizar los ajustes pertinentes para que fuera correcta. Debido a la experiencia del equipo de desarrollo un mes atrás con el filtro ICF, el cual tuvo que ser re-codificado y revisado en más de una ocasión debido a su inconsistencia, se aventuró un futuro similar con estos algoritmos ya que son más grandes y con una complejidad superior. La realidad en este caso superó las expectativas del equipo de desarrollo, cuando los tres algoritmos tuvieron una desviación menor al 1\% en comparación con los de referencia. (En futuros \textit{sprints} se ha propuesto ser más críticos con la asignación de puntos de historia para no tener diferencias de este calibre). Con todo y con ello, la implementación de los filtros en UBUMLaaS incurrió en múltiples modificaciones a la estructura base de la propia plataforma, pero con un resultado satisfactorio. -Los \textit{rankings} creados no han convencido en estructura y formato, es por ello que en siguiente \textit{sprint} tendrán que ser repetidos. +Los \textit{rankings} creados no han convencido en estructura y formato, es por ello por lo que en siguiente \textit{sprint} tendrán que ser repetidos. \end{itemize} \subsubsection{\textit{Sprint} 10: Jerry} @@ -391,12 +391,12 @@ \subsubsection{\textit{Sprint} 10: Jerry} \caption{\textit{Burndown Chart Sprint 10.}}\label{fig:BD-Sprint10} \end{center} \end{figure} -Este \textit{sprint} ha sido más ajustado el número de horas invertidas en el desarrollo de las tareas marcadas en comparación los puntos de historia. Se han marcado un total de 46 puntos de historia y se han invertido 35 horas de trabajo. Siguiendo un poco más la tónica de otros \textit{sprints}. En los primeros días, tal y como se aprecia en la Figura~\ref{fig:BD-Sprint10}, sí que hubo \textit{commits} pero no se cerraron tareas debido a que se trabajó en <> sobre varias \textit{issues} a la vez, ya que toda la parte de crear la interfaz de administración y las páginas que la iban a comenzar a formar parte de la misma, se encuentran fuertemente inter-relacionadas. +Este \textit{sprint} ha sido más ajustado el número de horas invertidas en el desarrollo de las tareas marcadas en comparación los puntos de historia. Se han marcado un total de 46 puntos de historia y se han invertido 35 horas de trabajo. Siguiendo un poco más la tónica de otros \textit{sprints}. En los primeros días, tal y como se aprecia en la Figura~\ref{fig:BD-Sprint10}, sí que hubo \textit{commits} pero no se cerraron tareas debido a que se trabajó en <> sobre varias \textit{issues} a la vez, ya que toda la parte de crear la interfaz de administración y las páginas que la iban a comenzar a formar parte de esta, se encuentran fuertemente interrelacionadas. \item \textbf{\textit{Sprint review meeting}}\\ El trabajo realizado durante este \textit{sprint} ha sido más duro que el de \textit{sprints} anteriores. Esto se debe a la poca experiencia del equipo de desarrollo con aplicaciones que poseen un \textit{frontend}, el uso de JavaScript, jQuery, AJAX,\dots es algo que hasta la fecha no se había utilizado en gran medida y ahora es con lo que más se está trabajando, entonces ha requerido de un esfuerzo extra. -La parte de administración de UBUMLaaS ha sido creada con una base más moderna, sencilla y clara. Siguiendo el esquema de colores de la Universidad de Burgos. Es por ello que ahora mismo parecen dos aplicaciones diferentes, (la parte de administración en comparación con la parte de funcionalidad de MLaaS propiamente dicha). +La parte de administración de UBUMLaaS ha sido creada con una base más moderna, sencilla y clara. Siguiendo el esquema de colores de la Universidad de Burgos. Es por ello por lo que ahora mismo parecen dos aplicaciones diferentes, (la parte de administración en comparación con la parte de funcionalidad de MLaaS propiamente dicha). Durante la realización del \textit{sprint} fueron surgiendo pequeños \textit{bugs} en la interfaz gráfica que se fueron solventando, todos ellos originados por descuidos (debido a la falta de experiencia) del propio equipo de desarrollo con el uso de las nuevas librarías. \end{itemize} @@ -467,7 +467,7 @@ \subsubsection{\textit{Sprint} 12: DVB} En líneas generales se puede afirmar que el \textit{frontend} ha sido rehecho entero, se han reutilizado formatos o formularios existentes por facilidad de uso a todos aquellos usuarios que ya la conocieran, pero a nivel de código prácticamente es nueva. Con un estilo mucho más moderno, fino y elegante. -La integración de CI/CD finalmente ha quedado hecha con elementos \textit{cloud}, entre ellos se encuentran Travis-CI, Codebeat, SonarCloud y Codacy. Debido a que se ha rehecho toda la interfaz web de la aplicación, los tests existentes no pasan, es por ello que se tendrán que rehacer poco a poco, aunque no es uno de los elementos de mayor prioridad por el momento. +La integración de CI/CD finalmente ha quedado hecha con elementos \textit{cloud}, entre ellos se encuentran Travis-CI, Codebeat, SonarCloud y Codacy. Debido a que se ha rehecho toda la interfaz web de la aplicación, los tests existentes no pasan, es por ello por lo que se tendrán que rehacer poco a poco, aunque no es uno de los elementos de mayor prioridad por el momento. \end{itemize} @@ -483,7 +483,7 @@ \subsubsection{\textit{Sprint} 13: Kutschbach} \item Realizar algunas pruebas de estrés para detectar puntos de rotura de la interfaz. \item Comenzar a escribir los Requisitos. \item Comenzar a escribir dentro del Diseño, el diagrama de casos de uso. -\item Añadir a los aspectos relevantes los métodos que se están haciendo así como los cambios en la interfaz. +\item Añadir a los aspectos relevantes los métodos que se están haciendo, así como los cambios en la interfaz. \item Revisar comentarios hechos por Alvar en la memoria. \end{enumerate} @@ -567,7 +567,7 @@ \subsubsection{\textit{Sprint} 15: Robbie} \subsubsection{\textit{Sprint} 16: Matt 16} \begin{itemize} \item \textbf{\textit{Planning meeting}}\\ -Objetivos del dieciseisavo \textit{sprint}: +Objetivos del decimosexto \textit{sprint}: \begin{enumerate} \item Mejora de la calidad del código de los algoritmos de la biblioteca \texttt{IS-SSL}. \item Remates de los diagramas de secuencia. @@ -586,7 +586,7 @@ \subsubsection{\textit{Sprint} 16: Matt 16} \caption{\textit{Burndown Chart Sprint 16.}}\label{fig:BD-Sprint16} \end{center} \end{figure} -En este \textit{sprint} se ha trabajado principalmente en la memoria y en retoques de código, es por ello que se ha dado una cifra superior de puntos de historia de la media, y con lo visto en el \textit{sprint} anterior, estas tareas están comenzando a llevar más tiempo de que inicialmente se piensa. Se han invertido aproximadamente 37 horas. Los tiempos de trabajo empiezan a ser correctos de forma reiterada con lo planificado. +En este \textit{sprint} se ha trabajado principalmente en la memoria y en retoques de código, es por ello por lo que se ha dado una cifra superior de puntos de historia de la media, y con lo visto en el \textit{sprint} anterior, estas tareas están comenzando a llevar más tiempo de que inicialmente se piensa. Se han invertido aproximadamente 37 horas. Los tiempos de trabajo empiezan a ser correctos de forma reiterada con lo planificado. \item \textbf{\textit{Sprint review meeting}}\\ Con la experimentación a tres sextos realizada, todavía no se ha encontrado un nexo común que nos permita crear hipótesis, por lo que se aprovecharán las vacaciones de Semana Santa para dejar más experimentos en ejecución y rehacer las \textit{scripts} de análisis de resultados. @@ -621,7 +621,7 @@ \subsubsection{\textit{Sprint} 17: Dae Han} El trabajo a lo largo de este \textit{sprint} ha sido a ritmo constante, tal y como se aprecia en la Figura~\ref{fig:BD-Sprint17}, se aprecia como el número de puntos de historia es elevado, esto se debe a que se realizan en total 26 \textit{issues}, del total de 27 planificadas. Son muchas tareas pequeñas que acaban elevando el número de puntos de historia empleados. En total se han invertido alrededor de 45 horas de trabajo a lo largo de todo el \textit{sprint}. \item \textbf{\textit{Sprint review meeting}}\\ -En este \textit{sprint} se sobre-predijo el número de puntos de historia necesarios para resolver un número determinado de \textit{bugs} en \texttt{UBUMLaaS}, resultando estos más sencillos de resolver que en lo que en un primer momento parecía. +En este \textit{sprint} se sobre predijo el número de puntos de historia necesarios para resolver un número determinado de \textit{bugs} en \texttt{UBUMLaaS}, resultando estos más sencillos de resolver que en lo que en un primer momento parecía. Una tarea que quedó por cubrir fue la escritura de las pruebas que se han realizado en los productos \textit{software} desarrollados, no dando tiempo a finalizarlo en tiempo y forma. @@ -770,7 +770,7 @@ \subsubsection{\textit{Sprint} 21: Pheezy} \FloatBarrier \subsection{Resumen} -A continuación se muestra un resumen del tiempo dedicado a cada tipo de tarea. El cálculo ha sido realizado en función de los puntos de historia asignados mediante \texttt{ZenHub}, a razón de 45 minutos por punto de historia. +A continuación, se muestra un resumen del tiempo dedicado a cada tipo de tarea. El cálculo ha sido realizado en función de los puntos de historia asignados mediante \texttt{ZenHub}, a razón de 45 minutos por punto de historia. \begin{table}[] \centering @@ -806,13 +806,13 @@ \subsection{Viabilidad económica} Lo primero de todo que se va a calcular es la viabilidad económica del proyecto, reportando y analizando los costes/beneficios que habría supuesto el desarrollo del proyecto en el sector empresarial, en España\footnote{Se hace referencia al lugar de desarrollo puesto que se van a hacer referencias económicas en la moneda del país, así como uso de legislación vigente, la cual varía en función del país en el que se encuentre asentada la empresa desarrolladora.}. \subsubsection{Costes} -La realización de un proyecto de esta envergadura lleva asociados una serie de costes fijos y variables, a continuación se desglosan agrupados en \textit{hardware}, \textit{software}, personal, otros. +La realización de un proyecto de esta envergadura lleva asociados una serie de costes fijos y variables, a continuación, se desglosan agrupados en \textit{hardware}, \textit{software}, personal, otros. \textbf{Costes \textit{hardware}} Para el desarrollo del proyecto es necesario más de un equipo \textit{hardware}, lo primero de todo es un equipo de tipo portátil. Se utilizará un MacBook Pro, con un procesador Inter Core i7 de 4 núcleos a 2.3~GHz, con 16~GB de memoria RAM, atendiendo a un precio de mercado de 2249~\officialeuro, se tiene en cuenta que la vida útil del equipo se encuentra en torno a los seis años, por lo que para los cálculos se usa la vida media del inmovilizado, es decir, 3 años. -A su vez se necesita un servidor para desplegar la aplicación y trabajar sobre esta, ya que el despliegue local no se considera una forma de trabajo óptima. Es por ello que se hace uso de un equipo con un AMD FX(tm)-4130 Quad-Core a 4.5~GHz, con 64~GB de memoria RAM. El coste aproximado del equipo es de 1500~\officialeuro. La vida útil estimada es de seis ocho años, se utilizará igual que con el equipo portátil, su vida media de inmovilizado, 4 años. +A su vez se necesita un servidor para desplegar la aplicación y trabajar sobre esta, ya que el despliegue local no se considera una forma de trabajo óptima. Es por ello por lo que se hace uso de un equipo con un AMD FX(tm)-4130 Quad-Core a 4.5~GHz, con 64~GB de memoria RAM. El coste aproximado del equipo es de 1500~\officialeuro. La vida útil estimada es de seis ocho años, se utilizará igual que con el equipo portátil, su vida media de inmovilizado, 4 años. La amortización para cada equipo es diferente, pero el tiempo de uso es el mismo, de noviembre de dos mil veintiuno a junio de dos mil veintidós, ambos incluidos, luego en total ocho meses. Se detallan todos los costes \textit{hardware} en la Tabla~\ref{tab:costes-hardware}. @@ -903,7 +903,7 @@ \subsubsection{Costes} Siendo el coste total en personal de 12.653,29~\officialeuro{}. \textbf{Otros costes}\\ -Costes no agrupables en los anteriores apartados pero a tener en cuenta, Tabla~\ref{tab:costes-otros}. +Costes no agrupables en los anteriores apartados, pero para tener en cuenta, Tabla~\ref{tab:costes-otros}. \begin{table}[H] \centering @@ -951,7 +951,7 @@ \subsubsection{Costes} El proyecto está compuesto de dos partes, las cuáles se pueden comercializar de forma independiente. \begin{itemize} \item \textbf{IS-SSL.} Las bibliotecas de algoritmos son distribuidas de forma pública, gratuita y sin publicidad, con el fin de aportar un <> a la investigación en aprendizaje semi-supervisado y selección de instancias. -\item \textbf{UBUMLaaS.} En el diseño existente no está planteada su monetización. Si se quisiera obtener un rédito económico de este \texttt{MLaaS}, se podría fácilmente crear niveles de usuarios para acceso, número de experimentos máximos a lanzar. También se podría plantear como servicio de suscripción. En la Tabla~\ref{tab:opciones-beneficio} se plantean algunas posibilidades de comercialización con sus posibles respectivos costes para los usuarios, todas las licencias son anuales, en caso de un usuario quedarse sin tiempo podría comprar más horas de ejecución. +\item \textbf{UBUMLaaS.} En el diseño existente no está planteada su monetización. Si se quisiera obtener un rédito económico de este \texttt{MLaaS}, se podría fácilmente crear niveles de usuarios para acceso, número de experimentos máximos para lanzar. También se podría plantear como servicio de suscripción. En la Tabla~\ref{tab:opciones-beneficio} se plantean algunas posibilidades de comercialización con sus posibles respectivos costes para los usuarios, todas las licencias son anuales, en caso de un usuario quedarse sin tiempo podría comprar más horas de ejecución. \end{itemize} \begin{table}[H] diff --git a/docs/tex/B_Requisitos.tex b/docs/tex/B_Requisitos.tex index e546910..8c01f49 100644 --- a/docs/tex/B_Requisitos.tex +++ b/docs/tex/B_Requisitos.tex @@ -3,7 +3,7 @@ \section{Introducción} Este anexo recoge las necesidades funcionales que deberán ser soportadas por el sistema que va a ser desarrollado. Con el fin de obtener una buena documentación se deben identificar y describir los requisitos que debe el sistema satisfacer, pero sin entrar en cómo los va a resolver. -Hoy en día, no existe una autoridad que indique cómo se deben de realizar las especificaciones de requisitos \textit{software}, SRS. La comunidad se encuentra dividida entre <> siguiendo guías de buenas prácticas (IEEE 830-1998~\cite{720574} ó 12207-2-2020~\cite{IEEE1220722020}), en contraposición con el \textit{Agile Manifiesto}, donde no se hace una especificación formal de toda la aplicación, sino que cada 2-4 semanas se revisa y <> en función de las necesidades del cliente. +Hoy en día, no existe una autoridad que indique cómo se deben de realizar las especificaciones de requisitos \textit{software}, SRS. La comunidad se encuentra dividida entre <> siguiendo guías de buenas prácticas (IEEE 830-1998~\cite{720574} o 12207-2-2020~\cite{IEEE1220722020}), en contraposición con el \textit{Agile Manifiesto}, donde no se hace una especificación formal de toda la aplicación, sino que cada 2-4 semanas se revisa y <> en función de las necesidades del cliente. Se va a realizar una combinación de ambos, por un lado, se trabaja a lo largo del proyecto con una planificación ágil, y por otro se va a tener como referencia una especificación de requisitos que va a seguir la guía de buenas prácticas IEEE 830-1998. Ésta última recoge los siguientes puntos como referencias a una buena especificación de requisitos \textit{software}~\cite{ingenieriasoftwareytiemporeal_2020}. \begin{itemize} @@ -18,7 +18,7 @@ \section{Introducción} \item \textbf{Consistente.} Si un SRS <> con algún documento de nivel superior (\textit{i.e.} una especificación de requisitos de sistema), entonces no será consistente. \item \textbf{Comprobable.} Será comprobable si, y sólo si, cada requisito declarado es comprobable. A su vez un requisito será comprobable si, y sólo si, allí existe un proceso rentable finito con que una persona o la máquina puede verificar que el producto del \textit{software} reúne el requisito. Cualquier requisito ambiguo no es comprobable. \item \textbf{Modificable}. Será modificable si, y sólo si, su estructura y estilo son tales que puede hacerse cualquier cambio a los requisitos fácilmente, completamente y de forma consistente mientras conserva la estructura y estilo. -\item \textbf{Identificable.} Será identificable si el origen de cada uno de los requisitos está claro y facilita de igual manera las referencias de cada requisito de desarrollo futuro o documentación del mismo. +\item \textbf{Identificable.} Será identificable si el origen de cada uno de los requisitos está claro y facilita de igual manera las referencias de cada requisito de desarrollo futuro o documentación de este. \end{itemize} @@ -34,17 +34,17 @@ \section{Objetivos generales}\label{objetivos-generales} En la biblioteca referida a los algoritmos de filtrado más comunes se implementarán algoritmos clásicos de la literatura como son CNN, RNN, ICF, ... Mientras que la biblioteca de algoritmos clásicos de Semi Supervisado contendrá \textit{Co-Training}, \textit{Tri-Training}, etc. Estando estructuradas en forma de clases accesibles mediante importación clásica de paquetes. Deben de ser fácilmente escalables, posterior a la finalización del proyecto deben poder ampliarse sin añadir complejidad. -Las interfaces a diseñar se requieren que sean intuitivas, fáciles de entender y utilizar. Deberán de ser transparentes al usuario, impidiendo que este conozca la lógica de diseño de la aplicación, así como los posibles fallos internos que se puedan producir por acciones del sistema, del usuario, o de terceros. +Las interfaces por diseñar se requieren que sean intuitivas, fáciles de entender y utilizar. Deberán de ser transparentes al usuario, impidiendo que este conozca la lógica de diseño de la aplicación, así como los posibles fallos internos que se puedan producir por acciones del sistema, del usuario, o de terceros. \section{Usuarios del \textit{software}}\label{usuarios-participantes-software} Cualquier persona podrá hacer uso de la aplicación UBUMLaaS, siendo únicamente necesarios una serie de datos básicos para su registro dentro de ella. -Dentro de la aplicación se encuentra el usuario base y una generalización del mismo en forma de administrador. +Dentro de la aplicación se encuentra el usuario base y una generalización de este en forma de administrador. \begin{itemize} \item \textbf{Usuario.} El usuario será el modelo base, en la forma de una persona la cual tendrá las capacidades de: crear experimentos y todas las funcionalidades asociadas con los mismos. Así como editar sus datos personales, añadir nuevos, quitar, etc. Y conocer sus estadísticas de uso de la última semana. -\item \textbf{Administrador.} Actor generalizado de usuario. Tiene todas las funcionalidades propias del usuario, pero además posee acceso a toda la parte de administración de la aplicación. En esta nueva parte posee acceso a la monitorización del sistema en tiempo real, a las estadísticas del mismo en cuanto a uso respecta, administración de todos los usuarios, etc. +\item \textbf{Administrador.} Actor generalizado de usuario. Tiene todas las funcionalidades propias del usuario, pero además posee acceso a toda la parte de administración de la aplicación. En esta nueva parte posee acceso a la monitorización del sistema en tiempo real, a las estadísticas de este en cuanto a uso respecta, administración de todos los usuarios, etc. \end{itemize} Un usuario es creado por una persona ajena que quiere registrarse en la aplicación, o por un administrador. Pero un administrador sólo puede ser <> (elevación de usuario a administrador) por otro administrador, y lo mismo para el caso contrario, pasar de administrador a usuario. @@ -56,7 +56,7 @@ \section{Factores de riesgo}\label{factores-de-riesgo} Se identifican los siguientes factores de riesgo: \begin{enumerate} \item \textbf{Desconocimiento teórico.} Se posee una cantidad muy limitada de conocimiento en la materia en la que el proyecto transcurre. El proyecto tiene un enfoque fuertemente relacionado con la minería de datos, un área hasta ahora inexplorada. El proyecto ya en su base más pura va a suponer un reto en el día a día. -\item \textbf{Documentación a utilizar.} Hasta ahora nunca se ha tratado con \textit{papers} o artículos científicos, mucho menos su lectura y comprensión, análisis y posterior implementación de los algoritmos propuestos. Puede suponer retrasos sin previo aviso un \textit{paper} con una alta complejidad, bien por la condensación de información, bien por la encapsulación de información, o simplemente por los conocimientos que se requieren para entender el documento. +\item \textbf{Documentación para utilizar.} Hasta ahora nunca se ha tratado con \textit{papers} o artículos científicos, mucho menos su lectura y comprensión, análisis y posterior implementación de los algoritmos propuestos. Puede suponer retrasos sin previo aviso un \textit{paper} con una alta complejidad, bien por la condensación de información, bien por la encapsulación de información, o simplemente por los conocimientos que se requieren para entender el documento. \item \textbf{Experiencia modificando un proyecto \textit{software}.} La experiencia personal dictamina que la modificación de proyectos que han sido iniciados por terceros (como se trabaja en la industria) conlleva una etapa de adaptación la cual no suele ser linear, sino exponencial, en función de la complejidad de la aplicación que se desea asimilar. \item \textbf{Mínima experiencia con algunos lenguajes/bibliotecas.} El proyecto requiere del uso de lenguajes de programación como JavaScript, o lenguajes de marcas como son HTML, CSS, \LaTeX ... o bibliotecas como Flask o Vue. Con las que no se tiene prácticamente experiencia real de uso. Supondrá un esfuerzo extra e impedirá que determinadas tareas sean tan cortas como deberían serlo. \item \textbf{Existencia del usuario final.} Se desconoce el usuario final de la aplicación, por lo que no se podrán realizar talleres, esto motivará a que el proyecto se creará como se cree que el usuario lo esperaría, pero sin su aprobación. @@ -159,7 +159,7 @@ \subsection{Requisitos no funcionales}\label{requisitos-no-funcionales} \item \textbf{RNF-8 Soporte.} La plataforma debe dar soporte a ficheros CSV y ARFF como mínimo. Así como ser compatible con HTML5. \item \textbf{RNF-9 Monitorización.} La plataforma debe ser fácilmente monitorizable por un administrador. \item \textbf{RNF-10 Internacionalización.} La plataforma debe de estar desarrollada en un inglés sencillo y fácil de comprender por todo tipo de usuarios no nativos. -\item \textbf{RNF-11 Respuesta autónoma.} En caso de inicio o reinicio, el tiempo empleado por la plataforma hasta estar al 100\% de operatibilidad de nuevo debe ser inferior a los 3 minutos. +\item \textbf{RNF-11 Respuesta autónoma.} En caso de inicio o reinicio, el tiempo empleado por la plataforma hasta estar al 100\% de operatividad de nuevo debe ser inferior a los 3 minutos. \end{itemize} \newpage \section{Especificación de requisitos} @@ -391,7 +391,7 @@ \subsection{Casos de uso}\label{casos-de-uso} \textbf{Autor} & Daniel Puente Ramírez\\ \textbf{Requisitos asociados} & RF-4, RF-4.1, RF-4.2, RF-4.3, RF-4.4\\ \textbf{Descripción} & Permite al usuario modificar sus datos personales dentro de la plataforma.\\ -\textbf{Precondición} & Los datos del usuarios son recuperados de la base de datos.\\ +\textbf{Precondición} & Los datos del usuario son recuperados de la base de datos.\\ \textbf{Acciones} & \begin{enumerate} \def\labelenumi{\arabic{enumi}.} diff --git a/docs/tex/C_Diseno.tex b/docs/tex/C_Diseno.tex index c2abfee..a2617af 100644 --- a/docs/tex/C_Diseno.tex +++ b/docs/tex/C_Diseno.tex @@ -35,7 +35,7 @@ \subsubsection{Diagrama Relacional} \subsection{Diseño procedimental} En esta sección interna se recogen los detalles más relevantes en cuanto a los procedimientos llevados a cabo por la plataforma en función de las acciones del usuario. -A continuación se explican los diagramas de secuencia (DS): +A continuación, se explican los diagramas de secuencia (DS): \begin{itemize} \item \textbf{DS para la monitorización del sistema en tiempo real.} Figura~\ref{fig:DSec-LiveMonitor}. Muestra el proceso seguido por el sistema en el momento en el que solicita la vista correspondiente. Es el único diagrama en el que se muestra la comprobación de si es administrador o no, por brevedad en el resto se indica en forma de texto nada más. @@ -71,7 +71,7 @@ \subsection{Diseño procedimental} \subsection{Diseño arquitectónico} \imagenFlotante{../img/anexos/design/client-server}{Arquitectura cliente-servidor.}{client-server} -La aplicación con el fin de cumplir con todos los requerimientos funcionales así como objetivos principales, y por ende, conseguir un bajo acoplamiento y una alta cohesión. Sigue una arquitectura de cliente servidor. +La aplicación con el fin de cumplir con todos los requerimientos funcionales, así como objetivos principales, y, por ende, conseguir un bajo acoplamiento y una alta cohesión. Sigue una arquitectura de cliente servidor. En la Figura~\ref{fig:client-server} se aprecia un modelo simplificado de la arquitectura seguida, en la cual los procesos se van a dividir en dos grupos. \begin{itemize} @@ -80,7 +80,7 @@ \subsection{Diseño arquitectónico} \end{itemize} \subsubsection{Arquitectura de tres capas} -La aplicación sigue una arquitectura de tres capas (multicapa), siguiendo esta arquitectura el cliente implementa la lógica de presentación (es un cliente ligero); el servidor de aplicación implementa la lógica de negocio, y los datos residen en una base de datos de \texttt{SQLite}, por definición de la arquitectura de tres capas sería necesario que hubiera un servidor dedicado a la comunicación con la base de datos, pero ahí es donde reside una de las cualidades de \texttt{SQLite}, es \textit{serverless}, permitiendo una auto-gestión y soportando múltiples clientes realizando tareas en paralelo. +La aplicación sigue una arquitectura de tres capas (multicapa), siguiendo esta arquitectura el cliente implementa la lógica de presentación (es un cliente ligero); el servidor de aplicación implementa la lógica de negocio, y los datos residen en una base de datos de \texttt{SQLite}, por definición de la arquitectura de tres capas sería necesario que hubiera un servidor dedicado a la comunicación con la base de datos, pero ahí es donde reside una de las cualidades de \texttt{SQLite}, es \textit{serverless}, permitiendo una autogestión y soportando múltiples clientes realizando tareas en paralelo. UBUMLaaS sigue esta arquitectura por las siguientes razones: \begin{itemize} diff --git a/docs/tex/D_Manual_programador.tex b/docs/tex/D_Manual_programador.tex index 6b18c9f..c130ebf 100644 --- a/docs/tex/D_Manual_programador.tex +++ b/docs/tex/D_Manual_programador.tex @@ -3,7 +3,7 @@ \section{Introducción} En este anexo se va a describir con detalle la documentación técnica de programación. Se describirá la estructura de directorios que posee, la instalación del propio entorno de desarrollo, cómo llevar a cabo su compilación, instalación y ejecución; además de las pruebas que se han realizado. -Se debe recordar que el proyecto se encuentra dividido en dos repositorios diferenciados, UBUMLaaS e IS-SSL\footnote{Biblioteca de algoritmos de selección de instancias y aprendizaje semi-supervisado programado.}; es por ello que, se dividirá en dos secciones respectivamente, y tantas subsecciones como son necesarias para cada uno de ellos. +Se debe recordar que el proyecto se encuentra dividido en dos repositorios diferenciados, UBUMLaaS e IS-SSL\footnote{Biblioteca de algoritmos de selección de instancias y aprendizaje semi-supervisado programado.}; es por ello por lo que, se dividirá en dos secciones respectivamente, y tantas subsecciones como son necesarias para cada uno de ellos. Ambos repositorios son consultables desde: \begin{itemize} @@ -174,7 +174,7 @@ \subsubsection{Importar el proyecto en Visual Studio Code} \begin{enumerate} \item Presionar \texttt{F1} y correr el comando: \texttt{Remote-SSH: Open SSH Host...} \item Introducir el usuario y el \texttt{host/IP} en el formato:\\ -\texttt{user@host-o-ip} ó \texttt{user@domain@host-o-ip} +\texttt{user@host-o-ip} o \texttt{user@domain@host-o-ip} \item En caso de que se solicite, introducir la contraseña, pero se recomienda configurar el uso de llaves SSH, ver guía~\cite{Remote-Development-Tricks-Tips}. \item Después de la conexión usar Archivo $\rightarrow$ Abrir carpeta, para abrir el directorio donde se encuentra el proyecto en la máquina remota. \end{enumerate} @@ -213,6 +213,10 @@ \subsubsection{Instalación en Linux} export EMAIL_URL= export FLASK_ENV=development #development or production LIBFOLDER=/absolute/path/to/UBUMLaaS +export MONITOR_DISK_USED= +export MONITOR_DISK_SIZE= +export MONITOR_NETWORK_RX=
+export MONITOR_NETWORK_TX=
\end{lstlisting} \item Dentro del entorno virtual de UBUMLaaS en \texttt{Conda}, se debe ejecutar el siguiente comando para permitir la importación de las variables anteriormente declaradas al entorno virtual.\\ \texttt{source env\_vars\_to\_conda.sh} @@ -260,7 +264,7 @@ \subsubsection{Travis-CI} Herramienta \textit{cloud} desarrollada para la realización de pruebas de integración continua sobre proyectos alojados en GitHub (con soporte beta para BitBucket, GitLab y Assembla). Permite realizar un \textit{build} del proyecto y ejecutar sobre ella una batería de pruebas de manera automática cada vez que se realiza un \textit{commit} y/o \textit{pull request}, permitiendo pruebas concurrentes, incluso sobre diferentes sistemas operativos (Linux, Windows, macOS y FreeBSD). Con el proyecto configurado en \texttt{Travis-CI} se debe configurar un fichero \texttt{YAML} y debe de estar en el directorio raíz, será a partir del cual se ejecuten las pruebas. - +\imagenFlotante{../img/anexos/manual-programador/Travis-CI-UBUMLaaS}{Travis-CI.}{Travis-CI-UBUMLaaS} El fichero se encuentra dividido en: \begin{itemize} \tightlist @@ -279,17 +283,14 @@ \subsubsection{Travis-CI} \item \texttt{before\_script:} configuración de dependencias antes de ejecutar la sección \texttt{script}. \item \texttt{script:} pruebas a realizar. \end{itemize} - Los \textit{logs} son públicos y consultables desde~\cite{Travis-CI-LOG-UBUMLaaS}. - -\imagenRuta{../img/anexos/manual-programador/Travis-CI-UBUMLaaS}{Travis-CI.}{Travis-CI-UBUMLaaS} - +\FloatBarrier \subsection{Pruebas del sistema} Las pruebas del sistema se encuentran dentro de los trabajos futuros que debe seguir la aplicación. Tal y como se ha descrito, \texttt{UBUMLaaS} es un \textit{software} que ha sufrido un cambio de diseño de grandes dimensiones, por lo que las pruebas de integración continua previas que existían han dejado de ser funcionales. La problemática que surge con las existentes es que no eran pruebas sobre el \textit{backend} de la aplicación, sino la interacción del usuario (mediante el uso de \textit{Selenium}) con el \textit{frontend}. -Es por ello que, al haberse hecho <> toda la interfaz de la aplicación web, literalmente, no existe ninguna referencia de las antiguas que las pruebas existentes puedan reutilizar. +Es por ello por lo que, al haberse hecho <> toda la interfaz de la aplicación web, literalmente, no existe ninguna referencia de las antiguas que las pruebas existentes puedan reutilizar. Debido a esta problemática, y con el fin de obtener un sistema estable, se ha seleccionado a un grupo de personas de edades comprendidas entre 18 y 55 años, profesionales de mecánica y electrónica, medicina, informática y estudiantes del grado de otras universidades españolas; con el fin de que dado un \href{https://github.com/dpr1005/Semisupervised-learning-and-instance-selection-methods/blob/917d49bcc9d7f1a4825225414b246023bfa2ea7b/docs/misc/survey_steps.pdf}{documento} relativamente sencillo, puedan hacer uso de todo el sistema, y sean estos los que reporten en un \href{https://forms.gle/eZUWmT5GNahqYVVa6}{formulario de \texttt{Google}} sus impresiones y resultados. Está preparado para que se vaya leyendo el documento, probando la aplicación y posteriormente rellenando el formulario, de forma que todo sea un proceso auto-guiado. @@ -340,7 +341,7 @@ \subsubsection{Python 3.7+} El desarrollo se ha realizado siguiendo las últimas formas de programación disponibles a partir de la versión 3.7 de Python. El desarrollo se comenzó después de que se dejara de mantener Python 2, por lo que se trabajó desde el inicio con versiones de Python 3. Se puede obtener la última versión disponible de Python desde~\cite{pythonGetIt}. Es importante que el desarrollador se asegure que los binarios han sido añadidos al \texttt{path} del sistema que esté utilizando. \subsubsection{Bibliotecas Python} -Esta sección es la más importante de todas junto con la anterior, debido a que el proyecto depende de (está construido utilizando) bibliotecas de $3^{os}$. Y en especial, determinadas versiones de las mismas. +Esta sección es la más importante de todas junto con la anterior, debido a que el proyecto depende de (está construido utilizando) bibliotecas de $3^{os}$. Y en especial, determinadas versiones de estas. En la Tabla~\ref{tab:bibliotecas-python-is-ssl} se detallan las bibliotecas necesarias para utilizar el proyecto tal y como se encuentra en el repositorio. Para el uso en exclusiva de las bibliotecas de \texttt{IS-SSL} se deben utilizar aquellas que se encuentran en negrita. @@ -409,7 +410,7 @@ \subsubsection{Adquisición del código fuente} \item En URL introducir:\\ \texttt{git clone https://github.com/dpr1005/\\Semisupervised-learning-and-instance-selection-\\methods.git} \end{itemize} -\item Hacer \textit{click} en \textit{Clone the repo!}. +\item Hacer \textit{click} en \textit{Clone the repo!} \end{itemize} \end{itemize} @@ -486,7 +487,7 @@ \subsubsection{Sonar Cloud} A pesar de que sea un proyecto \textit{open source} no es gratuita, y como todas las herramientas de estas características incluye una versión \textit{community} (gratuita) para aquellos proyectos que sean \textit{open source}. -El proceso de integración es sencillo, una vez registrados y asociada la cuenta con una de GitHub, se selecciona sobre qué proyecto se desea comenzar a analizar el código. El siguiente paso es definir un conjunto de reglas (si no se quiere utilizar el que se proporciona por defecto), y en cada \textit{pull request} que se realice al repositorio, Sonar Cloud analizará todos los cambios y emitirá un informe consultable desde la web así como un comentario en la propia \textit{pull request} con los resultados encontrados. +El proceso de integración es sencillo, una vez registrados y asociada la cuenta con una de GitHub, se selecciona sobre qué proyecto se desea comenzar a analizar el código. El siguiente paso es definir un conjunto de reglas (si no se quiere utilizar el que se proporciona por defecto), y en cada \textit{pull request} que se realice al repositorio, Sonar Cloud analizará todos los cambios y emitirá un informe consultable desde la web, así como un comentario en la propia \textit{pull request} con los resultados encontrados. \imagenRuta{../img/anexos/manual-programador/SonarCloud-IS-SSL}{SonarCloud.}{SonarCloud-IS-SSL} @@ -494,7 +495,7 @@ \subsection{Pruebas del sistema} En esta sección se van a describir las pruebas que poseen las bibliotecas. -Las pruebas son realmente sencillas, ya que los propios algoritmos no poseen muchas disyunciones. Es por ello que el conjunto de pruebas codificado está compuesto de pruebas unitarias para cada algoritmo programado, permitiendo comprobar tanto que las entradas son correctas, como sus salidas. En el caso de los algoritmos de selección de instancias se asegura que las instancias recuperadas pertenecen al conjunto de datos de entrada, y que no son más que las que se introdujeron en primera instancia. De tal manera que en caso de que los algoritmos se modifiquen, el filtrado lo sigan realizando. La prueba base se puede visualizar en la Figura~\ref{fig:base-test-is}. +Las pruebas son realmente sencillas, ya que los propios algoritmos no poseen muchas disyunciones. Es por ello por lo que el conjunto de pruebas codificado está compuesto de pruebas unitarias para cada algoritmo programado, permitiendo comprobar tanto que las entradas son correctas, como sus salidas. En el caso de los algoritmos de selección de instancias se asegura que las instancias recuperadas pertenecen al conjunto de datos de entrada, y que no son más que las que se introdujeron en primera instancia. De tal manera que en caso de que los algoritmos se modifiquen, el filtrado lo sigan realizando. La prueba base se puede visualizar en la Figura~\ref{fig:base-test-is}. Para la biblioteca de algoritmos de aprendizaje semi-supervisado se poseen también pruebas unitarias para todos y cada uno de ellos, la prueba base se puede visualizar en~\ref{fig:base-test-ssl}. En ellas se comprueban: \begin{itemize} @@ -525,12 +526,12 @@ \subsection{Validación} Los algoritmos de selección de instancias han sido testados contra los homónimos propuestos por \texttt{Weka}, y en ambos se han utilizado árboles de decisión (J48 en \texttt{Weka}) y vecinos más cercanos, como clasificadores base para realizar la comparativa. La experimentación se ha realizado mediante validación cruzada, con 5 \textit{folds}, tanto para \texttt{Weka} como para los implementados. Se ha tenido en cuenta la diferencia de lenguajes de programación Java (\texttt{Weka}) y los implementados en Python. -En las Tablas~\ref{tab:is-algs-checks-knn}~y~\ref{tab:is-algs-checks-tree} se aprecia la comparativa uno a uno de los resultados arrojados por cada uno de los algoritmos para cada uno de los clasificadores base utilizados. Si bien puede observarse como para determinados pares conjunto de datos : algoritmo, no son compatibles por diferentes motivos, la muestra es lo suficientemente grande como para asegurar una variación menor al $\pm 5\%$ su fiabilidad. +En las Tablas~\ref{tab:is-algs-checks-knn}~y~\ref{tab:is-algs-checks-tree} se aprecia la comparativa uno a uno de los resultados arrojados por cada uno de los algoritmos para cada uno de los clasificadores base utilizados. Si bien puede observarse como para determinados pares, conjunto de datos : algoritmo, no son compatibles por diferentes motivos, la muestra es lo suficientemente grande como para asegurar una variación menor al $\pm 5\%$ su fiabilidad. De igual manera, los algoritmos de aprendizaje semi-supervisado han sido validados contra los propios del grupo de investigación ADMIRABLE de la Universidad de Burgos. Estos últimos sí que se encuentran implementados en Python, por lo que se esperan resultados prácticamente idénticos. La experimentación en esta ocasión también se ha realizado con validación cruzada de 5 \textit{folds}, pero como se trata de conjuntos de datos de semi-supervisado, ha sido una validación cruzada estratificada. -En la Tabla~\ref{tab:ssl-algs-check} se aprecia la comparativa uno a uno de los resultados arrojados por cada uno de los algoritmos. En el caso del \textit{Co-Training}, la implementación desarrollada por este proyecto es capaz de soportar conjuntos de datos con más de dos vistas significativas (internamente las re-trabaja), mientras que el propuesto por ADMIRABLE no. Los resultados son tal y como se esperaba, con variaciones del $\pm 1\%$. +En la Tabla~\ref{tab:ssl-algs-check} se aprecia la comparativa uno a uno de los resultados arrojados por cada uno de los algoritmos. En el caso del \textit{Co-Training}, la implementación desarrollada por este proyecto es capaz de soportar conjuntos de datos con más de dos vistas significativas (internamente las retrabaja), mientras que el propuesto por ADMIRABLE no. Los resultados son tal y como se esperaba, con variaciones del $\pm 1\%$. \begin{landscape} \begin{table}[] diff --git a/docs/tex/E_Manual_usuario.tex b/docs/tex/E_Manual_usuario.tex index 6134a2b..969dad6 100644 --- a/docs/tex/E_Manual_usuario.tex +++ b/docs/tex/E_Manual_usuario.tex @@ -3,7 +3,7 @@ \section{Introducción} En esta sección se detallan los requerimientos de la aplicación, su instalación y despliegue (en el caso de \texttt{UBUMLaaS}) y se acompañan de una serie de indicaciones y consejos para su correcto uso. -De igual manera que en el Manual del Programador cada parte del proyecto, \texttt{IS-SSL} y \texttt{UBUMLaaS}, se describirá por su propio lado, de tal manera que aunque haya aspectos comunes, cada una su propia documentación de usuario. +De igual manera que en el Manual del Programador cada parte del proyecto, \texttt{IS-SSL} y \texttt{UBUMLaaS}, se describirá por su propio lado, de tal manera que, aunque haya aspectos comunes, cada una su propia documentación de usuario. \section{UBUMLaaS} En esta sección se va a presentar el manual de usuario para el correcto uso de la plataforma \texttt{UBUMLaaS}, de tal forma que sirva como guía para comprender y consiguientemente poder utilizar eficientemente el \textit{software} desarrollado. @@ -27,7 +27,7 @@ \subsection{Manual del usuario} \subsubsection{Registro} -Lo primero de todo una vez se conozca la URL en la que se encuentra desplegada la aplicación, es acceder a la misma, y se llegará a una página web similar a la Figura~\ref{fig:index-no-login}, pudiendo variar en función de la resolución del dispositivo (dispositivos móviles no son recomendados pero si tabletas). +Lo primero de todo una vez se conozca la URL en la que se encuentra desplegada la aplicación, es acceder a la misma, y se llegará a una página web similar a la Figura~\ref{fig:index-no-login}, pudiendo variar en función de la resolución del dispositivo (dispositivos móviles no son recomendados, pero si tabletas). \imagenFlotante{../img/anexos/manual-usuario/UBUMLaaS/index-no-login}{Página de inicio.}{index-no-login} @@ -44,7 +44,7 @@ \subsubsection{Registro} \item Se deberá indicar el uso que se le va a dar a la plataforma. \end{itemize} -Finalmente una vez se pulse el botón \texttt{Register} el cliente recibirá un correo electrónico (revisar la carpeta de correo no deseado o SPAM) con el enlace de verificación de la cuenta que acaba de crear. +Finalmente, una vez se pulse el botón \texttt{Register} el cliente recibirá un correo electrónico (revisar la carpeta de correo no deseado o SPAM) con el enlace de verificación de la cuenta que acaba de crear. Es importante tener en cuenta que mientras la cuenta no se encuentre verificada, permanecerá inactiva. En caso de tener algún problema con la activación, se recomienda contactar con soporte desde el mismo correo electrónico con el que se registró para solucionar los problemas que hayan podido surgir. @@ -149,7 +149,7 @@ \subsubsection{Modificación de datos del usuario y actualizar contraseña} En este momento se lanzará un modal el cual posee dos partes diferencias, modificación de datos personales, y en la parte inferior modificación de la contraseña. -Cuando se decida qué se quiere modificar, se deberá hacer \textit{click} en el \textit{checkbox} que se encuentra en la parte superior de cada formulario, lo cual habilitará la edición del mismo. Los formularios se encuentran en las Figuras~\ref{fig:edit-profile-data}~y~\ref{fig:edit-profile-passwd}, respectivamente. +Cuando se decida qué se quiere modificar, se deberá hacer \textit{click} en el \textit{checkbox} que se encuentra en la parte superior de cada formulario, lo cual habilitará la edición de este. Los formularios se encuentran en las Figuras~\ref{fig:edit-profile-data}~y~\ref{fig:edit-profile-passwd}, respectivamente. \begin{figure} \centering @@ -208,10 +208,10 @@ \subsubsection{Users} Un usuario no puede quitarse a sí mismo privilegios de administrador, ni desactivarse la cuenta, o eliminarla, teniendo que ser otro administrador el que lo haga; de esta manera el sistema siempre tendrá como mínimo un administrador. -A su vez se soporta crear un usuario haciendo \textit{click} en el botón verde \textit{New user}. Desplegándose un formulario y se deberán de rellenar los campos de correo electrónico, nombre de usuario, país y uso que se va a hacer; las restricciones de los campos existentes deben de seguir cumpliéndose. Al usuario se le generará una contraseña y al correo electrónico llega un correo, valga la redundancia, de activación de la cuenta, pero deberá de re-establecer la contraseña como si la hubiera olvidado antes de poder iniciar sesión por primera vez. +A su vez se soporta crear un usuario haciendo \textit{click} en el botón verde \textit{New user}. Desplegándose un formulario y se deberán de rellenar los campos de correo electrónico, nombre de usuario, país y uso que se va a hacer; las restricciones de los campos existentes deben de seguir cumpliéndose. Al usuario se le generará una contraseña y al correo electrónico llega un correo, valga la redundancia, de activación de la cuenta, pero deberá de reestablecer la contraseña como si la hubiera olvidado antes de poder iniciar sesión por primera vez. \subsubsection{Live System Monitor} -A la monitorización del sistema en tiempo real se accede a través del botón \textit{Live System Monitor} en la barra lateral. Cuando se hace \textit{click} se redirecciona a una vista similar a la que aparece en la Figura~\ref{fig:live-monitor}. En la parte superior derecha de la página a la que se llega hay un botón para activar si se quiere que la página se auto-recargue cada 60 segundos, desde el momento en el que se hace \textit{click}. +A la monitorización del sistema en tiempo real se accede a través del botón \textit{Live System Monitor} en la barra lateral. Cuando se hace \textit{click} se redirecciona a una vista similar a la que aparece en la Figura~\ref{fig:live-monitor}. En la parte superior derecha de la página a la que se llega hay un botón para activar si se quiere que la página se recargue automáticamente cada 60 segundos, desde el momento en el que se hace \textit{click}. \imagenFlotante{../img/anexos/manual-usuario/UBUMLaaS/live-monitor}{Vista de \textit{Live System Monitor}.}{live-monitor}