Rapport de Fin de Projet PDF

Rapport de fin de projet
Stock Overflow
Fantastic 6
Dcembre 2010
Rapport de fin de projet Dcembre 2010
Table des matires

1 Prsentation du projet............................................................................................. 5 1.1 1.2 2 Introduction ..................................................................................................... 5 Mise en contexte .............................................................................................. 5
Revue de littrature ................................................................................................ 7 2.1 2.2 2.3 Module client ................................................................................................... 7 Module serveur ................................................................................................ 8 Module joueur artificiel ................................................................................... 8
Synthse du projet................................................................................................. 11 3.1 3.2 3.3 3.4 3.5 Prsentation................................................................................................... 11 Changement dorientation du projet ............................................................. 12 Organisation .................................................................................................. 14 Hypothses et contraintes ............................................................................. 15 Livrables ........................................................................................................ 16
Revue des processus de gestion............................................................................. 18 4.1 4.2 4.3 4.4 Mise en route ................................................................................................. 18 Planification ................................................................................................... 19 Excution ....................................................................................................... 20 Contrle.......................................................................................................... 20
4.4.1 Investissement sur les livrables ................................................................ 21 4.4.2 Efforts des membres de lquipe ................................................................ 23 4.5 5 Le gain de cette pratique ............................................................................... 24
Revue des processus techniques ........................................................................... 26 5.1 5.2 Dcomposition modulaire .............................................................................. 26 Architecture ................................................................................................... 26
5.2.1 Module du client ......................................................................................... 26
1|Page
Rapport de fin de projet Dcembre 2010 5.2.1 Module du serveur ..................................................................................... 30 5.2.3 Module du joueur artificiel......................................................................... 32 5.3 Infrastructures .............................................................................................. 34
5.3.1 Module du client ......................................................................................... 34 5.3.2 Module du serveur ..................................................................................... 34 5.3.3 Module du joueur artificiel......................................................................... 34 5.4 Algorithmes techniques ................................................................................. 35
5.4.1 Choix des algorithmes et justification ....................................................... 35 5.4.2 Performance et corrlation......................................................................... 35 5.4.3 Le rseau de neurones ............................................................................... 36 5.5 Mthodes et outils.......................................................................................... 41
5.5.1 Module du client ......................................................................................... 41 5.5.2 Module du serveur ..................................................................................... 41 5.5.3 Module du joueur artificiel......................................................................... 42 5.6 5.7 Dploiement ................................................................................................... 43 Amliorations techniques .............................................................................. 43
5.7.1 Module du client ......................................................................................... 43 5.7.2 Module du serveur ..................................................................................... 44 5.7.3 Module du joueur artificiel......................................................................... 44 5.8 5.9 6 Assurance qualit .......................................................................................... 45 Documentation............................................................................................... 46
Rsultats de lexprience ....................................................................................... 48 6.1 6.2 6.3 Client.............................................................................................................. 48 Serveur........................................................................................................... 48 Joueur artificiel ............................................................................................. 49
Guide de dveloppement ....................................................................................... 50
2|Page
Rapport de fin de projet Dcembre 2010 7.1 Module du client ............................................................................................ 50
7.1.1 Couche logique ........................................................................................... 50 7.1.2 Couche de prsentation .............................................................................. 52 7.2 7.3 8 Module du serveur ......................................................................................... 55 Module du joueur artificiel ............................................................................ 56
Guide dutilisation ................................................................................................. 57 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 Installation et mise jour ............................................................................. 57 Accs Stock Overflow .................................................................................. 58 Le tableau de bord ......................................................................................... 59 La barre dfilante .......................................................................................... 61 La gestion de portefeuille .............................................................................. 61 La messagerie ................................................................................................ 63 La recherche .................................................................................................. 64 Dtails dun titre ............................................................................................ 66 Historique de simulation ............................................................................... 68 Console dadministration ............................................................................... 68 Changement de priode ................................................................................. 71
Conclusion ............................................................................................................. 72 9.1 9.2 Amliorations................................................................................................. 73 Exprience acquise ........................................................................................ 74 Rfrences ......................................................................................................... 76 Bibliographie ................................................................................................. 76 Annexe A ........................................................................................................ 81
10 10.1 10.2
3|Page
Table des figures
Figure 1 Sparations des composants ...................................................................... 11 Figure 2 - Dcomposition gnrale ............................................................................ 26 Figure 3 Division du client ...................................................................................... 26 Figure 4 Division de la couche logique ..................................................................... 27 Figure 5 Divison de la couche de prsentation ........................................................ 28 Figure 6 Division des composants du serveur.......................................................... 30 Figure 7 Structure interne du joueur artificiel ........................................................ 32 Figure 8 - Structure du rseau de neurones .............................................................. 38 Figure 9 Sparation prcise de la couche logique .................................................... 50 Figure 10 Sparation prcise de la couche de prsentation..................................... 52 Figure 11 Page dinstallation.................................................................................... 57 Figure 12 Fentre denregistrement......................................................................... 58 Figure 13 Tableau de bord ........................................................................................ 59 Figure 14 Item de la barre dfilante ........................................................................ 61 Figure 15 Gestion de portefeuille ............................................................................. 61 Figure 16 Onglets de donnes dans la gestion de portefeuille ................................ 62 Figure 17 Onglet de messagerie ............................................................................... 63 Figure 18 Alerte de nouveaux messages .................................................................. 64 Figure 19 Indicateur de nouveaux messages dans le tableau de bord .................... 64 Figure 20 Recherche rapide par symbole ................................................................. 65 Figure 21 Recherche par nom de compagnie............................................................ 65 Figure 22 Onglet de dtails dun titre ...................................................................... 66 Figure 23 Sommaire dun titre ................................................................................. 66 Figure 24 Filtre de lhistorique................................................................................. 68 Figure 25 Historique de simulation ......................................................................... 68 Figure 26 Gestion des participants la simulation ................................................. 69 Figure 27 Fentre de cration de niveau ................................................................. 70
4|Page
PRSENTATION DU PROJET
1.1
Introduction
Le prsent document constitue le rapport de fin de projet pour lapplication
Stock Overflow . Le contenu a t dcid dun commun accord entre le professeur
Gabriel Girard et les membres de lquipe des Fantastic 6 . Le rapport de fin de projet permet de rendre compte du droulement du projet tout au long de la session. Compte tenu du fait quil sagit dun projet denvergure, le prsent document est divis en plusieurs chapitres qui faciliteront la lecture et la comprhension. Tout dabord, nous rsumerons ce que les lectures faites dans la cadre du projet nous ont apport. Par la suite, nous ferons une synthse de la dfinition relle du projet. Un autre chapitre sera consacr la revue des processus de gestion et limportance quils ont pu avoir dans le prsent projet. Le chapitre suivant constitue la principale section du rapport, car cest cet endroit que tous les lments techniques du projet se trouveront. La section suivante traitera des rsultats de lexprience pour les diffrents composants de lapplication. Un guide pour les dveloppeurs sera aussi inclus, tout comme le guide dutilisation de Stock
Overflow . Finalement, une conclusion sera prsente. Les rfrences et annexes se
trouveront en fin de document.
1.2
Mise en contexte
Le projet consiste un jeu de simulation de gestion de portefeuille. Il doit
reprsenter le plus fidlement possible lunivers de la gestion de portefeuille incluant les activits du Front Office (ngociations), du Middle Office (suivi et gestion des risques de march) et du Back Office (suivi et gestion des risques oprationnels) (1). Le but des joueurs, qui agissent en tant que gestionnaires, est de maximiser leur richesse personnelle. De bonnes performances entraneront la promotion du joueur, alors que de mauvaises auront leffet contraire. Afin de bien
5|Page
Rapport de fin de projet Dcembre 2010 faire lvaluation du travail du gestionnaire, des contrles seront faits sur les dcisions prises par ce dernier concernant la gestion de son portefeuille. Dans loptique de crer une comptition entre les utilisateurs, un administrateur sera responsable de crer une simulation dans laquelle il ajoutera des participants et dfinira les rgles du jeu. Dsirant implanter un module dintelligence artificielle leur projet, les membres des Fantastic 6 se sont engags crer un joueur artificiel qui se fiera des indicateurs techniques pour prendre ses dcisions et comptitionner avec les autres participants. Ce projet a pour objectif de crer un environnement de simulation pour des participants qui pourront mesurer leurs performances agir en tant que gestionnaire de portefeuille. De plus, il permettra de mesurer lefficacit dune entit dintelligence artificielle qui se basera sur lhistorique du march pour prendre ses dcisions. (2)
6|Page
REVUE DE LITTRATURE
Un projet tel Stock
Overflow
ncessite beaucoup de recherches.
Premirement, il sagit dun domaine auquel aucun des membres de lquipe na de connaissances approfondies. Deuximement, tel quil sera dtaill plus loin, le projet est divis en trois grands modules qui utilisent trois technologies diffrentes. Cest pourquoi nous avons consult beaucoup douvrages et de sites Internet afin de parfaire notre comprhension. Voici donc une brve revue de la littrature utilise dans Stock Overflow . Des explications supplmentaires sur lutilisation et la justification des ouvrages seront fournies dans la suite du document.
2.1
Module client
Pour nous permettre de btir une application conviviale et fluide, nous avons
utilis la technologie Windows Presentation Foundation (WPF ). Bien que nous possdions dj une certaine exprience avant le dbut du projet, nous avons eu recourt aux livres Pro WPF in C# 2010 de Matthew MacDonald
(3)
et WPF
Unleashed dAdam Nathan (4). D au domaine o uvre Stock Overflow, beaucoup de graphiques sont contenus dans lapplication. Pour nous aider les inclure dans notre projet, nous avons consult les sections de support du site Internet de Visifire
(5)
pour mieux intgrer leurs contrles.
De plus, lapplication a t programme en C# dans version 4.0 du Framework

.NET et louvrage dAndrew Troelsen, Pro C# 2010 and the .NET 4 Plateform (6)
nous a grandement aids. cela sajoute le livre de Steve McConnell, Code Complete Second Edition (7), fort utile pour les mthodologies de programmation. Au niveau des sites Web consults pour la construction du module du client, on retrouve MSDN.com
(8),
le site officiel des dveloppeurs de Microsoft, avec
notamment un article prsentant le patron de conception Model-View-View Model (MVVM ) par Josh Smith (9). Les changes entre notre serveur et le client sont raliss par services Web. Pour bien encadrer ces conversations, nous nous sommes rfrs au site Web officiel
7|Page
Rapport de fin de projet Dcembre 2010 JavaScript Object Notation (JSon )

(10).
Dautres lectures ont t ncessaires pour
mieux encadrer le processus de communication, notamment la consultation de la bibliothque de srialisation JSon

(11)
et larticle expliquant larchitecture
Representational State Transfer (REST ) (12).
2.2
Module serveur
Du ct du serveur, la majorit des notions ncessaires taient dj bien
matrises par les membres des Fantastic 6 . Cependant, des lectures sur des questions plus approfondies nous ont permis de construire un meilleur serveur, par son efficacit et sa robustesse. Tout dabord, la configuration du serveur ft un lment essentiel notre russite et cest en consultant le livre en ligne Java & Struts2 & Spring & Hibernate & Eclipse Tutorial (13) de Chis Hulbert que nous avons dcid de notre configuration. Par la suite, le serveur devait soccuper de la gestion des donnes. La consultation du document Hibernate Reference Documentation
(14)
nous a permis
dacqurir les notions ncessaires pour raliser la majeure partie de nos travaux. De plus, pour la persistance concrte des donnes, cest sur le site de MySQL (15) que nous avons trouv la rponse nos questions. Finalement, comme ce ft le cas pour le client, nous avons eu besoin dexplorer certains ouvrages pour les services Web. Le document principal utilis est le RESTful Web services Developers Guide (16) de la compagnie Sun.
2.3
Module joueur artificiel

Le module du joueur artificiel est la section o il y avait le plus de
nouveauts. Premirement, le langage de programmation tait nouveau pour tout le monde et cest pourquoi beaucoup douvrages ont t consults, dont le site de lditeur de dveloppement PyDev (17) ainsi que les outils dinstallation de Python (18) , qui ont t fort utiles.
8|Page
Rapport de fin de projet Dcembre 2010 Deuximement, une fois lintgration complte au monde Python, nous avons eu recourt certains composants externes pour nous aider progresser. Le site dAPScheduler
(19)
nous a permis den apprendre un peu plus sur les
ordonnanceurs en Python. Pour construire notre rseau de neurones, la documentation de PyBrain

(20)
nous a grandement facilit la tche. Il faut aussi
mentionner le livre de Stuart Russet et Peter Norvig, Artificial Intelligence A Modern Approach
(21)
qui est intervenu un niveau plus thorique. Une autre
rfrence qui nous a permis davancer ft la documentation des outils scientifiques SciPy (22), qui nous ont bien renseigns quant la bonne utilisation de leur produit. Troisimement, pour la communication entre le joueur artificiel et le serveur, nous avons d lire sur lutilisation du composant Django (23), afin de sassurer de bien faire nos requtes. Dans le mme ordre dide, une lecture de la documentation de la bibliothque httplib2 (24) ft ncessaire. Quatrimement, dans le but doffrir un module robuste et fiable, nous avons utilis le framework de tests unitaires de Python (25). La lecture de la documentation de cet utilitaire nous a permis de confirmer lutilisation que nous en faisions. Cinquimement, nous retrouvons toutes les lectures relies aux analyseurs techniques utiliss. Pour lalgorithme Relative-Strengh-Index (RSI ), les sites dabcBourse (26), deduBourse (27) et de ComprendreLaBourse (28) furent consults. Pour lalgorithme Directional Movement Index (DMI ), les sites dabcBourse
(29),
de
TraderWorkstation (30), de Mataf (31) et de la Trading-School (32) nous ont permis den apprendre un peu plus. Pour lalgorithme Arms Ease of Movement Value (EMV ), nous navons eu besoin que de linformation recueillie sur le site deduBourse
(33).
Finalement, les sites dabcBourse et deduBourse ont aussi servis pour les algorithmes de moyenne mobile arithmtique (MMA ) (34) et Stochastic (35) . Bien sr, plusieurs autres ouvrages sur le domaine financier nous ont aids dans le projet au courant de la session. Ces derniers sont documents dans ltude du domaine financier (36).
9|Page
Rapport de fin de projet Dcembre 2010 Initialement, nous avons explor de multiples ouvrages dauteurs qui ont utilis lintelligence artificielle dans le but dobtenir des performances de transactions boursires. Parmi ces derniers, on retrouve Using Neural Networks to Forecast Stock Market Prices
(37)
de Ramon Lawrence, Stock price forecasting:
autoregressive modelling and fuzzy neural netwok (38) de Duan Marek, Forecasting the portuguese stock market time series by using artificial neural networks
(39)
de
Monica Isfan, Rui Menezes et Diana A. Mendes, et finalement Stock Market Prediction Using Artificial Neural Networks (40) de Birgul Egeli, Meltem Ozturan et Bertan Badur. En conclusion, un site fort utile pour tous les modules qui fut consult de nombreuses reprises est Stack Overflow dveloppeurs en informatique.
(41),
un forum spcialis pour les
10 | P a g e
SYNTHSE DU PROJET
3.1
Prsentation
Tel que mentionn prcdemment dans la mise en contexte (section 1.2), le
projet Stock Overflow consiste une application de simulation de gestion de portefeuille. La plus value du logiciel se trouve dans lajout de la gestion de risque. la suite de notre tude des applications existantes similaires (42), nous nous sommes aperus que nous tions les seuls offrir cette fonctionnalit. De plus, lapproche prconise fut dorienter le dveloppement vers un outil pdagogique. Grce ce logiciel spcialis, les tudiants en finance pourront approfondir leurs connaissances sur le march boursier. Lintgration dun joueur artificiel est justifie par notre intrt comptitionner contre les autres utilisateurs. Malgr notre absence de formation dans ce domaine au dbut de la session, nous voulions vrifier notre capacit performer. Notons que le joueur artificiel pourrait aussi tre utilis pour dmontrer mathmatiquement le raisonnement quun gestionnaire devrait avoir. Dun point de vue plus technique, la ralisation dun tel genre de projet ncessitait une sparation flagrante des composants, tel quon peut le voir la Figure 1.
Figure 1 Sparations des composants
Comme on peut le constater, il sagit dune division de trs haut niveau. Il est ncessaire de la garder en tte pour comprendre le raisonnement derrire nos choix dans la suite du document.
11 | P a g e
3.2
Changement dorientation du projet

Il faut savoir que le projet Stock Overflow na pas toujours eu la forme dont
il a prsentement. la base, la notion de simulation nexistait pas. Nous voulions construire une application qui servirait daide la dcision pour des individus sans connaissance majeure dans le domaine de la bourse et qui souhaitaient sy initier. Pour y arriver, nous avions lintention dinterprter les nouvelles sur le Web afin de dterminer leur influence, positive ou ngative sur la valeur du titre associ. De plus, nous aurions utilis des indicateurs techniques pour augmenter lefficacit de nos prdictions. Cependant, la semaine 6 de la session, nous avons rencontr des gens de la Facult dadministration de lUniversit de Sherbrooke qui avaient entendu parler de notre projet. Ces derniers cherchaient depuis quelque temps se munir dun outil de simulation de gestion de portefeuille. Nous leur avons donc prsent notre travail, afin de voir si nous pouvions concorder nos projets. Il sagissait dune rencontre pour discuter de ce que nous pourrions faire pour adapter notre solution leurs besoins. Nous avons convenu de prparer des documents plus formels pour bien prsenter le changement de direction que prendrait le projet. la suite d'une deuxime rencontre, le 18 octobre 2010, ils nous ont prsent un document prsentant leur vision de ce quils aimeraient avoir. De notre ct, nous nous tions prts au mme exercice afin de voir si nous pouvions faire de la place dans notre projet initial pour implmenter leurs fonctionnalits. Heureusement, nous avions sensiblement la mme pense ce sujet. Ensuite, nous avons fait une valuation du temps requis pour raliser les changements faisant passer le projet initial de gestion de portefeuilles pour un utilisateur dbutant avec aide la dcision (via une prdiction de laction qui devrait tre prise sur chaque titre) vers un projet de jeu de simulation o le participant occuperait le rle dun gestionnaire devant performer du mieux quil peut (2). En nous basant sur les temps estims au tout dbut du projet, nous avons coup certaines fonctionnalits que nous voulions faire, afin de nous laisser du temps pour ajouter le ncessaire pour la simulation.
12 | P a g e

Tableau 1 Tableau rcapitulatif des changements
STATUT Retrait
FONCTIONNALIT
TEMPS ESTIM (en heures) 40 120 45 50 255
Indexation de nouvelles Analyse lexicale des nouvelles Gestion des favoris Recherche dinformations sur une entreprise Sous-total
Ajout
Joueur artificiel Gestion des utilisateurs Console dadministration Tableau de bord Contrleur de jeu Document de revue dapplications similaires Sous-total
80 20 50 20 75 10 255
BILAN
+/- 0
Comme nous pouvons le constater dans le Tableau 1 Tableau rcapitulatif des changements, la balance des changements apporter est nulle, ce que signifie que thoriquement, changer compltement lorientation du projet ne devrait pas affecter la russite et la compltion de Stock Overflow . Suite cette conclusion, nous avons pris la dcision de suivre cette voie.
13 | P a g e
3.3
Organisation
Tout dabord, il est impratif de prsenter notre quipe de travail afin de
mettre en contexte lapport de chacun dans le projet. Dans le Tableau 2, les membres des Fantastic 6 sont numrs avec la, ou les, fonctions affectes suite un commun accord dans le contrat dquipe (43).
Tableau 2 Affectations des membres de lquipe
NOM ric Sylvestre Yannick Charron Genevive Lamarche Samuel Dionne Alexandre Deschamps Jean-Michel Nadeau
FONCTIONS Chef dquipe Responsable du client et des infrastructures Responsable de la documentation Responsable du serveur de donnes Responsable de lintelligence artificielle
Responsable du joueur artificiel et de la base de donnes. Adjoint au chef dquipe.
Nous nous sommes bass sur les forces et les connaissances de chacun pour former des petites quipes de travail. Comme nous avions trois sections importantes raliser client, joueur artificiel et serveur , il a t simple de former des duos et ainsi mieux diviser le travail. Donc, pour le client, ric et Yannick ont travaill la majeure partie du temps ensemble pour implanter les fonctionnalits ncessaires. Du ct du serveur, ce sont Samuel et Genevive qui se sont occups de btir les services Web utiliss par le client et le joueur artificiel. Finalement, le joueur a t principalement le travail dAlexandre et de Jean-Michel. Bien que cette faon de procder limite les apprentissages de chacun, nous avons dcid que le produit final serait de meilleure qualit, et que nous pourrions inclure beaucoup plus de fonctionnalits dans Stock Overflow . Aux membres de lquipe sajoutent dautres personnes impliques dans la ralisation du projet. Tout dabord, M. Gabriel Girard a agi en tant que superviseur
14 | P a g e
Rapport de fin de projet Dcembre 2010 tout au long de la session. Nous avons donc pu profiter de ses nombreuses recommandations constructives dans tous les aspects de la conception. Finalement, nous avons t choys en ayant deux prcieux collaborateurs, soient M. Frank Coggins, professeur la Facult dadministration de lUniversit de Sherbrooke, ainsi quAbdennabi Khiari, coordonnateur la salle des marchs de la mme facult. Lide originale de simulation de gestion de portefeuille provient de M. Coggins, qui a ainsi pu nous prsenter sa vision de lapplication. De son ct, M. Khiari nous a guids dans nos recherches dinformations sur le march financier. Nous sommes trs chanceux davoir pu compter sur laide de ces messieurs, car leur apport en termes de connaissances et de conseils a t enrichissant pour nous tous.
3.4
projet :
Hypothses et contraintes
Quelques hypothses ont t releves afin de permettre la ralisation du
Nous sommes en mesure de produire un outil pdagogique sur la simulation de gestion de portefeuille. Un systme intelligent est en mesure de performer dans la gestion de portefeuille. Nous pouvons utiliser des donnes disponibles gratuitement pour arriver notre but. De mme, certaines contraintes ont t dtermines. En effet, les parties prenantes doivent tre en mesure de tester le systme dune faon autonome, ce qui veut dire que les membres des Fantastic 6 ne sont pas requis pour lessai de lapplication. Le systme doit pouvoir sexcuter sous Windows 7. Idalement, des machines virtuelles (VMWare) seront installes et graves sur disque. Ces machines doivent contenir une version complte et fonctionnelle de chaque partie du systme.
15 | P a g e
3.5
Livrables
Afin de sassurer de toujours progresser dans la ralisation du projet, les
livrables constituent un bon indice pour mesurer lavancement. Dans le cadre du projet Stock Overflow, nous avons tabli des livrables en tenant compte des fonctionnalits que nous voulions ajouter lapplication, en plus des documents ncessaires. On retrouve, dans le Tableau 3, lnumration de tous les livrables qui figurent dans la liste des activits requises pour complter le projet.
Tableau 3 numration des livrables
CODE MAN ETU SES IHM RDS SAS SCL PGP PVV -
LIVRABLE Mandat de prestation de service Document dtude du domaine financier Spcification des exigences du systme Guide dinterface homme-machine Rapport de suivi de projet Analyse technique du cerveau Spcification d'architecture de systme Spcification de conception de logiciel Plan de gestion de projet Plan de vrification et validation Base de donnes Obtention dune cote Services Web (transactions, titres, utilisateurs et prdictions) Gestion des utilisateurs Onglet de dtails dun titre Application client fonctionnelle, navigable et qui affiche des donnes provenant du serveur
RAS -
Ordonnanceur des tches de prdictions Document de revue dapplications similaires Services Web (portefeuille, administration et tableau de bord) Tableau de bord
16 | P a g e
Rapport de fin de projet Dcembre 2010 PDD DDP RFM BIP BFP Fonctionnalits de gestion dun portefeuille Fonctionnalits des transactions Rseau de neurones pour le joueur artificiel Plan de dploiement Contrleur de simulation Onglet dadministration dans le client Rapports de simulation Joueur artificiel complet Diaporama de prsentation Rapport final et rcapitulatif Bilan individuel de fin de projet Bilan de fin de projet
Bien que cela semble comprendre tout le travail que nous avions faire, il faut apporter une nuance : il sagit de livrables et non de tches. Cela veut simplement dire que du travail connexe a d tre fait afin de nous permettre de complter ces fonctionnalits et ces documents. Par exemple, aucun livrable portant sur la mise en place de nos serveurs nest prsent, alors quune priode de temps considrable a t consacre cette tche. Ceci dit, cest la lueur des documents des personnes ressources de la Facult dadministration de lUniversit de Sherbrooke, ainsi que de nos rencontres dquipe que nous avons pu tablir cette liste de livrables. Elle constituait, selon nous, les critres de russite du projet.
17 | P a g e
REVUE DES PROCESSUS DE GESTION
4.1
Mise en route
Un projet denvergure comme Stock Overflow ncessite une structure de
gestion de projet solide. Il est impensable de se lancer dans la conception sans avoir pris le temps de bien diviser le travail et sentendre sur celui-ci. Il nest pas rare, dans notre domaine, dapprendre que des projets ont chou, non pas parce que le produit ntait pas adquat, mais bien en raison dun processus de gestion inefficace. Cest pourquoi nous avons pris du temps ds le dpart pour dfinir la faon de procder tout au long de la session. Cette prparation simposait et chacun devait comprendre ce que cela entranait. Aprs les discussions, nous avons dcid de suivre les mthodologies Agiles pour guider notre projet, plus prcisment lorientation Scrum . Les mthodes Agile sont des groupes de pratiques pouvant sappliquer [] aux projets de dveloppement en informatique et se veulent plus pragmatiques que les mthodes traditionnelles. Elles impliquent au maximum le demandeur (client) et permettent une grande ractivit ses demandes. Elles visent la satisfaction du client et non les termes dun contrat de dveloppement. (44) En ce qui concerne la mthode Scrum , qui appartient au monde Agile , Il sagit dun processus simple pour grer et contrler le dveloppement dun produit. Contrairement lapproche en cascade [] Scrum requiert peu dartefacts. Cela se concentre sur ce qui est important : grer un projet ou produire un logiciel qui amne une valeur ajoute une entreprise. (45). Ces choix sont justifis par le fait que ce sont des pratiques qui taient connues de tous les membres de lquipe. Comme la nature du projet ntait pas dfinitive au dpart, nous devions tre rapides nous adapter aux changements apporter lapplication. Une fois lentente sur le processus de gestion complte, nous avons mis en place les outils ncessaires pour aider au suivi hebdomadaire que nous allions pratiquer. Nous avons opt pour le logiciel JIRA de la compagnie Atlassian
(46)
Cest une application Web qui permet dappliquer les mthodes Agile et Scrum
18 | P a g e
Rapport de fin de projet Dcembre 2010 notre dveloppement. Encore une fois, la dcision dy aller avec ce logiciel est due lexprience gnrale de la majorit de lquipe avec JIRA . Nous avions donc notre outil o toute linformation relative aux tches et au temps investi sur le projet serait consolide.
4.2
Planification
Selon les mthodologies employes, notre projet se divise en sprints qui vont
du mercredi au mardi. Les sprints ont t regroups afin de former cinq itrations. Nous avons rattach des livrables aux itrations et ainsi, la vrification et le contrle de lavancement du projet. Le mercredi nous nous rencontrons afin de faire un sprint review et un sprint planning. Cela consiste faire une rtrospective (sprint review) de ce qui a t fait durant la semaine prcdente. On y parle aussi des problmes encourus, des rflexions quon a dues faire et des tches qui nont pu tre termines. De plus, nous prvoyons le travail qui devra tre fait dans la prochaine semaine (sprint planning). Cette planification est accomplie tout dabord par un remplissage du backlog. Le backlog est un ensemble de fonctionnalits et de tches raliser pour arriver produire des livrables. Il est de la responsabilit du chef dquipe dajouter ces items dans le backlog. Par la suite, lors de chacune des rencontres de planification, nous donnons une estimation du temps ncessaire pour la ralisation de chacune de ces tches. Une fois cela fait, nous incluons un nombre arbitraire dlments dans le sprint afin datteindre le nombre dheures dsir. Habituellement, un total de 120 heures y sera consacr, rparti aux six membres de lquipe, qui doivent contribuer raison de vingt heures par semaine (47). Notons que le temps pass en classe lors de rencontre avec M. Luc Lavoie est comptabilis dans ces vingt heures. Plus de dtails sur le fonctionnement des pratiques Agile et Scrum sont disponibles dans le plan de gestion de projet (PGP) (47).
19 | P a g e
4.3
Excution
Comme nous avons choisi de petites priodes de travail dune semaine, il fut
facile de voir rapidement le progrs et de sajuster lorsque cela devenait ncessaire. Les quipiers devaient veiller bien documenter leurs tches dans JIRA et inscrire leur temps correctement. Pour le chef dquipe, le suivi devenait plus simple en raison des graphiques dvolution fournis avec le logiciel de gestion de projet. De plus, comme nous ntions pas toujours en quipe pour travailler, JIRA aidait les gens voir ce que les autres taient en train de faire. Cela vitait donc que deux personnes travaillent en mme temps sur une mme tche. Par la suite, lorsquest venu le te temps de procder une priode de tests plus intense, JIRA nous a t fort utile. En effet, lorsquune personne dcouvrait un nouveau bogue ou problme avec lapplication, elle ouvrait une nouvelle tche et lassignait une personne responsable de la partie do mergeait lerreur. Cette personne recevait alors un courriel linformant de la situation et pouvait donc commencer investiguer sur la nature du problme.
4.4
Contrle
Qui dit gestion de projet, dit ncessairement contrle. En effet, il est bien
beau mettre en place tout un systme visant structurer les pratiques, il est impratif davoir un moyen de mesurer leffort et lavancement du projet. Tel que mentionn plus tt, cest principalement lors de nos rencontres de sprint review que nous procdions ce genre de contrle. Tout dabord, le chef dquipe se chargeait de produire un rapport de suivi qui faisait tat de toutes les tches dont du temps a t investi pendant le sprint prcdemment. Une mise jour sur le statut des livrables pour litration en cours tait aussi incluse. La totalit des feuilles de temps relatant linvestissement de chacun faisait aussi partie du rapport. Finalement, une conclusion prsentant les impressions du chef dquipe sur le progrs et le droulement du sprint terminait le rapport.
20 | P a g e
Rapport de fin de projet Dcembre 2010 Une rencontre entre le chef dquipe et le superviseur du projet permettait ce dernier de voir lavancement du projet. Il pouvait aussi y aller de ses recommandations pour la suite et ainsi rester au courant de ce qui se passait. En fin ditration, une prsentation de Stock Overflow tait faite pour voir concrtement le rsultat des efforts mis pendant cette priode. Sans le moindre doute, cette surveillance troite a certainement permis de se rendre plus loin que prvu dans le projet, car les quipiers ne pouvaient mentir sur lavancement. En effet, si par exemple, une tche consistait ajouter de la couleur dans une fentre de lapplication, mais que cette couleur ne sy trouvait pas la fin du sprint ou de litration, cela va sen dire quil y a eu un manque un certain niveau.
4.4.1 Investissement sur les livrables

Dans le Tableau 4, on retrouve un rcapitulatif des livrables selon litration laquelle ils se rattachaient.
Tableau 4 Rcapitulatif des livrables par itration
Itration Activits
1 Mandat Document dtude du domaine financier Spcification des exigences Guide dinterface homme-machine Rapport de suivi de projet TOTAL ITRATION #1
Remise
temps temps temps temps temps
Temps investi
194 heures
Spcification d'architecture de systme Spcification de conception de logiciel Plan de gestion de projet Plan de vrification et validation Analyse technique du cerveau
temps temps temps temps Retard (1 semaine)
21 | P a g e
Rapport de fin de projet Dcembre 2010 Rapport de suivi de projet TOTAL ITRATION #2 temps 224,7 heures
Base de donnes Obtention dune cote Services Web (transactions, titres, utilisateurs et prdictions) Gestion des utilisateurs Onglet de dtails dun titre Application client fonctionnelle, navigable et qui affiche des donnes provenant du serveur Ordonnanceur des tches de prdictions Rapport de suivi de projet
temps temps temps temps temps
temps
temps temps 365,74 heures
TOTAL
ITRATION #3
Document de revue dapplications similaires Services Web (Portefeuille, administration et tableau de bord) Tableau de bord Fonctionnalits de gestion dun portefeuille Fonctionnalits des transactions Rseau de neurones pour le joueur artificiel Plan de dploiement Rapport de suivi de projet
temps
temps temps temps temps temps temps temps 399 heures
TOTAL
ITRATION #4
22 | P a g e
Rapport de fin de projet Dcembre 2010 5 Contrleur de simulation Onglet dadministration dans le client Rapports de simulation Joueur artificiel complet Diaporama de prsentation Rapport final et rcapitulatif Bilan individuel de fin de projet Bilan de fin de projet TOTAL ITRATION #5 504,57
TOTAL PROJET
1 723
Pour une raison de clart, le temps investi par livrables nest pas inscrit. Seul le total par itration est prsent. On remarque, dans ce tableau, quun seul retard a t not. Cependant, les dommages ont t limits en raison du peu de temps qui a t requis pour rattraper le retard. Cette statistique tmoigne de limpressionnante prcision dont les Fantastic 6 ont fait preuve lors des estimations de temps de chacune des tches.
4.4.2 Efforts des membres de lquipe

Pour arriver un produit final de la qualit de Stock Overflow, il a fallu tenir un effort soutenu de la part de tous les membres de lquipe, et ce, tout au long de la session. Nous avons ralis quun projet denvergure ncessite beaucoup
dinvestissement personnel. ce niveau, les membres des Fantastic 6 ont fait preuve dun total dvouement leur projet. Dans le Tableau 5, on retrouve un bilan du temps investi pour chacun des quipiers.
23 | P a g e

Tableau 5 Bilan du temps investi Yannick Charron 54 Alexandre Deschamps 36 Samuel Dionne 33 Genevive Lamarche 35,5 JeanMichel Nadeau 34 ric Sylvestre 36,5
Priode
Total
Sprint 14 Sprint 5 Sprint 6 Sprint 7 Sprint 8*
229
22,5 20,67 20 42,83 20 22,5 20,75 20,25 20,33 20,5 20 304,33
17,67 19,78 21 40,33 22,5 20,75 25,5 19,75 20 28,75 20 292,03
15 19,75 10,25 42 21,5 22,5 27 24,25 22,32 21,33 20 278,91
18 20 14 43,83 20 22,75 20,25 22,5 22,25 17,5 20 276,58
9 17,75 22,75 42,08 21 22,25 23 15,25 18 25,75 20 270,83
24,33 20,25 20,67 46 20 26 20,75 20 20,08 25,75 20 300,33
106,5 118,2 108,67 257,07 125 136,75 137,25 122 122,98 139,58 120 1 723
Sprint 9 Sprint 10 Sprint 11 Sprint 12 Sprint 13 Sprint 14 Sprint 15(**) Total
* : Ce sprint a dur deux semaines. ** : Ce sprint a t ajout pour la balance du travail qui sera fait entre la fin de la rdaction de ce document et la remise finale. Voir la conclusion du rapport de suivi du sprint 14 (48) pour plus de dtails.
On constate que tout le monde a russi faire au moins le nombre dheures minimal pour le cours, soit 270 heures. Considrant la session charge que les membres de lquipe avaient, il sagit dune trs belle ralisation. Les gens ont pris cur le projet et cela a eu beaucoup de rpercussions positives sur le produit final.
4.5
Le gain de cette pratique

Certains pourraient se demander pourquoi nous avons opt pour les
pratiques Agiles et Scrum au lieu de par exemple, la mthode en cascade. Et bien, comme nous savions que notre projet serait en constante volution et que les besoins pourraient changer rapidement, nous avions besoin dun processus de gestion adapt notre ralit.
24 | P a g e
Rapport de fin de projet Dcembre 2010 Cette dcision fut probablement la plus importante de toutes celles prises au cours de la session, car tel que mentionn la section 3.2 Changement
dorientation du projet du prsent document, un changement norme a eu lieu sur lorientation du projet. Indubitablement, cette restructuration naurait jamais t possible dans le cadre dun projet en cascade. Selon cette approche, tous les documents auraient t prpars lavance pour quil ne reste qu transformer lanalyse en vritable code. De notre ct, nous y allions mthodiquement en analysant les fonctionnalits tout juste avant de les programmer. Ainsi, lorsquil ft le temps dvaluer les risques pour tudier le possible changement dorientation, nous navons eu qu retirer certains modules ncessaires pour le projet initial et ajouter lensemble des nouveaux besoins. videmment, il faut avouer que cette transition naurait pas pu tre possible beaucoup plus tard, en raison des limites de temps du projet. Cependant, dans une approche autre quAgile , cette limite aurait t beaucoup plus tt. Il faut comprendre que cest pratiquement 40% des fonctionnalits que nous avons d modifier pour permettre lintgration dun jeu de simulation de gestion de portefeuille. Consquemment de la transformation de la nature de Stock Overflow , nous avons pu abaisser le niveau de risque de russite du projet. Initialement, nous prvoyions faire de lanalyse lexicale de nouvelle afin dy dceler un signe encourageant ou non pour les titres boursiers associs. Ce module tait le gros point dinterrogation du projet, compte tenu de la complexit de cette opration. Manifestement, nous naurions pas eu les rsultats esprs et limpression de russite aurait t moins grande. Bref, nous sortons gagnants de ce chamboulement, tout comme les gens de la Facult dadministration, qui se retrouve avec une bonne version originale doutil de simulation de gestion de portefeuille avec proccupation de la gestion de risque. Cela a t rendu possible principalement en raison de notre gestion efficiente.
25 | P a g e
5
5.1
REVUE DES PROCESSUS TECHNIQUES

Dcomposition modulaire
Figure 2 - Dcomposition gnrale
Stock Overflow
Les flches signifient utilise .
Module client
Module serveur
Joueur artificiel
la Figure 2, on retrouve la dcomposition gnrale de Stock Overflow . Ce dcoupage a t fait selon les ncessits du projet, en plus de vouloir offrir une meilleure sparation du travail. Il est important de garder en tte cette sparation pour comprendre certains choix expliqus plus loin dans le document.
5.2
Architecture
Lapplication du client a t dcoupe de faon bien sparer la logique
5.2.1 Module du client
daffaire de linterface graphique. Cela est ncessaire afin de prvoir le futur. En effet, si nous voulions transformer le client en site Web, nous naurions besoin que de construire les pages et dappeler notre bibliothque de fonctions qui communique avec le serveur.
Figure 3 Division du client
StockOverflow.Client.UI SERVEUR utilise communique
StockOverflow.Client.Log ic 26 | P a g e
Rapport de fin de projet Dcembre 2010 Dans le but de faciliter toute modification et amlioration de la partie cliente de Stock Overflow, nous dcoupons tout ce qui touche linterface graphique et la logique ncessaire au traitement des donnes. Comme on peut le voir Figure 3, la couche de prsentation
(StockOverflow.Client.UI) utilise la couche logique (StockOverflow.Client.Logic) pour obtenir les donnes. Cette couche logique communique avec le serveur pour rpondre la demande du client. Couche de prsentation : Module contenant les fentres et les contrles pour la totalit de lapplication. Couche logique : Module contenant toutes les entits du domaine daffaires, les contrats indiquant les signatures des mthodes et limplmentation directe des fonctionnalits. Le processus de traitement est ainsi reprsent : 1. Lutilisateur exploitera une fonctionnalit de lapplication via
linterface graphique. 2. Cette action se traduira par un appel la couche logique. 3. Cette dernire appellera le serveur via un service Web pour obtenir la rponse. Division de la couche logique
Figure 4 Division de la couche logique
27 | P a g e
Rapport de fin de projet Dcembre 2010 La Figure 4 nous permet de voir les principales divisions dans la couche logique. Cette sparation nous permet dobtenir un meilleur regroupement de nos classes et offre une flexibilit trs intressante. Voici une brve explication de chacune de ces sections. Contracts : Les contrats sont en ralit les interfaces qui offrent les fonctionnalits. En regroupant les mthodes selon leur contexte dopration, nous nous assurons de bien rpondre la totalit des besoins. Managers : Ce sont les classes les plus importantes de la couche logique. Cest cet endroit que tout le traitement des donnes est fait. Tel que mentionn prcdemment, la grande majorit du temps, un appel est fait au serveur pour complter lopration dsire. Models : Il sagit de tous les objets du domaine daffaires. Dans le cas qui nous intresse, on parle probablement dune cote ou dun utilisateur, par exemple. Division de la couche de prsentation
Figure 5 Divison de la couche de prsentation
la Figure 5, on retrouve notre division de la couche prsentation. Sur le graphique, on ne retrouve que les sections importantes la comprhension. Dans le cadre du projet, nous implmentons le patron de conception Model-View-ViewModel (MVVM) (9). Cette approche permet de mieux sparer le travail entre les graphistes et les programmeurs. En effet, la View ne se proccupe pas du contenu quelle doit
28 | P a g e
Rapport de fin de projet Dcembre 2010 afficher. Ce rle revient au ViewModel qui enveloppe nos entits du domaine daffaires (Models). De plus, la sparation selon le patron MVVM permet de faciliter les tests unitaires, car nous pouvons tester les actions de lutilisateur sans avoir besoin dun vrai utilisateur pour les faire. Enfin, le contrleur dapplication (ApplicationController) soccupe de faire le lien entre toutes ces parties. Voici un sommaire expliquant les diffrents composants de ce dcoupage. Views : Il sagit de toutes les fentres de linterface homme-machine. Ces vues ne contiennent aucune logique outre celle relative linteraction avec lutilisateur. ViewModels : Cest le lien entre les entits du domaine daffaires et linterface graphique. Le ViewModel reprend les proprits de lentit afin de mieux interagir avec les contrles. Models : Cette section appartient la couche logique, cest ce qui explique la diffrence daffichage dans la Figure 5. Il sagit des objets du domaine daffaires. ApplicationController : Il fait le lien entre les Views et les ViewModels afin dviter tout couplage entre linterface et le comportement de cette dernire.
29 | P a g e
5.2.1 Module du serveur

la Figure 6, on retrouve la vision des composants inclus dans le serveur. Voici une brve explication de chacun de ces composants.
Figure 6 Division des composants du serveur
Service Web : Les services web sont en ralit les interfaces qui offrent les fonctionnalits du serveur aux diffrentes parties prenantes. En regroupant les mthodes selon leur contexte dopration, nous nous assurons de bien rpondre aux besoins. Job : Les jobs sont des tches qui sexcutent automatiquement, selon un intervalle donn, pour effectuer diffrents calculs. Par exemple, certaines tches servent pour le calcul les valeurs des portefeuilles des joueurs en fin de journe. Simulation : Dans ce module, on retrouve des classes qui ont pour but daccomplir diffrents calculs pour les portefeuilles. Elles sont appeles par le module des jobs. Rgle : Toutes les rgles des simulations sont vrifies dans ce module. Elles se divisent en trois types : les rgles quotidiennes, les rgles de fin de priode
30 | P a g e
Rapport de fin de projet Dcembre 2010 et les rgles de dbut de priode. Elles sont aussi appeles par le module des jobs. Service : Cette partie est le lien entre la persistance et les autres modules voulant effectuer des oprations (Service Web, Simulation et Rgle). Persistance : Cest ce module qui soccupe de persister les donnes et de faire les accs la base de donnes. Model : Il sagit de tous les objets du domaine daffaires. Dans le cas qui nous intresse, on parle probablement dun titre ou dun utilisateur, par exemple. Communication : Ce dernier est responsable daller chercher des
informations sur internet par services web. Il servira notamment pour aller chercher les informations sur les titres lorsquelles ne se trouvent pas dj dans la base de donnes. Lorsque nous avons d dfinir larchitecture du serveur, nous avons dcid de sparer la couche de donnes de tout le reste. Compte tenu que, selon les donnes demandes, le systme aurait rechercher plusieurs endroits, nous avons ajout la couche Service , dans le but de rendre la recherche des donnes transparente pour les classes plus hautes. Cest pour cette raison que tous les objets voulant effectuer une transaction sur des donnes doivent passer par le service correspondant au type de ces donnes. De son ct, le service se chargera de rpondre la demande en interrogeant soit la couche Persistance , pour les donnes directement dans la base de donnes, soit la couche Communication , pour les donnes se trouvant sur Internet.
31 | P a g e
5.2.3 Module du joueur artificiel

Figure 7 Structure interne du joueur artificiel
Nous pouvons observer, dans la Figure 7 ci-dessus, une revue globale de larchitecture du composant cerveau de Stock Overflow. Voici les diffrents modules de ce dernier : Services Web : Les services Web sont les interfaces qui offrent les fonctionnalits du serveur aux diffrentes parties prenantes. net : Ce module a pour objectif de contenir tout ce qui a attrait aux requtes et aux rponses du Web. Cest partir de ce dernier que nous faisons tous nos appels aux services Web. Aussi, la srialisation et la dsrialisation des requtes/rponses du format JSon en objet logique sont faites dans ce module. ta : Cest le premier niveau intelligent. Il contient toutes les notions danalyse technique de notre systme. On y retrouve en effet tous nos diffrents algorithmes danalyse techniques, soit : cmf, dmi, emv, mma, rsi et stochastic. Ils contiennent aussi le code ncessaire pour garder en cache tous les rsultats des diffrents algorithmes et le code pour les visualiser laide de
32 | P a g e
Rapport de fin de projet Dcembre 2010 linterface administrateur Django. Il utilise le module net pour aller chercher les donnes qui lui sont ncessaires afin deffectuer ses diffrents calculs. nn: Ceci est le cur de lintelligence de notre cerveau. Il contient, entre autres, un module python du nom de neuralnetwork. Dans ce dernier, on retrouve notre abstraction du rseau de neurones avec ses mthodes ncessaires pour sa calibration, son entranement et son activation. De plus, on y retrouve les outils ncessaires pour le srialiser dans le cache, le charger du cache, ainsi quobtenir le meilleur rseau de neurones pour un titre donn. Il sert grossirement pondrer les diffrents algorithmes que lon retrouve dans le module ta. Il utilise aussi le cache pour sauvegarder son tat. Il fournit, laide des indicateurs pondr, une utilit un titre boursier. Encore une fois, une interface administrateur Django est disponible pour visualiser le niveau de confiance de chaque rseau de neurones, ainsi que dautres statistiques intressantes. user : Cette partie du cerveau se sert de labstraction des connaissances faite par les rseaux de neurones pour offrir une gestion de portefeuille complte. Elle se sert de cette dernire pour choisir quelles actions il entreprendra. Il soccupe de la gestion des actifs, du budget, de la diversit et du risque du portefeuille. Ce module contient aussi un scheduler, qui a comme rle de faire jouer le joueur artificiel chaque jour une heure donne, de manire le rendre compltement autonome. Larchitecture du systme est dfinie en couches dabstraction de linformation. Donc, on a un joueur qui consomme plusieurs rseaux de neurones, chacun de ces derniers consommant plusieurs algorithmes, qui eux exploitent directement les donnes du serveur.
33 | P a g e
5.3
Infrastructures
Nous avons dcid de faire linterface graphique laide de la nouvelle
technologie de Microsoft, Windows Presentation Foundation (WPF). Nous avons fait ce choix en raison de lexprience de certains membres de lquipe, ainsi que de notre mprise envers certaines technologies existantes pour crer des interfaces. Le choix de prendre WPF fait aussi partie de notre processus dapprentissage que nous avons pu parfaire laide des livres WPF 4 Unleashed WPF in C# 4.0 (3). Cest pour cette raison que les utilisateurs doivent tre sur une machine supportant un des systmes dexploitation de Microsoft, partir de Windows XP. En raison de la nouveaut de la technologie et de la grande quantit de graphiques de lapplication, nous ne pouvons recommander une machine ne possdant pas au moins un giga-octet de mmoire vive. Les requis logiciels seront installs au mme moment que lapplication et ne devraient pas apporter aucun problme lutilisateur.
(4)
et de Pro

Le serveur doit rouler sur Windows ou Linux. Il utilise un serveur dapplication GlassFish et une base de donnes MySQL.

Le joueur artificiel peut tre excut sur nimporte quelle plateforme supportant linterprteur Python 2.6. Le cache, quant lui, est fait avec une base de donnes Sqlite. La raison de ce choix est simplement quil est directement imbriqu dans la bibliothque Django. Il est gnr et maintenu par Django. Par la suite, pour pouvoir excuter le joueur artificiel, il faut simplement sassurer que toutes les bibliothques spcifies dans le plan de dploiement soient installes. Plus de dtails sont prsents dans le plan de dploiement dutilisation (section 8 du prsent document).
(49)
et le guide
34 | P a g e
5.4
Algorithmes techniques
Nous avons fait beaucoup de recherches avant de choisir nos analyses
5.4.1 Choix des algorithmes et justification
techniques. Initialement, elles ntaient pas destines servir dans le rseau de neurones, mais la lecture de plusieurs articles sur les prvisions boursires grce aux rseaux de neurones et notre rflexion, nous avons revu leurs utilits. Au dpart, nous avions slectionn quatre algorithmes, soit le RSI, le mouvement directionnel (DMI), les moyennes mobiles (MMA) et le Stochastique. Ces algorithmes ont t choisis pour leur simplicit dimplmentation et pour leurs rsultats obtenus moyen et court terme. Par la suite, nous avons mis en place le rseau de neurones et notre module danalyse technique a grossi, en plus dajouter les algorithmes Chaikin Money Flow (CMF) et Ease of Movement (EMV). Les raisons qui ont motiv nos choix ont t sensiblement les mmes que les quatre premiers algorithmes, soit la simplicit dimplmentation et les rsultats moyen et court terme. Toutefois, nous voulions de plus que les algorithmes donnent des indications diffrentes des algorithmes que nous avions dj, pour quils ragissent dans des conditions diffrentes des autres indicateurs, dans le but de diversifier notre rseau de neurones.
5.4.2 Performance et corrlation

Nous avons test individuellement que chaque algorithme ragissait de la faon dont il tait suppos. Cependant, les calculs de RSI et Stochastic sont similaires. Donc, il serait normal que lon puisse voir une corrlation entre ces deux indicateurs dans les rseaux de neurones. Aprs avoir test le bon fonctionnement de chaque algorithme, nous avons entrain plusieurs rseaux de neurones pour pondrer lutilisation des algorithmes danalyse technique en fonction dun titre.
35 | P a g e
5.4.3 Le rseau de neurones

Introduction Considrant que le rseau de neurones est une partie autant cruciale que complexe du cerveau, il semble ncessaire den glisser une explication plus labore. En premier lieu, il faut comprendre quil y a plusieurs rseaux diffrents de neurones dans notre systme qui agissent comme des experts pour chaque titre boursier. La raison de ce choix est que les algorithmes danalyse techniques sont reconnus pour devoir tre interprts de manire diffrente sur chaque titre. En dautres mots, un mme algorithme peut tre extrmement prcis avec Google, mais tre toujours dans lerreur avec Amazon. Cest pour cela que nous entranons un rseau de neurones par titre.
Pourquoi? Avant de nous lancer dans une solution comme un rseau de neurones, nous avons pris le temps dobserver plusieurs autres solutions ainsi que ce qui avait dj t fait. Comme prlminaires, nous avons lu des papiers tels que Using Neural Networks to Forecast Stock Market Prices
(37)
de Ramon Lawrence, Stock price
forecasting: autoregressive modelling and fuzzy neural netwok (38) de Duan Marek, Forecasting the portuguese stock market time series by using artificial neural networks (39) de Monica Isfan, Rui Menezes et Diana A. Mendes, et finalement Stock Market Prediction Using Artificial Neural Networks
(40)
de Birgul Egeli, Meltem
Ozturan et Bertan Badur. Aprs lecture de ces derniers, il semblait dj que ce qui avait le plus t fait tait des tentatives de crer des rseaux de neurones, parfois juxtaposs sur un algorithme gntique, avec comme objectif de prdire la bourse. Puis, lorsque nous avons tent de trouver de la documentation plus concrte sur le sujet, nous avons remarqu quil ne semblait pas y avoir de solutions disponibles nulle part; tout semblait thorique. Nous croyons pouvoir justifier cette absence de documentation claire par un manque de volont des chercheurs de diffuser les dtails, ou bien simplement parce quune implmentation na jamais t faite. Par la suite, nous avons observ les possibilits dutiliser des agents. Cependant, encore
36 | P a g e
Rapport de fin de projet Dcembre 2010 une fois, il semblait que les implmentations possibles tiennent encore en compte un de rseau de neurones. Ensuite, nous avions approfondi nos connaissances sur lanalyse technique paralllement nos recherches sur les rseaux de neurones. Pendant cette tude, nous avons constat que la faiblesse principale des diffrents modles danalyse technique tait que linterprtation de leur rsultat diffrait dun titre lautre. De cette constatation est ne une ide, celle denlever cette faiblesse laide dun rseau de neurones, qui se chargerait de pondrer les indications de chacun de ces algorithmes.
37 | P a g e
Rapport de fin de projet Dcembre 2010 Limplmentation Pour ce qui est de limplmentation proprement parler, nous avons opt pour ne pas rinventer la roue. Nous avons donc fait des recherches approfondies sur
Figure 8 - Structure du rseau de neurones
les diverses bibliothques dintelligence artificielle offerte en Python. Aprs plusieurs essais, nous avons convenus utiliser pybrain
(20) ,
cause de
son ergonomie, sa simplicit dutilisation et de ses diffrentes fonctionnalits. Nous utilisons sa
cration de rseau et son implmentation du populaire algorithme dentrainement de rseau de neurones back-propagation. Comme illustre dans la Figure 8, la structure du rseau est compose de chacun des rsultats des algorithmes en entre, qui auront une
interprtation diffrente, dpendant de chaque action en sortie. Puis, les trois neurones dactions se compilent en une seule sortie. Le rseau de neurones, lorsquactiv, retourne une utilit. Plus cette dernire est ngative, plus la vente est profitable, et plus elle est positive, plus lachat est profitable. Lentranement Dans un rseau de neurones, il est bien connu que la difficult premire est de lui trouver un entrainement idal. Nous avons recherch lentranement optimal, et nous nous sommes rapidement rendu compte que ctait l lart du rseau de neurones. En fait, il nexiste pas de formule pour trouver la solution parfaite. Donc, nous nous sommes lancs. Notre choix de technique dentranement sest arrt sur back-propagation parce quelle tait dj implmente dans pybrain et nous lavions dj tudi lors de la phase de recherche sur les rseaux neuronaux. Avec cette technique, nous offrons au rseau des chantillons dentres et une rcompense en sortie, puis lalgorithme se charge de propager les erreurs sur les fautifs. Les annes utilises pour nos entranements sont arbitrairement 2006-2007. Par la suite, il fallait donner un nombre ditrations dentranement qui utiliserait les 38 | P a g e
Rapport de fin de projet Dcembre 2010 donnes. Puisquencore une fois, il ne semblait pas y avoir une valeur magique qui conviendrait facilement nos besoins, nous en avons essay quelques-unes. Notre indicateur recherch tait que deux rseaux de neurones, initialiss par dfaut avec des poids alatoires diffrents, devaient finir avec sensiblement les mmes poids suite au mme entranement. Le nombre trouv fut 15 000 itrations.
Les donnes Aussi, comme on peut le constater dans la Figure 7, le rseau de neurones utilise le cache, qui est une base de donnes locale au joueur artificiel. En effet, tant donn que lentrainement dun rseau de neurones peut aller jusqu 3 heures et quon en a prsentement une centaine, il nous tait ncessaire de pouvoir les garder en mmoire. Ainsi, nous avons utilis un type de srialisation nomme pickle, qui est propre au langage Python. La raison de ce choix est simplement sa convivialit. En effet, le langage Python offre une srialisation de nimporte quel de ses objets sous forme de chaine de caractres. Nous nous en sommes donc servis pour crire dans la base de donnes les poids des diffrents rseaux. La calibration Aprs une tude des premiers rseaux de neurones entrans, nous avons fait une dcouverte intressante : le champ dexpertise dun rseau nest pas limit au titre avec lequel ce dernier a t entrain. Par exemple, bien quun rseau de neurones ait t entran avec le titre Google, nous avons remarqu que sa transaction moyenne a un profit de 2.7% sur ce mme titre, alors que ce mme rseau a une transaction moyenne de 31% avec un titre comme Amazon. Cest donc pour cette raison que nous avons instaur un systme de calibration, de confiance. Comme expliqu ci-dessus, un besoin de connaitre les performances de chaque rseau de neurones avec chaque titre sest install. Cet indice de performance est en fait le profit moyen, en pourcentage, de chaque transaction effectue. Nous avons donc fait jouer tous les rseaux de neurones avec tous les titres doctobre 2009 octobre 2010. Ces dates nont pas t choisies de manire compltement arbitraire. On ne pouvait pas faire une valuation des performances
39 | P a g e
Rapport de fin de projet Dcembre 2010 sur 2006-2007 tant donn que ces annes ont t utilises pour lentranement. Puis, nous avons initialement utilis les annes 2008 2010. Cependant, 2008 est lanne de la crise conomique. Elle a compltement viol lintgrit de nos indices de performance. Donc nous lavons enleve. Puis, nous avons eu un autre chantillon dsagrable : le dbut de 2009. En effet, cette priode fut la reprise conomique. Elle biaisait gravement nos rsultats vers le haut. Il est noter que pour notre banc dessai original, nous utilisions un seuil dessai arbitraire. La slection de ce dernier est t le rsultat dune observation des diffrentes valeurs ressorties par un rseau de neurones choisi au hasard. Puis, nous avons encore observ un problme majeur : 60% de nos donnes ntaient pas utiliss, puisque le seuil dactivation choisi nadmettait pas de transactions valides. Considrant que les seuils dactivations ncessaires pour ressortir seulement les meilleures transactions, tout en aillant un chantillon de transaction de taille intressante, semblaient varier dun rseau lautre, nous avons implment un systme de gestion de seuil dactivation dynamique. Son comportement est relativement simple. En faisant passer son test de performance aux titres, il sassure que chaque titre a un minimum de transactions effectues dans la priode donne. Ce dernier a t arbitrairement fix deux. Puis, tant donn que lon sait que parfois, un titre peut simplement ne jamais avoir de moment dachat idal, nous allouons un nombre dexceptions, arbitraire encore une fois, trois. De cette manire, chaque fois que le rseau de neurones ralise que ces derniers critres ne sont pas respects, il diminue son seuil dactivation minimal.
40 | P a g e
5.5
Mthodes et outils
Le client a t ralis entirement en C# dans le Framework .NET 4.0. Ce
choix a dcoul de la dcision prcdente de prendre WPF comme technologie de graphisme. Tel quil a t mentionn plus tt, nous avons implment le patron de conception MVVM dans la couche de prsentation. cela sajoute le patron de la Fabrique
(50),
utilis pour fournir les classes qui servent raliser les oprations
dans la couche logique.

Le serveur a t dvelopp en Java, car nous souhaitions exploiter les forces de lquipe dans ce langage. Le serveur sest rvl tre une bonne position pour Java, car les interfaces de ce langage sont beaucoup moins toffes et facilement mallables. Lutilisation que nous avons faite de Java est trs rpandue et il est facile de trouver des exemples lorsque nous avions des problmes. De plus, tout le cycle de vie des Services, DAO, etc. est pris en charge par Spring. Cest en quelque sorte la colle qui tient chacun des morceaux de la partie serveur ensemble. Cest Spring qui soccupe dinstancier les diffrentes parties du serveur et dinjecter les bonnes rfrences lorsque requises. Pour faire le lien entre la base de donnes et le modle objet, nous avons utilis Hibernate. Cest un ORM (Object Relational Mapping) trs complet. Comme plusieurs membres de lquipe taient dj familiers avec sa configuration, ce fut un choix logique. Pour ce qui est des services Web, nous avons choisi dutiliser des services Web RESTful puisque ces derniers sont simples implanter et trs lgers, contrairement aux services SOAP. Il nest pas ncessaire davoir des outils spcialiss pour dvelopper un service RESTful. Par contre, il faut bien documenter chaque service, car loppos des services SOAP, les services REST ne fournissent pas de fichier WSDL (Web Service Definition Language) qui dcrit toutes les requtes/rponses quun service fournit. Nous avons utilis la librairie Jersey qui est une implmentation Java des services web RESTful. Pour rduire au maximum la
41 | P a g e
Rapport de fin de projet Dcembre 2010 trace de nos services, nous avons choisi dutiliser la reprsentation JSON pour toutes les requtes/rponses de nos services. JSON est un mode de reprsentation qui nous vient de JavaScript, il est beaucoup plus lger que XML.

Nous avons choisi dutiliser Python 2.6 pour exploiter les forces du langage. Premirement pour sa grande flexibilit et ensuite pour la grande quantit de librairies fournit par le langage. Dailleurs, le choix de Python 2.6 ft pour lutilisation dune bibliothque qui tait seulement disponible dans cette version. Au niveau des bibliothques utilises, Nous avons pris APScheduler
(19)
pour faire une planification de tche, ce qui est utile pour le joueur artificiel qui doit jouer tous les jours. Ainsi, une mthode de jeu est appele par le scheduler une fois par jour. Ensuite, la libraire Django devait initialement tre utilise pour fournir des services Web, mais lorsque le cerveau sest transform en joueur artificiel, lutilisation de Django cest aussi transform, tant donn que nous navions plus le mandat de fournir des services Web. Ainsi, Django fut utilis plutt un peu comme Hibernate pour Java, soit comme service de persistance dobjets Python. De plus, nous avons utilis HTTPLib2 (24) pour les requtes Web. Ainsi, toutes les communications entre le serveur et le joueur artificiel seffectuent laide de cette bibliothque. Finalement, nous avons eu besoin dutiliser PyBrain
(20)
pour le rseau de
neurones. Toutefois, cette librairie utilise plusieurs autres librairies pour son bon fonctionnement et ainsi, nous avons aussi utilis les bibliothques Numpy & Scipy
(22)
et SetupTools
(18) .
Cette dernire a aussi une autre utilit dans notre systme,
soit le dploiement du joueur artificiel. En effet, SetupTools fournit un outil appel easy_install qui permet dinstaller des bibliothques supplmentaires linstallation de Python trs facilement.
42 | P a g e
5.6
Dploiement
Afin de nous assurer de pouvoir dployer rapidement notre application et de
maintenir facilement nos versions, nous avons utilis la technologie ClickOnce de Microsoft. laide de cet outil, ds que nous faisons un changement sur notre code source, nous navons qu publier une nouvelle version sur le serveur. Pour que les modifications soient refltes aux utilisateurs, une vrification est faite chaque lancement de lapplication dans le but de savoir si la version prsentement utilise est la dernire disponible. Advenant le cas que non, la nouvelle version est automatiquement installe suite au consentement de lutilisateur. Du ct du serveur, il suffit de publier la mise jour des services Web pour que les changements soient immdiatement mis en ligne. Pour le joueur artificiel, il faut redployer les fichiers sur le serveur et redmarrer le service qui sen sert. Ces explications sont trs sommaires. Pour la procdure complte, veuillezvous rfrer au plan de dploiement (49).
5.7
Amliorations techniques
Du ct du client, quelques aspects de la programmation pourraient tre
amliors. Tout dabord, beaucoup dinformations sont transfres entre le client et le serveur. Lors de certaines mises jour, on retransmet la totalit des donnes alors que les changements uniquement pourraient tre transmis. Toujours en parlant des mises jour, notre contrle qui rafraichit les donnes dans les onglets est trs simple. Il serait profitable de lamliorer en ajoutant des paramtres supplmentaires pour optimiser lefficacit de ces mises jour. Finalement, pour amliorer lexprience de jeu de lutilisateur, il faudrait minimiser limpact quont les rafrachissements de donnes sur linterface graphique. Prsentement, nous pouvons constater un court ralentissement lors de certaines mises jour, et nous voudrions amliorer cet aspect.
43 | P a g e

Bien que nous nous sommes efforcs de dvelopper la solution la mieux structure possible, nous avons not quelques lments qui mriteraient dtre amliors dans la partie serveur. Premirement, la gestion du module des Jobs, les tches sexcutant automatiquement, serait retravailler. Prsentement, les tches sexcutent du lundi au vendredi sans savoir si la bourse est ouverte ou non. Un des correctifs possibles serait de programmer les tches pour quelles dmarrent au besoin uniquement. De plus, pour permettre un meilleur dcoupage des diffrentes parties, le projet Eclipse devrait tre dcoup en trois projets. Ceci nous permettrait de travailler sur chacune des parties sans devoir ncessairement arrter tout le systme. En ce moment, chaque fois que lon souhaite apporter une modification aux tches planifies ou aux services web, il faut compltement arrter tout le systme, ce qui peut causer des problmes dans un systme en production.

Il est bien certain quune science abstraite comme lintelligence artificielle laisse toujours place multiples amliorations afin davoir des augmentations de performances. Par exemple, ajouter de la diversit aux algorithmes danalyse techniques en entre ne peut quamliorer la prcision des rsultats. Une autre amlioration serait dinvestir du temps sur une fonction de rcompense plus efficace pour lentranement du rseau de neurones. Toujours au niveau des rseaux de neurones, une dfaillance note est, que les cots de transactions ne sont pas pris en compte. Donc, il pourrait tre intressant de les modliser, peut-tre par une entre fixe de neurones, ou bien de diminuer consquemment la rcompense lors des transactions. Pour ce qui est du joueur en soi, il reste encore plusieurs amliorations possibles. Pour linstant, la dispersion des actifs se fait de manire extrmement simple, soit un pourcentage dallocation par action, o chaque titre achet aura le mme volume. Il faudrait allouer un budget proportionnel lactivation.
44 | P a g e
5.8
Assurance qualit
Pour nous assurer une application des plus robustes, nous avons procd
une panoplie de tests. un niveau plus bas, chacun des modules comporte son lot de tests unitaires. Nous nous assurions ainsi davoir nos cas de base fonctionnels. Par la suite, des revues de code par dautres dveloppeurs faisaient en sorte de garder un standard et une constance dans la programmation. Grce cela, on vitait certaines erreurs dinattention. Au niveau des tests concrets dans lapplication, nous nous sommes construits un document qui reprenait chaque fonctionnalit sous forme de sries de tests effectuer. Ainsi, vers la fin du projet, nous avons repris cette liste dactions poser et avons valid les rsultats attendus. Cette approche nous a permis de trouver quelques failles dans notre systme et de les corriger rapidement. Dans le but dassurer un bon niveau de qualit sur le serveur, diffrents tests ont t faits. Premirement, tous les services Web sont tests par des tests dintgrations. Ces tests ont pour objectif de vrifier le bon fonctionnement du service et de sassurer que les bons codes de retour sont envoys selon tous les scnarios possibles. Deuximement, toutes les mthodes qui se retrouvent sur le serveur ont t testes manuellement, cest--dire que nous avons pris soin de bien vrifier que les rsultats obtenus taient bien ceux escompts avant de soumettre notre code. Pour ce faire, nous avons pu nous fier au document du plan de validation et vrification (51), conu au dbut du projet, qui regroupe tous les cas de tests selon les exigences initiales. Pour le joueur artificiel, nos tests ont chang au courant du projet, principalement parce que ce module est pass dun cerveau un joueur artificiel. Tel que le plan de validation le mentionne, nous avons valid toutes les fonctions de notre systme. Nos tests doivent toutefois tre faits manuellement. Chaque paquet contient un fichier tests.py qui contient tous les tests de ce paquet. Les tests que nous avons effectus sont les suivants : 46
Srialiser un objet en JSON
47
Dsrialiser un objet en JSON
45 | P a g e
Rapport de fin de projet Dcembre 2010 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64

o o o o o o o o o o o o o Services Web Obtenir les valeurs dun titre
65 66 68 69
Faire un banc dessai sur un rseau de neurones Analyse technique dun titre
Obtenir les informations dun titre 67 Authentifier un utilisateur Obtenir tous les titres courants o o o o o o
Calcul de MMA Calcul de RSI Calcul de DMI Calcul de EMV Calcul de CMF Calcul de Stochastique Utilisateur
Ajouter un symbole au portefeuille 70 Obtenir le portefeuille de lutilisateur 71 Obtenir des VaRs Obtenir une simulation Obtenir des transactions Effectuer des transactions Rseau de neurones Sauvegarder les paramtres
72 73 74 75 76
du 77
o o o
Trouver les meilleurs titres acheter Trouver les meilleurs titres vendre Grer les risques des transactions effectuer
rseau de neurones entrain
78
o
Charger les paramtres dun rseau 79 de neurones entrain Entrainer un rseau de neurones
Faire une itration complte du droulement du jeu
80
Finalement, dans la dernire semaine de travail, nous nous sommes livrs un exercice de simulation relle de lapplication. Nous avons cr une nouvelle partie o chaque membre des Fantastic 6 a pu tenter sa chance dans le rle de gestionnaire de portefeuille. Cette pratique a permis de confirmer le droulement complet de lapplication, du dbut la fin. Il sagit du mme processus qui sera appliqu lors de lutilisation relle de Stock Overflow, dans le cadre dun cours, par exemple.
5.9
Documentation
Un aspect important dans un projet dune telle envergure est la
documentation. De plus, nous savions quil sagit dun projet susceptible dtre repris par dautres tudiants ou de faire source dtudes pour comprendre le
fonctionnement derrire Stock Overflow.
46 | P a g e
Rapport de fin de projet Dcembre 2010 Cest pourquoi nous avons mis en place des processus pour nous assurer davoir un bon contrle sur la documentation du projet. Premirement, dans le module du client, toutes proprits et mthodes publiques ont t commentes de faon gnrer un site Web semblable la bibliothque de rfrences de Microsoft (MSDN). En effet, laide de loutil SandCastle excellent guide pour les futurs dveloppeurs. En ce qui concerne le serveur, qui est programm avec le langage Java, nous nous servons de la Javadoc
(53) (52) ,
il est simple de gnrer un
pour exporter lensemble des commentaires sur les
proprits et les mthodes. Cela constitue aussi une trs bonne rfrence pour toute personne qui puisse intervenir sur le serveur. Dans le mme ordre dide, nous avons conserv le diagramme de classes du modle jour tout au long du projet. Pour les services Web, nous avons cr des documents pour y conserver toutes les informations ncessaires leurs utilisations. Ces documents contiennent la description gnrale du service ainsi quune description plus prcise de chaque mthode disponible, soit les paramtres dentre, les paramtres de sortie et ladresse URL correspondante. Enfin pour le joueur artificiel, conu en Python, il nexiste pas de moyen pour le moment dexporter directement, sous une structure facilement lisible, lensemble des commentaires dans le code. Nanmoins, les proprits et les mthodes ont toutes t documentes de faon faciliter la tche aux dveloppeurs.
47 | P a g e
6
6.1
RSULTATS DE LEXPRIENCE
Client
Quelques hypothses avaient t leves en dbut de projet, dont une
concernait directement le module du client. Il sagit de produire un outil pdagogique sur la simulation de gestion de portefeuille . Aprs avoir termin compltement ce que nous voulions faire pour Stock Overflow, nous croyons pouvoir dire mission accomplie. En effet, nous avons russi btir une application solide, efficace, facile dutilisation et surtout qui remplit parfaitement le mandat qui nous avait t confi pralablement. Dautant plus quil sagissait dun dfi technologique, car construire un client dune telle ampleur et surtout, de rendre agrable lutilisation tait un objectif ardu. Certes, bien que nous ayons dj t impliqus de prs ou de proche sur une application qui utilisait ces procds de conception, nous devions maintenant tre responsables de mener terme un projet qui nest parti de rien. Cet aspect est souvent nglig dans le cadre des projets universitaires, car souvent une simple preuve de concept, o une courte partie dune application peut tre faite et connatre beaucoup de succs. Cependant, ce que nous avons russi faire, cest de prendre une simple ide thorique et de lamener un produit fini et utilisable.
6.2
Serveur
Lhypothse initiale du projet, par rapport la partie serveur, tait de russir
dvelopper des services Web rpondant aux besoins du client pour la gestion de portefeuilles, en utilisant des donnes de la Bourse. tant donn que nous tions dans un contexte dapprentissage luniversit, nous voulions aussi pouvoir se servir de ces donnes gratuitement. Maintenant que nous sommes la fin du projet, nous pouvons comparer le rsultat final avec lhypothse de dpart. Prsentement, nous utilisons des services
48 | P a g e
Rapport de fin de projet Dcembre 2010 Web de Yahoo pour rcuprer les donnes de la Bourse. Grce ces services, nous sommes en mesure de rcuprer, avec un dcalage de quinze minutes seulement, les donnes tout au long de la journe des titres du NASDAQ 100, du STX 60 ainsi que du Dow Jones. De plus, nous pouvons aller chercher les valeurs quotidiennes de tous ces titres plusieurs annes en arrire, ce qui est trs utile pour certains calculs, notamment la Valeur Risque (VaR). Nous pouvons par consquent rpondre aux besoins de la partie quant aux ncessits davoir accs de vraies donnes de la Bourse. Donc, avec ces rsultats concluants, nous pouvons affirmer que nous avons rempli les attentes dfinies avec notre hypothse.
6.3
Joueur artificiel
Nous sommes en gnral trs satisfaits de notre travail. Nous avons
plusieurs chiffres trs intressants prouvant lefficacit autant de lentranement des rseaux de neurones que de leur calibration. Pour ce qui est des rseaux de neurones, nous en avons entran 100, soient un pour chaque titre du NASDAQ 100. Aprs lentranement, nous les avons tous soumis un banc dessai. Ce dernier prend, pour chaque titre, lactivation de juin 2009 octobre 2010 du rseau de neurones et fait un achat et une vente en alternance aussitt que le seuil dactivation est atteint. Les dtails sur le seuil dactivation se retrouvent dans la partie calibration de la section rseau de neurones. Les rsultats de ces tests sont clairs : aucun de nos rseaux de neurones na de profit de transaction moyen ngatif. En effet, les 100 rseaux de neurones tests sur les 100 titres ont tous un profit de transaction moyen se trouvant entre 1.15% et 14.44%. Bien entendu, nous avons aussi soumis le joueur artificiel lui-mme au test. En effet, nous avons soumis le joueur dans son ensemble dans le contexte de 2005. Nous lavons fait dbuter le 1er janvier 2005 et termin le 31 dcembre 2005. la fin de lanne, il est pass dun portefeuille de 10 000$ un portefeuille de 11 334$, pour une augmentation de 13.3%. Nous pouvons donc affirmer que nous avons russi produire une intelligence artificielle assez intressante.
49 | P a g e
GUIDE DE DVELOPPEMENT
Ce guide se veut un outil daide pour toute personne souhaitant modifier le
code source de lapplication. Un langage plus technique devra tre utilis pour bien expliquer le fonctionnement et lorganisation de la programmation.
7.1
Module du client
Lenvironnement de dveloppement recommand est Visual Studio 2010.
Pour dbuter la modification du programme, ouvrez la solution (.sln) qui se trouve dans les sources du client. Vous aurez alors accs lensemble des projets inclus dans la solution.
7.1.1 Couche logique

La couche logique de Stock Overflow est le projet se nommant StockOverflow.Client.Logic. Comme il a t mentionn dans le prsent rapport, cette couche sert communiquer avec le serveur via des services Web. Voici une explication plus approfondies des diffrentes sections quon retrouve la Figure 9.
Figure 9 Sparation prcise de la couche logique
1. Contracts : Interfaces contenant toutes les fonctionnalits 2. Extensions : Classes pour nous aider programmer plus rapidement 3. Helpers : Ensemble de classes statiques pour aider faire des oprations communes 4. Managers : Classes qui ralisent
concrtement les oprations des interfaces (Contracts) 5. WebServices : services Web Managers relis aux
50 | P a g e
Rapport de fin de projet Dcembre 2010 6. Models : Objets utiliss pour transporter de linformation 7. Args : Paramtres pour chaque mthode 8. Entities : Objets du domaine daffaires. 9. Requests : Objets relis aux requtes faites au serveur 10. Responses : Objets retourns par le serveur lors de requtes 11. ManagerFactory : Unique point dentre pour accder la couche logique Vous trouverez dans chacune des classes des indications sur le fonctionnement de celles-ci. Pour bien faire comprendre la relation entre chacune des parties, voyons le scnario dans lequel nous voudrions ajouter la gestion des favoris. tapes pour ajouter la gestion des favoris* 1. Ajoutez une nouvelle interface nomme IFavoriteContract dans le rpertoire Contracts. 2. Assurez-vous de faire hriter votre interface de la classe IBaseContract et de la mettre publique. 3. Ajouter les mthodes que vous dsirez, par exemple GetFavorites ou AddFavorites. 4. Vous devez alors crer les classes ncessaires pour complter la signature de la mthode. a. LArgs contenant les paramtres de la fonction. b. La Response pour avoir le retour de la requte. 5. Validez que tout compile. 6. Dans la section Managers -> WebServices, crer une nouvelle classe pour le FavoriteManager. 7. Faites hriter la classe du BaseWebServiceManager, ainsi que du contrat dfini plus haut, IFavoriteContract. 8. Implmenter chaque mthode de linterface pour faire lappel au bon service Web. 9. Dans le ManagerFactory, ajoutez une proprit permettant la fabrique de retourner une instance de Manager pour les favoris.
51 | P a g e

* : Veuillez noter que nous avions prvu faire la fonctionnalit des favoris, ce qui explique que certaines classes peuvent toujours exister.
7.1.2 Couche de prsentation

La couche de prsentation est le projet nomm StockOverflow.Client.UI. Cest dans cette partie de la solution que tous les contrles graphiques relatifs lapplication se trouvent. Voici une explication plus dtaille de chacune des divisions comme on le voit la Figure 10.
Figure 10 Sparation prcise de la couche de prsentation
1. AttachedProperties : Ce sont des proprits supplmentaires contrles. 2. Configs : Fichiers de configuration utiliser selon le contexte. 3. Controllers : Ensemble des contrleurs pour lapplication. Ce sont eux qui font le lien entre les diffrentes fentres. 4. Controls : Regroupement des contrles que lon veut ajouter sur des
supplmentaires que nous avons ajouts. 5. Converters : Utilitaires pour transformer
laffichage des objets lcran. 6. Events : vnements supplmentaires
ncessaires au fonctionnement de lapplication. 7. Helpers : Ensemble de classes statiques
relatives linterface graphique pour aider faire des oprations communes. 8. Images : Images utilises. 9. Input : Classes pour passer les commandes provenant de linterface graphique vers la logique.
52 | P a g e
Rapport de fin de projet Dcembre 2010 10. Refreshers : Ensemble de classes servant faire la mise jour des diffrentes sections. 11. Resources : Fichiers contenant toutes les ressources localisables, cest--dire qui sont adaptes selon culture (par exemple, fr-CA ou en-US) de lutilisateur. 12. Sounds : Sons utilises. 13. Themes : Styles appliqus certains contrles. 14. Types : Valeurs que peuvent prendre certains types. 15. ViewModels : Cest le lien entre les entits du domaine daffaires et linterface graphique. Le ViewModel reprend les proprits de lentit afin de mieux interagir avec les contrles. 16. View : Il sagit de toutes les fentres de linterface homme-machine. Ces vues ne contiennent aucune logique outre celle relative linteraction avec lutilisateur. 17. Wrappers : Classes englobant des donnes pour faciliter laffichage. 18. MainWindow.xaml : Fentre principale de lapplication. Reprenons le scnario tabli dans le point prcdent qui voquait lajout de de la gestion des favoris. tapes pour ajouter la gestion des favoris 1. Crez le FavoriteViewModel ncessaire dans le dossier ViewModels. 2. Faites hriter cette classe du BaseViewModel. 3. Exposez les proprits intressantes, par exemple la liste des favoris. Notez bien que selon les requis de WPF, vous devez vous assurez dappeler la mthode NotifyPropertyChanged dans le set de chaque proprit pour que la valeur soit mise jour automatiquement dans linterface. 4. Ajoutez les commandes disponibles pour lutilisateur, par exemple ajouter un favori . Cette commande doit tre de type ICommand. 5. Pour communiquer avec la couche logique, il suffit dajouter une rfrence (via les using dans le haut de la classe) vers le ManagerFactory qui pourra nous fournir une instance du IFavoriteContract. Il ne reste qu faire lappel simplement en passant les bons paramtres (avec un objet AddFavoriteArgs par exemple).
53 | P a g e
Rapport de fin de projet Dcembre 2010 6. Une fois ces tapes compltes, il faut crer la vue, soit la FavoriteView dans le dossier Views. 7. Il faut maintenant remplir votre vue des diffrents contrles souhaites selon les besoins. 8. Pour tablir le lien entre la FavoriteView et le FavoriteViewModel, il faut avoir recourt lApplicationController. Dans cette classe, une mthode nomme CreateDefaultTabs sert ajouter un nouvel onglet. Cest cet endroit que nous allons instancier notre vue et lui assigner son contexte, soit le FavoriteViewModel. 9. ce moment, si vous lancez lapplication, vous devriez tre en mesure de voir votre onglet. Fonctionnement des Refreshers Le client et le serveur ne sont pas en constante communication, le serveur ne fait que rpondre des demandes du client. Il est donc impossible pour le client d'tre inform lors d'une modification. Pour rpondre ce problme, le client devait tre en mesure de demander des mises jour un intervalle rgulier (valeur des titres en temps rel) et des moments prdtermins (mise jour des titres dun portefeuille). Pour pallier ce problme, lquipe de Stock Overflow a mis sur pied un systme de rafraichissement dynamique se nommant Refresher. Chaque onglet de la vue principale ncessitant des actualisations est associ un Refresher, qui lui permet de demander des mises jour au serveur de faon asynchrone. Ds que possible, linterface graphique de la vue en question affiche les toutes nouvelles donnes, permettant ainsi aux utilisateurs dtre toujours au fait des derniers changements sans avoir poser une action. Cette infrastructure pourrait tre dveloppe davantage pour par la suite devenir une solution possible des problmes semblables. Procdure pour ajouter un Refresher Pralable : La View et le ViewModel de vue sont crs. 1. Crer la classe du Refresher, il doit hriter de BaseRefresher.
54 | P a g e
Rapport de fin de projet Dcembre 2010 2. Le ViewModel doit hriter de BaseViewModel et IUpdatable<T> o T est le type du nouveau Refresher. 3. Dans la classe du Refresher, la mthode Refresh permet de faire un appel asynchrone pour recevoir les nouvelles donnes (faire le plus de traitement possible dans cette mthode). 4. La premire ligne de la mthode est gnralement base.Refresh(). 5. Les donnes voulant tre conserves doivent tre gardes comme membre de la classe. 6. La mthode doit mettre jour linterface avec cette ligne : Dispatcher.Invoke(new Action() =>{UpdateLayout();})); 7. Dans le ViewModel, la mthode Update et le Refresher permettent de mettre jour linterface avec les donnes reues.
Autres informations importantes Tous les objets qui ncessitent dtre partags entre les diffrents contrles se trouvent dans lApplicationController. Afin de minimiser limpact des rafrachissements de donnes, nous utilisons plusieurs threads pour complter ces oprations.
7.2
Module du serveur
Le dveloppement de la partie serveur se fait laide dEclispe. Pour plus de facilit, nous conseillons dinstaller un serveur GlassFish et une base de donne MySQL sur le poste de dveloppement. Pour linstallation et la configuration, il suffit de suivre les tapes du plan de dploiement (49). Ensuite, voici les tapes pour configurer GlassFish dans Eclipse : Dans la vue Serveurs , faites un clic de droit et slectionner Nouveau Serveur . Slectionnez GlassFish Server Open Source Edition 3 puis cliquez sur Suivant . Slectionnez le dossier dinstallation de GlassFish et y inscrire les informations de connexions requises. Appuyez sur Terminer .
55 | P a g e
Rapport de fin de projet Dcembre 2010 Faites un clic de droit sur le serveur GlassFish apparu dans la vue Serveurs . En slectionnant Ajout & Suppression , ajouter le projet StockOverflow. Cette configuration met en place lenvironnement de dveloppement pour le serveur et permet de modifier et de tester le code localement. De plus, en dmarrant le serveur GlassFish en mode debug, on peut utiliser les points darrts.
7.3
Module du joueur artificiel

Le dveloppement du cerveau a t entirement effectu sous
lenvironnement Eclipse, laide du module d'extension pydev. Pour tout dveloppeur voulant continuer le dveloppement, il lui est fortement suggrer daller suivre les tutoriaux de bases sur lenvironnement Django. De plus, afin dexcuter lapplication, il sera ncessaire davoir install toutes les bibliothques dcrites dans le plan de dploiement (49). Un autre point souligner est que si un dveloppeur dcide de tenter une nouvelle phase dentrainement des rseaux de neurones, il faut quil ait beaucoup de temps sa disposition. En effet, lentrainement et la calibration de nos 100 rseaux de neurones ont pris en somme un peu plus dune semaine avec un ordinateur temps plein.
56 | P a g e
GUIDE DUTILISATION
Ce guide dutilisation se veut une rfrence pour toutes les personnes
susceptibles dutiliser lapplication Stock Overflow . Il a t construit sur les bases de la premire version du logiciel. Pour toute information supplmentaire, il faudra sadresser au responsable de votre simulation.
8.1
Installation et mise jour

La premire tape consiste installer lapplication sur votre ordinateur. Un
lien avec ladresse permettant de tlcharger lapplication vous sera remis. Une fois sur la page de tlchargement, cliquer sur le bouton Install, comme il est indiqu par une flche rouge sur la Figure 11 Page dinstallation. Notez quil se peut que vous ayez besoin du navigateur Internet Explorer afin de pouvoir tlcharger lapplication. Pour complter linstallation, suivez les indications lcran. Les prrequis pour faire fonctionner lapplication seront aussi installs si ncessaire.
Figure 11 Page dinstallation
Voici les spcifications minimales pour pouvoir utiliser lapplication : Systme dexploitation Windows XP, Windows Vista ou Windows 7 Processeur de 1,6Ghz Mmoire vive de 2go
57 | P a g e
Rapport de fin de projet Dcembre 2010 Espace disque disponible de 500mo
Notez que ces spcifications ont t tablies selon les tests pralablement effectus sur diffrents ordinateurs.
En ce qui concerne les mises jour, lapplication se chargera elle-mme de vous avertir lorsque quil y en a des nouvelles. Vous naurez qu les accepter et elles sinstalleront par elles-mmes.
8.2
Accs Stock Overflow

Pour accder lapplication une premire fois, il est impratif de vous crer
un nouveau compte. Pour se faire, voici les tapes suivre. 1. Ouvrir lapplication. 2. Cliquer sur le bouton Crer un nouveau compte . 3. Remplir tous les champs prsents la Figure 12. 4. Cliquer sur Crer compte .
Figure 12 Fentre denregistrement
Une fois enregistr, vous pouvez vous authentifier afin daccder lapplication. Cependant, pour pouvoir agir concrtement, un administrateur devra vous inclure dans une simulation. Vous aurez alors accs la totalit des fonctionnalits de Stock Overflow et serez ainsi en mesure de participer au jeu.
58 | P a g e
Rapport de fin de projet Dcembre 2010 Une fois que votre simulation sera termine et que vous tomberez dans une priode dattente avant de recommencer, si vous tentez daccder lapplication, vous naurez accs qu lhistorique de vos simulations prcdentes. Notez quil est normal que le logiciel prenne du temps ouvrir en raison de la quantit importante dinformation qui doit tre obtenue et analyse.
8.3
Le tableau de bord
la Figure 13, vous retrouvez le tableau de bord, la premire fentre que
vous voyez votre entre dans le jeu.

Figure 13 Tableau de bord
Il sagit dune prsentation globale de ltat de la simulation active. On y retrouve une panoplie dinformations sur le joueur connect, sur la composition de son portefeuille et sur le classement en cours.
59 | P a g e
Rapport de fin de projet Dcembre 2010 Identification du niveau Dans lentte du tableau de bord, on retrouve une photo en noir et blanc prsentant une image de la ville associe au niveau actuel. Cettedite ville est aussi marque clairement dans le haut gauche, ainsi que son numro de niveau. Lheure actuelle locale apparait aussi, toujours dans lentte, dans le coin en bas gauche. Informations sur le joueur Sous la bote didentification du niveau se trouve un sommaire concernant les informations du joueur actuel. Par exemple, on y voit son salaire actuel, son salaire cumulatif, son bonus anticip et le total des bonus quil a pu recevoir. Un icne indique aussi larrive de nouveaux messages dans la bote de rception du joueur. Classement Le classement est la grille qui se trouve dans le centre de lcran. Vous pouvez en tout temps cliquer sur lentte des colonnes de la grille de classement pour classer selon le champ dsir. Certaines donnes sont mises jour seulement le soir, lorsque la Bourse est ferme. Donc, il est normal de ny voir des changements que le lendemain. Rpartition des titres La pointe de tarte droite de lcran reprsente la rpartition des titres du portefeuille actuel du joueur. Valeur du portefeuille Dans le coin infrieur droit de lcran, un graphique prsente lvolution de la valeur du portefeuille du joueur dans la priode actuelle.
60 | P a g e
8.4
La barre dfilante
Au bas de lcran, une barre dfile constamment, affichant les derniers
changements sur les titres du march boursier. Comme on peut le constater la Figure 14, les items de la barre offrent une panoplie dinformations rapidement accessibles pour le gestionnaire. En cliquant sur lune des petites botes, un nouvel onglet contenant le dtail pour ce titre est ouvert.
Figure 14 Item de la barre dfilante
8.5
La gestion de portefeuille
Il sagit probablement de longlet le plus important pour le gestionnaire de
portefeuille. Cest cet endroit que lon retrouve lensemble des titres dans le portefeuille, comme on peut le voir dans la Figure 15.
Figure 15 Gestion de portefeuille
61 | P a g e
Rapport de fin de projet Dcembre 2010 Tout dabord, dans la barre de gauche, on voit les donnes sur ltat actuel du portefeuille : encaisse, valeur et actif et total. Ensuite, on remarque la prsence du graphique de la composition du portefeuille. Prenez note quil sagit du mme diagramme que dans le tableau de bord. Dans le haut, droite du titre Gestion de portefeuille , deux statistiques importantes sont affiches, soit la valeur risque (VaR) et le rendement. Vous vous devez de porter une attention particulire ces donnes. Selon le niveau dans la simulation, des pnalits sont appliques si la limite de risque VaR est trop leve. En ce qui concerne le rendement, cest lindicatif de votre performance concrte, donc de ltat de votre gestion. Sous ces chiffres, on retrouve trois onglets comprenant des informations supplmentaires, comme on peut le voir la Figure 16.
Figure 16 Onglets de donnes dans la gestion de portefeuille
1. Onglet Portefeuille Cest laffichage de tous les titres prsentement dans le portefeuille. Les donnes par rapport la valeur actuelle et la fluctuation sont mises jour automatiquement. Vous pouvez effectuer des actions concrtes sur ces titres, comme acheter plus dactions, vendre un certain nombre dactions ou retirer le titre du portefeuille (uniquement si la quantit que vous possdez est nulle).
2. Onglet Transactions Deux grilles prsentent lensemble de vos transactions. Dans la premire, on observe celles qui sont en attente. tant donn que les vritables valeurs sont obtenues quinze minutes plus tard que la ralit, vos transactions sont en attente pour cette priode. De plus, si des transactions sont ralises pendant
62 | P a g e
Rapport de fin de projet Dcembre 2010 les heures de fermeture, elles ne sont acceptes que le matin du prochain jour ouvrable. Dans la grille du bas, il sagit de lhistorique de toutes les transactions qui ont t conclues depuis le dbut de la priode.
3. Onglet Rendement Cet onglet sert montrer le rendement dans la journe des titres du portefeuille. La taille de la bulle est relative la proportion du titre dans le portefeuille, ainsi quau rendement obtenu dans la journe.
8.6
La messagerie
La messagerie regroupe toutes les conversations quil y a eu au cours de la
simulation. Pour le moment, vous ne pouvez que recevoir des messages. Votre patron ou ladministrateur de la simulation vous fera parvenir, si ncessaire, des messages pour vous communiquer une nouvelle ou un avertissement. Un avertissement survient lorsque vous djouez une des rgles du jeu. Comme on peut le voir dans la Figure 17, la totalit des messages reus se trouve dans la liste de gauche. En slectionnant un item, son contenu sera affich dans la fentre de droite.
Figure 17 Onglet de messagerie
63 | P a g e
Rapport de fin de projet Dcembre 2010 Lorsque de nouveaux messages arrivent, une alerte vous lindique (Figure 18). Lapplication vous propose alors daccder la fentre de messagerie pour les consulter aussitt.
Figure 18 Alerte de nouveaux messages
Une autre faon de savoir que de nouveaux messages sont arrivs est de consulter lindicateur dans le tableau de bord (Figure 19).
Figure 19 Indicateur de nouveaux messages dans le tableau de bord
8.7
La recherche
Il y a deux types de recherche dans Stock Overflow . La recherche par symbole Il sagit dun mode de recherche rapide. Si vous connaissez dj le symbole du titre, vous pouvez linscrire dans la case pour accder directement la fiche dtaille. Vous pouvez profiter de ce type de recherche deux endroits, soit tout en haut de lapplication (Figure 20), soit dans longlet de recherche avance.
64 | P a g e

Figure 20 Recherche rapide par symbole
La recherche par nom de compagnie Dans longlet de recherche avance, vous pouvez raliser la recherche par nom de compagnie. Slectionnez le bouton option Recherche par nom de compagnie et indiquez la compagnie voulue dans la case Nom de la compagnie . Lancez ensuite la recherche en cliquant sur bouton
Recherche . Une grille vous prsente alors tous les rsultats obtenus (Figure 21). Pour obtenir plus de dtails sur le titre trouv, cliquez sur le bouton du mme nom dans la dernire colonne de la grille.
Figure 21 Recherche par nom de compagnie
65 | P a g e
8.8
Dtails dun titre

Les dtails complets dun titre sont regroups lintrieur dun mme onglet
(Figure 22).
Figure 22 Onglet de dtails dun titre
Sommaire Informations sommaires sur le titre (Figure 23).

Figure 23 Sommaire dun titre
Actions Lorsque vous ouvrez un titre pour obtenir plus dinformations sur ce dernier, vous obtenez aussi la possibilit de faire des actions concrtes.
66 | P a g e
Rapport de fin de projet Dcembre 2010 o o Actualiser : Rafrachit les donnes de longlet. Ajouter au portefeuille : Ajoute le titre votre portefeuille. Accessible uniquement si le titre ny est pas dj. o Transaction : Ouvre une fentre pour effectuer une transaction.
Nouvelles Ce sont les actualits relatives au titre en cours. En cliquant sur le titre de la nouvelle, une page Web souvre pour lire le contenu.
Onglet des graphiques Dans la section de droite de longlet se trouvent deux graphiques prsentant lvolution du titre. Celui du haut prsente la variation de la valeur du titre chaque jour. Les botes vertes indiquent une hausse de la valeur, alors que les rouges indiquent une baisse. En laissant votre souris au-dessus de ces botes, vous obtenez la valeur louverture, la fermeture, la plus haute obtenue, ainsi que la plus basse pour la journe. Si vous cliquez sur le graphique et glissez le curseur tout en maintenant enfonc le bouton gauche de la souris, cela agrandit la section pour mieux observer lvolution. Le graphique du bas dmontre le nombre dactions sur ce titre qui se sont changes au cours de la journe.
Onglets des donnes brutes Dans cette section, vous obtenez exactement les mmes donnes que sur les graphiques prcdents. Elles sont cependant prsentes sous forme de grille, ce qui vous permet de les classer en cliquant sur lentte des colonnes.
Filtre Une fonctionnalit intressante est de pouvoir filtrer les donnes laide du contrle situe au haut de longlet (Figure 24). Pour lutiliser, vous navez qu entrer la date de dbut, la date de fin et cliquez sur le bouton Appliquer .
67 | P a g e

Figure 24 Filtre de lhistorique
8.9
Historique de simulation
Figure 25 Historique de simulation
la fin de chaque simulation, il est possible de consulter un bref rapport de la performance du joueur. Pour ce faire, rendez-vous dans longlet Historique de simulation . Dans la liste de gauche, comme on le voit la Figure 25, toutes les simulations auxquelles vous avez particip et qui sont termines apparaissent. Cliquez sur une pour obtenir les dtails de celle-ci. Dans la partie de droite, vous retrouverez dans le haut le classement final. Dans le bas, vous y verrez le contenu de votre portefeuille lors de cette simulation.
8.10 Console dadministration

La console dadministration est disponible uniquement pour les administrateurs. Cest partir de cette section quils peuvent grer les simulations. De plus, pour contrler les participants une simulation, les utilisateurs doivent se crer un compte eux-mmes et cest ladministrateur qui les inclut dans une simulation. Cette situation est illustre la Figure 26.
68 | P a g e

Figure 26 Gestion des participants la simulation
En utilisant les flches, ladministrateur peut insrer et retirer les utilisateurs. Dans la bote de slection en haut gauche, on montre la simulation pour laquelle nous sommes en train de faire les changements. Pour crer une nouvelle simulation, il suffit de cliquer sur le bouton Crer une nouvelle simulation . Une fentre saffichera alors, vous demandant de remplir les diffrents champs obligatoires. Ltape 1 consiste assigner un nom la nouvelle simulation. Ltape 2 permet de dfinir les priodes lintrieur dune simulation. Ltape 3 sert crer lensemble des niveaux de la simulation. Comme on peut le voir la Figure 27, ladministrateur peut personnaliser chacun de ses niveaux avec beaucoup de flexibilit.
69 | P a g e

Figure 27 Fentre de cration de niveau
Voici une explication rapide des paramtres. Numro : Numro du niveau Ville : Endroit o se trouve le gestionnaire Salaire : Salaire annuel du gestionnaire Image : Lien vers une image de la ville en question qui sera affiche dans le tableau de bord Vente dcouvert : Est-ce que la vente dcouvert est permise ou non Type de VaR : Type de VaR utilis Premier quartile : Traitement rserv aux utilisateurs terminant dans le premier quartile Dernier quartile : Traitement rserv aux utilisateurs terminant dans le dernier quartile Rgles : Valeurs que lutilisateur doit respecter o Limite de Valeur Risque
70 | P a g e
Rapport de fin de projet Dcembre 2010 o o o o Nombre maximum de dpassement de la VaR Pourcentage maximum dun titre Cot des transactions Bonus
Lorsque vous avez complt le formulaire, il suffit de cliquer sur Terminer pour crer la nouvelle simulation.
8.11 Changement de priode

Un concept important connatre dans la simulation est que celle-ci est spare en plusieurs priodes. Ces priodes reprsentent une anne fictive dans le jeu. Leur nombre et leur dure dpendent de ladministrateur qui aura cr la simulation. Au dbut de chaque priode, vous recevrez un message vous informant quune nouvelle anne commence. De plus, vous recevrez les bonus associs votre rendement de la priode prcdente. la fin de chaque priode, les rglements de la limite de risque VaR sont vrifis. Cest galement ce moment que la performance est value. Les joueurs dans le premier quartile se mriteront une ascension au prochain niveau, tandis que ceux dans le dernier quartile devront retourner au niveau prcdent. Pour ce qui est du portefeuille, chaque dbut de priode vous recommencez avec le montant des actifs sous gestion dfinis votre niveau. Par contre, vous ne perdez pas vos titres dj dans votre portefeuille, le systme vous les redonne selon la mme proportion que lors de la dernire journe de la priode prcdente. Il est noter aussi que les donnes du classement et les messages sont affichs pour la priode en cours seulement.
71 | P a g e
CONCLUSION
Pour conclure ce rapport, il est ncessaire de faire un rcapitulatif des bons et
des mauvais coups que nous avons faits pendant la session. Tout dabord, nous avions mis des hypothses en dbut de projet. Voici un petit rappel. Nous sommes en mesure de produire un outil pdagogique sur la simulation de gestion de portefeuille. Un systme intelligent est en mesure de performer dans la gestion de portefeuille. Nous pouvons utiliser des donnes disponibles gratuitement pour arriver notre but. Il est maintenant le temps de vrifier ces propositions afin de savoir si nous sommes parvenus atteindre ces objectifs. Premirement, il est facile de constater que nous avons trs bien russi produire un outil pdagogique sur la simulation de gestion de portefeuille. Nous avons bti une application concrte, autonome et qui peut servir sans problme dans un cours. Cest probablement l notre plus grande russite en tant ququipe. Deuximement, nous voulions produire un systme intelligent qui serait en mesure de performer dans le contexte dune simulation de portefeuille. la lueur des rsultats obtenus, et dans nos tests intensifs, et dans la simulation fictive que nous avons faite, notre joueur artificiel fait des profits. Cest donc dire quen quinze semaines de travail, sans aucune exprience, nous en sommes venus comprendre assez le domaine financier pour avoir du succs. Il sagit encore une fois dune russite majeure pour nous tous. Troisimement, nous croyions quen utilisant uniquement des donnes provenant de sources gratuites, nous serions en mesure de construire un systme tout aussi efficace. Eh bien, force est dadmettre que nous avons une fois de plus su relever ce dfi. Dans les autres points positifs, la gestion de projet qui a t faite tout au long de la session a t impeccable. En effet, nous savions rapidement comment le projet
72 | P a g e
Rapport de fin de projet Dcembre 2010 progressait et lajustement, si ncessaire, sappliquait promptement. De plus, nous sommes dautant plus satisfaits de la faon dont nous avons profit de notre organisation du travail pour nous retourner rapidement lorsquest venu le temps de dcider si nous voulions adopter le projet des gens de la Facult dadministration. De la faon dont nous travaillions, ce changement a pu soprer facilement et sans perte de temps. Tout bon projet comprend aussi son lot de points ngatifs. ce niveau, il faut se considrer chanceux, car nous nous en sommes sortis avec une liste trs brve. Tout dabord, certaines runions dquipe ont parfois dvi du sujet principal alors que cela ntait pas ncessaire. Par exemple, deux individus discutaient de limpact dune dcision ou comment ils allaient procder pour raliser une tche. Cela a fait en sorte dtirer certaines rencontres et de faire perdre lattention des autres membres. Un autre point ngatif fut probablement le manque de communication sur leffort mettre lors de la semaine des examens. Nous avions convenu au dpart de faire quand mme les heures requises, malgr les examens intras. Cependant, lorsque la situation sest prsente, certaines personnes nont pas tenu leurs engagements pour prioriser leurs tudes, ce qui tait tout fait lgitime. Le
problme apparait lorsque dautres, qui ont nglig leurs tudes sous le prtexte de devoir travailler sur le projet, ont dnonc linjustice. Ce que nous aurions d faire ce moment est de rviser la rgle que nous nous tions impose pralablement. Cela aurait fait en sorte de mettre tout le monde sur la mme longueur donde. Nanmoins, ce ne sont que des problmes mineurs qui sont survenus et nous croyons que cet aspect a fait en sorte de nous aider grandement progresser.
9.1
Amliorations
Considrant que nous avons travaill dans une priode de temps restreinte, il
est clair que nous aurions pu amliorer lapplication et ajouter des fonctionnalits intressantes. En voici une courte liste : Ajouter la gestion des favoris Afficher plus de statistiques lutilisateur
73 | P a g e
Rapport de fin de projet Dcembre 2010 Offrir la possibilit de personnaliser davantage une simulation pour ladministration Obtenir les donnes en temps rels, toujours en gardant la gratuit dans cette acquisition. Ajouter des algorithmes danalyse technique pour amliorer notre joueur artificiel Permettre une allocation de portefeuille plus dynamique pour le joueur artificiel o Cela permettrait possiblement davoir un meilleur rendement, parce que les meilleurs titres pourraient tre achets en plus grande quantit.
9.2
Exprience acquise
Ce projet nous a permis de raliser toutes les tapes dun projet informatique
de faon autonome. Dans nos diffrentes expriences de travail, certains des membres des Fantastic 6 ont dj pris part toutes les tapes de dveloppement dun logiciel, mais ce projet fut le premier dans lequel nous avions prendre toutes les dcisions et implmenter la totalit de la solution. Ce fut donc une exprience qui nous sera assurment profitable dans nos futures carrires respectives. De plus, Stock Overflow nous a fait dcouvrir beaucoup de choses. Tout dabord, de nouveaux langages de programmation (Python), puisquaucun de nous navait une relle exprience avec ce langage. Nous avons donc grandement appris sur ce langage, ses points forts et son utilisation. Ensuite, nous avons grandement amlior nos connaissances avec les services Web. Par la suite, nous avons eu une bonne exprience avec la Bourse et son fonctionnement. Nous avons explor plusieurs domaines de la Bourse, les transactions, la gestion des risques, lallocation du portefeuille et bien sur le domaine auquel nous tions le plus intress, lanalyse technique. Finalement, nous avons acquis une grande exprience avec les rseaux de neurones et leurs utilisations.
74 | P a g e
Rapport de fin de projet Dcembre 2010 Bref, le bagage de connaissances que nous ressortons de lexprience est norme. Pour chacun dentre nous, il sagit dfinitivement dun point majeur dans nos jeunes carrires.
75 | P a g e
10
RFRENCES
10.1 Bibliographie
1. Coggins, Frank. Jeu de simulation de gestionnaires de portefeuille. Sherbrooke : Frank Coggins, 2010. 2. Fantastic 6. Mandat de prestation de service. Sherbrooke : Fantastic 6, 2010. 3. MacDonald, Matthew. Pro WPF in C# 2010. s.l. : Apress 2010, 2010. 4. Nathan, Adam. WPF 4 Unleashed. 1st. s.l. : Sams, 2010. p. 848. 5. VisiFire. VisiFire. VisiFire. [En ligne] VisiFire. [Citation : 01 10 2010.] http://www.visifire.com. 6. Toelsen, Andrew. Pro C# 2010 and the .NET 4 Plateform. s.l. : Apress 2010, 2010. 7. McConnell, Steve. Code Complete Second Edition. 2nd. 2004. 8. Microsoft. MSDN. MSDN. [En ligne] Microsoft, 2010. http://www.msdn.com. 9. Smith, Josh. WPF Apps With the MVVM Design Pattern. MSDN. [En ligne] Microsoft, 01 Fvrier 2009. http://msdn.microsoft.com/enus/magazine/dd419663.aspx. 10. JSon authors. Introducing JSON. JSon. [En ligne] 2010. http://www.json.org/. 11. Newton-King, James. Json.NET. James Newton-King : No pressure, no diamonds. [En ligne] 2010. http://james.newtonking.com/pages/json-net.aspx. 12. Wikipedia. Representational State Transfer. Wikipedia. [En ligne] 2010. http://en.wikipedia.org/wiki/Representational_State_Transfer.
76 | P a g e
Rapport de fin de projet Dcembre 2010 13. hulbert, Chris. Java & Struts2 & Spring & Hibernate & Eclipse Tutorial. Building a web app from scratch. Scridb. [En ligne] Avril 2010. [Citation : 20 Septembre 2010.] http://www.scribd.com/doc/25244173/Java-Struts-SpringHibernate-Tutorial. 14. Gavin King, Christian Bauer, Max Rydahl Andersen, Emmanuel Bernard & Steve Ebersole. Hivernate Reference Documentation. Hibernate Relational Persistence for Idiomatic Java. [En ligne] [Citation : 10 Novembre 2010.] http://docs.jboss.org/hibernate/core/3.3/reference/en/pdf/hibernate_reference.pdf. 15. Oracle Corporation. MySQL. MySQL. [En ligne] Oracle corporation, 2010. http://www.mysql.org/. 16. Sun Microsystems Inc. RESTfulWeb Services Developer's Guide. [En ligne] Avril 2009. [Citation : 2010 Septembre 2010.] http://dlc.sun.com/pdf/820-4867/8204867.pdf. 17. Aptana inc. PyDev. PyDev. [En ligne] Aptana inc., 2010. http://pydev.org/. 18. Python Software Foundation. Python Setup Tools. Python Development. [En ligne] Python Software Foundation, 2010. http://pypi.python.org/pypi/setuptools. 19. Grnholm, Alex. Advanced Python Scheduler. [En ligne] 2009. http://packages.python.org/APScheduler/. 20. CogBotLab & Idsia. Welcome to the PyBrain's documentation. PyBrain. [En ligne] CogBotLab & Idsia, 2009. http://pybrain.org/docs/index.html. 21. Norvig, Stuart Russet & Peter. Artificial Intelligence A Modern Approach. 3rd. s.l. : Prentice Hall, 2009. 22. Gommers, Ralf. ScyPy. ScyPy. [En ligne] 2010. http://www.scipy.org/SciPy. 23. Django Software Foundation. Django Documentation. Django. [En ligne] Django Software Foundation, 2010. http://docs.djangoproject.com/en/1.2/. 24. httplib2. httplib2. [En ligne] MIT, 2010. http://code.google.com/p/httplib2/.
77 | P a g e
Rapport de fin de projet Dcembre 2010 25. Python Software Foundation. 25.3. unittest Unit testing framework. The Python Standard Library. [En ligne] Python Software Foundation. http://docs.python.org/library/unittest.html. 26. ABC Bourse. Analyse technique - Leon 7 - Les R.S.I. ABC Bourse. [En ligne] ABC Bourse, 2010. http://www.abcbourse.com/apprendre/11_lecon7_1.html. 27. edu Bourse. RSI ou Relative Strengh Index. edu Bourse. [En ligne] edu Bourse, 09 10 2000. http://www.edubourse.com/guide-bourse/rsi.php. 28. Comprendre La Bourse. Indicateur : Oscillateurs simples. Comprendre La Bourse. [En ligne] Comprendre La Bourse, 2000. http://www.comprendrelabourse.com/Analyse/AnalyseTechnique/anaTech_oscillateu r.htm. 29. ABC Bourse. Analyse technique - Leon 8 - Le Mouvement Directionnel. ABC Bourse. [En ligne] 2010. http://www.abcbourse.com/apprendre/11_lecon8_1.html. 30. Trader Workstation. L'indicateur technique DMI. Trader Workstation. [En ligne] Trader Workstation, 2010. http://www.traderworkstation.com/daytrading/le_dmi.php. 31. MATAF Forex Trading. Le mouvement directionnel ou DMI. MATAF Forex Trading. [En ligne] MATAF Forex Trading, 2010. http://www.mataf.net/fr/analysetechnique/11-17-mouvement-directionnel-DMI. 32. Trading School. ADX, ADXR, DMI : Directional Movement. Trading School. [En ligne] Trading School, 2010. http://www.trading-school.eu/glossaire-bourse/ficheADX-ADXR-DMI-Directional-Movement-53. 33. edu Bourse. Adm's Ease Of Movement Value. edu Bourse. [En ligne] edu Bourse, 07 07 2005. http://www.edubourse.com/guide-bourse/arm-easemovement.php. 34. ABC Bourse. Analyse technique - Leon 2 - Les moyennes mobiles. ABC Bourse. [En ligne] ABC Bourse, 2010. http://www.abcbourse.com/apprendre/11_lecon2.html.
78 | P a g e
Rapport de fin de projet Dcembre 2010 35. edu Bourse. Stochastique, dtecteur de survente et surachat. edu Bourse. [En ligne] edu Bourse, 22 01 2001. http://www.edubourse.com/guidebourse/stochastique.php. 36. Fantastic 6. tude sur le domaine financier. Sherbrooke : Fantastic 6, 2010. 37. Lawrence, Ramon. Using Neural Networks to Forecast Stock Market Prices. University of Manitoba. [En ligne] 12 Dcembre 1997. https://people.ok.ubc.ca/rlawrenc/research/Papers/nn.pdf. 38. Duan Marek. Stock Price Forecasting: AutoRegressive Modelling and fuzzy neural network. [En ligne] http://www.eusflat.org/publications/proceedings/EUSFLATESTYLF_1999/papers/187-marcek.pdf. 39. Monica Isfan, Rui Menezes & Diana A. Mendes. Forecasting the portuguese stock market time series by using artificial neural networks. [En ligne] 2010. http://iopscience.iop.org/1742-6596/221/1/012017. 40. Birgul Egeli, Meltem Ozturan & Bertan Badur. Stock Market Prediction Using Artificial Neural Networks. [En ligne] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.134.1114&rep=rep1&type= pdf. 41. Stack Overflow. Stack Overflow. Stack Overflow. [En ligne] Stack Overflow, 2010. http://www.stackoverflow.com. 42. Fantastic 6. tudes sur les applications de gestion de portefeuille et de simulation. Sherbrooke : s.n., 2010. 43. . Contrat d'quipe. Sherbrooke : Fantastic 6, 2010. 44. Wikipdia. Mthode agile. Wikipdia. [En ligne] [Citation : 27 11 2010.] http://fr.wikipedia.org/wiki/Methode_agile.
79 | P a g e
Rapport de fin de projet Dcembre 2010 45. Murphy, Craig. Adaptive Project Management Using Scrum. Methods And Tools. [En ligne] 2 12 2004. [Citation : 27 11 2010.] http://www.methodsandtools.com/archive/archive.php?id=18. 46. Atlassian. JIRA. Atlassian. [En ligne] Atlassian. [Citation : 27 11 2010.] http://www.atlassian.com/software/jira/. 47. Fantastic 6. Plan de gestion de projet. Sherbrooke : Fantastic 6, 2010. 48. . Rapport de suivi - Itration #5 - Sprint 14. Sherbrooke : s.n., 2010. 49. . Plan de dploiement. Plan de dploiement. Sherbrooke : Universit de Sherbrooke, 2010. 50. Guy, Romain. Design patterns : le motif Factory. Developpez.com. [En ligne] 24 Septembre 2009. http://gfx.developpez.com/tutoriel/conception/pattern/fabrique/. 51. Fantastic 6. Plan de validation. Sherbrooke : Fantastic 6, 2010. 52. SandCastle's team. SandCastle - Documentation compiler for Managed Class Librairies. CodePlex. [En ligne] Microsoft, 2010. http://sandcastle.codeplex.com/. 53. Oracle. Javadoc Tool Home Page. Oracle Technology Network. [En ligne] Oracle, 2010. http://www.oracle.com/technetwork/java/javase/documentation/index-jsp135444.html.
80 | P a g e
10.2 Annexe A
Les termes sont mentionns en ordre dapparition dans le texte. TERME Stock Overflow DFINITION Nom de lapplication rsultante du projet. Clin dil la plateforme daide pour les dveloppeurs informatique Stack Overflow (http://www.stackoverflow.com). Fantastic 6 Nom dsignant les membres de lquipe comprenant ric Sylvestre, Yannick Charron, Genevive Lamarche,
Samuel Dionne, Alexandre Deschamps et Jean-Michel Nadeau. Parties prenantes Groupes ou individus qui sont impliqus dans le projet.
81 | P a g e

Rapport de Fin de Projet PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Rapport de Fin de Projet PDF

Caricato da

Copyright:

Formati disponibili

Rapport de fin de projet

Rapport de fin de projet Dcembre 2010

Table des matires

5.2.1 Module du client ......................................................................................... 26

Guide de dveloppement ....................................................................................... 50

Rapport de fin de projet Dcembre 2010 7.1 Module du client ............................................................................................ 50

Rapport de fin de projet Dcembre 2010

Table des figures

Rapport de fin de projet Dcembre 2010

Stock Overflow . Le contenu a t dcid dun commun accord entre le professeur

trouveront en fin de document.

Rapport de fin de projet Dcembre 2010

ncessite beaucoup de recherches.

pour mieux intgrer leurs contrles.

De plus, lapplication a t programme en C# dans version 4.0 du Framework

le site officiel des dveloppeurs de Microsoft, avec

Rapport de fin de projet Dcembre 2010 JavaScript Object Notation (JSon )

Dautres lectures ont t ncessaires pour

mieux encadrer le processus de communication, notamment la consultation de la bibliothque de srialisation JSon

et larticle expliquant larchitecture

Representational State Transfer (REST ) (12).

Module joueur artificiel

nous a permis den apprendre un peu plus sur les

ordonnanceurs en Python. Pour construire notre rseau de neurones, la documentation de PyBrain

nous a grandement facilit la tche. Il faut aussi

qui est intervenu un niveau plus thorique. Une autre

de Ramon Lawrence, Stock price forecasting:

un forum spcialis pour les

Rapport de fin de projet Dcembre 2010

Rapport de fin de projet Dcembre 2010

Changement dorientation du projet

Rapport de fin de projet Dcembre 2010

TEMPS ESTIM (en heures) 40 120 45 50 255

Rapport de fin de projet Dcembre 2010

Responsable du joueur artificiel et de la base de donnes. Adjoint au chef dquipe.

Rapport de fin de projet Dcembre 2010

Rapport de fin de projet Dcembre 2010

REVUE DES PROCESSUS DE GESTION

Rapport de fin de projet Dcembre 2010

4.4.1 Investissement sur les livrables

temps temps temps temps Retard (1 semaine)

temps temps temps temps temps

temps temps 365,74 heures

temps temps temps temps temps temps temps 399 heures

4.4.2 Efforts des membres de lquipe

Rapport de fin de projet Dcembre 2010

Sprint 14 Sprint 5 Sprint 6 Sprint 7 Sprint 8*

22,5 20,67 20 42,83 20 22,5 20,75 20,25 20,33 20,5 20 304,33

17,67 19,78 21 40,33 22,5 20,75 25,5 19,75 20 28,75 20 292,03

15 19,75 10,25 42 21,5 22,5 27 24,25 22,32 21,33 20 278,91

18 20 14 43,83 20 22,75 20,25 22,5 22,25 17,5 20 276,58

9 17,75 22,75 42,08 21 22,25 23 15,25 18 25,75 20 270,83

24,33 20,25 20,67 46 20 26 20,75 20 20,08 25,75 20 300,33

Sprint 9 Sprint 10 Sprint 11 Sprint 12 Sprint 13 Sprint 14 Sprint 15(**) Total

Le gain de cette pratique

Rapport de fin de projet Dcembre 2010

REVUE DES PROCESSUS TECHNIQUES

Les flches signifient utilise .

5.2.1 Module du client

StockOverflow.Client.UI SERVEUR utilise communique

Rapport de fin de projet Dcembre 2010

5.2.1 Module du serveur

Rapport de fin de projet Dcembre 2010