Rapport de projet de fin d’année








télécharger 101.99 Kb.
titreRapport de projet de fin d’année
page1/3
date de publication13.07.2017
taille101.99 Kb.
typeRapport
ar.21-bal.com > loi > Rapport
  1   2   3




Rapport de projet de fin d’année :


Application de gestion financière d’un établissement universitaire

Réalisé par :
Abdelouahid Benlamlih

Omar Haji

Encadré par :
M. Ismail Kassou

Année universitaire 2006/2007


Sommaire

3.1. Technologies utilisées 22

3.1.2. Le modèle MVC 22

3.1.3. La démarche de développement STRUTS 24

3.1.4. Apache Tomcat 26

3.1.5. les pages JSP 27

3.1.6. Mysql 27

3.2. Présentation de quelques interfaces 28

28

4.1. Déploiement de la base de données 32

4.2. Déploiement de l’application 32

Table des figures



Figure 1 : Diagramme de Gantt 9

Figure 2 : Cycle de vie en cascade 11

Figure 3: Diagramme de cas d'utilisation 15

Figure 4: diagramme de séquence, consultation d'un bon de commande 18

Figure 5: diagramme de séquence, Consultation d'Etats 19

Figure 6 : Diagramme de séquence, Ajout d'un bon de commande 19

Figure 7 : Diagramme de classes 20

Figure 8 : Architecture du modèle MVC 22

Figure 9 : Modèle MVC 23

Figure 10 : Architecture STRUTS 24

Figure 11 : Authentification 28

Figure 12 : Menu d'accueil 29

Figure 13 : Détails des programmes d'emplo 29

Figure 14 : Gestion des produits et services 30

Figure 15 : Liste des programme d'emploi 30

Figure 16 : liste des devis 31

Introduction

La gestion financière d’un établissement universitaire subit plusieurs contraintes et règles pour assurer la transparence, la traçabilité des opérations et mouvements de comptes. Cette discipline incorpore divers modules de gestion de budget, de stocks, de personnel et gestion de projets, d’où l’importance et la taille d’un projet de développement d’une solution de gestion financière. Sa particularité est que la plus grande partie des recettes financières viennent directement sous formes de budget de l’état, ce qui impose un double contrôle en aval et en amont à chaque mouvement d’argent, dépense ou engagement. En plus des recettes de l’état, l’université tire profit des différentes formations, projets qu’elle accueille au sein de ses établissements.

Dans le cadre du projet de fin de la deuxième année, nous avons développés la partie de l’application de gestion financière qui s’occupe de la gestion des programmes d’emploi. Notre partie s’occupe des différents programmes d’emploi des recettes d’un établissement universitaire, elle assure le suivi, l’archivage des différents mouvements de dépense et peut présenter un rapport de la situation. Les diverses informations sont saisies par un utilisateur. Lors de chaque opération, il devra saisir les différentes informations relatives aux différentes formes que prennent les dépenses. A tout moment, les différents comptes doivent être équilibrés et toute dépense ou engagement d’argent sera justifié par l’application.

Dans le présent rapport, nous décrivons en détail les différentes étapes de développement du projet. Dans le premier chapitre, nous décrivons les détails et le contexte du projet, les besoins auxquels la solution doit répondre, nous établissons un cahier des charges qui formule les spécifications des besoins, et enfin nous présenterons la planification des tâches et leur déroulement durant toute la période de notre projet de fin d’année. Dans le chapitre suivant, on analyse les entités du projet, les différents cas d’utilisation et scenarii modélisés par le langage UML et qui nous amènerons à la conception d’un modèle de données sur lequel est basée l’application. Enfin dans le dernier chapitre, nous présentons et justifions nos choix technologiques de développement, puis nous terminons par quelques captures d’écran présentant les principales interfaces et scénarios d’utilisation.





  1. Chapitre 1 : Contexte du projet



    1. Capture des besoins

      1. Présentation du contexte du projet

Dans un établissement universitaire, un grand nombre d’opérations est effectués dans le cadre de projets scientifiques, formations ou bien simplement d’entretien de l’établissement et rémunération du personnel. Ces opérations génèrent un abondant flux d’opérations financières, de mouvements de comptes et changements de crédit des différents budgets. Avec les différentes formes que peuvent prendre les recettes (budget de l’état, formations, projets…) et les dépenses (marché, bon de commande, régie...), la gestion financière et l’archivage des mouvements et leurs justificatifs devient très complexe.

Il devient compliqué alors d’avoir des états sur la situation financière lors d’établissement du budget annuel ou encore la consultation des budgets précédents. Le contrôle de performance d’une telle gestion est ainsi lésé par la délicatesse de gestion et d’extraction de l’information en temps voulu.

Notre application va devoir faciliter la saisie d’information. Les données relatives aux différentes formes de dépenses (Marché, Régie, Bon de commande, Frais de remboursement) seront stockées dans une base de données. Ces informations là pourront être consultées pour usage ultérieur ou modifiées si besoin est.

      1. Périmètre du projet

Une application de gestion financière incorpore plusieurs modules de gestion budgétaire, comptable, de stock, de personnel et de projets. La taille d’une telle application devient alors très grande et nécessite des compétences et un temps considérable de développement.

Dans le cadre de notre projet de fin d’année, nous nous limiterons à la gestion de programme d’emploi, une sorte de mini budget qui repartie les recettes d’un projet mené à l’école selon différentes rubriques. Ainsi nous avons géré 4 formes que peuvent prendre les dépenses dans ce genre de budget : « Bon de commande », « Appel d’offre et marché », « Régie » pour l’argent liquide, et autres « Remboursement de frais » (frais de mission, repas ou services …)

      1. Besoins

A travers nos réunions avec notre professeur encadrant et qui s’avèrent l’utilisateur potentiel direct de l’application nous avons pu recueillir et capturer les différents besoins tout en limitant le diamètre du projet :

  • Besoin d’informations : avoir instantanément l’état financiers des différents programmes d’emploi pour l’établissement d’un nouveau programme d’emploi ;

  • Génération de formulaire : générer des formulaires pré remplis avec les différentes informations recueillies par l’application pour être signé (ordre de paiement de paiement, bon de commande …) ;

  • Mesure de l’efficacité des procédures : pouvoir mesurer combien prend de temps le traitement d’un document depuis sa création jusqu'à sa validation par les responsables et l’université.



      1. Objectif du projet

Notre projet vise à assurer en premier lieu le suivi des différents Programmes d’emploi, et assurer l’archivage de leurs mouvements de dépenses. Ainsi, chaque dépense devra être saisie, selon son type, dans l’application pour pouvoir assurer à tout moment un équilibre entre les crédits des différentes rubriques et les dépenses correspondantes.

En deuxième lieu, la solution doit offrir un moyen d’extraire l’information instantanément à propos de chacun des programmes d’emploi. Elle vise à présenter un rapport d’état de la situation financière des programmes d’emploi, l’argent payé, l’argent engagé et enfin l’argent non-engagé est qui est toujours disponible.

    1. Cahier des charges

Pour initier notre projet, il a fallu dresser une liste de besoins qui constitueront le cahier des charges. Les besoins que nous avons pu distinguer sont de deux types et sont comme suit :

Besoins fonctionnels :

  • Génération de rapport d’état

  • Saisie d’opérations de dépenses sous 4 formes

  • Saisie de nouveaux programme d’emploi et leurs rubriques avec le crédit allouer a chacune.

Besoins non fonctionnels :

    • Intégrité des données : assurer la disponibilité et la fiabilité de l’information fournie par l’application.

    • Sécurité : authentification obligatoire pour éviter la falsification de documents.



    1. Planification des taches

Le cycle de vie de du développement de l’application est un modèle en cascade qui va de l’initialisation à la réalisation en passant par la conception et l’analyse. Le diagramme de Gantt ci-dessous montre la planification de tâches tout au long du projet. Ceci dit, nous avons souvent été amené à revoir quelques phases telles l’élaboration du cahier de charges mais surtout l’analyse des données. En effet, l’élaboration du modèle conceptuel de donnée et du diagramme de classes a nécessité plusieurs retouches. Nous avons été amené à délaisser le projet durant la période de préparation mais on continuait à se familiariser avec les outils de travail (struts, eclipse, langage jsp…).



Figure 1 : Diagramme de Gantt


  1. Chapitre 2 : Analyse et Conception



    1. Modèle en cascade

Nous avons adopté un modèle de cycle de vie en cascade pour le développement de notre application. Ce type de modèle est bien adapté à notre projet puisqu’il s’agit d’une application d’une durée moyenne. Le modèle en cascade présente l’avantage de nous permettre de valider chaque phase pour passer à la suivante. Même si, au cours du projet, nous étions obligé parfois de revenir à l’une des phases pour remédier à un problème ou corriger une erreur de conception ou de modélisation par exemple.

Le principe de modèle en cascade est de découper le projet en phases distinctes sur le principe du non-retour. Lorsqu’une phase est achevée, son résultat sert de point d'entrée à la phase suivante. Ce modèle, développé dans les années 1970 par W. ROYCE a servi pendant des années de modèle de référence.



Figure 2 : Cycle de vie en cascade

L'avantage de ce modèle est de proposer au fur et à mesure une démarche de réduction des risques, en minimisant au fur et à mesure l'impact des incertitudes. L'impact d'une incertitude dans la phase de développement étant plus faible que l'impact d'une incertitude dans les phases de Conception ou de Spécifications, plus le projet avance, plus les risques diminue.

Néanmoins, cette démarche, basée sur un processus de contrôle qualité en fin de chaque phase, a l'inconvénient d'exclure l'utilisateur dès la phase de conception car trop technique. Le contrôle qualité significatif survient alors en fin de projet, et, à ce moment, si l'utilisateur s'aperçoit que le système ne répond pas correctement aux besoins exprimés, il peut être trop tard.

Le modèle en cascade est adapté aux projets de durée inférieure à l'année, sur des projets à forte composante règlementaire, comme les projets de back-office.

Pour de grands systèmes, cette démarche présente également l'inconvénient de ne pas permettre de mener, en parallèle, le développement de modules d'applications.

    1. Démarche de modélisation : UML

      1. Introduction

Nous avons adopté tout au long du projet le langage UML comme langage de modélisation et de conception. Ce choix est justifié d’une part par le fait que nous voulions mettre en pratique les nouvelles connaissances acquises tout au long de la deuxième année et d’une autre part par le fait qu’UML est un langage de modélisation de plus en plus utilisé grâce à la puissance des outils qu’il offre et l’efficacité de ses méthodes.

La description de la programmation par objets a fait ressortir l’étendue du travail conceptuel nécessaire : définition des classes, de leurs relations, des attributs et méthodes, des interfaces etc.

Pour programmer une application, il ne convient pas de se lancer tête baissée dans l’écriture du code : il faut d’abord organiser ses idées, les documenter, puis organiser la réalisation en définissant les modules et étapes de la réalisation. C’est cette démarche antérieure à l’écriture que l’on appelle modélisation ; son produit est un modèle.

Les spécifications fournies par la maîtrise d’ouvrage en programmation impérative étaient souvent floues : les articulations conceptuelles (structures de données, algorithmes de traitement) s’exprimant dans le vocabulaire de l’informatique, le modèle devait souvent être élaboré par celle-ci. L’approche objet permet en principe à la maîtrise d’ouvrage de s’exprimer de façon précise selon un vocabulaire qui, tout en transcrivant les besoins du métier, pourra être immédiatement compris par les informaticiens. En principe seulement, car la modélisation demande aux maîtrises d’ouvrage une compétence, un professionnalisme qui ne sont pas aujourd’hui répandus.

      1. Mise en œuvre d’UML

UML n’est pas une méthode (i.e. une description normative des étapes de la modélisation) : ses auteurs ont en effet estimé qu’il n’était pas opportun de définir une méthode en raison de la diversité des cas particuliers. Ils ont préféré se borner à définir un langage graphique qui permet de représenter, de 5 L’OMG (Object Management Group) est une association américaine à but non lucratif créée en 1989 dont l’objectif est de standardiser et promouvoir le modèle objet sous toutes ses formes. L’OMG est notamment à la base des spécifications UML, MOF, CORBA et IDL. L’OMG est aussi à l’origine de la recommandation MDA communiquer les divers aspects d’un système d’information (aux graphiques sont bien sûr associés des textes qui expliquent leur contenu). UML est donc un métalangage car il fournit les éléments permettant de construire le modèle qui, lui, sera le langage du projet.

Il est impossible de donner une représentation graphique complète d’un logiciel, ou de tout autre système complexe, de même qu’il est impossible de représenter entièrement une statue (à trois dimensions) par des photographies (à deux dimensions). Mais il est possible de donner sur un tel système des vues partielles, analogues chacune à une photographie d’une statue, et dont la juxtaposition donnera une idée utilisable en pratique sans risque d’erreur grave.

UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues distinctes pour représenter des concepts particuliers du système d’information. Ils se répartissent en deux grands groupes :

Diagrammes structurels ou diagrammes statiques (UML Structure) :

diagramme de classes (Class diagram) ;

diagramme d’objets (Object diagram) ;

diagramme de composants (Component diagram) ;

diagramme de déploiement (Deployment diagram) ;

diagramme de paquetages (Package diagram) ;

diagramme de structures composites (Composite structure diagram).

Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) :

diagramme de cas d’utilisation (Use case diagram) ;

diagramme d’activités (Activity diagram) ;

diagramme d’états-transitions (State machine diagram) ;

Diagrammes d’interaction (Interaction diagram) ;

diagramme de séquence (Sequence diagram) ;

diagramme de communication (Communication diagram) ;

diagramme global d’interaction (Interaction overview diagram) ;

diagramme de temps (Timing diagram) .

Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement tous produits à l’occasion d’une modélisation. Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes d’activités, de cas d’utilisation, de classes, d’objets, de séquence et d’états-transitions. Les diagrammes de composants, de déploiement et de communication sont surtout utiles pour la maîtrise d’oeuvre à qui ils permettent de formaliser les contraintes de la réalisation et la solution technique.
  1   2   3

similaire:

Rapport de projet de fin d’année iconGrand Projet ap fin d’année (100 points)

Rapport de projet de fin d’année iconRapport de projet de Fin d’Études

Rapport de projet de fin d’année iconRapport de projet de fin d’etudes
«Assistance à maitrise d’ouvrage pour la remise en concurrence et l’amélioration des infrastructures de télécommunication d’une Chambre...

Rapport de projet de fin d’année iconLa Ville de Chambéry vous souhaite de joyeuses fêtes de fin d’année et une bonne année 2014
«découvertes du goût» spéciales enfants, dégustations de produits par un artisan, etc

Rapport de projet de fin d’année iconFour Seasons Hotels and Resorts annonce l’ouverture de son second...

Rapport de projet de fin d’année iconProjet de fin d’études

Rapport de projet de fin d’année iconRapport d’activité Les actions qui ont été menées au cours de l’année...
«Respire» le week-end des 8 et 9 mars (stand mutualisé avec les bénévoles du journal L’âge de faire)

Rapport de projet de fin d’année iconCalendrier se dépliant en début et en fin de volume. J. Grand-Carteret...

Rapport de projet de fin d’année iconRapport Moral
«Au Printemps la Normandie se découvre» a remporté un franc succès, elle est donc reconduite cette année à la demande du crt (Comité...

Rapport de projet de fin d’année iconRapport de fin de stage brevet de technicien superieur








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com