Projet d'Ingénierie / QL
Pierre-Edouard PORTIER
Séance 1H4211
Guillaume ABADIE
Thierry CANTENOT
Juliette COURLET
Rémi DOMINGUES
Adrien DUFFY-CROISSARD
Ahmed KACHKACH
Architecture du système
Cas d'utilisation (1/3)
Sous-système contrôleur
-
Synchroniser et configurer une balance
-
Affecter un produit à une balance
-
Choisir l’événement déclenchant une livraison
-
Demander la livraison d'un produit
-
Signaler la panne d'une balance
Cas d'utilisation (2/3)
Sous-système planification
Cas d'utilisation (3/3)
Sous-système livraison
- Entrer dans le réseau urbain
- Suivre un itinéraire
- Déposer des produits à livrer
- Retour à l'entrepôt
Phasage
Nous diviserons ce projet en 4 grandes phases :
-
Organisation du projet
-
Expression des besoins
-
Conception du système
- Conception de l’algorithme d’optimisation de chemins
Organisation du projet
- Dossier d'initialisation
- Procédures pour le contrôle qualité
-
Procédure d'assurance de la traçabilité entre modèles
Expression des besoins
- Analyse de l'existant
- Recueil des exigences
- Description des cas d'utilisation
Conception du système
- Modèles de l'environnement
- Modèles des concepts
- Modèles de protocole
- Architecture du système
-
Spécifications OCL des opérations
Algorithme d'optimisation
- Spécifications OCL
- Ecriture de l'algorithme
-
Réflexion sur performances/limitations
Répartition des tâches
Itération courante
Prochaine itération
Procédures de contrôle qualité
- Mise en place de règles définissant les outils utilisés
LaTeX, Git, Trello
Mise en place de règles sur la présentation et l'organisation des documents.
- Pour chaque document, il faudra conserver dans un dossier sur GitHub :
- Le fichier au format texte.
- Un Makefile pour facilement créer le PDF.
- Les différents fichiers insérés (images, tableaux, etc...).
- On a choisi de ne pas garder le document PDF sur le dépôt pour une question d'espace mémoire.
- Les titres seront indentés en fonction de leurs importances.
- Ne pas hésiter à aérer le texte en passant à la ligne, ou à faire des listes.
Mise en place de règles de "bon usage"
"Une pré-condition d'un cas d'utilisation doit se retrouver dans la post-condition d'un autre cas d'utilisation !"
Mise en place d'un glossaire
Traçabilité
Pourquoi ?
=> Besoin de s'assurer que ce qui est prévu au départ est bien réalisé à la fin d'un projet.
=> Besoin d'avoir les liens de cause à effet entre les différents éléments d'un projet, afin de pouvoir connaitre ce sur quoi un élément va influencer, et quel élément est à l'origine d'un autre.
Que doit-on tracer ?
- Besoin client <-> Cas d'utilisation
- Cas d'utilisation <-> Exigence produit (fonctionnelle)
- Exigence produit <-> Exigence d'architecture
- Exigence produit <-> Algorithme
- Exigence produit <-> Tests
- Algorithme <-> Tests
Comment réaliser la traçabilité ?
Simple quand il s'agit de chose nommables
-> Graphique récapitulatif avec une convention de nommage
(exigences, tests, CDU)
Plus complexe quand il s'agit de l'algorithme :
-> Séparation intelligente en fonctions correspondants à une seule exigence
-> Indexation par fonctions, tests, exigences
Avancement
Dossier d'initialisation (80 %)
Procédures de contrôle qualité (30%)
Procédure d'assurance de la traçabilité entre modèles (30%)
Architecture système (50%)
Description des cas d'utilisation (60%)
Des questions?
Nom du cas d'utilisation :
\begin{formalisme}
\item[Contexte~:]
\item[Acteurs~:]
\item[Scénario principal~:] ~\\
\begin{itemize}
\item début du scénario~;
\item élément du scénario~;
\item fin du scénario~;
\end{itemize}
\end{description}
Règles de bonne utilisation :
\begin{formalisme}
\item Lors de l'écriture d'un cas d'utilisation, si une pré-condition est présente, bien s'assurer qu'un autre cas d'utilisation a cette condition en post-condition.
La Qualité, c'est bien
By hexamome
