Conception d'un système d'information pour la gestion des activités académiques. Cas de l'institut supérieur de commerce de Kinshasa.

Année Académique 2013-2014

i

REPUBLIQUE DEMOCRATIQUE DU CONGO

MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET
UNIVERSITAIRE

INSTITUT SUPERIEUR DE COMMERCE

Section Licence

Département Informatique de Gestion

BP : 16596

KINSHASA-GOMBE

CONCEPTION D'UN SYSTEME D'INFORMATION POUR

GESTION DES ACTIVITES ACADEMIQUES

(CAS DE L'INSTITUT SUPERIEUR DE COMMERCE DE KINSHASA)

?

LEPEYA OTOKO Herve

Mémoire de fin d'études présenté et défendu en vue de l'obtention du titre de Licencié en Informatique de Gestion

Option : Conception des Systèmes d'information Promoteur : P.O. J. A. MVIBUDULU KALIYUT. Rapporteur : MUKENGE MBUMBA Josich

ii

IN MEMORIAM

A notre défunte maman Henriette LEPEYA Bemanga, pour l'éducation reçue, pour tous les sacrifices endurés, pour tous les efforts déployés le jour au jour, pour l'amour sans mesure témoigné ; que la terre de nos ancêtres lui soit douce.

iii

Epigraphe

« Le savoir scientifique n'est ni de type sapiential, ni de type contemplatif, ni de type herméneutique, mais de type opératoire »

Jean LADRIERE

iv

REMERCIEMENTS

A l'éternel Dieu Tout Puissant, pour toutes les merveilles accomplies dans notre vie tout au long de notre formation intellectuelle, humaine et spirituelle, reviennent nos premiers remerciements.

A nos frères et soeurs : Julienne NYEMBO, Popaul LEPEYA, Legrand LEPEYA, Devos LEPEYA, Kally LEPEYA, Nadine LEPEYA, Jean de Dieu LEPEYA et Esther LEPEYA pour leurs soutiens incontestables à notre égard. ;

A nos belles soeurs et beaux-frères : Gaston NTOYA, Getride KINKELA, Irène MBO, Lucie CLAIR, etc. ;

A tous nos cousines et cousins ;

A nos nièces et neveux: Nelly ABWASAMBWA, Serge WANDJA, Chris LEPEYA, Glorianne LEPEYA, Louisette LEPEYA, Priscille, Jevim LEPEYA, Noëline LOLIMBA, Vainqueur LEPEYA, Glody LEPEYA, Divine LEPEYA, Arnold LEPEYA, Nadège LEPEYA, Nicianne LEPEYA, Chadrack LEPEYA, Giguyna, etc. ;

A nos ami (es) et connaissances : Arnold MBAMA, Seraphine IMONA, Rodrigue LONGOLAMAYI, Rody LIFU, Guelord LUSEKE, Gladys KITETE, Rodrigue MERBA, Patrick NGALAMULUME, Djonny NGWIZANI, Fleury NGOMA, Jacob MASAMBA, Josué BUABIBI, KOFFI, PITHOS MBAA, Franklin TSHIBANGU, Christian KIAKU, Jean de Dieu KAPENDA, Germaine MVUAMVUA, KALOMBO Denis, Maman Ruth MANSONI, Henriette DIANSANA, Cynthia SUMBELA, Francis KATAMBAY et à la promotion L2 Informatique ;

A Notre très chère aimable Christelle KIBANYA ;

A toutes et tous, nous vous remercions pour votre soutient.

Herve LEPEYA OTOKO

v

Résumé

Le présent travail intitulé « Conception d'un Système d'Information pour la Gestion en Ligne des activités académiques » cas de l'Institut Supérieur de Commerce de Kinshasa. Un sujet, né à partir d'un constat fait sur la manière de gérer et d'administrer les activités académiques plus précisément dans le processus des délibérations des étudiants et des délivrances des relevés des côtes à l'aide de l'automatisation.

De ce constat, reste née l'hypothèse selon laquelle si les autorités académiques pourraient mettre en place ce système, cela leur permettra une gestion optimale des activités académiques, et leur offrira des avantages énormes en produisant à un temps record les différents documents tels que : Les Grilles de délibérations, les PV des délibérations, les relevés des côtes et ce, grâce à une application web et une base de données structurée, non redondante et exhaustive.

La conduite de notre recherche s'est appuyée sur des méthodes et des techniques de la recherche scientifique, à savoir : Structuro-fonctionnelle, Historique, Observation, Interview et analyse documentaire ; Par ailleurs, nous avons eu à investiguer le système existant grâce à la méthode Merise. Et Par la suite, la conception du nouveau système a été rendue possible par l'application des notations UML dans le processus Two Track Unified Process du processus unifié. La mise en oeuvre et le développement du nouveau système se sont appuyés sur l'architecture trois tiers et les langages de programmation tels : Php, Javascript, etc.

La brèche que nous avons ouverte partant de l'angle choisi dans ce sujet reste ouvert à tous ceux qui veulent continuer ce champ pour la promotion de la science et de parfaire là où nous avons failli et restructurer là où nous n'avons pas approfondi.

vi

Abstract

This work entitled "Design of an Information system for the Line control of the academic activities" case of the Higher Institute of Trade of Kinshasa. A subject, born starting from a report made on the manner more precisely of managing and of managing the academic activities in the process of the deliberations of the students and the deliveries of the statements of the coasts using automation.

This report, remains born the assumption according to which if the academic authorities could set up this system, that will allow them an optimal management of the academic activities, and will offer enormous advantages to them by producing at a time record the various documents such as:Grids of deliberations, the statement of the deliberations, statements of the coasts and this, thanks to an application Web and a data base structured, no redundant and exhaustive.

The control of our research was based on methods and techniques of scientific research, namely:Structuro-functional, History, Observation, Interview and abstract;In addition, we had with investiguer the existing system thanks to the Merise method.And Thereafter, the design of the new system was made possible by the application of notations UML in the process Two Track Unified Process of the unified process.The implementation and the development of the new system were based on architecture three thirds and the programming languages such:Php, Javascript, etc.

The breach that we opened on the basis of the angle chosen in this subject remains open to all those who want to continue this field for the promotion of science and to perfect where we failed and to restructure where we did not deepen.

vii

SIGLES ET ABREVIATIONS

2TUP : Two Track Unified Process

Acad. : Académique

BDD : Base de données

DE : Délibération des étudiants

Dos : Dossier

EEPF : Enregistrer des Etudiant ayant Payés le Frais

ELEE : Envoyer la Liste des Enrôlés aux Enseignants

Enr : Enrôlé

ISC : Institut Supérieur de Commerce

MAI : Méthode Analyse Informatique

MC : Modèle Conceptuel

MFC : Modèle de Flux Conceptuel

ML : Marge Libre

MPM : Méthode Potentiel de Métra

MT : Marge Totale

ORC : Obtention Relevé des côtes

PGM : Programme

PV : Procès-Verbal

RFC : Remettre la Fiche des côtes

SGA : Secrétariat Général Académique

SGBD : Système de Gestion de Base de Données

UML : Unified Modeling Language

UP : Unified Process

viii

LISTE DES FIGURES

Figure 1.1.1 : Graphe partagé à niveaux 8

Figure 1.1.2 : Graphique potentiel 10

Figure 1.2.1 : Organisation du système dans une entreprise 13

Figure 1.2.2 : Architecture fonctionnelle typique d'un SGBD 17

Figure 1.2.3. : Schéma historique d'UML 20

Figure 1.2.4.: Processus de développement en Y 24

Figure 1.2.5. : Schéma d'un héritage simple 26

Figure 1.2.6. : Schéma d'un héritage multiple 27

Figure 1.2.7. : Exemple d'un polymorphisme. 27

Figure 2.1.1. : Organigramme général de l'Institut Supérieur de Commerce de Kinshasa 36

Figure 2.2.1 : Modèle d'une fiche des côtes 45

Figure 2.2.2. : Modèle d'un relevé des côtes 46

Figure 2.2.3.: Modèle d'un reçu de frais 47

Figure 2.2.4.: Modèle d'une grille de délibération 47

Figure 2.2.5.: Modèle d'un PV de délibération 48

Figure 2.2.6. : Représentation d'un domaine d'étude 51

Figure 2.2.7.: Représentation d'un acteur externe 52

Figure 2.2.8.: Représentation d'un domaine connexe 52

Figure 3.1.1.: Présentation du digramme de contexte dynamique 69

Figure 3.1.2.: Symboles utilisés 69

Figure 3.1.3.: Présentions du diagramme de contexte statique 70

Figure 3.2.1.: Présentation du diagramme de cas d'utilisation 72

Figure 3.2.3.: Diagramme d'activité Envoyer les listes 84

Figure 3.2.4.: Diagramme d'activité Remettre les fiches 85

Figure 3.2.6.: Diagramme d'activité Obtention relevé 87

Figure 3.2.7.: Diagramme d'activité Gestion profil d'usagers 88

Figure 3.2.8.: Package de spécification fonctionnelle 89

Figure 3.2.9.: Diagramme de classe affiné Délibération des étudiants 95

Figure 3.2.10.: Diagramme de classe affiné Gestion relevés des côtes 95

Figure 3.2.11.: Diagramme de classe affiné Gestion des profils d'usagers 96

Figure 3.3.2.: Présentation du Style de déploiement 98

Figure 3.3.3.: Présentation des cas d'utilisation techniques 99

Figure 3.3.4.: Présentation des couches logicielles 100

Figure 3.4.1.: Présentation de classe optimisée Enregistrer les étudiants ayant ... 105

ix

Figure 3.4.2.: Présentation de classe optimisée Envoyer les listes 106

Figure 3.4.3.: Présentation de classe optimisée Remettre la fiche 107

Figure 3.4.4.: Présentation de classe optimisée Délibération ... 107

Figure 3.4.5.: Présentation de classe optimisée Obtention relevé 107

Figure 3.4.6.: Présentation de classe optimisée Gestion profil ... 108

Figure 3.4.7.: Présentation de diagramme d'état Enregistrer les étudiants 111

Figure 3.4.8.: Présentation de diagramme d'état Envoyer les fiches ... 111

Figure 3.4.9.: Présentation de diagramme d'état Remettre la fiche 112

Figure 3.4.10.: Présentation de diagramme d'état Délibération des étudiants 112

Figure 3.4.11.: Présentation de diagramme d'état Obtention relevé 113

Figure 3.4.12.: Présentation de diagramme d'état Gestion des profils 113

Figure 3.4.13.: Présentation de diagramme séquence Enregistrer les étudiants 114

Figure 3.4.14.: Présentation de diagramme séquence Envoyer les listes 114

Figure 3.4.15.: Présentation de diagramme séquence Remettre la fiche 115

Figure 3.4.16.: Présentation de diagramme séquence Délibération des étudiants 115

Figure 3.4.17.: Présentation de diagramme séquence Obtention relevé des côtes 116

Figure 3.4.18.: Présentation de diagramme séquence Gestion des profils 116

Figure 3.5.1.: Présentation de Framework design patterns mécanisme 118

Figure 3.5.3.: Présentation du modèle de configuration logicielle 121

Figure 3.6.1.: Présentation du déploiement 123

Figure 3.6.2.: Modèle d'exploitation délibération des étudiants 124

Figure 3.6.3.: Modèle d'exploitation Gestion relevé des côtes 125

Figure 3.6.4.: Modèle d'exploitation Gestion profils d'usagers 125

Figure 3.6.5.: Applications dans le modèle d'exploitation 126

Figure 3.6.6.: Les composants métiers du système 127

Figure 3.6.7.: Schéma de dépendance entre composants métiers du modèle d'exploitation 128

Figure 3.6.7.: Schéma de dépendance entre composants métier du modèle d'exploitation 128

Figure 3.7.1.: Modèle logique de la conception détaillée 135

Figure 3.7.2.: Configuration logicielle Profils d'usager 136

Figure 3.7.3.: Configuration logicielle Enregistrer Etudiant 137

Figure 3.7.4.: Configuration logicielle Envoyer Liste 138

Figure 3.7.5.: Configuration logicielle Remettre Fiche 139

Figure 3.7.6.: Configuration logicielle Délibération 140

Figure 3.7.7.: Configuration logicielle Obtention Relevé 141

X

LISTE DES TABLEAUX

Tableau 1.1.1 : Identification des tâches et délais 7

Tableau 1.1.2 : Détermination des dates au plus tôt 9

Tableau 1.1.3 : Détermination des dates au plus tard 9

Tableau 2.2.1 : Description du poste étudiant 41

Tableau 2.2.2 : Description du poste Secrétariat Général Académique 41

Tableau 2.2.3. : Description du poste Président du jury 42

Tableau 2.2.4. : Description du poste Secrétaire du jury 42

Tableau 2.2.5 : Description du poste Membres du jury 42

Tableau 2.2.6 : Description du poste Encodeur 43

Tableau 2.2.7. : Description du poste Secrétariat de la section 43

Tableau 2.2.8 : Description du poste Chef de département 43

Tableau 2.2.9 : Description du poste chef de section 43

Tableau 2.2.10 : Description du poste banque 44

Tableau 2.2.11 : Description du poste Enseignant 44

Tableau 2.2.12 : Liste d'un échantillonnage des matériels recensés 49

Herve LEPEYA OTOKO

xi

Avant-propos

Toute oeuvre est le fruit des efforts consentis par une ou plusieurs personnes en vue d'obtenir un bien ou un service. Ainsi, au terme de ce présent mémoire qui marque la fin de notre deuxième cycle en informatique de gestion à l'Institut Supérieur de Commerce, ISC en sigle, nous rendons grâce à notre Dieu, qui nous a guidé et fortifié tout au long de notre parcours académique.

Le présent mémoire n'est autre que le résultat de la collaboration des professeurs et chefs de travaux qui ont pu, tout au long de notre parcours académique, nous baigner dans cette source qu'est l'école. Qu'ils trouvent ici l'expression de notre profonde gratitude pour toutes les connaissances qu'ils ont réussies à nous transmettre.

C'est à juste titre que nous tenons à remercier Monsieur le professeur MVIBUDULU KALIYUT Jacques Alphonse et Monsieur MUKENGE MBUMBA Josich qui, en dépit de leurs multiples occupations, ont bien voulu assurer la direction scientifique de ce mémoire et sans oublier monsieur Louis Denis KONKFIE IPEPE pour sa contribution scientifique.

Nous ne pouvons rester indifférent vis-à-vis de monsieur Paulin ITOKO, qui a accepté de faire la lecture formelle de cette oeuvre scientifique.

Que les autorités administratives, académiques de l'Institut Supérieur de Commerce trouvent, à travers ces lignes, l'expression de notre profonde gratitude pour le bagage intellectuel combien important qu'ils nous ont transmis.

Une attention particulière est accordée à nos compagnons des luttes : IYEMBO Rodrigue, Grace MALULU, KABANGU Frederick, MBAYI Beverly, BEYA Nelly, NGOMA Fleury, MASAMBA Jacob, etc.

Il nous sera difficile de citer tout le monde dans ce petit espace. Que tous trouvent ici l'expression de notre amitié et de notre reconnaissance.

1

INTRODUCTION

Dans l'ère actuelle, l'informatique est considérée comme un facteur efficace de gestion parce qu'elle se place au centre de résolution des multiples problèmes complexes de gestion d'entreprise, suite à son système de traitement automatique rapide et rationnel d'une masse d'informations par l'ordinateur en vue de produire des bons résultats répondant aux besoins des utilisateurs.

C'est dans ce cadre que nous voudrions circonscrire notre sujet en partant de la Gestion manuelle des activités académiques de l'Institut Supérieur de Commerce (I.S.C. en sigle) de Kinshasa à une Gestion automatique et ce, grâce à l'informatique qui est une science de traitement rationnel de l'information par des machines programmables appelées « Ordinateur ».

L'informatisation est à cet effet, un processus qui implique divers outils afin d'arriver à mettre en place un logiciel capable de répondre aux besoins des utilisateurs. Pour ce faire, l'analyste est obligé de mener des études préalables au terme desquelles sortira la décision si, oui ou non, il est opportun d'informatiser.

Compte tenu du fait que l'informatisation ne s'improvise pas, nous allons tout au long de ce travail, montrer la démarche à suivre pour passer d'une application manuelle à une application informatique.

2

1. Problématique

L'être humain étant étouffé dans son milieu professionnel par divers problèmes tels que la complexité des tâches qui lui reviennent de l'entreprise, la gestion de grandes masses d'informations, etc. il n'a plus de choix que de recourir à l'outil informatique capable de résoudre en un temps record, ainsi qu'au moindre coût, ses différents problèmes.

La gestion des activités académiques pose souvent d'énormes difficultés pour lesquelles, l'on ne trouve pas de solutions appropriées notamment : la lenteur dans le processus des délibérations plus précisément dans l'encodage des côtes et l'établissement des PV de délibération ainsi que l'obtention des différents documents académiques ; s'informer en temps réel des différentes annonces du campus, etc. Ces difficultés dont nous cherchons des solutions, peuvent être résolues à la suite de la question suivante :

L'Institut Supérieur de Commerce de Kinshasa, est-il capable de recourir à un système susceptible de gérer automatiquement les informations relatives aux activités académiques ? Si tel est le cas, comment y parvenir ?

Cette question oriente notre étude vers une éventuelle décision sur l'opportunité de l'informatisation du système existant.

2. Hypothèse

L'hypothèse étant une proposition des réponses provisoires que nous donnons à propos de l'objet de la recherche, il s'agit des réponses attendues à apporter à la question posée dans la problématique.

Nous répondons par oui, parce que le système à mettre en place permettra une gestion optimale des activités académiques, et offrira des avantages énormes en produisant à un temps record les différents documents tels que : Les Grilles de délibérations, les PV des délibérations, les relevés des côtes et ce, grâce à une application web et une base de données structurée, non redondante et exhaustive. A la lumière de ce qui précède, les bénéficiaires directs du système informatique envisagé sont : le Secrétariat Général Académique, les différentes sections, etc. de L'Institut Supérieur de Commerce de Kinshasa.

Ainsi, ce système informatique avec sa base de données offre une opportunité à l'Institut Supérieur de Commerce de Kinshasa de faire usage de la technologie de l'information et de la communication, et faciliterait la circulation rapide et sûre de l'information tout en permettant de prendre des décisions efficaces en temps voulu.

3

3. Choix et intérêt du Sujet

a. Choix

Le choix de notre sujet portant sur la « Conception d'un Système d'Information pour la Gestion en Ligne des Activités Académiques » se justifie par le souci profond qui nous préoccupe d'aider l'Institut Supérieur de Commerce de Kinshasa à faire bon usage de ses activités académiques en vue d'avoir désormais, une gestion contrôlable, saine et exacte grâce au logiciel que nous proposons par rapport aux difficultés auxquelles, elle est confrontée.

b. Intérêt

L'intérêt de ce sujet porte sur trois volets exprimés ci-dessous :

- Pour l'Institut Supérieur de Commerce de Kinshasa, ce système une fois implanté permettra et facilitera un contrôle rigoureux des activités académiques, une lecture et une consultation immédiate des opérations relatives aux activités académiques, etc. ;

- Pour nous étudiant, nous aurons palpé du doigt aux réalités professionnelles longtemps attendues ;

- Pour les chercheurs en ce domaine, cette ébauche leur servira de jalon dans leurs quêtes du monde scientifique.

4. Délimitation du sujet

Le sujet d'étude que nous avons choisi est basé essentiellement à l'informatisation des activités académiques plus précisément dans le processus de délibération des étudiants et de l'obtention de relevé des côtes, et cela pour la période allant de 2012 à 2013.

5. Méthodes et techniques utilisées

L'analyse d'une application exige des méthodes et des techniques de recherche adaptées aux différents cas afin de rendre intelligible la tâche qui devra être développée. Si la méthode est un chemin poursuivi pour atteindre un but, la technique en est un outil pour atteindre ce même but.¹

a. Méthodes

La méthode est l'ensemble des règles et des principes qui organisent le mouvement d'ensemble de la connaissance c'est-à-dire les relations entre l'objet de recherche et le chercheur (...). C'est une procédure qui organise un va et viens théorique entre les faits et les théories et qui préside aux choix des techniques.²

Etant donné que la méthode informatique est une démarche organisationnelle et conceptuelle permettant la mise en oeuvre d'une solution informatique, nous jugeons utiles que diverses méthodes nous aident à la réalisation du présent travail entre autre :

¹ MVIBUDULU K. et KITOKO Alphonse, Cours de MAI I, Inédit, G2 INFO, ISC-GOMBE, 2009-2010

² KAMBAYI, B. L. , Cité par MUKUNA BWATSHIA, dans Essai méthodologique sur la rédaction d'un travail scientifique., G2 INFO, ISC-GOMBE, 2009-2010.

4

- Structuro fonctionnelle : cette méthode nous a servi à connaitre et à étudier la structure et le fonctionnement de l'I.S.C. Kinshasa.

- Historique : nous a facilité l'étude du passé, du présent en vue d'un système futur.

- UML : C'est un langage de modélisation permettant de concevoir des systèmes d'information. Grâce à elle, nous avons eu à concevoir notre système d'information.

- UP : Le Processus Unifié (UP, pour Unified Process) est un processus de développement logiciel « itératif et incrémental, centré sur l'architecture, conduit par les cas d'utilisation et piloté par les risques »

- Méthode Potentiel de Métra : C'est une méthode d'ordonnancement basée sur la théorie des graphes, et visant à optimiser la planification des tâches d'un projet.

- Merise : C'est une méthode de conception des systèmes d'information. Grâce à elle, nous avons eu à analyser le système existant.

b. Techniques

La technique est l'ensemble de procédés employés pour produire une oeuvre, en obtenant un résultat déterminé. Autrement définie comme « Un moyen d'atteindre un but, un ensemble d'outils mis à la disposition de la recherche et organisés par la méthode pour atteindre un objectif quelconque »3

Pour la rédaction de ce travail, nous avons recouru aux techniques ci-après :

- Observation : elle nous a aidés à récolter les données à partir des simples observations au sein de l'Institut Supérieur de Commerce de Kinshasa.

- Interview : constitue l'ensemble d'investigations menées auprès des différents postes concernés par l'étude. Ces investigations sont formulées par des questions dont les réponses constituent les données.

- Analyse documentaire : elle nous a permis de recueillir les données sur base des documents soumis à notre disposition et aux différentes consultations : ouvrages, notes de cours, articles relatifs à notre sujet, etc.

6. Canevas du travail

A part l'introduction et la conclusion, notre travail est subdivisé en trois parties dont chacune d'elles contient des chapitres et sections.

Première partie : Cadrage du projet et approche théorique ayant comme chapitres :

1. Planning prévisionnel de réalisation du projet

2. Fondements Conceptuels

³ MUKUNA BWATSHIA, Op. Cit. p. 37

5

Deuxième partie : Etude préalable, comportant les chapitres suivants :

1. Présentation générale de l'Institut Supérieur de Commerce de Kinshasa

2. Analyse de l'existant

Troisième partie : Phase de la conception du Nouveau Système d'information avec comme chapitres :

- Capture initiale des besoins

- Capture des besoins fonctionnels

- Capture des besoins techniques

- Analyse fonctionnelle

- Conception générique

- Conception préliminaire

- Conception finale

Toutes ces trois parties et chapitres y afférents, nous ont aidé à développer et à concrétiser notre étude pour la production du logiciel.

Ière Partie : Cadrage du projet et Approche

théorique

Tout projet, dit informatique, doit avoir un planning prévisionnel permettant au maître d'oeuvre d'exécuter les travaux tels que présentés par maître d'ouvrage, et cela en respectant les besoins exprimés dans le cahier de charges et le délai de la réalisation des travaux.

C'est ainsi que, toute discipline dite scientifique comporte des termes propres voire spécifiques à partir desquels émane sa spécificité. Ainsi que, dans le deuxième chapitre de cette partie, il sera question de passer en revue les concepts informatiques de base et ceux de la modélisation orientée objet.

7

Chapitre I : Planning prévisionnel de réalisation du projet

Section 1 : Généralités

Pour concrétiser à bien un projet, il est recommandé au concepteur de pouvoir planifier les différentes tâches qui feront l'objet du projet et sa durée de réalisation.

Pour ce faire, nous avons opté pour « Ordonnancement » comme outil de recherche opérationnelle, surtout pour ces avantages ci-après :

- L'élaboration du planning de réalisation du projet ;

- La préséance des tâches ;

- La définition de la durée de chaque tâche ;

- La fixation de la date au plus tard et de la date au plutôt.

Pour y arriver, nous nous sommes servis de la méthode Potentielle de metra (MPM).

Section 2 : Ordonnancement du projet

2.1. Identification des tâches et délais

Code	Tâches	Coût (CDF)	Durée (jours)	Tâches antérieures
A	Recueil des données	147,000	4	-
B	Capture des besoins fonctionnels	414,000	6	A, B
C	Analyse	1, 380,000	10	C
D	Capture des besoins techniques	368,000	2	A, B
E	Conception générique	1, 223,600	7	B, D
F	Conception préliminaire	1, 380,000	10	C, E
G	Conception détaillée	1, 375,400	13	F
H	Codage et test	2, 318,400	28	G
I	Recette	460,000	5	F, G
J	Formation des utilisateurs	1, 380,000	2	I
	Formation de webmaster	920,000	3	A, D, I

Tableau 1.1.1 : Identification des tâches et délais

Le coût global du projet s'élève à 11, 366,400 CDF

8

2.2. Détermination des niveaux

>	Niveau 0	(C0)	: {a}
>	Niveau 1	(C1)	: {b}
>	Niveau 2	(C2)	: {c, d}
>	Niveau 3	(C3)	: {e}
>	Niveau 4	(C4)	: {f}
>	Niveau 5	(C5)	: {g}
>	Niveau 6	(C6)	: {h, i}
>	Niveau 7	(C7)	: {j, K}

2.3. Graphe partagé à niveaux

Ta=0

A

Tz=81

2

Tb=4 Td=10

B D

4

Z

6

6

C E F G

10 7 10

Tc=10 Te=20 Tf=27 Tg=37

13

13

H

I

Th=50

Ti=50

28

5

J

Tj=78

2

3

28

Tk=78

K

C0 C1 C2 C3 Cs C5 C6 C7 C8

Figure 1.1.1 : Graphe partagé à niveaux

9

2.4. Détermination des dates au plutôt (Tx)

Nivaux	Calculs de Tx	Tx Retenue
C0	- Ta=0	- Ta=0
C1	- Tb=Ta+4=0+4=4	- Tb=4
C2	- Tc=Tb+6=4+6=10 - Td=Tb+6=4+6=10	- Tc=10
C3	- Te=Tc+10=10+10=20	- Te=20
C4	- Tf=Te+7=20+7=27	- Tf=27
C5	- Tg=Tf+10=27+10=37	- Tg=37
C6	- Th=Tg+13=37+13	- Th=50
C7	- Tj=Th+28=50+28=78 - Tk=Th+28=50+28=78	- Tk=78
C8	- Tz=Tk+3=78+3=81	- Tz=81

Tableau 1.1.2 : Détermination des dates au plus tôt

2.5. Détermination des dates au plus tard (Tx)

Tâches	Calculs de T^*x	T^*x Retenue
Z	- T^*z =Tz=81	- T^*z = 81
K	- T^*k =Tz-3=81-3=78	- T^*k = 78
J	- T^*j = Tz-2=81-2=79	- T^*j = 79
H	- T^*h =Tj-28=79-28=51	- T^*h = 51
I	- T^*i =Tz-5=81-5=76	- T^*i = 76
G	- T^*g =Th-13=51-13=38	- T^*g = 38
F	- T^*f =Tg-10=38-10=28	- T^*f =28
E	- T^*e =Tf-7=28-7=21	- T^*e =21
D	- T^*d =Tz-2=81-2=79	- T^*d =79
C	- T^*c =Te-10=21-10=11	- T^*c =11
B	- T^*b =Tc-6=11-6=5	- T^*c =5
A	- T^*a =Tb-4=5-4=1	- T^*a =1

Tableau 1.1.3 : Détermination des dates au plus tard

10

2.6. Graphique potentiel

10

6

81

81

Z

27 28 F

37

10

21

20

10

7

E

38

50

13

G

I

A

5

4

B

4

0 1

6

10

C

79

5

11

76

2

13

3

28

50

51

78

79

H

J

28

78 78

K

D

C0 C1 C2 C3 C4 C5 C6 C7 C8

Figure 1.1.2 : Graphique potentiel

: Le chemin critique

: Le chemin non critique

- Le chemin critique est donné par : A, B, C, E, F, G, H, K et la durée est de 81 jours

2.7. Calculs des marges de tâches non critiques Les tâches non critiques sont : D, I et J

a. Marge Totale (MT)

Formule : MT=T^*x - Tx
MT(d)	=79-10=69
MT(i)	=76-10=26
MT(j)	=79-78=1

11

b. Marge Libre (ML)

Formule : ML=Tjx - Tⁱx-dx

ML(d)	=81-10-2=69
ML(i)	=81-50-5=26
ML(j)	=81-78-2=1

12

Chapitre 2 : Fondements conceptuels

Section1. Concepts informatiques de base

1.1. Notion du système

1.1.1. Définition

Les projets informatiques se réalisent dans les domaines bien définis lesquels constituent très souvent les systèmes (entreprise, organisation, institution). On peut définir le domaine et le système de différentes manières, selon qu'on se trouve dans tel ou tel domaine, selon tel ou tel auteur.

Nous retiendrons quelques-unes de ces définitions dont :

? Un système est un ensemble d'éléments structurés en interaction dynamique, poursuivant un but commun⁴

? Un système est défini comme quelque chose qui est dotée d'une structure, qui exerce une activité évoluant dans le temps et dans un environnement pour quelque chose.⁵

? Un système est un ensemble d'éléments notamment des ressources humaines, des matérielles, financières en interaction, structurées, organisées, dynamiques poursuivant un but en fonction des objectifs prédéfinis ».⁶

⁴ Joël de ROSNAY, cité par MVIBUDULU et KITOKO, dans le cours de MAI I G2 INFO, 2009-2010

⁵ J.L. LEMOIGNE, cité par MVIBUDULU et KITOKO, dans le cours de MAI G2 INFO, 2009-2010

⁶ MVIBUDULU et KITOKO, notes de cours de MAI I, G2 INFO, ISC /GOMBE, 2009-2010, Inédit

13

1.1.2. Organisation du système dans l'entreprise7

Dans l'entreprise, le système est organisé en différents systèmes appelés « Sous-système » représentés dans le schéma ci-après :

Système

Système de pilotage

Système d'information

Système d'opérant

Flux externe

Figure 1.2.1 : Organisation du système dans une entreprise

Flux interne

1.1.2.1. Système de pilotage

Ce système est constitué des dirigeants, c'est-à-dire des responsables de l'entreprise. Il a pour but la prise de décision, le contrôle, la coordination ainsi que la planification des activités.

Pour réaliser ces tâches, le système de pilotage donne des informations sous forme informationnelle au système opérant. Celui-ci est constitué des exécutants dont le but est la réalisation des services autrement dit, le système de pilotage décide des actions à conduire sur le système opérant en fonction des objectifs et des politiques de l'entreprise⁸

⁷ MVIBIDULU, Notes de cours MAI, G2 INFO ISC/GOMBE, 2010, Inédit. ^8. MVIBIDULU K et KITOKO M., Op. Cit.

14

1.1.2.2. Système d'information

C'est un système qui est défini comme l'ensemble des informations (données) circulant dans l'entreprise et/ou dans l'organisation. Cet ensemble d'information constitue la matière principale c'est-à-dire la partie intelligente d'un système. Du point de vue rôle, le système d'information :

- S'approprie des informations internes et externes ; - Fait l'analyse brute des informations ;

- Fait le traitement proprement dit ;

- Et la diffusion (l'utilisation).

De ce rôle ressort la fiabilité, la rapidité, la sécurisation et la pertinence de l'information du point de vue de sa qualité. Pour atteindre toutes ces qualités, il faut informatiser le système. A voir de près, le système d'information sert d'interface entre le système de pilotage et le système opérant dans une entreprise. Car, celle-ci est un système complexe dans lequel transitent de très nombreux flux d'informations.

1.1.2.3. Système Opérant

C'est un ensemble d'éléments matériels ou immatériels en interaction transformant par processus des éléments (les entrées) en d'autres éléments (sortie). Pourrions-nous dire que « Le système opérant englobe toutes les fonctions liées à l'activité propre de l'entreprise : Facturer les clients, gérer les affectations des agents, etc. »9

De ce qui procède, à propos des différents systèmes, il y a une décomposition qui prend bien en compte :

? « La différence de besoin en matière d'information des modules opérants et pilotes ; ? La nécessité pour le système d'information de ne pas se contenter de transmettre les informations mais d'en changer le niveau système ;

? Un système d'information intégré au système opérant ne décrit plus le fonctionnement du système d'information intégré au système de pilotage doit permettre d'engager les décisions prises lors de diverses situations afin de rendre le pilotage plus intelligent »10

Ainsi, toutes ces procédures systémiques convergents à l'organisation de l'entreprise pour que le traitement de l'information se structure de manière étroite et fiable. C'est alors que l'on parlera de l'information qui, elle, est une analyse ou une étude d'un système existant manuel.

⁹ DIGALLO F., Méthode Merise- Cours du Cycle B, Paris, 2001, P6

¹⁰ DISONAMA J., Cours de système d'exploitation II, G2 INFO, ISC-Gombe, 2009-2010, Inédit.

15

1.2. La notion de base de données

1.2.1. Définition

Pour J THULY et A. SAUNIE (dans Objectif et Conception d'une base de données) « une base de données est un ensemble d'informations normalisées, en liaison logique les unes avec les autres, qui, après avoir été saisies une seule fois, permettent de fournir aux différents échelons de la hiérarchie toutes les informations indispensables pour agir en temps voulu »11

Pour MARTIN H. : « Une base de données est une collection de données sur un domaine d'application particulier où les propriétés des données ainsi que les relations sémantiques entre ces données sont spécifiées en utilisant les concepts proposés par le modèle de données sous-jacent »¹². Autrement, pourrions-nous dire qu'une base de données est une entité dans laquelle il est possible de stocker les données de façon structurées et avec le moins de redondance possible. Ces données doivent pouvoir être utilisées par des personnes, par des utilisateurs différents.

Ainsi, la notion de base de données est généralement couplée à celle de réseau, afin de pouvoir mettre en commun ces informations, d'où le nom de base. On parle souvent de système d'informations pour désigner toute structure regroupant les moyens mis en oeuvre pour pouvoir partager des données.

« De façon simpliste, une base de données est définie comme étant un grand fichier dans lequel on retrouve des petits fichiers ayant des liens entre eux, renfermant des informations nécessaires, non répétitives et permettant à plusieurs utilisateurs d'y accéder simultanément »13

1.2.2. Architecture d'une base de données (SGBD)14

Les SGBD reposent sur trois niveaux d'abstractions qui assurent l'indépendance logique et physique des données, autorisent la manipulation de données et optimisent l'accès aux données.

Ce faisant, un SGBD est un système de stockage de l'information qui en assure la recherche et la maintenance. Les données sont persistantes (gestion de disque), partagées entre

¹¹ J THULY, A. SANNIE, Cité par KOLA MASIALA, dans le cours d'initiation à l'informatique G1 INFO, 20082009

¹² MARTIN H. Base de données et systèmes de gestion de base de données, Paris 1999

¹³ MVIBUDULU K, KONKFIE IPEPE, Technique de base de données ; Etude et cas 2^ème Edition Revue et corrigée, Ed. CRIGED, P17, 2012

¹⁴ J. MVIBUDULU et A. KITOKO, Notes de cours MAI II, G3 Info, Inédit, 2009-2010

16

de nombreux utilisateurs ayant des besoins différents, qui les manipulent à l'aide de langage approprié.¹⁵

ANSI/SPARC [ANSI] spécifie cette architecture à trois niveaux ci-après :

- Le niveau externe : il regroupe toutes les possibilités d'accès aux données par les différents usagers. Ces accès, éventuellement distants, peuvent se faire via différents types d'interfaces et langages plus ou moins élaborés. Ce niveau détermine le schéma externe qui contient les vues des utilisateurs sur la base de données, c'est-à-dire le sous ensemble de données accessibles ainsi que certains assemblages d'information et éventuellement des informations calculées.¹⁶

- Le niveau conceptuel : Il correspond à la vision des données générales, indépendantes, des applications individuelles et de la façon dont les données sont stockées. Dans le cas de SGBD relationnels, il s'agit d'une vision tabulaire où la sémantique de l'information est exprimée en utilisant les concepts de relation, attributs et de contraintes d'intégrité.

- Le niveau interne (physique) : Il regroupe les services de gestion de la mémoire secondaire. Il s'appuie sur un système de gestion de fichiers pour définir la politique de fonction des volumes de données traitées, des relations sémantiques entre les données ainsi qu'en fonction de l'environnement matériel disponible. La personne responsable de ce niveau est un administrateur de base de données. Son rôle est à la fois d'assurer la mise en place et le contrôle des procédures systèmes liées à la gestion de la base mais aussi de gérer les droits d'accès à la base.

Les architectures des bases de données prennent en compte trois schémas, à savoir : schéma conceptuel, schéma interne et schéma externe.

¹⁵ Jean Claude Marti, Cours de Base de données, Ed. Correction 2003, p. 3

¹⁶ www.wikipedia.com\informatique\base de donnée\architecture.php, consulté le 21 décembre 2013, 06h45

17

Il a comme rôle la modification des requêtes, le contrôle d'intégrité de données, le contrôle d'automatisation.

ARCHITECTURE FONCTIONNELLE TYPIQUE D'UN SGBD

BDD

METABASE

CONTROLEUR

ANALYSEUR

OPTIMISEUR

EXECUTEUR

Figure 1.2.2 : Architecture fonctionnelle typique d'un SGBD

Remarque : L'architecture fonctionnelle typique d'un SGBD combine les schémas ci-après : conceptuel, interne et externe. Son fonctionnement se fait à l'aide des programmes ci-après :

1. Analyseur

Il permet l'analyse syntaxique, sémantique et l'analyse de gestion de schéma.

2. Contrôleur

18

3. Optimiseur

Il permet l'ordonnancement, l'optimisation et l'élaboration des plans.

4. Exécuteur

Il exécute le plan, les méthodes d'accès et la tonicité des transactions.

En dehors de cette architecture, on distingue aussi :

- L'architecture client/serveur ; - L'architecture DRTG, etc.

L'architecture client serveur

L`architecture client/serveur désigne un mode de communication entre plusieurs ordinateurs d'un réseau, un ou plusieurs clients du serveur ; chaque logiciel client peut envoyer des requêtes à un serveur. Un serveur peut être spécialisé en serveur d'application, de fichiers, de terminaux, ou encore de messagerie électronique.

Caractéristique d'un serveur :

- Il est initialement passif (ou esclave, en attente d'une requête) ; - Il est à l'écoute, prêt à répondre aux requêtes au serveur ; - Il attend et reçoit les réponses du serveur.

Le client et le serveur doivent bien sûr utiliser le même protocole de communication. Un serveur est généralement capable de servir plusieurs clients simultanément.

Avantages

Toutes les données sont centralisées sur un seul serveur, ce qui simplifie les contrôles de sécurité et la mise à jour des données et des logiciels.

- Les technologies supportant l'architecture client/serveur sont plus matures que les autres.

- Une administration au niveau serveur, les clients ayant peu d'importance dans ce modèle, ils ont moins besoin d'être administrés.

Recherche d'informations

Les serveurs étant centralisés, cette architecture est particulièrement adoptée et véloce pour retrouver et composer de vaste quantité d'informations.

Inconvénients

Si trop des clients veulent communiquer avec le serveur au même moment, ce dernier risque de ne pas supporter la charge (alors que les réseaux pair à pair fonctionnent mieux en joutant de nouveaux participants).

19

- Si le serveur n'est plus disponible, plus aucun des clients ne fonctionne (le réseau pair à pair continu à fonctionner, même si plusieurs participants quittent le réseau). - Le coût de mise en place et de maintenance sont élevés.

- En aucun cas des clients ne peuvent communiquer entre eux, entraînant une asymétrie de l'information au profit des serveurs.

1.2.3. Importance de la base de données

Une base de données a comme importance de mettre des données à la disposition des utilisateurs pour une consultation, une saisie ou bien une mise à jour, la gestion de grande quantité d'informations, tout en s'assurant des droits accordés à ces derniers. Cela est d'autant plus utile que les données informatiques sont de plus en plus nombreuses.

Ainsi, l'avantage majeur d'une base de données est la possibilité de pouvoir y accéder par plusieurs utilisateurs de façon simultanée.

Section 2. Concepts relatifs à la modélisation orientée objet

Modéliser une application en utilisant les méthodes de la modélisation orientée objet nécessite une bonne maitrise de ses concepts. C'est alors, nous abordons de façon claire des différents concepts de base de la modélisation orientée objet.

2.1. Approche Objet17

L'approche objet consiste à créer une représentation informatique des éléments du monde réel, sans se préoccuper de l'implémentation, ce qui signifie indépendamment d'un langage de programmation. Il s'agit donc de déterminer les objets présents et d'isoler leurs données et les fonctions qui les utilisent. Pour cela, des méthodes de conception et de développement orientées objet ont été mises au point. Entre 1970 et 1990, de nombreux analystes ont mis au point des approches orientées objets, si bien qu'en 1994 il existait plus de 50 méthodes objets.

Toutefois, seules 3 méthodes ont véritablement émergées :

? La méthode OMT de Rumbaugh

? La méthode BOOCH'93 de Booch ? La méthode OOSE de Jacobson

A partir de 1994, Rumbaugh et Booch (rejoints en 1995 par Jacobson) ont unis leurs efforts pour mettre au point la méthode UML (Unified Modeling Language), qui permet de définir une notation standard en incorporant les avantages de chacune des méthodes précédentes (ainsi que celles d'autres analystes).

1. Les bases d'UML

¹⁷ Pascal Roques, Modéliser une application Web, 4^ème Edition, Ed. EYROLLES, Paris, 2009, p4.

UML 2 s'articule autour de treize (13) types de diagrammes, chacun d'eux étant dédié à la représentation des concepts particuliers d'un système logiciel.

20

UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.

UML unifie à la fois les notations et les concepts orientés objet. Il ne s'agit pas d'une simple notation graphique, car les concepts transmis par un diagramme ont une sémantique précise et sont porteurs de sens au même titre que les mots d'un langage. C'est ainsi, nous vous présentons cette historique sous forme d'un schéma.

Figure 1.2.3. : Schéma historique d'UML

UML unifie également les notations nécessaires aux différentes activités d'un processus de développement et offre, par ce biais, le moyen d'établir le suivi des décisions prises, depuis l'expression de besoin jusqu'au codage. Dans ce cadre, un concept appartenant aux exigences des utilisateurs projette sa réalité dans le modèle de conception et dans le codage.

Le fil tendu entre les différentes étapes de construction permet alors de remonter du code aux besoins et d'en comprendre les tenants et les aboutissants. En d'autres termes, on peut retrouver la nécessité d'un bloc de code en se référant à son origine dans le modèle des besoins.

2. Les diagrammes UML 2

21

Ces types de diagrammes sont répartis en deux grands groupes :

· Six diagrammes structurels :

- Diagramme de classes :

y' Jl montre les briques de base statiques :

Classes, associations, interfaces, attributs, opérations, généralisations, etc.

- Diagramme d'objets :

y' Il montre les instances des éléments structurels et leurs liens à l'exécution.

- Diagramme de packages :

y' Il montre l'organisation logique du modèle et les relations entre packages.

- Diagramme de structure composite :

y' Il montre l'organisation interne d'un élément statique complexe.

- Diagramme de composants :

y' Jl montre des structures complexes, avec leurs interfaces fournies et requises. - Diagramme de déploiement :

y' Jl montre le déploiement physique des « artefacts » sur les ressources matérielles.

· Sept (7) diagrammes comportementaux : - Diagramme de cas d'utilisation :

y' Jl montre les interactions fonctionnelles entre les acteurs et le système à l'étude.

- Diagramme de vue d'ensemble des interactions :

y' Il fusionne les diagrammes d'activité et de séquence pour combiner des fragments d'interaction avec des décisions et des flots.

- Diagramme de séquence :

22

y' Jl montre la séquence verticale des messages passés entre objets au sein d'une interaction.

- Diagramme de communication :

y' Il montre la communication entre objets dans le plan au sein d'une interaction.

- Diagramme de temps :

y' Il fusionne les diagrammes d'états et de séquence pour montrer l'évolution de l'état d'un objet au cours du temps.

- Diagramme d'activité :

y' Il montre l'enchaînement des actions et décisions au sein d'une activité.

- Diagramme d'états :

y' Il montre les différents états et transitions possibles des objets d'une classe.

2.2. Processus unifié

2.2.1. Définition du processus unifié

Un processus unifié est un processus de développement logiciel construit sur UML ; il est itératif et incrémental, centré sur l'architecture, conduit par les cas d'utilisation et piloté par les risques¹⁸ ;

2.2.2. Les principes fondamentaux du processus unifié19

Ces principes fondamentaux se présentent comme suit :

- Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1 mois) qui aident à mieux suivre l'avancement global. À la fin de chaque itération, une partie exécutable du système final est produite, de façon incrémentale.

- Centré sur l'architecture : tout système complexe doit être décomposé en parties modulaires afin de garantir une maintenance et une évolution facilitées. Cette architecture (fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML et pas seulement documentée en texte.

- Piloté par les risques : les risques majeurs du projet doivent être identifiés au plus tôt, mais surtout levés le plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l'ordre des itérations.

¹⁸ Pascal Roques & Franck vallée, UML 2 en action de l'analyse à la conception 4^ème Edition, Ed. EYROLLES, Paris, 2007, p12.

¹⁹ Pascal Roques, Modéliser une application Web 4^ème Edition, Ed. EYROLLES, Paris, 2006, p9-10.

23

- Conduit par les cas d'utilisation : le projet est mené en tenant compte des besoins et des exigences des utilisateurs. Les cas d'utilisation du futur système sont identifiés, décrits avec précision et priorisés.

2.2.3. Les phases et les disciplines de UP20

La gestion d'un tel processus est organisée d'après les 4 phases suivantes: pré étude (inception), élaboration, construction et transition²¹.

y' La phase d'initialisation conduit à définir la « vision » du projet, sa portée, sa faisabilité, son business case, afin de pouvoir décider au mieux de sa poursuite ou de son arrêt.

y' La phase d'élaboration poursuit trois objectifs principaux en parallèle :

- Identifier et décrire la majeure partie des besoins des utilisateurs ;

- Construire (et pas seulement décrire dans un document !) l'architecture de base du système ;

- Lever les risques majeurs du projet.

y' La phase de construction consiste surtout à concevoir et implémenter l'ensemble des éléments opérationnels (autres que ceux de l'architecture de base). C'est la phase la plus consommatrice en ressources et en effort.

y' Enfin, la phase de transition permet de faire passer le système informatique des mains des développeurs à celles des utilisateurs finaux. Les mots-clés sont : conversion des données, formation des utilisateurs, déploiement, béta-tests.

Ses activités de développement sont définies par 6 disciplines fondamentales qui décrivent la modélisation métier, la capture des besoins, l'analyse et la conception, l'implémentation, le test et le déploiement²².

2.2.4. Le Processus 2TUP23

Le 2TUP signifie « 2 Track Unified Process ». C'est un processus UP qui répond aux caractéristiques que nous venons de citer. Le processus 2TUP apporte une réponse aux contraintes de changement continuel imposées aux systèmes d'information de l'entreprise.

En ce sens, il renforce le contrôle sur les capacités d'évolution et de correction de tels systèmes. « 2 Track » signifie littéralement que le processus suit deux chemins. Il s'agit des chemins « fonctionnels » et « d'architecture technique », qui correspondent aux deux axes de changement imposés au système informatique.

²⁰ Pascal Roques, Op. Cit. p10.

²¹ Pascal Roques & Franck vallée, Op. Cit. p12

²² Idem.

²³ Pascal Roques, Op. Cit. p10.

Ils ont un nom et soit un type de base (simple ou construit) soit une classe (l'attribut référence un objet de la même ou une autre classe).

24

À l'issue des évolutions du modèle fonctionnel et de l'architecture technique, la réalisation du système consiste à fusionner les résultats des deux branches. Cette fusion conduit à l'obtention d'un processus de développement en forme de Y.

Figure 1.2.4.: Processus de développement en Y

2.3. Notion de classe et objet

? Classe :

On appelle classe, la structure d'un objet, c'est-à-dire la déclaration de l'ensemble des entités qui composeront un objet. Les objets de même nature ont en général la même structure et le même comportement. La classe factorise les caractéristiques communes de ces objets et permet de les classifier.

Classe = instanciation + attributs (variables d'instances) + opérations

V' L'instanciation :

L'objet possède une identité, qui permet de le distinguer des autres objets, indépendamment de son état. L'instanciation représente la relation entre un objet et sa classe d'appartenance qui a permis de le créer.

V' Les attributs (appelés aussi variables d'instances):

25

V' Les opérations (appelées parfois méthodes):

Elles sont les opérations applicables à un objet de la classe. Elles peuvent modifier tout ou en partie l'état d'un objet et retourner des valeurs calculées à partir de cet état.

? Objet

Un objet est une abstraction d'un élément du monde réel. Il possède des informations, par exemple Id_Cours, Lib_Cours, Nbre_Heure, etc., et se comporte suivant un ensemble d'opérations qui lui sont applicables.

De plus, un ensemble d'attributs caractérisent l'état d'un objet, et l'on dispose d'un ensemble d'opérations (les méthodes) qui permettent d'agir sur le comportement de notre objet.

Un objet est l'instance d'une classe tandis qu'une classe, est un type de données abstrait, caractérisé par des propriétés (ses attributs et ses méthodes) communes à des objets, qui permet de créer des objets possédant ces propriétés.

Vu l'importance qu'offre l'approche objet, nous faisons un petit détail sur ses

avantages.

> Avantages de l'approche objet :

La modélisation des objets de l'application (consiste à modéliser informatiquement un ensemble d'éléments d'une partie du monde réel en un ensemble d'entités informatiques. Ces entités informatiques sont appelées objet)

La modularité (la programmation modulaire permet la réutilisation du code, via l'écriture de librairies).

La réutilisabilité - L'extensibilité

Pour une meilleure productivité des développeurs et une plus grande qualité des applications.

> La maitrise de la complexité d'un système

Il est à signaler que la maitrise de la complexité d'un système repose sur trois principes à savoir :

V' l'abstraction (voir le comportement des objets indépendamment de leur représentation interne).

V' La décomposition (des objets complexes en objets plus simple)

V' La connexion (des objets suivants leurs interactions).

26

2.4. L'Encapsulation

Le concept d'encapsulation est un mécanisme consistant à rassembler les données

et les méthodes au sein d'une structure en cachant l'implémentation de l'objet, c'est-à-dire en empêchant l'accès aux données par un autre moyen que les services proposés. L'encapsulation permet donc de garantir l'intégrité des données contenues dans l'objet.

L'encapsulation permet de définir des niveaux de visibilité des éléments de la classe. Ces niveaux de visibilité définissent les droits d'accès aux données selon que l'on y accède par une méthode de la classe elle-même, d'une classe héritière, ou bien d'une classe quelconque.

Il existe trois niveaux de visibilité :

· publique : Les fonctions de toutes les classes peuvent accéder aux données ou aux méthodes d'une classe définie avec le niveau de visibilité public. Il s'agit du plus bas niveau de protection des données.

· protégée : l'accès aux données est réservé aux fonctions des classes héritières, c'est-à-dire par les fonctions membres de la classe ainsi que des classes dérivées.

· privée : l'accès aux données est limité aux méthodes de la classe elle-même. Il s'agit du niveau de protection des données le plus élevé.

Intérêt de l'encapsulation : On peut protéger le contenu des classes d'une manipulation maladroite et ou mal intentionnée. Un objet est caractérisé par ses données et ses traitements mais il est aussi caractérisé par une partie publique, une partie privée et une partie implémentation, c'est ce que l'on appelle l'abstraction.

2.5. La notion d'Héritage

La notion d'héritage est une relation entre différentes classes permettant de définir une nouvelle classe en se basant sur les classes existantes. On parle d'héritage simple lorsqu'une classe fille ne possède qu'une classe mère.

On parle d'héritage multiple lorsqu'une classe fille possède plusieurs classes filles.

CLASSE 1		Classe mère

Héritage simple

CLASSE 2		Classe fille

Figure 1.2.5. : Schéma d'un héritage simple

27

Héritage multiple

CLASSE 1

		CLASSE 2
CLASSE 3

Figure 1.2.6. : Schéma d'un héritage multiple

2.6. Abstraction

C'est le fait de se concentrer sur les caractéristiques importantes d'un objet selon le point de vue de l'observateur.

NB : L'abstraction est un principe qui consiste à ignorer certains aspects d'un sujet qui ne sont pas importants pour le problème dans le but de se concentrer sur ceux qui le sont.

2.7. Polymorphisme

Le terme polymorphisme issu du grec signifie la faculté de prendre plusieurs formes. Une entité est polymorphe si à l'exécution elle peut se référer à des instances de classe différentes.

Ex :

DIRECTEUR

Calcul - salaire ()

ELECTRICIEN

Calcul - salaire ()

Figure 1.2.7. : Exemple d'un polymorphisme.

Le polymorphisme est un mécanisme qui permet à une sous classe de redéfinir une méthode dont elle a hérité tout en gardant la même signature de la méthode.

28

IIème Partie : Etude préalable

L'étude préalable autrement appelée l'étude de faisabilité, permet d'étudier l'opportunité et la praticabilité du nouveau système à mettre en place, c'est-à-dire elle permet au concepteur de recueillir toutes les informations nécessaires et les besoins des utilisateurs pour décider sur les modifications des objets, des moyens ou des méthodes afin d'améliorer la performance ou réduire le coût.

Son but est de répondre à la question oui ou non doit-on informatiser. C'est-à-dire :

- Est-il opportun de résoudre les problèmes par ordinateur ?

- Quelle est la praticabilité d'utilisation de l'ordinateur ?

29

Chapitre I : Présentation de l'institut supérieur de commerce de

Kinshasa

Dans ce chapitre, il sera question de faire une brève présentation de l'Institut Supérieur de Kinshasa et de donner son organisation ainsi que le fonctionnement.

Section 1. Dénomination et situation géographique

L'institut supérieur de commerce se situe dans la commune de la Gombe à Kinshasa, sur l'avenue de la libération (ex 24 novembre) en République Démocratique du CONGO (RDC). Plus précisément en diagonale avec le CIDEP et en face de l'Inspection Provinciale de la Police de Kinshasa (IP KIN en sigle).

Section 2. Aperçu historique

L'Institut Supérieur de Commerce de Kinshasa fut fondé en 1962 sous l'initiative du Révérend Père Gaston BOGAERT par la congrégation des pères de SCHEUT de LIMETE ; il portait la dénomination de l' « Ecole Supérieur de Commerce ».

Elle fonctionnera jusqu'à 1966 d'une manière provisoire sous l'arrêté ministériel n°EDM/ESURS/2123 du 14 décembre 1964. C'est seulement cette année-là qu'elle sera agréée définitivement suite à la décision du ministre de l'éducation nationale n°EDM/ESURS/1249 du 8 juin 1966, celle-ci autorisait à l'école Supérieure de Commerce de fonctionner avec une seule section commerciale et financière.

En 1968, la section commerciale et financière ne sera que passagère ; en 1970 la section secrétariat de direction fut créée, elle qui était auparavant un cycle.

Pendant toutes ces périodes, l'Ecole Supérieur de Commerce avait pour mission la formation des cadres moyens au profit des entreprises commerciales et bancaires ; comme il ne possédait pas ses propres bâtiments, il utilisait les locaux de l'Institut TECHNIQUE commercial de LIMETE (COLLEGE saint Raphaël) pour son fonctionnement.

Le 6 août 1971, date de la première réforme de l'Enseignement Supérieur et Universitaire, a occasionné un concert de trois universités du pays (Kinshasa, Lubumbashi et Kisangani) avec les institutions supérieures. Ils constituèrent dorénavant l'Université Nationale du Zaïre, UNAZA en sigle. Le fonctionnement de l4 Instituts Supérieurs de Commerce fut désormais régi par l'ordonnance n° 71-075 du 6 août 1971.

Cette même année, l'Ecole Supérieure de Commerce déménagera pour le siège actuel de l'ISC-KINSHASA sur l'avenue de la libération du 24 Novembre.

L'Ecole Supérieure de Commerce sera dotée d'une section nouvelle en 1974, l'Informatique. En 1978, elle va changer d'appellation pour devenir «Institut Supérieur de Commerce de Kinshasa », ISC Kinshasa en sigle.

30

En 1981, une nouvelle réforme de l'Enseignement Supérieur et Universitaire accorde à l'ISC l'autonomie de gestion. L'ordonnance loi présidentielle n°81/158 du 7 octobre 1981 confère à cet effet, à l'ISC la personnalité juridique et son organisation actuelle.

La section licence (2^ème Cycle) sera créée à l'Institut Supérieur de Commerce de Kinshasa par l'arrêté ministériel n° ESU/CABMIN/0728 du 04 juin 1996 et la section secrétariat de direction sera transformée en cycle complet de graduat par l'arrêté ministériel n° ESU/CABMIN/0729 du 04 juin 1996.

Section 3. Missions et objectifs

L'Institut SUPERIEUR de commerce a pour mission :

a. De former des cadres spécialisés dans le domaine des techniques commerciales, de comptabilités et informaticiens dans le domaine de sciences informatiques de gestion;

b. D'organiser la recherche sur l'adaptation des techniques commerciales et de comptabilité aux exigences du développement de notre pays ;

c. De former les cadres de direction dans les domaines de secrétariat ;

d. D'adapter nos anciens diplômes aux exigences nouvelles de la science et de la technologie.

Ainsi, l'enseignement s'étend sur une période de quatre ans pour la section soir. Trois ans pour la section jour et sur période de deux ans pour la licence.

Pour le moment, L'ISC fonctionne avec 7 sections, à savoir:

- Les sciences commerciales et financières /jour; - Les sciences commerciales et financières /Soir; - Guidance

- Le secrétariat de direction

- L'informatique de gestion

- La licence.

- Gestion des Ressources humaines

Il est à signaler qu'actuellement, l'ISC dispense le programme de master en différentes options, qui est un partenariat avec l'université de liège.

31

Section 4 : Organisation et fonctionnement

4.1. Organisation :

La structure organisationnelle de l'Institut Supérieur de Commerce se présente comme suit :

a) Section graduat jour

La section graduat jour est généralement disponible d'accueillir les jeunes détenteurs de diplôme d'état. Elle forme des techniciens en machine de gestion financière des entreprises.

Et la formation acquise favorise l'intégration plus poussée dans les milieux économiques à travers les stages et les visites guidées dans les entreprises. La durée des études est de trois ans.

b. Section informatique

La formation dans cette section est organisée par une fusion de deux techniques à

savoir :

La technique de sciences commerciales et la technique de sciences informatique qui, à la fin de formation, produit des analyses programmeurs appelés à concevoir et à réaliser les programmes et qui alimenteraient les matériels de traitement de l'information.

c. Section graduat soir

Créer sur la demande des entreprises de place pour la perfection et l'acquisition d'une qualification adéquate de leurs agents, la section graduat soir était réservée aux jeunes qui exercent un métier ou fonctionnaire.

Un emploi de plein temps, libre au lieu à un contrat de travail. Suite à l'incapacité d'accueil à la section pour laquelle l'incapacité a fragilisé le critère de recrutement à la section soir qui était jadis réservée aux travailleurs. La durée des études est de quatre ans.

d. Section secrétariat de direction

La section secrétariat de direction forme les secrétaires (hommes et femmes) destines aux travaux de bureau, d'ordination. La durée d'études est de trois ans.

e. Section guidance

Dirigée par un chef de section, assisté par deux adjoints. La section guidance :

? Aide les étudiants qui présentent les différents problèmes d'adaptation dans le milieu académique ;

? Organise de semaines pédagogiques en vue d'améliorer et d'adapter l'enseignement en programme.

32

La section guidance est aussi en organe d'information et analyse statique.

f. Section licence

Opérationnelle depuis l'année académique 1997- 1998. Cette section était réservée seulement aux anciens diplômés de l'Institut Supérieur de Commerce ayant une expérience d'au moins cinq ans dans la vie professionnelle. Actuellement, l'Institut a allégé ses exigences.

g. Section Administration et Gestion des Ressources humaines

La section Gestion des Ressources Humaines a vu le jour depuis l'année académique 2013-2014. Sur ce, on n'a pas pu accueillir les informations importantes sur son fonctionnement.

4.2. Fonctionnement

L'Institut Supérieur de Commerce dans son fonctionnement, renferme les agences ci-

après :

> Le conseil de l'Institut Supérieur de Commerce ;

> Le comité de gestion ;

> Le directeur générale ;

> Le conseil de section ;

> Le conseil de département.

a. Conseil de l'Institut Supérieur de Commerce Il est composé des membres ci- après :

> Le Directeur Général ;

> Le secrétaire général académique ;

> Le secrétaire administratif ;

> L'administrateur du budget ;

> Les chefs de sections ;

> Un représentant du corps académiques ;

> Un représentant du corps scientifique ;

> Un représentant du personnel administratif et technique ;

> Un représentant des étudiants.

Le conseil de l'Institut Supérieur de Commerce de Kinshasa examine tous les problèmes importants qui ont trait à la vue de l'institut, il fixe la politique générale de l'ISC. En conformité avec la voie tracée par les organes supérieurs : le conseil d'administration et le ministère de l'éducation nationale, l'enseignement supérieur et universitaire et de la recherche scientifique.

b. La comite de gestion Ce comité comprend :

> Le Directeur Général ;

> Le secrétaire général académique ;

Ce comité assure la gestion courante de l'Institut sous la direction du Directeur général et fait exécuter les décisions du département de l'enseignement supérieur et universitaire.

33

? Le secrétaire général administratif ;

? L'administrateur du budget.

Il assure la gestion quotidienne de l'institut sans la direction du chef d'établissement ; il exécute les instructions du ministère de tutelle, du conseil d'administration de l'Institut Supérieur Techniques.

C. Le Directeur Général

Il est nommé par l'ordonnance présidentielle sur proposition du ministre de L'Enseignement Supérieur et Universitaire et de la Recherche Scientifique, parmi les membres du personnel académique ayant au moins de grade du professeur, pour un mandat de cinq ans une fois renouvelable. Il préside le conseil de l'Institut et de la comité de gestion; il supervise et coordonne l'ensemble des activités; veille au respect du statut et règlement de l'Institut Supérieur de Commerce dans toutes les relations extérieures officielles avec les autorités tant nationales qu'internationales et, en cas d'urgence prend des mesures nécessaires qui relèvent de la compétence du conseil de l' ISC, à charge de l'en informer à toute prochaine réunion, enfin, il fait un rapport annuel au conseil d'administration sur le fonctionnement de l'établissement.

d. Secrétaire Général Académique

Il remplace le DG en cas d'absence. Il fait des propositions sur le développement des activités académiques et scientifiques de l'Institut. Son rôle est de gérer les étudiants et il élabore le calendrier avec l'horaire des cours.

e. Secrétaire Général Administratif

Il conseille l'administration après avis du conseil de section et de département, des écoles, des instituts, le nombre d'heures de cours que compte la répartition des matières par année d'étude et tous.

Les documents administratifs de l'Institut, a pour un mandat de 4 ans

renouvelables.

f. Administrateur du Budget

Il doit être parmi les personnes titulaires d'un diplôme de licence et justifiant d'une expérience d'au moins 3 ans dans l'administration de finances publiques ou de l'enseignement supérieur et universitaire et ce pour un mandat de 4 ans renouvelables. Son rôle et de gérer des ressources financières qui permettent à l'Institut de faire face à d'autres problèmes financières.

g. Les chefs de section

Ils doivent être parmi les membres du corps académique proposé par conseil de section pour un mandat de 2 ans renouvelables. Leur rôle est gérer les professeurs oeuvrant dans leurs sections les étudiants.

h. Le comité de gestion

34

i. La direction générale

Il coordonne et supervise toutes les activités de l'établissement et seconde dans l'exécution de ses fonction par :

? Un assistant ;

? Un secrétaire ;

? Un chargé des relations publiques ;

? Un service de sécurité et d'audit interne.

Le conseil de section

Ce conseil se constitue de corps enseignement ainsi que des étudiants. Il gère les chefs des sections qui exercent leurs fonctions selon les dispositions du règlement organique.

Le chef de section est secondé dans ses fonctions par :

1. Chef de section adjoint chargé de l'enseignement ;

2. Chef de section adjoint chargé de recherche ;

3. Secrétaire académique auprès de la section.

Source : Secrétariat Général Académique

35

Conseil de l'Institut
Comité de gestion
Directeur Général

Chef de cabinet
Chargé de coopération
Chargé des activités
Secrétaire administratif

Chargé des rel. Publiques

Div. Garde et Sécurité Informatique

Bureau de planification statistique et Dvpt.

Secrétaire Gen. Acad.

Secrétaire Gen. Adm.

Adm. Du Budget

Les sections

Dir. du personnel

Dir. des finances et Budget

Dir. des affaires académiques

Dir. des oeuvres estudiantines

Dir. Budget et contrôle

Dir. des services académiques

Dir. des affaires sociales

Dir. de l'auto-financement

Dir. de l'enseignement et recherche

Dir. d'entretien et maintenance

Dir. de patrimoine et intendance

Dir. de recherche Int. et Dvpt.

Bibliothèque

Programme Master

4.3. Organigramme de l'Institut Supérieur de Commerce de Kinshasa

36

Figure 2.1.1. : Organigramme général de l'Institut Supérieur de Commerce de Kinshasa

Chapitre II : Analyse de l'existant

But

L'analyse de l'existant a pour but de recenser les points faibles et les points forts de l'application c'est-à-dire du domaine d'étude. Pour ce faire, l'analyste est sensé mener des investigations dans le système pour connaître son fonctionnement afin de relever les failles du système en vigueur qui permettront de poser un diagnostic précis en ce qui concerne l'organisation, le traitement de l'information pour le domaine concerné à l'informatisation.

Section 1. Description des activités du Secrétariat Général Académique

Le secrétariat général académique de l'Institut Supérieur de Commerce de Kinshasa exerce les activités ci-après :

- Tenir à jour les dossiers académiques

des membres du personnel académique et scientifique ;

- Organiser le recrutement du personnel
scientifique ;

- Veiller au respect du calendrier
académique, etc.

Section 2 : Organisation et fonctionnement

2.1. Organisation

Le Secrétariat Général Académique l'Institut Supérieur de Commerce de Kinshasa est organisé de la manière suivante :

- Le secrétaire général académique ;

- Le chef de division assistant du

secrétaire général académique;

- Le chef de bureau chargé du
secrétariat;

- Le dactylographe;

- Le directeur des services académiques;

- Le chef de bureau du secrétariat;

- Le chef e division des inscriptions et

contrôle de scolarité;

- Le chef de bureau des inscriptions ;

- Le chargé des archives;

- Le chargé d'Enregistrement et contrôle

des dossiers

? Le Chef de division Assistant du

Secrétaire Général Académique

37

- Le chef de bureau de scolarité;

- Le chef de division enseignement et

recherche;

- Le chef de bureau gestion du personnel
académique et scientifique;

- Le chargé de recrutement;

- Le chargé de gestion du personnel et

scientifique à temps plein;

- Le chargé de gestion du personnel
académique et scientifique à temps partiel;

- Le chef de bureau enseignement et
programme;

- Le chargé des horaires;

- Le chargé des stages et pratiques

professionnels;

2.2. Fonctionnement

? Le Secrétaire Général Académique

Il est chargé à résoudre des problèmes académiques et conformément aux dispositions du règlement organique de l'Etablissement (Ord. n°81/142, art. 17). A ce titre :

a) Il remplace le chef d'Etablissement en cas d'empêchement ou d'absence ;

b) Il peut assister sans voix aux réunions des conseils des sections, des départements et de toutes autres institutions ou services de l'Etablissement ainsi qu'aux jurys d'examens ;

c) Il est tenu de suivre au jour le jour les activités de tout le secteur académique de l'Etablissement ;

d) Il assiste de façon régulière aux réunions des sections et à toutes les réunions à caractère académique ;

e) Il rédige chaque semestre un rapport détaillé sur la vie académique de son Etablissement ;

f) Il est tenu de suivre de près tout ce qui concerne l'auto-évaluation ;

g) Il tient à jour une documentation complète des règlements, instructions, circulaires, etc. d'ordre académique ;

h) Il supervise de manière directe les services des inscriptions ;

i) Il établit les états de besoin en personnel académique et scientifique etc.

a) Il est le seul habilité à entrer en contact

avec le secrétaire général académique pour tous les problèmes de la direction ;

38

Il est collaborateur du Secrétaire Général Académique et à ce titre :

a) Il coordonne toutes les activités du Secrétariat Général Académique ;

b) Il veille à l'application ou à l'exécution des instructions transmises par le Secrétaire Général Académique à l'intention du personnel du Secrétariat Général Académique ;

c) Il s'occupe de la rédaction de certaines correspondances qui lui sont confiées par le Secrétaire Général Académique ;

d) Il élabore les projets et des réunions de service du Secrétariat Général Académique ;

e) il organise les audiences et les rendezvous du Secrétariat Général Académique etc.

? Le chef de Bureau Chargé du

Secrétariat

Il est le collaborateur immédiat de l'Assistant du Secrétaire Général Académique, et

à ce titre :

a) Il rédige les lettres administratives lui confiées par l'assistant du Secrétaire Général Académique ;

b) Il veille à la dactylographie de tout travail demandé par l'assistant su Secrétaire Général Académique ;

c) Il établit les états de besoin en fournitures de bureau, mobiliers, matériels et équipements pour le Secrétariat Général Académique, qu'il transmet à l'assistant ;

d) Il veille à l'organisation et au fonctionnement efficace de toutes les activités du Secrétariat Général Académique ;

? Le dactylographe

Il est chargé ;

1. D'assurer la dactylographie de tous les documents relevant du bureau du Secrétaire Général Académique ;

2. De veiller à l'entretien de la machine mise à sa disposition etc.

? Le Directeur des services

académiques

Il est le collaborateur immédiat du Secrétaire Général Académique dans son secteur, et à ce titre :

ce titre :

39

b) Il est chargé d'assurer le contrôle et l'exécution des décisions du comité de gestion relative au fonctionnement de la direction ;

c) Il supervise et coordonne les activités des divisions placées sous sa responsabilité ;

d) Il établit les rapports semestriels et annuels des activités de la direction à adresser au secrétaire général académique etc.

? Le chef de bureau du secrétariat

Il est le collaborateur du directeur des services académiques, à ce titre :

a) Il rédige les lettres administratives lui confiées par le directeur des services académiques ;

b) Il veille à l'enregistrement, à la transmission et à l'expédition du courrier de la direction des services académiques ;

c) Il veille à la dactylographie de tout travail demandé par le directeur des services académiques ;

d) Il établit les états de besoins en fournitures de bureau, mobiliers et matériel d'équipement pour le secrétariat des services académiques etc.

? Le chef de division inscription et

contrôle de scolarité

Il est le collaborateur immédiat du directeur des services académiques ans son secteur, et à ce titre :

a) Il supervise et coordonne toutes les activités de la division ;

b) Il fait part au directeur des initiatives venant des agents placés sous ses ordres ;

c) Il adresse au directeur des services académiques les rapports d'activités périodiques ;

d) Il décide dans toutes les matières de sa compétence et donne ses avis dans celles qui ne le sont pas ;

e) Il conçoit les programmes à exécuter en matière d'inscription et de scolarité ;

f) Il coordonne les recours des étudiants etc.

? Le chef de bureau des inscriptions

Il est le collaborateur du chef de division des inscriptions et contrôle de scolarité, et

40

a) Il supervise et coordonne toutes les activités du bureau ;

b) Il cote au 1^èr échelon tous les agents sous sa responsabilité ;

c) Il décide dans toutes les matières de sa compétence et donne ses avis dans celle qui ne le sont pas ;

d) Il enregistre les candidatures des étudiants et en établit le tableau de synthèse ;

e) Etc.

? Le chargé des archives

Il est sous la supervision du chef de bureau des inscriptions, il est chargé de :

a) recevoir les dossiers des candidats,
anciens et nouveaux diplômes des humanités ;

b) enregistrer les candidatures des
étudiants aux sessions d'examens ;

c) Etablit les listes des étudiants admis ou
refusés.

? Le chargé d'Enregistrement et

contrôle des dossiers

Il est Sous la supervision du chef de bureau des inscriptions, il est chargé de :

a) enregistrer, classer et de sérier les
dossiers des étudiants par année d'études ;

b) élaborer les fiches récapitulatives des
principaux éléments constitutifs des dossiers ;

c) tenir une fiche de retrait des
documents.

Section 3 : Etudes des postes de travail

Dans cette section, il sera question de passer en revue les différents postes intervenant aux processus retenus pour ce travail concernant les activités académiques.

3.1. Recensement des postes de travail

Par rapport aux données récoltées lors de notre entretien avec les différentes autorités académiques et autorités de canal, nous présentons des postes recensés de la manière ci-après :

- Etudiant ;

- Président du jury ; - Secrétaire du jury ;

41

- Membre du jury ;

- Secrétariat de la Section ;

- Chef de section ;

- Chef de département ;

- Banque ;

- Secrétaire Général Académique ;

- Enseignant ;

- Encodeur.

3.2. Description des postes de travail

1. Candidat (Etudiant)

Attributions		Payer les frais académiques, Payer les frais d'enrôlements, Payer les frais de relever de côtes, Présenter les examens des différentes sessions, etc.	Documents reçu
Reçu de frais académiques, Reçu de frais d'enrôlement et Relever de côtes.		Document émis
Aucun		Documents classés
Reçu de frais académiques, Reçu de frais d'enrôlement et Relever de côtes

Tableau 2.2.1 : Description du poste étudiant

2. Secrétaire Général Académique

Attributions	Signer et Publier les différentes listes en provenance des différentes sources, etc.
Documents reçu	Listes des étudiants ayant payé les frais académiques, Listes des étudiants ayant payé les frais d'enrôlement, Les PV de délibérations de toutes les promotions
Documents émis	Listes des étudiants ayant payé les frais académiques, Listes des étudiants ayant payé les frais d'enrôlement (Fiche des côtes), Listes des délibérations de toutes les promotions.
Documents archivés	Listes des étudiants ayant payé les frais académiques, Listes des étudiants ayant payé les frais d'enrôlement, Les PV de délibérations de toutes les promotions

Tableau 2.2.2 : Description du poste Secrétariat Général Académique

3. 42

Président du jury

Attributions	Présider le jury, contre vérifier les Grilles de délibérations, signer les PV et Grilles de délibérations, etc.
Documents reçu	Grilles de côtes avant délibération, les PV et Grilles de délibérations
Document émis	Aucun
Documents classés	Les PV et Grilles de délibérations

Tableau 2.2.3. : Description du poste Président du jury

4. Secrétaire du jury

Attributions	Recevoir les fiches de côtes en provenance des enseignants (département), vérifier les grilles de côtes avant délibération, élaborer les PV sur base des grilles de délibération.
Documents reçu	Fiches de côtes (liste des enrôlés), Grille de côtes avant délibération.
Documents émis	Les PV et Grilles de délibérations
Documents classés	Fiches de côtes (liste des enrôlés), Les PV et Grilles de délibérations

Tableau 2.2.4. : Description du poste Secrétaire du jury

5. Membres du jury

Attributions	Participer au jury de délibération, donner des avis sur des décisions prises par le jury de délibération, etc.
Document reçu	Grilles de côtes avant délibération
Document émis	Aucun
Documents classés	Aucun

Tableau 2.2.5 : Description du poste Membres du jury

6. Encodeur

Attributions	Saisir les côtes des étudiants, aider le secrétaire du jury à l'élaboration des différents documents, etc.
Document reçu	Fiches de côtes (liste des enrôlés)
Document émis	Grilles de côtes

43

Documents classés

Grilles de côtes

Tableau 2.2.6 : Description du poste Encodeur

7. Secrétariat de la Section

Attributions		Percevoir l'argent pour les relevés des côtes, établir les relevés de côtes, etc.	Documents reçu
Relevés de côtes signés par le chef de section.		Documents émis
Reçu de payement des frais de relevé des côtes, relevés de côtes, Cahier de retrait de relevés de côtes		Document archivé
Cahier de retrait de relevés de côtes

Tableau 2.2.7. : Description du poste Secrétariat de la section

8. Chef de Département

Attributions		Remettre des fiches de côtes sans côte aux enseignants, recevoir les fiches de côtes avec en provenance des enseignants, vérifier les relevés de côtes avant signature du chef de section, etc.	Documents reçu
Fiche des côtes (liste des enrôlés), PV et Grilles de délibérations de son département, Relevés de côtes, Liste des admis, etc.		Document émis
Aucun		Documents classés
PV et Grilles de délibérations de son département, Liste des admis, Liste des enrôlés.

Tableau 2.2.8 : Description du poste Chef de département

9. Chef de section

Attributions	Gérer la section, signer les relevés de côtes, etc.
Documents reçu	Relevés de côtes, PV et Grilles de délibérations de sa section.
Document émis	Relevés de côtes signés
Documents classés	PV et Grilles de délibérations de sa section

Tableau 2.2.9 : Description du poste chef de section

10. 44

Banque

Attributions		Perception des frais académiques, enrôlements, établir la liste des différents payements, etc.	Documents reçu
Reçu de frais académiques, Reçu de frais d'enrôlement et Relever de côtes.		Document émis
Listes des étudiants ayant payé les frais académiques, Listes des étudiants ayant payé les frais d'enrôlement, etc.		Documents Archivés
Listes des étudiants ayant payé les frais académiques, Listes des étudiants ayant payé les frais d'enrôlement, etc.

Tableau 2.2.10 : Description du poste banque

11. Enseignant

Attributions	Recevoir les fiches des enrôlés sans côtes en provenance du département, Remplir les fiches des côtes avec des côtes, etc.
Documents reçu	Fiches de côtes sans côtes (liste des enrôlés)
Documents émis	Fiches de côtes avec côtes
Documents classés	Fiches de côtes avec côtes

Tableau 2.2.11 : Description du poste Enseignant

45

Section 4 : Etudes des documents utilisés

Dans le processus d'informatisation, l'étude des documents permet très souvent de déceler les principales causes du mauvais fonctionnement de la gestion administrative de l'organisation concernée par l'étude

4.1. Recensement des documents

Les documents recensés sont les suivants :

- Fiche de côtes ;

- Relevé de côtes ;

- Reçu ;

- Grille de délibération ;

- PV de délibération.
4.2. Présentation des documents

1. Liste des enrôlés

Rôle : Elle permet à l'enseignant de transcrire des côtes des étudiants. Modèle

Figure 2.2.1 : Modèle d'une fiche des côtes

46

2. Relevé des cotes

Rôle : Il permet à l'étudiant de découvrir ses côtes obtenues pendant les épreuves d'une session donnée.

Modèle

Figure 2.2.2. : Modèle d'un relevé des côtes

47

3. Reçu

Rôle : Il permet à l'étudiant de l'exhiber en cas d'une nécessité. Modèle

Figure 2.2.3.: Modèle d'un reçu de frais

4. Grille de délibération

Rôle : Elle reprend toutes les côtes des étudiants d'une promotion donnée et aide le jury à siéger sur le sort de chaque étudiant.

Modèle

Figure 2.2.4.: Modèle d'une grille de délibération

48

5. PV de délibération

Rôle : Il reprend les noms de tous les étudiants d'une promotion donnée avec leurs mentions. Modèle

Figure 2.2.5.: Modèle d'un PV de délibération

Section 5. Etude des moyens de traitement des informations

Cette étude nous permet d'examiner les différents moyens de traitement des informations qui rentrent dans le processus de la facturation des clients, à savoir :

- Moyens matériels - Moyens humains

- Moyens financiers

49

5.1. Moyens Matériels

Le Secrétariat Général Académique de l'ISC, ainsi que les bureaux dont nous étions passés pour la récolte de données disposent d'une gamme de matériels que nous décrivons de la manière suivante :

N°	Type matériel	Nature	Support d'information	Système d'exploitation	Date d'acquisition	Langage programmation	OBSER
1	Bic	Stylo	-	-	-	-
2	Papier	-	-	-	-	-
3	Calculatrice	-	-	-	-	-
4	Chaise	-	-	-	-	-
5	Classeur	-	-	-	-	-
6	Table	-	-	-	-	-
7	Imprimante	HP	-	-	-	-
8	Ordinateur	IBM	Disk Dur	XP Pack 2	-	-

Tableau 2.2.12 : Liste d'un échantillonnage des matériels recensés

NB : Cette liste des matériels est non exhaustive, raison pour laquelle nous avons présenté qu'un

échantillon de matériels qu'on peut retrouver à l'intérieur des différents bureaux.

5.2. Moyens Humains

Les moyens humains constituent l'ensemble du personnel dont dispose une entité (Ex : ISC Kinshasa) dans le but de réaliser une tâche précise. Il n'est point besoin de rappeler que dans tout système ou organisation, le personnel demeure le plus précieux et le plus important des ressources.

NB : Nous n'avons pu recenser tous les moyens humains de l'ISC, mais sauf qu'on peut tout simplement les chiffrer de la manière ci-après :

- Professeurs Ordinaires	:	11
- Professeurs	:	9
- Professeurs Associés	:	17
- Chefs de Travaux	:	101
- Assistants 1^er Mandant	:	27
- Assistants 2^ème Mandant	:	19
- Bibliothécaire s	:	6
- Administratifs	:

50

5.3. Moyens Financiers

L'institut Supérieur de Commerce de Kinshasa étant un organe éducatif de l'Etat congolais, il a une autonomie dans la gestion des différents frais perçus en son sein. Ces frais permettent à son personnel de bénéficier d'une prime appelée FOCAS en dehors du salaire de base payé par l'Etat congolais et assurent au bon fonctionnement de l'établissement.

Un acteur externe est un élément émetteur ou récepteur de données, situé hors du système d'information étudié.

51

Section 6. Etude de la circulation des informations

Cette étude est très importante, car elle permet d'identifier les tâches informatisables, elle détermine le matériel nécessaire pour chaque poste à informatiser, et plus tard, elle permet de dégager le coût de l'informatisation au regard des moyens à mettre en oeuvre.

De cette étude, nous allons élaborer le diagramme de flux, qui nous aiderait à déceler la complexité de postes, de voir aussi s'il n'y a pas oublié de certaines informations, et de préciser enfin les postes automatisables.

6.1. Diagramme de flux

6.1.1. Définition

Le Diagramme de flux est une représentation graphique des acteurs et des flux

échangés.

Les diagrammes de flux répondent à la question : Que fait le système ? En ce sens, ce sont des modèles FONCTIONNELS (qui décrivent les fonctions)

Il existe 2 principaux types de diagrammes de flux :

? Le modèle de contexte (MC) où le domaine d'étude est vu comme une boite noire. On ne représente que les flux extérieurs au domaine ;

? Le modèle de flux de données (DFD) ou encore modèle de flux conceptuels (MFC) où l'on détaille les activités du domaine d'étude. On représente aussi les flux internes au domaine.

6.1.2. Vocabulaires associés aux modèles flux

A. Domaine d'étude

Le domaine d'étude est un sous-ensemble cohérent de l'entreprise ou de l'organisme, bien délimité et formant le contenu du sujet à étudier.

Dans les modèles de flux, le domaine d'étude est représenté par un rectangle à trait plein. Le nom du domaine est placé à l'intérieur du rectangle.

Domaine d'étude

Figure 2.2.6. : Représentation d'un domaine d'étude

B. Acteur externe

52

Dans les modèles de flux, un acteur externe est représenté par un cercle plein. Le nom de l'acteur est placé à l'intérieur du cercle.

Acteur externe

Figure 2.2.7.: Représentation d'un acteur externe

C. Domaine connexe

Un domaine connexe est un composant du système d'information interagissant avec le domaine d'étude. C'est un acteur interne à l'entreprise, mais externe au domaine d'étude

Dans le modèle de flux, un domaine connexe est représenté par un rectangle (ou un rond). Le nom du domaine connexe est placé à l'intérieur du rectangle.

Domaine connexe

Figure 2.2.8.: Représentation d'un domaine connexe

D. Activité

L'activité est un ensemble de traitements homogènes qui transforment ou manipulent des données. Une activité peut souvent être vue comme un sous-domaine d'étude, un morceau du domaine d'étude.

Chaque activité peut être éclatée. Cet éclatement se traduit alors par l'élaboration d'un nouveau diagramme qui décompose ce processus éclaté en plusieurs processus plus élémentaires.

Activité

Figure 2.2.9.: Représentation d'une activité

E. Flux de données

Un flux est un transfert d'informations entre composants du système. Le composant peut être un domaine, une activité ou un acteur externe.

Dans les modèles de flux, un flux de données est représenté graphiquement par une flèche orientée du composant émetteur du flux vers le composant récepteur. Le libellé du flux est inscrit en regard de la flèche tracée.

53

Flux

Figure 2.2.10.: Représentation d'un flux de données

Figure 2.2.11: Formalisme graphique illustrant un échange entre un acteur externe et le domaine d'étude

6.1.2. Modèle de Flux Conceptuel ou Diagramme de Flux de Données

Ce modèle permet de décider quelles activités, inter-reliées de quelle manière, permettront de résoudre au mieux le problème posé, et cette réflexion est menée sans s'encombrer dans un premier temps du comportement du système (ordonnancement, règles d'émission, synchronisations...).

Les modèles de flux conceptuels permettent de décomposer le domaine d'étude en activités. Il n'y a pas ici de notion d'organisation mais d'objectifs à réaliser. On représente les flux entre activités et avec l'environnement.

? Domaine d'étude

Le domaine d'étude retenu pour ce présent travail est la gestion des activités académiques.

Les acteurs externes

Les acteurs externes recensés pour la présente étude sont les suivants :

- Etudiant

- Enseignant

? Les domaines connexes

Les domaines connexes recensés pour la présente étude sont les suivants :

- Banque

- Secrétaire Général Académique

- Secrétariat de la Section

- Chef de Section

- Chef de département

- Secrétaire du jury

- Président du jury

- Encodeur

- Membres du jury

54

? Les activités

Les activités recensées pour la présente étude sont les suivantes :

- Payement des frais académiques ; - Payement des frais d'enrôlements ; - Gestion des délibérations des étudiants ; - Gestion des relevés des côtes.

55

? Représentation des flux entre activités et avec l'environnement GESTION DES ACTIVITES ACADEMIQUES

Paiement de frais académiques Réception reçu

Payement des
frais

académiques

Liste des étudiants ayant payés les frais académiques

Etudiant

B

Paiement frais d'enrôlement

Réception reçu

B

Perception frais académiques

Etablissement reçu frais acad.

Banque

Etablissement liste des étudiants ayant payés

Réception liste des étudiants ayant payés frais acad.

Secrétaire
Général
Académique

C

Perception frais d'enrôlement

Etablissement reçu frais d'enrôlement

Etablissement liste des étudiants ayant payés frais enr.

Réception liste des étudiants ayant payés frais acad. Publication liste des enrôlés par classe

A

C

A

Payement des
frais

d'enrôlements

D

Liste des enrôlés

Président du jury

Membres du jury

Réception PV et Grille de délibérations

Réception Grilles des côtes

56

D

Gestion des
délibérations
des étudiants

Réception PV et Grilles de délibérations

Réception fiche des côtes et Grille des côtes

Emet PV et Grilles de délibérations

Grilles des délibérations

F

Réception liste des enrôlés

Dispatching liste des enrôlés

Réception PV et Grilles de délibérations

Réception liste des enrôlés

Remise fiche des côtes

B Consultation Grilles de délibérations

Chef département

Chef Section

Secrétaire du jury

Réception PV et Grille de délibérations

C

Enseignant

E

57

F

Gestion des
relevés des
côtes

Secrétariat de la
section

Réception relevé des côtes pour signature

Remise du relevé des côtes

E

Etablissement relevé des côtes

Réception demande et frais relevé

B

Demande relevé et paiement frais

Réception relevé des côtes

Sigles et abréviations

- Acad. : Académique

- PV : Procès-verbal

- Dos : Dossier

- Enr : Enrôlé

X

: Symbole d'une connexion

58

Section 7. Diagnostic de l'existant et recherche de la solution

Le but de cette étape est de donner un diagnostic précis et clair sur les procédures manuelles utilisées, les défauts et les qualités doivent être dégagés. Il est donc question de ne pas tout détruire sous prétexte que de nouvelles solutions seront proposées. Il s'agit d'être objectif pour simplifier des solutions à apporter.

Cette étape permet en outre, d'acquérir une bonne connaissance du domaine impliqué et mettre en évidence les sous-ensembles représentant sur lesquels porte l'analyse préalable.²⁴

7.1. Diagnostic de l'existant

7.1.1. Les points forts du système actuel

Nous devons avouer sincèrement que, d'après notre étude, l'Institut Supérieur de Commerce de Kinshasa a un système de travail assez bien organisé. On y trouve par exemple :

- Du point de vue ressources humaines

Un personnel assez compétent et qualifié qui prône toujours la promotion et la valorisation de ses services en matière d'administration et d'enseignement.

- Du point de vue documents

Les documents utilisés dans différents services sont simplifiés et disponibles. Ces qualités facilitent la transparence dans leur circulation et aussi une collaboration et transmission des informations au niveau du circuit de l'information.

7.1.2. Les points faibles du système actuel

Signalons qu'à côté des qualités évoquées, l'on peut signaler quelques anomalies décelées, par exemple :

- Bien que les informations soient simplifiées et disponibles, le suivi de ces documents est très fatigant à cause du cumul et du volume très élevé des informations ;

- Vu le nombre considérable des étudiants, les autorités de l'Institut Supérieur de Commerce de Kinshasa sont confrontés à d'énormes difficultés du point de moindre capacité d'accueil ;

- Il y a une lenteur dans le traitement des informations suite au remplissage manuel des certains documents ;

- Une lenteur excessive dans la transmission de côtes par les enseignants, dans l'encodage

des côtes par les encodeurs, dans la livraison des relevés des côtes par les sections ;

²⁴ DIONSI DOMINIQUE, l'essentiel sur merise, Ed. Eyrolles, Paris 1995, p.25

59

- Un engouement dans des banques pour paiement des différents frais ;

- Difficultés de faire parvenir l'information à l'étudiant et à la hiérarchie, etc. 7. 2. Recherche des solutions

Pour remédier aux insuffisances constatées dans la critique objective du système actuel que nous venons d'émettre, nous procédons ainsi, à proposer quelques pistes de solutions appropriées d'abord pour la gestion des activités académiques ensuite, pour l'ensemble de l'organisation répondant désormais, aux besoins de ces dernières.

7.2.1. Ebauche des solutions

Dans ce point, nous suggérons deux scénarios, notamment :

- Scénario de réorganisation ; - Scénario d'informatisation.

? Scénario de réorganisation

Suite à nos investigations effectuées au sein de l'Institut Supérieur de Commerce de Kinshasa et en rapport avec la critique de ce dernier, pour améliorer la gestion des activités académiques, nous proposons aux autorités de mettre l'accent sur les points suivants:

- Recycler les agents à l'utilisation de la technologie de l'information et de la

communication ;

- Améliorer les primes ou salaires des agents ;

- Aménager les bureaux des agents administratifs et enseignants ;

- Doter ces bureaux avec des matériels didactyles appropriés, etc.

1. Avantages

- Maitrise du processus organisationnel du système actuel (existant) ;

- Moindres coûts, et l'on conserve des données en toute sécurité en cas de coupure brusque d'électricité ou de panne de l'ordinateur, etc.

2. Inconvénients

La solution de réorganisation (manuelle) entraine aussi des inconvénients tels que :

- Difficultés de se procurer des informations fiables ;

- Le système accuse une lourdeur, beaucoup d'erreurs dans le calcul et une perte de temps exagérée dans la vérification des certains documents, etc.

60

? Scénario d'informatisation

Depuis la genèse du présent travail, nous avons cessé de répondre à l'objectif principal qui n'est rien autre que l'automatisation du système manuel, c'est-à-dire mettre en place un système d'information capable de gérer automatiquement les activités académiques dont il est question ici. Ce système tournera en ligne (sur l'Internet) pour une bonne rentabilité de l'entreprise.

1. Cahier des charges

C'est un document de synthèse des études préalables. Il doit à la fois fournir aux

constructeurs les informations nécessaires et lui indiquer les problèmes que les propositions de matériels devront résoudre.²⁵

Ainsi, pour répondre impérativement à l'attente des autorités de l'Institut Supérieur de Commerce de Kinshasa, nous présentons les points phares de notre Cahier des Charges de la manière ci-après :

- Les besoins des utilisateurs ; - Le langage de modélisation ; - L'environnement de travail ; - Les matériels ;

- Les logiciels, etc.

NB : Pour plus de détail sur le cahier des charges, certains éléments sont présentés de façon claire dans le point « présentation du projet » de ce présent travail.

2. Avantages

- Fiabilité dans le traitement des certaines informations ;

- Rapidité dans le traitement des informations ;

- Bonne conservation des données sur différents supports : DVD, CD, CLE USB, Disque

Dur, etc. ;

- Mise à jour et production des documents rapides ;

- Disponibilité de l'information 24h sur 24, etc.

3. Inconvénients

- Suppression de certains postes et de certains emplois, ceci entraine le chômage sur le plan social ;

- Coût très élevé pour l'engagement des informaticiens et pour l'achat des ordinateurs et aussi pour leur entretien ;

- Facturation très élevée de l'électricité, etc.

²⁵ P.A. Pounet, Le Lancement du système d'informatique de gestion, Dunod économie, 1969, P. 48

61

7.2.2. Choix de la meilleure solution

Partant des avantages qu'offre chacune des solutions citées ci-haut, nous proposons aux autorités de l'Institut Supérieur de Commerce de Kinshasa d'opter pour la solution d'informatisation, car elle va maximiser ses recettes et permettra une gestion optimale des activités académiques.

Nous voici à la fin de notre prospection sur le système existant, nous ne pouvons pas prétendre avoir donné tout le remède aux anomalies constatées, mais nous croyons avoir apporté notre contribution dans la gestion future des activités académiques de l'Institut Supérieur de Commerce de Kinshasa.

62

Section 8 : Présentation du projet

Dans cette section, nous présentons de façon plus claire des besoins recensés auprès des autorités académiques lors de notre investigation, nos propositions pour un meilleur rendement, ainsi que les moyens permettant d'aboutir aux résultats attendus par ces dernières.

8.1. Grands choix techniques

Pour pallier aux risques qu'égorge le système manuel de la gestion des activités académiques, nous avons opté pour une approche itérative et incrémentale, basée sur le processus Two Tracks Unified Process (2TUP) Y.

Dans le souci de répondre impérativement aux attentes des autorités académiques et d'amener l'Institut Supérieur de Commerce de Kinshasa dans l'évolution de la Technologie de l'Information et de la Communication, nous leurs proposons des technologies ci-après :

V' Langage de modélisation : UML 2 (Unified Modeling Language);

V' Outil de modélisation : PowerAMC 15 et ArgoUML ;

V' Architecture réseau : Les architectures 3-tiers;

V' Mode de communication ou connexion : Internet;

V' Langages de programmation : Php 5, Javascript, XHTML 5, CSS 3, Etc.

V' Serveur Web : Apache version 2.2.17 ;

V' SGBD : MySQL version 5.5.8 ;

V' Navigateurs compatibles : Internet Explorer 10, Google Chrome,

Opera Mini, Mozilla.

8.2. Spécification des besoins fonctionnels

Partant de notre entretien avec les autorités académiques de l'institut au sujet des activités académiques, nous élaborons notre cahier de charges préliminaires de la manière ci-après :

1. Enregistrement des étudiants ayant

payés les frais d'enrôlements

Concernant l'enregistrement des étudiants ayant payés les frais d'enrôlements, les besoins se présentent comme suit :

- La possibilité de gérer l'enrôlement de la mi- session, 1^ère session et 2^ème session;

- Informer l'étudiant de la validation du payement des frais d'enrôlements dans les heures qui suivent son versement par e-mail ou par SMS;

- Fournir la situation journalière des frais d'enrôlements perçus par la banque.

63

2. Délibération des étudiants Les besoins fonctionnels en délibération des étudiants se présentent comme suit :

- Les enseignants recevrons des fichiers Excel en provenance du Secrétariat Général

Académiques reprenant les noms des enrôlés par e-mail ;

- Les enseignants doivent joindre au système les fichiers Excel après l'avoir rempli avec

des côtes ;

- Le secrétaire du jury peut délibérer en compagnie des membres du jury un étudiant c'est-

à-dire, il peut modifier ou compléter une cote en cas d'une nécessité ;

- Possibilité de faire des péréquations des grilles de délibérations ;

- Possibilité d'imprimer ou d'afficher la grille de délibération d'un étudiant ;

- Gérer la 1^ère et 2^ème session des délibérations.

3. Obtention des relevés des côtes

Pour l'obtention des relevés des côtes, les besoins fonctionnels sont reformulés de la manière suivante :

- Possibilité de payer par la voix électronique le frais des relevés des côtes, après payement, le système doit fournir un numéro permettant au concerné d'imprimer son relevé des côtes ;

- Sécuriser la signature numérique de la section.

8.3. Spécification des besoins opérationnels

Par rapport aux besoins opérationnels de l'application, nous mettons plus l'accent sur la sécurité, car sans elle, l'application risquerait de tomber caduque lors de son déploiement sur l'Internet.

Sécurité

Pour mieux sécuriser notre application, nous présentons les mécanismes de sécurité

suivants :

- Chaque machine connectée au système doit être vue par l'administrateur système ;

- Accès au système est conditionné par un Username et Password ;

- L'administrateur système peut déconnecter une machine connectée au système quand il

veut ;

- Un administrateur système est chargé de définir les profils des utilisateurs.

Nous ne pouvons jamais nier les attaques qu'on peut retrouver sur l'Internet. Mais, il est à signaler qu'il existe aussi des mécanismes de sécurité pour se préserver aux attaques des hackers. Pour conclure, il n'y a pas une sécurité à 100% sur l'Internet.

64

8.4. Spécification des besoins non fonctionnels Exigences de qualité

Pour donner satisfaction aux Users qui fréquentent le module de l'application déployé à leur égard, et les rendre fidèles à ce dernier, il est important de répondre aux exigences de qualité suivantes :

? Ergonomie sobre et efficace connaitre

la situation des inscriptions, imprimer une grille de délibération et acheter le relevé des côtes sur le Web ne doivent pas prendre beaucoup de temps ou demander une maîtrise de mathématiques! La mise en page du module déployé facilitera au maximum la démarche à l'aide d'une présentation claire et intuitive. Les modules d'application trop riches et trop complexes n'incitent pas les Users, car ils demandent un effort intellectuel important et non souhaité.

? Formulaire de saisie simple Très
souvent, les Users rencontrent des difficultés au moment de remplissage des différents formulaires, car l'effort le plus important à fournir est le renseignement de ces derniers! La conception et la présentation de ceux-ci seront donc particulièrement soignées pour ne pas rebuter les Users.

? Aide en ligne puissante. À tout
moment, les Users peuvent consulter des pages d'aide contextuelle, ainsi que lancer une recherche dans l'ensemble des pages d'aide.

65

IIIème Partie : Phase de la conception du Nouveau

Système d'information

La conception du système d'information n'est pas évidente car il faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception nécessite des méthodes permettant de mettre en place un modèle sur lequel on va s'appuyer. Il s'agit donc de valider chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant reliées au traitement, il faut vérifier la concordance entre les données et le traitement afin de s'assurer que toutes les données nécessaires au traitement sont présentées et qu'il n'y a pas de données superflues, raison pour laquelle, nous avons opté pour le processus 2TUP du Processus unifié.

66

Chapitre I : Capture initiale des besoins

Ce chapitre va nous servir à poser les bases de la capture des besoins du système à réaliser. Et il consiste à effectuer un premier repérage des besoins fonctionnels et opérationnels, en utilisant principalement le texte, ou des diagrammes très simples.

1.1. Identification des acteurs du système

Les acteurs humains pour ce projet sont les suivants :

V' Etudiant (Internaute)

L'étudiant est appelé à effectuer des tâches suivantes :

u Payer le frais d'enrôlement ;

u Consulter et imprimer le résultat de délibération ;

u Obtenir le relevé des côtes en formulant une demande en amont.

V' Enseignant

L'enseignant a pour tâches :

u Recevoir la liste des enrôlés par email ;

u Remplir les fiches des côtes des étudiants ;

u Modifier son mot de passe ;

u Envoyer les fiches des côtes des étudiants via le système.

V' Secrétaire Général Académique

Le Secrétaire Général Académique a pour rôles :

u Entrer les noms des étudiants ayant payés les frais enrôlements dans le système ;

u Publier la liste des enrôles ;

u Envoyer par email la liste des enrôles aux enseignants ;

u Créer, modifier et supprimer le profil des secrétaires et présidents des jurys ;

u Modifier son mot de passe ;

u Consulter les différents rapports que fournis le système.

V' Chef de section

Le chef de section a comme rôle :

u Consulter et annuler toutes les demandes de relevé des côtes ;

u Approuver toute demande de relevé des côtes ;

u Modifier son mot de passe ;

u Consulter les résultats des délibérations des étudiants de sa section.

67

V' Secrétaire du jury

Le secrétaire du jury a comme tâches :

u Mettre à jour la grille de délibération ;

u Modifier son mot de passe ;

u Imprimer les grilles et PV de délibération.

V' Administrateur système

L'administrateur système a comme rôles :

u Mettre à jour quelques informations du système (annonces, etc.) ; u Créer, modifier et supprimer les profils des usagers (Enseignant, etc.) u Maintenir le système en cas de pannes ; u Faire des backups à la fin de la journée.

68

1.2. Identification des messages

1.2.1. Liste des messages que le système envoi aux acteurs

Le système permettra de transmettre aux acteurs du système les éléments ci-

après :

u La liste des enrôlés sous la forme d'une fiche des côtes ;

u La grille des côtes calculée et péréquée ; u Le PV de délibération ; u Le relevé des côtes, etc.

1.2.2. Liste des messages que les acteurs envoient au système

Les acteurs vont transmettre au système les éléments ci-après :

u La liste des étudiants ayant payés le frais d'enrôlement ;

u La fiche des côtes ;

u Les informations relatives à la création, modification et suppression des profils usagers ; u Les informations relatives à l'authentification ;

u Les informations concernant la demande et à l'annulation d'une demande d'un relevé des côtes, etc.

69

1.3. Diagramme de contexte

1.3.1. Diagramme de contexte dynamique

« Actor »

Figure 3.1.1.: Présentation du digramme de contexte dynamique

Figure 3.1.2.: Symboles utilisés

1.3.2. Diagramme de contexte statique

0..1 0..1

0..1

0..1

0..1 0..1

70

Figure 3.1.3.: Présentions du diagramme de contexte statique

Chaque type d'acteur est le seul et l'unique à accéder au système pour visualiser les informations émises par le système lui concernant.

71

Chapitre II : Capture des besoins fonctionnels

Ce chapitre va nous permettre de préciser l'étude du contexte fonctionnel du système, en décrivant les différentes façons qu'auront les acteurs d'utiliser le futur système.

2.1. Diagramme de cas d'utilisation

Un cas d'utilisation (use case) représente un ensemble de séquences d'actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier. Un cas d'utilisation modélise un service rendu par le système²⁶. Il exprime les interactions acteurs/système et apporte une valeur ajoutée « notable » à l'acteur concerné.

2.1.1. Identification des cas d'utilisation

Les cas d'utilisation identifiés sont les suivants :

- S'authentifier ;

- Enregistrer les étudiants ayant payés les frais ;

- Envoyer les listes des enrôlés aux enseignants ;

- Remettre les fiches des côtes ;

- Délibération des étudiants ;

- Obtention relevé des côtes ;

- Gestion des profils usagers.

2.1.2. Réalisation de Diagramme de cas d'utilisation

On obtient sans difficulté un diagramme préliminaire en transcrivant la réponse précédente sur un schéma qui montre les cas d'utilisation (ovales) reliés par des associations (lignes) à leurs acteurs principaux (icône du « stick man »).

²⁶ Pascal Roques, Modéliser une application Web 4^ème Edition, Ed. EYROLLES, Paris, 2006, p 42.

72

Figure 3.2.1.: Présentation du diagramme de cas d'utilisation

73

2.1.3. Fiche de description des cas d'utilisation

u Enregistrer les étudiants ayant payés le frais

Sommaire d'identification

Titre: Enregistrement des étudiants ayant payés les frais d'enrôlements

But : Permettre aux autorités d'avoir l'effectivité des étudiants en ordre avec les frais d'enrôlements.

Résumé : Ce cas d'utilisation permet d'ajouter dans le système les étudiants ayant payés les frais d'enrôlement.

Acteur : Secrétaire Général Académique (principal)

Date de création : Périodique Date de mise à jour : N/A

Version : N/A

Responsable : Secrétaire Général Académique

Description des enchaînements

Pré conditions:

y' Le Secrétaire Général Académique doit s'authentifier au système c'est-à-dire doit entrer le Username et le Password.

y' La liste des étudiants ayant payés les frais d'enrôlements doit être dressée sous Excel 2007 ou 2010.

y' Le SGA ou son Cabinet doit avoir une bonne connaissance d'Excel précisément dans l'élaboration des différents tableaux.

Enchaînements :

L'élément déclencheur du cas d'utilisation fonctionnel est lorsque l'étudiant paye le frais d'enrôlement, le Secrétaire Général Académique procédera par l'enregistrement de ces informations dans le système.

Enchaînement (a) Enregistrer les étudiants ayant payés les frais d'enrôlements

(Secrétaire Général Académique)

Le SGA doit disposer d'un fichier électronique au format Excel contenant les informations (Noms, Post-nom, Prénom, Date du payement, Session) des étudiants ayant payés les frais d'enrôlements pour pouvoir les enregistrer. L'enregistrement se fait par la jointure du fichier dans le système.

74

Si l'enregistrement non OK

Enchaînement (e)

Reprendre l'opération sur l'enregistrement des étudiants ayant payés les frais d'enrôlements (Secrétaire Général Académique)

Cet enchaînement supprime toutes les données sauvegardées 10 minutes avant, pour reprendre l'enregistrement.

Enchaînement (f) Fermer l'enregistrement Frais enrôlement (Secrétaire Général

Académique)

Ce cas d'utilisation se termine lorsque :

V' L'enregistrement des étudiants ayant payés les frais d'enrôlements est effectué avec succès.

V' L'enregistrement des étudiants ayant payés les frais d'enrôlements est repris et effectué avec succès.

V' L'enregistrement Frais d'enrôlements est fermé et effectué. V' L'enregistrement Frais Académique est fermé et effectué. Exceptions :

[Exception 1 : Absence de l'électricité et de la connexion internet]

Post-conditions :

V'

75

? Envoyer les listes des enrôlés aux enseignants

Sommaire d'identification

Titre: Envoi des listes des enrôlés aux enseignants

But : Permettre aux enseignants de se procurer des listes faisant office des fiches de cotation, pour pouvoir les remplir et les remettre plus tard.

Résumé : Ce cas d'utilisation permet d'envoyer aux enseignants par email des listes des enrôlés en provenance du système.

Acteur : Secrétaire Général Académique (principal) et Enseignant (secondaire)

Date de création : Périodique Date de mise à jour : N/A

Version : N/A

Responsable : Secrétaire Général Académique

Description des enchaînements

Préconditions:

Le Secrétaire Général Académique doit s'authentifier au système c'est-à-dire doit entrer le Username et le Password. Les enseignants doivent préalablement exister dans le système pour pouvoir recevoir ces listes

Enchaînements :

L'élément déclencheur du cas d'utilisation fonctionnel est lorsque la session prend fin, le Secrétaire Général Académique procédera par l'envoi des listes des enrôlés aux enseignants.

Enchaînement (a) Envoyer les listes des enrôlés aux enseignants (Secrétaire Général Académique)

Le SGA doit simplement sélectionner la classe et exécuter ce module, c'est alors que le système regroupera par classe les enrôlés et les enseignants qui y enseignent et produira une liste au format Excel qui sera envoyer à ces enseignants.

Si l'envoi non OK

Enchaînement (b) Reprendre l'opération sur l'Envoi des listes des enrôlés aux

enseignants (Secrétaire Général Académique)

76

Cet enchaînement supprime toutes les données sauvegardées 10 minutes avant, pour reprendre l'envoi.

Enchaînement (c) Annuler l'envoi des listes des enrôlés (Secrétaire Général

Académique)

Enchaînement (d) Fermer l'envoi des listes des enrôlés (Secrétaire Général

Académique)

Ce cas d'utilisation se termine lorsque :

y' L'envoi des listes est effectué avec succès. y' L'envoi des listes est repris et effectué. y' L'envoi des listes est annulé et effectué. y' L'envoi des listes est fermé et effectué.

Exceptions :

[Exception 1 : Absence de l'électricité et de la connexion internet]

Post-conditions :

77

? Remettre la fiche des côtes

Sommaire d'identification

Titre: Remise des fiches des côtes

But : Permettre aux enseignants de remettre les fiches des côtes en les joignant au système.

Résumé : Ce cas d'utilisation permet d'introduire des côtes des étudiants dans le système par les enseignants.

Acteur : Enseignant (principal)

Date de création : Périodique Date de mise à jour : N/A

Version : N/A

Responsable : Enseignant

Description des enchaînements

Préconditions:

L'Enseignant doit s'authentifier au système c'est-à-dire doit entrer le Username et le Password. Et enfin avoir le fichier contenant les côtes au format Excel.

Enchaînements :

L'élément déclencheur du cas d'utilisation fonctionnel est lorsque la délibération s'annonce, l'enseignant est appelé à remettre la fiche de côtes en le joignant au système.

Enchaînement (a) Remise de la fiche des côtes (Enseignant)

L'Enseignant doit d'abord joindre le fichier à l'application et exécuter ce module. C'est alors que le système va extraire les données se trouvant dans le fichier, les comparer aux données du système et copiera enfin les côtes dans le système.

Si la remise non OK

Enchaînement (b) Reprendre l'opération sur la remise des côtes (Enseignant)

Cet enchaînement supprime toutes les données sauvegardées 10 minutes avant, pour reprendre l'envoi.

78

Enchaînement (c) Annuler le processus de la remise des côtes (Enseignant)

Enchaînement (d) Fermer le processus de la remise des côtes (Enseignant)

Ce cas d'utilisation se termine lorsque :

y' La copie des côtes est effectuée avec succès. y' La copie des côtes est reprise et effectuée. y' La copie des côtes est annulée et effectuée. y' La copie des côtes est fermée et effectuée. y' Le rapport de la remise des côtes est établi.

Exceptions :

[Exception 1 : Absence de l'électricité et de la connexion internet]

Post-conditions :

u Délibération des étudiants

Sommaire d'identification
Titre: Délibération des étudiants But : Permettre aux secrétaires des jurys de délibérer les étudiants, publier les résultats et imprimer les grilles des délibérations. Résumé : Ce cas d'utilisation permet de visualiser les côtes envoyées par les enseignants, délibérer les étudiants et publier les résultats des délibérations. Acteur : Secrétaire du jury (principal) Date de création : Périodique Date de mise à jour : N/A Version : N/A Responsable : Secrétaire du jury
Description des enchaînements
Pré conditions: Le secrétaire du jury doit s'authentifier au système Username et le Password.	c'est-à-dire doit entrer le

79

Enchaînements :

L'élément déclencheur du cas d'utilisation fonctionnel est lorsque les côtes sont envoyées pour la délibération, le secrétaire du jury est appelé à les imprimer sous forme des grilles des côtes sans décision.

Enchaînement (a) Imprimer la grille des côtes (Secrétaire du Jury)

Le secrétaire du jury n'a qu'à sélectionner sa classe et lancer l'impression des grilles des côtes.

Enchaînement (b) Annuler l'impression de la grille des côtes (Secrétaire du

Jury)

Enchaînement (c) Définir les critères de délibération (Secrétaire du Jury)

Enchaînement (d) Effectuer la péréquation des côtes (Secrétaire du Jury)

Enchaînement (e) Imprimer la grille délibération (Secrétaire du Jury)

Enchaînement (f) Publication des résultats de délibération (Secrétaire du jury)

Enchaînement (g) Annuler l'impression de la grille de délibération (Secrétaire

du Jury)

Enchaînement (h) Imprimer PV

Enchaînement (g) Fermer le processus de délibération (Secrétaire du Jury)

Ce cas d'utilisation se termine lorsque :

y' La grille des côtes est imprimée avec succès.

y' Les côtes des étudiants sont péréquée avec succès.

y' La grille des côtes est annulée et effectuée.

y' La délibération des étudiants est fermée et effectuée.

Exceptions :

[Exception 1 : Absence de l'électricité et de la connexion internet]

Post-conditions :

80

? Obtention de relevé des côtes

Sommaire d'identification

Titre: Obtention de relevé des côtes

But : Permettre à l'étudiant de formuler une demande de relevé des côtes et d'en imprimer.

Résumé : Ce cas d'utilisation permet au système de recevoir les demandes de relevés des côtes, les traiter et les approuver par le chef de section.

Acteurs : Chef de section (principal), Etudiant

Date de création : Périodique Date de mise à jour : N/A

Version : N/A

Responsable : Chef de section

Description des enchaînements

Préconditions:

Le chef de section et l'internaute (ou étudiant) doivent s'authentifier au système c'est-à-dire doivent entrer le Username et le Password. L'étudiant doit préalablement payer le frais de relevé des côtes, soit par la voix électronique ou à la caisse de la section et un numéro d'identification lui sera donné.

Enchaînements :

L'élément déclencheur du cas d'utilisation fonctionnel est lorsque l'étudiant formule sa demande de relevé des côtes, elle sera approuvée par le chef de section, traitée par le système et imprimée par lui-même étudiant (ou internaute).

Enchaînement (a) Formuler la demande de relevé des côtes et envoyer (Etudiant)

L'étudiant doit se connecter à un compte créé par lui-même, lancer le formulaire de demande de relevé des côtes et le remplir avec les informations telles que : N° d'identification, Nom, Post nom, Année Académique, Promotion, Session (1^ère ou 2^ème) et Adresse E-mail.

Si demande non OK

Enchaînement (b) Reprendre l'opération de la demande de relevé des côtes

81

(Etudiant)

Annuler l'opération de la demande de relevé des côtes

Enchaînement (c) (Etudiant)

Enchaînement (d) Lister les demandes de relevés (Chef de section)

Enchaînement (e) Approuver les demandes de relevés des côtes (Chef de Section)

Enchaînement (f) Envoyer le relevé des côtes à l'étudiant (Chef de section)

Enchaînement (g) Imprimer le relevé des côtes (Chef de section)

Ce cas d'utilisation se termine lorsque :

y' La demande de relevé des côtes est effectuée avec succès.

y' La demande de relevé des côtes est approuvée et traitée avec succès. y' Le relevé des côtes est imprimé avec succès.

Exceptions :

Néant

Post-conditions :

Néant

82

q Gestion des profils d'usagers

Sommaire d'identification

Titre: Gestion des profils d'usagers

But : Accorder l'accès aux usagers à différentes fonctionnalités du système.

Résumé : Accorder un mot de passe ainsi qu'un nom d'usager à chaque acteur du système.

Acteurs : Administrateur du système (principal)

Date de création : Indéterminé

Date de mise à jour : N/A

Version : N/A

Responsable : Indéterminé

Description des enchaînements

Préconditions:

ü S'authentifier

ü Embauche d'un employé

ü Remplacement (Backup) d'un employé

ü Nouvelle fonctionnalité du système

ü L'administrateur du système est authentifié

Enchaînements :

L'élément déclencheur du cas d'utilisation fonctionnel est lorsque l'administrateur du système désire créer, modifier ou supprimer un profil d'usager.

Enchaînement (a) Créer un nouvel usager

L'administrateur du système accorde les accès aux différentes fonctionnalités, le nom d'usager et le mot de passe à l'usager du système.

Enchaînement (c) CréerModifier un un nouvel profil usagerusager

L'administrateur du système ajoute ou retire des accès à l'utilisateur. Il peut aussi modifier le mot de passe de l'usager.

Enchaînement (c) Supprimer un profil usager L'administrateur du système supprime l'accès à l'usager.

83

Ce cas d'utilisation se termine lorsque :

V' Le profil est créé et enregistré;

V' Le profil est modifié et enregistré; V' Le profil est supprimé et enregistré. Exceptions :

Néant.

Post-conditions :

Néant.

84

2.2. Diagramme dynamique

? Diagramme d'activité « Envoyer les listes des enrôlés aux enseignants »

Figure 3.2.3.: Diagramme d'activité Envoyer les listes ...

La première étape de l'opération Envoyer les listes des enrôlés aux enseignants est la sélection de la classe des étudiants. Ensuite, on a différentes possibilités, telles que : Envoyer les listes des enrôlés, la reprendre, l'annuler ou la fermer. Finalement, la requête est exécutée et les données sont sauvegardées.

85

? Diagramme d'activité « Remettre les fiches des côtes »

Figure 3.2.4.: Diagramme d'activité Remettre les fiches ...

La première étape de l'opération Remettre les fiches des côtes est la jointure du fichier contenant les côtes des étudiants au système. Ensuite, on a différentes possibilités, telles que : Remettre la fiche des côtes, la reprendre, l'annuler ou la fermer. Finalement, la requête est exécutée et les données sont sauvegardées.

86

? Diagramme d'activité « Délibération des étudiants »

Figure 3.2.5.: Diagramme d'activité Délibération des étudiants ...

La première étape de l'opération Délibération des étudiants est la vérification des côtes remises c'est-à-dire voir si toutes les côtes sont prêtes pour la délibération. Ensuite, on a différentes

possibilités, telles que : Afficher Grille avant délibération, la fermer ou Situation délibération.

Quelques possibilités ont leurs sous actions à savoir : Afficher Grille avant délibération (Imprimer Grille, Définir les critères de délibération, Péréquation des côtes, Annuler l'impression grille des côtes ou Publication des résultats de délibération) et Situation délibération (Imprimer PV ou Afficher statistique délibération)

87

? Diagramme d'activité « Obtention relevé des côtes »

Figure 3.2.6.: Diagramme d'activité Obtention relevé ...

88

? Diagramme d'activité « Gestion des profils d'usagers »

Figure 3.2.7.: Diagramme d'activité Gestion profil d'usagers

Le diagramme dynamique du profil d'usager débute par une demande des critères où l'on affiche la liste des usagers. La seconde étape est soit : la création d'un usager, la modification d'usager ou la suppression d'un usager. Il se termine encore une fois par l'exécution de la requête et la sauvegarde des données en questions.

89

2.3. Package de spécification fonctionnelle

Figure 3.2.8.: Package de spécification fonctionnelle

Cas d'utilisation	Acteurs	Package
Enregistrer les étudiants ayant payés le frais	Secrétaire Général Académique	Délibérations des étudiants
Envoyer les listes des enrôlés aux enseignants	Secrétaire Général Académique
Remettre les fiches des côtes	Enseignant
Délibération des étudiants	Secrétaire du Jury
Obtention des relevés des côtes	Etudiant	Gestion relevés des côtes
	Chef de section
Gestion des profils d'usagers	Administrateur du système	Gestion des profils d'usagers

1

Classe

Peuvent Appartenir 1..*

Secrétaire Gén. Acad.

1..*

Gère

1..*

Enregistrer

Section

Fichier_Frais

1

Concerne

Etudiant

1

1

Appartient

Département

1

1..*

90

II.4. Diagramme de classe

y' Tableau descriptif de diagramme de classe « Enregistrer les étudiants ayant payés les frais »

N°	Association	Classes d'objets		Multiplicités		Règles de gestion
		Source	Cible	Source	Cible
1	Enregistrer	Profil_Usager (SGA)	Fichier_Frais	1	1..*	SGA enregistre un ou plusieurs fichiers frais
2	Appartenir	Classe	Etudiant	1	1..*	Un ou plusieurs étudiants peuvent appartenir à une seule classe
3	Appartenir	Département	Etudiant	1	1	Un étudiant appartient à un et un seul département
4	Gérer	Section	Département	1	1..*	Une section gère un ou plusieurs départements
5	Concerner	Etudiant	Fichier_Frais	1	1..*	Fichier_Frais concerne un ou plusieurs étudiants

y' Diagramme de classe « Enregistrer les étudiants ayant payés le frais »

91

y' Tableau descriptif de diagramme de classe «Envoyer les listes des enrôlés aux enseignants »

N°	Association	Classes d'objets		Multiplicités		Règles de gestion
		Source	Cible	Source	Cible
1	Enregistrer	Profil_Usager (SGA)	Fiche_Cote	1	1..*	SGA envoi une ou plusieurs fiches des côtes
2	Etre Repris	Cours	Fiche_Cote	1	1	Dans une fiche côte est repris un et un seul cours
3	Appartenir	Section	Cours	1	1	Les cours appartiennent au moins une section
4	Recevoir	Profil_Usager (Enseignant)	Fiche_Cote	1	1..*	Un Enseignant reçoit une ou plusieurs fiches des côtes
5	Etre	Enseignant	Cours	1	1..*	Un enseignant est titulaire d'un ou plusieurs cours
6	Provenir	Fichier_Frais	Fiche_Cote	1	1	Une fiche des côtes provient d'un et un seul fichier frais

y' Diagramme de classe « Envoyer les listes des enrôlés aux enseignants »

Secrétaire Gén. Acad.

1 1..* Envoi

Fiche_Cote

1

Cours

1 Est repris

1..*

Reçois

1..*			Section
	Appartient	1		1

1..* 1

Est titulaire

Enseignant

1

FichierFrais

		Provient
	1

y' Tableau descriptif de diagramme de classe «Remettre les fiches des côtes »

N°	Association	Classes d'objets		Multiplicités		Règles de gestion
		Source	Cible	Source	Cible
1	Remettre	Profil_Usager (Enseignant)	Fiche_Cote	1	1..*	Un enseignant remet une ou plusieurs fiches des côtes
2	Etre Repris	Cours	Fiche_Cote	1	1	Dans une fiche côte est repris un et un seul cours
3	Appartenir	Section	Cours	1	1	Les cours appartiennent au moins une section
4	Etre	Enseignant	Cours	1	1..*	Un enseignant est titulaire d'un ou plusieurs cours

92

y' Diagramme de classe « Remettre les fiches des côtes »

Enseignant

1

Est titulaire

1 1..*

Remet

Section

1

Appartiennent

Fiche Côte

1..*

1..*

1..*

Est repris

Cours

1

Secrétaire du jury

Fiche_Cote

Contrôle

1 1

Modifie

Publie

1

Est repris

Grille_Cote

1

y' Tableau descriptif de diagramme de classe «Délibération des étudiants»

N°	Association	Classes d'objets		Multiplicités		Règles de gestion
		Source	Cible	Source	Cible
1	Contrôler	Profil_Usager (Sec. Jury)	Grille_Cote	1	1..*	Un Sec. Du jury contrôle au moins une grille des côtes
2	Etre Repris	Grille_Cote	Fiche_Cote	1	1	Une fiche des côtes est reprise une et une seule fois dans une grille des côtes

? Diagramme de classe « Délibération des étudiants»

93

? Tableau descriptif de diagramme de classe «Obtention des relevés des côtes»

N°	Association	Classes d'objets		Multiplicités		Règles de gestion
		Source	Cible	Source	Cible
1	Formuler	Profil_Usager (Etudiant)	Demande	1	1..*	Un étudiant formule une ou plusieurs demandes
2	Bénéficier	Profil_Usager (Etudiant)	Relevé des côtes	1	1..*	Un étudiant bénéficie d'un ou plusieurs relevés des côtes
3	Etablir	Profil_Usager (Chef Section)	Relevé des côtes	1	1..*	Le chef de section établi un ou plusieurs relevés des côtes
4	Provenir	Grille_Cote	Releve_Cote	1	1	Un relevé des côtes provient d'une et une seule grille des côtes cours
5	Approuver	Profil_Usager (Chef Section)	Demande	1	1..*	Le chef de section approuve une ou plusieurs demandes

? Diagramme de classe « Obtention des relevés des côtes »

Etudiant

Établi

1

Chef de Section

1 1..*

1..*

Est repris

Demande

1..*

1

Classe

Formule

1

Bénéficie

1..*

1..*

Releve_Cote

1

Provient

1

Grille_Cote

1

Approuve

94

? Diagramme de classe « Profils d'usager »

Utilisateur

1 Possède

1

Profil d'usager

1 1 Possède

Username

Crée Modifie Supprimer

1..*

Administrateur Système

1

1

1 1 Possède

Password

Permet

1

1

1 1 1 1

DroitEnregistrer
les étudiants ayant
payés les frais

DroitEnvoyer les
listes des enrôlés
aux enseignants

DroitRemettre
les fiches des
côtes

DroitDélibé
rer les
étudiants

DroitObtenir
le relevé des
côtes

DroitDéfinir les
profils d'usager

Crée Crée Crée Crée

Modifie Modifie Modifie Modifie

Supprimer Supprimer Supprimer Supprimer

1..* 1..* 1..* 1..*

Section

Classe

Cours

Département

Le diagramme de classe « Profil d'usager ». Dans ce diagramme, on peut observer que l'utilisateur possède un profil d'usager et que ce profil possède un nom d'usager et un mot de passe. Également, ce profil d'usager permet à l'utilisateur d'avoir différents droits dans l'application (enregistrer les étudiants ayant payés les frais, envoyer les listes des enrôlés aux enseignants, profil d'usager, etc.). Finalement, l'administrateur du système, en plus d'être un utilisateur, peut aussi créer, modifier et supprimer un ou plusieurs profils d'usagers.

95

2.5. Diagramme de cas d'utilisation affinés

? Diagramme de cas d'utilisation affiné : «Délibérations des étudiants»

Figure 3.2.9.: Diagramme de classe affiné Délibération des étudiants

? Diagramme de cas d'utilisation affiné : «Gestion relevés des côtes»

Figure 3.2.10.: Diagramme de classe affiné Gestion relevés des côtes

96

? Diagramme de cas d'utilisation affiné : «Gestion des profils d'usagers»

Figure 3.2.11.: Diagramme de classe affiné Gestion des profils d'usagers

Les diagrammes de cas d'utilisations affinées montrent qu'il y a certaines relations entre les différents cas d'utilisations. En effet, certains cas peuvent être regroupés ensemble pour aider à mieux comprendre le fonctionnement du système. Par exemple, L'enregistrement des étudiants ayant payés le frais, Envoi des listes des enrôlés aux enseignants, la remise des fiches des côtes et la délibération des étudiants interagissent entre eux, donc peuvent être regroupés. On observe même des relations dites « extend » entre ces différents cas. Cette relation explique que le cas de base (ex : Enregistrer des étudiants ayant payés le frais) incorpore implicitement un autre cas (ex : Envoyer les listes des enrôlés aux enseignants). Le cas de base peut fonctionner tout seul, mais il peut également être complété par un cas d'extension. Finalement, les autres cas n'ont pas de points en communs, donc ne peuvent être regroupés ensemble.

97

Chapitre III : Capture des besoins techniques

Dans ce chapitre nous abordons comment le concept de cas d'utilisation peut être étendu pour répondre à ce besoin, et de quelle manière le processus en Y répond particulièrement bien à la spécification technique d'un système client/serveur.

3.1. Configuration matérielle

Figure 3.3.1.: Configuration matérielle

La mobilité des acteurs et la volonté de fournir une plus grande disponibilité de l'application aux employés, dirigeants et internautes, nous avons opté pour rendre la présente application accessible tant à l'intérieur du réseau de l'entreprise, que à partir de l'externe grâce à une connexion Internet sécurisée (HTTPS.).

En permettant un accès aux informations à partir d'Internet, on accroît la valeur des informations disponibles en les rendant accessibles facilement et au bon moment.

La configuration matérielle de la présente application permet de présenter les contraintes matérielles suivantes :

? Pour que l'application puisse fonctionner, elle doit avoir accès à la base de données au moyen d'une connexion fiable et rapide.

? Pour des raisons de sécurité, les accès au Serveur Web et au Serveur de SGBDR sont filtrés par des dispositifs de Coupe-feu (Firewall) donnant accès seulement à certains

98

ports et adresses IP déterminées. Par exemple, aucun accès direct au serveur de SGBDR ne sera permis, seulement des connexions originaires du Serveur Web seront acceptées.

? Pour des raisons de facilité d'intégration et pour une diminution des coûts de maintenance, les systèmes d'exploitation utilisés sont : Linux Debian pour le serveur de données et Windows Server 2008 R2 pour le serveur web.

3.2. Style de déploiement

Figure 3.3.2.: Présentation du Style de déploiement

L'architecture 3-tiers utilisée dans le cadre de notre application implique des contraintes d'exploitation. En effet, il y a une répartition des composantes suivant les responsabilités :

? Le stockage de données sera fait par des instances redondantes de bases de données. On a retenu un moteur de bases de données relationnel.

? L'exécution des services métier sera faite par de Components (côté serveur). La technologie utilisée sera Apache 2.2.7.

? La présentation et la gestion des applications correspondent à plusieurs composantes d'exploitation exécutées côté serveur. Ces applications seront développées en PHP 5, JavaScript, HTML, etc.

Au stade actuel du développement de l'application, on ne peut fournir qu'une typologie de déploiement présentant les types de composantes d'exploitation.

99

3.3. Cas d'utilisation technique

Le cas d'utilisation technique nous permet de déterminer l'exploitant et d'identifier des enchaînements qui produiront une valeur ajoutée dite opérationnelle ou technique.

Les exploitants du nouveau système sont :

1. L'utilisateur qui utilise le système. Par le fait même, la totalité des acteurs de la branche fonctionnelle sont des utilisateurs dans la dimension technique;

2. L'administrateur du système, qui est chargé de déployer et de remédier aux problèmes du système;

Suite à la considération des attentes opérationnelles de chaque exploitant, les cas d'utilisations techniques requis pour la présente application sont :

Figure 3.3.3.: Présentation des cas d'utilisation techniques

? Aide aux usagers : Un service d'aide doit être disponible pour chaque utilisateur afin de l'accompagner, lorsqu'il y a questionnement, dans l'utilisation du système.

? Gestion de l'intégrité : Le système doit s'assurer à l'intégrité et de la conformité des informations. De plus, l'une des particularités de ce cas d'utilisation, est le contrôle la mise à jour simultanée d'une même entité par deux utilisateurs différents.

? Gestion des objets : L'utilisateur doit manipuler des entités sous forme d'objets ce qui engage la mise en oeuvre de mécanismes de persistance et de gestion de cycle de vie de ces mêmes objets.

? L'authentification : Un système d'authentification doit reconnaître chaque utilisateur afin d'octroyer les bons privilèges (lecture, écriture, suppression, accès) pour les modules du nouveau système auxquels il a le droit.

100

3.4. Couche logicielle

Une couche logicielle représente un ensemble de spécifications ou de réalisations qui respectivement expriment ou mettent en oeuvre un ensemble de responsabilités techniques et homogènes pour un système logiciel.

Figure 3.3.4.: Présentation des couches logicielles

Présentation

La couche présentation a pour rôle de générer les interfaces du logiciel. Elle permet à l'utilisateur de manipuler certaines informations à l'aide de menus et de commandes qui se retrouvent dans cette présentation.

Application

La couche application s'appuie sur la couche métier pour gérer et contrôler les informations manipulées par la couche présentation. Elle dirige donc les règles de l'application.

101

Métier

La couche métier au sein de laquelle sont intégrées l'ensemble des règles de gestion propres au fonctionnement de l'entreprise. Ces règles ne sont pas nécessairement spécifiques à notre application. Cette couche permettra à l'utilisateur du système d'accéder aux différents objets.

Accès aux données

La couche accès aux données est responsable d'aller rechercher les données stockées, d'exploiter les procédures d'accès aux données et de fournir des fonctionnalités exigées pour transformer les requêtes en primitives. Cette couche gère l'accès aux données de chaque utilisateur.

Stockage des données

La couche stockage de donnée dont le rôle est de gérer la sauvegarde et la mise à jour des informations. Toutes les données entrées dans le système s'inséreront dans des tables.

3.5. Cas d'utilisation techniques détaillés

? Support aux usagers

Sommaire d'identification

Couche logicielle : Présentation

Titre du cas d'utilisation : Support aux usagers

But : Fournir une aide contextuelle aux utilisateurs

Résumé : Permettre un service d'aide pour chaque utilisateur afin de

l'accompagner, au besoin, dans l'utilisation du système. Exploitants et/ou couches exploitantes :

? La couche présentation lorsque l'usager demande de l'aide.

Description des enchaînements

Préconditions: Néant.

Enchaînements :

L'élément déclencheur du cas d'utilisation technique est lorsque l'utilisateur de Dégimi éprouve de la difficulté à utiliser le système et requiert une demande d'aide.

Enchaînement (a) Demander de l'aide

Cet enchaînement permet à l'usager de demander de l'aide via un hyperlien « Support aux usagers », représenté dans la couche présentation.

102

Enchaînement (b) Rechercher de l'aide

Pour effectuer la recherche, la couche application se met à l'oeuvre. En effet, cette dernière demande l'information nécessaire à la couche d'accès aux données. Dans le cas où le système ne trouve aucun élément pertinent pour répondre à la demande un message générique sera émis par le système.

Enchaînement (c) Afficher l'aide

La couche application retourne l'information à la couche présentation pour que l'utilisateur puisse visionner l'information.

Exceptions : Néant.

Post-conditions : Néant.

? Gestion de l'intégrité

Sommaire d'identification

Couche logicielle : Accès aux données

Titre du cas d'utilisation : Gestion de l'intégrité

But : S'assurer que la gestion et la coordination des données sont bien
effectuées.

Résumé : Gérer les collisions

Exploitants et/ou couches exploitantes :

? La couche accès aux données lorsqu'elle vérifie si plusieurs utilisateurs accèdent aux
données au même moment.

? La couche métier lors de la gestion des collisions et de l'annulation d'enregistrements

Description des enchaînements

Pré conditions: Néant.

Enchaînements :

L'élément déclencheur du cas d'utilisation technique est lorsque deux ou plusieurs utilisateurs

veulent utiliser les mêmes fonctionnalités au même moment.

Enchaînement (a) Gérer les collisions

Permet de vérifier si un enregistrement est en cours d'utilisation. Si c'est le cas, il sera impossible d'accéder à l'enregistrement et un message d'erreur sera envoyé à la couche présentation.

Exceptions :

103

Néant.

Post-conditions :

Les seuils de limitations de données ne sont pas dépassés pour les requêtes qui concernent la couche présentation.

? Gestion des objets

Sommaire d'identification

Couche logicielle : Accès aux données

Titre du cas d'utilisation : Gestion des objets

But : S'assurer que la gestion et la coordination des données sont bien

effectuées.

Résumé : Trouver des enregistrements, ajouter des enregistrements et supprimer des
enregistrements.

Exploitants et/ou couches exploitantes :

? La couche accès aux données lorsqu'elle vérifie si plusieurs usagers accèdent aux données

au même moment.

? La couche métier lors de la gestion des collisions et de l'annulation d'enregistrements

Description des enchaînements

Pré conditions: Néant.

Enchaînements :

L'élément déclencheur du cas d'utilisation technique est lorsqu'une demande de création, de modification, de suppression, fermeture est effectuée.

Enchaînement (a) Trouver l'enregistrement

Cet enchaînement permet de trouver un enregistrement, à l'aide d'un critère, qui doit être soit chargé, modifié ou supprimé.

Enchaînement (b) Créer un enregistrement

Cet enchaînement, avec l'aide de la couche métier, permet de créer une nouvelle donnée et de l'enregistrer dans la base de données.

Enchaînement (c) Annuler un enregistrement

Il s'agit de supprimer un enregistrement existant via la couche métier.

Exceptions : Néant.

Post-conditions :

Les seuils de limitations de données ne sont pas dépassés pour les requêtes qui concernent la couche présentation.

104

? Authentification

Sommaire d'identification

Couche logicielle : Métier

Titre du cas d'utilisation : Authentification

But : Gérer les différents niveaux d'accès selon le type d'utilisateur

Résumé : Demander renseignements sur l'utilisateur, valider les informations, accorder
les droits d'accès au module.

Exploitants et/ou couches exploitantes :

? La Couche Présentation lors de la saisie des paramètres

? La Couche Métier lors de l'accès au différent module

Description des enchaînements

Pré conditions :

L'utilisateur doit avoir un profil dans l'application

L'élément déclencheur du cas d'utilisation technique est lorsque la couche de présentation demande l'accès à un module de l'application

Enchaînements :

Enchaînement (a) Demander renseignement sur l'usager

La couche présentation nous fournit les informations remplit par l'utilisateur. Enchaînement (b) Valider les informations

La couche métier fait appel à la couche accès aux données afin de vérifier si l'utilisateur est inscrit dans la base de données, pour ce faire, un appel à la couche donnée est généré.

Enchaînement (c) Accorder les droits d'accès aux modules

La couche de présentation demande une liste des modules accessibles à cet utilisateur. Cette liste de données réduites permettant à l'utilisateur de choisir le module qu'il veut accéder. La couche métier demande l'accès aux modules choisis.

Exceptions : Néant.

Post-conditions :

L'utilisateur accède au module voulu et ses actions sont limitées par les privilèges qui lui sont accordés

105

		Enregistre

Figure 3.4.1.: Présentation de classe optimisée Enregistrer les étudiants ayant ...

Chapitre IV : Analyse fonctionnelle

Dans ce chapitre, nous présentons le diagramme de classes complétées et optimisées, le diagramme d'état et le diagramme de séquence.

4.1. Diagramme de classes complétées

Étant donné la simplicité de notre système, nous avons choisi d'effectuer les étapes « affiner les classes », « affiner les associations », « ajouter les attributs », « ajouter les opérations » et « optimiser avec la généralisation » en une seule itération. Ceci s'est soldé par une progression du diagramme de classes au diagramme de classes optimisées directement.

4.2. Diagramme de classes optimisées

Les diagrammes de classes optimisées représentent une version plus détaillée des diagrammes de classes vus aux points précédents. On y retrouve certains éléments importants comme les attributs, l'encapsulation, les agrégations et les compositions.

? Diagramme de classe optimisée « Enregistrer les étudiants ayant payés les frais »

Remet

106

? Diagramme de classe optimisée «Envoyer les listes des enrôlés aux enseignants »

Envoi

Reçoit

Est titulaire

Figure 3.4.2.: Présentation de classe optimisée Envoyer les listes ...

? Diagramme de classe optimisée «Remettre la fiche des côtes »

Figure 3.4.5.: Présentation de classe optimisée Obtention relevé ...

107

Figure 3.4.3.: Présentation de classe optimisée Remettre la fiche ...

q Diagramme de classe optimisée «Délibération des étudiants »

Contrôle

Figure 3.4.4.: Présentation de classe optimisée Délibération ...

q Diagramme de classe optimisée «Obtention relevé des côtes »

Bénéficie

Formule

1..*

Etablir

Approuve

1

108

? Diagramme de classe optimisée «Gestion profils d'usagers »

	Figure 3.4.6.: Présentation de classe optimisée Gestion profil ...

4.3. Liste de scénarios

? Enregistrer les étudiants ayant payés les frais

Scénarios nominaux :

EEPF_N1 : Enregistrer les enrôlés

EEPF_N2 : Annuler l'enregistrement des enrôlés

Scénarios alternatifs :

Aucun

Scénarios aux limites :

Aucun

Scénarios d'erreurs :

EEPF_E1 : Aucun fichier détecté lors de la jointure

109

? Envoyer les listes des enrôlés aux enseignants

Scénarios nominaux :

ELEE_N1 : Envoyer par email le fichier des enrôlés ELEE_N2 : Afficher les fichiers des enrôlés déjà envoyés

Scénarios alternatifs :

Aucun

Scénarios aux limites :

Aucun

Scénarios d'erreurs :

ELEE_E1 : Les adresses entrées sont introuvables

? Remettre la fiche des côtes

Scénarios nominaux :

RFC_N1 : Remettre la fiche des côtes

RFC_N1 : Afficher les fiches des côtes déjà remises par l'enseignant

Scénarios alternatifs : Aucun

Scénarios aux limites : Aucun

Scénarios d'erreurs :

RFC_E1 : Aucun fichier détecté lors de la jointure

110

? Délibérations des étudiants

Scénarios nominaux :

DE_N1 : mettre à jour la grille des côtes

DE_N2 : Publier la grille des côtes

Scénarios alternatifs : Aucun

Scénarios aux limites : Aucun

Scénarios d'erreurs :

DE_E1 : Péréquation non effectuée

? Obtention relevé des côtes

Scénarios nominaux :

ORC_N1 : Formuler la demande ORC_N2 : Approuver la demande

Scénarios alternatifs : Aucun

Scénarios aux limites : Aucune

Scénarios d'erreurs :

ORC_E1 : Information incomplète sur le formulaire demande

? Gestion des profils d'usagers

Scénarios nominaux :

GPU_N1 : Création du profil usager

GPU_N2 : Suppression du profil usager

Scénarios alternatifs :

GPU_A1 : Modification du profil usager

Scénarios aux limites : Aucune

Scénarios d'erreurs :

GPU_E1 : Assigner le même nom d'usager à deux personnes en même temps.

111

4.4. Diagramme d'états

? Diagramme d'états « Enregistrer les étudiants ayant payés les frais »

Figure 3.4.7.: Présentation de diagramme d'état Enregistrer les étudiants...

? Diagramme d'états « Envoyer les fiches des côtes des enseignants »

Figure 3.4.8.: Présentation de diagramme d'état Envoyer les fiches ...

112

? Diagramme d'états « Remettre la fiche des côtes »

Figure 3.4.9.: Présentation de diagramme d'état Remettre la fiche ...

? Diagramme d'états « Délibération des étudiants »

Figure 3.4.10.: Présentation de diagramme d'état Délibération des étudiants

113

? Diagramme d'états « Obtention des relevés des côtes »

Figure 3.4.11.: Présentation de diagramme d'état Obtention relevé...

? Diagramme d'états « Gestion des profils des usagers »

Figure 3.4.12.: Présentation de diagramme d'état Gestion des profils...

Figure 3.4.14.: Présentation de diagramme séquence Envoyer les listes...

114

4.5. Diagramme d'interactions

? Diagramme de séquence « Enregistrer les étudiants ayant payés les frais »

Figure 3.4.13.: Présentation de diagramme séquence Enregistrer les étudiants...

? Diagramme de séquence « Envoyer les fiches des côtes aux enseignants »

115

? Diagramme de séquence « Remettre la fiche des côtes »

Figure 3.4.15.: Présentation de diagramme séquence Remettre la fiche...

Figure 3.4.16.: Présentation de diagramme séquence Délibération des étudiants

? Diagramme de séquence « Délibération des étudiants »

116

? Diagramme de séquence « Obtention relevé des côtes »

Figure 3.4.17.: Présentation de diagramme séquence Obtention relevé des côtes

? Diagramme de séquence « Gestion des profils d'usagers »

Figure 3.4.18.: Présentation de diagramme séquence Gestion des profils ...

117

Chapitre V : Conception Générique

La conception générique consiste à développer la solution qui répond aux spécifications techniques que nous vous avons présentées au chapitre 3.

Cette conception est qualifiée de générique car elle est entièrement indépendante des aspects fonctionnels spécifiés en branche gauche. La conception générique reste donc une activité de la branche droite.

5.1. Framework design patterns mécanismes

Définition Design Patterns

Un design pattern est une solution de conception commune à un problème récurrent dans un contexte donné²⁷.

Dans les faits, les design patterns recensent les problématiques communément rencontrées lors des conceptions orientées objet.

Le Framework définit les interfaces de réalisation des responsabilités logicielles. La figure suivante reprend les différentes couches logicielles et complètent la conception à l'aide d'autres Framework répondant à des services spécifiques du système.

²⁷ Pascal Roques
· Franck Vallée, UML 2 en Action de l'analyse des besoins à la conception, Ed. Eyrolles, 2007, Paris, p209.

118

Contrôleur

Modèle

Vue

Figure 3.5.1.: Présentation de Framework design patterns mécanisme

5.2. Modèle logique

L'organisation du modèle logique reprend les couches logicielles. À chaque couche correspond un Framework technique, en partie abstrait, qui définit des interfaces de réalisation des responsabilités logicielles :

V' Noyau présentation :

Ce noyau représente un « Framework » qui renvoi les données à l'utilisateur (aspect visuel, menu, présentation). Celui-ci est donc essentiel pour définir les classes, les interfaces, et les mécanismes de base pour réaliser l'affichage d'objets. Par le fait même, il couvre les besoins de la couche présentation. Celui-ci permettra aux utilisateurs du système de bien visualiser l'application et ainsi faciliter la navigation à travers le système.

V' Noyau applicatif :

Le noyau applicatif va permettre le rafraîchissement des vues et le chargement des modèles de fonctionnement. Il symbolise aussi les objets de contrôle, dirige les règles et répond aux besoins de la couche application. Ce noyau permettra de lister et classer les données du système afin que l'utilisateur du système puisse mieux s'y retrouver.

119

V' Noyau métier :

Le « Framework » noyau métier permet de répondre aux différents besoins de la couche métier. Il représente donc les objets métier et leurs attributs caractéristiques tout en implémentant leurs règles de gestion. Ce Framework permettra à l'utilisateur d'accéder aux objets Fichier Frais, objets Fiche des Cotes, objets Grille des côtes, etc.

V' Noyau sécurité :

Le noyau sécurité n'est pas représenté, car il est assuré par l'authentification des usagers définit dans les cas d'utilisations techniques.

V' Accès aux données :

Le « Framework » accès aux données permet de gérer l'accès aux données ainsi que le stockage vers la base de données. Il couvre par le fait même les besoins de la couche accès aux données. Cette couche gère l'accès aux données de chaque utilisateur.

V' Authentification :

Ce « Framework » permet d'accéder aux différentes fonctionnalités du système qui ont été établies lors de l'attribution du profil d'usager. Chaque utilisateur détiendra un profil et un mot de passe qui délimitera l'accès qui leur a été accordé.

120

5.3. Modèle d'Exploitation de la conception technique

En conception générique, le modèle d'exploitation montre l'organisation des composants correspondant aux différents Framework techniques que l'on peut mettre en oeuvre.

Voici comment nous avons choisi d'organiser les composants génériques qui devront être intégrés au prototype de validation de la conception générique :

V' pour des raisons de performances, la base de données du référentiel métier et le référentiel des informations d'intégrité sont séparés ;

V' le composant d'accès aux données correspond à la partie générique du Framework qui pilote la connexion à la base de données ;

V' le superviseur de la distribution est le chef d'orchestre des composants, il est

notamment chargé de démarrer tous les autres composants distribués. La relation de démarrage constitue une dépendance particulière. C'est pourquoi nous avons introduit le stéréotype « start ».

Figure 3.5.2.: Présentation du modèle d'exploitation de la conception technique

121

5.4. Modèle de Configuration logicielle

Le modèle de configuration logicielle est développé au niveau de la conception technique. Les sous-systèmes identifiés sont autant de cibles de fabrication indépendantes, de manière à pouvoir être réutilisés par différents projets, par exemple dans le cas de notre projet :

Le sous-système « Superviseur components » établit comment fabriquer les composants du système constituant les services d'exécution.

Le sous-système « Exécuter métier » regroupe l'ensemble des composants du système et des packages PHP permettant de fabriquer un composant d'exécution métier.

Le sous-système « Environnement local » structure les packages PHP. Il permet l'exploitation des éléments à intégrer dans le code des applications clientes.

Figure 3.5.3.: Présentation du modèle de configuration logicielle

122

5.4. Présentation et justification du choix des langages de développement y' Présentation des langages de développement

5 couches	Langages
Présentation	HTML, JavaScript, Css
Application	PHP, Ajax
Métier	PHP
Accès aux données	PHP
Stockage de données	MySQL

y' Justification du choix des langages de développement

Plusieurs possibilités s'offrent à nous afin de présenter une application simple, durable, complète et intègre. Comme il nous a été demandé, nous désirons créer une application Web qui se définit comme : l'automatisation de certaines tâches de gestion courante, à partir du Web, afin de répondre aux besoins spécifiques de chaque fonction de l'organisation.

De ce fait, nous envisageons créer notre application HTLM (Hyper-Text Mark-up Language) à l'aide du logiciel Dreamweaver. Celui-ci est définit comme un Logiciel performant qui nous permet de réaliser nos pages Web avec rapidité, simplicité et professionnalisme. La version récente intègre les plus récentes innovations technologiques. De nouvelles fonctions nous permettent de personnaliser le logiciel selon nos besoins et notre niveau de connaissance ».

Tout ce qui concerne l'aspect présentation de notre application sera géré par le code

HTML.

Par ailleurs, pour répondre aux besoins de la couche application, plus précisément le volet validation et contrôle, l'utilisation de PHP et Ajax seront de mise. Et pour afin répondre aussi aux différents besoins de la couche métier et accès aux données, nous utilisons le PHP.

Finalement, pour la création de notre base de données, considérant notre demande en volume de données assez illimité, notre choix s'est arrêté sur MySQL.

123

Chapitre VI : Conception Préliminaire

La conception préliminaire est certainement l'étape la plus délicate du processus 2TUP car elle en représente le coeur. C'est en effet à cette occasion que s'effectue la fusion des études fonctionnelles et techniques.

En conséquence, plusieurs activités doivent coexister. Il convient de :

V' Passer de l'analyse objet à la conception,

V' Intégrer les fonctions métier et applicatives du système dans l'architecture technique,

V' Adapter la conception générique aux spécifications fournies par l'analyse.

La conception préliminaire est avant tout affaire d'organisation ; elle s'appuie sur les points de vue de spécifications fonctionnelle et structurelle de l'analyse, mais également sur les Frameworks de la conception technique. Elle se termine lorsque la conception est organisée suivant :

V' Son déploiement cible,

V' Son modèle d'exploitation, V' Son modèle logique.

6.1. Conception du déploiement

Le déploiement d'une solution client/serveur se construit sur la définition des postes de travail. Le poste de travail représente un ou plusieurs acteurs pouvant être localisés sur une machine d'un type particulier et remplissant une fonction identifiée dans l'entreprise.

Figure 3.6.1.: Présentation du déploiement

124

La présente figure représente l'environnement de travail de tous les acteurs du système. Étant donné la nature de notre application, 3 tiers côté serveur et client léger (navigateur), le déploiement impliquera uniquement l'installation d'un navigateur générique pour accéder à ce nouveau système. Par la suite, la gestion des profils se chargera de la gestion des différents accès aux fonctionnalités du système.

Une connexion LAN sera utilisée pour relier le serveur central au serveur web et au navigateur interne. De plus, les acteurs du système auront accès au système via un navigateur externe qui utilisera une connexion internet. Cela s'avère utile pour faire du télétravail ou même pour répondre à des situations d'urgence.

6.2. Conception du modèle d'exploitation

L'élaboration d'une architecture d'exploitation avait déjà commencé en conception générique. À partir du déploiement, il est possible de la compléter en fonction des machines et des postes de travail, tout en intégrant les besoins exprimés en analyse

? Identification des différentes applications « EnregistrerEPF, EnvoyerLEE, RemettreFC et DélibEtu»

EnvoyerLEE

Effectue l'envoi des listes des enrôlés aux enseignants et prépare les grilles des côtes

Figure 3.6.2.: Modèle d'exploitation délibération des étudiants

EnregistrerEPF

Différentes informations sur les étudiants ayant payés les frais d'enrôlement

DélibEtu

Différentes

informations sur les calculs des côtes,

péréquation et
publication des résultats

RemettreFC

Différentes

informations sur les des étudiants

Pour cette figure on retrouve 4 applications, soit EnregistrerEPF, EnvoyerLEE, RemettreFC et DelibEtu. Ces applications correspondent aux fonctions de la Délibération des étudiants.

125

V' Identification des différentes applications « ObtentionCote»

ObtentionCote
Différentes informations sur les demandes et livraisons des relevés des côtes
Figure 3.6.3.: Modèle d'exploitation Gestion relevé des côtes

Pour cette figure on retrouve une seule application, soit ObtentionCote. Cette application correspond aux fonctions de la Gestion relevés des côtes.

V' Identification des différentes applications « GesProfil»

GesProfil
Gestion des différents profils d'usagers du système.

Figure 3.6.4.: Modèle d'exploitation Gestion profils d'usagers

L'application GesProfil contient les définitions des différents profils d'usagers de notre système. GesProfil est destiné plus particulièrement à l'administrateur de système. Celui-ci aura la responsabilité de gérer cette fonctionnalité.

126

? Définitions des applications dans le modèle d'exploitation

Figure 3.6.5.: Applications dans le modèle d'exploitation

La figure ci-dessus illustre la définition des applications dans le modèle d'exploitation. Étant donné que tous les postes de travail auront le même type de déploiement, il est important d'illustrer en arrière-plan le serveur WEB. En effet, toutes les applications sont exploitées directement sur le serveur WEB (Apache). Ces mêmes applications seront donc attribuées selon le profil d'usager. Par conséquent, le poste de travail du :

· Secrétaire Général Académique interagit avec les applications EnregistrerEPF, EnvoyerLEE et DelibEtu.

· Secrétaire du jury interagit avec l'application DelibEtu.

· Etudiant interagit avec l'application ObtentionCote.

· Enseignant interagit avec l'application RemettreFC.

· Chef de Section interagit avec l'application ObtentionCote.

· Administrateur du système interagit avec les applications et GesProfil.

127

6.3. Organisation du modèle logique

La distribution d'un composant facilite sa réutilisation, puisque les mêmes services sont accessibles depuis différentes applications. La première façon d'identifier les composants distribués consiste donc à recenser les catégories d'analyse partagées par plusieurs applications.

? Identification des composants métiers du système

Figure 3.6.6.: Les composants métiers du système

Cette figure nous permet d'identifier les différents composants métier et d'illustrer les différentes catégories du système. Par le fait même, l'illustration de ces catégories (Enregistrer Etudiant, Envoyer Liste, Remettre Fiche, Délibération, Obtention relevé, Profil d'usager et exploitation informatique) nous permet de mieux comprendre le système ainsi que son efficacité.

128

? Schéma de dépendances entre composants métier du modèle d'exploitation

Figure 3.6.7.: Schéma de dépendance entre composants métiers du modèle d'exploitation

⁶⁷ Shé

ation

La figure ci-dessus représente les différents liens de dépendances entre les composants métier du système. Par exemple, la catégorie profil attribue une exploitation informatique pour chaque usager qui, par ricochet, donne accès aux différentes fonctionnalités de la catégorie Enregistrer Étudiant. Cette dernière, recueille les données et les transferts vers la catégorie Envoyer Liste. De plus, la catégorie Remettre Fiche transfert les données vers la catégorie Délibération qui elle transfert à son tour les données vers la catégorie Obtention relevé.

129

6.4. Conception des interfaces

Cette conception consiste à recenser dans un premier temps les objets (interfaces) métier de notre système et à les projeter sur chacun des composants du système. Ces interfaces ont pour but de regrouper les responsabilités du système.

Composant distribué	Interface	Description de ses responsabilités
Profils d'usagers	iProfil	Gestion centralisée de l'entité profils d'utilisateur : Consulter, créer, modifier, supprimer des profils d'utilisateur
Etudiant	iEtudiant	Gestion centralisée de l'entité Etudiant : Ajouter des étudiants.
Fichier Frais	iFichierFrais	Gestion centralisée de l'entité Fichier Frais : Enregistrer des étudiants.
Fiche des côtes	iFicheCote	Gestion centralisée de l'entité Fiche des côtes: Envoyer la liste des enrôlés aux enseignants
Grille des côtes	iGrilleCote	Gestion centralisée de l'entité Grille des côtes : Enregistrer, Mettre à jour la grille des côtes.
Demande	iDemande	Gestion centralisée de l'entité Demande : Créer et mettre à jour les demandes formulées par les étudiants.
Relevé des côtes	iReleve	Gestion centralisée de l'entité Relevé des côtes : Ajouter le relevé disponible.
Département	iDepartement	Gestion centralisée de l'entité Département : Créer, Modifier, Supprimer des départements.
Section	iSection	Gestion centralisée de l'entité Section : Créer, Modifier, Supprimer des section.
Classe	iClasse	Gestion centralisée de l'entité Classe : Créer, Modifier, Supprimer des Classes.
Droit	iDroit	Gestion centralisée de l'entité Droit : Créer, Modifier, Supprimer des droits.

130

6.5. Conception de la structure de présentation

? Énumération des vues de l'application EnregistrerEPF

Cette section nous permet de mieux comprendre et définir les interfaces exploitées par l'application « EnregistrerEPF» et donne une idée sur l'environnement de travail du Secrétaire Général Académique.

Vue d'IHM	Description
index	Cette vue permet de visualiser les enregistrements effectués le même jour et trier par classe.
indexAll	Cette vue permet de visualiser tous les enregistrements de la table Fichier_Frais et trier par classe
annulerEnregstrer	Cette vue permet d'annuler c'est-à-dire supprimer les données enregistrées 10 minutes avant
enregistrerFrais	Cette vue permet d'ajouter les données dans la table Fichier_Frais par la jointure du fichier Excel.
form_AnnulerEnregistrer	Cette vue est un formulaire permettant d'effectuer l'annulation de l'enregistrement en faisant appel à la vue annulerEnregistrer
form_EnregistrerFrais	Cette vue est un formulaire permettant d'effectuer la jointure du fichier et l'enregistrement des données en faisant appel à la vue enregistrerFrais

131

'7 Énumération des vues de l'application EnvoyerLEE

Cette section nous permet de mieux comprendre et définir les interfaces exploitées par l'application « EnvoyerLEE» et donne une idée sur l'environnement de travail du Secrétaire Général Académique.

Vue d'IHM		Description
index		Cette vue permet de visualiser les listes des enrôlés expédiées aux enseignants le même jour et trier par classe.
	indexAll	Cette vue permet de visualiser toutes les listes des enrôlés expédiées aux enseignants et trier par classe
envoyerListe		Cette vue permet d'envoyer les listes des enrôlés aux enseignants par leurs adresses e-mail et ajouter ces noms dans la table Grille_cote.
form_EnvoyerListe		Cette vue est un formulaire permettant d'effectuer l'envoi des listes des enrôlés en faisant appel à la vue envoyerListe

'7 Énumération des vues de l'application RemettreFC

Cette section nous permet de mieux comprendre et définir les interfaces exploitées par l'application « RemettreFC » et donne une idée sur l'environnement de travail de l'enseignant.

Vue d'IHM	Description
index	Cette vue permet de visualiser les fiches des côtes remises par l'enseignant.
remiseFichecote	Cette vue permet d'ajouter les côtes dans la table Grille_Cote par la jointure du fichier Excel.
form_remiseFichecote	Cette vue est un formulaire permettant d'effectuer la remise des côtes en faisant appel à la vue remiseFichecote

132

? Énumération des vues de l'application DelibEtu

Cette section nous permet de mieux comprendre et définir les interfaces exploitées par l'application « DelibEtu » et donne une idée sur l'environnement de travail de Secrétaire du jury.

Vue d'IHM	Description
index	Cette vue permet de visualiser les fiches des côtes déjà remises par les enseignants.
updateGrille	Cette vue permet de mettre à jour la table Grille_Cote.
form_UpdateGrille	Cette vue est un formulaire permettant d'effectuer la modification des côtes d'un étudiant en faisant appel à la vue updateGrille
perequation	Cette vue effectue la péréquation des côtes des étudiants.
deliberer	Cette vue complète la colonne décision par rapport au pourcentage de l'étudiant.
publier	Cette vue rend disponible les résultats des délibérations sur l'internet.

133

? Énumération des vues de l'application ObtentionCote

Cette section nous permet de mieux comprendre et définir les interfaces exploitées par l'application « ObtentionCote» et donne une idée sur l'environnement de travail du Chef de section et de l'étudiant.

Vue d'IHM	Description
index	Cette vue permet de visualiser les demandes récemment envoyées, elle est disponible pour le chef de section.
indexappro	Cette vue permet de visualiser les relevés des côtes déjà imprimés. elle est disponible pour le chef de section.
insertdemande	Cette vue permet de mettre à jour la table Grille_Cote.
form_demande	Cette vue est un formulaire permettant d'effectuer la demande d'un relevé des côtes en faisant appel à la vue insertdemande. Elle est disponible uniquement pour l'étudiant.
approuver	Cette vue effectue l'approbation d'une demande, elle est disponible pour le chef de section.
imprimer_releve	Cette vue permet à l'étudiant d'imprimer son relevé des côtes, lorsque sa demande est approuvée par le chef de section moyennant un code qui lui sera envoyé à son adresse e-mail.
form_imprimereleve	Cette vue est un formulaire permettant à l'étudiant d'introduire le code qui lui était envoyé, pour enfin imprimer son relevé des côtes en faisant appel à la vue imprimer_releve. Elle est disponible uniquement pour l'étudiant.

134

? Énumération des vues de l'application GesProfil

Cette section nous permet de mieux comprendre et définir les interfaces exploitées par l'application « GesProfil» et donne une idée sur l'environnement de travail du Chef de section et de l'étudiant.

Vue d'IHM	Description
index_prof	Cette vue permet de visualiser tous les profils usagers de l'organisation.
insert_prof	Cette vue permet de créer un nouvel utilisateur dans l'organisation
update_prof	Cette vue permet de modifier le profil d'un utilisateur de l'organisation
delete_prof	Cette vue permet de supprimer le profil d'un utilisateur de l'organisation
form_prof	Cette vue est un formulaire permettant d'effectuer de créer ou modifier un profil en faisant appel aux vues insert_prof et update_prof.
index_cours	Cette vue permet de visualiser tous les cours du système.
insert_cours	Cette vue permet de créer un nouveau cours du système.
update_cours	Cette vue permet de mettre à jour un cours du système
delete_cours	Cette vue permet de supprimer un cours du système
form_cours	Cette vue est un formulaire permettant d'effectuer de créer ou modifier un cours en faisant appel aux vues insert_cours et update_cours.
index_section	Cette vue permet de visualiser toutes les sections du système.
insert_section	Cette vue permet de créer une nouvelle section du système.
update_section	Cette vue permet de mettre à jour une section du système
delete_section	Cette vue permet de supprimer une section du système
form_section	Cette vue est un formulaire permettant d'effectuer de créer ou modifier une section en faisant appel aux vues insert_section et update_section.
index_depart	Cette vue permet de visualiser tous les départements du système.
insert_depart	Cette vue permet de créer un nouveau département du système.
update_depart	Cette vue permet de mettre à jour un département du système
delete_depart	Cette vue permet de supprimer un département du système
form_depart	Cette vue est un formulaire permettant d'effectuer de créer ou modifier un département en faisant appel aux vues insert_depart et update_depart.

135

Chapitre VII : Conception Détaillée

La conception détaillée est une activité qui s'inscrit dans l'organisation définit par la conception préliminaire. Le modèle logique y est particulièrement important dans la mesure où c'est en conception détaillée que l'on génère le plus gros volume d'informations²⁸.

7.1. Modèle logique de conception détaillée

Figure 3.7.1.: Modèle logique de la conception détaillée

²⁸ Pascal Roques
· Franck Vallée, UML 2 en Action de l'analyse des besoins à la conception, Ed. Eyrolles, 2007, Paris, p281

136

Cette figure illustre la conception du stockage des différentes classes dans un modèle relationnel. On peut voir les différentes relations avec les autres classes au moyen de clés étrangères.

7.2. Développement de la configuration logicielle détaillée

La conception préliminaire a défini une structure de configuration logicielle en packages ou sous-systèmes. C'est lorsque toutes les classes sont détaillées à un niveau proche du code que chaque sous-système de configuration logicielle peut être définie²⁹. Pour documenter et concevoir la configuration logicielle, il peut être utile de représenter la configuration logicielle à l'aide d'un ou plusieurs diagrammes de composants UML.

? Développement de la configuration logicielle : Profil d'usager

Figure 3.7.2.: Configuration logicielle Profils d'usager

La figure ci-dessus illustre la configuration logicielle du « Profil d'usager » ainsi que la hiérarchie de ses imports. On y voit clairement la dynamique d'échange entre iProfil et les opérations possible lors de l'exécution du module « Profils d'usagers ».

Donc, lorsque l'exécution d'une opération survient le fichier « profils d'usager » va importer les données vers l'interface iProfil.

Cela permettra à l'administrateur du système de visionner l'information. Simultanément, les données du fichier seront aussi importées vers l'opération Profils d'usagers.

²⁹ Pascal Roques
· Franck Vallée, Op. Cit. p321

137

Cette étape permettra le traitement des informations selon les différentes opérations possibles du module « Profil d'usager ».

? Développement de la configuration logicielle : Enregistrer Etudiant

Figure 3.7.3.: Configuration logicielle Enregistrer Etudiant

La figure ci-dessus illustre la configuration logicielle de « Enregistrer Etudiant » ainsi que la hiérarchie de ses imports. On y voit clairement la dynamique d'échange entre iFichierFrais, iEtudiant et les opérations possibles lors de l'exécution du module « Enregistrer Etudiant ». Donc, lorsque l'exécution d'une opération survient le fichier « Enregistrer Etudiant » va importer les données vers l'interface iFichierFrais et iEtudiant. Cela permettra à l'administrateur du système de visionner l'information. Simultanément, les données du fichier seront aussi importées vers l'opération Enregistrer Etudiant. Cette étape permettra le traitement des informations selon les différentes opérations possibles du module « Enregistrer Etudiant ».

138

? Développement de la configuration logicielle : Envoyer Liste

Figure 3.7.4.: Configuration logicielle Envoyer Liste

La figure ci-dessus illustre la configuration logicielle de « Envoyer Liste » ainsi que la hiérarchie de ses imports. On y voit clairement la dynamique d'échange entre iFichierFrais, iFicheCote, iGrilleCote et les opérations possibles lors de l'exécution du module « Envoyer Liste ». Donc, lorsque l'exécution d'une opération survient le fichier « Envoyer Liste » va importer les données vers l'interface iFichierFrais, iFicheCote et iGrilleCote. Cela permettra à l'administrateur du système de visionner l'information. Simultanément, les données du fichier seront aussi importées vers l'opération Envoyer Liste. Cette étape permettra le traitement des informations selon les différentes opérations possibles du module « Envoyer Liste ».

139

? Développement de la configuration logicielle : Remettre Fiche

Figure 3.7.5.: Configuration logicielle Remettre Fiche

La figure ci-dessus illustre la configuration logicielle de « Remettre Fiche » ainsi que la hiérarchie de ses imports. On y voit clairement la dynamique d'échange entre iFicheCote, iGrilleCote et les opérations possibles lors de l'exécution du module « Remettre Fiche ». Donc, lorsque l'exécution d'une opération survient le fichier « Remettre » va importer les données vers l'interface iFicheCote et iGrilleCote. Cela permettra à l'administrateur du système de visionner l'information. Simultanément, les données du fichier seront aussi importées vers l'opération Remettre Fiche. Cette étape permettra le traitement des informations selon les différentes opérations possibles du module « Remettre Fiche ».

140

? Développement de la configuration logicielle : Délibération

Figure 3.7.6.: Configuration logicielle Délibération

La figure ci-dessus illustre la configuration logicielle de « Délibération » ainsi que la hiérarchie de ses imports. On y voit clairement la dynamique d'échange entre iFicheCote, iGrilleCote et les opérations possibles lors de l'exécution du module « Délibération ». Donc, lorsque l'exécution d'une opération survient le fichier « Délibération » va importer les données vers l'interface iFicheCote et iGrilleCote. Cela permettra à l'administrateur du système de visionner l'information. Simultanément, les données du fichier seront aussi importées vers l'opération Délibération. Cette étape permettra le traitement des informations selon les différentes opérations possibles du module « Délibération ».

141

? Développement de la configuration logicielle : Obtention Relevé

Figure 3.7.7.: Configuration logicielle Obtention Relevé

La figure ci-dessus illustre la configuration logicielle de « Obtention Relevé » ainsi que la hiérarchie de ses imports. On y voit clairement la dynamique d'échange entre iDemande, iReleve, iGrilleCote et les opérations possibles lors de l'exécution du module « Obtention Relevé ». Donc, lorsque l'exécution d'une opération survient le fichier « Obtention Relevé » va importer les données vers l'interface iDemande, iReleve et iGrilleCote. Cela permettra à l'administrateur du système de visionner l'information. Simultanément, les données du fichier seront aussi importées vers l'opération Obtention Relevé. Cette étape permettra le traitement des informations selon les différentes opérations possibles du module « Obtention Relevé ».

142

CONCLUSION

Nous voici arrivé à la fin de notre étude qui a consisté à la « Conception d'un Système d'Information pour la Gestion en Ligne des Activités Académiques »cas de l'Institut Supérieur de Commerce de Kinshasa. Notre objectif poursuivi était d'investiguer le système existant avec des méthodes et des techniques de recherche, et de proposer des solutions qui pourront faciliter la dite gestion. Nos Conclusions se trouvent incluses dans chacun de ces paragraphes qui suivent.

Dans sa première partie, il a été question d'élaborer un planning prévisionnel grâce à la méthode Potentiel Métra et d'expliquer quelques concepts informatiques de base et ceux relatifs à la modélisation orientée objet.

Quant à la deuxième partie, nous avons eu à investiguer le système existant et proposer des solutions après une critique objective du système en vigueur de la gestion des activités académiques, cela a été rendu possible grâce à la méthode Merise.

La solution d'informatisation étant retenue, dans la troisième partie de ce travail, nous avons eu à présenter les graphiques et les textes destinés à comprendre, et décrire des besoins et documenter le fonctionnement du nouveau système, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue, en se servant des notations UML 2 et du processus Two Track Unified Process.

Quelques états sont à générer par l'application tels que : la liste des enrôlés, la grille des côtes, le relevé des côtes, etc.

Ainsi, nous suggérons aux autorités académiques de l'Institut Supérieur de Commerce de Kinshasa d'utiliser ce système, car étant une innovation, il facilitera beaucoup de situations en matière des activités académiques.

Enfin, notre grand souhait est que d'autres lecteurs qui liront ce travail puissent l'éclairer et l'approfondir davantage, car une oeuvre ne vaut que par les différents commentaires, critiques et suggestions qu'elle suscite et surtout qu'ils soient constructifs.

143

Bibliographie

A. Ouvrages

1. DIGALLO F., Méthode Merise- Cours du Cycle B, Paris, 2001

2. DIONISI DOMINIQUE, l'essentiel sur merise, Ed. Eyrolles. Pars 1995

3. Dominique NANCY et Bernard ESPINASSE, Ingénierie des systèmes d'information merise deuxième génération, Ed. Sybex, paris 1998

4. Gérard Donadieu & Michel Karsk, la systémique : penser et agir dans la complexité, Ed. liaison, 2002

5. Joël de Rosnay, Le macroscope, Ed. Seuil, 1975

6. Josich MUKENGE MBUMBA, Le Langage Java et Nous, 1^ère Edition, Ed. CRIGED, Kinshasa, Octobre 2012

7. MVIBUDULU LALUYIT et Louis Denis KONKFIE IPIPI, Technique des bases de données, l'étude et cas, 2^ère édition corrigée et révisée, Ed. CRIGED, Décembre 2012

8. Roques Pascal, Les cahiers du programmeur, UML 2 Modéliser une application web, 4ème Edition, Ed. Eyrolles, Paris, 2006.

9. Roques Pascal, UML 2 par la pratique, études de cas et exercices corrigés, 5^ème Edition, Ed. Eyrolles, Paris, 2008.

10. Roques Pascal, Vallée, Franck, UML 2 en action : De l'analyse des besoins à la conception, 4ème édition, Editions. Eyrolles, Paris, 2007

B. Notes de cours

1. BOOTO EKIOENA, Notes de cours d'UML, L1 Info, ISC-Kinshasa, 2012-2013, Inédit.

2. KOLA MASALA, Notes de cours d'initiation à l'informatique, ISC/GOMBE, G1 Info, 2008-2009, inédit

3. MPUTU KINSALA, Notes de cours de technique de base de données, ISC/GOMBE G3 Info, 2004-2005 inédit

4. MUKUNA BWATSHIA, Notes de cours d'initiation à la recherche scientifique, ISC/GOMBE, G2 Info, 2009-2010, inédit

5. MVIBUDULU LALUYIT et KITOKO Alphonse, Notes de cours de MAI, ISC/GOMBE, G2 Info, 2009-2010, inédit.

6. DISONAMA J., Notes de cours de système d'exploitation II, G2 INFO, ISC-Gombe, 2009-2010, Inédit.

C. Sites Web

144

1. www.developpez.com

2. www.commentçamarche.net

Table des matières

IN MEMORIAM ii

Epigraphe iii

REMERCIEMENTS iv

Résumé v

Abstract Erreur ! Signet non défini.

SIGLES ET ABREVIATIONS vii

LISTE DES FIGURES viii

LISTE DES TABLEAUX x

Avant-propos xi

INTRODUCTION 1

1. Problématique 2

2. Hypothèse 2

3. Choix et intérêt du Sujet 3

4. Délimitation du sujet 3

5. Méthodes et techniques utilisées 3

6. Canevas du travail 4

Ière Partie : Cadrage du projet et Approche théorique 6

Chapitre I : Planning prévisionnel de réalisation du projet 7

Section 1 : Généralités 7

Section 2 : Ordonnancement du projet 7

2.1. Identification des tâches et délais 7

2.2. Détermination des niveaux 8

2.4. Détermination des dates au plutôt (T_x) 9

2.5. Détermination des dates au plus tard (Tx) 9

2.6. Graphique potentiel 10

2.7. Calculs des marges de tâches non critiques 10

Chapitre 2 : Fondements conceptuels 12

Section1. Concepts informatiques de base 12

1.1. Notion du système 12

1.1.1. Définition 12

1.1.2. Organisation du système dans l'entreprise 13

1.1.2.1. Système de pilotage 13

145

1.1.2.2. Système d'information 14

1.1.2.3. Système Opérant 14

1.2. La notion de base de données 15

1.2.1. Définition 15

1.2.2. Architecture d'une base de données (SGBD) 15

1.2.3. Importance de la base de données 19

Section 2. Concepts relatifs à la modélisation orientée objet 19

2.1. Approche Objet 19

2.2. Processus unifié 22

2.3. Notion de classe et objet 24

2.4. L'Encapsulation 26

2.5. La notion d'Héritage 26

2.6. Abstraction 27

2.7. Polymorphisme 27

II^ème Partie : Etude préalable 28

Chapitre I : Présentation de l'institut supérieur de commerce de Kinshasa 29

Section 1. Dénomination et situation géographique 29

Section 2. Aperçu historique 29

Section 3. Missions et objectifs 30

Section 4 : Organisation et fonctionnement 31

4.1. Organisation : 31

4.2. Fonctionnement 32

4.3. Organigramme de l'Institut Supérieur de Commerce de Kinshasa 35

Chapitre II : Analyse de l'existant 36

But 36

Section 1. Description des activités du Secrétariat Général Académique 36

Section 2 : Organisation et fonctionnement 36

2.1. Organisation 36

2.2. Fonctionnement 37

Section 3 : Etudes des postes de travail 40

3.1. Recensement des postes de travail 40

3.2. Description des postes de travail 41

Section 4 : Etudes des documents utilisés 45

4.1. Recensement des documents 45

146

4.2. Présentation des documents		45
Section 5. Etude des moyens de traitement des informations		48
5.1. Moyens Matériels		49
5.2. Moyens Humains		49
5.3. Moyens Financiers		50
Section 6. Etude de la circulation des informations		51
6.1. Diagramme de flux		51
Section 7. Diagnostic de l'existant et recherche de la solution		58
7.1. Diagnostic de l'existant		58
7.1.1. Les points forts du système actuel		58
7.1.2. Les points faibles du système actuel		58
7. 2. Recherche des solutions		59
7.2.1. Ebauche des solutions		59
7.2.2. Choix de la meilleure solution		61
Section 8 : Présentation du projet		62
8.1. Grands choix techniques		62
8.2. Spécification des besoins fonctionnels		62
8.3. Spécification des besoins opérationnels		63
8.4. Spécification des besoins non fonctionnels		64
IIIème Partie : Phase de la conception du Nouveau Système d'information		65
Chapitre I : Capture initiale des besoins		66
1.1. Identification des acteurs du système		66
1.2. Identification des messages		68
1.2.1. Liste des messages que le système envoi aux acteurs		68
1.2.2. Liste des messages que les acteurs envoient au système	68
1.3. Diagramme de contexte		69
1.3.1. Diagramme de contexte dynamique		69
1.3.2. Diagramme de contexte statique		70
Chapitre II : Capture des besoins fonctionnels		71
2.1. Diagramme de cas d'utilisation		71
2.1.1. Identification des cas d'utilisation		71
2.1.2. Réalisation de Diagramme de cas d'utilisation		71
2.1.3. Fiche de description des cas d'utilisation		73
2.2. Diagramme dynamique		84

147

2.3. Package de spécification fonctionnelle 89

2.5. Diagramme de cas d'utilisation affinés 95

Chapitre III : Capture des besoins techniques 97

3.1. Configuration matérielle 97

3.2. Style de déploiement 98

3.3. Cas d'utilisation technique 99

3.4. Couche logicielle 100

3.5. Cas d'utilisation techniques détaillés 101

Chapitre IV : Analyse fonctionnelle 105

4.1. Diagramme de classes complétées 105

4.2. Diagramme de classes optimisées 105

4.3. Liste de scénarios 108

4.4. Diagramme d'états 111

4.5. Diagramme d'interactions 114

Chapitre V : Conception Générique 117

5.1. Framework design patterns mécanismes 117

5.2. Modèle logique 118

5.3. Modèle d'Exploitation de la conception technique 120

5.4. Modèle de Configuration logicielle 121

5.4. Présentation et justification du choix des langages de développement 122

Chapitre VI : Conception Préliminaire 123

6.1. Conception du déploiement 123

6.2. Conception du modèle d'exploitation 124

6.3. Organisation du modèle logique 127

6.4. Conception des interfaces 129

6.5. Conception de la structure de présentation 130

Chapitre VII : Conception Détaillée 135

7.1. Modèle logique de conception détaillée 135

7.2. Développement de la configuration logicielle détaillée 136

CONCLUSION 142

Bibliographie 143

Table des matières 144

ANNEXE 149

148

149

ANNEXE

150

Quelques pages web de l'application

1. Boite de connexion

151

2. Pages web

152

153

Les écritures du code

Entité Departement

<?php

namespace Library\Entities;

class Departement extends \Library\Entity { protected $Libelle_Dept, $Id_Section;

const LIBELLEDEPT_INVALIDE = 0; const IDSECTION INVALIDE = 1;

_

public function isValid(){

return !(empty($this->Libelle_Dept)||empty($this->Id_Section));

}

public function setLibelle_Dept($Libelle_Dept){ if (!is_string($Libelle_Dept))

{

$this->erreurs[] = self::LIBELLEDEPT_INVALIDE;

}

else

{

$this->Libelle_Dept=$Libelle_Dept;

}

}

public function setId_Section($Id_Section){ if (!is_int($Id_Section))

{

}

else

{

}

$this->erreurs[] = self::IDSECTION_INVALIDE;

$this->Id_Section=$Id_Section;

}

public function Libelle_Dept(){ return $this->Libelle_Dept;

}

public function Id_Section(){ return $this->Id_Section;

}

}

?>

}

154

Manager Departement

<?php

namespace Library\Models;

use Library\Entities\Departement;

abstract class DepartementManager extends \Library\Manager {

abstract public function count();

abstract protected function add(Departement $departement); abstract protected function modify(Departement $departement); public function save(Departement $departement)

{

if ($departement->isValid())

{

$departement->isNew() ? $this->add($departement) : $this->modify($departement);

}

else

{

throw new \RuntimeException('Le département doit être validé pour être enregistré');

}

}

abstract public function getList($debut = -1, $limite = -1); abstract public function getDetail($debut = -1, $limite = -1); abstract public function getUnique($id);

}

?>

Manager Departement PDO

<?php

namespace Library\Models;

use Library\Entities\Departement;

class DepartementManager_PDO extends DepartementManager {

public function count(){

return $this->dao->query('SELECT COUNT(*) FROM table_classe')->fetchColumn();

}

protected function add(Departement $departement){

$requete = $this->dao->prepare('INSERT INTO table_departement SET Libelle_Dept =:libelle_dept, Id_Section=:id_section');

$requete->bindValue(':libelle_dept', $departement-
>Libelle_Dept());

$requete->bindValue(':id_section', $departement->Id_Section()); $requete->execute();

}

protected function modify(Departement $departement){

$requete = $this->dao->prepare('UPDATE table_departement SET Libelle_Dept =:libelle_dept, Id_Section=:id_section WHERE Id_Dept = :id');

$requete->bindValue(':libelle_dept', $departement-
>Libelle_Dept());

$requete->bindValue(':id_section', $departement->Id_Section()); $requete->bindValue(':id', $departement->id(), \PDO::PARAM_INT); $requete->execute();

155

public function getList($debut = -1, $limite = -1){

$sql = 'SELECT Id_Dept as id,Libelle_Dept, Id_Section FROM table_departement ORDER BY Id_Dept DESC';

if ($debut != -1 || $limite != -1)

{

$sql .= ' LIMIT '.(int) $limite.' OFFSET '.(int) $debut;

}

$requete = $this->dao->query($sql);

$requete->setFetchMode(\PDO::FETCH_CLASS | \PDO::FETCH_PROPS_LATE, '\Library\Entities\Departement');

$listeDepartement = $requete->fetchAll();

$requete->closeCursor(); return $listeDepartement;

}

public function getDetail($debut = -1, $limite = -1){

$sql = 'SELECT Id_Dept as id,Libelle_Dept, b.Libelle_Section FROM table_departement as a inner join table_section as b on a.Id_Section=b.Id_Section';

if ($debut != -1 || $limite != -1)

{

$sql .= ' LIMIT '.(int) $limite.' OFFSET '.(int) $debut;

}

$requete = $this->dao->query($sql);

$requete->setFetchMode(\PDO::FETCH_CLASS | \PDO::FETCH_PROPS_LATE, '\Library\ViewModels\DepartementView');

$listeDepartement = $requete->fetchAll();

$requete->closeCursor(); return $listeDepartement;

}

public function getUnique($id){

$requete = $this->dao->prepare('SELECT Id_Dept as id,Libelle_Dept, Id_Section FROM table_departement WHERE Id_Dept = :id');

$requete->bindValue(':id', (int) $id, \PDO::PARAM_INT); $requete->execute();

$requete->setFetchMode(\PDO::FETCH_CLASS | \PDO::FETCH_PROPS_LATE, '\Library\Entities\Departement');

if ($departement = $requete->fetch())

{

return $departement;

}

return null;

}

}

?>

156

Controlleur Departement

<?php

namespace Applications\Backend\Modules\Departement;

class DepartementController extends \Library\BackController{ public function executeIndex(\Library\HTTPRequest $request)

{

$this->page->addVar('title', 'Gestion des departements');

$manager = $this->managers->getManagerOf('Departement'); $this->page->addVar('listeDepartement', $manager->getDetail()); $this->page->addVar('nombreDepartement', $manager->count());

}

public function executeUpdate(\Library\HTTPRequest $request)

{

if ($request->postExists('Libelle_Dept')||$request->postExists('Id_Section'))

{

$this->processForm($request);

}

else

{

$this->page->addVar('departement', $this->managers->getManagerOf('Departement')->getUnique($request->getData('id')));

}

$this->page->addVar('title', 'Modification d\'un departement');

$manager = $this->managers->getManagerOf('Section'); $this->page->addVar('listeSection', $manager->getlist());

}

public function executeInsert(\Library\HTTPRequest $request)

{

if ($request->postExists('Libelle_Dept')||$request->postExists('Id_Section'))

{

$this->processForm($request);

}

$manager = $this->managers->getManagerOf('Section'); $this->page->addVar('listeSection', $manager->getlist()); $this->page->addVar('title', 'Ajout d\'un departement');

}

public function processForm(\Library\HTTPRequest $request)

{

$Departement = new \Library\Entities\Departement( array(

'Libelle_Dept' => $request-

>postData('Libelle_Dept'),

'Id_Section' => (int)$request-

>postData('Id_Section')

)

);

if ($request->postExists('id'))

157

{

$Departement->setId($request->postData('id'));

}

if ($Departement->isValid())

{

$this->managers->getManagerOf('Departement')->save($Departement);

$this->app->user()->setFlash($Departement->isNew() ? 'Le d&eacute;partement a bien &eacute;t&eacute; ajout&eacute; !' : 'Le d&eacute;partement a bien &eacute;t&eacute; modifi&eacute; !');

$this->app->httpResponse()->redirect('/admin/departement');

}

else

{

$this->page->addVar('erreurs', $Departement->erreurs());

}

$this->page->addVar('Departement', $Departement);

}

}

?>

Vues Departement

Formulaire de saisie département

<form class="formoid-default-skyblue" style="background-color:#FFFFFF;font-size:14px;font-family:'Open Sans','Helvetica Neue','Helvetica',Arial,Verdana,sans-serif;color:#666666;max-width:480px;min-width:150px" method="post">

<p style="text-align:center;">

<?php if (isset($erreurs) &&

in_array(\Library\Entities\Departement::LIBELLEDEPT_INVALIDE, $erreurs)) echo 'Libell&eacute; departement est invalide.<br />';

if (isset($erreurs) &&

in_array(\Library\Entities\Departement::IDSECTION_INVALIDE, $erreurs)) echo 'La section est invalide.<br />';

?>

</p>

<table align="center">

<div class="title"><?php

if(isset($departement) && !$departement->isNew())

{

?><h2>Modifier D&eacute;partement</h2> <?php

}

else

{

?>

<h2>Ajout D&eacute;partement</h2> <?php

}

?>

</div>

<tr>

<td> <input class="large" type="hidden" name="id" value="<?php if

(isset($departement)) echo $departement['id']; ?>"/></div>

158

<label class="title">Libell&eacute; D&eacute;partement<span

class="required">*</span></label></td>

<td><input class="large" type="text" name="Libelle_Dept"

required="required" value="<?php if (isset($departement)) echo

$departement['Libelle_Dept']; ?>" placeholder="Libelle Dept"/></td>

</tr>

<tr>

<td><label class="title">Section<span class="required">*</span></label></td>

<td><span><select name="Id_Section" required="required">

<option value="-1">Selectionner la section</option>

<?php

if (isset($listeSection)&& !empty($listeSection)){

foreach ($listeSection as $section)

{

?>

<option value="<?php echo $section->id();?>"<?php if

((isset($departement))&&(isset($section))&&($section-

>id()==$departement['Id_Section']) ){ echo "selected";}?>> <?php echo

$section['Libelle_Section']?></option>

<?php }}else{echo "No data";}?>

</select><i></i></span></td>

</tr>

<tr>

<td></td>

<?php

if(isset($departement) && !$departement->isNew())

{

?>

<td> <div class="submit"><input type="submit" value="Modifier"/></div></td> <?php

}

else

{

?>

<td><div class="submit"><input type="submit" value="Ajouter"/></div></td>

<?php

}

?>

</tr>

</table></form>

Vue d'insertion département

<?php require '_form.php';?>

</div>

<div class="footer"></div></div>

</div></div></div></div>

<div id="footer" role="contentinfo">

<p id="legal">Copyright &copy; 2014 Herve Lepeya. Tous droits r&eacute;serv&eacute;s.</p></div>

<div role="navigation" id="navFull"> <ul><li class="active"><a href="/admin/" class="scTrack:SRD:Nav:a01">Accueil</a> <ul><li class="active"><a href="/admin/agence" class="scTrack:SRD:Nav:h39">Classe</a><ul> <li class="active"><a href="/admin/agence-insert.html" class="scTrack:SRD:Nav:h40">Saisie Classe</a></li>

<li><a href="/admin/classe" class="scTrack:SRD:Nav:h41">Liste Classe</a></li>

159

</ul></li>

<li ><a href="/admin/section" class="scTrack:SRD:Nav:h43">Section</a>

<ul>

<li ><a href="/admin/section-insert.html" class="scTrack:SRD:Nav:h44">Saisie

Section</a></li>

<li><a href="/admin/section" class="scTrack:SRD:Nav:h44">Liste

Section</a></li>

</ul>

</li>

<li ><a href="/admin/departement"

class="scTrack:SRD:Nav:h43">D&eacute;partement</a>

<ul>

<li ><a href="/admin/departement-insert.html"

class="scTrack:SRD:Nav:h44">Saisie D&eacute;partement</a></li>

<li><a href="/admin/departement" class="scTrack:SRD:Nav:h44">Liste

D&eacute;partement</a></li>

</ul>

</li>

<li ><a href="/admin/devise" class="scTrack:SRD:Nav:h43">Cours</a>

<ul>

<li ><a href="/admin/devise-insert.html" class="scTrack:SRD:Nav:h44">Saisie

Cours</a></li>

<li><a href="/admin/devise" class="scTrack:SRD:Nav:h44">Liste Cours</a></li>

</ul>

</li>

<li ><a href="/admin/agent" class="scTrack:SRD:Nav:h43">Profil Usager</a>

<ul>

<li ><a href="/admin/agent-insert.html" class="scTrack:SRD:Nav:h44">Saisie

Profil</a></li>

<li><a href="/admin/agent" class="scTrack:SRD:Nav:h44">Liste Profils</a></li>

</ul>

</li>

<li ><a href="/admin/ip" class="scTrack:SRD:Nav:h43">IP</a>

<ul>

<li ><a href="/admin/ip-insert.html" class="scTrack:SRD:Nav:h44">Saisie

IP</a></li>

<li><a href="/admin/ip" class="scTrack:SRD:Nav:h44">Liste IP</a></li>

</ul>

</li>

</ul>

<li ><a href="/admin/session" class="scTrack:SRD:Nav:h43">Session</a>

<ul>

<li ><a href="/admin/session"

class="scTrack:SRD:Nav:h44">Connect&eacute;s</a></li>

</ul> </li>

<li><a href="/admin/changepassword.html" class="scTrack:SRD:Nav:a03">Reglage</a> <ul>

<li><a href="/admin/changepassword.html" class="scTrack:SRD:Nav:h44">Change Mot de Passe</a></li>

</ul>

</li>

</ul>

</div>

</div>

<script type="text/javascript">if(typeof PAYPAL != 'undefined'){

PAYPAL.core.Navigation.init(); }</script></div><script type="text/javascript"

160

src="js/widgets.js"></script><script type="text/javascript" src="js/jquery.js"></script><script type="text/javascript" src="/js/passwordRecovery.js"></script><script type="text/javascript" src="js/hostedpayments.js"></script><script type="text/javascript" src="/js/pageBlockingUnsafeBrowsers.js"></script><script type="text/javascript" src="js/mid.js"></script><script type="text/javascript">PAYPAL.tns.loginflow = 'p\x2fgen\x2flogin';PAYPAL.tns.flashLocation = 'https\x3a\x2f\x2fwww\x2epaypal\x2ecom\x2fen\x5fUS\x2fm\x2fmid\x2eswf';</scri pt><script type="text/javascript" src="js/bid.js"></script> <script type="text/javascript">

</body></html>

Vue Liste département

<div class="datatable">

<div class="title"><h3>Il y a actuellement &nbsp; <span><?php echo '<b></b>'; ?></span></h3></div>

<div style="overflow: visible;" class="tableWrapper" id="tableWrapperID"> <table id="transactionTable" summary="Tableau de Envoi ." align="center" border="0" cellpadding="0" cellspacing="0">

<tr><th>D&eacute;partement</th><th>Section</th><th>Action</th></tr> <?php

if(isset($listeDepartement) && $listeDepartement!=null ){

foreach ($listeDepartement as $departement)

{

echo '<tr><td>', $departement['Libelle_Dept'], '</td><td>',

$departement['Libelle_Section'],'</td><td><a href="departement-update-',

$departement['id'], '.html">Editer</a></td></tr>', "\n";

}

}else{?>

<tr><td class="noResults" headers="details" colspan="11" nowrap="">-

Aucun nouvel objet -</td>

</tr>

<?php }

?>

</table>

</div>

</div>

</div>

<div class="footer"></div></div>

</div></div></div></div>

<div id="footer" role="contentinfo">

<p id="legal">Copyright &copy; 2014 CRFI. Tous droits

r&eacute;serv&eacute;s.</p></div>

<div role="navigation" id="navFull">

<ul><li class="active"><a href="/admin/"

class="scTrack:SRD:Nav:a01">Accueil</a>

<ul><li class="active"><a href="/admin/agence"

class="scTrack:SRD:Nav:h39">Classe</a><ul>

<li class="active"><a href="/admin/classe-insert.html"

class="scTrack:SRD:Nav:h40">Saisie Classe</a></li>

<li><a href="/admin/classe" class="scTrack:SRD:Nav:h41">Liste Classe</a></li>

</ul></li>

<li ><a href="/admin/section" class="scTrack:SRD:Nav:h43">Section</a>

<ul>

<li ><a href="/admin/section-insert.html" class="scTrack:SRD:Nav:h44">Saisie

Section</a></li>

161

<li><a href="/admin/section" class="scTrack:SRD:Nav:h44">Liste Section</a></li>

</ul> </li> <li ><a href="/admin/departement" class="scTrack:SRD:Nav:h43">D&eacute;partement</a>

<ul>

<li ><a href="/admin/departement-insert.html" class="scTrack:SRD:Nav:h44">Saisie D&eacute;partement</a></li>

<li><a href="/admin/departement" class="scTrack:SRD:Nav:h44">Liste D&eacute;partement</a></li>

</ul>

</li>

<li ><a href="/admin/devise" class="scTrack:SRD:Nav:h43">Cours</a>

<ul>

<li ><a href="/admin/devise-insert.html" class="scTrack:SRD:Nav:h44">Saisie

Cours</a></li>

<li><a href="/admin/devise" class="scTrack:SRD:Nav:h44">Liste Cours</a></li>

</ul>

</li>

<li ><a href="/admin/agent" class="scTrack:SRD:Nav:h43">Profil Usager</a>

<ul>

<li ><a href="/admin/agent-insert.html" class="scTrack:SRD:Nav:h44">Saisie

Profil</a></li>

<li><a href="/admin/agent" class="scTrack:SRD:Nav:h44">Liste Profils</a></li>

</ul>

</li>

<li ><a href="/admin/ip" class="scTrack:SRD:Nav:h43">IP</a>

<ul>

<li ><a href="/admin/ip-insert.html" class="scTrack:SRD:Nav:h44">Saisie

IP</a></li>

<li><a href="/admin/ip" class="scTrack:SRD:Nav:h44">Liste IP</a></li>

</ul>

</li>

</ul>

<li ><a href="/admin/session" class="scTrack:SRD:Nav:h43">Session</a>

<ul>

<li ><a href="/admin/session"

class="scTrack:SRD:Nav:h44">Connect&eacute;s</a></li>

</ul> </li>

<li><a href="/admin/changepassword.html" class="scTrack:SRD:Nav:a03">Reglage</a> <ul>

<li><a href="/admin/changepassword.html" class="scTrack:SRD:Nav:h44">Change Mot de Passe</a></li>

</ul>

</li> </ul> </div> </div> <script type="text/javascript">if(typeof PAYPAL != 'undefined'){ PAYPAL.core.Navigation.init(); }</script></div><script type="text/javascript" src="js/widgets.js"></script><script type="text/javascript" src="js/jquery.js"></script><script type="text/javascript" src="/js/passwordRecovery.js"></script><script type="text/javascript" src="js/hostedpayments.js"></script><script type="text/javascript" src="/js/pageBlockingUnsafeBrowsers.js"></script><script

162

type="text/javascript" src="js/mid.js"></script><script

type="text/javascript">PAYPAL.tns.loginflow =

'p\x2fgen\x2flogin';PAYPAL.tns.flashLocation =

'https\x3a\x2f\x2fwww\x2epaypal\x2ecom\x2fen\x5fUS\x2fm\x2fmid\x2eswf';</scri

pt><script type="text/javascript" src="js/bid.js"></script>

<script type="text/javascript">

function Code(n){

//alert(n.checked)

var active;

if(n.checked){

active=1;}

else

{

active=0;

}

$.ajax({

url: "/admin/agencestatus-"+n.value+"-"+active+".html",

beforeSend: function( xhr ) {

// xhr.overrideMimeType( "text/plain; charset=x-user-defined" );

//xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest");

}

})

.done(function( data ) {

$( "#results" ).text(data);

if ( console && console.log ) {

console.log( "Sample of data:", data.slice( 0, 6000 ) );

}

})

.fail(function( jqXHR, textStatus ) {

alert( "Request failed: " + textStatus);

});

}

</script>

</body></html>