rapport 2 pour analyse de conception de systèmes … · rapport ii Étude de cas : port de québec...

IFT-21453 Analyse et conception de systèmes d'information

Rapport II

Étude de cas : port de Québec

Présenté à

Luc Lamontagne

et Walid Chaker

Par

Maxime Vallières (02 310 050) Simon Lessard (03 151 164)

Jean-François Roy (03 162 559)

14 avril 2005

©2005 Lessard, Roy et Vallières

ii

Table des matières

Table des matières ...................................................................................................................ii

Introduction.............................................................................................................................1

Objectifs..................................................................................................................................2

Addenda ..................................................................................................................................3

Méthodologie ..........................................................................................................................4

Conception de la base de données (MCD)................................................................................5

Conception générale du système d’information (DFD).............................................................7

Conception de l’interface humain-machine ............................................................................30

Conception des cas de test .....................................................................................................39

Conclusion ............................................................................................................................42


1

Introduction

L’Administration Portuaire de Québec (APQ) nous a octroyé un mandat d’analyse et d’amélioration du processus de gestion des séjours des navires par la transformation du système d’information qui supporte actuellement ce processus. Pour ce faire, notre équipe suivra une méthodologie en cascade afin de bien comprendre la situation actuelle, d’identifier les problèmes majeurs du système en place et de concevoir un nouveau système adapté aux besoins réels de notre client. En effet, bien que les systèmes d’information aient radicalement changé la façon d’opérer des entreprises vers la productivité post-moderne que nous connaissons tous, il n’en reste pas moins qu’un système mal conçu fera plus de tord que de bien à une organisation, peut importe son domaine d’activité. C’est pourquoi il est essentiel de respecter un protocole d’analyse et de conception bien défini qui garantira un résultat approprié. Nous avons effectué en premier lieu une étude préliminaire pour déterminer la faisabilité du projet en tenant compte du contexte, des différentes contraintes qui lui sont associées et des besoins réels de l’APQ. En connaissant les processus existants ainsi que leurs lacunes, nous sommes en mesure de proposer une solution sous la forme d’un processus d’affaire amélioré qui rendra la gestion des escales plus efficace. Il ne restera plus qu’à concevoir un nouveau système d’information implémentant ce nouveau processus d’affaire grâce à une approche de type « top-down » décrite en détail à la section Conception du nouveau SI du premier rapport. Bien entendu, un tel système doit être testé avant de pouvoir être livré. C’est pourquoi nous terminerons ce rapport par l’analyse et la validation de l’une des transformations critiques du nouveau système d’information.


2

Objectifs

1. Automatisation du procédé d’enregistrement et de gestion du séjour des navires.

2. Réduire au maximum, si possible éliminé, les changes sous forme de télécopie Télex avec

les agents de consignation.

3. Obtenir en temps réel le Lloyds Register grâce au service Internet « Internet Ships Register » et ainsi ne plus souffrir du délai de 3 mois engendré par l’attente du CD-ROM.

4. Migrer les fiches d’escale vers un support informatique.

5. Respecter la contrainte budgétaire de 3 millions de dollars et l’échéancier de 4 mois pour l’analyse, la conception et l’implantation du nouveau système.


3

Addenda

Dans le but de répondre aux besoins du client, il est nécessaire d’étirer la frontière du projet. Nous ajouterons :

• Le flux de sorti refus du système d’information vers l’agent de consignation • L’annonce d’arrivée du bateau vers le système d’information.


4

Méthodologie

Pour la conception générale du système d’information nous avons suivi les étapes suivantes :

1. Conception de la base de données 2. Conception des flux entrants 3. Conception des flux sortants 4. Transformation de sorties et de mise à jour

Cette approche diffère légèrement de la méthode proposée durant le cours. En effet, bien que la base de données fut conçue en premier, tel que décrit dans la méthodologie enseignée, nous avons choisi de concevoir les flux entrants et sortants avant les transformations, ce qui en fait un approche plutôt de type « top-down ». Cette façon de faire a le mérite de parfaitement bien définir les traitements en termes des entrées qui leur seront disponibles et des sorties qu’ils devront fournir. Il n’est pas nécessaire, contrairement à ce que le bon sens pourrait suggérer, de complètement définir les traitements avant de pouvoir énumérer une liste relativement complète d’entrées et de sorties qui seront requises. En effet, la description du problème est généralement suffisante pour extrapoler un certain nombre d’informations critiques au système. De plus, il peut s’avérer que la capture de ces entrées ou que l’affichage de ces sorties engendrent la création de traitements additionnels, ce qui rend la définition des IOs avant la celle des traitements avantageux. C’est donc à dire que la méthodologie que nous avons employée est également plus cyclique que celle proposée. Ainsi, nous avons du, de par la nature même de cette méthodologie, revenir en arrière afin d’ajouter de nouveaux éléments à une étape déjà complétée. Par exemple, la définition de certaines fonctions d’entrées a requis des changements à la structure des bases de données. Par contre, il ne faut pas voir ces révisions comme de l’inefficacité, mais bien comme un processus itératif améliorant le design du système en entier. En fait, les méthodologies itératives sont beaucoup mieux adaptées aux technologies de l’information que toute autre type de méthode de développement de projet en ingénierie de part la nature même du logiciel et du cycle de programmation typique (codage, compilation, liaison, débuggage).


5

Conception de la base de données (MCD)

Avant de commencer la base de données pour le SI, il est important de figer les entités de

données. Une entité est un regroupement d’information concret ou abstrait qui deviendra, si nécessaire, une table de notre base de données. Une fois les tables établies, elles doivent être reliées entre elles. La principale difficulté de cette tâche consiste à lier les bonnes entités et d’assigner la bonne cardinalité à leurs relations.

Les outils proposés pour la modélisation de la base de données sont le modèle conceptuel

de données ainsi que le modèle logique de données qui sera presque l’emprunte de la future base de données. Ces diagrammes offrent comme avantages majeurs de garder la définition des données indépendante des langages de bases de données du moment et d’éviter la redondance dans les données.

Le MDC révèle que les pilote, dockers ainsi que tous les autres employés du port ont des

données en communs. De plus, il est évident que la table d’escale sera le point névralgique de notre futur BD puisqu’elle est au centre de toutes les relations.

Figure 9 : Modèle logique de données


6 Le MLD est un modèle plus formel et plus prêt d’une base de données. Lors de l’implantation du SI, c’est cet organigramme que voudra voir le programmeur. Il est intéressant de noter la particularité des dockers et des pilotes qui partagent des caractéristiques communes avec les employés du port. Bien que nous n’avons pas employé directement des méthodes orientés objets dans cette étude, certains concepts, ici le polymorphisme et l’héritage, nous permettaient de réduire la redondance de nos données. Il est relativement aisé d’implémenter une telle structure dans une base de données à l’aide de champs « type d’objet » par exemple.

Figure 10 : Modèle logique de données


7

Conception générale du système d’information (DFD)

Pour bien comprendre comment l’information circulera dans le SI du port de Québec, il

est capital de formaliser les échanges d’information par l’entremise d’un DFD (Diagramme de Flux de données).

Un DFD se divise par niveau. Le diagramme de contexte, permet d’observer la procédure de haut niveau, c'est-à-dire avec le maximum d’abstraction des détails. Par la suite, chaque procédure sera découpée en sous-procédure jusqu’a l’obtention de tâches prêtes à être informatisées.

Comme écrit dans la section sur la méthodologie, nous préconisons l’approche « top-

down », c'est-à-dire de commencer par les sphères plus large du système puis d’approfondir chaque procédure dans un niveau plus bas. Certains analystes préfèrent faire une esquisse du premier niveau pour y greffer par la suite des corrections au fur et à mesure de la conception. Selon nous, le contexte du DFD est la fondation de notre SI, et comme nous souhaitons avoir une conception solide, il est capital d’établir nos bases avant de commencer.

Le premier DFD est la gestion de demande d’escale par l’agent de consignation. Il indique l’information requise par l’agent pour faire une demande d’escale. Selon les paramètres envoyés par l’agent, le système lui retourne la réservation qu’il désire ou une erreur si l’institut a émis une interdiction pour le navire ou si l’agent n’est pas intéressé par les offres présentées par le système.

Gestion de la demande d’escale par l’agent de consignation

Figure 11 : Diagramme de contexte de la demande d’escale par l’agent de consignation


8

Le premier niveau élabore les étapes par lesquels devra passer l’agent de consignation pour la demande d’escale.

Figure 12 : Niveau 1 de la demande d’escale par l’agent de consignation


9La première partie du deuxième niveau explicite le processus de validation de l’identité

de l’agent de consignation ainsi que la validation de l’identité du navire lors de la demande d’escale. Vous trouverez la validation du fret du navire ainsi que la procédure de réservation d’escale dans la suite du niveau 2 à la page suivante.

Figure 13 : Niveau 2 de la demande d’escale par l’agent de consignation


10

Figure 14 : Suite du niveau 2 de la demande d’escale par l’agent de consignation


11Gestion d’annulation par l’agent de consignation

Le deuxième DFD schématise la gestion d’annulation d’escales. Comme il arrivera très

probablement des imprévus, il faut palier à ces derniers grâce à une procédure d’annulation d’escales. Le diagramme de contexte illustre les informations que l’agent de consignation devra fournir ainsi que celles que le système d’information lui retournera.

Figure 15 : Diagramme de contexte de la gestion de demande d’annulation par l’agent de consignation


12Le premier niveau de la demande d’annulation démontre les principales étapes par lesquelles devra passer l’agent de consignation pour obtenir l’annulation.

Figure 16 : Diagramme de niveau 1 de la gestion de demande d’annulation par l’agent de consignation


13

Le deuxième niveau révèle les détails des procédures qui seront exécuté pour annuler l’escale.

Figure 17 : Diagramme de niveau 2 de la gestion de demande d’annulation par l’agent de consignation


14Gestion de la demande de création d’escale par un employé du port

Certain agents de consignation ne voudrons probablement pas utiliser le nouveau système

d’information. C’est pour cela et pour gérer d’autre cas d’exception non prévus qu’il est crucial que les employés du port puissent créer des demandes d’escale.

Figure 18 : Diagramme de contexte de la gestion de demande de création d’escale par un employé du port


15Le niveau 1 de création de demande d’escale par un employé ressemble énormément à la procédure pour un agent de consignation à l’exception qu’il a plus de marge de manœuvre.

Figure 19 : Diagramme de niveau 1 de la gestion de demande de création d’escale par un employé du port


16 Le niveau 2 de création de demande d’escale par un employé valide l’identité de l’agent ainsi que l’identité du navire. La suite du niveau 2 présente le processus de présentation des postes d’accostages valides ainsi que la confirmation.

Figure 20 : Diagramme de niveau 2 de la gestion de demande de création d’escale par un employé du port


17

Figure 21 : Suite du niveau 2 de la gestion de demande de création d’escale par un employé du port


18Gestion de la demande d’annulation par un employé du port Pour permettre au système d’information d’être souple, il faut permettre aux employés du port d’annuler une réservation. Les trois prochains diagrammes montrent la procédure à suivre.

Figure 22 : Diagramme de contexte de gestion de la demande d’annulation par un employé du port

Figure 23 : Diagramme de niveau 1 de gestion de la demande d’annulation par un employé du port


19

Figure 24 : Diagramme de niveau 2 de gestion de la demande d’annulation par un employé du port


20

Expiration des escales Ce diagramme sort plutôt hors de l’ordinaire. En effet, il n’a aucune entrée parce que cette procédure est événementielle. Elle est déclanchée chaque matin pour vérifier qu’il n’y a aucune escale périmée dans la base de données.

Figure 25 : Diagramme de contexte de l’expiration des escales

Figure 26 : Diagramme de niveau 1 de l’expiration des escales


21Arrivée d’un navire Cette procédure est très importante puisqu’elle découle directement de la demande du client. Elle permet d’informatiser la fiche d’escale saisie par la commandant du port.

Figure 27 : Diagramme de contexte de l’arrivée d’un navire

Figure 28 : Diagramme de niveau 1 de l’arrivée d’un navire


22

Figure 29 : Diagramme de niveau 2 de l’arrivée d’un navire


23

Figure 30 : Suite du niveau 2 de l’arrivée d’un navire


24Avis de libération La procédure de libération est déclanché lors que le commandant du port constate que le navire est accosté. On peut donc libérer le pilote et l’éventuelle remorque pour qu’ils puissent être disponibles pour d’autres escales.

Figure 31 : Diagramme de contexte d’avis de libération

Figure 32 : Diagramme de niveau 1 d’avis de libération


25Fin du chargement / déchargement La fin du chargement et la fin du déchargement sont en fait 2 procédures identiques. Elles visent à libérer l’éventuel docker après la fin de son travail pour qu’il puisse être disponible pour une autre escale.

Figure 33 : Diagramme de contexte de fin du chargement / déchargement

Figure 34 : Diagramme de niveau 1 de fin du chargement / déchargement


26 Départ d’un navire Lors du départ du navire, le commandant doit conclure la saisie de la fiche d’escale.

Figure 35 : Diagramme de contexte de départ d’un navire

Figure 36 : Diagramme de niveau 1 de départ d’un navire


27

Figure 37 : Diagramme de niveau 2 de départ d’un navire


28Réception d’une interdiction Lorsqu’une interdiction est reçue, le commandant utilise le logiciel de gestion du port pour effectuer le processus suivant qui enregistrera l’interdiction et fera la vérification de toutes les escales non complétées afin de déterminer celles qui doivent être annulées.

Figure 38 : Diagramme de contexte pour la réception d’une interdiction

Figure 39 : Diagramme de niveau 1 pour la réception d’une interdiction


29

Figure 40 : Diagramme de niveau 2 pour la réception d’une interdiction


30

Conception de l’interface humain-machine

Plutôt que de se limiter à la seule interface de la fiche d’escale d’un navire, qui en soit n’en n’est pas une mais est plutôt un document généré par le système d’information, nous avons décider de concevoir l’interface humaine du système en entier proprement dite. L’architecture que nous avons choisie repose sur deux interfaces distinctes, l’une pour les agents consignataires, l’autre pour les employés du port. Pour la première, il a été jugé préférable de concevoir une interface web. En effet, les agents consignataires devraient pouvoir accéder au nouveau système le plus rapidement possible, sans mentionner le fait qu’il ne serait pas éthiquement correct de les forcer à installer quelque logiciel que ce soit pour une plateforme donnée. De plus, une interface web offre un accès global, peu importe l’emplacement géographique d’un agent de consignation. Par contre, dans le cas de l’interface pour les employés du port, il était plus intéressant de concevoir un logiciel proprement dit. En effet, bien qu’une interface web offre certains avantages d’accessibilité et d’indépendance, un logiciel offre une bien meilleure expérience d’utilisation, que ce soit par un feedback plus instantané ou des services interactifs de recherche et d’aide en ligne intelligente. Sans plus attendre, voici l’interface web pour les agents de consignation.

Figure 41 : Interface de connexion


31 La page d’authentification est relativement simple. Elle demande simplement à un agent d’entrer son nom d’utilisateur et son mot de passe. Le nom d’utilisateur correspond au numéro d’agent dans la base de données, et le mot de passe est hashé puis comparé au hash contenu dans la base de données. Il est à noter que le début de plusieurs DFD, dont ceux de réservation et d’annulation d’escale par un agent de consignation, correspondent à cette interface. Une fois authentifié, un agent de consignation peut effectuer certaines opérations. La capture d’écran, par exemple, montre le cas d’un agent pouvant réserver de nouvelles escales dans pouvoir en annuler aucune.

Figure 42 : Menu principal de l’interface web


32 L’interface d’annulation d’escale étant relativement simple (demande du numéro d’escale à annuler, puis confirmation ou message d’erreur), nous avons décider de ne montrer que l’interface de réservation d’escale. Celle-ci commence par le formulaire de recherche d’offres.

Figure 43 : Interface de recherche d’offres d’escale


33 Dans le cas où le système peut générer au moins une offre répondant aux critères fournis par l’agent, la page de sélection d’offre est affichée.

Figure 44 : Interface de sélection d’offres d’escale

Il suffit à l’agent de cliquer sur la ligne de l’offre qu’il désire pour premièrement confirmer son choix, puis terminer le processus de réservation.

Figure 45 : Message de confirmation


34 Si l’offre choisie est toujours valide, alors l’agent recevra une confirmation finale de sa réservation, incluant le numéro d’escale correspondant. Il est à noter que le numéro d’escale est tout simplement l’index de l’escale en question dans la table d’escales, affiché en hexadécimal. La capture d’écran assume un index de 64 bits, mais la méthode est applicable à toutes les tailles d’index.

Figure 46 : Interface de confirmation de réservation


35

Dans le cas d’une erreur, une page sera générée dynamiquement afin d’informer l’agent des détails de cette erreur.

Figure 47 : Interface de confirmation de réservation

En résumer, l’interface web interagit principalement avec les tables reliées aux escales et bien sûr aux agents de consignation. Comme il a été indiqué précédemment, les DFD de réservation et d’annulation d’escales décrivent les processus requis par cette interface. Il est également important de rappeler que l’accès sera sécurisé avec HTTPS et qu’aucune technologie propriétaire ne sera utilisée. Interface pour les employés du port Cette interface a pour but de servir les employés du port, en particulier le commandant. La décision de réaliser cette dernière par un logiciel conventionnel se justifie par le désir d’offrir la meilleure expérience d’utilisation possible pour des gens qui normalement n’ont aucune base en informatique. Il est également important d’indiquer que les employés du port n’auront fort probablement jamais à accéder au système en dehors des frontières physiques du port, ce qui rend une interface web nettement moins intéressante.


36 Également, nous avons décidé de laisser l’authentification des employés au système d’exploitation des machines qui soutiendront le logiciel de gestion du port. En effet, le port a sans doute déjà une politique d’accès bien établie et il serait idiot d’en construire une par-dessus. De plus, pour faire une histoire courte, l’interface interne de gestion du port touche à toute la base de données et s’appuie sur la majorité des processus modélisés par les DFD. Il est cependant important de mentionner que la création d’escale par les employés du port se fera par l’interface web et que l’agent de consignation ne désirant pas utiliser l’interface web devra contacter directement le port pour faire ses réservations. Nous pensons que cette contrainte sera à long terme bénéfique puisqu’elle incitera les agents à migrer vers le nouveau système. Bien entendu, les processus impliquant un agent consignataire en tant qu’utilisateur humain sont gérés par l’interface web. Enfin, pour faire un lien avec la demande de cette étude, la fiche d’escale d’un navire n’est qu’un document généré par l’interface de gestion du port, qui peut alors être imprimé autant de fois que nécessaire. Elle contient toutes les informations pertinentes à propos d’une escale, tel que le numéro d’escale, la date d’arrivée prévue et effective, l’agent de consignation, le numéro de Lloyds du navire, le nom du quai, le poste d’accostage, la durée prévue de l’escale et la prochaine destination du navire. Finalement, avant de présenter l’interface interne de gestion du port, il serait intéressant de discuter rapidement de certains concepts d’interfaces humain-machine qui supportent cette dernière. Premièrement, toutes les fonctionnalités de premier niveau sont disponibles de plusieurs façons, que ce soit par la fenêtre de gestion globale ou par les menus. De plus, ces menus possèdent tous un raccourci clavier. Également, toute les fenêtres contiennent un bouton d’aide ou un notice indiquant comment obtenir de l’aide. Ces éléments sont cruciaux pour l’accessibilité de l’interface, qui comme il a déjà été mentionné est d’une importance capitale pour le type d’usager qui sera servi par le système. Sans plus tarder, voici le menu principal du logiciel.

Figure 48 : Menu principal

Ensuite, la fenêtre principale du logiciel. Pour ceux ne connaissant pas les normes de l’interface Aqua de Mac OS X, ce type de fenêtre reste toujours au premier plan, ce qui garantie son accessibilité en tout temps à l’intérieur du logiciel. La fenêtre fondamentalement offre un bouton pour chacun des processus modélisés par les DFD.


37

Figure 49 : Fenêtre principal

L’enregistrement d’une interdiction se fait simplement à l’aide d’une boîte de dialogue.

Figure 50 : Enregistrement d’une interdiction


38Dans tous les cas où une escale doit être choisi, une fenêtre de sélection d’escale est personnalisée pour le processus concerné puis affichée à l’utilisateur. Il y aura donc une grande standardisation au niveau de l’interface, ce qui diminue énormément le temps de formation.

Figure 51 : Recherche et sélection d’escale

Finalement, lorsque des ressources du port doivent être assignées à un processus, comme à l’arrivée d’un navire, la fenêtre suivante est correctement paramétrée puis instanciée pour permettre à l’utilisateur d’allouer les ressources requises.

Figure 52 : Affectation des ressources


39

Conception des cas de test

Pour s’assurer de la qualité du système d’information les tests sont incontournables. Pour démontrer la méthode qui sera utilisé nous avons fais un exemple pour la procédure valider fret du diagramme de flux de données au niveau 2 de la demande d’escale par l’agent de consignation (voir figure 14).

Les premiers tests seront les tests en boîte blanche. Un test en boîte blanche est un test qui vérifie l’intérieur des procédures. Le but de ce test est de vérifier que la réalisation de la procédure est conforme à sa spécification. Par la suite nous pourrons effectuer un test en boîte noir qui consiste à envoyer une entré à la procédure et valider sa sorti. Exemple, sortir tout les postes d’accostage qui peuvent recevoir un fret de céréales pour un navire dont le tirant d’eau est d’au moins de 6 mètres. Voici un exemple d’algorithme à tester : ListePoste trouverAcceptables(Integer typeFret, Integer tirant)

{

// Initialise une liste de postes vides

1. ListePoste posteAcceptables <- initListePostes();

// Obtient tous les postes d'accostages à partir de la BD

2. ListePoste lesPostes <- obtenirLesPostes();

3. Integer nbPostes <- obtenirNbPostes();

4. Integer i <- 0;

5. while(i < nbPostes)

{

6. ListeInteger fretsAcceptables <-

obtenirLesFretsAcceptables(obtenirElement(lesPostes, i));

7. Integer nbFrets <-

obtenirNbFretsAcceptables(obtenirElement(lesPostes, i));

8. Boolean trouver <- false;

9. Integer j <- 0

10. while(j < nbFrets)

{

11. if(typeFret = obtenirElement(fretsAcceptables, j))

12. trouver <- true;

13. j++;

}

14,15. if(trouver && tirant <=

obtenirTiranMaximal(obtenirElement(lesPostes, i)))

16. ajouterElement(posteAcceptables, obtenirElement(lesPostes,

i));

17. i++;

}

18. return posteAcceptables;

}


40Le digramme de flot de contrôle permet d’avoir une vue d’ensembles de tous les chemins que peuvent prendre l’algorithme. Un tel diagramme permettra de s’assurer que toutes les boucles seront exécutées au moins une fois.

Figure 53 : Flot de contrôles


41Cas de test pour le chemin 1 : typeFret = x (n’importe quelle valeur) tirant = y (n’importe quelle valeur)

Base de données : ne contient aucun poste d'accostage. Sortie : liste de postes vide.

Cas de test pour le chemin 2 : typeFret = x (n’importe quelle valeur) tirant = y (n’importe quelle valeur)

Base de données : contient un seul poste d'accostage n’acceptant aucun type de fret. Sortie : liste de postes vide.

Cas de test pour le chemin 5 : typeFret = 1 tirant = y (n’importe quelle valeur)

Base de données : contient un seul poste d'accostage n’accepte qu’un seul type de fret, différent de 1. Sortie : liste de postes vide.

Cas de test pour le chemin 7 : typeFret = 1 tirant = 5

Base de données : contient un seul poste d'accostage n’accepte qu’un seul type de fret, égal à 1 et un tirant d’eau maximum inférieur à 5. Sortie : liste de postes vide.

Cas de test pour le chemin 8 : typeFret = 1 tirant = 5

Base de données : contient un seul poste d'accostage n’accepte qu’un seul type de fret, égal à 1 et un tirant d’eau maximum supérieur à 5. Sortie : liste contenant le poste d’accostage présent dans la base de données.

*Les chemins 3, 4 et 6 ne peuvent être parcourues, quelque soient les valeurs de test.


42

Conclusion Après réévaluation du projet, nous somme dans la certitude que l’étirement de la frontière n’empêchera pas le projet de terminer dans les délais. Cependant au fur et à mesure de l’étape de la conception du projet, nous avons observé certaines fonctionnalités qui pourraient être des plus utiles pour les utilisateurs du système. Bien sûr l’actuel système devra être conçu de façon à ce que ces fonctionnalités soient aisément implantées dans le futur, si ces dernières plaisent au client. La première fonctionnalité serait de pouvoir modifier une escale. Dans le présent système, si l’agent de consignation se trompe lors de la saisie de la date d’arrivée et souhaite corriger cette erreur, il devra annuler sa réservation puis en créer une nouvelle, ce qui est peu commode. La deuxième fonctionnalité est conditionnelle aux employés du port. Si ils adoptent le présent système d’information, il serait optimal qu’ils régissent eux même leurs libérations au lieu de prendre le commandant comme intermédiaire. La troisième fonctionnalité est pour éviter de la saisie inutile. Lors de l’arrivée de nouvelle interdiction de séjours par courriel par la direction maritime, le système devrait automatiquement entamer la procédure d’interdiction de séjours. Cela éliminerai des erreurs possible et permettrai de sauver du temps. La dernière fonctionnalité proposé est l’annulation d’une l’interdiction de séjour. Puisque si une interdiction erronée est entrée dans le système actuel, l’utilisateur devra contacter un technicien pour qu’il efface l’interdiction directement dans la base de données.

Les objectifs devant être respecté, particulièrement ceux de temps et d’argent, il est fortement conseillé de reporter ces fonctionnalités dans une version ultérieure.

rapport 2 pour analyse de conception de systèmes … · rapport ii Étude de cas : port de québec...

Documents