mirror of
https://github.com/LucasVbr/interpreteur-lir.git
synced 2026-05-13 17:21:52 +00:00
101 lines
5.7 KiB
TeX
101 lines
5.7 KiB
TeX
% \chapter{Organisation du projet}
|
||
|
||
\section{Présentation du cycle de vie itératif} % TODO relecture
|
||
Pour développer l’Interpréteur LIR, le modèle de cycle de vie itératif a été
|
||
choisi. Ce modèle de développement de logiciel consiste en une succession de
|
||
cycles de spécification, de conception, de réalisation et de tests, le but
|
||
est d’enrichir et de « remodeler » des prototypes du logiciel successifs. Par
|
||
conséquent, une version du logiciel sera un « dernier prototype ».
|
||
\\La gestion du risque va entraîner la mise en place d’un noyau architectural
|
||
avec des fonctions indispensables du logiciel dès les deux premières
|
||
itérations. Les itérations suivantes apporteront des corrections et de
|
||
nouvelles fonctions au logiciel.
|
||
\\Les versions successives des prototypes permettent de matérialiser
|
||
l’avancement et d’éviter « l’effet tunnel » sur le projet. Ces prototypes
|
||
(versions 0.x) entretiennent la motivation des différents acteurs du projet :
|
||
l’équipe MOE, la MOA.
|
||
\\Le principe fondamental à chaque début d’itération est de ne spécifier en
|
||
détail que les fonctionnalités nécessaires pour cette itération. Ainsi la
|
||
prise en compte d’évolutions du besoin reste possible jusqu'à la dernière
|
||
itération. De même le « refactoring » de la conception (largement facilité
|
||
par les outils) a lieu à chaque étape pour intégrer des évolutions et des
|
||
ajouts. Le but étant bien sûr de fabriquer le logiciel adapté au besoin en
|
||
laissant la possibilité de « mûrir » au cours du temps.
|
||
\\Ce type de cycle implique une taille homogène de l’équipe et une
|
||
polyvalence des équipiers.
|
||
|
||
\section{Répartition des rôles}
|
||
Rôles des membres de l’équipe impliqués dans le projet jusqu'au mois de mai
|
||
2021 :
|
||
\begin{center}
|
||
\begin{tabular}{rl}
|
||
Chef de projet MOE & Pierre Debas \\
|
||
Secrétaire de projet & Heïa Dexter \\
|
||
Gestionnaire de configuration & Sylvan Courtiol \\
|
||
Développeur & Nicolas Caminade \\
|
||
Développeur & Lucàs Vabre \\
|
||
\end{tabular}
|
||
\end{center}
|
||
|
||
\section{Plan communication}
|
||
\subsection{Localisation géographique des intervenants}
|
||
L'équipe MOE, la MOA et les contrôleurs qualités sont basés sur Rodez (12).
|
||
\\La MOA, les contrôleurs qualités, H. Dexter sont basés sur Rodez (12), S.
|
||
Courtiol sur Luc-La-Primaube à côté de Rodez (12), P. Debas est basé à la
|
||
fois sur Rodez et à Albi (81), L. Vabre sur Gages (12) et N. Caminade sur
|
||
Rodez et Moncaut (47).
|
||
|
||
\subsection{Moyens de communication utilisés}
|
||
Les communications formelles sont effectuées via les mails de l’IUT
|
||
(généralement par le chef de projet) avec les autres membres du projet en CC.
|
||
\\Serveur Discord spécifique au projet pour communication écrite ou vocale de
|
||
la MOE.
|
||
\\Cf. le document Configuration interpréteur du langage LIR produit par le
|
||
gestionnaire de configuration (S. Courtiol).
|
||
|
||
\subsection{Réunions projets MOE}
|
||
Les réunions projet MOE seront hebdomadaires voire bi-hebdomadaires et dans
|
||
le contexte de la crise sanitaire elles se dérouleront en distanciel via
|
||
Discord (vocal, visio-conférence). Seront prévue des réunions courtes de 20
|
||
minutes et des réunions longues de 1h30.
|
||
\\Ces réunions auront pour objectif de faire le point sur l’avancement du
|
||
projet, le respect des objectifs fixé sur la période et de fixer les
|
||
prochains objectifs à remplir d’ici la prochaine réunions. Aussi ces réunions
|
||
seront l’occasion de faire part de difficultés éventuelles rencontrées par
|
||
les membres de l’équipe au cours de la semaine et de communiquer les
|
||
informations sur les prochaines rencontres avec la MOA.
|
||
\\Les comptes-rendus seront rédigés par la secrétaire de projet (H. Dexter)
|
||
et diffusés sur le serveur Discord de l’équipe sous format texte.
|
||
|
||
\subsection{Comités de Pilotage}
|
||
Les comités de pilotage rassembleront la MOA et toute l’équipe de MOE. Les
|
||
COPIL seront dirigé par le chef de projet éventuellement assisté par le
|
||
secrétaire.
|
||
\\La fréquence des COPIL est au mieux hebdomadaire et d’une durée d’une
|
||
demi-heure à trois quarts d’heure selon l’avancement du projet.
|
||
Les comptes-rendus des COPIL seront rédigés par l’actuelle secrétaire de
|
||
projet (H. Dexter) et diffusés le lendemain à la MOE du projet.
|
||
|
||
|
||
\section{Assurance qualité}
|
||
\subsection{Normes et standards de travail à observer (formalisme de modélisation, méthodes de contrôle, méthodes de développement, cycle de vie, conventions de code…)}
|
||
Pour mener à bien ce projet l'équipe MOE travaille
|
||
en utilisant le langage UML comme formalisme de modélisation, la méthode de
|
||
développement dirigé par les tests i.e. la méthode TDD (Test Driven
|
||
Development) en respectant les Java Code Convention pour un modèle de cycle
|
||
de vie itératif.
|
||
|
||
%\subsection{Manuel qualité et démarche qualité à observer (suivant la politique qualité de l’organisation), suivi et contrôle qualité (organisation, fréquence, participants).}
|
||
|
||
|
||
\section{Ressources matérielles et logicielles}
|
||
La partie qui suit est un résumé du document de gestion de la configuration joint
|
||
au dossier technique. Merci de vous y référer pour plus de détails.
|
||
|
||
La conception en langage UML sera effectuée sous Modelio. La rédaction des
|
||
différents documents du dossier sera faite en utilisant \LaTeX. Nous utiliserons
|
||
Eclipse configuré avec un \emph{workspace} similaire à celui utilisé lors de nos
|
||
cours de programmation. Les dépôts en ligne et le contrôle de l'historique des
|
||
versions seront assurées par Git, plus précisément via GitHub. Lavancement sera
|
||
contrôlé sur un tableau Trello. Enfin, la communication sera assurée via un
|
||
serveur Discord dédié ou Google Meet pour les visio-conférences. |