RAPPORT DE STAGE POUR L`OBTENTION DU DIPLÔME DE

Transcription

UNIVERSITÉ DE NICE - SOPHIA ANTIPOLIS
IUT DE NICE - CÔTE D'AZUR
DÉPARTEMENT INFORMATIQUE
41 bd. Napoléon III - 06200 NICE
RAPPORT DE STAGE POUR L'OBTENTION DU
DIPLÔME DE LICENCE PROFESSIONNELLE
SYSTÈMES INFORMATIQUES ET LOGICIELS
SPÉCIALITÉ
INFORMATIQUE DISTRIBUÉE ET SYSTÈMES D'INFORMATION
D'ENTREPRISE
SESSION 2009 - 2010
Automatisation de l'expression des besoins en formation
+
Analyse de l’architecture d’un logiciel de gestion de parc de machines
&
Amélioration d’un logiciel de facturation
Présenté par Yohan MELOTTI
Entreprise :
Ville de Cannes
Direction des Systèmes d'Information et des Télécommunications
15, Avenue de Grasse - 06400 Cannes - France
Sous la direction de :
M. Philippe DEMILLY, tuteur entreprise
M. Nhan LE THANH, tuteur IUT
31/08/2010
Remerciements
Ce stage a été effectué au sein de la mairie de Cannes sous la direction de M BONO Thierry
et M DEMILLY Philippe, qu'il me soit permis de les remercier, ainsi que M URIEN Nicolas
pour leur aide efficace, leur disponibilité et les conseils qu’ils m’ont apportés.
Mes remerciements s'adressent aussi à l'ensemble du service informatique pour sa sympathie
et sa bonne humeur.
Je remercie également M. Nhan LE THANH, enseignant responsable de mon stage en
entreprise, ainsi que l’ensemble des professeurs de la licence pour leurs enseignements qui
m’ont permis d’appréhender ce stage de la meilleure manière qu’il soit.
Yohan MELOTTI
Les mots suivis d’un * sont explicités dans le glossaire à la fin de ce rapport
2
Résumé
J’ai effectué mon stage de Licence Professionnelle SIL (Systèmes Informatiques et Logiciels)
spécialité IDSE (Informatique Distribuée et Systèmes d'information d'Entreprise) au sein de
la DSIT (Direction Systèmes d’Information et des Télécommunications) à la mairie de
Cannes, un organisme public.
Les travaux qui m’ont été confiés ont été divers.
Premièrement, il m’a été confié la
réalisation d’un questionnaire devant servir à l’automatisation des besoins en formation de la
mairie de Cannes, c'est-à-dire permettre au personnel de la mairie de saisir leurs demandes de
formation en ligne et que celles-ci soient analysées informatiquement.
Ce projet, écrit en PHP*/JavaScript* et basé sur le CMS* Joomla!* et le composant/module
Breezing Form a duré un mois et demi. Par la suite, on m’a confié la mission d’analyser
l’architecture d’une application de gestion du parc de machines. Cette application, créée par
une personne n’étant plus en poste à l’heure actuelle et étant peu documentée, j’ai dû analyser
une à une les tables existantes ainsi que le code PHP* pour créer un MLD* (Modèle Logique
de Données) avec le logiciel DB Designer. Ce projet a duré une quinzaine de jours.
Enfin, ma dernière mission au sein de cet organisme a été de modifier un logiciel de
facturation
précédemment
créer
afin
de
lui
ajouter
de
nouvelles
fonctions.
Ce projet a été réalisé en PHP*/JavaScript*/AJAX* sur une durée d’un mois.
Ce stage m’a été précieux car il m’a permis d’intégrer une équipe et d’exercer pleinement le
métier auquel je me destine. De plus, j’ai perfectionné mes connaissances en matière de
CMS* et en particulier Joomla!* ainsi qu’en PHP*. Enfin j'ai pu mettre en application les
enseignements reçus au cours de cette année universitaire, tels que la gestion de projet et la
modélisation de base de données.
Yohan MELOTTI
3
Summary
I have done my training period of a Professionnal Licence SIL (Computer Systems and
Software) with IDSE option (Distributed Computing and information Systems of Company)
in the DSIT (Direction of the Systems of Information and Telecommunications) at Cannes’s
city hall, a public organism.
The missions who were given to me have been diverse.
First, the realization of an online survey to automate the collection of needs about formation
from employee of the municipality was given to me.
This project, wrote in PHP*/JavaScript* and based on Joomla!* CMS* and the
component/module Breezing Form, lasted one and a half month. Secondly, my mission was to
analyze the architecture of a computer park management's application. This program was
designed by a person who does not work anymore at Cannes’s city hall. From a week
documentation, I had to analyze existing tables one by one as well as PHP* code to create a
LDM (Logical Data Model) with the software DB Designer. This project lasted me two
weeks.
Finally, my last mission at Cannes’s city hall was to modify an invoicing software that has
been previously created and add it new functionalities.
This project had been realized in PHP*/JavaScript*/AJAX* and lasted me one month.
This training period was important for me because it allowed me to integrate a team and work
as a developer for which I intend myself. Moreover, I perfected my knowledge about CMS*
and particularly Joomla! * but I also perfected my skills about PHP. Finally, I was able to
apply the teachings received during this academic year, such as the project management and
the modelling of database.
Yohan MELOTTI
4
Table des matières
1. Introduction ..................................................................................................................................................................6
1.1. Objet du stage .......................................................................................................................................................6
1.2. Objectifs personnels..............................................................................................................................................6
1.2.1. Acquérir des compétences ............................................................................................................................6
1.2.2. M’auto former...............................................................................................................................................6
1.2.3. Acquérir une expérience professionnelle ......................................................................................................6
2. Présentation de l’organisme et du service.....................................................................................................................7
2.1. Présentation de l’organisme : la mairie de Cannes ...............................................................................................7
2.2 Présentation du service : la DSIT...........................................................................................................................7
2.3. Conditions de travail........................................................................................................................................... 11
3. Projet « Automatisation de l'expression des besoins en formation » phase d’analyse ................................................ 12
3.1 Le but................................................................................................................................................................... 12
3.2 Analyse de l’existant............................................................................................................................................ 13
3.3 Problèmes liés à l’existant ................................................................................................................................... 14
3.4 Expression du besoin ........................................................................................................................................... 14
3.5 Réalisation souhaitée / Contraintes techniques .................................................................................................... 15
3.6 Délai .................................................................................................................................................................... 15
4. Projet « Automatisation de l'expression des besoins en formation » phase de réalisation .......................................... 16
4.1Choix de la technique ........................................................................................................................................... 16
4.1.1 Contraintes................................................................................................................................................... 16
4.1.2 Étude des possibilités................................................................................................................................... 17
4.2 Réalisation ........................................................................................................................................................... 20
4.2.1 Spécificités................................................................................................................................................... 20
4.2.2 Langages utilisés.......................................................................................................................................... 21
4.2.3 Code............................................................................................................................................................. 22
5. Projet « Automatisation de l'expression des besoins en formation » phase de tests.................................................... 26
5.1Matériel de test ..................................................................................................................................................... 26
5.2 Phases de tests...................................................................................................................................................... 26
5.3 En cas de tests non concluants ............................................................................................................................. 27
6. Projet « Automatisation de l'expression des besoins en formation » phase de livraison............................................. 28
6.1 Documentation..................................................................................................................................................... 28
6.2 Démonstration...................................................................................................................................................... 29
7. Projet « Analyse de l’architecture d’un logiciel de gestion de parc de machines » phase d’analyse ......................... 39
7.1 Le but................................................................................................................................................................... 39
7.2 Réalisation souhaitée / Contraintes techniques .................................................................................................... 39
7.3 Délai .................................................................................................................................................................... 39
8. Projet « Analyse de l’architecture d’un logiciel de gestion de parc de machines » phase de réalisation ................... 40
8.1 Logiciel utilisé ..................................................................................................................................................... 40
8.2 Analyse de la structure de l’application ............................................................................................................... 40
8.3 Analyse du code de l’application ......................................................................................................................... 41
8.4 Création du MLD*............................................................................................................................................... 41
9. Projet « Analyse de l’architecture d’un logiciel de gestion de parc de machines » phase de livraison...................... 42
9.1 Résultat ................................................................................................................................................................ 42
10. Projet « Amélioration d’un logiciel de facturation» phase d’analyse ....................................................................... 43
10.1 Le but................................................................................................................................................................. 43
10.2 Analyse de l’existant.......................................................................................................................................... 43
10.3 Problèmes liés à l’existant ................................................................................................................................. 43
10.4 Expression du besoin ......................................................................................................................................... 43
10.5 Réalisation souhaitée / Contraintes techniques .................................................................................................. 44
10.6 Délai .................................................................................................................................................................. 44
11. Projet « Amélioration d’un logiciel de facturation» phase de réalisation ................................................................. 45
11.1 Langages utilisés................................................................................................................................................ 45
11.2 Code................................................................................................................................................................... 45
12. Projet « Amélioration d’un logiciel de facturation» phase de tests........................................................................... 48
12.1Matériel de test ................................................................................................................................................... 48
12.2 Phases de tests.................................................................................................................................................... 48
13. Projet « Amélioration d’un logiciel de facturation» phase de livraison .................................................................... 49
13.1 Résultat .............................................................................................................................................................. 49
14. Conclusion ................................................................................................................................................................ 56
14.1. Bilan technique ................................................................................................................................................. 56
14.2. Bilan personnel ................................................................................................................................................. 56
Yohan MELOTTI
5
1. Introduction
1.1. Objet du stage
Dans le cadre de l’obtention de la Licence Professionnelle Systèmes Informatiques et Logiciels,
option Informatique Distribuée et Systèmes d'information d'Entreprise) un stage de 3 mois est
nécessaire au terme de l’année de formation. Ce stage a été effectué au sein de la DSIT
(Direction des Systèmes d’Information et de Télécommunications) à la mairie de Cannes. Il
permet la mise en application des connaissances acquises à l’IUT Informatique en vue d’une
insertion professionnelle après obtention du diplôme.
Mon travail au cours du stage porte sur la réalisation d’une application en PHP*/JavaScript*
basé sur le CMS* Joomla!* et son intégration à l’intranet de la ville, ce projet a pour but de
gérer informatiquement les demandes du service formation.
Il m’a également été demandé d’apporter des modifications et évolutions sur diverses
applications développées par la DSIT.
1.2. Objectifs personnels
1.2.1. Acquérir des compétences
Le but de ce stage est de parfaire mes connaissances acquises tout au long de mon année de
Licence Professionnelle à l’IUT Informatique et de les mettre en application dans le milieu
professionnel auquel je me destine.
1.2.2. M’auto former
Travailler en temps que développeur web implique une veille technologique et un
apprentissage permanents. En effet, les techniques et langages de programmation sont
variés et évoluent tellement rapidement qu’il est nécessaire de s’auto former de façon
régulière notamment grâce à Internet mais aussi grâce à des livres ou à la documentation
laissée par nos prédécesseurs.
1.2.3. Acquérir une expérience professionnelle
J’aborde ce stage avec l’envie d’intégrer le milieu du travail en tant que développeur dit
« web » c'est-à-dire spécialisé dans les langages de programmation tels que PHP* ou
JavaScript*. C’est pourquoi, ce stage de trois mois au sein desquels on m’aura confié
diverses responsabilités, est une parfaite occasion d’acquérir une véritable première
expérience professionnelle.
Yohan MELOTTI
6
2. Présentation de l’organisme et du
service
2.1. Présentation de l’organisme : la mairie de Cannes
Cannes est une ville des Alpes Maritimes, elle a une population d’environ 70 000 habitants.
La mairie emploie environ 3000 agents dans divers services tels que les services techniques,
les
transports
ou
encore
les
finances
et
les
nouvelles
technologies.
Par ailleurs, la ville de Cannes est réputée pour son tourisme de loisirs et son tourisme
d’affaires. Elle est aussi mondialement connue pour son festival de cinéma.
2.2 Présentation du service : la DSIT
La direction systèmes d'information et de télécommunications est l’un des services de la
mairie de Cannes, elle est rattachée à la direction générale adjointe (D.G.A.) finances,
achats et commandes publics, NTIC (Nouvelles Technologies de l'Information et de la
Communication), laquelle est placée sous la responsabilité de Monsieur Didier VESCOVI.
La D.G.A. regroupe les directions suivantes :
- Finances
- Achats et commandes publics
- Systèmes d'information et de télécommunications
- Systèmes d’information géomatique
Yohan MELOTTI
7
La direction systèmes d'information et de télécommunications comprend 3 services :
- Sécurité, infrastructure, système (S.I.S.)
- Administratif (ADM)
- Etudes et projets NTIC (EPN)
Figure 1 - Organigramme de la Direction des Systèmes d'Information et de Télécommunications
Yohan MELOTTI
8
Les services et leurs missions
Le service SIS (Sécurité infrastructure système)
Il gère tout le « back office* » technique : les serveurs, les postes de travail, les réseaux, les
télécommunications, les bases de données, la sécurité, les approvisionnements et l'assistance
aux utilisateurs.
Il est chargé de :
- Mettre en œuvre, pérenniser et faire évoluer l'infrastructure (du systeme) et être garant de
sa sécurité.
- Acquérir, intégrer et exploiter au quotidien l'ensemble des composants de l'infrastructure.
- Assurer l'assistance aux utilisateurs
- Déployer tous les nouveaux équipements informatiques ou de télécommunication
- Réaliser la veille technologique et accroître l'expertise des agents.
- Participer activement au développement économique du territoire cannois.
Le service ADM (administratif)
Il regroupe les activités administratives de la DSIT : accueil, gestion des salles de formation
et réunion, comptabilité, gestion du personnel, gestion des guichets uniques de téléphonie
mobile et CNIL*, marchés publics, formation bureautique, formation des informaticiens,
courriers, délibérations.
Il est chargé de :
- Veiller à la qualité de l'accueil physique et téléphonique, à la bonne gestion des plannings
(salles, matériels, véhicules),
- Assurer le suivi des courriers et la rédaction des délibérations,
Yohan MELOTTI
9
- Veiller à la bonne gestion comptable : engagements, bons de commande et suivi de
l'exécution,
- Participer à la préparation budgétaire,
- Effectuer la passation des marchés publics et veiller à leur bonne exécution,
- Réaliser le reporting financier et des marchés publics pour la direction,
- Guichets uniques de téléphonie mobile et C.N.I.L.*,
- Formation, plan de formation DSIT, réseau des CI, formations bureautiques.
Le service EPN (études projets et nouvelles technologies)
Il gère tous les projets de gestion, l'informatisation des services, la maintenance des
progiciels, les sites web Ville de Cannes (analyse, mise en œuvre, suivi), et la relation client
avec les services utilisateurs.
Il est chargé de :
- Assurer la mise en œuvre et le suivi des applications métiers utilisées par les services
(relations avec les fournisseurs, etc.),
- Assurer le rôle de guichet unique pour les services dans le cadre de leurs besoins en
informatique et télécommunications,
- Etudier et déployer les nouvelles technologies au service des agents, des citoyens et des
entreprises,
- Assurer la mise en œuvre et le suivi des sites internet, intranet et extranet proposés aux
citoyens ainsi qu'aux services municipaux (au niveau de l'architecture technique et de la
définition du besoin notamment),
- Accompagner les services dans l'expression de leurs besoins pour la rédaction du cahier
des charges ainsi que dans le déroulement de la procédure de consultation.
Yohan MELOTTI
10
2.3. Conditions de travail
Bureaux en « open-space », ou plateau ouvert, c’est un lieu de travail où les bureaux
ne sont pas séparés par des murs. En conséquence, les personnes se voient et
s'entendent entre elles.
Il en découle beaucoup d’échanges au sein du service.
Minimum une réunion par semaine sur l’avancement du projet en présence de mon
tuteur de stage et parfois du demandeur du projet.
Yohan MELOTTI
11
3. Projet « Automatisation de
l'expression des besoins en
formation » phase d’analyse
3.1 Le but
Automatiser l’expression des besoins en formation de la Mairie de Cannes.
C’est-à-dire ?
Permettre au personnel de la mairie de saisir sa demande de formation en ligne
et que celle-ci soit analysée informatiquement.
Figure 2 - Schéma d’illustration global
Figure 3 - Diagramme des cas d’utilisation
Yohan MELOTTI
12
3.2 Analyse de l’existant
Comme dans tout projet, avant de commencer la réalisation et avant même la conception, on
se doit d’analyser l’existant.
En l’occurrence je me suis entretenu avec Mme ERB Nathalie, la responsable du service
formation de la mairie de Cannes et demandeuse du projet, le 03/06/2010 afin d’établir
ensemble un descriptif de l’existant.
Avant le début du projet, le service formation fonctionnait donc de la façon suivante :
L’agent avait une fiche comme celle-ci
Figure 4 – Aperçu de l’ancienne fiche de formation
Yohan MELOTTI
13
L’agent devait ensuite :
- La signer et la faire signer à son supérieur hiérarchique
- Remplir les déclarations de niveau avant formation
- Envoyer le tout au service formation
Le service formation, lui, devait :
- Saisir dans un fichier Excel la demande de l’agent
- Scanner et enregistrer le bulletin et les déclarations de niveau dans un dossier
partagé avec le formateur
Le formateur, enfin, devait :
- Donner la liste des participants aux formations bureautiques en fonction des
personnes inscrites et des déclarations de niveau des agents
3.3 Problèmes liés à l’existant
- La plupart des agents ne remplissaient pas les déclarations de niveau.
- Sans les déclarations de niveau, il était difficile de savoir si l’agent avait les pré requis
nécessaires pour assister à la formation bureautique demandée.
- Le traitement papier et l’analyse non automatisée des questionnaires entraînaient une
gestion lourde des inscriptions.
Résultat :
- On pouvait se retrouver avec des agents assistants à la formation « comment archiver ses
mails » alors que cette personne savait à peine se servir d’un ordinateur.
3.4 Expression du besoin
Après avoir analyser l’existant, il en ressort un besoin d’informatiser cette démarche de
demande de formation. La finalité de ce projet est donc de répondre à ce besoin en
permettant d’automatiser la gestion des réponses au questionnaire et de générer un
document « Parcours de formation » aux formats HTML* et PDF*.
Il y aussi un besoin de modularité et d’accessibilité dans ce projet, en effet, il est important
qu’une personne ne connaissant pas ou peu le domaine de la programmation puisse rajouter
des questions au formulaire.
Yohan MELOTTI
14
3.5 Réalisation souhaitée / Contraintes techniques
On désire réaliser un formulaire interactif en PHP* pouvant s’intégrer facilement à l’intranet
de la ville de Cannes qui a été développé avec le CMS* Joomla!* 1.5.
On désire que l’application génère deux PDF* (« Parcours de formation » et « Demande de
formation »).
Le PDF* « Parcours de formation » contiendra les trois formations conseillées à l’agent en
fonction du score qui lui aura été attribué lors de la soumission du questionnaire.
Si l’agent a un mauvais score à plus de trois formations, on affichera seulement les trois
principales grâce à un ordre de priorité des formations définit au préalable par le service
formation.
3.6 Délai
Ce projet n’a pas de délai fixe concernant sa réalisation mais, il est souhaitable qu’il soit
finalisé dans le cadre du stage
Délai estimé : 1 mois et demi à 2 mois
Yohan MELOTTI
15
formation » phase de réalisation
4.1 Choix de la technique
4.1.1 Contraintes
En ce qui concerne le choix de la technique de réalisation appropriée il y a toujours des
contraintes liées à l’environnement de développement et à l’environnement dans lequel on
veut implanter l’application réalisée. En l’occurrence, pour ce projet, j’ai dû intégrer mon
code au CMS* Joomla!* 1.5 puisque c’est sur cette plateforme qu’est développé l’intranet
de la ville (intracannes) auquel devra être intégré le questionnaire de formation.
Toujours dans un désir d’intégration à l’intranet, j’ai dû réfléchir à une implémentation au
sein même du template*, ceci afin de ne pas avoir à quitter l’intranet pour répondre au
questionnaire.
Il y a aussi des contraintes liées au développement de l’application elle-même.
En effet, dans le cas de ce questionnaire de formation, on désire qu’il soit esthétique et
ergonomique. Il se doit d’être esthétique car il est destiné à être implémenté dans l’intranet
de la ville, on veut donc qu’il soit le plus joli et dynamique possible mais il se doit aussi
d’être ergonomique car on développe un questionnaire pour des personnes qui peuvent avoir
pas
ou
peu
d’expérience
dans
le
domaine
de
l’informatique.
Toujours dans ce souci d’ouverture aux néophytes de l’informatique, on désire que le
formulaire dispose d’un « back office* » de qualité pour permettre à quiconque, comme
une secrétaire par exemple, de rajouter ou d’enlever des questions au formulaire.
Enfin, on désire que ce questionnaire de formation s’affiche correctement sous FireFox,
récemment installé sur une bonne partie des postes de la mairie, mais aussi sous Internet
Explorer 6, disponible sur la totalité des postes de la mairie et encore largement utilisé par le
personnel.
Yohan MELOTTI
16
4.1.2 Étude des possibilités
Après avoir longuement étudié les contraintes et le rendu final désiré, je me suis attelé à
l’étude des possibles techniques de réalisation utilisables.
Il en est ressorti trois possibilités de développement :
- Créer un composant Joomla!*
- Utiliser des solutions de Rich Internet Application* (Application Internet
Dynamique)
- Utiliser un composant Joomla!* préexistant du nom de Breezing Form
Fort de ce constat, j’ai étudié les avantages et inconvénients de ces trois possibilités afin de
déterminer laquelle était la plus viable et de la présenter à mon tuteur de stage ainsi qu’a la
demandeuse du projet.
•
Créer un composant Joomla!*
Créer un composant entier de Joomla!* présentait l’avantage d’être comme son nom
l’indique créé pour l’occasion et donc entièrement personnalisé, cela permettant de
répondre exactement aux besoins du client.
Néanmoins, le principal inconvénient de cette technique est qu’elle demande un temps
de création long et qu’elle oblige à recréer des « bouts » de composant déjà existants.
•
Utiliser des solutions de Rich Internet Application*
Cette technique, pour laquelle on peut utiliser Mootools* (framework Javascript
compact et modulaire orienté objet) et des plug-ins tels que SexyForms ou FancyForms
possède l’avantage de garder le côté personnalisé de la création complète de composant
Joomla!* tout en ayant un « cadre » pré-établi.
Malgré cela, le temps de réalisation, certes moins long que dans le cas de la création
d’un composant Joomla!* entier, reste long et la « trame » obligatoire de réalisation liée
à l’utilisation de Mootools* peut être handicapante.
Yohan MELOTTI
17
•
Utiliser un composant Joomla!* préexistant du nom de Breezing Form
L’utilisation de ce composant Joomla!* déjà existant à pour principal avantage un délai
de réalisation bien plus court que les deux solutions précédemment vues. De plus, il est
déjà bien connu des services de la mairie (car déjà utilisé pour d’autres projets), répond
aux besoins du client (car permettant la réalisation de formulaires à la fois esthétiques et
ergonomiques) et dispose d’un « back office* » de qualité.
En dépit de cela, cette méthode oblige à respecter une certaine mise en page et à utiliser
les fonctionnalités natives de ce composant.
Après ce travail d’analyse et de comparaison des diverses possibilités de réalisation
existantes, j’ai participé à une réunion le 07/06/2010 durant laquelle j’ai présenté à
M DEMILLY (tuteur de stage) et Mme ERB (demandeuse du projet) la solution que j’avais
sélectionné : Breezing Form.
Ce choix a été validé par ces deux personnes, jugeant cette option complète, simple à mettre
en œuvre et disposant d’un « back office* » de qualité.
Figure 5 – Aperçu du « front office »* de Breezing Form
Yohan MELOTTI
18
Figure 6 – Aperçu du « back office* » de Breezing Form
Yohan MELOTTI
19
4.2 Réalisation
4.2.1 Spécificités
Le composant Joomla!* Breezing Form à trois interfaces pour la création de formulaires :
- Classic Mode (mode classique)
- Easy Mode (glisser-déposer des objets (boutons,champs) aux endroits voulus)
- Quickform (mode rapide)
L’interface Quickform, permet de modifier un formulaire sans connaissance en
programmation.
En terme de programmation dans Breezing Form, il y a deux notions importantes :
l’existence d’une API* (interface de programmation) propre à ce composant et la possibilité
de « scripting » à divers moments de l’exécution du questionnaire.
•
L’API* de Breezing Form
Cette API*, proposant de nombreuses fonctions de base, est héritée de l’API* de
FacileForm, un autre composant Joomla! qui est en fait la version Joomla!* 1.0 de
Breezing Form (qui pour rappel fonctionne lui sous Joomla!* 1.5).
Cette API* facilite la tâche au développeur notamment grâce à ses fonctions :
•
ff_getElementByIndex(index) => Permet de récupérer un élément du
formulaire grâce à son index dans la table ff_elements.
•
ff_getElementByName(name) => Permet de récupérer un élément du
formulaire grâce à son nom.
•
ff_nextpage() => Permet de naviguer à la page suivante dans un formulaire
multi pages.
•
ff_previouspage() => Permet de naviguer à la page précédente dans un
formulaire multi pages.
•
ff_redirect(url) => Permet de rediriger le navigateur vers une autre url.
•
ff_validate_submit() => Permet de valider un formulaire (champs remplis, bon
typage des champs…) et de le soumettre pour traitement.
Yohan MELOTTI
20
•
Le « scripting » dans Breezing Form
Le « scripting » est la possibilité de créer des « scripts » en JavaScript* ou des
« pièces » en PHP* que l’on peut insérer avant le chargement du formulaire, dans les
éléments du formulaire ou à la validation/soumission du formulaire.
Grâce à cela, on peut par exemple :
-
Avant le chargement du formulaire : Désactiver des champs par défaut, créer
des variable globales à tout le formulaire etc.
-
Dans les éléments du formulaire : Vérifier le typage d’un champ (entiers, mot
en majuscules etc.), vérifier qu’un champ est rempli etc.
-
A la validation/soumission du formulaire : Rediriger vers une autre page PHP
etc.
4.2.2 Langages utilisés
Pour mener à bien ce projet, j’ai du utiliser plusieurs langages :
Pour les fonctions :
•
PHP* (PHP: Hypertext Preprocessor)
•
JavaScript*
Pour la mise en page :
•
HTML* (Hypertext Markup Language)
•
CSS* (Cascading Style Sheets)
•
+ une libraire PHP*de conversion du HTML* en PDF* du nom de TCPDF
A propos de TCPDF :
TCPDF est une classe PHP*, d'utilisation très répandue, permettant de générer des
documents PDF*. Elle est libre et open source.
TCPDF est actuellement la seule librairie PHP* de génération PDF* offrant un support
complet de l'encodage UTF-8* et des langues s'écrivant de droite à gauche, incluant le texte
bidirectionnel.
TCPDF est aussi l'une des librairies PHP* les plus utilisées au monde, étant donné qu'elle
est intégrée de base dans certains CMS*, applications et frameworks* PHP*.
Yohan MELOTTI
21
4.2.3 Code
Pour réaliser ce projet, j’ai du faire deux types de code : des pages HTML*/PHP* simples et
des fonctions/pièces à insérer dans Breezing Form (méthode de scripting décrite
précédemment).
• Pages HTML*/PHP* simples
-
Une page PHP* nommée parcoursformationhtml2.php :
Cette page contient la mise en forme HTML* des résultats du formulaire tels
qu’ils seront vus par l’utilisateur après la soumission du formulaire.
Elle affiche les informations saisies par l’utilisateur (Nom, fonction etc.) et elle
calcule, en fonction des réponses de l’utilisateur, les trois formations que l’on lui
conseille de suivre.
-
Une page PHP* nommée parcoursformationpdf.php :
Cette page contient la mise en forme PDF* des résultats du formulaire tels qu’ils
seront vus par l’utilisateur lorsqu’il cliquera sur le bouton « Parcours de formation
PDF* »
Elle utilise la libraire TCPDF pour convertir le code HTML* en version PDF*,
elle utilise aussi la fonction de génération de tableau offerte par cette librairie.
En fait, la page PHP*, via une fonction result() écrit dans un fichier les intitulés
des
trois
principales
formations
séparées
par
le
séparateur
« ; ».
La fonction de TCPDF créera ensuite automatiquement des cellules de tableau à
chaque fois qu’elle lira un « ; » dans le fichier .txt.
-
Une page PHP* nommée demandeformationpdf.php :
Cette page utilise elle aussi la librairie TCPDF afin de créer un PDF* « Demande
de formation » qui est un simple formulaire que l’utilisateur pourra renseigner puis
joindre au service formation accompagné de sa fiche « Parcours de formation ».
-
Une feuille de style CSS* nommée theme.css :
Cette feuille de style m’a permis de modifier le style du formulaire (boutons,
couleur des champs etc.) afin de réaliser un formulaire à la fois sobre et esthétique.
Yohan MELOTTI
22
-
Un fichier PHP* nommé imax.php :
Ce fichier a été créé dans un but d’accessibilité et de modularité, point important
de ce projet. Il regroupe les scores maximums que l’utilisateur peut obtenir à
chaque question du formulaire.
Cela permet à une personne de pouvoir rajouter des questions dans le formulaire
sans connaissance informatique particulière et que ces questions soient
comptabilisées dans le score final de l’utilisateur en incrémentant simplement de 1
le score de la section dans laquelle elle aura rajouté sa question.
Par exemple, pour ajouter la question « Ajouter un organigramme ? » à la section
PowerPoint du questionnaire, il lui suffira de rajouter cette question dans le « back
office* » de Breezing Form puis de rentrer dans ce fichier imax.php, de chercher
la ligne correspondant à la section PowerPoint en l’occurrence :
// PowerPoint
$qPpMax = 6;
Une fois cela fait, il faudra passer ce nombre de 6 à 7 pour que sa question soit
prise en compte dans le calcul du score de l’utilisateur.
• Fonctions/pièces insérées dans Breezing Form
Les fonctions/scripts :
En matière de « scripting », j’ai du réaliser deux types de fonctions :
les fonctions de contrôle, et les fonctions d’affichage.
Les fonctions de contrôle :
-
Une fonction de contrôle du nom saisit, ff_valueiscaps() :
Cette fonction vérifie que le nom est bien saisi en majuscules.
Pour cela, j’ai récupéré la valeur saisie dans le champ nom grâce à une variable
nommée test :
var test = element.value ;
Puis j’ai vérifié que cette valeur n’était pas nulle et bien en majuscules grâce à :
if ((element.value!=' ')&&(element.value==test.toUpperCase()))
Yohan MELOTTI
23
-
Une fonction de contrôle du prénom saisit, ff_firstvalueiscaps() :
Cette fonction vérifie que le prénom est saisi avec sa première lettre en majuscule.
Pour cela, j’ai procédé de la même façon que pour la fonction ff_valueiscaps() sauf
que j’ai récupéré la première lettre du prénom grâce à une fonction JavaScript*
permettant de découper la chaîne :
var test2 = substr(0,1) ;
J’ai ensuite testé que cette lettre était bien en majuscule (grâce à la fonction
JavaScript toUpperCase()) puis j’ai récupéré le reste du prénom, sans la première
lettre donc :
var test3 = substr(1,50) ;
Et j’ai vérifié que ce reste de prénom était bien en minuscule grâce à la fonction
Javascript* toLowerCase().
-
Des fonctions de contrôle issues de l’API* de Breezing Form / Facile Form
Une fonction de contrôle permettant de vérifier que les champs sont biens
remplis :
ff_valuenotempty()
Une fonction de contrôle permettant de vérifier que le numéro de téléphone est
bien entré en chiffres :
ff_integer()
Et une fonction de contrôle permettant de tester si l’e-mail est bien de la forme
[email protected] :
ff_validemail()
Yohan MELOTTI
24
La fonction d’affichage :
-
Une fonction d’affichage contextuel des champs
Cette fonction « d’affichage contextuel » est une fonction qui permet d’afficher ou
non un ensemble de questions en fonction des choix de l’utilisateur. Si par
exemple l’utilisateur répond « oui » à la question « avez-vous besoin d’aide
concernant Excel ? », cette fonction lui affichera automatiquement en dessous les
questions sur Excel et s’il décide de se rétracter et de mettre « non » à la place de
« oui » ces questions disparaissent de l’écran.
A la base, cette fonctionnalité est nativement gérée par Breezing Form, néanmoins,
dans notre cas, nous désirons implémenter le formulaire dans l’intranet de la ville
c'est-à-dire au sein d’une frame*.
Or, sous IE6, la gestion des frames* et l’utilisation de cette fonction « d’affichage
contextuel » ne peuvent être gérées simultanément.
Fort de ce constat, j’ai donc dû recréer une fonction « d’affichage contextuel »
compatible avec l’utilisation des frames* sous IE6.
Pour cela, j’ai notamment utilisé la fonction de l’API* Breezing Form
bfToggleFields() qui permet de rendre un champ actif ou non actif.
A chaque fois que l’utilisateur cliquera sur « oui » on effectuera donc :
bfToggleFields(on, 'section', 'Nom_de_la_section', bfDeactivateField);
Et à chaque fois qu’il cliquera sur « non » on fera :
bfToggleFields(off, 'section', 'Nom_de_la_section', bfDeactivateField);
Yohan MELOTTI
25
formation » phase de tests
5.1Matériel de test
Poste sous Windows XP
Navigateurs :
-
Internet Explorer 6 (IE6) v6.0.2900.5512.xpxp.080413.2111
-
Internet Explorer 7 (IE7) v7.0.5730.13
-
FireFox 3 (FF3) v3.6
5.2 Phases de tests
Au cours du développement de cette application, j’ai effectué plusieurs phases de tests en
fonction de l’avancée du développement.
01/06/2010 – 21/06/2010 (3 semaines) :
Phase de développement en local.
Tests réalisés en local sur mon poste avec les navigateurs précédemment cités et un logiciel
permettant d'installer l'ensemble PHP5* Apache* et MySQL* sur Windows : WampServer
2.0.
21/06/2010 – 25/06/2010 (4 jours) :
Phase de pré production.
Tests réalisés sur le serveur de test de l’intranet de la ville (intracannestest, ntsci115).
25/06/2010 – 16/07/2010 (3 semaines) :
Phase de production.
Tests réalisés sur le serveur de l’intranet de la ville (intracannes).
Yohan MELOTTI
26
5.3 En cas de tests non concluants
En cas de tests non concluants, je réagissais en trois temps :
1) Recherche de solutions
En autonomie et avec des moyens tels que Internet ou des documentations diverses, je
recherchais la solution à mon problème.
2) Notification au tuteur de stage
Ayant trouvé la solution au problème ou non, j’en faisais part au tuteur de stage durant les
réunions de projet hebdomadaires.
3) Débats / Propositions
Une fois ma recherche personnelle effectuée et mon tuteur notifié, nous avions un débat au
cours duquel mon tuteur ou moi-même proposions des solutions. Mon tuteur me faisait
profiter de son expérience et moi j’apportais le résultat de mes recherches et mes
compétences acquises à l’IUT.
Yohan MELOTTI
27
formation » phase de livraison
6.1 Documentation
Pour rappel, on a choisi d’utiliser pour ce projet le composant Joomla!* Breezing Form car
il possédait un « back office* » de qualité à la fois esthétique et simple d’utilisation.
Afin d’aller au bout de cette démarche d’accessibilité, j’ai créé un manuel utilisateur
permettant de guider pas à pas une personne qui n’y connaîtrait rien en programmation et
qui voudrait ajouter des questions dans le questionnaire.
Ce manuel est un document composé de captures d’écran et de textes explicatifs décrivant
pas à pas le fonctionnement du questionnaire.
Vous trouverez l’intégralité de ce manuel en Annexe I.
Yohan MELOTTI
28
6.2 Démonstration
Dans ce paragraphe vous trouverez une démonstration en images du résultat final afin
d’avoir un aperçu de l’applicatif en fonctionnement.
Figure 7 – Aperçu du questionnaire intégré à l’intranet de la ville
Yohan MELOTTI
29
Figure 8 – Démonstration (image 1)
Ceci est la première page du questionnaire, elle comprend des informations personnelles de
l’utilisateur, ainsi que les réponses aux deux premières questions qui permettent notamment
de ne pas afficher le questionnaire si l’utilisateur n’a pas accès à un ordinateur chez lui ou
au travail.
Yohan MELOTTI
30
Ceci est la deuxième page du questionnaire, elle comprend des réponses aux premières
questions qui sont pour l’instant traitées de façon purement statistique.
Yohan MELOTTI
31
Ceci est la troisième page du questionnaire, elle comprend les premières questions qui
interviendront dans le calcul du score de l’utilisateur.
Pour cette section, chaque fois que l’utilisateur répond « oui » il gagne un point, et quand il
répond « non », il n’en gagne pas.
Yohan MELOTTI
32
1
2
Ceci est la quatrième page du questionnaire, on y voit l’une des particularités développée pour
cette application.
En 1, on voit la page telle qu’elle apparaît aux yeux de l’utilisateur quand il arrive page 4 du
questionnaire. On voit ici que par défaut, la réponse à la question « Avez-vous besoin d’aide
pour l’explorateur Windows ? » est « non ».
Si l’utilisateur choisit de répondre « oui » comme en 2, les questions relatives à l’explorateur
Windows apparaîtront à l’écran. Si il re-choisit « non », ces questions disparaîtront.
Ce système « d’affichage contextuel » a été développé par moi-même en JavaScript* comme
décrit dans les précédents chapitres.
Les pages 5, 6, 7, 8 et 9 du questionnaire fonctionnent sur le même principe que cette page 4
pour les sections « Internet », « Manipulation d’images », « PowerPoint », « Outlook » et
« Messagerie ».
Yohan MELOTTI
33
1
2
On voit ici les pages 10 (en 1) et 11 (en 2) du questionnaire.
On peut remarquer que la page 10 fonctionne comme la page 4 (cf Figure 11).
Néanmoins, les choix effectués en page 10 modifient le contenu de la page 11, ici on a choisi
« Créer et mettre en forme des tableaux » et « Rédiger et mettre en forme un long document »
en page 10, on aura donc que ces groupes de questions qui s’afficheront en page 11.
On peut aussi remarquer qu’il est possible de ne cocher aucune case au cas où on ne sait faire
aucune des propositions, cela sera tout de même comptabilisé dans le score final.
Les pages 12 et 13 fonctionnent sur le même principe mais pour la section « Excel ».
Yohan MELOTTI
34
On voit ici la page 14 du formulaire qui est une page récapitulant les scores de l’utilisateur
pour chaque question à laquelle il a répondu.
On peut noter que le « not available » de la question « Word Rédiger et mettre en forme un
long document » sera tout de même interprété comme étant un score de zéro à la question
grâce à un changement effectué par moi-même dans le code qui transforme la valeur null* en
0.
Yohan MELOTTI
35
Figure 14– Démonstration (image 7)
Ceci est la page de résultat « Parcours de formation » avec une mise en page HTML*. Elle
propose un bilan des informations personnelles de l’utilisateur ainsi qu’un ensemble de trois
formations principales qu’il doit suivre grâce à une analyse des réponses que cet utilisateur a
fourni lors du remplissage de son questionnaire.
Il peut alors imprimer son parcours en version HTML* grâce à son navigateur ou bien
imprimer la version PDF* en cliquant sur le bouton « Parcours de formation PDF* » (cf
Figure 15).
Yohan MELOTTI
36
Ceci est la page de résultat « Parcours de formation » avec une mise en page PDF*. Elle
propose un bilan des informations personnelles de l’utilisateur ainsi qu’un ensemble de trois
formations principales qu’il doit suivre grâce à une analyse des réponses que cet utilisateur a
fourni lors du remplissage de son questionnaire.
Cette mise en page présente l’avantage d’être plus esthétique que la version HTML* et
facilement imprimable. Pour rappel, cette page a été réalisée grâce à la librairie PHP* TCPDF
décrite au chapitre 4.2.2.
Yohan MELOTTI
37
Ceci est la page « Demande de formation » qui doit accompagner la page « Parcours de
formation de l’utilisateur » avec une mise en page PDF*. Elle propose un bilan des
informations personnelles de l’utilisateur ainsi qu’un espace réservé à l’appréciation du chef
de service du demandeur.
Pour rappel, cette page a été réalisée grâce à la librairie PHP* TCPDF décrite au chapitre
4.2.2
Yohan MELOTTI
38
7. Projet « Analyse de l’architecture
d’un logiciel de gestion de parc de
machines » phase d’analyse
7.1 Le but
Analyser l’architecture d’un logiciel de gestion de parc de machines
C’est-à-dire ?
A partir d’un logiciel de gestion de parc de machines existant (intradsit
gesparc), analyser la structure des tables de la base de données et la présenter
sous forme de MLD* (Modèle Logique de Données).
On souhaite réaliser un MLD*, ce modèle logique des données qui consiste à décrire la
structure de données utilisée sans faire référence à un langage de programmation
Il s'agit donc de préciser le type de données utilisées lors des traitements, les tables et
leurs relations.
7.3 Délai
Pour ce projet, on dispose d’un délai d’environ 15 jours.
Yohan MELOTTI
39
machines » phase de réalisation
8.1 Logiciel utilisé
Pour mener à bien ce projet, j’ai utilisé le logiciel DB Designer.
DB Designer est un système de conception de base de données sous forme graphique qui
intègre tous les niveaux de conception, de modification, de création et de maintenance sur la
structure d'une base de données. Il combine une interface conviviale avec des outils
puissants qui permettent de générer rapidement des scripts SQL* ou XML* pour créer les
bases conçues ou bien permet la « rétro-ingénierie* » sur des bases existantes pour en
extraire la structure et en donner une interprétation graphique. Y sont également intégrés des
greffons permettant de générer des diagrammes de structures des bases, ainsi qu’une mini
application en PHP* de visualisation/modification basée sur des vues de la base.
DBDesigner a été développé et optimisé pour être utilisé avec le SGBD* relationnel
MySQL*, lui aussi disponible gratuitement.
8.2 Analyse de la structure de l’application
Le serveur de base de données de l’application existante est un Linux Ubuntu 7.04
(lxsci010). On dispose d’un « back office* » de gestion de la base de données
Webmin 1.360 (interface web, sous licence BSD*, qui permet d'administrer un serveur
Linux à distance via n'importe quel navigateur web).
Grâce à cette interface, j’ai pu voir la structure et le contenu des tables, cela m’a permis de
me faire une idée des interactions existantes entre elles.
Yohan MELOTTI
40
8.3 Analyse du code de l’application
Parallèlement à l’analyse des tables sous Webmin, j’ai analysé le code de l’application
présent sur le serveur lxsci010 afin d’extraire les requêtes utilisées par le développeur de
cette application et d’en déduire les échanges entre tables.
8.4 Création du MLD*
En temps normal, l’application utilisée, DB Designer, est capable d’effectuer une « rétroingénierie* »
du
code
afin
de
générer
un
schéma
de
base
de
données.
Malheureusement, dans notre cas il était impossible d’utiliser cette fonction car la base de
données a été créée par une personne qui ne maîtrisait pas la création de base et qui a
notamment créé quelques redondances qui ont empêché le logiciel d’effectuer cette « rétroingénierie* ».
Il a donc fallu que je construise moi-même le schéma à partir des résultats de mes analyses
précédemment effectuées.
Yohan MELOTTI
41
machines » phase de livraison
9.1 Résultat
Voici donc en image un aperçu du résultat final :
Figure 17– Aperçu du schéma de la base de données de l’application gesparc
Yohan MELOTTI
42
10. Projet « Amélioration d’un logiciel
de facturation» phase d’analyse
10.1 Le but
Améliorer un logiciel de facturation.
C’est-à-dire ?
Il existe un logiciel de gestion de caisses précédemment développé par la
DSIT. Le but de ce projet est d’intégrer de nouvelles fonctionnalités à cette
application.
10.2 Analyse de l’existant
Il existe donc un logiciel de gestion de caisse qui permet à un caissier d’ouvrir sa caisse, de
vendre des articles, et de clôturer sa caisse. Il permet aussi à un régisseur de contrôler les
clôture de caisses, les factures etc. et de clôturer lui-même sa régie. Enfin, les
administrateurs bénéficient d’un statut spécial.
10.3 Problèmes liés à l’existant
Il y a deux principaux problèmes sur l’application existante :
•
On ne peut pas utiliser deux modes de paiement simultanément (Carte bleue,
chèque etc.)
•
On ne peut clôturer sa caisse qu’une fois (en fin de journée)
10.4 Expression du besoin
Il ressort un besoin de pouvoir utiliser deux modes de paiements simultanés, par exemple
payer une partie en carte bleue et l’autre en espèces ou payer une partie en espèces et l’autre
en chèque culture ainsi qu’un besoin de clôture de caisse à la mi-journée pour permettre à
un agent de fermer sa caisse à midi et à un autre agent de rouvrir la caisse l’après midi et
clôturer la caisse en fin de journée.
Yohan MELOTTI
43
On désire développer deux fonctionnalités en PHP*/JavaScript*/AJAX* qui devront être
complémentaires avec le code existant où qui devront même parfois le remplacer.
Il faudra aussi travailler avec une base de données MySQL* existante et une librairie de
génération de PDF* : FPDF.
10.6 Délai
Pour ce projet, on dispose d’un délai d’environ un mois.
Yohan MELOTTI
44
de facturation» phase de réalisation
11.1 Langages utilisés
Pour mener à bien ce projet, j’ai du utiliser plusieurs langages :
•
PHP* (PHP: Hypertext Preprocessor)
•
JavaScript*
•
AJAX* (Asynchronous JavaScript and XML, ce n’est pas un langage à
proprement parlé mais une solution informatique libre pour le développement
de pages dynamiques et d'applications Web regroupant plusieurs langages)
Pour la mise en page :
•
HTML* (Hypertext Markup Language)
•
CSS* (Cascading Style Sheets)
•
+ une libraire PHP* de conversion du HTML* en PDF* du nom de FPDF
11.2 Code
Pour ce projet je n’ai pas créé de page ou de fonction entière puisque j’ai repris le travail
d’un ancien stagiaire.
J’ai donc modifié les fichiers déjà présents pour qu’ils puissent répondre aux besoins du
client qui sont l’acceptation de plusieurs modes de paiement et la clôture de caisse le midi.
-
Fichier Caisse.php :
Ce fichier est le fichier principal de gestion de la caisse.
J’y ai modifié la fonction formVerif() pour qu’elle puisse vérifier les valeurs des
champs carte bleue et chèque si ceux-ci sont remplis.
Pour cela j’ai testé si les champs étaient remplis :
if (f.sommecb.value == "")
Puis j’ai vérifié leur nature grâce à une regex* pour contrôler qu’ils soient bien du
type entier ou flottant :
var maRegex = new RegExp("(^[1-9][0-9]*(\.[0-9]|\.[0-9][0-9])?$)");
J’ai aussi créé une variable pour chacun de ces modes de paiement qui contient le
montant en euros du mode comme cela je permet aux caissiers de sélectionner tous
Yohan MELOTTI
45
les modes de paiements qu’ils désirent tout en vérifiant que l’addition des
montants de chaque mode de paiement est supérieure ou égale au montant dû par
l’acheteur et à les avertir dans le cas contraire.
-
Fichier edition_facture.php :
Ce fichier sert à l’édition d’un ticket de caisse imprimable en PDF*.
J’y ai modifié la récupération des différents montants et l’affichage des modes de
paiements afin de pouvoir afficher par exemple :
Somme due : 100€
Modes de paiements :
Espèces : 30€
CB : 70€
En effet, avant modification, on ne pouvait sélectionner qu’un seul mode de
paiement, ce type d’affichage était donc impossible.
-
Fichier menu.php :
Ce fichier sert à afficher le menu d’ouverture de caisse.
J’y ai rajouté une fonction de test qui va regarder dans la base de données si la
caisse a déjà été clôturée ou non.
Si on a déjà eu nos deux clôtures de la journée alors on affiche à l’écran que ce
n’est plus possible d’ouvrir avant le lendemain, si on a eu une seule clôture on
propose d’ouvrir l’après midi et sinon on propose d’ouvrir la journée.
-
Fichier Verification.php :
Ce fichier sert à vérifier les entrées de l’utilisateur dans menu.php.
J’y ai donc rajouté la gestion du type « Ouvrir_aprem » qui permet à l’utilisateur
d’ouvrir sa caisse l’après midi et qui n’était pas géré antérieurement.
J’ai aussi rajouté un test permettant de choisir une heure limite minimale pour la
deuxième ouverture de caisse, par exemple 12 :00 :01, afin de servir de « gardefou » en cas de ré ouverture de caisse fortuite.
-
Fichier editon_cloture_caisse.php :
Ce fichier génère un PDF lors d’une clôture de caisse.
Je l’ai modifié afin qu’il puisse afficher, en plus du montant récolté dans la journée
et du montant en caisse, le montant récolté dans la demi journée.
Yohan MELOTTI
46
Pour cela, j’ai créé une variable pour la clôture du midi :
$datecloturedtime = $date_cloture." 12:00:00";
Et j’ai testé dans ma requête SQL que l’heure de la facture soit inférieure à cette
date pour les résultats du matin ou supérieure pour ceux de l’après midi.
Yohan MELOTTI
47
de facturation» phase de tests
12.1Matériel de test
Poste sous Windows XP
Navigateurs :
-
Internet Explorer 6 (IE6) v6.0.2900.5512.xpxp.080413.2111
-
FireFox 3 (FF3) v3.6
12.2 Phases de tests
Lors de ce projet, j’ai effectué toute une série de tests au fur et à mesure de l’avancement du
développement. J’ai fait ces tests en local sur ma machine grâce aux navigateurs
précédemment cités et à un logiciel permettant d'installer l'ensemble PHP5* Apache* et
MySQL* sur Windows : WampServer 2.0.
Yohan MELOTTI
48
de facturation» phase de livraison
13.1 Résultat
Voici donc en images un aperçu du résultat final :
Figure 18– Aperçu du menu du logiciel de facturation
On peut voir ici que, comme il n’y a pas eu de clôture de la journée, le logiciel nous
présente la date de la dernière clôture et nous propose d’ouvrir la caisse pour la journée en
cours.
Yohan MELOTTI
49
Figure 19– Aperçu de la caisse du logiciel de facturation
Ici l’utilisateur ayant acheté pour 50€ a décidé de payer 20€ en espèces et 30€ en carte bleue,
ce n’était pas possible avant car lorsque l’on sélectionnait un mode de paiement, les autres se
grisaient.
Yohan MELOTTI
50
Figure 20– Aperçu d’un ticket de caisse du logiciel de facturation
Ici on peut noter que, contrairement à avant mes modifications, les modes de paiement choisis
s’affichent tous les deux.
Yohan MELOTTI
51
Figure 21– Aperçu d’une clôture de caisse du logiciel de facturation
Sur cette image, on voit bien qu’on a clôturé la matinée (en en tête), on y voit aussi les ventes
de la demi-journée et les ventes cumulées de la journée, ce qui est le résultat de mes
modifications.
Yohan MELOTTI
52
1
2
Figure 22 – Aperçu d’une ouverture d’après midi dans le logiciel de facturation
Sur cette page on voit que, comme on a clôturé la matinée, le logiciel nous propose d’ouvrir
l’après-midi (en 1).
Et si jamais on essaye d’ouvrir l’après-midi en pleine matinée, le logiciel nous indique un
message d’erreur (en 2).
Yohan MELOTTI
53
1
2
Figure 23 – Aperçu d’une vente et d’une clôture dans l’après midi
On constate ici que, comme dit précédemment, le montant de la vente de l’après-midi (en 1) a
été rajouté au montant de la journée (en 2).
Yohan MELOTTI
54
Figure 24 – Aperçu d’une caisse déjà clôturée deux fois dans la journée
On constate ici que, en cas de caisse déjà clôturée par deux fois au cours de la journée (matin
et après midi), le logiciel indique à l’agent que la journée est clôturée et qu’il ne peut pas
rouvrir sa caisse avant le lendemain.
Yohan MELOTTI
55
14. Conclusion
14.1. Bilan technique
Lors de ce stage j’ai eu l’occasion de mettre en application diverses méthodes apprises à l’IUT
comme les cours de gestion de projet (notamment en ce qui concerne le cycle de développement), de
modélisation de base de donnée ou encore d’algorithmique.
D’autre part, cela m’a permis d’élargir mes compétences en PHP* et en programmation Web avec
l’utilisation du CMS* Joomla!* et la génération de PDF*grâce aux librairies PHP* TCPDF et
FPDF.
Enfin, j’ai pu appréhender l’intégration d’une équipe et la prise de responsabilité concernant un
projet afin de le gérer du début à la fin.
14.2. Bilan personnel
Personnellement je me suis imposé six règles de rigueur qui m’ont parues essentielles dans le monde
de l’entreprise, soumis à des contraintes de temps et d’argent.
-1_Analyse
Avant d’entamer un projet, j’ai toujours débuté par une phase d’analyse qui m’a permis de bien
cerner les buts de projet et d’analyser l’existant.
- 2 Rigueur dans le code
J’ai apporté un soin particulier aux commentaires, à ré utiliser un maximum l’architecture habituelle
de code au sein du service.
- 3 Documentation
Au fur et à mesure de l’avancement des projets, j’ai réalisé une documentation afin de me réaliser
une sorte de « carnet de bord » mais surtout afin de permettre à un collègue ou à un futur stagiaire
reprenant le résultat de mon travail de comprendre le fonctionnement global de l’application.
J’ai aussi réalisé le manuel utilisateur de l’application du service formation (cf Annexe 1).
- 4 Tests
La phase de tests est aussi une des phases très importantes dans un projet, j’ai donc au maximum
utilisé un plan de tests strict pour le « gros » projet de questionnaire du service formation.
Pour les petits projets comme celui du logiciel de facturation, je n’ai utilisé les tests qu’au fur et à
mesure du développement.
- 5 Délais
C’est l’une des problématiques importantes lors d’un projet, j’ai donc établi comme priorité numéro
une de respecter les délais fixés pour chaque projet.
- 6 Résultats
Enfin, il est très important que le résultat final réponde aux exigences et aux besoins du client, qu’il
se rapproche au maximum de la solution parfaite.
Yohan MELOTTI
56
Glossaire (1)
AJAX : Acronyme de Asynchronous JavaScript and XML (« XML et Javascript
Asynchrones ») et désignant une solution informatique libre pour le développement de pages
dynamiques et d'applications Web. AJAX n'est pas une technologie en elle-même, mais un
terme qui évoque l'utilisation conjointe d'un ensemble de technologies libres couramment
utilisées sur le Web.
Apache : C'est un logiciel de serveur HTTP produit par l'Apache Software Foundation. C'est
le serveur HTTP le plus populaire du Web. C'est un logiciel libre avec un type spécifique de
licence, nommée licence Apache.
API : Application Programming Interface, interface de programmation, du point de vue
technique une API est un ensemble de fonctions, procédures ou classes mises à disposition
par une bibliothèque logicielle, un système d'exploitation ou un service.
Back office : C’est une partie d'un site Web ou d'un système informatique. Une traduction
possible de back office est arrière guichet, ou arrière-boutique.
Elle concerne la partie qui permet à l'entreprise d'administrer et de gérer son site.
CMS : Un système de gestion de contenu ou SGC (en anglais Content Management System
ou CMS) est une famille de logiciels destinés à la conception et à la mise à jour dynamique de
site web ou d'applications multimédia.
CNIL : La Commission Nationale de l'Informatique et des Libertés (CNIL) est une autorité
administrative indépendante française. La CNIL est chargée de veiller à ce que l’informatique
soit au service du citoyen et qu’elle ne porte atteinte ni à l’identité humaine, ni aux droits de
l’homme, ni à la vie privée, ni aux libertés individuelles ou publiques
CSS : Cascading Style Sheets (feuilles de style en cascade), c’est un langage informatique qui
sert à décrire la présentation des documents HTML et XML.
Frame : Cadre en HTML, permet d’afficher plusieurs documents HTML dans une même
fenêtre.
Framework : c’est un kit de composants logiciels structurels, qui définissent les fondations
ainsi que les grandes lignes de l'organisation de tout ou partie d'un logiciel (architecture). En
programmation orientée objet un framework est typiquement composé de classes mères qui
seront dérivées et étendues par héritage en fonction des besoins spécifiques à chaque logiciel
qui utilise le framework.
Front office : C'est un terme d'architecture logicielle. Il désigne la partie qui prend en charge
l'interface d'une application, par opposition au back office qui lui regroupe la partie gestion.
HTML : HyperText Markup Language. C’est le format de données conçu pour représenter les
pages web. Il permet notamment d'implanter de l'hypertexte dans le contenu des pages et
repose sur un langage de balisage, d’où son nom.
JavaScript : C’est un langage de programmation de scripts principalement utilisé dans les
pages web interactives. C'est un langage orienté objets à prototype, c'est-à-dire que les bases
du langage et ses principales interfaces sont fournies par des objets qui ne sont pas des
instances de classes.
Joomla! : C’est un CMS libre, open source et gratuit. Il est écrit en PHP et utilise une base de
données MySQL. Joomla! inclut des fonctionnalités telles que des flux RSS, des news, une
version imprimable des pages, des blogs, des sondages, des recherches.
Licence BSD : Berkeley Software Distribution license, c’est une licence libre utilisée pour la
distribution de logiciels. Elle permet de réutiliser tout ou partie du logiciel sans restriction,
qu'il soit intégré dans un logiciel libre ou propriétaire.
Yohan MELOTTI
57
Glossaire (2)
MLD : Le Modèle Logique des Données consiste à décrire la structure de données utilisée
sans faire référence à un langage de programmation. Il s'agit donc de préciser le type de
données utilisées lors des traitements. Ainsi, le modèle logique est dépendant du type de base
de données utilisé.
Mootools : Mootools est un framework Javascript compact, modulaire, orienté objet.
Grâce à un ensemble de classes et de fonctions compatibles avec les navigateurs web les plus
utilisés, Mootools offre une réponse aux problématiques du développement de Rich Internet
Applications. L'ensemble de la bibliothèque est contenu dans un fichier Javascript unique.
MySQL: My Structured Query Language. C’est un serveur de bases de données relationnelles
SQL développé dans un souci de performances élevées en lecture. Il est multi-thread et multiutilisateurs.
Null : NULL est un mot clef présent dans de nombreux langages informatiques, et qui désigne
l'état d'une variable qui n'a pas de valeur.
PDF : Portable Document Format. C’est un langage de description de pages d'impression créé
par Adobe Systems. La spécificité du PDF est de préserver la mise en forme (polices
d'écritures, images, objets graphiques…) telle qu'elle a été définie par son auteur, et ce quelles
que soient l'application et la plate-forme utilisées pour imprimer ou visualiser ledit fichier.
PHP : Acronyme récursif pour : Hypertext PreProcessor. C’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.
Regex : Une expression rationnelle ou expression régulière (regex) est en informatique une
chaîne de caractères qui décrit un ensemble de chaînes de caractères possibles selon une
syntaxe précise.
Rétro-ingénierie : La rétro-ingénierie (traduction littérale de l'anglais reverse engineering),
également appelée rétroconception, ingénierie inversée ou ingénierie inverse, est l'activité qui
consiste à étudier un objet pour en déterminer le fonctionnement interne ou la méthode de
fabrication.
RIA : Rich Internet Application, ou application Internet riche, est une application Web qui
offre des caractéristiques similaires aux logiciels traditionnels installés sur un ordinateur. La
dimension interactive et la vitesse d'exécution sont particulièrement soignées dans ces
applications Web.
SGBD : Un Système de Gestion de Base de Données est un ensemble de logiciels qui sert à la
manipulation des bases de données. Il sert à effectuer des opérations ordinaires telles que
consulter, modifier, construire, organiser, transformer, copier, sauvegarder ou restaurer des
bases de données. Il est souvent utilisé par d'autres logiciels ainsi que les administrateurs ou
les développeurs.
Template : Un template est un gabarit qui désigne un modèle de conception de logiciel ou de
présentation des données, c’est un patron de mise en page où l'on place images et textes.
UTF-8 : UCS Transformation Format 8 bits, c'est un format de codage de caractères. Il
permet de gérer tous les caractères dits unicodes.
XML : Extensible Markup Language, langage extensible de balisage, est un langage
informatique de balisage générique. Il sert essentiellement à stocker/transférer des données de
type texte Unicode structurées en champs arborescents. Ce langage est qualifié d’extensible
car il permet à l'utilisateur de définir lui-même les balises des éléments.
Yohan MELOTTI
58
Bibliographie
FPDF, site de la librairie PHP FPDF, disponible sur http://www.fpdf.org/
Joomla!, site officiel, disponible sur http://www.joomla.org/
Joomla!, site français, disponible sur http://www.joomla.fr/
MySQL, site du système de gestion de base de données MySQL, disponible sur http://www.mysql.fr/
PHP, site de la documentation de PHP, disponible sur http://www.php.net/
TCPDF, site de la librairie PHP TCPDF, disponible sur http://www.tcpdf.org/
Yohan MELOTTI
59
Annexes
Annexe I : Manuel utilisateur du logiciel d’automatisation des demandes de formation.
Yohan MELOTTI
60

RAPPORT DE STAGE POUR L`OBTENTION DU DIPLÔME DE

Transcription

Documents pareils

Samedi 17 février 2007 Le feu et la glace

Lycée Jean Favard Guéret Année scolaire 2006-2

Flyer - APSN

Trouvez votre emploi saisonnier agricole en 3 étapes

Oeil-de

Arbeitsrecht / Droits du travail

Moodle - guide - Fonctionnalites (2014) - ged

Lucarne rampante

A renvoyer à l`adresse : Gordon Crossings 55, rue Lauriston 75116

espace saint-exupery