Memoire Online - Developpement et integration d'un systeme de gestion integrée pour la gestion des établissements scolaires cas du complexe scolaire l'age d'or

DEVELOPPEMENTD'UNE SOLUTION DE GESTION INTEGREE POUR LA GESTION D'UN ETABLISSEMENT SCOLAIRE

Travail de fin d'Etude présenté et défendu en vue deL'obtention du grade d'Ingénieur en Sciences Informatiques.

L'Université Méthodiste au Katanga n'attend ni approuver ni désapprouver les opinions personnelles du candidat

EPIGRAPHE

« Les systèmes informatiques n'ont jamais été autant au centre de la stratégie des entreprises qu'aujourd'hui. Les fonctionnalités qu'ils offrent, leur facilité d'utilisation, leur ?abilité, leur performance et leur robustesse sont les qualités reines qui permettent aux entreprises d'être compétitives. L'ingénierie du logiciel fournit sans cesse de nouvelles technologies facilitant la mise en oeuvre de ces systèmes tout en accroissant leurs qualités ».

DEDICACE

REMERCIEMENTS

Lui, qui nous accorde le souffle de vie, lui qui nous accorde l'opportunité de voir un nouveau jour se lever, lui qui nous garde, lui qui intervient dans toutes nos activités en générale, et dans nos études en particulier, lui qui nous a permis de terminer nos études universitaires à l'UMK dans cinq ans, que l'honneur, la gloire et la grâce lui soient rendu. Merci Seigneur Dieu.

A l'église méthodiste-unie, d'avoir mis à notre disposition l'Université Méthodiste au Katanga, pour assurer la formation des cadres universitaires dans notre cher et beau pays la RDC ; nous remercions par cette même occasion le PO, docteur Révérend KASAP'Owan, l'Evêque de l'Eglise méthodiste-unie.

Nos remerciements vont au conseil d'administration de l'Université Méthodiste au Katanga ainsi qu'à toute autorité académique, d'avoir contribué et veiller en même temps à notre formation d'ingénieur en informatique, pendant cinq d'études. Par-là, nous remercions le Recteur de l'Université le PO. KONGOLO Chijika, le P.A SUL a Nawej, secrétaire Général Académique, le P. PITHSI Ngoy Kazadi, Secrétaire Administratif, l'Administrateur de Budget l'Ass NZAM Mwinkeu ; Nos plus sincèresremercient vont de plus à la faculté de qui nous a formé, le Doyen de la faculté le P.A MUTEBA Mayembe Elie, le vice doyen de la faculté, Master Mike NYIRONGO Banda, le secrétaire de la faculté l'Assistant MUTUYA Agay. Nous ne pouvons pas nous permettre d'oublier de remercier dans cette section l'appariteur central de l'UMK, Monsieur Paul KAMANGA Kashiki.

Au corps professoral de la faculté des sciences informatiques de l'Université Méthodiste au Katanga, Professeurs, Chefs des travaux, Assistants, Chargés de cours et/ou Chargés de pratiques professionnels, particulièrement, au Professeur BAVUEZA Daniel, au CT Dieudonné YAV Muchail, à l'Ass. Hervé MAMBWE Kazwiba, Ass. Landry MBAY Kanyimbu, Ass.Trésor POYO Ramazani, Ass. Gauthier SULA Mashimbo et Ass.Bernard KAMONA Kipili qui ont sans doute participé et contribué directement à notre formation.

Nous tenons à exprimer nos plus sincèresremerciements au Professeur, Docteur MUTEBA Mayembe Elie et l'Assistant NZAM Mwinkeu, respectivement Directeur et co-directeur, pour avoir encadré ce travail de fin d'études. Leur disponibilité, leurs conseils éclairés et leur soutien nous ont été d'une aide inestimable et ont largement contribué à notre formation. Nous n'oublierons certainement jamais cette extraordinaire collaboration.

Les marques d'amour, indéfectible soutien moral, spirituel, matériel, physique scientifique, sacrifices, non seulement pendant nos cinq d'études universitaires, mais pendant toute notre existence. Je remercie mes parents NGOY wa Ilunga Grégoire et NTALAJA Ngoie Christine, qui ont choisis de nous conduire dans cette voix de chercheur et scientifiques ; Avoir des parents comme eux, ce n'est pas seulement une grâce, mais aussi une fierté.

A vous mes frères et soeurs, qui nous ont vu grandir depuis notre bas âge, Marlene MUTOMBO Kasongo, Enoch MAKOBOKasungami, Guershom Esdras NGOY wa Ilunga, Esther MANGI Museba, Martine KABANGE Muteba, Dorcas MWADI Kasongo, John KANYEMBO Sambwa, Daniel KASONGO, Divina NTALAJA, Christelle KYALWE et Benjamin-Lighten LEMBALEMBA. A vous, oncles, tantes, cousins et cousines Papa KANYEMBO Sambwa, Maman Jacqueline MUSEBA, Maman Solange BANZE, Papa SESE Lefeke, Astanel MASTAKI, Elie KANYEMBO, Shekina MUSHAME Mande, Enoch MAMBWE ; Merci à vous.

Nous adressons une pensée amicale à toutes les personnes avec qui nous avons sympathisé ensemble en auditoire, au laboratoire, à la bibliothèque, au logement, etc., à commencer par Pax MUTONDO Kaulu, Stéphane MALAMBA, Carlos MAKOBO, Hornelle KABWANG, Julia BILEMO, Naomie KAM Kabash, Evodie NALEMBE, Séraphin MAFEFE, Chancelle MAKOKE, Hadassa MULIEJI, Emmanuel MUSOLO, Léa TSHISOLA.Il est maintenant clair que nos échanges, via notre plate-forme collaborative, ont élargi le spectre de nos recherches et ont renforcé l'approfondissement de nos relations.

Nous remercions sincèrement tous les membres de la promotion, pour leur chaleureux accueil et pour les bons moments passés ensemble et la bonne ambiance que nous avions entretenus pendant toutes ces cinq d'études.

Enfin, à tous ceux, de près ou de loin dont leurs noms ne figurent pas sur cette liste, et qui nous ont soutenus d'une manière ou d'une autre dans la rédaction de ce travail, nous le sommes infiniment reconnaissants et nous les adressons nos sincères remerciements.

SIGLES ET ABREVIATIONS

TABLE DES ILLUSTRATIONS

TABLE DES MATIÈRES

1. INTRODUCTION GENERALE

I. Justification de la recherche

Aujourd'hui l'enseignement est devenu un pas vers la révolution du monde, ceci dit ; il fournit des étapes très avancées pour tout être humain, dans le but de pouvoir se familiariser avec les notions importantes d'une discipline quelconque de la science, en RDC ; notre pays, l'enseignement se poursuit sous plusieurs angles, généralement quatre ; parmi lesquels nous citons ; le degré inferieur ou élémentaire ou encore primaire, le degré moyen ou secondaire, le degré supérieur ou universitaire, ainsi que le degré professionnel. L'enseignement secondaire, emmène l'apprenant vers un nouveau monde scientifique en l'initiant au domaine quelconque de la science. Le but poursuivit est de faire connaitre à l'apprenant les notions ainsi que les connaissances de base d'une discipline choisie.Cette tache attribuée à l'enseignement secondaire, devient de plus en plus complexe, du fait que les écoles se retrouvent dans l'obligation de pouvoir gérer un grand nombre d'informations, stockées non seulement de jour en jour, semaine en semaine, ou de mois en mois, mais encore plus d'années en années ; la sauvegarde d'un grand nombre d'informations perturbent la plupart d'établissement scolaire actuellement.

L'informatique est définie comme étant une science de traitement automatique et rationnel de l'information circulant dans une organisation à l'aide des outils que nous appelons « ordinateur ». Faciliter la gestion d'un établissement scolaire, en optimisant les qualités de services ; rapidité, exactitude et précision, est l'une de taches les plus importantes de l'informatique ; L'ordinateur est devenu un objet de consommation courante, distribué dans les grandes surfaces (critère certain de diffusion dans toutes les classes sociales). Ce tableau un peu de la situation ne doit cependant pas nous faire oublier que la diffusion de l'informatique est une réalité qui présente de nombreux aspects positifs.^1(*)

Le but de cette recherche est de mener une analyse et étude approfondie sur le système d'information du complexe scolaire l'Age d'or, pour comprendre sa complexité dans le but de présenter une solution qui répondre à la problématique constaté, et aux besoins que présente ladite institution.

Le choix de cet objet d'étude à l'Age d'or, est motivé par un besoin que nous avions constaté, le besoin étant de faire communiquer l'information dans différents services, nous nous sommes donné le courage d'en apprendre beaucoup plus sur ce besoin constaté. Mener ces recherches en nous orientant dans le domaine de conception de système d'information et génie logiciel, n'est pas un hasard, c'est que nous visons non seulement à présenter une solution consistante pour l'institution en besoin, mais aussi expérimenter le métier d'un ingénieur en système d'information, qui consiste à présenter un aspect problème/solution dans des organisations.

A. II. L'état de la question

B. La connaissance antérieure à la recherche

1. Les idées de Brigitte DENIS

L'auteur propose une classification multidimensionnelle et panoramique des usages pédagogiques de l'ordinateur. Elle les met en lien avec différents paradigmes d'apprentissage/enseignement. Divers exemples illustrent la catégorisation proposée.

2. Les idées de Charles DUCHATEAU

L'auteur dit dans cet ouvrage, que cette communication tentera de cerner les causes des échecs répétés d'introduction des nouvelles technologies de l'information et de la communication (NTIC) dans le milieu scolaire. Pour cela, il comparera les deux univers en présence ; celui de l'école d'une part, celui des nouvelles technologies d'autre part. Dans le monde de l'usage de l'environnement informatisés, tout se conjugue au futur et même au futur antérieur, c'est une fuite en avant permanente, les versions de logiciels se succédant sans arrêt, devenant de plus en plus gourmandes en terme de capacité du matériel requis, obligeant à une mise à jour permanente des savoirs et savoir-faire des utilisateurs... c'est aussi un univers où contrairement aux assertions des constructeurs et des vendeurs de logiciels, les instruments sont complexes et les environnements de travail artificiel.^2(*)

3. Les idées de Pascal PEROTIN

Les progiciels de gestion intégrée, instruments de l'intégration organisationnelle ? Etude de cas ;

L'auteur a posé la question du Progiciel de Gestion Intégrée, outil utilisable dans le cadre du changement organisationnel. L'analyse en profondeur d'un cas de mise en place d'un PGI a permis de vérifier que le PGI permet de réaliser l'objectif d'intégration. L'auteur a vu à quelles conditions en décrivant la stratégie employée par la direction du projet, et en mettant en évidence des facteurs déterminants du succès ; le PGI est associée au BPR, pour jouer le rôle d'un outil de gestion aux mains des dirigeants afin de réaliser un changement organisationnel. Cette vision téléologique du changement met en avant le potentiel du PGI pour intégrer et standardiser l'organisation dans les circonstances spécifiques qu'il a pu observer.^3(*)

4. Les idées de Sukkhleen KAUR BAWEJA

Uses of educationnal Enterprise ressource planning, traduit par « l'utilisation des progiciels de gestion intégrée éducationnels »;

L'auteur a mené des études sur les Progiciels de Gestion Intégrée, qui sont une solution logicielle utilisée dans les systèmes d'information, aussi dans les affaires et le milieu éducatif. Il a présenté dans ce document les progiciels de gestion intégrée éducationnel, en précisant leurs modules et leurs objectifs ; généralement toutes les institutions éducatives, en trouvent les bénéfices de cette intégration, la solution présente un contact Enseignant-Parent-Elève.En sa conclusion les PGI, sont actuellement des outils indispensables non seulement dans des organisations industrielles, mais aussi dans des systèmes d'information scolaire ou éducative, puisqu'ils présentent une cohérence des informations de l'école, entre les acteurs concernés ci-haut cités.^4(*)

5. Les idées de Yaser DALVEREN

Using E-Learning in Enterprise Resource Planning (ERP) Training : A case study to assist curriculum designer in turkey; traduit par « l'utilisation de l'enseignement à distance, assistance à l'élaboration de curriculum en Turquie ».

L'auteur a donné des résultats sur des recherches effectuées sur l'intégration des PGI dans un parcours universitaire pour l'enseignement à distance ; il présente ensuite que la mise en fonction d'un PGI au sein d'une institution universitaire, permet de suivre les parcours académique des étudiants, en représentant les études faites, dans un domaine quelconques.^5(*)

C. La synthèse des idées des auteurs

1. Synthèse de Brigitte DENIS

Selon elle, l'utilisation de l'outil informatique, en occurrence l'occurrence serait indispensable, pour permettre un suivi du modèle Apprentissage/Enseignement ; en utilisant des logiciels adaptés pour les informations qui transitent.

2. Synthèse de Charles DUCHATEAU

Charles DUCHATEAU présente une idée paradoxale, il insiste sur le pourquoi est-il bien difficile, d'intégrer des logiciels dans un milieu éducatif, suite aux versions de logiciels qui accroissent du jour au lendemain, et l'indisponibilité des éditeurs de logiciels, conduit à ce que les écoles, n'arrivent pas à intégrer des logiciels.

3. Synthèse de Pascal PEROTIN

Selon Pascal PEROTIN ; les organisations actuellement présentent une bonne organisation, lorsqu'un progiciel de gestion intégrée se trouve dans le système ; sur ce, il a donné les approches de l'intégration est basé actuellement sur les PGI.

4. Synthèse de Sukkhleen KAUR BAWEJA

Le présent auteur aprésenté, les avantages d'un PGI dans un milieu éducatif, qui est celui de faciliter la communication ENSEIGNANT-PARENT-ELEVE ;

5. Synthèse de Yaser DALVEREN

Les PGI, permettent aux institutions éducatives, de faire un suivi sur le parcours académiques des étudiants qui font les études à distances, ces outils facilitent les étudiants à avoir une facilité dans la génération de leurs parcours académiques.

D. L'évaluation des connaissances antérieures

Les auteurs présentent ici l'importance des progiciels de gestion intégrée en milieu éducatif. Ils présentent les objectifs des PGI, les modules pour un PGI éducationnel, l'intégration d'un PGI pour le parcours du cursus académique pour l'enseignement à distance, ainsi que l'organisation dans une Enterprise pour y intégrer un progiciel de gestion intégrée. Ces solutions ne suffisent pour une gestion améliorée d'une école, d'une université, bref d'une institution éducative, le besoin dans de milieu scolaire, est aussi la gestion des effectifs des élèves, la comptabilité, etc. l'intégration d'un PGI en milieu éducatif ne doit pourtant pas se limiter qu'aux modules de parcours académique.

E. L'orientation de la recherche

Ayant évalué les idées des auteurs sur les PGI en milieu éducatif, nous avons choisis d'orienter nos recherches vers une intégration, incluant les modules importants d'une école, qui n'est pas seulement la communication Enseignent-Parent-Elève, ou le suivi du parcours scolaire ; mais une intégration basée sur la gestion d'une école, les modules varieront en fonction de besoins présents sur le champ de la recherche en occurrence la gestion de la comptabilité, le suivi élève, etc.

II. La problématique

Ladite organisation (L'Age d'or) présente un besoin de communication entre différents services ; actuellement il possède d'un système d'information informatisé, qui gères en utilisant des technologies différentes les différents services, entre autre, la comptabilité, les cours, le personnel, les élèves, etc.

Parmi ces technologies nous avons remarqué en occurrence MS Excel et MS Access. L'utilisation de ces technologies implique une répétition des mêmes informations, dans plusieurs classeurs au besoin. Les informations qui transitent dans les services différents, ne sont pas faciles à être contrôlées et vérifiées par les agents concernés ; ce qui nous causent les conséquences telles que : La lenteur dans le traitement de ces données, Le non transparence des données qui circulent, les données de la comptabilité par exemple, Les statistiques ainsi que les traces des opérations ne sont pas gérés, inexactitude des élèves par année, dans des classes différentes, perte de certains fichiers de la comptabilité, ce qui conduit à un recours aux reçus de paiement parfois le carnet des reçus n'est plus disponible ou que les élèves ont également perdu les copies.

Parfois le système de conserve pas les archives (MS Excel), en fin d'année, considéré comme un nouvel exercice, le fichier ancien est écrasé en créant un nouveau fichier, ce qui à ce que l'encodage des mêmes informations, parfois avec ajout de quelques nouvelles, est constaté ; Le traitement des réponses est trop lourd, les informations demandées prennent du temps à être retournées ; Les mêmes données sont collectées plusieurs fois, dans des systèmes différents ; Les données stockées avec redondance sont incohérentes dans les différents fichiers et bases de données ;

III. La question de la recherche

La question de la recherche sera utilisée comme guide, dans la conduite de ces recherches scientifiques, pour cela nous nous sommes posés la question de savoir :

- Comment devons-nous procéder pour donner une solution consistante aux problèmes qu'a actuellement le complexe scolaire l'Age d'or ?

IV. Hypothèses de la recherche

Partant de cette question, nous suggérons de procéder par une étude de solutions pouvant s'adapter aux types de problèmes ici présents de mettre en place une plateforme logicielle, qui pourra faciliter l'administration des services du complexe scolaire l'Age d'or, en mettant en place une technique de centralisation de données (Créer un système de stockage de données), qui sera accessible dans chaque service les nécessitant, en plus ce système permettra de produire des statistiques dans les services tels que la comptabilité, les inscriptions, la rémunération, etc.

V. Méthodologie

A. Méthodes scientifiques

Tout au long de ces recherches, nous avons utilisé les méthodes scientifiques qui nous donnerons une démarche pour présenter et mener une recherche scientifique, en respectant les exigences d'une institution universitaire (la nôtre UMK) ;

B. Méthodes d'ingénierie

Et pour suivre les processus métier du système cible, nous allons utiliser la méthode d'ingénierie 2TUP. 2TUP signifie « 2 Track Unified Process» .C'est un processus qui répond aux caractéristiques du Processus Unifié. 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 d'information.^6(*)

C. Techniques de collecte de l'information

Nous avons également utilisé certaines techniques, pour poursuivre cette recherche, entre autre la technique d'interview, qui ouvrira un canal entre nous et l'Age d'or en posant de questions sur notre objet d'étude ; la technique d'observation, qui consistera à se rendre sur le champ cible pour observer les processus métier et l'administration de l'école en étant nous-même sur le lieu. Nous allons également nous servir de la technique documentaire, en utilisant les différents documents officiels à l'école, nous comprendrons la complexité de ce système ainsi que leur système de gestion.

D. Sources d'information

Enfin, pour collecter les informations dont nous aurons besoins, nous allons utiliser certaines sources d'informations, de préférences internet ; cette source elle est pertinente, car elle nous permet de récolter certaines données en consultant des pageset de sites web ; nous allons également utiliser la bibliothèque, un endroit pour consulter des livres au besoin et enfin la documentation de l'école.

VI. Délimitation du sujet

Ainsi pour notre cas nous avions effectué nos recherches au Complexe Scolaire l'Age d'or; ladite institution est située dans la province du Haut-Katanga à plus oumoins 120 Km de la ville de Likasi.

Dans cette partie nous établirons le temps dans lequel nous étions en train d'effectuer nos recherches dans ladite institution, nos recherches se sont déroulées au cours de l'année académique 2018-2019, la solution proposée pourra donc être en fonctionnement jusqu'à une nouvelle version qui pourra venir après un délai selon les besoins des utilisateurs.

VII. Subdivision et structure

Pour appréhender le développement de notre thème d'étude, nous avons voulu subdivisé ce mémoire en 4 grandes parties, qui couvrent nos chapitres, mises a part l'introduction et la conclusion ; nous avons entre autre :

- Le premier chapitre, intitulé CONSIDERATION THEORIQUE ; ce chapitre traite des notions théoriques non seulement du thème d'étude, mais également du domaine dans lequel nous avons mené ces recherches

- Le deuxième chapitre, PRESENTATION DU CHAMP D'ETUDE ET ANALYSE DE L'EXISTANT, qui traite sur l'étude détaillée du système d'information dans lequel nous appliquons les fruits de ces recherches, nous avons présenté ici ; les différents besoins que présente le Complexe Scolaire Age d'or dans le but de pouvoir améliorer sa qualité de gestion.

- Le troisième chapitre, ANALYSE ET CONCEPTION OBJET DE LA NOUVELLE SOLUTION, qui a porté sur l'étude approfondie de besoins techniques et fonctionnelle, pour ensuite arrivé à une conception objet de la nouvelle solution proposée précédemment.

- Le dernier chapitre intitulé ARCHITECTURE TECHNIQUE ET CODAGE, présente dernièrement l'infrastructure réseau, les classes dialogues et quelques classes contrôle ; pour illustrer la mise en place de la nouvelle intégrée.

CHAPITRE PREMIER

CONSIDERATIONS THEORIQUES

INTRODUCTION

Ce chapitre est typiquement théorique, parlant des généralités, nous parlerons dans cette première partie du travail des notions théoriques sur ce qui constituent notre thème, le domaine d'étude et le domaine technique ; nous serons amenés à parler des systèmes d'information et des progiciels de gestion intégrée ainsi que d'autres notions théoriques.

VIII. Théorie sur les systèmes d'information et le génie logiciel

A. Théorie sur les Systèmes d'information

Un système d'information noté SI, est un ensemble structuré des ressources matérielles, logicielles, humaines, des données et de réseaux qui recueille, traite, transforme et diffuse de l'information dans une entreprise.^7(*)Un système est un élément fini dont le périmètre est une frontière qui le sépare de son environnement.Il interagit avec son environnement grâce à des flux d'informations entrantes, qu'il va traiter et restituer àl'environnement sous forme de flux d'informations sortantes.Le système va générer des informations qui rendent compte de son comportement à la fois au sein del'environnement, mais aussi pour son propre compte.

Un système communique.Un système a besoin, pour prendre des décisions, de stocker et de traiter des informations.

1. Typologie des systèmes d'information

On peut distinguer différents types de systèmes d'information suivant le support de l'information et les outils utilisés :

- Les SI informels : ils « dépendent de règles de comportement non prédéterminées »^8(*). Ce sont, par exemple, les discussions autour de la machine à café, les rumeurs ou les réseaux sociaux sur Internet.

- Les SI formels : à l'inverse des SI informels, les SI formels sont structurés et fonctionnent conformément à des règles prédéterminées. Ils sont en général supportés par des outils dédiés construits par l'homme. Ce sont, par exemple, les SI informatisés.

- Les SI informatisés : ils se fondent sur les technologies informatiques et de télécommunication.

- Les SI manuels : ils utilisent des moyens « traditionnels » de type papier et crayon

Désormais, avec la montée en puissance des nouvelles technologies, le terme « SI » indique généralement un système d'information formel informatisé.

2. Les Technologies de l'Information et la Communication Educationnelles

Depuis les années quatre-vingts, les TICE n'ont pas manqué d'alimenter les réflexions dans le monde entier. Les années Internet et les multiples mutations engendrées n'ont fait que les renforcer. Baron, Bruillard et bien d'autres ont investi ce domaine et offert d'abondantes ressources les traitant sous des angles aussi divers que variés. L'école primaire, le collège, le lycée, l'enseignement supérieur et la formation à distance aussi bien en France qu'à l'international en ont constitué les principaux axes.

Les Technologies de l'Information et de la Communication pour l'Enseignement (TICE) recouvrent les outils et produits numériques pouvant être utilisés dans le cadre de l' éducation et de l' enseignement (TICE = TIC + Enseignement). Les TICE regroupent un ensemble d'outils conçus et utilisés pour produire, traiter, entreposer, échanger, classer, retrouver et lire des documents numériques à des fins d'enseignement et d' apprentissage.

Pour esquisser une typologie rapide des ressources apportées par les TICE, on retiendra six familles de ressources :

- Logiciels généraux (texte, son, image numériques) utilisés à des fin d'enseignement ou d'apprentissage.

- Banques de données et d'informations (documents numériques : textes, images, vidéos...) pouvant être utilisés comme supports de cours et d'illustrations par l'enseignant ou pouvant servir comme source d'information pour les élèves lors de recherche documentaire.

- Manuels numériques enrichis de données nouvelles (vidéos...) et d'outil de navigation unique ⁵.

- Outils de travail personnel ( exerciseurs, laboratoires personnels) capables de s'adapter au niveau des apprenants, à leurs objectifs et à leurs parcours.

- Simulateurs, systèmes experts, permettant de modéliser les phénomènes étudiés et d'en faire varier les paramètres.

Les exemples d'outils existants sont nombreux. Ils vont du simple didacticiel, à la plateforme d'apprentissage en ligne. Et surtout les méthodes d'appropriation des outils et l'usage de ces outils sont excessivement variables d'un "Éducateur" à l'autre. Une pédagogie des TICE prenant sa source dans les savoirs issus des sciences de l'éducation se façonne actuellement.

B. Théorie sur le Génie logiciel

1. La crise du logiciel et la naissance du Génie logiciel

a. La crise du logiciel

Le terme « crise du logiciel », « software crisi » en anglais ; désigne la situation générale qui caractérisa les échecs de développement logiciel dans les années soixante et soixante-dix. Dans son essence le terme fait référence à la difficulté d'écrire des programmes informatiques corrects, compréhensibles et vérifiables. On retiendra trois principales causes à l'origine de ce phénomène :

Ce qui est paradoxal à notre époque et ce, depuis les années 60, c'est la difficulté de produire des logiciels de qualité à bon prix et dans des délais raisonnables. Les causes de la crise du logiciel sont nombreuses : Il y a d'abord les raisons liées à l'essence, à la nature même du logiciel, ce que nous appelons les propriétés essentielles du logiciel, particulièrement sa virtualité. Il y a ensuite les raisons liées aux problèmes qui entourent la production du logiciel, ce que nous appelons les propriétés accidentelles du logiciel, par exemple les besoins des utilisateurs qui changent sans cesse, la demande de fonctionnalités sophistiquées, les courts délais de livraison, l'inexpérience des développeurs, etc.^10(*)

b. La naissance du Génie Logiciel

Pour résoudre la crise du logiciel, il fallait comprendre tous les phénomènes sociotechniques observés autour de la production de logiciels et proposer une technique industrielle de production de logiciels s'appuyant sur la connaissance de ces phénomènes. Il fallait donc une science et une technique de la production du logiciel. Ce qui conduisit les universitaires, les praticiens et les organisations divers réunis sous les hospices de l'OTAN en 1968 et 1969 en Allemagne à créer la discipline nommée « Software Engineering », « génie logiciel » en français, discipline scientifique et technique chargée des deux missions.

La crise du logiciel est toujours d'actualité. Les facteurs explicatifs du phénomène sont permanents : il y a toujours des clients pressés, des utilisateurs incompris, des informaticiens pas ou peu compétents, et le logiciel est toujours virtuel. Ce qui fait de l'étude du génie logiciel une exigence permanente dans la formation de l'informaticien.^11(*)

2. Le logiciel et le cycle de vie du logiciel

a. Le logiciel

Le premier concept à saisir est le concept de logiciel, software en anglais. On peut saisir le concept sur le plan étymologique ou selon les usages courants. Étymologiquement, le terme logiciel dérive du mot logique, par opposition à physique ou matériel. Il fut créé en 1972 du terme anglais software d'après l'encyclopédie Wikipédia. La traduction française a été officialisée par un arrêté publié au Journal officiel français du 17 janvier 1982. Dans l'usage courant, le terme peut être employé au sens particulier ou au sens général. Au sens particulier, le terme logiciel désigne un programme ou un paquet de programmes installés sur un ordinateur afin d'y effectuer une tâche. Ici, on fait référence à une entité informatique distinguable et dénombrable (un logiciel, deux logiciels, des logiciels, nos logiciels, leurs logiciels, ce logiciel-ci, ce logiciel-là).^12(*)

b. Le cycle de vie d'un logiciel

Le « cycle de vie d'un logiciel » (en anglais software lifecycle), désigne toutes les étapes du développement d'un logiciel, de sa conception à sa disparition. L'objectif d'un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en oeuvre.Voici l'image qui illustre le cycle de vie d'un logiciel, avec toutes ses étapes :

IX. LES PROGICIELS DE GESTION INTEGREE (PGI)

Des années soixante-dix, les premiers progiciels ont vu le jour, notamment dans le domaine comptable en offrant de nouvelles approche en parallèle avec le développement spécifique réalisé par les informaticiens de l'entreprise. Ils étaient le plus souvent la reprise d'une application développée pour une entreprise et adaptée à une autre du même secteur d'activité ; leur dépendance par rapport à un environnement technique était importante, en effet, ils ne fonctionnent que sur les ordinateurs ayant un système d'exploitation d'un constructeur donné.

Les progiciels se développèrent durant des années quatre-vingt, en luttant contre le syndrome « il existe pas deux entreprises pareilles », et tout en restant prisonnier de leur domaine technique. A partir du domaine comptable et financier ce développement, se poursuivit vers le domaine de la paie et de la GPAO et enfin celui des ventes ; les progiciels devinrent donc des briques applicatives répondant aux besoins d'un domaine fonctionnel spécifique, le finance, les ventes, la production.

La fin des années quatre-vingt, de début des années quatre-vingt-dix virent apparaitre les premières installations, en France les premières ERP, SAP R/2, le plus souvent dans les filiales françaises de groupes allemands.^13(*)

X. Les méthodes, la notation et le langage de programmation

A. Les méthodes utilisées

1. Utilisation de la méthode scientifique

Désigne l'ensemble des canons guidant ou devant guider le processus de production des connaissances scientifiques, qu'il s'agisse d'observations, d'expériences, de raisonnements, ou de calculs théoriques. À la suite de cette découverte scientifique, ou parallèlement, les chercheurs tentent d'expliquer le phénomène par des hypothèses. Une hypothèse, pour être scientifiquement admissible, doit être réfutable, c'est-à-dire doit permettre des expérimentations qui la corroborent (la confirmation) ou la réfutent (l'infirmation).

Ce sont les preuves répétées et confirmées par d'autres chercheurs, diverses et variées, qui confortent une hypothèse. C'est son acceptation par de nombreux chercheurs qui conduit à un consensus sur l'explication du phénomène. L'acceptation de l'hypothèse peut se manifester par la citation de travaux précédents qui servent souvent de repères de validation5. Elle devient ainsi la nouvelle théorie consensuelle sur le phénomène considéré et enrichit ou remplace une théorie précédemment admise (ou plusieurs, ou en partie). La démarche qui nous a permis de justifier l'objectif notre recherche c'est la méthode inductive qui part d'observations ou d'interviews et mène à une hypothèse ou un modèle scientifique.^14(*)

2. La méthode de 2TUP

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.^15(*)

La branche gauche (fonctionnelle) comporte ; la capture des besoins fonctionnels, qui produit un modèle des besoins focalisé sur le métier des utilisateurs. Elle qualifie au plus tôt le risque de produire un système inadapté aux utilisateurs. De son côté, la maîtrise d'oeuvre consolide les spécifications et en vérifie la cohérence et l'exhaustivité l'analyse, qui consiste à étudier précisément la spécification fonctionnelle de manière à obtenir une idée de ce que va réaliser le système en termes de métier. Les résultats de l'analyse ne dépendent d'aucune technologie particulière.

- La capture des besoins techniques, qui recense toutes les contraintes et les choix dimensionnant la conception du système. Les outils et les matériels sélectionnés la conception préliminaire, qui représente une étape délicate, car elle intègre le modèle d'analyse dans l'architecture technique de manière à tracer la cartographie des composants du système à développer ;

- la conception détaillée, qui étudie ensuite comment réaliser chaque composant ;

- l'étape de codage, qui produit ces composants et teste au fur et à mesure les unités de code réalisées ;

- l'étape de recette, qui consiste enfin à valider les fonctions du système développé.^16(*)

- ainsi que la prise en compte de contraintes d'intégration avec l'existant conditionnent généralement des prérequis d'architecture technique ;

- la conception générique, qui définit ensuite les composants nécessaires à la construction de l'architecture technique. Cette conception est la moins dépendante possible des aspects fonctionnels. Elle a pour objectif d'uniformiser et de réutiliser les mêmes mécanismes pour tout un système.

L'architecture technique construit le squelette du système informatique et écarte la plupart des risques de niveau technique. L'importance de sa réussite est telle qu'il est conseillé de réaliser un prototype pour assurer sa validité.

B. La notation et le langage de modélisation

1. Le Langage de modélisation UML

L'UML se définit comme un langage de modélisation graphique et textuel. Il est destiné à comprendre et décrire des besoins, spécifier et documenter les systèmes, et sert aussi à esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue. L'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.^17(*)

UML s'articule autour de 13 diagrammes qui servent à la modélisation des systèmes, dont 7 diagrammes comportementaux et 6 diagrammes structurels.

a. Les diagrammes structurels

- Diagramme de classes : Il montre les briques de base statiques : classes, associations, interfaces, attributs, opérations, généralisations, etc.

- Diagramme d'objets : Il montre les instances des éléments structurels et leurs liens à l'exécution.

- Diagramme de packages : Il montre l'organisation logique du modèle et les relations entre packages.

- Diagramme de structure composite : Il montre l'organisation interne d'un élément statique complexe.

- Diagramme de composants : Il montre des structures complexes, avec leurs interfaces fournies et requises.

- Diagramme de déploiement : Il montre le déploiement physique des « artefacts » sur les ressources matérielles.

b. Les diagrammes comportementaux

- Diagramme de cas d'utilisation : Il montre les interactions fonctionnelles entre les acteurs et le système à l'étude.

- Diagramme de vue d'ensemble des interactions : 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 : Il montre la séquence verticale des messages passés entre objets au sein d'une interaction.

- Diagramme de communication : Il montre la communication entre objets dans le plan au sein d'une interaction.

- Diagramme de temps : 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é : Il montre l'enchaînement des actions et décisions au sein d'une activité.

- Diagramme d'états : Il montre les différents états et transitions possibles des objets d'une classe.^18(*)

2. Le langage de programmation

Les langages de programmation permettent de décrire d'une part les structures des données qui seront manipulées par l'appareil informatique, et d'autre part d'indiquer comment sont effectuées les manipulations, selon quels algorithmes. Ils servent de moyens de communication par lesquels le programmeur communique avec l'ordinateur, mais aussi avec d'autres programmeurs ; les programmes étant d'ordinaire écrits, lus, compris et modifiés par une équipe de programmeurs ³. La possibilité d'écriture abstraite libère l'esprit du programmeur d'un travail superflu, notamment de prise en compte des spécificités du matériel informatique, et lui permet ainsi de se concentrer sur des problèmes plus avancés ².

XI. Théorie sur les données et le stockage de données

A. Théorie sur les données

1. Théorie sur les bases de données

Une base de données désigne un objet informatique qui permet de stocker et de gérer les données en les structurant ; dans le but de permettre d'effectuer assez simplement de dénombrements, des statistiques et/ou des recherches à l'intérieur des données stockées en suivant des critères bien définis.^19(*)

2. Théorie sur les Big Data

Les Big data englobe tout terme pour décrire toute collection de données tellement volumineuse et complexe qu'il devient difficile de la traiter en utilisant des outils classiques de traitement d'applications.^20(*) Les Big data est donc une collection de données dont la taille dépasse la capacité de capture, de stockage, de gestion et d'analyse des systèmes de gestion de bases de données classiques.

Les Big data sont dit en un concept de 3V (Volumétrie, Vélocité, Variété) ;

- Vélocité : Flux continus de données (Capteurs, appareils mobiles, réseaux sociaux) ;

MOT	DESCRIPTION
MAP REDUCE	Principe de programmation qui consiste à distribuer et paralléliser le traitement sur plusieurs noeuds
HADOOP, HDFS (Hadoop Distributed File System)	Hadoop est une plateforme informatique open source de la fondation apache, capable de gérer/traiter des Big data sur une architecture distribuée. HDFS est le système de fichier de base qui supporte Hadoop
NOSQL	Technologie qui se différencie à la notion relationnelle de données, adaptée à de données peu structurées ;
HBase, Cassandra, MongoDB, Couche DB, Redis, NE04J	SGBD qui supporte l'approche d'interrogation de données NoSQL ;
SAS, Talend, R, Python, SPSS	Outils et/ou environnement de programmation et analyses adaptés au Big Data
Cloud Computing	Ensemble de processus permettant d'offrir un espace de stockage sous formes de serveurs, accessibles à distance sous forme de location.

B. Théorie sur le stockage de données

Le logiciel qui permet à un utilisateur d'interagir avec une base de données est un système de gestion de base de données (SGBD). Il permet principalement d'organiser les données sur les supports périphériques et fournit les procédures de recherche et de sélection de ces mêmes données. Pour aboutir à ce résultats, l'utilisateur décrit en termes abstraits ce qu'il souhaite faire sur les données, laissant le soin su système d'effectuer les taches de recherche en fonction de la représentation et de l'organisation des données sur les supports physiques.

CHAPITRE DEUXIEME

PRESENTATION DU CHAMP D'ETUDE ET ANALYSE DE L'EXISTANT

I. PRESENTATION DU CHAMP D'ETUDE

A. Présentation

Le complexe scolaire l'Age d'or est une école d'obédience chrétienne se trouvant dans la ville Lubumbashi, province du haut Katanga ; ayant comme objectifs la formation de nouveaux cadres scientifiques dans différents domaines. Le complexe scolaire l'Age d'or comporte trois sections, dont maternelle, une primaire et une autre secondaire.

L'école fonctionne tous les jours c'est-à-dire du Lundi au Vendredi de 8h00' à 11h30' pour la section maternelle et de 7h30' à 12h30' pour la section primaire et secondaire

B. Aperçus historique

Le complexe scolaire l'Age d'or, que nous avons présenté ci-dessus, a été créé vers le début de l'année scolaire 2013-2014.

C. Organisation administrative

II. ANALYSE DE L'EXISTANT

A. Etude préliminaire

1. Identification des acteurs

Le but ici est de constituer et Vérifiez que les acteurs communiquent bien directement avec le système, par émission et/ou réception de messages. Une erreur fréquente consiste à répertorier en tant qu'acteurs des entités externes qui n'interagissent pas directement avec le système, mais uniquement par le biais d'un des véritables acteurs.^21(*) Pour notre cas voici entre autres les acteurs :

- Le Directeur des études : Il fait un suivi sur le déroulement de l'enseignement au sein de l'Ecole

- Le secrétaire : il travaille sous la direction directe du préfet des études, ayant comme mission la rédaction des fiches d'inscriptions pour les élèves, l'envoi et la réception des courriers.

- Le préfet des études : il est le représentant direct de l'établissement, il coordonne toutes les activités au sein de l'institution et établit le rapport à l'inspection.

- Le parent : le parent représente la famille qui envoie leurs enfants dans cette institution, il peut être son tutelle ou autre personne habilité à veiller sur l'élève.

- L'élève : il est l'élément moteur de l'éducation, considéré comme le client de l'établissement scolaire

- Le promoteur : comme nous travaillons dans une institution éducative privée, le promoteur est le garant de l'établissement ; il est sensé gérer et coordonner sur toutes les activités qui se passe dans cette institution.

- Le comptable : il gère les activités ainsi que les flux financiers de l'établissement

- Le directeur de discipline : il est chargé de veiller sur la conduite des enfants (élèves).

2. Modèle de contexte statique

Tous les messages (système ? acteurs) identifiés précédemment peuvent être représentés de façon synthétique sur un diagramme, que l'on peut qualifier de diagramme de contexte dynamique.

3. Les Diagrammes d'activité

Dans cette partie du mémoire, nous allons devoir présenter les diagrammes d'activité du système de gestion de notre champ d'étude, sur ce, nous présenterons cela en trois diagrammes d'activités différents.

a. Diagramme d'activité Gestion de la scolarité

Ce processus est déclenché ; lorsque la préfecture fixe et publies la date des inscriptions, ensuite l'élève demande l'inscription à la préfecture, une fois la demande reçu, il dépose son dossier qui est vérifié, s'il s'agit d'un faut dossier la demande est annulée, sinon s'il s'agit d'un nouvel élève la préfecture enregistre les informations de l'élève en remplissant sa fiche d'inscription et la remet à l'élève qui va avec à la comptabilité. La comptabilité vérifie ensuite la fiche d'inscription et lui fixe les frais d'inscriptions. L'élève paie, la comptabilité lui établit le reçu d'inscription. Pour les anciens élèves, une fois qu'ils se présentent à la préfecture pour la réinscription, la préfecture vérifies son dossier et le conduit à la comptabilité là qu'on va lui attribuer le reçu d'inscription après versement. Une fois que l'élève est inscrit pendant les études, la direction des études fait un suivi ELEVE, en élaborant des fiches disciplinaires en cas de punitions infligées à l'élève (retards, absences, ou toutes autres formes de punitions). L'élève ou même les parents de l'élève peuvent consulter ses fiches disciplinaires.

b. Diagramme d'activité SUIVI DE PAIEMENT

Ce processus est lancé lorsque le promoteur établit un plan de paiement annuel et par promotion, une fois que le plan de paiement établit le comptable publies le plan de paiement, et attends lorsqu'un élève viendra se présenter pour demander un paiement. En cas de demande de paiement l'élève se présente à la comptabilité, qui lui vérifie, s'il est vérifiés, il verse l'argent avec le motif concerné, ensuite la comptabilité lui établit et lui livre un reçu de paiement. En fin du mois, le comptable établit un rapport de paiement mensuel, qui est livré à l'administration.

c. Processus métier GESTION DE COURS

Ce processus commence lorsque le Directeur des Etudes établit un programme de cours par classe, qui est validé par le préfet. Une fois le programme validé le Directeur des Etudes affecte les cours aux enseignants et informe chacun sur ses cours attribués ; et chacun consulte en rapport ses cours. Après le Directeur des études établit un horaire de cours hebdomadaire sur accort de son chef direct, qui est le Préfet des Etudes. NB : les élèves peuvent consulter le programme de cours de leur promotion en cas de besoin.

d. Processus métier SUIVI DES EVALUATIONS

Ce processus est déclenché par l'enseignant qui enregistre les cotes obtenues par les élèves aux travaux. Une fois que les cotes sont enregistrées, en fin de période les enseignants déposent les cotes à la direction des études pour vérification ; les cotes sont vérifiées par le préfet, après le conseil administratif, constitué du préfet, directeur des études ainsi que du corps enseignant délibère les cotes et rend public les résultats qui seront à la portée des élèves et de des parents des élèves.

B. Capture de besoins

1. Besoins fonctionnels

La capture des besoins fonctionnels est la première étape de la branche gauche du cycle en Y. Elle formalise et détaille ce qui a été ébauché au cours de l'étude préliminaire. Elle est complétée au niveau de la branche droite du Y par la capture des besoins techniques et prépare l'étape suivante de la branche gauche : l'analyse.

a. Diagramme de cas d'utilisation fonctionnel du système

Le diagramme de cas d'utilisation, est un diagramme UML qui permet de modéliser les besoins des utilisateurs du système informatique en conception. Ce diagramme est un diagramme pivot du processus unifié avec la méthode 2TUP, car l'un des principes de 2TUP est que cette dernière est orientée utilisateur.^22(*) L'identification des cas d'utilisation une première fois, nous donne un aperçu des fonctionnalités futures que doit implémenter le système. Cependant, il nous faut plusieurs itérations pour ainsi arriver à constituer des cas d'utilisation complets. D'autres cas d'utilisation vont apparaître au fur à mesure de la description de ceux-là, et l'avancement dans le « recueil des besoins fonctionnels ».

Pour constituer les cas d'utilisation, il faut considérer l'intention fonctionnelle de l'acteur par rapport au système dans le cadre de l'émission ou de la réception de chaque message. En regroupant les intentions fonctionnelles en unités cohérentes, on obtient les cas d'utilisations.

a. Description des cas d'utilisation (Diagramme de séquences systèmes)

Un cas d'utilisation représente un ensemble de séquences d'interactions entre le système et ses acteurs. Pour décrire la dynamique du cas d'utilisation, le plus naturel consiste à recenser toutes les interactions de façon textuelle. Le cas d'utilisation doit par ailleurs avoir un début et une fin clairement identifiés. Il doit préciser quand ont lieu les interactions entre acteurs et système, et quels sont les messages échangés. Il faut également préciser les variantes possibles, telles que les différents cas nominaux, les cas alternatifs, les cas d'erreurs, tout en essayant d'ordonner séquentiellement les descriptions, afin d'améliorer leur lisibilité. Chaque unité de description de séquences d'actions est appelée enchaînement. Un scénario représenteune succession particulière d'enchaînements, qui s'exécute du début à la fin du cas d'utilisation.^23(*)

i. Cas d'utilisation PROGRAMMER COURS

PROGRAMMER COURS
But	Le but de ce cas d'utilisation est de programmer le cours dans une classe et une période donnée, à partir des enseignants disponibles.
Acteurs	Directeur des études (principal)
Préconditions	- Le Directeur des études est authentifié - Il existe au moins une commande confirmée à programmer - Avoir une liste des enseignants, des classes, ainsi que le programme de cours ;
Scenario nominal	Ce cas d'utilisation commence lorsque le Directeur des études demande au système de programmer un cours - Le système affiche la liste de classes disponibles - Le Directeur des études, commence par sélectionner la classe dont le cours devra être programmé - Il spécifie ensuite le cours sur la liste de cours ; - Il valide ensuite le choix du cours qu'il a programmé, et lance la publication aux utilisateurs concernés - Le système valide ces actions et renvoie un message de confirmation
Scenario alternatif	Enchainement(b) : -
Post condition

Les scenarios que nous avons ci-haut explicités, sont alors présentés par le diagramme de séquence ci-dessous :

ii. Cas d'utilisation S'AUTHENTIFIER

S'AUTHENTIFIER
But	Le but de ce cas d'utilisation est de protéger l'accès à la gestion et l'utilisation du système
Acteurs	Directeur des études, Elève, Enseignant, Promoteur, Comptable, Préfet, Administrateur
Préconditions	- Démarrage de l'application - Affichage de la fenêtre d'authentification
Scenario nominal	- L'utilisateur accède à la page d'authentification - L'utilisateur saisit ses coordonnées de connexion au système - Le système vérifie les données fournies - Le système affiche le compte de l'utilisateur
Scenario alternatif	- Lorsque les coordonnées sont incorrectes : § Le système revérifie et affiche un message d'erreur § Le système demande à l'utilisateur de ressaisir ses coordonnées
Post condition	Affichage de la fenêtre principale de gestion concernée (compte de l'utilisateur)

Dans la partie qui suit, nous avons détaillés les scenarios, en montrant son diagramme de séquence :

iii. Cas d'utilisation ELABORER FICHE DISCIPLINAIRE

ELABORER FICHE DISCIPLINAIRE
But	Elaborer des rapports sous formes de fiches disciplinaires, pour faire un suivi sur la conduite de l'élève
Acteurs	Directeur des études
Préconditions	- Etre authentifié - Avoir les informations d'un élève inscrit
Scenario nominal	1. Le Directeur de discipline saisit le code de l'élève 2. Le système recherche les informations de l'élève contenant ce code 3. Le système affiche les informations de l'élève 4. Le Directeur clique sur la commande ajouter fiche disciplinaire 5. Le système affiche le formulaire de la page d'édition de la fiche 6. Le Directeur des études saisit les informations concernant la fiche disciplinaire 7. Le système enregistre ces informations et affiche le message « Fiche ajoutée avec succès »
Scenario alternatif	Si aucun résultat ne correspond à la recherche effectuée 1. Le système affiche un message qu' « aucun élément ne correspond à la recherche effectuée » 2. Le système demande au Directeur de ressaisir l'élément de recherche
Post condition	Quitter la page d'Edition de la fiche disciplinaire

Voici le diagramme de séquence du cas d'utilisation Elaborer fiches disciplinaires :

iv. Cas d'utilisation CONSULTER RESULTATS

CONSULTER RESULTATS
But	Ce cas d'utilisation permet à l'élève de consulter ses cotes en ligne ou en local, via son compte
Acteurs	Elève
Préconditions	Il doit être authentifié à son compte
Scenario nominal	1. L'élève lance la commande de vérification de ses résultats 2. Le système recherche les critères de recherche 3. Le système affiche les critères de recherche 4. L'élève sélectionne un critère de recherche 5. Le système recherche le résultat correspondant 6. Le système affiche les résultats
Scenario alternatif	Si aucun résultat ne correspond à la recherche lancée 1. Le système affiche un message `Aucune cote' et 2. Le scenario reprend au nominal 4
Post condition

v. Cas d'utilisation CREATION D'UN NOUVEAU COMPTE

CREATION D'UN NOUVEAU COMPTE
But	Ce cas d'utilisation permet à l'Administrateur de créer un nouveau compte utilisateur ;
Acteurs	Administrateur
Préconditions	Avoir les coordonnées de l'utilisateur, être authentifié
Scenario nominal	1. L'administrateur lance la création d'un nouveau compte 2. Le système recherche le formulaire d'enregistrement 3. Le système affiche le formulaire d'ajout de l'utilisateur 4. L'administrateur saisit les coordonnées 5. Le système valide la saisie et enregistre l'utilisateur 6. Le système envoie le message d'enregistrement
Scenario alternatif	S'il y a une erreur dans la saisie des données de l'utilisateur :Le système affiche un message d'erreur
Post conditions	Octroyer les droits au nouvel utilisateur

Le cas d'utilisation ajouter un nouveau compte, est bien démontré dans la figure qui suit, avec tous les détails sur les différents scenarios :

Figure 17 Diagramme de séquence du cas d'utilisation CREATION D'UN NOUVEAU COMPTE

vi. Cas d'utilisation FIXER FRAIS DE PAIEMENT

FIXER LES FRAIS DE PAIEMENT
But	Le but de ce cas d'utilisation est de pouvoir élaborer un plan de paiement de frais d'une année
Acteurs	Promoteur
Préconditions	Etre authentifié avec les privilèges « Promoteur »
Scenario nominal	1. Le promoteur demande l'affichage du formulaire 2. Le système génère le formulaire 3. Le système affiche le formulaire 4. Le promoteur sélectionne la classe correspondante et introduit les coordonnées de paiement de l'année 5. Le système valide la saisie et enregistre 6. Le système affiche le plan de paiement 7. Le promoteur lance l'impression du plan ou l'enregistrement au format PDF 8. Le système imprime et/ou enregistre le PDF
Scenario alternatif	Si le promoteur lance l'impression : 1. Le système imprime le plan de paiement 2. Le système affiche un message après impression Sinon si le promoteur lance l'enregistrement au PDF : 1. Le système enregistre 2. Le système affiche le message d'enregistrement
Post conditions

Lorsque le promoteur devra fixer les frais de paiement, le système devra donc suivre et répondre au diagramme de séquence ci-dessous :

vii. Cas d'utilisation GERER COTES ELEVES

GERER LES COTES ELEVES
But	Le but de ce cas d'utilisation est de gérer les différentes cotes obtenues par les élèves dans les cours d'un enseignant.
Acteurs	Enseignant
Préconditions	Etre authentifié, avoir enregistré les cotes
Scenario nominal	1. L'enseignant lance la commande d'affichage de la liste de cotes 2. Le système recherche la liste par classe et par cours 3. Le système affiche la liste de cotes 4. L'enseignant lance la commande tri, par classe et par cours 5. Le système génère la liste triée 6. Le système affiche la liste triée 7. L'enseignant la commande de gestion (ajouter, modifier ou supprimer) 8. Le système traite la commande et affiche un message
Scenario alternatifs	Le scenario nominal 8 (le système traite la commande et affiche un message) : S'il y a une erreur dans la commande lancée : 1. Le système affiche un message d'erreur, 2. Le système demande à l'enseignant de recommencer l'action Sinon : Le système affiche un message de succès
Post conditions	Publier les résultats modifiés

Diagramme de séquence du cas d'utilisation gérer les cotes des élèves, démontrés par la figure suivante :

viii. Cas d'utilisation GERER LE PAIEMENT

GERER LE PAIEMENT
But	Le but ici est de faire un suivi et une gestion des flux financiers, les actions de paiement de frais
Acteurs	Comptable, Promoteur
Préconditions	Le promoteur doit au préalable enregistrer le plan de paiement
Scenario nominal	1. Le comptable lance la demande du formulaire de gestion de paiement 2. Le système recherche le formulaire 3. Le système affiche le formulaire 4. Le comptable lance une commande gestion 5. Le système traite la commande lancée et affiche les résultats de la requête 6. Le comptable lance l'impression du reçu de paiement 7. Le système imprime le reçu et affiche un message d'après impression
Scenario alternatif	Si la commande de gestion est traitée avec succès : Le comptable lance l'impression du reçu Sinon : le comptable relance la commande (Scenario nominal 5)
Post conditions	Aucune

ix. Cas d'utilisation INSCRIRE ELEVE

INSCRIRE ELEVE
But	Le but de ce cas d'utilisation et d'enregistrer les nouveaux élèves inscrits au complexe scolaire l'Age d'or
Acteurs	Préfet des études
Préconditions	Etre authentifié
Scenario nominal	1. Le préfet lance la demande du formulaire d'inscription 2. Le système recherche et affiche le formulaire 3. Le préfet introduit les coordonnées du candidat 4. Le système vérifie les contraintes de validation 5. Le système valide l'inscription 6. Le préfet lance l'impression de la fiche d'inscription 7. Le système imprime la fiche
Scenario alternatif	Scenario nominal 4 : si les contraintes de validation ne sont pas respectées : 1. Le système envoie un message d'erreur au préfet 2. Le système redemande au préfet de recommencer la saisie
Post conditions	Aucune

Voici le diagramme de séquence système, du cas d'utilisation inscrire élève :

x. Cas d'utilisation OCTROYER LES DROITS

OCTROYER LES DROITS
But	Ce cas d'utilisation a pour but, l'octroi de droits aux différents utilisateurs du système, pour leur permettre de manipuler les fonctions qui leur seront données.
Acteurs	Administrateur
Préconditions	Se connecter entant qu'administrateur, Créer compte utilisateur
Scenario nominal	1. L'administrateur lance l'affichage de la liste des utilisateurs 2. Le système recherche la liste 3. Le système affiche la liste des utilisateurs 4. L'administrateur lance la commande (octroyer ou enlever droits) 5. Le système exécute la commande et affiche le message de mise à jour
Scenario alternatif	Aucun
Post conditions	Gérer l'utilisateur

Présentation du diagramme de séquence système, pour le cas d'utilisation octroyer les droits d'accès :

xi. Gérer les profils

GERER LES PROFILS
But	Le but de ce cas d'utilisation est donc de permettre à l'administrateur du système de faire un suivi, sur les comptes des utilisateurs, créer de nouveaux comptes, modifier les comptes existants, ou supprimer les comptes ;
Acteurs	Administrateur
Préconditions	Se connecter entant qu'administrateur, Créer compte Facultatif : octroyer les droits d'accès
Scenario nominal	1. L'administrateur lance la commande d'affichage de la liste des utilisateurs 2. Le système recherche la liste et l'affiche 3. L'administrateur lance la commande gestion 4. Le système exécute la commande 5. Le système affiche le message du traitement de la commande
Scenario alternatif	Scenario nominal 4 : le système exécute la commande de gestion 1. En cas d'une erreur dans l'exécution de la commande 2. Le système affiche un message d'erreur.
Post conditions	Mettre à jour le système de gestion des utilisateurs

b. Organisation de cas d'utilisation

Cette section traite de l'analyse objet du système à réaliser. Le découpage en catégories constitue la première activité de l'étape d'analyse(il s'affine bien sûr de manière itérative au cours du projet). Il se situe sur labranche gauche du cycle en Y et succède à la capture des besoins fonctionnels.

N°	Cas d'utilisation	Acteurs	Package
01	Définir horaire Programmer cours	Directeur des études	Gestion de cours
02	Inscrire élève Elaborer fiche disciplinaire	Préfet, directeur des études	Gestion de la scolarité
03	Fixer les frais de paiement Gérer le paiement	Comptable, promoteur	Gestion de paiement
04	Gérer cotes élèves Consulter résultats	Enseignant, élève, parent	Gestion de cotes
05	Gérer les profils Octroyer les droits Créer un nouveau compte	Administrateur, utilisateurs	Gestion des utilisateurs

3. Besoins techniques

La capture des besoins techniques couvre, par complémentarité avec celle des besoins fonctionnels, toutes les contraintes qui ne traitent ni de la description du métier des utilisateurs, ni de la description applicative. Le modèle de spécification logicielle concerne donc les contraintes techniques telles que nous avons pu les évoquer au chapitre 4. La spécification technique est une activité de la branche droite du Y ; elle est primordiale pour la conception d'architecture.

a. Elaboration du modèle de spécification matérielle

L'expression des prérequis techniques implique également le choix d'un style d'architecture client/serveur. Ce choix conditionne la façon dont seront organisés et déployés les composants d'exploitation du système.

La figure ci-dessus, démontre la présentation du diagramme de spécification logicielle pour le système que nous allons mettre en place.

b. Elaboration du modèle de spécification logicielle

i. Exploitant des Cas d'utilisation techniques

Un cas d'utilisation technique est destiné à l'exploitant. C'est une séquence d'actions produisant une valeur ajoutée opérationnelle ou purement technique.

- l'utilisateur, qui utilise une des applications du système. La majorité des acteurs de la branche fonctionnelle sont donc des utilisateurs dans la dimension technique,

- l'administrateur du système, qui est chargé de déployer et de dépanner le système.

Les cas d'utilisation techniques sont d'abord identifiés en considérant l'attente opérationnelle de chaque exploitant :

- l'utilisateur va travailler avec des entités sous la forme d'objets, ce qui implique la mise en oeuvre des mécanismes de persistance et de gestion de cycle de vie des objets ;

- plusieurs utilisateurs peuvent travailler en parallèle. L'intégrité est le mécanisme qui empêche la mise à jour simultanée d'une même entité par deux utilisateurs différents

- chaque utilisateur bénéficie également d'une gestion des charges au niveau du serveur. Ainsi, les temps de réponse du système ne s'en trouvent pas dégradés en fonction du nombre d'utilisateurs connectés ;

- l'utilisateur doit se connecter et être reconnu du système pour pouvoir y travailler. L'authentification est le mécanisme qui protège le système des intrusions externes ;

- chaque utilisateur doit disposer d'une aide contextuelle qui l'aide à exploiter le système de la manière la plus efficace ;

- le système doit être exploitable ; à ce titre, il faut qu'il soit en mesure de générer des traces et des alertes qui vont faciliter sa maintenance au sein du système informatique global de l'entreprise. C'est cette analyse technique du problème qui permet d'introduire l'administrateur comme autre exploitant du système ;

- l'administrateur ainsi que l'utilisateur sont soumis à des règles de sécurité.

Dans un système client/serveur ces aspects recouvrent l'authentification, l'habilitation, le cryptage, la non-répudiation et l'audit.

ii. Diagramme des Cas d'utilisation techniques

C. Etude des supports d'échanges informationnels

D. Présentation du diagnostic de l'existant

Ci-dessous, voici l'extrait de l'application que l'Age d'or utilise, pour la gestion de frais ainsi que les inscriptions :

Interface qui démontre la gestion de pointage et le suivi de rémunération pour le personnel du complexe scolaire l'âge d'or.

III. CRITIQUES DE L'EXISTANT

Le système informatique existant est fonctionnel présentement, mais il présente des insuffisances de traitement de l'information ; nous allons ci-dessous présenter ces détails :

Performance	Information	Contrôle	Efficacité	Services
Le travail effectué en une grande durée est faible, par rapport à la performance ;	L'information est produite en retard par rapport au moment opportun de son utilisation.	Les données enregistrées ne sont pas correctement éditées ;	Les données sont enregistrées ou copiées avec redondance ;	Le système produit des résultats imprécis.
Le délai d'attente des réponses est long	Les données ne sont pas collectées avec exactitude, elles contiennent des erreurs ;	Les crimes (fraudes, accès et modifications illicites) sont ou peuvent être commis contre les données ;	Les données sont traitées avec redondance ; L'information est produite avec redondance.	Le système produit des résultats inconsistants.
	Les données sont collectées avec redondance les mêmes données sont collectées plusieursfois à des endroits déférents ;	Les données stockées avec redondance sont incohérentes dans les déférents fichiers et bases de données ;	L'exécution de tâches requiert trop d'effort.	Le système produit des résultats non fiables.
	Les données telles que stockées ne sont pas flexibles, il est très difficile d'extraire des informations utiles à partir de ces données ;	Des erreurs de manipulation (traitement) de données sont commises soit par des personnes, soit par des machines,		Le système est difficile à utiliser. Le système embarrasse beaucoup les utilisateurs.

IV. PROPOSITION ET PRESENTATION DE LA NOUVELLE SOLUTION

La solution informatique qu'utilise actuellement le complexe scolaire l'Age d'or, ne satisfait pas totalement les besoins et attentes des utilisateurs, comme nous l'avons détaillés au point précèdent, c'est ainsi que nous proposons une solution centralisée de données qui permettra une gestion intégrée du complexe scolaire. Mettre à la disposition des utilisateurs une base de données commune, qui sera exploitable dans les secteurs de l'institution par les interfaces de gestion métier.

CHAPITRE TROISIEME

ANALYSE ET CONCEPTION OBJET DU SYSTEME DE GESTION INTEGREE POUR LA GESTION DU CS. L'AGE D'OR

INTRODUCTION

Dans ce chapitre il est donc question de parler de l'analyse Objet ainsi que la conception des classes, des interfaces, des tables ainsi que des méthodes, pour le codage de la nouvelle solution à implémenter.

V. ANALYSE OBJET

A. Typologie de classes d'analyse

1. Les classes dialogues

Sont celles qui permettent les interactions entre les utilisateurs du système et le système en question. Ces classes sont plu tard considérées comme les interfaces de l'application.

2. Les classes contrôles

Ces classes contiennent la dynamique de l'application, elles sont là non seulement pour contenir la logique de l'application, mais aussi pour jouer l'intermédiaire entre les classes dialogues et les classes métiers, ou les entités du système.

3. Les classes métiers ou les classes entités

Elles contiennent les objets métiers ; qui proviennent directement du modèle du domaine, tout comme ces classes peuvent provenir du diagramme de cas d'utilisation.

B. Modèle de classe participante

La modélisation ici, concerne le diagramme de classe. Le digramme de classe participante constitue les entités ou les concepts déduits de cas d'utilisation.Le diagramme de classes participantes est important puisqu'il effectue la jonction entre, d'une part, les cas d'utilisation, les modèles de la couche métiers et l'interface avec l'utilisateur. Il semble particulièrement important pour guider la phase de production du livrable final. C'est cette importance qui nous a poussés à concevoir un tel diagramme dans le souci d'une phase de développement claire et efficace. On utilisera alors une implémentation de l'architecture 3-tiers, le pattern Modèle-Vue-Contrôleur (MVC).^24(*)

1. Programmer cours

Ce cas d'utilisation permet au directeur des études, de fixer, d'enregistrer ou de créer techniquement et logiquement les cours, dans les différentes classes.

Figure 28 Diagramme de classe participante du cas d'utilisation Programmer cours

2. Gérer le paiement

C'est ici que toutes les transactions, concernant les paiements des élèves sont gérées, nous utilisons ici les classe plan de paiement et paiement des frais.

3. S'authentifier

Ce cas d'utilisation, est le premier lorsqu'un utilisateur veut accéder à son compte, il permet de sécuriser les données d'un utilisateur à un autre en garantissant la sécurité maximale du système.

4. Elaborer horaire

5. Elaborer les fiches disciplinaires

6. Gérer les cotes des élèves

7. Consulter résultats

8. Fixer les frais de paiement

9. Gérer les inscriptions des élèves

10. Gérer les comptes des utilisateurs

C. Développement du modèle dynamique

Le développement du modèle dynamique constitue la troisième activité de l'étape d'analyse. Il s'agit d'une activité itérative, fortement couplée avec la modélisation statique.

1. Programmer cours

2. Gérer paiement

3. S'authentifier

4. Elaborer Horaire

5. Elaborer les fiches disciplinaires

6. Gérer les cotes des élèves

7. Consulter horaire

8. Consulter résultats

9. Fixer les frais de paiement

10. Gérer les inscriptions des élèves

11. Gérer les comptes des utilisateurs

VI. CONCEPTION OBJET

A. Classes de conception préliminaire

Nous allons attribuer des responsabilités précises de comportement aux classes d'analyse en construisant une vue statique complétée sous forme de diagrammes de classes de conception préliminaire, indépendamment des choix technologiques que nous avons choisis.

La conception préliminaire nous a permis d'affiner et compléter les diagrammes de classes participantes obtenus précédemment pour :

- Ajouter des types aux attributs et aux paramètres et retours des opérations.

- Affiner les relations entre classes: associations (avec indication de navigabilité), généralisations ou dépendances.

B. Classes de conception globale

Le diagramme de packages montre l'organisation logique du modèle et les relations entre packages. Il permet de structurer les classes d'analyse et de conception, mais aussi les cas d'utilisation.

Nous démontrons sur la figure qui suit, l'organisation et les differents paquets qui constituent le nouveau système que nous avons proposés precedemment :

VII. PLANIFICATION DES TACHES DE REALISATION

A. Planification

La planification d'un projet est un outil incontournable pour le management du projet. Elle permet de : Définir les travaux à réaliser, Fixer des objectifs, Coordonner les actions, Maitriser les moyens, Diminuer les risques, Suivre les actions encours, Rendre compte de l'état d'avancement du projet.^25(*)

1. Description des taches

Dans la coordination de projet la tâche constitue le fractionnement élémentaire du travail à fournir pour produire le résultat : une tâche définit le livrable attendu ; sa bonne exécution est dévolue à un responsable identifié ; elle peut se voir allouer des ressources particulières et se voir enserrée dans des contraintes (échéance, durée, conditions d'enclenchement). Il est conseillé d'ajuster le degré de détail des tâches à la périodicité du suivi que l'on sait pouvoir assurer (c'est-à-dire, en principe, à l'autonomie estimée des personnes responsables). Une tâche est réalisée par l'exécution d'une ou plusieurs actions entreprises soit par le responsable seul, soit par les personnes qu'il encadre et de la production desquelles il se porte garant.^26(*)

2. Diagramme de GANTT

Le diagramme de Gantt (Harmonogram Adamieckiego) est un outil utilisé (souvent en complément d'un réseau PERT) en ordonnancement et gestion de projet et permettant de visualiser dans le temps les diverses tâches liées composant un projet (il s'agit d'une représentation d'un graphe connexe, valué et orienté). Il permet de représenter graphiquement l'avancement du projet. Le diagramme de Gantt, couramment utilisé en gestion de projet, est l'un des outils les plus efficaces pour représenter visuellement l'état d'avancement des différentes activités qui constituent un projet.^27(*)

CHAPITRE QUATRIEME

ARCHITECTURE TECHNIQUE ET CODAGE DU SYSTEME DE GESTION INTEGREE POUR LA GESTION DU CS. L'AGE D'OR

I. CHOIX DE TECHNOLOGIES

A. Langage et plateforme de développement

1. Présentation du langage de programmation PHP

Le langage que nous avons choisis pour l'implémentation de la solution proposée, analysée et conçue dans les phases précédentes ; est le langage de programmation PHP. «PHP: Hypertext Preprocessor, plus connu sous son sigle PHP (acronyme récursif), est un langage de scripts libre principalement utilisé pour produire des pages Web dynamiques via un serveur HTTP, mais pouvant également fonctionner comme n'importe quel langage interprété de façon locale, en exécutant les programmes en ligne de commande. PHP dispose depuis la version 5 de fonctionnalités objet complètes. En raison de la richesse de sa bibliothèque, on désigne parfois PHP comme une plate-forme plus qu'un simple langage.»^28(*)

Il y a beaucoup d'informations dans ces quelques lignes, les plus importantes sont mises en évidence dans le texte :

- Il est principalement utilisé sur le Web pour générer des pages dynamiques.

- Il existe autour de PHP un écosystème très riche (bibliothèques, CMS, frameworks, etc.).

2. Fonctionnement de PHP

Même s'il peut être utilisé en ligne de commande, PHP est principalement associé à un serveur Web utilisant le protocole HTTP dans le cadre d'une architecture client/serveur.

Le fonctionnement du langage de programmation PHP est illustré par la figure suivant :

1) Le client, le plus souvent un navigateur Web, fait la demande au serveur d'une page PHP au travers du protocole HTTP.

3) L'interprétation de la page PHP produit une page HTML de résultat fournie au serveur.

Souvent, le code de la page PHP utilise les données stockées dans une base de données afin de générer le résultat HTML. On se trouve alors en présence d'une architecture trois-tiers (navigateur Web, serveur Web/interpréteur PHP, SGBD). Les tiers serveurs Web et SGBD peuvent être hébergés sur des machines distinctes ou regroupés sur une machine unique. Dans ce cas d'une machine unique sous Linux avec Apache comme serveur Web et MySQL comme SGBD, on obtient ce qu'on appelle un serveur LAMP ou WAMP sous Windows.

3. Principales caractéristiques de PHP

La page PHP ci-dessous offre un aperçu des principales caractéristiques du langage.On peut faire les observations suivantes :

- Les variables sont préfixées par le symbole $ et leur typage est dynamique, contrairement à des langages comme C# ou Java où le typage est statique.

- On peut construire un résultat HTML en mélangeant balises HTML et code PHP, ou bien en utilisant l'instruction PHP echo pour générer les balises HTML.

B. Moyen de sauvegarde de données

MySQL est un Système de Gestion de Bases de Données (SGBD) fonctionnant sous Linux et Windows. Les Système de Gestion de Bases de Donnéestels que MySQL permettent de manipuler facilement et avec beaucoup de souplesse un très important volume de données. Toutefois, aussi robuste soit MySQL, il peut être intéressant de récupérer l'ensemble des données que contient notre base de données, pour faire une sauvegarde (backup) ou bien tout simplement pour passer à une autre base de données. On appelle "exportation" le fait de formater dans un fichier (appelé dump) toutes les informations nécessaires à la création d'une base de données identique. A l'inverse, on appelle importation le fait de créer dans un SGBD une nouvelle base de données à partir d'un fichier d'exportation (dump).

MySQL offre un certain nombre d'outils permettant d'exporter ses bases vers d'autres SGBD ou bien de les importer.

II. ARCHITECTURE DE DEPLOIEMENT

La technologie Objet requiert une architecture. C'est cette architecture qui organise les interactions entre objets. On a l'habitude de regrouper ces objets en classes, ces classes en domaines, et ces domaines en couches.

Les couches permettent de présenter l'architecture de l'application. Les équipes de réalisation s'attribuent alors des responsabilités sur le développement de chaque couche. Aussi, si modéliser est indispensable, construire une architecture à couche est un critère de qualité dans le cadre d'un développement Objet. Reste à choisir le nombre de couches et à définir leur contenu.

A. Architecture 3-Tiers

Pour avoir une architecture robuste, modulable et évolutive, il nous faut utiliser le principe de « couche ». Nous allons donc séparer au maximum les différents types de traitement de l'application (Dao, Métier, Présentation).

B. Architecture MVC

L'architecture Modèle Vue Contrôleur (MVC) est une méthode de conception pour le développement d'applications logicielles qui sépare le modèle de données, l'interface utilisateur et la logique de contrôle. Ce modèle d'architecture impose la séparation entre les données, les traitements et la présentation, ce qui donne trois parties fondamentales dans l'application finale : le modèle, la vue et le contrôleur :

- Le Modèle : représente le comportement de l'application : traitements des données, interactions avec la base de données, etc. Il décrit les données manipulées par l'application et définit les méthodes d'accès.

- la Vue : correspond à l'interface avec laquelle l'utilisateur interagit. Les résultats renvoyés par le modèle sont dénués de toute présentation mais sont présentés par les vues. Plusieurs vues peuvent afficher les informations d'un même modèle. Elle peut être conçue en html, ou tout autre « langage » de présentation. La vue n'effectue aucun traitement, elle se contente d'afficher les résultats des traitements effectués par le modèle, et de permettre à l'utilisateur d'interagir avec elles.

- le Contrôleur : prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle. Il n'effectue aucun traitement, ne modifie aucune donnée, il analyse la requête du client et se contente d'appeler le modèle adéquat et de renvoyer la vue correspondant à la demande.

En résumé, lorsqu'un client envoie une requête à l'application, celle-ci est analysée par le contrôleur, qui demande au modèle approprié d'effectuer les traitements, puis renvoie la vue adaptée au navigateur, si le modèle ne l'a pas déjà fait.

Un avantage apporté par ce modèle est la clarté de l'architecture qu'il impose. Cela simplifie la tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le projet. En effet, la modification des traitements ne change en rien la vue. Par exemple on peut passer d'une base de données de type SQL à XML en changeant simplement les traitements d'interaction avec la base, et les vues ne s'en trouvent pas affectées.

III. PRESENTATION DU MODELE LOGIQUE RELATIONNEL

A. Règles de conversion

Afin de pouvoir implémenter une base de données, il faut pouvoir traduire le modèle conceptuel en modèle logique. Cela signifie qu'il faut pouvoir convertir un modèle.

UML en modèle relationnel. Les modèles conceptuels sont suffisamment formels pour que ce passage soit systématisé dans la plupart des cas.

1. Transformation des classes et attributs

a. Transformation des classes

Pour chaque classe non abstraite, on crée une relation dont le schéma est celui de la classe ; la clé primaire de cette relation est une des clés de la classe. Les classes abstraites sont ignorées à ce stade, et n'étant pas instanciables, ne donnent généralement pas lieu à la création de relation.

b. Transformation des attributs

- Pour chaque attribut élémentaire et monovalué d'une classe, on crée un attribut correspondant.

- Pour chaque attribut composite comprenant N sous-attributs d'une classe, on crée N attributs correspondants, dont les noms sont la concaténation du nom de l'attribut composite avec celui du sous-attribut.

- Pour chaque attribut multivalué b d'une classe C, on crée une nouvelle relation RB, qui comprend un attribut monovalué correspondant à b, plus la clé de la relation représentant C ; la clé de RB est la concaténation des deux attributs.

- Dans le cas où le nombre maximum de est fini, et petit, on peut également adopter b la transformation suivante : Classe1(#a,b1,b2,b3,b4,b5,b6,b7,b8,b9,b10).

- Si le nombre d'attributs est infini (b[1..*]) c'est impossible, s'il est trop grand ce n'est pas souhaitable.

2. Transformation des attributs dérivés et méthodes

On ne représente pas en général les attributs dérivés ni les méthodes dans le modèle relationnel, ils seront calculés dynamiquement soit par des procédures internes à la BD (procédures stockées), soit par des procédures au niveau applicatif.

On peut décider (pour des raisons de performance essentiellement) de représenter l'attribut dérivé ou la méthode comme s'il s'agissait d'un attribut simple, mais il sera nécessaire dans ce cas d'ajouter des mécanismes de validation de contraintes dynamiques (avec des par exemple) pour assurer que triggers la valeur stockée évolue en même temps que les attributs sur lesquels le calcul dérivé porte.

Notons qu'introduire un attribut dérivé ou un résultat de méthode dans le modèle relationnel équivaut à introduire de la redondance, ce qui est en général déconseillé, et ce qui doit être dans tous les cas contrôlé.

3. Transformation des associations

- Pour chaque association binaire de type 1..* : on ajoute à la relation côté * une clé étrangère vers la relation côté 1.

- Pour chaque association binaire de type M..* : on crée une nouvelle relation, composée de clés étrangères vers chaque relation associée, et dont la clé primaire est la concaténation de ces clés étrangères.

- La solution la plus simple et la plus générale pour transformer une association 1..1 consiste à traiter cette association 1...1 comme une association 1..*, puis à ajouter une contrainte UNIQUE sur la clé étrangère pour limiter la cardinalité maximale à 1.

- Les attributs de la classe d'association sont ajoutés à la relation issue de l'association *...M.

- Les attributs de la classe d'association sont ajoutés à la relation issue de la classe côté *. Les attributs de la classe d'association sont ajoutés à la relation qui a été choisie pour recevoir la clé étrangère.

Si les deux classes ont été fusionnées en une seule relation, les attributs sont ajoutés à celle-ci.

A. C. Présentation du modèle

Figure 55 Modèle relationnel

IV. IMPLEMENTATION

A. Présentation des classes dialogue

1. Interface d'accueil

2. Page d'authentification

3. Affichage de l'interface de l'enseignant

4. Interface module suivi de cours

5. Module gestion de la scolarité

6. Interface Liste des élèves inscrits

D. Extrait des classes contrôles

1. Extrait de la classe control pour la connexion

2. Extrait de la classe control gestion cours

3. Extrait de la classe control suivi de la scolarité

CONCLUSION GENERALE

L'implantationd'unPGIestuneétapeimportantedanslavied'uneorganisation.Lesentreprises qui implantent un tel système le font avanttoutpoursupporterleurcroissance,pour uniformiser leurs processus logistiques et pour augmenter la flexibilité de leur système de production. L'implantation de tels systèmesreprésenteundéfiquiexigedesressourcesmonétairesethumainesimportantes.Dans le cadre de cette étude nous avons analysé l'implantationd'unPGIauseind'un établissement scolaire. Notreétude démontre que les entreprises connaissent les étapesetlesdéfisreliésàl'implantationd'un PGI.

Lesentreprisesbénéficientmaintenant d'un système qui supporte leur croissance. Elles ont également profité de l'implantation pouramélioreretuniformiserleursprocessus logistiques ce qui leur procure des systèmes de production plus flexibles et leur permet d'effectuer une meilleure coordination des flux entre les diverses entités de l'entreprise. Après avoir étudié l'implantation des systèmes, il serait intéressant, dans le cadre de recherches futures, de suivre l'utilisation de ceux-ci dans les organisations. Cela permettrait d'identifier l'évolution des façons de faireauseindesentreprises, écoles et autres organisations suiteàl'implantationdusystèmeetd'avoiruncertainreculsur l'évaluation des bénéfices logistiques à long terme. Tout autour de ce travail, nous l'avons subdivisé en quatre grandes parties, chacune a donné un point bien précis sur notre objet d'étude.

- Dans le premier chapitre nous nous sommes intéressés à l'étude théorique des concepts et éléments clés pouvant intervenir dans notre travail ;

- Dans le chapitre suivant nous sommes passés d'une étude approfondie du champ de recherche, qui est l'Age d'or de Lubumbashi, étudier le système existant pour dégager les failles et les faiblesses qui en découlent

- Dans le troisième chapitre nous nous étions intéressés à la conception objet de la nouvelle solution, que nous avions proposés dans le chapitre précèdent ;

- Enfin le quatrième et dernier chapitre a été consacré à l'étude sur l'intégration du nouveau système que nous avons développé.

Finalement, bénéficiant de l'expérienceacquiselorsdecetteétude,l'utilisation d'unquestionnairecibléauprèsd'unéchantillon beaucoup plus large d'entreprises nous permettraitdevaliderdefaçonstatistiquecertains de nos résultats.

BIBLIOGRAPHIE SOMMAIRE

I. OUVRAGES

1. D. SIBONY.Problématique de l'informatique dans l'enseignement.ACADEMIE FRANCAISE.Paris. 2011;

2. DUCHATEAU, Charles.Pourquoi l'école ne peut intégrer les nouvellesTechnologies.RECHEARCHGATE. Paris. 2009;

3. Joseph Gabay, David Gabay « UML2 analyse et conception, Mise en oeuvre guidée avec études deCas », DUNOD, Paris, 2008.

4. Sukkhleen KAUR BAWEJA, « uses of educationnal Enterprise ressource planning », InternationalJournal of Engineering Rechearch an General, vol. 3/1 (2015);

5. YASER Dalveren, Using E-Learning in Enterprise Resource Planning (ERP) Training, A case studyto assist curriculum designers in Turkey, ELSEVIER, Turquie, 2014;

6. LAUDON Kenneth et LAUDON Jane. Management des systèmes d'information. Pearson EducationFrance, Paris, 2006.

7. Abdelhak DJAMEL, Evolution et maintenance des systèmes logiciels, Lavoisier, Paris, 2014;

8. Roger S. PRESMANN, Software Engineering, A practitioner's approach, McGraw-Hill, New York, 2010;

9. Pascal ROQUES et Franck Vallée, « UML 2 en action de l'analyse de besoins à la conception »,EYROLLES, Paris, 2007;

10. Michal ZABOVSKY, « Database programming with C# », fascicule du cours de Base de donnéesDispensé à la faculté of informatics de University of ZILINA en 2008 ;

11. Buschmann, et al, Pattern Oriented Software Architecture. John Wiley and Sons, New York, 1996.

12. Michel Nekourouh, Savoir manager et diriger les Projets - De la performance à l'excellence en 100 Conseils, Astuces et "Best Practices», EKM, ISBN 9782-953-43653-2

13. Roger AÏM, La Gestion de Projet Introduction historique - Concept de projet Méthodes de gestionStructure organisationnelle - Communication, Éditions Gualino, Paris, 2007

14. Xavier BLANC et Isabelle MOUNIER, UML 2 pour les développeurs cours et exercices corrigés,EYROLLES, Paris, 2009;

15. Krakoviak S., Systèmes intégrés de production de logiciel : concepts et réalisations, TSI, AFCET-Bordas, 1982.

16. Pascal ROQUES et Franck VALLEE, UML 2 en action de l'analyse des besoins à la conception,EYROLLES, Paris;

17. Sodhi J., Sodhi P.Software Reuse Domain Analysis and Design Process, Software Development.Mc Graw Hill.New York.1998.

18. Rolland C., Foucaut O.,Benci G., Conception des systèmes d'information, la méthode Rémora.Eyrolles. Paris. 1987 ;

19. Parnas D.L., On the Criteria to be Using in Decomposing System into Modules, CACM, vol. 5, #12, décembre. 72, p. 1053.

II. COURS SUIVIS

1. BAVUEZA Daniel, « Analyse et Conception de Systèmes d'Information », cours dispensé à la faculté de sciencesInformatiques de l'Université Méthodiste au Katanga en 2017.

2. FATIMA Bouyahia, « l'Information dans l'Entreprise », fascicule du cours d'introduction auxSystèmes d'information de l'Entreprise dispensé à la faculté de sciences de l'universitéSEMLALIA MARAKKECH en 2016;

3. YAV Muchail Dieudonné, « Génie Logiciel », cours dispensé à la faculté des sciences informatiques de l'Université Méthodiste au Katanga en 2018 ;

4. Léopold MUKALENG « les Big data », cours suivi d'Analyse et fouille de données dispensé à laFaculté de sciences informatiques de l'Université Méthodiste au Katanga en 2018 ;

5. BAVUEZA Daniel, « Analyse et conduite des projets informatiques ». cours dispensé à la faculté de sciences informatiques de l'Université Méthodiste au Katanga en 2019;

III. SITES WEB

IV. MEMOIRES ET THESES

1. KAMAL Ghssiss, « L'informatisation de la gestion des ressources humaines », thèse de doctoratSoutenu à la faculté des sciences de l'Université ABDELMALEK ESSAADI en juin 2008;

2. Pérotin, PASCAL.« Les progiciels de Gestion Intégrée, instruments de l'intégration Organisationnelle ? - Etude de cas ». Thèse doctorale soutenue publiquement à la faculté desSciences et Techniques de l'Université MONTPELLIER II en Septembre 2004 ;

3. Stéphanie BAUCHE, « Utilisation de l'Urbanisme des SI pour la recette des applications ». Mémoire de master soutenu à la faculté d'informatique de l'Université Paris Ouest en 2010 ;

4. YAV Muchail, « Urbanisation du système d'information hospitalier par l'approche orientée service ». Mémoire de licence soutenu à la faculté d'informatique de l'Institut Supérieur des Statistiques en 2010 ;

5. POYO Ramazani, « Conception et mise en place d'un service web de processus de gestion de ventes des produits miniers ». Mémoire de Licence soutenu à la faculté des sciences informatiques de l'Université Méthodiste au Katanga en 2013 ;

6. MASWEKA Kakonde, « Conception et Mise en place d'un didacticiel web pour l'accès aux Items des Examens d'Etat », Mémoire de licence soutenu à la faculté des sciences informatique de l'Université Méthodiste au Katanga en 2018 ;

7. Edouard NGOYMushame, « Conception et réalisation d'une application web pour la publication d'offres d'emploi ». Travail de fin de cycle présenté à la faculté des sciences informatiques de l'Université Méthodiste au Katanga en 2017 ;

* ¹ D. SIBONY, Problématique de l'informatique dans l'enseignement, ACADEMIE FRANCAISE, Paris, 2011, s.p ;

* ² Charles DUCHATEAU, Pourquoi l'école ne peut intégrer les nouvelles technologies ?, RECHEARCHGATE, Paris, 2009, s.p ;

* ³ PASCAL Pérotin, « Les progiciels de Gestion Intégrée, instruments de l'intégration Organisationnelle ? - Etude de cas », Thèse doctorale soutenue publiquement à la faculté desSciences et Techniques de l'Université MONTPELLIER II en Septembre 2004, s.p ;

* ⁴ Sukkhleen KAUR BAWEJA, « uses of educationnal Enterprise ressource planning », International Journal ofEngineering Rechearch an General, vol. 3/1 (2015), p.12;

* ⁵ YASER Dalveren, Using E-Learning in Enterprise Resource Planning (ERP) Training, A case study

* ⁶ BAVUEZA Daniel, « Analyse et Conception de Systèmes d'Information », cours dispensé à la faculté De sciencesInformatiques de l'Université Méthodiste au Katanga en 2017.

* ⁷ FATIMA Bouyahia, « l'Information dans l'Entreprise », fascicule du cours d'introduction aux Systèmes d'information de l'Entreprise dispensé à la faculté de sciences de l'université SEMLALIA MARAKKECH en 2016, p.27 ;

* ⁸LAUDON Kenneth et LAUDON Jane. Management des systèmes d'information. Pearson Education France, Paris, 2006, p.16.

* ⁹http://www.wikipedia.org [les NTICE] en ligne consulté le 07 Mars 2019 à 12h42 ;

* ¹⁰ Abdelhak DJAMEL, Evolution et maintenance des systèmes logiciels, Lavoisier, Paris, 2014, p.55 ;

* ¹¹ YAV Muchail Dieudonné, « Génie Logiciel », cours dispensé à la faculté des sciences informatiques De l'Université Méthodiste au Katanga en 2018 ;

* ¹² Roger S. PRESMANN, Software Engineering, A practitioner's approach, McGraw-Hill, New York, 2010, s.p;

* ¹³ KAMAL Ghssiss, « L'informatisation de la gestion des ressources humaines », thèse de doctorat

Soutenu à la faculté des sciences de l'Université ABDELMALEK ESSAADI en juin 2008,

* ¹⁵ Pascal ROQUES et Franck Vallée, « UML 2 en action de l'analyse de besoins à la conception », EYROLLES, Paris, 2007, p. 13 ;

* ¹⁶ Daniel BAVUEZA, « Le processus 2TUP », cours d'Analyse et conception de système d'information Dispensé à la faculté de sciences informatiques de l'Université Méthodiste au Katanga en 2018 ;

* ¹⁷ Joseph Gabay, David Gabay « UML2 analyse et conception, Mise en oeuvre guidée avec études de Cas », DUNOD, Paris, 2008.

* ¹⁸ BAVUEZA Daniel, « UML », fascicule du cours d'Analyse et Conception des Systèmes D'information dispensé à la Faculté des Sciences informatiques de l'UMK en 2018 ; p. 38 ;

* ¹⁹ Michal ZABOVSKY, « Database programming with C# », fascicule du cours de Base de données Dispensé à la faculté of informatics de University of ZILINA en 2008 ;

* ²⁰ Léopold MUKALENG « les Big data », cours suivi d'Analyse et fouille de données dispensé à la Faculté de sciences informatiques de l'Université Méthodiste au Katanga en 2018 ;

* ²¹ BAVUEZA DANIEL, « la méthode 2TUP », cours suivi d'Analyse et Conception des Systèmes d'information dispensé à la faculté de sciences informatiques de l'Université Méthodiste au Katanga en 2018 ;

* ²² Xavier BLANC et Isabelle MOUNIER, UML 2 pour les développeurs cours et exercices corrigés, EYROLLES, Paris, 2009, p. 97-106 ;

* ²³ Pascal ROQUES et Franck VALLEE, UML 2 en action de l'analyse des besoins à la conception,

* ²⁴ Buschmann, et al,Pattern Oriented Software Architecture. John Wiley and Sons, New York, 1996,

* ²⁵Daniel BAVUEZA, « Outils de pilotage des projets », cours suivi de Méthodes de conduite de projets Informatiques, dispensé à la faculté des sciences informatiques en 2019 ;

* ²⁶ Michel Nekourouh, Savoir manager et diriger les Projets - De la performance à l'excellence en 100 Conseils, Astuces et "Best Practices», EKM, ISBN 978-2-953-43653-2

* ²⁷ Roger AÏM, La Gestion de Projet Introduction historique - Concept de projet - Méthodes de gestion Structure organisationnelle - Communication, Éditions Gualino, Paris, 2007

* ²⁸http://prof.bpesquet.fr/cours/php-en-bref/ en ligne le 05 mai 19 à 07h55 ;