relecture, gestion et conclusion

chapitres/conclusions/resultats.tex

@@ -1,18 +1,19 @@
-\chapter{Résultats}
+\chapter{Résultats obtenus}
-
-\section{Aspects fonctionnels}
-
-D'un point de vue technique, l'application 
-
-\section{Aspects visuels}
-
-divers screenshots de l'application
-
-\chapter{Synthèses}
-
-\section{Retours du mandant}
 
 Au terme de la période de la réalisation de ce travail de bachelor, le résultat obtenu répond à l'ensemble des besoins exprimés dans le cahier des charges de la pré-étude. Le mandant du projet pour le CHUV ainsi que les membres de son équipe ont pu tester et utiliser l'application au cours de sa création et ainsi participer activement à son développement en donnant des retours réguliers.
 
-\section{Conclusion personnel}
+\chapter{Synthèse personnelle}
 
+En tant que premier projet de développement \emph{professionnel}, je suis non seulement satisfait du résultat mais surtout du chemin parcouru pour y arriver. Trouver des solutions pertinentes et savoir s'adapter à la situation sont pour moi deux des trais les plus importants d'un ingénieur. La problématique présentée dans ce projet est propre à la sécurité des réseaux informatiques, et sa parfaite compréhension m'a permis d'imaginer des solutions adéquates.
+
+Les différents modules suivi au cours de ma formation à la \acrshort{heig} m'ont amené certains outils qui ont été utiles durant la réalisation de ce projet. Les différents cours de programmation (bien que plus orienté pour des équipements embarqués) ont probablement contribué à améliorer ma logique et ma créativité lorsqu'il s'agit d'imaginer des algorithmes efficaces pour résoudre des problèmes. Le fait de mettre en pratique ces connaissances acquises est encore bien différent et je me suis rendu compte durant ce projet, que des idées qui semblent pertinentes au début, ne le sont plus par la suite. Savoir donc adapter le travail existants et continuellement l'améliorer et quelque chose que je me suis efforcé de faire pendant la phase de développement.
+
+La mise en pratique du \gls{tdd} comme méthode de développement m'a également beaucoup apporté. Il est vite devenu très naturel de décrire le comportement attendu par un objet ou une méthode et d'écrire ensuite le code nécessaire à sa mise en place. Cela m'a permis de m'assurer que ce qui était fonctionnel l'est toujours après l'ajout de nouvelles fonctionnalités. Ces tests sont également la base qui rend possible la mise en place des mécanismes d'intégration continue. Grâce à Gitlab, il va facilement pouvoir exécuter les taches de vérification et ne déployer le code que si l'ensembles des tests est validé.
+
+Bien que le réalisation de la partie métier en Ruby est vite devenue intuitive, la partie frontend, elle, m'a posé beaucoup plus de problèmes. N'ayant jamais abordés cette partie là dans le cadre de ma formation, j'ai donc découvert ce milieu au cours du projet. La logique requise pour ce genre développement est vraiment différente et les langages utilisés également. J'ai aussi eu beaucoup plus de peine à réellement tester l'interface et à simuler les actions d'un utilisateur.
+
+L'utilisation d'analyseur de code dès le début du projet m'a permis d'apprendre énormément sur les bonnes pratiques à utiliser en Ruby et avec le Javascript. Ces langages interprétés ont des syntaxes qui ont tendances à évoluer et à changer plus rapidement avec le temps. Ceci a pour effet de rendre plus rapidement obsolète la littérature à leur sujet. Grâce à ces analyseurs, j'ai pu m'assurer d'utiliser les syntaxes les plus a jour et de supprimer toutes utilisations de méthodes dépréciées. N'étant pas un développeur professionnel ni en Ruby ni en Javascript, suivre les recommandations validées par la communauté me semble être le meilleur choix pour avoir un code lisible et maintenable.
+
+L'utilisation de Gitlab tout au long du projet s'est trouvé être une bien meilleure idée que ce que j'imaginais au départ. Il m'a en effet permis de mettre en place des dépôts Git et d'appliquer la méthode Git Flow grâce notamment au \emph{merge request} intégrées. Mais il s'est avéré être un outil de qualité pour le suivi du projet de façon plus global. Définir les sprints (grâce aux \emph{milestones}) et ensuite y attribuer des taches (sous forme d'\emph{issues}) m'a permis de d'avoir en tout temps une vue globale sur l'avancement du projet. De plus, il est possible d'estimer le temps nécessaire à chaque tache et ensuite d'entrer le temps effectivement utilisé, ce qui permet ensuite d'avoir une vision précise du temps de travail. Enfin, les mécanismes intégré pour mettre facilement en place de l'intégration continue et du déploiement m'a permis de gagner beaucoup de temps tout au long du projet en mettant automatiquement à jour l'application.
+
+Pour finir, j'ai eu du plaisir à mettre en place quelques éléments des méthodes Agile au cours du projet. Le contact régulier avec les utilisateurs permet vraiment de mieux comprendre la problématique et d'adapter le code au fur et à mesure. C'est surtout vrai pour l'interface web, car c'est ce que le client va utiliser au final et donc personne n'est mieux placé pour donner un avis à ce niveau-là. D'un point de vue personnel, c'est aussi encourageant de savoir que le travail effectué est apprécié et avoir des retours de qualité permet d'améliorer encore un peu cela. Aux cours des diverses discussions, plusieurs idées d'améliorations sont venues et il est maintenant certain que le projet continuera.

chapitres/gestion/echeancier.tex

@@ -1,8 +1,8 @@
 \chapter{Échéancier détaillé}
 
-\section{Sprints}
+\section{Planification}
 
-La réalisation de ce présent travail de bachelor a été faite en suivant les \emph{User Stories} définis au chapitre "Analyse et planification" de la pré-étude. La période de réalisation en elle-même a été découpée en six \gls{sprint} de deux semaines. Le but est de pouvoir faire une revue avec le client à la fin de chacun d'entre eux, pour avoir des retours sur le travail effectué et réajusté la priorité d'une fonctionnalité si besoin. Le premier sprint ayant surtout consisté à mettre en place l'environnement de développement et le réseau de test, il n'y avait pas lieu de faire une revue, car il n'y avait rien de terminé à montrer au client. Le dernier sprint se termine le jour du rendu de ce présent rapport, aucune revue ne sera donc faite avant cette date.
+La réalisation de ce présent travail de bachelor a été faite en suivant les \emph{User Stories} définis au chapitre "Analyse et planification" de la pré-étude. La période de réalisation en elle-même a été découpée en six \glspl{sprint} de deux semaines. Le but est de pouvoir faire une revue avec le client à la fin de chacun d'entre eux, pour avoir des retours sur le travail effectué et réajusté la priorité d'une fonctionnalité si besoin. Le premier sprint ayant surtout consisté à mettre en place l'environnement de développement et le réseau de test, il n'y avait pas lieu de faire une revue, car il n'y avait rien de terminé à montrer au client. Le dernier sprint se termine le jour du rendu de ce présent rapport, aucune revue ne sera donc faite avant cette date.
 
 \vspace{3mm}
 \begin{table}[H]
@@ -26,20 +26,117 @@ La gestion des sprints est gérée par le serveur Gitlab sous la forme de "miles
 
 \begin{figure}[H]
     \centering
-    \includegraphics[width=100mm]{gitlab_milestones}
+    \includegraphics[width=160mm]{gitlab_milestones}
     \caption{Gestion des sprints avec Gitlab}
 \end{figure}
 
+Certaines fonctionnalités requièrent du développement sur plusieurs parties différentes du projet et ont donc été découpées en tâches afin de pouvoir en assurer un suivi plus précis. De plus, avant de pouvoir commencer la première partie de l'application, il a fallut mettre en place le réseau de test décrit dans la pré-étude (section 3.4) ainsi que l'environnement de développement. Tout cela a été regroupé dans une user story qui va précéder la première. La tableau suivant reprend donc la liste des fonctionnalités triées par priorités, les identifiants seront ensuite utilisés dans les détails des sprints. 
 
-\subsection*{Sprint - 1}
+\vspace{3mm}
 
-\textbf{Planification}
+\begin{table}[H]
+    \centering
+    \caption{Liste des User Stories}
+    \label{gestion-us-tab}
+    \begin{tabular}{|l|l|}
+    \hline
+    \textbf{Identifiant}             & \textbf{User Story}                              \\ \hline
+    0   &   Mise en place du réseau de test et de l'environnement de développement      \\ \hline
+    1   &   Obtenir les règles de sécurité d'un équipement Fortinet                     \\ \hline
+    2   &   Enregistrer les informations de connexion d'un équipement                   \\ \hline
+    3   &   Automatisation de la récupération des informations                          \\ \hline
+    4   &   Pérenniser les informations                                                 \\ \hline
+    5   &   Executer une recherche dans les règles de sécurité                          \\ \hline
+    6   &   Chiffrer les échanges                                                       \\ \hline
+    7   &   Pouvoir faire une recherche avec un formulaire WEB                          \\ \hline
+    8   &   Afficher les règles de sécurité de chaque équipement                        \\ \hline
+    9   &   Obtenir les règles de sécurité d'un équipement PaloAlto                     \\ \hline 
+    \end{tabular}
+\end{table}
 
-\noindent
+\vspace{3mm}
-Objectifs:
-\begin{itemize}
-    \item Mise en place de l'environnement de développement
-    \item Configuration du réseau de test
 
-\end{itemize}
+\newpage
+\section{Sprints}
 
+\subsection{Sprint 1}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=160mm]{sprint1}
+    \caption{Détail des taches du sprint 1}
+\end{figure}
+
+Une grande partie de ce sprint a été dédié à la préparation de l'environnement de travail requis pour ce projet. Cela comprend notamment la mise en place d'un serveur de virtualisation pour pouvoir mettre en place une instance Gitlab\cite{gitlabsite} ainsi que d'autres machines virtuelles qui se sont occupés d'exécuter et valider les différents tests. Avec cela, un mécanisme de backup journalier du serveur a été configuré pour se protéger contre une éventuelle perte de données.
+
+Le réseau de test (comme décrit dans la section sur le routage (\ref{subsec:network:ip:routing})) a ensuite été configuré pour simuler une architecture réseau utilisant les mêmes technologies que celles du CHUV. Ces équipements ont pu ensuite servir d'éléments de tests pertinents durant le développement de l'application.
+
+La seconde partie du sprint a servis à commencer le programme qui va permettre de pouvoir exécuter des requêtes sur les équipements Fortinet. 
+
+\newpage
+\subsection{Sprint 2}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=160mm]{sprint2}
+    \caption{Détail des taches du sprint 2}
+\end{figure}
+
+Sprint principalement orienté sur la création du backend. Mise en place de l'application, création des modèles de classe et intégration du module pour interfacer les Fortinet. Apprentissage de l'utilisation des outils de tests Ruby et mise en place de structure dans le code.
+
+Travail de recherche sur les mécanismes utilisés quand on veut faire du chiffrement symétrique. Mise en place de la solution SyymetricEncryption\cite{symmetricencryption} pour chiffrer les mots de passes des identifiants dans la base de donnée.
+
+Installation et configuration de objets pour pouvoir les stocker dans la base MongoDB. Utilisation de mongoid\cite{mongoid} également pour faire les tests de validation des attributs.
+
+Première revue avec les futurs utilisateurs pour valider les trois premières user stories. L'accès à l'information se fait via des requêtes HTTP qui ont été fournies sous la forme d'une collection pour le programme Postman\cite{postman}.
+
+\newpage
+\subsection{Sprint 3}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=160mm]{sprint3}
+    \caption{Détail des taches du sprint 3}
+\end{figure}
+
+Finalisation de l'intégration des objets dans MongoDB qui a permit de développer l'algorithme pour rechercher efficacement une règle de sécurité dans un équipement. Pour cela, il a fallu faire quelques modifications sur certains objets et notamment la conversion décimale pour les objets de type \Colorbox{light-gray}{\lstinline|Address|}.
+
+Création du projet pour la partie frontend de l'application avec une interface de recherche sobre mais qui permet de démontrer le bon fonctionnement de l'algorithme de recherche. La seconde revue a permis de valider cette fonctionnalité et ainsi que des retours sur l'interface WEB.
+
+\newpage
+\subsection{Sprint 4}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=160mm]{sprint4}
+    \caption{Détail des taches du sprint 4}
+\end{figure}
+
+Sprint complètement concentré sur la partie frontend du projet et également la mise en place du chiffrement SSL pour utiliser le protocole HTTPS. L'aspect visuel de la recherche de règle, ainsi que l'affichage des résultats retournés par celle-ci, a été revue pour prendre en compte les retours de la revue précédente. Pour cela, la façon de formatter les polices de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}) en JSON a été revue.
+
+L'interface WEB permet maintenant de voir les équipements gérés dans l'application et d'obtenir la liste des règles implémentées dans ceux-ci. La troisième revue a valider cette partie-là. Quelques retours supplémentaires sont arrivés concernant l'affichage des polices de sécurité.
+
+\newpage
+\subsection{Sprint 5}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=160mm]{sprint5}
+    \caption{Détail des taches du sprint 5}
+\end{figure}
+
+Création et développement du projet d'accès aux équipements PaloAlto, construit selon la même logique que celui pour les Fortinet. Il s'en suit l'intégration et le support de ces derniers dans l'application principale.
+
+Mise à jour de l'interface WEB pour améliorer l'affichage et l'ergonomie. La quatrième revue a permis de valider les dernières user stories, mais en remontant un problème qui survient dans certains cas avec des recherches qui inclus des équipements PaloAlto.
+
+
+\newpage
+\subsection{Sprint 6}
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=160mm]{sprint6}
+    \caption{Détail des taches du sprint 6}
+\end{figure}
+
+Corrections des derniers problèmes remontés et finalisation du présent rapport.

chapitres/introduction/network.tex

@@ -99,7 +99,7 @@ La notation \acrshort{cidr} est beaucoup utilisée dans cette application, il s'
 \end{table}
 \vspace{3mm}
 
-Ainsi le réseau \emph{192.168.1.0 255.255.255.0} peut s'écrire plus simplement \emph{192.168.1.0/24}. Cette notation est notamment utilisée dans les objets \Colorbox{light-gray}{\lstinline{Address}} et \Colorbox{light-gray}{\lstinline{Route}}, pour l'attribut "network".
+Ainsi le réseau \emph{192.168.1.0 255.255.255.0} peut s'écrire plus simplement \emph{192.168.1.0/24}. Cette notation est notamment utilisée dans les objets \Colorbox{light-gray}{\lstinline|Address|} et \Colorbox{light-gray}{\lstinline|Route|}, pour l'attribut "network".
 
 \newpage
 \subsection{Le routage}