UniversityLib

Génie Logiciel - Projet de Développement d'un Logiciel d'Aide à la Régulation Aéroportuaire

École Nationale des Sciences de l'Informatique (ENSI)
1/2
100%
Rendu du PDF...
Page 1 sur 2Lecteur de document UniversityLib

Génie Logiciel - Projet de Développement d'un Logiciel d'Aide à la Régulation Aéroportuaire

École Nationale des Sciences de l'Informatique (ENSI) · Programming, Software Engineering · exam

Voir tous les documents en génie logiciel

Fiche de révisionCorrigé

Corrigé – Génie Logiciel - Projet de Développement d'un Logiciel d'Aide à la Régulation Aéroportuaire

Rédigée à partir de ce document, puis vérifiée avant publication.

Phase 1 - La pré-étude

Quels sont les problèmes qui ont provoqué la naissance du projet L ?

Le problème principal découle de l'augmentation continue du volume des vols. Actuellement, le régulateur (R) gère l'affectation de plus de 500 tâches quotidiennes et les aléas (retards, absences, etc.) à l'aide d'un simple planning au format papier, modifié au crayon. Face à la croissance du trafic, ce système manuel a atteint ses limites : il est devenu trop lent, source d'erreurs, et ne permet plus à R de planifier ou de réagir aux imprévus en temps réel de manière efficace.

Que peut faire R, étant donné sa situation problématique ?

En tant qu'utilisateur principal souffrant de cette situation, R doit faire remonter le problème. Il peut alerter sa hiérarchie sur les risques d'erreurs (qui pourraient impacter le fonctionnement de l'aéroport) et exprimer son besoin critique pour un outil automatisé et dynamique qui l'aiderait à visualiser et modifier les plannings instantanément.

Que peut faire U ?

U étant le représentant des utilisateurs (R et les agents Aj), son rôle est de centraliser, formaliser et porter la demande de R et des agents auprès de la direction. Il a le pouvoir de déclencher une étude d'opportunité pour justifier le lancement d'un projet informatique (le projet L) visant à résoudre ce goulot d'étranglement.

Que font U, R et I ?

Ensemble, ils mènent l'étude de faisabilité.

  • R et U apportent l'expertise métier : ils décrivent la situation actuelle, les limites atteintes et les gains attendus d'un nouveau système.
  • I (le responsable de l'informatique existante) évalue la faisabilité technique : il vérifie si l'idée s'intègre dans le système d'information actuel de l'aéroport (par exemple, comment récupérer les données du service de recherche opérationnelle) et estime les contraintes techniques et financières. Leur collaboration permet de décider si le projet L doit être lancé (Go/No-Go).

Phase 2 - La phase de spécification des besoins

Quels sont les acteurs de cette phase ?

Les acteurs principaux sont U (qui porte la voix des utilisateurs), P (le chef de projet qui rédige les spécifications), et I (pour s'assurer que les besoins sont compatibles avec l'informatique existante). R et certains Aj peuvent être consultés via U.

Quel est le rôle de U pendant cette phase ?

U est la maîtrise d'ouvrage (MOA) déléguée. Son rôle est d'exprimer clairement, de manière exhaustive et sans ambiguïté les besoins fonctionnels du futur logiciel L. À la fin de cette phase, U devra valider (signer) le cahier des charges.

Quel est le rôle de P pendant cette phase ?

P représente la maîtrise d'œuvre (MOE). Son rôle est de recueillir les besoins exprimés par U, de les analyser, de lever les ambiguïtés et de les formaliser dans un document contractuel de référence : le document de spécification des besoins (ou cahier des charges).

A quoi servent les développeurs dans cette phase ?

Généralement, les développeurs (Di) n'interviennent pas ou très peu dans cette phase purement fonctionnelle. Toutefois, P peut faire appel à eux pour évaluer la faisabilité technique d'une fonctionnalité complexe demandée par U, ou pour réaliser un maquettage rapide (prototype) afin d'aider U à mieux visualiser un besoin.

Quel est le rôle de I ?

I veille à ce que les spécifications prennent en compte les contraintes d'intégration. Par exemple, le logiciel L doit importer les "plannings prévisionnels" générés un mois à l'avance. I définit comment L va communiquer avec ce système existant (formats de fichiers, bases de données, réseaux).

Comment les agents Aj auront-ils connaissance de leur prochaine tâche ?

C'est un point crucial de spécification. Puisque l'on supprime le "papier modifié au crayon", les agents ne pourront plus venir consulter le bureau de R de la même manière. Lors des spécifications, U et P devront définir une nouvelle interface : cela pourrait être des écrans d'affichage répartis dans l'aéroport, des terminaux mobiles fournis aux agents, ou des bornes interactives. Le besoin est "l'accès instantané à l'information mise à jour par R".

Comment I et U vont-ils suivre l'avancement du projet L ?

Ils suivront l'avancement grâce à des indicateurs de pilotage, des réunions régulières (comités de pilotage ou revues de projet) organisées par P, et par la lecture des rapports d'avancement et des livrables documentaires.

Quelles sont les bonnes questions sur les fonctionnalités du logiciel qu'il faudra poser à U pour la spécification des besoins ?

Pour concevoir un bon outil de régulation, P doit interroger U sur les scénarios métier :

  • Comment R doit-il être alerté d'un vol supplémentaire ou d'un retard ?
  • Quelles règles définissent l'affectation d'un agent (compétences spécifiques pour les handicapés, temps de pause) ?
  • Comment R souhaite-t-il visualiser les conflits (ex: deux tâches assignées au même agent en même temps) ?
  • Que doit voir exactement un agent Aj sur son écran ?

Comment I et U pourront-ils vérifier que L répondra à leurs besoins ?

En s'appuyant sur le cahier des charges. Ils doivent exiger que les besoins soient testables et définir, dès cette phase, les critères d'acceptation et les jeux d'essai. La validation se fera via des revues de maquettes en cours de route, puis lors de la phase de recette (tests d'acceptation) à la fin du cycle.

Comment se termine cette phase ?

Cette phase s'achève par la validation formelle (signature) du cahier des charges / document des spécifications fonctionnelles par les représentants des clients (U et I). Ce document devient la référence stricte pour la suite du développement.

Phase 3 - La phase de conception globale

Quel est le principal acteur pendant cette phase ? Que doit-il faire ?

Le principal acteur est le chef de projet P (ou un architecte logiciel sous sa direction). Il doit traduire le cahier des charges en une architecture technique. Il définit les grandes briques du logiciel, l'architecture du système, le modèle de données relationnel, et les interfaces entre les modules.

Comment P découpe-t-il L en modules ?

P va utiliser une approche descendante ou modulaire, en regroupant les fonctionnalités par domaine de cohérence. Par exemple, il pourrait définir :

  • Un module de gestion des données prévisionnelles (interface avec le système de la recherche opérationnelle).
  • Un module d'interface de régulation dynamique pour R (le cœur du système, gestion des glisser-déposer, alertes).
  • Un module de consultation pour les agents Aj.
  • Un module de gestion de la base de données centrale.

Choix du matériel de développement ?

Ce choix est fait en concertation entre P et I. Il faut définir les serveurs, les postes de travail pour les développeurs, et s'assurer que ce matériel simule correctement l'environnement de production de l'aéroport géré par I.

Choix des outils de développement ?

P choisit les langages de programmation, les environnements de développement intégrés (IDE), les frameworks, et les outils de gestion de version (ex: Git) en fonction de la complexité du projet et des compétences des développeurs (Di) de son équipe.

Comment se termine cette phase ?

Elle se clôt par la production et la validation du document de conception architecturale (ou conception préliminaire). Ce document fige l'architecture du système avant de passer aux détails.

Phase 4 - La phase de conception détaillée

Quels sont les acteurs de cette phase ?

Les acteurs sont le chef de projet P (qui supervise) et l'équipe de développeurs Di (D0 à D4).

Quel est le rôle de P pendant cette phase ?

P distribue les modules définis lors de la conception globale aux différents développeurs (Di). Il coordonne le travail, s'assure que chaque conception détaillée respecte l'architecture globale, et prépare le terrain pour les tests.

Qu'écrivent les développeurs pendant cette phase ?

Chaque développeur (Di) rédige le dossier de conception détaillée de son module. Cela inclut les algorithmes spécifiques, les structures de données locales, les requêtes SQL complexes, et les diagrammes de classes/séquences précis nécessaires pour écrire le code sans ambiguïté.

Que doit prévoir P pour la validation future des modules de L ?

P doit rédiger le plan de tests. Il doit prévoir les plans de tests unitaires (pour valider chaque module isolément) et le plan de tests d'intégration (pour valider que les modules communiquent bien ensemble comme prévu dans la conception globale).

Du fait qu'ils sont responsables de modules qui interagiront avec un être humain, qu'écrivent D0 et D1 de plus que les autres développeurs ?

D0 et D1 travaillent probablement sur les modules d'interface utilisateur (pour R et pour Aj). Contrairement aux développeurs "back-end", ils doivent spécifier l'Ergonomie et l'Interface Homme-Machine (IHM). Ils écriront les maquettes d'écrans, définiront les flux de navigation (ex: que se passe-t-il quand R clique sur "Affecter"), et rédigeront les règles de validation des formulaires.

Phase 5 - Les phases de codage et tests

Quels sont les acteurs de cette phase ?

Les développeurs Di (D0 à D4) sont les acteurs exclusifs de cette étape technique, toujours sous le contrôle de P.

Que font-ils pendant cette phase ?

Ils traduisent les spécifications détaillées en code source dans les langages choisis. Immédiatement après avoir codé, ils exécutent les tests unitaires prévus par P pour vérifier que leurs fonctions ne contiennent pas d'erreurs (bugs), puis ils procèdent aux tests d'intégration pour s'assurer que le module de D0 fonctionne correctement avec le module de D2, par exemple.

Phase 6 - La phase d'installation

Quels nouveaux acteurs interviennent dans cette phase ?

Les utilisateurs finaux entrent véritablement en scène : le régulateur R et les agents au sol Aj. (U et I sont également présents pour encadrer le déploiement).

Que se passe-t-il si R et Aj trouvent que L ne répond pas à leurs besoins ?

C'est le scénario d'un échec lors de la recette (tests d'acceptation). Si le logiciel s'écarte du cahier des charges, P et son équipe (Di) doivent corriger les anomalies (bugs) pour rendre L conforme. Si le cahier des charges a été respecté mais que le besoin réel a changé (ou était mal exprimé), U devra négocier un avenant au projet pour développer de nouvelles fonctionnalités. Dans l'immédiat, la mise en production peut être suspendue.

Que se passe-t-il si R et Aj trouvent que L répond à leurs besoins ?

L'équipe cliente (U, au nom de R et Aj) signe le procès-verbal de recette définitive. Le logiciel est officiellement accepté et déployé en production dans l'aéroport. L'ancien système papier est abandonné. Le projet passe alors de la phase de "développement" à la phase de "maintenance".

Phase 7 - La phase de maintenance

Quels types de problèmes peuvent se poser après le développement ?

On distingue trois grandes catégories de maintenance informatique :

  1. La maintenance corrective : R ou Aj découvrent un bug (une erreur de programmation) qui n'avait pas été détecté lors des tests (ex: une tâche d'enfant non accompagné disparaît de l'écran si R la déplace deux fois).
  2. La maintenance adaptative : L'environnement informatique de l'aéroport géré par I évolue (ex: mise à jour du système d'exploitation des postes de R, ou changement du format de données de la recherche opérationnelle). Le logiciel L doit être adapté pour continuer à fonctionner.
  3. La maintenance évolutive : L'aéroport grandit, de nouvelles règles métiers apparaissent (ex: nouveau terminal, nouvelles règles syndicales pour les pauses des agents Aj). Le logiciel doit évoluer pour intégrer de nouvelles fonctionnalités non prévues à l'origine.

Méthode

Face à une étude de cas en Génie Logiciel portant sur le cycle de vie d'un logiciel :

  1. Identifiez les acteurs et leurs rôles types : Ne confondez jamais la maîtrise d'ouvrage (MOA = le client, les utilisateurs, "ceux qui ont le besoin" : ici U, R, Aj) avec la maîtrise d'œuvre (MOE = ceux qui réalisent, "ceux qui ont la compétence technique" : ici P, Di). I joue souvent un rôle de contrainte environnementale (MOA technique).
  2. Suivez la chronologie (Cycle en V ou Cascade) : Chaque question correspond à une étape. La sortie d'une étape (ex: le cahier des charges) est l'entrée indispensable de l'étape suivante. Les réponses doivent refléter cette dépendance.
  3. Reliez la théorie au cas pratique : Ne vous contentez pas de recracher la définition du cours. Utilisez le vocabulaire du sujet (mentionnez les avions, les plannings papiers, les agents Aj et le régulateur R) pour prouver que vous avez compris l'application concrète des concepts.
  4. Traitez chaque phase pour ses livrables : À chaque question "Comment se termine cette phase ?", la réponse attendue est presque toujours le nom d'un document validé et signé (Cahier des charges, Dossier d'architecture, PV de Recette). C'est ce qui formalise le passage à l'étape suivante.

Toutes les révisions