Gestion des tournois d'echecs

parakeetaromaticSoftware and s/w Development

Nov 17, 2012 (4 years and 9 months ago)

515 views









































2010


Licence Professionnelle SIL ARS

Groupe 2


Auteur

: KOPP Anthony



RUSSELL Kilian



ZINGER Nicolas


Gestion des tournois d’échecs

2


SOMMAIRE







Sommaire










page 2


1.
Objectifs du projet "Tournois d'échec
"






page 3


2. Identification des intervenants







page 4



3. Caractéristiques générales de la demande





page 5



4. Descrip
tion de l’existant








page 7


5. Conception










page 8


6. Mise en place









page 10


7. Organisation/communication







page 12


8. Déploiement









page 15


9. Plan assurance qualité








page 18


10. Bilan fin de projet









page 1
9












3


1.

Objectifs du projet

"Tournois d'échec"
.


Après interrogation du service "Jeux de plateau" de notre entreprise, demandeur d'une
application de gestion de tournois d'échec, il a été noté que :




Ce projet a pour but la mise en place
d'une solutio
n décisionnelle destinée à

la
gestion des tournois d'échec régulièrement organisés par le service demandeur ;




Cette solution sera
remise au service interne "Jeux de plateau
"

de notre entreprise,

qui organise régulièrement des tourn
ois de ce type ;




Ce log
iciel devra gérer
tous les éléments requis pour des tournois sérieux :
participants, adresses des participants, juges, etc.

(liste exhaustive dans la partie 5 de
ce dossier)

;




Le projet ne devra pas coûter plus de
22.000€, sinon il devra y avoir renégocia
tion du
budget autorisé avec la Direction ;




L'application devra être remise clé en mains au plus tard le 1
er

mars 2010 car un
tournoi important est prévu le 3 mars

2010
. Un retard de livraison sera synonyme de
rupture de contrat ;




La remise du produit fi
ni devra être accompagnée d'une formation rapide pour le
personnel chargé de son utilisation
(maximum une demie journée)
;




La solution devra récupérer les données actuellement existantes ;















4


2.

Identification des intervenants.


Equipe du projet :




Maxime SCHOLTZ

:

Pupitreur

chargé de la correction des textes affichés, que cela soit
au niveau de l'orthographe, de la ponctuation, ou du sens ;




Adeline DUPONT

:

Développeur

chargée de la création brute du programme ;




Jason GROSS

:

Analyste/Programmeu
r

chargé d'analyser les besoins et demandes
pour les appliquer au logiciel en création et aider Adeline DUPONT à les y intégrer ;




Dora LEBLANC

:

Analyste

chargée d'épauler Jason GROSS dans l'analyse des besoins
et demandes à appliquer au logiciel demandé
;




Anthony KOPP
,

Kilian RUSSELL
,
Nicolas ZINGER

:

Chef
s

de projet

chargés de mener le
projet à son terme dans les temps et en respectant les contraintes ;




Maria
MESSOIR

:

Informaticien
ne

chargée de s'assurer de la fiabilité du programme
en création ainsi
que de s'assurer de son intégration totale dans l'environnement de
travail existant ;




Gérard
CLAIN

:

Directeur chargé de surveiller l'avancement des divers projets, et plus
particulièrement du nôtre, ainsi que de décider du budget à allouer au projet
"Tou
rnois d'échec" ;




Marcel
BAUDOT

:

Ouvrier Hautement Qualifié

chargé de l'intégration du produit fini
dans l'environnement en production

;




Dominique KIVUVU, Alexander PAZSEK

: Equipe de maintenance chargé d’intervenir
lors des différentes pannes informatiq
ues aussi bien logiciels que matériels

;




Maîtrise d'ouvrage :




Geoffrey HORR :

Maître d'œuvre

à interroger dans le cadre du projet

;




5


3.

Caractéristiques générales de la demande.


a)

Contexte.


Le service "Jeux de plateau" organise régulièrement des tournoi
s de jeux, et plus
particulièrement des tournois d'échec. Cependant, leur système de gestion des tournois est
relativement archaïque. Ceci leur a déjà apporté divers problèmes, notamment lors de
tournois où les meilleurs participants devaient être récompen
sés. En effet, l
e

système de
gestion
actuel

a
déjà été à l'origine de pertes et de défaillances de données, qui auraient pu
être évitées si la gestion avait été centralisée et automatisé
e
.


b)

Risques et
contraintes
.


Voici une liste détaillées des contrainte
s liées à ce projet :




Techniques :



L'environnement n'est pas homogène, aussi faudra
-
t
-
il composer avec un
environnement composé de machines sous Windows XP Pro SP3, Vista Enterprise
SP1 et Windows 7 Enterprise. Cependant, toutes les machines sont en 32

bits.


De plus, les documents Excel créés pour gérer les tournois n'ont pas tous la
même extension. Les postes les plus récents utilisant Windows Office 2007
Enterprise, certains documents Excel
récents
ont pour extension ".xlsx", alors que les
plus ancie
ns ont pour extension ".xls".




Financiers :



Le budget alloué à ce projet est de 22.000€. Un dépassement devra être
obligatoirement négocié auprès de la Direction

du service "Jeux de plateau"
, avec le
risque de refus que cela implique
.




Humain :



Adeline

DUPONT
, notre Développeur, est en période de grossesse. Elle sera en
arrêt de travail à partir du 1
er

février 2010, aussi faudra
-
t
-
il trouver un/une
Développeur remplaçant temporaire, le temps de terminer le projet. Cependant,
l'embauche de personnel temp
oraire dépendra de l'avancée du logiciel et de la
possibilité ou non de continuer son développement avec un Développeur en moins.



6




Calendaires :



Le projet ne pourra réellement débuter qu'en janvier, période de discussions
préalables avec le maître d'œuv
re et vacances de Noël obligent.


De plus, le projet devra être remis clé en mains au plus tard le
1
er

mars 2010
,
délais non négociable.


Ensuite, voici une liste des risques liés au projet :




Faire :



La diversité des postes qui accueilleront le produit
fini risque de rendre le
développement du logiciel plus complexe. En effet, l'architecture système et de
dossiers n'est pas la même d'un Windows XP Pro à un Windows Vista/7 Enterprise.
S'ajoute à cela la diversité des produits Microsoft Office utilisés pou
r créer les
différents documents Excel dont il faudra récupérer les données.




Ne pas faire :



Le projet n'est pas critique en soi. Cependant, ne pas le mener à terme avant
la date demandée contraindrait les organisateurs du tournoi d'échec du 3 mars 2010
à consigner les données du tournoi en employant encore une fois la méthode très
peu pratique qu'ils sont habitués à utiliser.


Plus concrètement, ne pas terminer le projet dans les temps donnerait une
mauvaise image de notre service aux yeux du reste de l'
entreprise.


c)

Enjeux.


Ce projet apportera au service demandeur un logiciel capable de les exempter du travail
fastidieux de copie/recopie à la main. Ce sera un gain de temps, et donc d'argent,
considérable.

De plus, et surtout, cela évitera de perdre d'éve
ntuelles feuilles volantes ou même des
documents Excel mal rangés. En effet, ce type de pertes a déjà amené à des problèmes
juridiques dû au fait que des joueurs n'ont pas reçu leurs lots alors qu'ils y avaient droit et
qui plus est alors qu'ils avaient pa
yé des frais d'inscription.






7


4.

Description de l'existant.


a)

Description de l'organisation actuelle.


L'organisation des tournois d'échec organisés par le service "Jeux de plateau" est presque
inexistante. En effet, il n'y a pas d'employé spécifiquement as
socié aux tournois, ni de
dossier, papier ou électronique, où sont rangés les documents des tournois en cours ou
passés. Aussi l
a circulation

des flux est trop aléatoire pour être représentée.


b)

Description des applicatifs concernés.


Le service "Jeux de p
lateau" est un service créé il y a environ 6 mois, suite à une étude de 3
mois. Il ne possède donc que très peu d'outils dédiés, tous sans rapport avec notre projet.
Aussi, le seul applicatif concerné est
Excel
, pour récupérer les données des précédents
to
urnois.


c)

Avantages et inconvénients.


A la vue de l'existant, il serait judicieux de le considérer comme temporaire. Cependant, il est
tout de même possible d'énumérer les inconvénients de la méthode de gestion des tournois
d'échec actuelle :




Organisation

inexistante ou presque
;



Grand risque de perte de données ;



Deux supports différents, ce qui rend fastidieux le recoupement des données ;



Sauvegarde
s

des données compliquée
s

;















8


LibelléCommun
Participant
Tournoi
Action
Lieu
5.

Conception.


a)

Spécifications fonctionnelles.


Les fonctionnalités
attendues dans le cadre du projet sont

:



Les participants inscrits au tournoi ;



Les informations sur les participants (adresse, palmarès, …)

;



Les juges

;



Les résultats des rencontres

;



Les résultats des tournois précédents

;


b)

Requêtes/Tableaux de bord.




c)

Architecture.


L’architecture retenue pour le projet sera une architecture client/serveur. La base de
données sera stockée sur un serveur central. L’utilisateur s’y connectera au travers de
l’application. Il aura ainsi accès à toutes les données.

Pour une

question de sécurité, les membres du service interne «

Jeux de plateau

» devront
se connecter avec leur identifiant. Ainsi, toutes les modifications seront identifiées.


d)

Modèle conceptuel de données.


















9


e)

Spécifications spécifiques.





f)

Cho
ix des outils.


Après
l’étude des besoins de l’équipe de développeurs, une liste de logiciels à été retenue
pour la conception du projet.

L’acquisition de licences a également été évoquée. La direction, qui a déjà alloué 22.000 €
dans le cadre de ce projet
, a donc demandé que des solutions gratuites soient utilisées.

Voici la liste des logiciels

:



Notepad++



NetBeans


g)

Chargement des données.


Une fois connecté à la session, l’application charge la base de données actuelle. Les
développeurs ont mis en place u
n module qui permet de sauvegarder les modifications ou
les ajouts toutes les minutes. Ce module permet aussi de recharger la base de données sans
que l’utilisateur ne s’en rende compte.


10


6.

Mise en place.


a)

Test.


Une série de tests (interne au service de dév
eloppeurs) a été planifiée pour vérifier le bon
fonctionnement de l’application. Ces tests seront effectués en date du 8 février 2010, soit
une semaine avant la validation. Le reste de la semaine sera consacré au débogage de
l’application, si nécessaire.


b)

Recette.


L’application finale doit d’abord être validée avant d’être installée dans le service interne
«

Jeux de plateau

». Cette validation a donc pour but de vérifier tous les aspects de
l’application. Le responsable du service «

Jeux de plateau

» vérif
iera la conformité de
l’application par rapport au cahier des charges. La date de cette validation a été fixée au 15
février 2010. Une liste des fonctionnalités a été dressée et chacune d’entre elles sera passée
au crible par le maître d’œuvre et le chef d
e projet.


c)

Documentation.


Voici une liste de l’ensemble des documents utilisés et créés dans le cadre du projet

:




Modèle Conceptuel de Données



Ebauche de l’IHM



Problèmes rencontrés par les concepteurs



Aspects à ajouter/améliorer


d)

Aide au démarrage.


Dès
lors que l’application sera fonctionnelle, les membres du service interne «

Jeux de
plateau

» seront amenés à suivre une formation. Celle
-
ci aura comme objectif la prise en
main de la nouvelle application par les membres du service interne «

Jeux de platea
u

».
Cette formation sera dirigée par Marcel BAUDOT. Elle aura lieu en salle de réunion et durera
une demi
-
journée. Les personnes qui ne peuvent pas être présentes le jour de la formation
devront contacter leur responsable afin de déterminer une autre séan
ce.






11


e)

Livrables.


Une fois l’application finalisée et prête à être installée sur les postes du service interne
«

Jeux de plateau

», il sera indispensable d’inclure plusieurs éléments destinés aux
utilisateurs de l’application.

Voici une liste du contenu

du packaging

:




CD d’installation



Manuel d’utilisation

De plus, la hotline du service informatique est toujours joignable en cas de problème…































12


7.
Organisation/Communication


a)

Plan opérationnel projet


Grille Opérationnelle


* Finalisation du projet

: l’approbation des chefs de s
ervices doit être unanime.

** Formation aux utilisateurs

: celle
-
ci sera réalisé en interne par
l’équipe de maintenance informatique.

Prio
rités

Résultats

Indicateurs

Bases administratives

Infrastructure administratives

-

Mise en place d’une cellule
de recherche

-

Réunion d’information avec
les dirigeants

-

Analyse de la situation

-

Rédaction du rapport de
projet

-

Définition du budget allou
é


Possibilité de réussite du
projet

Elaboration d’une maquette

-

Réunion d’information avec
les intervenants

-

Déclaration des outils et
besoins

-

Validation d’un noyau unique
de logiciel

-

Description des améliorations
à apporter

Finalisation du proje
t*

Résultat concluant des tests en
interne

-

Approbation de la part des
chefs de services utilisant le
logiciel

-

Rédaction d’une fiche
explicative

-

Elaboration d’un
fichier
destiné à la maintenance du
logiciel

Déploiement du logiciel

Installation du log
iciel sur les
postes clients

-

Mise en place du logiciel dans
les services concernés

-

Formation aux utilisateurs
**

-

Création d’une fiche de suivi
concernant les éventuels
problèmes lié au logiciel

13


b)

Planning



Calendrier de mise en œuvre des étapes constituant le projet

:



ETAPES

INDICATEURS

CALENDRIER

Bases administ
ratives


Mise en place d’une cellule de recherche

Lundi 4 Janvier 2010 à 9h00

Réunion d’information avec les dirigeants

Mercredi 6 Janvier 2010 à 19h00

Analyse de la situation

Mardi 12 Janvier 2010 à 8h30

Rédaction du rapport de projet

Du Mercredi 13

Janvier au
Mercredi 27 Janvier 2010

Définition du budget alloué

Jeudi 28 Janvier 2010 à 17h00

Possibilité de réussite du
projet


Réunion d’information avec les intervenants

Lundi 1
er

Février 2010 à 9h30

Déclaration des outils et besoins

Mercredi 3 Fé
vrier 2010 et Jeudi
4 Février 2010

Validation d’un noyau unique de logiciel

Du Jeudi

4 F
évrier
au Vendredi 19
F
évrier 2010

Finalisation du projet

Approbation de la part des chefs de services
utilisant le logiciel

Lundi 22 Février et Mardi 23
Février 201
0

Rédaction d’une fiche explicative

Mercredi 24 Février 2010

Elaboration d’un fichier destiné à la
浡楮ten慮ce Tu 汯杩捩敬

Mercredi 24 Février et Jeudi 25
Février 2010

Déploiement du logiciel

Mise en place du logiciel dans les services
concernés

Vendr
edi 26 Février et Samedi 27
Février (de nuit)

Formation aux utilisateurs

Lundi 1
er

Mars 2010

Création d’une fiche de suivi concernant les
敮tu敬猠p牯b注l敳 汩慵 汯杩捩敬

Jeudi 4 Mars 2010



Ce calendrier constitue une ébauche des différentes étape
s de réalisation du projet ainsi que
leur date. Concernant les réunions, celles
-
ci ne peuvent en aucun être reportées ou
annulées.

14


c)

Plan de

management de la

communication

et de formation


Durant l’élaboration du projet, de nombreux moyens ont été mis en œuv
re pour promouvoir
le nouveau logiciel de gestion des tournois d’échecs.


Tout d’abord, une première réunion d’information destinée aux utilisateurs du logiciel

sera
réalisée. Cette réunion aura

pour but d’expliquer de manière concise les fonctionnalités d
u
programme. Pour ce faire, l’équipe de main
tenance aura

préparé un diaporama explicatif,
ainsi qu’une synthèse
des différentes possibilités qui seront désormais possible de faire avec
le nouveau logiciel. Une documentation plus technique sera remise aux c
hefs des services
concernés. Un autre aspect sera abordé durant cette réunion, celui de l’installation.


L’installation du logiciel sur les postes clients se fera de nuit et par télédistribution. Cette
intégration du logiciel n’aura donc aucune conséquence

sur le travail des utilisateurs et ceux
là ne seront pas gênés durant leur journée de travail. Le fait de télédistribuer le programme
est aussi un avantage. Il est possible d’installer le logiciel à distance et de ce fait le service de
maintenance n’aura
pas à intervenir sur chaque poste.


Un bulletin sous forme de courriel sera envoyé à chaque chef de groupe tous les lundis entre
le début et la fin du projet (du 4 Janvier 2010 au 1
er

Mars 2010)
. Ce courriel aura pour but de
tenir informé les responsable
s sur l’avancement ou non des travaux.


Une deuxième réunion d’information aura lieu une fois que les chefs de services auront
validés le logiciel. Cette réunion sera composée d’une démonstration de l’application par
Adeline Dupont, ainsi qu’une initiatio
n au logiciel pour les futurs utilisateurs. Les aspects de
mises à jour et de résolutions de problèmes y seront également abordés. Il est également
possible qu’un éventuel client externe participe à cette réunion en vue d’une acquisition de
droit. Sa parti
cipation est encore à confirmer.


Enfin, une troisième et dernière réunion aura lieu environ un mois après le début
d’exploitation du logiciel. Cette ultime rencontre aura pour but de recueillir les avis des
utilisateurs. Une sorte de fiche d’appréciation
sera distribué
e aux utilisateurs concernés et ils
pourront prendre la parole pour suggérer des idées en vue d’améliorer l’esthétique ou
encore la fonctionnalité du logiciel.







15


8.
Déploiement


a)

Habilitation


Avec la mise en place du logiciel, certains a
spects comme la sécurité d’accès à la solution ou
encore la sécurité des données sont à prendre en compte et nécessite une nouvelle
approche.


L’entreprise se doit d’optimiser les principaux processus de sécurité et de mise en relation
avec les politiques

de sécurité et de conformité afin d'identifier les menaces et de protéger
l'entreprise contre les attaques externes ou internes.


Le service de maintenance aura pour mission de faire une analyse des vulnérabilités,
faiblesses et risques auxquels est expo
sée l'infrastructure interne et externe au niveau des
périphériques réseau, postes de travail, applications Web et bases de données. Cette
mission sera réalisée, une fois que le noyau principal du nouveau logiciel sera prêt.


Une appel d’offre sera effect
ué pour trouver une entreprise pouvant nous aider à évaluer la
conformité actuelle de nos pratiques, et nous fournir des recommandations précieuses et
nous porter assistance pour la mise en œuvre des contrôles et processus nécessaires pour
satisfaire aux
normes en vigueur.

La conformité aux normes en vigueur et politiques de sécurité internes est un élément
essentiel de la réussite de toute entreprise.


La question de sécurité aux données est très importante. Un nouveau serveur sera
exclusivement dédié aux

fichiers
provenant de la nouvelle application. Ainsi, les échanges
avec les autres services

non

concernés seront évités.














16


b)

Utilisateur pilote


Pendant toute la période du projet (du 4 Janvier 2010 au 1
er

Mars 2010), une équipe
interdisciplinai
re
travaillera sur le sujet. L’équipe interdisciplinaire sera composée de Marcel
BAUDOT, Maria MESSOIR, Adeline DUPONT, Jason GROSS, Dora LEBLANC et l’un des trois
chefs de projet (L’ordre de passage n’a pas encore été défini).


Cette cellule aura pour tâc
he première de s’immerger totalement dans le projet et ainsi de
développer une certaine pensée créative.


Cette méthode d’utilisateur pilote est divisé en quatre grandes étapes

:


-

Etape 1

:
l
a pose de fondations

: Durant cette première période, l’équipe

sera chargée
identifier les réels besoin de la création de l’application. Cette étape sera très rapide mais
constitue le véritable point de départ du projet.

-

Etape 2

: déterminer

les tendances

: Cette deuxième étape sera davantage axée sur les
parties t
echniques qui composent le projet. Un lexique de vulgarisation des termes
techniques sera également crée pour aider ceux qui ne sont pas des experts en la matière.

-

Etape 3

: identification des zones sensibles

: En arrivant dans la troisième période, l’éq
uipe
interdisciplinaire rencontre un tournant dans la gestion du projet. En effet, cette phase aura
pour but de critiquer et surtout de trouver une solution aux problèmes de sécurité et de
sauvegarde des données. Cette partie est sans nul doute la plus lon
gue des quatre, mais
c’est également la plus importante.

-

Etape 4

: rencontre avec les utilisateurs

: cette dernière partie ponctue le travail de
recherche de l’équipe. Un atelier de travail sera crée avec plusieurs futurs utilisateurs, 2
responsables du
service informatique et l’équipe elle
-
même. Cet atelier aura un but éducatif
et ludique pour bien comprendre les fonctionnalités de l’application et
cela pourra aussi
déterminer les modifications à apporter en cas de défaillance.


Une fois que les quatre é
tapes ont été
réalisées,

l’équipe pourra être dissoute et le projet
pourra être définitivement
bouclé.





17


c)

Sauvegardes et Restauration


En ce qui concerne la sauvegarde et la restauration de données, l’entreprise fera appelle à
un partenaire extérieur. D’a
près un récent sondage, 60% des entreprises en moyenne
perdent la totalité de leurs données dans un sinistre. Etant donné l’importance des fichiers
sauvegardes, l’entreprise ne veut en aucun cas perdre ses précieuses données.


L’entreprise externe aura pou
r but de sauvegarder,
récupérer

et restaure
r

les systèm
es et
données informatiques de l’
entreprise.
Elle interviendra

en cas de panne, de virus, de
sinistre...

Elle garantie la récupération de toutes les données en une journée. Elle aura également pour
rôl
e de nous conseiller pour la mise en place de solutions innovantes préventives de
protection de données et d’archivage de données.



Concernant la sauvegarde de donnée, l’entreprise externe fera
une sauvegarde du système
d'exploitation, configuré de manièr
e optimum. Cette sauvegarde devra être effectuée
semestriellement ou à chaque évolution du système (mise à jour, migration, ajout de
logiciel,...).

Une autre sauvegarde, se limitant aux fichiers modifiés depuis la sauvegarde précédente,
quotidienne et auto
matique, sera effectuée. Le client se limite à changer le support
magnétique après invite hebdomadaire du logiciel.


En cas de perte de données ou de matériel endommagé,
l’entreprise externe assure

la
restitution de la situation à la

dernière sauvegarde

J
-

1.

La restauration du système

d'exploitation peut intervenir
dans un délai d'un jour ouvrable
suivant le sinistre.

En cas de gros sinistres de type incendie, inondation et dans le cas ou le
s jeux de bandes
serait détruit: une restauration en l'état de

la
dernière

sauvegarde totale soit J
-

30 au
maximum.


Ce dossier sera suivi par Marcel BAUDOT pour prendre contact avec l’entreprise et pour fixer
un rendez
-
vous d’information
.









18


9.

Plan assurance qualité.


Comme dans n'importe quel projet, il faut s'
assurer que le produit, une fois terminé,
conviendra au client. Aussi est
-
il intéressant de prévoir certains points en avance par rapport
à la qualité du produit et aux attentes du service "Jeux de plateau". Voici donc une liste qui
pourra évoluer au fil d
e l'avancement du projet, mais qui devra être respectée :




Réunions

de projet avec le
maître d'œuvre et les chefs de projet un lundi sur deux

pour mettre au point les besoins du service "Jeux de plateau" dans le cadre du projet

(première réunion) et pour v
érifier que l'avancée du projet convient au client

et
éventuellement modifier les besoins

(réunions suivantes)
.

Première réunion de projet
avec le maître d'œuvre
le 4 janvier 2010
;




Réunion
s

de projet avec l'ensemble de l'équipe un lundi sur deux en fin d
e journée
pour vérifier
que le projet suit la bonne direction par rapport aux attentes du client.
Première réunion d'équipe le lundi 11 janvier 2010

;




Si le maître d'œuvre ne l'a pas fait, lui rappeler de recueillir l'avis des futurs usagers
sur
les fonct
ionnalités vitales pour eux ;




Tests du logiciel

semi
-
terminé ou

terminé avant
sa
mise en production, en présence
du maître d'œuvre qui pourra critiquer les points qui ne lui conviendront pas

;




Formation des futurs utilisateurs ;




Suivi du logiciel après
mise en production, d'une durée à déterminer avec la direction
et le maître d'œuvre ;













19


10.


Bilan fin de projet


De nombreux avantages ont été remarqués depuis la fin du projet. On peut noter que tous
les membres qui ont contribués à l’élaboration d
u logiciel ont acquis une certaine maitrise
dans le domaine du développement et de la communication d’information.

Notre développeur Adeline DUPONT a pu parfaire ses connaissances dans les langages
informatiques tels que le Java.

Le fait de communiquer a
vec les futurs utilisateurs a également permis de créer un climat
amical et détendu entre les services. Il était primordial de bien préparer les utilisateurs à
manipuler la nouvelle application. Un effort de communication a donc facilité l’intégration
du l
ogiciel.


Le projet a été une réussite sur tous les points, d’autant plus que des clients extérieurs sont
fortement
intéressés

par la nouvelle application. Cet engouement de la part des autres
entreprises apporte une certaine notoriété et également de la
publicité sur l’entreprise.


On peut également noter qu’une équipe de formation a été créée

après l’installation du
logiciel, pour offrir aux utilisateurs et essentiellement pour les nouvelles embauches un suivi
personnalisé

de l’outil de gestion des tournois d’échecs.


A l’heure actuelle, aucuns points négatifs, n’a encore été décelés. La seule petite ombre au
tableau réside dans la vitesse du programme. L’application étant assez complexe et difficile à
mettre en œuvre, les
ressources demandées pour que le programme fonctionne de manière
optimale sont assez importantes. Pour l’instant, nous n’avons pas encore
trouvé

de
désagr
ément majeur suite à ça, mais dans

le futur cela pourrait

être problématique.