Projet Exige - Portfolio

Transcription

Rapport final de projet
Jeu d’entreprise E.X.I.G.E.
EXercice
Informatisé de Gestion d’E
Entreprise
EX
Sous
HTML/CSS - PHP/MySQL
Réalisé par
Stéphane GIROD et Morgan MONTES
Sous la direction de
Henri BETAILLE et Philipe CHAPELLIER
Année universitaire 2008-2009
Page 2 sur 36
Rapport final de projet
EXercice
Informatisé de Gestion d’E
Entreprise
EX
Réalisé par
Stéphane GIROD et Morgan MONTES
Sous la direction de
Henri BETAILLE et Philipe CHAPELLIER
Page 3 sur 36
REMERCIEMENTS
Nous tenons tout d'abord à remercier nos tuteurs de projet : M. CHAPELLIER
pour son aide et ses conseils dans le domaine de la comptabilité, et M. BETAILLE
pour tout ce qui concerne la programmation et ses lumières sur le langage Basic.
Merci à Mme ALBERNHE, et M. MAHIDES pour son aide concernant la réalisation
de ce rapport, à M. SABATIER pour ses conseils.
Page 4 sur 36
Sommaire
REMERCIEMENTS ........................................................................................... 4
Glossaire ................................................................................................... 6
INTRODUCTION ............................................................................................ 7
1 – CAHIER DES CHARGES .............................................................................. 8
1.1. Situation de départ ........................................................................... 9
1.1.1. Présentation du logiciel exige ........................................................ 9
1.1.2. Objectifs..................................................................................... 9
1.2. Méthode de travail .......................................................................... 10
1.3. Outils ............................................................................................ 10
1.3.1 Langage de programmation ......................................................... 10
1.3.2. Logiciels utilisés ........................................................................ 11
1.4 Analyse .......................................................................................... 11
1.4.1 Diagramme d’Use Case ............................................................... 12
1.4.2 Diagramme de classes ................................................................ 20
1.4.2
Diagrammes de Séquences ....................................................... 21
1.5 Programmation ................................................................................ 25
2- RESULTAT ........................................................................................... 27
2.1
Les membres ................................................................................ 28
2.2
Les joueurs .................................................................................. 28
2.3
Les arbitres ou managers .............................................................. 28
2.4
Les administrateurs ....................................................................... 29
2.5 Les équipes ..................................................................................... 30
3 - DISCUSSION ...................................................................................... 31
Conclusion ............................................................................................... 33
Annexe : ................................................................................................. 34
Résumé ................................................................................................ 36
Summary ............................................................................................. 36
Page 5 sur 36
Glossaire
Un glossaire est nécessaire pour la bonne compréhension du rapport. Il est
important d’expliquer les termes techniques utilisés tout au long de ce rapport.
XHTML : XHTML est un langage de balise servant à écrire des pages pour
le World Wide Web (ou internet).
PHP : PHP est un langage de script libre principalement utilisé pour produire des
pages web dynamiques via un serveur http.
MySQL: Système de Gestion de Bases de Données (SGBD) gratuit et
performant.
Programmation Objet: Technique de programmation consistant à encapsuler
dans un objet ses propriétés et les méthodes que l'on peut lui appliquer.
Cette méthode est opposée à la programmation procédurale.
SGBD: Système de Gestion des Bases de Données. Ensemble de services
permettant de gérer les bases de données.
UML: Unified Modeling Language. Langage de modélisation pour la
programmation orientée objet. Il s'agit d'un langage de modélisation de 3e
génération. L'OMG a rendu effective sa normalisation à la fin des années 90.
Classes: permet de définir un objet en décrivant ses propriétés et en
implémentant ses méthodes.
Page 6 sur 36
INTRODUCTION
Apprentissage, compréhension, loisir, trois mots clés ciblés par les
enseignants de comptabilité. Le semestre 3 en comptabilité se caractérise par
l’apparition d’un jeu informatisé simulant l’activité de plusieurs entreprises. Ce
jeu informatisé a pour but d’apporter un nouvel aspect lié à l’apprentissage de
nouvelles notions comptables. EXIGE (acronyme de « EXercice Informatisé de
Gestion d’Entreprise ») offre la possibilité de diriger son entreprise à travers un
jeu de concurrence tout en restant dans le cadre éducatif.
Pour plus de facilité d’utilisation, d’accessibilité, et de convivialité, il nous a
été demandé de transposer Exige dans un langage client/serveur tout en
améliorant certains de ses aspects afin de viser une meilleure ergonomie.
Page 7 sur 36
1 – CAHIER DES CHARGES
Page 8 sur 36
1.1. Situation de départ
Dans cette partie, nous allons présenter les différents axes majeurs de notre
projet et décrire les attentes de nos tuteurs.
1.1.1. Présentation du logiciel exige
Le logiciel E.X.I.G.E. peut être considéré comme un jeu d’entreprise
dans lequel chaque équipe dirige une entreprise. Ce jeu simule
l'activité de plusieurs entreprises, de taille comparable, fabriquant un
produit de grande consommation dont le composant de base est une
même matière première, utilisée au cours d'un même processus de
fabrication dans les différentes entreprises.
Chaque entreprise est incarnée par un groupe d’étudiants. Chaque
équipe, constituée de 4 ou 5 joueurs selon l’effectif présent, dirige
une entreprise, et est confrontée à prendre des décisions
économiques pour améliorer ses parts de marché. Le professeur
représentant le manager tient le rôle d'arbitre, et pourra assigner des
amendes dans le cas d'une non-conformité aux règles établies.
L’objectif de ce jeu, mis en place lors du semestre 3, reste
pédagogique. Il permet entre autres d’assimiler des notions
importantes en comptabilité, et de mettre en situation le programme
de comptabilité, acquis tout au long du semestre 2 et 3.
1.1.2. Objectifs
Dans ce projet, il est question de transposer Exige dans un langage de
programmation actuel sous forme d'application client/serveur (PHP),
assurant ainsi une compatibilité sur toutes les machines.
De nouvelles modifications et mises à jour devront être apportées,
afin d'améliorer l'ergonomie du logiciel pour tous les utilisateurs.
Une ébauche de ce projet a été commencé l’année précédente, et il
nous ait demandé cette année de reprendre le travail effectué par les
deux binômes, afin d’avoir une version finale opérationnelle.
Page 9 sur 36
2008
1.2. Méthode de travail
Dans cette partie, nous allons décrire notre méthode de travail utilisée
utilisé
pour mener à bien notre projet.
La première phase de notre projet a été d’analyser le travail effectué
l’année précédente afin de pouvoir partir sur de bonnes bases.
Malgré les efforts fournis pour tenter de comprendre au mieux le travail
effectué l’année précédente, nous avons pris l’initiative
l’initiative de recommencer
re
au début le projet Exige. L’analyse et la compréhension du code déjà
effectués allaientt nous ralentir dans le développement du projet, et le
travail assez peu avancé nous a poussé à prendre cette décision.
Néanmoins, nous avons tout
tout de même gardé un regard sur ce début de
projet, et utilisé certaines fonctions comme le calcul de l’indice de
satisfaction.
La seconde phase a été de procéder à l’analyse UML du projet. Cette étape
a été indispensable dans notre projet, cela nous a permis
permis notamment de
nous recentrer constamment sur le sujet. Cette analyse a été modifiée
constamment, suite notamment à l’évolution de notre base de données, et
l’ajout de nouvelles fonctionnalités.
1.3. Outils
Tout au long de notre projet, nous avons utilisé
utilisé divers outils, que nous
allons vous présenter.
1.3.1 Langage de programmation
L’objectif principal de notre projet a été de réaliser le logiciel
Exige sous forme d’application client/serveur. Les binômes
de l’année précédente ont utilisé le langage HTML/PHP pour
le traitement des pages, couplé à MySQL pour les
traitements concernant la base de données.
Nous avons utilisé pour notre part les mêmes langages web que ceux de
l’an dernier puisque ceux-ci
ceux
restent les plus intéressants pour
l’accomplissement du projet. De plus le JavaScript a été utilisé pour
donner une meilleure ergonomie à certaines fonctionnalités sur le site.
Page 10 sur 36
2008
1.3.2. Logiciels utilisés
Au cours de ce projet, nous avons utilisé WAMP
(acronyme informatique pour « Windows Apache MySQL
PHP »),, nous permettant de créer un serveur local
Apache (indispensable pour exécuter les pages en PHP)
et d’avoir accès à une ou plusieurs bases de données
créées via l’interface phpMyAdmin.
phpMyA min. Ainsi, à travers ce
logiciel, nous avons pu travailler aisément sur notre
projet, sans besoin nécessaire d’avoir accès à internet.
A noter que tous ces logiciels possèdent une licence libre.
Nous avons utilisé le logiciel Notepad++
++ en tant qu’éditeur de texte.
Toutes nos lignes de codes ont été saisies à travers ce logiciel, aucun autre
logiciel annexe pour la programmation
progr
n’a été utilisé.
Quant à l’analyse UML, nous avons
s utilisé le logiciel ArgoUML pour
pou
sa simplicité d’utilisation, malgré le manque de fonctionnalités
pouvant devenir un obstacle pour certains utilisateurs.
1.4 Analyse
Il est important d’analyser notre mission grâce à une approche UML
approfondie du projet. Tout d’abord notons que l’on va utiliser 3 diagrammes
différents pour procéder à cette analyse.
o
Diagramme de Use Case :
Un diagramme d’Use Case permet de mettre en évidence les relations
fonctionnelles
ionnelles entre les acteurs et le système étudié. Il permet de décrire les
actions possibles de chaque utilisateur du logiciel.
o
Diagramme de Classe :
Un diagramme de classe est très utilisé pour représenter l'organisation des
données dans les Systèmes d'Information. Une classe possède un titre, des
attributs et des opérations.
o
Diagramme de Séquence :
Les diagrammes
de
séquences sont
la
représentation
graphique
des interactions entre les acteurs et le système selon un ordre chronologique. Le
but est donc de décrire comment se déroule les actions entre les acteurs ou
objets grâce à des exemples de cas.
Page 11 sur 36
1.4.1 Diagramme d’Use Case
1.4.1.1
Use case Général
On distingue donc 5 acteurs différents parmi les utilisateurs de EXIGE :
-
Administrateur : possède l’intégralité des droits sur le site.
Manager : dirige les équipes et joueurs du ou des jeux qu’il a créé.
Equipe : représente l’entreprise
et prend les décisions économiques
nécessaires pour augmenter ses parts de marché.
Joueur : s’inscrit à une équipe, et peut visualiser les données économiques de
son entreprise.
Membre : utilisateur inscrit sur le site, mais n’ayant encore jamais participé à
un jeu.
On remarque aussi l’importance des flèches reliant Administrateur – Manager et
celles reliant Equipe - Joueur – Utilisateur. Celles-ci montrent une généralisation.
En effet, cela montre pour l’exemple que l’administrateur possède tous les droits
et fonctionnalités du Manager en plus de ceux spécifiques à l’administrateur. De
plus l’équipe possède tous les droits et fonctionnalités du joueur et ce dernier
possède tous les droits et fonctionnalités de l’utilisateur.
Page 12 sur 36
1.4.1.2 Use Case Gestion des administrateurs et des managers
Un manager a la possibilité d’ajouter un jeu à tout moment et de le
modifier. De plus, il peut décider de passer à l’étape suivante d’un jeu et
de vérifier les données saisies par chaque équipe au cours d’une période.
Enfin, celui-ci peut terminer un jeu s’il pense avoir effectué suffisamment
de périodes.
De plus, l’administrateur pourra en plus des droits des managers
supprimer n’importe quel jeu ou en archiver un pour le garder en mémoire
pour les années futures.
Page 13 sur 36
L’administrateur a la possibilité quand il le souhaite d’ajouter, de modifier
les paramètres ou de supprimer un Manager (c'est-à-dire dans le cadre de
l’IUT Informatique de Montpellier, en général, un enseignant de TD en
comptabilité).
Page 14 sur 36
les paramètres ou de supprimer une usine pour n’importe quelle équipe
puisque cela est pris en compte dans un jeu.
Page 15 sur 36
L’administrateur, tout comme le manager, a la possibilité quand il le
souhaite d’ajouter, de modifier les paramètres ou de supprimer un joueur
(c'est-à-dire dans le cadre de l’IUT Informatique de Montpellier en général
un étudiant en comptabilité). Notons qu’il faut que ce joueur appartienne
au jeu auquel le manager est affecté. Et comme l’administrateur est
affecté à tous les jeux, il pourra donc faire cela dans tous les jeux
contrairement à un manager. Enfin, l’administrateur peut modifier les
paramètres d’un membre s’il veut que celui-ci devienne joueur par
exemple.
Page 16 sur 36
les paramètres ou de supprimer une équipe. De plus il peut envoyer un
message à une équipe pour les prévenir qu’elle a reçu une amende pour
non respect des lois par exemple.
L’administrateur a la possibilité quand il le souhaite de visualiser n’importe
quelles données des périodes précédentes et visualiser comme supprimer
un message laissé par n’importe quel contact.
Page 17 sur 36
Page 18 sur 36
L’administrateur, comme le manager a la possibilité au début de n’importe quel
jeu d’initialiser le plan de trésorerie, le bilan, les ventes, mais aussi les potentiels
à la période 0 si le jeu doit commencer. De plus il pourra valider les plans de
trésorerie, comptes de résultat et feuilles de décision envoyés par chaque équipe
à chaque période du jeu (notons qu’ici aussi il faut contrairement à
l’administrateur que le manager soit affecté à ce jeu pour qu’il ait ces
fonctionnalités).
1.4.1.3 Use Case Gestion des Equipes, Joueurs, Membres
Tandis qu’un membre peut seulement modifier les paramètres de son
compte, un joueur peut quant à lui en plus visualiser les informations de
son compte. De plus, l’équipe peut quant à elle saisir des données à
chaque période en plus des deux autres fonctionnalités.
Page 19 sur 36
1.4.2 Diagramme de classes
Au niveau des acteurs, on se rend compte que l’on a une classe utilisateur
possédant un rang à partir d’une variable rang qui définit si celui-ci est un
simple utilisateur (c'est-à-dire un étudiant si ce site reste utilisé dans le
cadre de l’IUT Informatique de Montpellier), un manager ou un
administrateur. Notons que le simple utilisateur a été divisé en 2 classes
(par généralisation) : l’équipe qui peut être considérée comme un super
étudiant et le joueur.
Un compte de messagerie est disponible pour chaque équipe,
administrateur ou manager si besoin est, et une équipe peut emprunter à
n’importe quelle période du jeu. Pour cela, il est bien expliqué que
l’emprunt appartient à une seule équipe. Par contre, l’équipe peut n’avoir
effectuée aucun emprunt ou plusieurs avec l’accord du manager.
Un utilisateur possède 1 jeu au minimum, ce qui est le cas pour tous les
utilisateurs. De plus un utilisateur possède au maximum plusieurs jeux, ce
qui est le cas pour l’administrateur seulement (en effet le reste des
utilisateurs possèdent un jeu au maximum). A l’inverse, un jeu possède au
minimum trois utilisateurs (1 manager et 2 équipes) mais peut
Page 20 sur 36
comprendre
beaucoup
l’administrateur.
d’autres
utilisateurs
selon
l’envie
de
Parlons maintenant d’un jeu. Un jeu est constitué de feuilles de
décision, de ventes et de potentiels pour chaque période et ces objets sont
spécifiques à un seul jeu. De plus on constate que les usines sont
communes à tous les jeux pour une simplicité d’utilisation.
1.4.2 Diagrammes de Séquences
Ici, on a choisi de monter trois diagrammes de séquences différents
pour démontrer la puissance de notre site grâce aux différentes sécurités
mises en place tout en gardant une simplicité et une efficacité d’utilisation
et pour monter quelques interactions possibles avec des acteurs différents.
1° Cas : Ce diagramme montre les étapes et actions effectuées lors d’une
demande de lancement d’un Jeu.
Page 21 sur 36
L’utilisateur arrive sur le site et demande de se connecter avec des
identifiants administratifs. La base de données vérifie alors les identifiants
et après une validation, le notifie « connecté en tant qu’administrateur ».
Celui-ci demande alors par l’intermédiaire d’un bouton présent dans son
interface administrateur le lancement d’un jeu. Et là, s’enchaine les
différentes vérifications de sécurités entre l’objet de la classe jeu et la base
de données comme la vérification du nombre d’équipes (si c’est le nombre
requis). Une fois les vérifications effectuées, le jeu est lancé et cela est
effectif par le changement d’état de la variable « etat_jeu ».
Page 22 sur 36
Enfin l’administrateur demande d’afficher les informations du jeu qui sont
sauvegardées dans la base de données et affichées grâce à l’interface du
site internet.
2° Cas : Ce diagramme montre les mêmes étapes et actions que le cas
N°1 mais une vérification a échoué.
L’utilisateur se connecte toujours en tant qu’administrateur. Mais après la
requête de lancement d’un Jeu, on s’aperçoit que le nombre de joueurs
requis par équipe n’est pas complété, ce qui signifie que la totalité des
joueurs ne sont pas encore inscrits. Le lancement du Jeu est alors annulé
et un message expliquant que le jeu n’a pas pu être, est alors affiché pour
l’utilisateur.
Page 23 sur 36
3° Cas : ce diagramme montre une équipe remplissant une feuille de
décision.
L’utilisateur arrive sur le site et souhaite se connecter en tant qu’équipe.
La connexion est acceptée et l’interface de l’équipe est renvoyée à l’écran.
L’équipe demande alors de remplir une feuille de décision que l’on va
chercher grâce à la table « Décision ». Après avoir rempli tous les champs,
l’équipe valide sa feuille de décision et une prévisualisation est alors
envoyée à l’écran pour une question de sécurité vis à vis de l’équipe cette
fois-ci avant d’être envoyée à la base de données que le manager pourra
ensuite consulter et valider.
Page 24 sur 36
1.5 Programmation
Fonction recherche :
public function recherche($investissementRecherche, $idequipe){
if ($investissementRecherche >= 100000) {
$equipe = new Equipe();
$equipe->afficheInfosEquipe($idequipe, 0);
$avancementRecherche = $equipe->equipe_recherche;
$rand = rand(1,9);
$avancementRecherche += ($investissementRecherche / 100000) +
$rand;
$equipe->ajoutRechercheEquipe($idequipe, $avancementRecherche);
}
}
La recherche n’est effective seulement si la somme minimale saisie est
supérieure ou égale à 100000€.
Dans le cas où l’investissement lié à la recherche est supérieur à 100 000, on
affecte à la variable avancementRecherche (variable représentant un indice
compris entre 0 et 50, 50 représentant l’obtention de la recherche) l’indice
recherche enregistré à la période précédente. ($equipe->equipe_recherche).
La formule liée à la recherche n’est autre qu’un random compris entre 1 et 9,
que nous ajouterons à l’indice total récupéré et a la fraction de l’investissement
de la recherche avec le taux minimal à saisir.
Ainsi, l’indice maximal pouvant être atteint sur une période est égal à 19 (cas où
le random vaut 9, et l’investissement égal à 1 000 000 €).
Page 25 sur 36
Calcul du salaire moyen pour toutes les équipes d’un jeu déterminé
public function salaireMoyen($idjeu, $periode){
$decision = new Decision();
$equipe = new Equipe();
$equipe->listeEquipeJeu($idjeu);
$salaire = 0;
if($equipe->nbEquipes){
while($dataEquipe = mysql_fetch_array($equipe->requete)){
$decision->afficheInfosDecision($idjeu,
$dataEquipe['equipe_id'], $periode);
$salaire = $salaire + $decision->decision13;
}
}
$salaire = $salaire/$equipe->nombreEquipes;
return $salaire;
}
La fonction salaireMoyen permet de calculer la moyenne de tous les salaires d’un
jeu déterminé en paramètres pour une période en cours. Cette fonction n’a rien
d’extraordinaire, elle utilise juste quelques classes avec un parcours partiel de
toutes les équipes récupérées à partir de la base de données.
$equipe->listeEquipeJeu($idjeu);
On récupère la liste des équipes contenu dans un jeu spécifié en paramètre, en
appelant la méthode listeEquipeJeu de la classe Equipe.
S’il existe bel et bien des équipes, on récupère les informations saisies par
chaque équipe dans la feuille de décision pour la période en cours :
$decision->afficheInfosDecision($idjeu, $dataEquipe['equipe_id'], $periode);
On appelle la méthode afficheInfosDecision appartenant à la classe Decision
pour récupérer les informations saisies.
On divise le total des salaires saisies par le nombre d’équipes composant le jeu,
pour obtenir le salaire moyen.
Page 26 sur 36
2- RESULTAT
Page 27 sur 36
Nous avons prévu dans notre projet quatre types d’utilisateurs :
l’administrateur, les arbitres appelés aussi managers, les joueurs, et les
membres. Nous allons tâcher d’expliquer en détail les actions possibles par
chaque utilisateur.
Chaque utilisateur a la possibilité de modifier les paramètres de son
compte, soit ses informations personnelles et ses informations
d’identification.
2.1 Les membres
Contrairement à ce que l’on peut penser, un membre n’est pas un joueur.
Prenons un exemple. L’administrateur décide de supprimer un jeu, la
suppression d’un jeu entraîne la suppression de toutes les données
relatives au jeu, autrement dit, il supprimera les équipes, les joueurs et
toutes les données économiques attachées au jeu sélectionné. Ainsi, un
joueur qui a vu son jeu supprimé par l’administrateur deviendra un
membre normal.
2.2 Les joueurs
Un utilisateur inscrit sur le site peut appartenir à une équipe représentant
une entreprise. L’ajout des joueurs est effectué par l’arbitre ou
l’administrateur. Un joueur ne peut pas s’inscrire à une équipe. Cela
permettra d’éviter à l’administrateur ou à l’arbitre, de transférer un certain
nombre de joueurs après certaines erreurs.
Le joueur possède des accès limités. Il a la possibilité de consulter les
données économiques de l’entreprise à laquelle il appartient. Mais il ne
pourra pas envoyer des documents au nom de son entreprise.
2.3 Les arbitres ou managers
Un utilisateur devient un arbitre si l’administrateur le désigne tel quel.
Le manager a des fonctions limitées en rapport à l’administrateur. Il a la
possibilité de créer un ou plusieurs jeux, et de les modifier par la suite s’il
souhaite réduire notamment le nombre d’équipes requises. A l’inverse de
l’administrateur, l’arbitre n’a pas la possibilité de supprimer un jeu. Seul
Page 28 sur 36
l’administrateur possède cette fonction. Ainsi, seul l’administrateur décide
du devenir des jeux une fois terminés. Une fonction archivage a été mise
en place pour gérer notamment la conservation des jeux dans la base de
données, une fois terminés.
Le manager créé et ajoute les équipes qui composent le jeu qu’il dirige.
C’est le manager qui définit les utilisateurs dans les équipes. Parmi une
liste d’utilisateurs disponibles, l’arbitre choisit quel utilisateur va dans
quelle équipe. A noter qu’un utilisateur ne peut appartenir qu’à une
équipe.
Les arbitres devront initialiser les comptes de résultats, bilans, potentiels
en début de simulation, ventes réalisées en début de simulation lors de la
création du jeu et des équipes. Pour procéder au lancement du jeu,
certains paramètres sont requis : le nombre d’équipes inscrites doit être
égal au nombre d’équipes requises dans le jeu … (le scénario lors d’un
lancement du jeu a été décrit à travers un diagramme de séquence, nous
vous invitons à le consulter).
En plus de ces différentes fonctions, l’arbitre aura la possibilité d’envoyer
des messages aux joueurs composant l’équipe n’ayant pas remplie les
documents qu’elle aurait du envoyer. Une vue globale permettra à l’arbitre
d’avoir un aperçu sur l’avancement de la période en cours. Ainsi à travers
une page, il aura la possibilité de connaître quelle équipe n’a pas encore
envoyé les documents nécessaires, … Cela permettra notamment d’éviter
d’obtenir certains messages de blocages lors du passage à la période
suivante.
Un système de validation de la feuille de décision, du compte de résultat,
et du plan de trésorerie a été mis en place. Il permet notamment de savoir
si l’entreprise a une erreur dans la saisie d’un champ.
2.4 Les administrateurs
Lors de l’installation de l’application Exige, l’utilisateur doit définir un
compte administrateur. Ce compte administrateur aura accès à toutes les
fonctions possibles du site.
L’administrateur aura notamment une vue globale sur tous les jeux, même
ceux qu’il ne dirige pas. Il aura la possibilité de supprimer un jeu. Il aura
un accès total sur la gestion des usines, il pourra en ajouter s’il le
souhaite, en modifier ou supprimer. C’est l’administrateur qui ajoute les
arbitres.
Page 29 sur 36
2.5 Les équipes
En plus des 4 types d’utilisateurs, les joueurs appartiennent à des équipes
qui constituent l’entreprise. Chaque équipe aura la possibilité d’envoyer pour
chaque période sa feuille de décision, son compte de résultat, et son plan de
trésorerie.
Elles auront la possibilité de consulter les données des périodes antérieures à
celles en cours (bilan, et comptes de résultat).
Page 30 sur 36
3 - DISCUSSION
Page 31 sur 36
Dans la réalisation du projet, nous avons décidé de le recommencer depuis le
début. Ce choix peut être interprété comme une perte de temps selon le point de
vue auquel on se place. Néanmoins, le résultat final obtenu est plus que
satisfaisant. Nous avons créé toute l’interface graphique de l’application, en plus
du moteur PHP qui étend considérablement les fonctionnalités de Exige.
Tout au long du projet, nous n’avons pas été confrontés à des problèmes
majeurs en matière de programmation, mais très vite, nous nous sommes
heurtés à des problèmes de calcul. Nous avons eu notamment des problèmes
avec le calcul de la recherche, de l’indice de satisfaction, et des parts de
marché.
Nous tenons à remercier le binôme qui travaille en parallèle sur Exige de nous
avoir communiqué la formule pour obtenir la recherche. Nous avons utilisé la
formule interprétée par les binômes de l’année précédente pour calculer l’indice
de satisfaction. Mais nous nous sommes confrontés à des problèmes de
compréhension des formules pour le calcul des parts de marché.
Malgré notre volonté de terminer le projet, nous n’avons pas pu déterminer la
fonction qui calculerait les valeurs boursières et mathématiques d’une entreprise.
Page 32 sur 36
Conclusion
EXIGE, jeu pédagogique de simulation d’entreprise, a donc été réalisé avec
succès sous forme de site internet. Celui-ci répond en grande partie aux
exigences exprimées dans le cahier des charges; c'est-à-dire la réalisation
complète du jeu, avec une ergonomie avancée, une interface simplifiée, une
modernisation de l’aspect programmation comme de l’aspect visuel du site par
rapport à l’ancienne version du Jeu réalisé en Basic et présentant d’énormes
difficultés d’utilisations.
Puisque exprimé en tant que site internet, tout utilisateur pourra se connecter à
n’importe quel moment de la journée et au moins visualiser ce qui a été réalisé
jusqu’à maintenant, voire modifier selon l’utilisateur connecté et selon l’heure où
celui-ci est connecté.
Notons que ce site a été réalisé grâce au langage PHP/MySQL permettant ainsi
une programmation dynamique. De plus, il nous a été préférable d’utiliser le PHP
avec un langage orienté Objet pour simplifier le code et l’accès à la base de
données grâce à des méthodes incluant seulement des requêtes SQL par
exemple.
Sur le plan personnel, ce projet nous a tout d’abord permit d’approfondir nos
connaissances en programmation Web que ce soit en xHTML/CSS ou PHP/MySQL
mais aussi de réutiliser et perfectionner nos connaissances sur les concepts et la
structure de la programmation orienté Objet.
Mais ce projet ne touche pas seulement le domaine de la programmation et nous
a ouvert l’esprit sur le domaine comptable du sujet qui nous a beaucoup
intéressé. De plus l’approche UML du projet nous a été d’une très grande aide
pour la réalisation du site au cours des nombreuses semaines disponibles.
En dehors de l’approfondissement des matières enseignés au cours de ces 2
années d’IUT informatique, ce projet nous a appris à gérer notre temps c'est-àdire prévoir le temps passé à chacune des tâches du projet et finir le projet dans
le temps imparti. De plus un travail d’équipe a été nécessaire, ce qui nous
montre l’importance du travail d’équipe durant nos années professionnelles.
Page 33 sur 36
Annexe :
Toutes les classes avec les méthodes associées.
Page 34 sur 36
Page 35 sur 36
Résumé
Le programme de comptabilité du 3ième semestre D’IUT informatique à
Montpellier comporte un jeu pédagogique appelé EXIGE. Ce jeu simule la
concurrence entre plusieurs entreprises. Mais la version utilisée du jeu date de
plus de 20 ans et comporte de nombreux problèmes ergonomiques.
Le but de notre projet est donc de résoudre ces problèmes et donc de
simplifier et moderniser l’application que ce soit pour les professeurs comme
pour les étudiants.
La mise en réseau de ce jeu parait donc la proposition la plus fiable pour
assurer un rendu plus ergonomique de l’interface mais aussi pour simplifier
l’utilisation de ce jeu. Les langages XHTML/CSS et PHP/MySQL ont donc été
retenus pour la réalisation de ce projet.
Mots-Clés : EXIGE, Comptabilité, Ergonomie, PHP/MySQL
Summary
The UTI accounting syllabus of the third half-year at Montpellier includes
an educational called game EXIGE. This game simulates competition between
several companies. But the latest version of the game dates twenty years old
and includes lots of ergonomics problems.
The aim’s project is to solve these problems and so to simplify and
modernize the application both professors and students.
The game’s networking is so the most reliable proposition to assure a
more ergonomic depiction of the interface and too to simplify the game’s use.
Xhtml/CSS and PHP/MySQL have been reserved to the project’s development.
Key-words : EXIGE, accounting, ergonomic, PHP/MySQL.
Page 36 sur 36

Projet Exige - Portfolio

Transcription

Documents pareils

Administrateur Systèmes Unix H/F

Connaître les caractéristiques du public « adulte »

et membres du Bureau Composition du Conseil d`Administration

Par décret n° 2013-2368 du 3 juin 2013. Monsieur Sami Ghazali

Candidatures reçues

Christopher Baldelli Président du Directoire de RTL radio en France

CONSEIL D`ADMINISTRATION Claude Lemieux, Président clalem

Composition du CA et du Bureau

Lycées Gabriel Touchard et George Washington Charte d`utilisation

BTS Informatique de Gestion