Rapport de Projet de

Fin dEtude
Conception et ralisation dune
application mobile (Android)

Session Juillet 2015

Ralis par :
Mlle EL AHMAR Fatima Zahra.
Encadrants Sofrecom :
M. MESSAOUDI Youssef Badreddin.
M. TIGMA Khalid.
Encadrant High Tech :
M. ACHA Nawfal.

Anne universitaire : 2014-2015

Rapport de Projet de
Fin dEtude
Conception et ralisation dune
application mobile (Android)

Session Juillet 2015

Ralis par :
Mlle EL AHMAR Fatima Zahra.
Encadrants Sofrecom :
M. MESSAOUDI Youssef Badreddin.
M. TIGMA Khalid.
Encadrant High Tech :
M. ACHA Naoufal.

Anne universitaire : 2014-2015

Ddicace
_________________________________________________

A mes chers parents, auxquels je dois

tout ce que je suis aujourdhui,
A mes chres surs et mon frre,
pour lamour et leur soutient continuel
A tous les tres qui me sont chers et
mes chers amis,
Je vous ddie ce travail pour
exprimer toute ma gratitude et mon
amour.
Fatima Zahra

Page | 4

Remerciements
_________________________________________________

Je tiens exprimer mes profonds remerciements toutes les personnes

qui ont contribu, de prs ou de loin, { llaboration de ce travail.

Jexprime ma gratitude { mes deux matres de stage M. Khalid TIGMA et

M. Youssef Badreddin MESSAOUDI pour leurs orientations et leurs conseils,
ainsi que Mlle Hanae EL MEKKI pour son assistance et ses explications durant
les premires phases du projet. De mme, je tiens remercier M. Mohammed
Amine TAZI pour ses conseils techniques.

A M. Nawfal ACHA, mon encadrant interne, jadresse un hommage

particulier pour sa disponibilit, ses remarques et ses suggestions.

Pour finir, je tiens remercier les membres du jury, pour avoir accept de
juger ce travail.

Page | 5

Rsum
_________________________________________________

Le document que vous avez entre les mains est une synthse de mon
projet de fin dtudes, effectu dans le cadre dun stage de quatre mois au sein
de la socit Sofrecom Service Maroc.

Le projet consiste crer un prototype mobile Android pour la gestion et

particulirement la recherche et la visualisation- des devices. Ma mission tait
de concevoir et crer cette application, en respectant au mieux les normes et
fonctionnement de ces fonctionnalits dans lapplication web.

Il fallait dans un premier temps que je me familiarise et que je comprenne

comment fonctionne Device-DB avant de pouvoir commencer le travail qui ma
t demand de faire. Ce rapport dtaille une une chaque tape suivi sur ses
trois diffrents chapitres :

Chapitre 1 Cadre du projet : Ce chapitre va prsenter le contexte

gnral du projet ainsi que lorganisme au sein duquel le projet sest
droul. La problmatique y sera dtaille et il se terminera par un cahier
des charges simplifi du projet.
Chapitre 2 Conduite du projet : Ce chapitre contient le planning
suivit pour la ralisation du projet, ainsi quune explication de la
mthodologie de dveloppement adopte. Finalement, il traiter de la
conception du projet.
Chapitre 3 Ralisation : Ce chapitre prsente quant lui des lments
lis la ralisation du prototype, comme la thorie suivie,
lenvironnement technologique adopt, les tests des services web et
finalement une explication des interfaces.

Page | 6

Abstract
_________________________________________________

The following document is the summary of my graduation project that

took place at Sofrecom Morocco for a period of four months.

The main purpose of the project is to conceive and develop a mobile

prototype to search and list the various devices existing in the Orange database.
My mission was to create this application, taking into consideration the existing
functionalities of the web application Device-DB.

First of all, I had to understand and familiarize with the existing web
application before I started working on the project. This document will go
through all the details of each of the development phase the project went
through, and it will contain the three following chapters:

Chapter 1 Framework of the Project: this chapter will give a general

presentation to the company, will mention the projects general context
and will explain the main challenges of the project.
Chapter 2 Project Management: this chapter will explain the schedule
that the project is supposed to follow, the agile methodology adopted to
make it, and the design of the project.
Chapter 3 Production: this final chapter will sum up all the elements
used to make the prototype, and will explain the web services test phase
as well as the graphic designing of the views of the application.

Page | 7

Liste des figures

_________________________________________________

Figure 1: Processus de production Sofrecom _______________________________ 17

Figure 2 : Implantation de Sofrecom _____________________________________ 18
Figure 3 : Organigramme 2013-2014 ______________________________________ 19
Figure 4 : Application native ou hybride ? (source : AppSolute) _______________ 21
Figure 5 : Cycle de vie RAD ____________________________________________ 27
Figure 6 : Cycle de vie en cascade _______________________________________ 28
Figure 7 : Cycle de vie RAD dtaill _____________________________________ 30
Figure 8 : Les tches __________________________________________________ 31
Figure 9 : Diagramme de GANTT________________________________________ 31
Figure 10 : Diagramme de packages ______________________________________33
Figure 11 : Diagramme de cas dutilisation Gestion des devices _____________ 34
Figure 12 : Diagramme de cas dutilisation Cration des devices ____________ 34
Figure 13 : Diagramme de squence Recherche ___________________________35
Figure 14 : Diagramme de squence Visualisation ________________________ 36
Figure 15 : Diagramme de classes _______________________________________ 37
Figure 16 : Schma logiciel global _______________________________________ 38
Figure 17 : Schma logiciel spcifique ____________________________________ 39
Figure 18 : Comment tablir la liaison ?___________________________________ 41
Figure 19 : Lien tablit via un web service ________________________________ 42
Figure 20 : Architecture 3-tiers, simplifie (Source : tutorielandroid.) _________ 44
Figure 21 : Architecture 3-tiers Mobile ___________________________________ 45
Figure 22 : Les web services REST_______________________________________ 50
Figure 23 : Web service Manufacturer ____________________________________ 51
Figure 24 : Web service Manufacturer, rsultat JSON _______________________52
Figure 25 : Web service Manufacturer, test JavaEE _________________________52
Figure 26 : IHM - Authentication ________________________________________53
Figure 26 : IHM - Search ______________________________________________ 54
Figure 27 : IHM Search Results _______________________________________ 55
Figure 28 : IHM Details _____________________________________________ 56
Figure 29 : Diagramme de GANTT rel __________________________________ 63

Page | 8

Liste des tableaux

_________________________________________________

Tableau 1 : Android Studio vs. Eclipse ___________________________________

Tableau 2 : REST vs. SOAP ____________________________________________
Tableau 3 : JSON vs. XML _____________________________________________
Tableau 4 : Les tches ________________________________________________

47
48
49
63

Page | 9

Liste des abrviations

_________________________________________________

ADT
ANRT
CPU
DB
HTML
HTTP
IDE
IHM
JavaEE
JDN
JSON
MSE
OS
PHP
R&D
RAD
RAM
REST
SDK
SGBDR
SGBDRO
SIG
SOAP
SSM
TMA
UP
URI
XML
XP

Android Development Tools

Agence Nationale de Rglementation
des Tlcommunications
Central Processing Unit
Data Base
HyperText Markup Language
HyperText Transfer Protocol
Integrated Development Environment
Interface Homme/Machine
Java Enterprise Edition
JournalDuNet
JavaScript Object Notation
Mdiation et Systmes Embarqus
Operating System
PHP: Hypertext Preprocessor
Recherche et Dveloppement
Rapid Application Development
Random Access Memory
Representational State Transfer
Software Development Kit
Systme de Gestion de Base de
Donnes Relationnelle
Systme de Gestion de Base de
Donnes Relationnelle Objet
Systme d'Information Gographique
Simple Object Access Protocol
Sofrecom Service Maroc
Tierce Maintenance Applicative
Unit de Production
Uniform Resource Identifier
eXtensible Markup Language
eXtreme Programming

Page | 10

Table des matires

_________________________________________________

Ddicace .................................................................................................................... 4
Remerciements ..........................................................................................................5
Rsum ...................................................................................................................... 6
Abstract .....................................................................................................................7
Liste des figures ........................................................................................................ 8
Liste des tableaux ...................................................................................................... 9
Liste des abrviations .............................................................................................. 10
Table des matires .................................................................................................... 11
Introduction ............................................................................................................. 13
Chapitre 1 : Cadre gnral du projet ....................................................................... 15
I - Prsentation de lorganisme daccueil ...................................................... 15
1 - Le groupe Sofrecom ............................................................................... 16
2 - Sofrecom Service Maroc ........................................................................ 18
3 - Organisation de Sofrecom Service Maroc ............................................ 18
II Contexte gnral du projet .................................................................... 20
1 La problmatique.................................................................................. 20
2 Cahier des charges simplifi ................................................................. 22
Chapitre 2 : Conduite du projet ............................................................................. 26
I Mthodologie de dveloppement ........................................................... 26
1 Mthode agile RAD ............................................................................... 27
2 Les phases du projet ............................................................................ 29
3 La planification du projet .....................................................................30
II Conception du projet .............................................................................. 32
1 Lacteur ................................................................................................... 32
2 Diagramme de packages ....................................................................... 32
3 Diagrammes de cas dutilisation .......................................................... 33
Page | 11

4 Diagrammes de squences ................................................................... 35

5 Diagrammes de classes .........................................................................36
6 Schma logiciel .....................................................................................38
Chapitre 3 : Ralisation ........................................................................................... 40
I Approche thorique ................................................................................. 40
II Architecture 3-tiers ................................................................................. 43
III Environnement technologique............................................................. 46
IV Tests des web services REST ..................................................................50
V Les Interfaces Homme/Machine (IHM)................................................. 52
1 Authentification (Authetication) :........................................................ 53
2 Recherche (Search) : .............................................................................54
3 Rsultats de la recherche (Search results) : ......................................... 55
4 Rsultats dtaills (Details) : ................................................................56
Conclusion ...............................................................................................................58
Bibliographie ........................................................................................................... 60
Annexe : Plan rel du projet ................................................................................... 62

Page | 12

Introduction
_________________________________________________

Dans un monde o la technologie volue sans cesse, lobtention

immdiate de linformation est devenue un des lments les plus indispensables
notre vie quotidienne, aussi bien sur le plan personnel que sur le plan
professionnel. Durant un court laps de temps, la recherche de linformation se
fait de plus en plus par lintermdiaire de tlphones ou de pads, plus quelle ne
se fait via des ordinateurs. Actuellement, les renseignements que nous
souhaitons avoir se doivent dtre accessibles du bout des doigts { tous les
moments et en tous lieux.
Dans cette optique dvolution constante vers des plateformes mobiles,
jai t men durant ce stage { raliser un prototype dapplication Android, qui
devrait reprendre certaines fonctionnalits de la version web existante, pour les
rendre portables et accessibles constamment.

Lexistant.
Device-DB est une des diverses parties de lapplication web Zoltar,
successeur de loutil DGCT du groupe Orange, lanc en 2007.
Zoltar est un outil qui rfrencie et regroupe toutes les informations
concernant les devices1 commercialiss par Orange. Il est utilis par plus de 500
clients dans 23 pays du monde, et contient les informations les plus prcises sur
plus de 2 000 devices diffrents.
Device-DB web sert plus prcisment recenser, consulter et modifier ces
devices, ainsi qu{ ajouter des commentaires de bugs qui pourraient tre
exploits par la suite.

Dans notre contexte, un device est tout quipement tlcom (tlphone, fax, radio ou autre)
commercialis par le groupe Orange.
Page | 13

Lavenir.
Dans loptique de raliser un premier prototype mobile de Device-DB,
seules quelques fonctionnalits parmi les fonctionnalits de bases seraient
reproduites dans un premier temps.
Device-DB Mobile est une application mobile destine rendre les
fonctionnalits de recherche et visualisation des devices deux fonctionnalits
disponibles dans lapplication web dorigine- plus portables et accessibles via des
terminaux mobiles Android.
Si approuv, le prototype donnerait naissance une application part
entire, complte, et ralise pour convenir plusieurs plateformes mobiles
(iOS, Windows Phone etc), cependant, avant den arriver l{, le choix sest
port sur le systme Android, tant lOS mobile le plus populaire du monde.

Page | 14

Chapitre 1 :
Cadre gnral du projet
Introduction : Ce premier chapitre dcrit le cadre gnral du projet. Dans un premier
temps, je vais prsenter lorganisme daccueil qui est Sofrecom Service Maroc, avant de
procder { la prsentation du cadre dont lequel sinscrit le projet.

Page | 15

I - Prsentation de lorganisme daccueil

1 - Le groupe Sofrecom
Raison sociale
Forme juridique
Groupe
Date de cration
Sige social
Capital social
Tlphone
Tlcopie
Site Web

: Ingnierie, tude technique

: Autre SA { conseil dadministration
: France Telecom Orange
: 01 Janvier 1967
: 24, Avenue du petit parc 94300 Vincennes France.
: 5 000 000 Euro
: +33 143 98 55 55
: +33 143 98 57 96
: www.sofrecom.com

Le groupe Sofrecom est une filiale de France Telecom Orange. Il est

spcialis dans le conseil des technologies de linformation, et plus
particulirement dans le domaine des tlcommunications. Il est compos dune
quipe internationale dexperts et de consultants de haut niveau spcialistes en
tlcommunications. Cest un leader dans le domaine du Conseil, de lIngnierie
et des Systme dinformation qui intervient { linternational depuis plus de
30ans. Ses prestations sadressent { tout type doprateur (fixe, mobile,
internet,) et sappuient sur des comptences pluridisciplinaires et
multiculturelles. Il a fait preuve, au fil des projets et { travers le monde, dun
savoir-faire unique dans divers domaines des tlcommunications.
Le chiffre daffaire de Sofrecom consolid, ayant dpass pour la premire
fois de son histoire, la barre symbolique des 100 M avec un rsultat net social
suprieur { 1.5 M et une prsence accrue { linternational (+55% du CA).
Le groupe Sofrecom est certifi ISO 9001 version 2008 et CMMI niveau 2,
et il est en train de prparer le niveau 3 de la certification CMMI.
Sofrecom crateur de solutions oprateurs
Sofrecom apporte une gamme complte de services et de solutions ddies
aux oprateurs savoir :
Conseil & Rseaux.
Systme dInformation.
Intgration & Dveloppement.
Ingnierie logicielle
Sofrecom apporte matrise et comptitivit aux projets dexternalisation et
de dveloppements de logiciels et de tierce maintenance applicative.
Page | 16

Le front office de Sofrecom sappuie sur ses software factories

dveloppes dans des filiales : Maroc, Argentine et Pologne, avec des ressources
et des infrastructures ddies.
Cette politique permet une adaptation rapide aux nouvelles technologies et
matrise des cots.

Pilotage de projet
Architecture
Expertise
fonctionnelle &
technique

Dveloppement
Maintenance
corrective et
volutive

Figure 1: Processus de production Sofrecom

Lingnierie logicielle rpond aux besoins suivants :

Externalisation de dveloppements logiciels en local, nearshore ou
offshore .
Intgration et portage de logiciel, de systme et darchitecture technique.
Implantation Sofrecom
Sofrecom est reprsente par huit filiales. Ces filiales sont implantes en
Algrie, Argentine, Indonsie, Maroc, Pologne, Jordanie, Duba et Vietnam.

Page | 17

Figure 2 : Implantation de Sofrecom

2 - Sofrecom Service Maroc

Sofrecom dveloppe sa prsence au Maroc avec laide de sa filiale Sofrecom
Services Maroc SSM cre en 2004, centre de services et dingnierie logicielle.
Le haut niveau dexpertise de ses collaborateurs marocains francophones et
la proximit avec lEurope, permettent { ces deux filiales doffrir flexibilit et
ractivit aux demandes de leurs clients : bases de donnes, systmes
dinformation dcisionnels ou dploiement de solutions applicatives (TMA).
Principaux clients : ANRT, Maroc Telecom, France Tlcom-Orange.

3 - Organisation de Sofrecom Service Maroc

Sofrecom Services Maroc est compose de trois directions, une direction
ressources humaines, commerciale, financire et une direction technique
organise selon plusieurs units de production (UP) dont : UP Web source, UP
Rseaux & SIG, UP MSE, UP Portail Self-Services et R&D, UP Gaia &
Technologies Oracle (voir organigramme).

Page | 18

Direction Gnrale
A. BOUZOUBAA

Direction des Ressources

Humaines

Direction Commerciale
L. MHAMMEDI

Charge daffaires
N. AROUS

Direction Financire
A. El GHALI

M. BACHIRI

Achats &
Moyens Gnraux

Comptabilit
K. BIDARA

Administration du Personnel

Juridique & Fiscalit

Contrle de Gestion

Recrutement et Communication Interne

A. MELLAK

SSM Consulting
& Engineering

SSM I T
UP Web
Source
H. RAHMAT

UP Rseaux
& SIG

UP MSE
L. DESCOUTURES

Architecture fonctionnelle
S. BENDALI

A.
BAGLIETTO
Architecture technique
G. MORIZE

Processus & Qualit

L. THEVENET

UP Portail,
Self Services
et R&D
S. FARHAT

UP Gaa &
Technologies
Oracle
I. SEMAAN

Service
Avancs
Telecom&Media
R. JEBARI

Architecture logicielle

Infrastructure technique
F. PICARD

Rseaux &
Services
S. KADIRI

Direction Technique
N. BENTAHAR

Figure 3 : Organigramme 2013-2014

Page | 19

II Contexte gnral du projet

1 La problmatique
En prenant en considration le but et lutilisation de lapplication de base
( quoi sert Device-DB ?) ainsi que les limites quune application mobile peut
avoir aussi bien sur un plan technique et fonctionnel, que dun plan de facilit
dutilisation (lequel est plus vident pour un utilisateur dapplication mobile :
rechercher et consulter ? ou remplir et insrer ?), la premire vraie question
laquelle il faudrait trouver une rponse : quelles sont les premires
fonctionnalits mettre en place pour Device-DB Mobile ?
Destine { tre utilise par un nombre prcis dutilisateurs, lapplication
future devrait au premier abord assurer son rle qui est de rendre laccs aux
informations concernant les devices facile, rapide, et effectif, et ce travers les
fonctionnalits de recherche et de visualisation, qui seront dtailles par la
suite.

A partir de l, il est naturel de se demander quelle plateforme choisir

pour le dveloppement de lapplication ?
Le choix sest port sur Android. Ce systme dexploitation est utilis
comme systme pour des appareils mobiles de marques varies. De plus,
lapplication visera la clientle venant dAfrique, et selon le site AfriqueItNews,
Android dtient la partie majeure du march, en plus davoir 85% du march
mobile { lchelle internationale.
Les appareils mobiles Android sont accessibles et beaucoup moins
coteux que leurs contemporains dApple ou Windows, ce qui a motiv le choix
de cette plateforme. Lapplication pourrait ventuellement tre adapte sur
dautres plateformes mobiles dans le futur.

Nous pourrions galement nous poser une question sur la nature de

lapplication { concevoir et crer. Devrait-elle tre native ou hybride ?
Avant de donner une rponse, je rappellerai brivement la dfinition des
deux. Une application mobile native est une application dveloppe
prcisment pour un des systmes dexploitation mobile. Son langage de
Page | 20

dveloppement est le langage spcifique du systme dexploitation en question.

Une application mobile hybride est une application qui combine des lments
dune application native et propres { un langage spcifique, en plus des
lments avec HTML5 sous forme de web application mobile.
Pour DeviceDB mobile, le choix sest port pour le natif. La refonte de
lapplication web existante pour la rendre hybride et lui permettre de safficher
correctement sur les appareils mobiles peut-tre une dmarche coteuse, et
longue. De plus, une application hybride est limite et ne permet pas
lutilisation de toutes les fonctions natives de lappareil.

Figure 4 : Application native ou hybride ? (source : AppSolute)

Page | 21

Passons maintenant une question de nature plus technique. Etant

donn la nature de lapplication et son langage de programmation (une
application mobile, programme en Android, donc.), la manipulation dune base
de donnes externe, comme il est le cas ici, peut poser des difficults : quelle
est la dmarche la plus convenable suivre pour les surmonter ?
La base de donnes associe Android est une base de donnes interne,
SQLite. Pour permettre la communication entre la plateforme Android et une
source de donnes externe, il faut utiliser une troisime couche qui servira
dintermdiaire entre les deux parties.

2 Cahier des charges simplifi

2.1 Description du projet
Objectif :
Lobjectif principal de lapplication mobile serait de faciliter la portabilit,
la recherche, et la visualisation des devices disponibles, fonctionnalits qui sont
aujourdhui uniquement disponibles via lapplication web interne Device-DB.
Pour des raisons de scurit mais galement dutilit, le premier
prototype de Device-DB mobile portera uniquement sur les fonctionnalits de
recherche et de visualisation.

Les besoins fonctionnels :

Lapplication devrait principalement permettre la recherche et la
consultation des devices.

Les besoins non-fonctionnels :

Lapplication devra tre prsentable. La qualit de lergonomie sera un
facteur essentiel pour lapplication.

Page | 22

Les fonctionnalits :
Authentification.
Etant donn la confidentialit des lments { visualiser, lutilisateur
devrait dans un premier temps sauthentifier avant de pouvoir accder {
lapplication mobile. Une premire vue o il peut insrer ses identifiants
apparat et ce nest quaprs vrification de ces informations que lutilisateur
peut parvenir aux autres vues. Lauthentification reprsente donc un premier
pas ncessaire de scurit.

Recherche :
Sur cette vue, lutilisateur peut effectuer une recherche des devices
prsents sur la base de donnes. Il a la possibilit de le faire en se basant sur les
critres de recherche suivants :
Recherche par supplier, ou manufacturer : o lutilisateur effectue sa
recherche en se basant sur le fournisseur et/ou constructeur du device.
(Exemples : Apple, Samsung, etc). Cette liste est sous forme dune liste
droulante.

Recherche par catalogue : le catalogue reprsente lanne et le trimestre

exact o le device est disponible en vente. (Exemple : si un device est dans
le Q4 de lanne 2014, a voudrait dire quil a t rendu disponible durant
le 4me trimestre de 2014.). Le critre catalogue a la forme dune liste
droulante contenant les combinaisons Q (quarters2 ) et Annes.

Recherche par Name : lutilisateur peut rechercher un device par son nom
complet, ou un mot cl appartenant { son nom, quil peut saisir dans un
champ texte.

Quarter : quart danne/trimestre, en anglais.

Page | 23

Visualisation :
Une fois la recherche effectue et le rsultat trouv, lutilisateur pourrait
slectionner le device en question et ainsi accder ses diverses informations.
La vue rsultante sera sous formes donglets o les diverses caractristiques de
chaque matriel seront lists, selon des catgories (General, Design, Features,
etc)

2.2 Ressources technologiques

Lapplication Android sera dveloppe en native avec le SDK3 Android, et
Android Studio4.

SDK Android :
Le SDK Android reprsente loutillage indispensable au dveloppeur
Android. Ce kit contient tous les outils ncessaires pour programmer avec
Android, excuter les programmes et les tester.

Android Studio :
Android Studio reprsente la plateforme officielle, soutenue par Google,
pour le dveloppement dapplications Android. Il repose sur IntelliJ 5 et devrait
permettre aux dveloppeurs dtre plus rapides et plus productifs. Avant la
sortie de la premire version stable dAndroid Studio, Google recommandait aux
dveloppeurs Android dutiliser linfrastructure Eclipse, combine au plugin
ADT6, une infrastructure qui reste une rfrence connue en matire de
dveloppement Java.

SDK : Software Development Kit en anglais, Kit de Dveloppement logiciel en franais.

Android Studio : Android Studio est un environnement de dveloppement pour dvelopper
des applications Android. Il est le premier de son genre car Google avait jusque-l propos ses
outils de dveloppement pour Android sous la forme dextensions pour lenvironnement
Eclipse, notamment lADT.
5
IntelliJ IDEA, IDE (environnement de dveloppement intgr) de JetBrains.
6
ADT : Android Development Tools. Plugin Eclipse permettant le dveloppement
dapplication sous Android.
4

Page | 24

2.3 Les contraintes

Contraintes de dlais :
Le projet devrait respecter le planning tablit et qui se droulera sur 95
jours au total.

Contraintes budgtaires :
Le projet qui reprsente un premier prototype ne ncessite pas de
ressources financires. Il ne ncessite pas de dplacement ou de matriel
particulier puisquil se concentre sur le dveloppement dapplication mobile
Android en utilisant loutil offert par Google qui est Android Studio.

Contraintes associes au projet :

Le dveloppement de cette application apportera galement son lot de
contraintes, associes { lapplication elle-mme :
Lapplication Android devrait tre lisible et compatible avec le maximum
des versions de lOS possibles. Depuis fvrier 2014, Google juge obsolte
toute version infrieure Jelly Bean 4.2.
Lapplication mobile devrait respecter au maximum les mesures de
scurit assures dans la version web.

Conclusion : Aprs avoir prsent le contexte gnral du projet, ainsi que lorganisme
daccueil au sein duquel sest droul ce stage dans ce premier chapitre, je procderai {
dtailler la conduite du projet dans le chapitre suivant.

Page | 25

Chapitre 2 :
Conduite du projet
Introduction : La premire partie de ce chapitre va porter sur la planification et la
mthode suivie pour mener bien le travail, tandis que sa seconde partie se focalisera
sur la conception.

Page | 26

I Mthodologie de dveloppement
1 Mthode agile RAD
Si vous achetez une maison sur plans, sans jamais visiter le chantier,
vous risquez davoir des surprises au moment dy emmnager, nest-ce pas ?
Cest pourtant une approche similaire qui guide la gestion traditionnelle de
projets de dveloppement logiciel. , extrait de larticle Pourquoi choisir la
gestion de projet Agile ? du site LesAffaires.Com. Cette question rsume, sans
dtailler, les raisons qui poussent chaque projet adopter une mthode agile
pour son dveloppement.
Les mthodes de dveloppement traditionnelles se basent sur un
enchanement des activits et des phases, depuis la phase spcification et
jusqu{ la mise en place du systme, selon un planning prcis et qui sert plus {
prdire la manire dont les choses devraient se passer. Cette vision est hlas loin
de la ralit, car les activits dun projet informatique ne peuvent, presque
jamais, se succder dune manire stricte, sans quaucun changement ne vienne
dranger ce planning prtablit.

Pour la ralisation de ce projet, jai adopt la mthode de dveloppement

rapide d'applications, note RAD7, qui se base sur un cycle de dveloppement
dont le dlai idal et de 90 jours minimum, et 120 jours maximum, et compos
de cinq phases : initialisation, cadrage, design, construction et finalisation, dont
trois principales et qui sont cadrage, design et construction. Son cycle de vie se
schmatise comme suit :

Figure 5 : Cycle de vie RAD

7

RAD : Rapid Application Development.

Page | 27

Avant de dcrire les phases principales de ce projet, il faudrait dabord

faire un bref rappel sur les anctres des mthodes agiles, et ainsi montrer
pourquoi elles ne sont plus au got du jour. Je vais choisir la mthode cascade,
ou waterfall, comme principal exemple. Jusqu{ la fin des annes 80, la mthode
cascade tait la mthode la plus employe par lindustrie du logiciel. La mise en
uvre dune nouvelle phase dpendait fortement de la compltude de sa
prcdente, chose qui pouvait engendrer plusieurs difficults pour le
dveloppement informatique.

Figure 6 : Cycle de vie en cascade

En informatique, recueillir lensemble des spcifications du premier coup

nest pas toujours facile. Dcrire exactement le systme attendu depuis le dpart
nest pas toujours vident. Avec la mthode classique en cascade, le temps de
ralisation du systme est souvent long et difficilement estimable { lavance.
Une rponse apporte ce problme a t propose avec la mthode
RAD. Dfinie par James Martin dans son live Rapid Application
Development , elle est avant tout pragmatique. Elle regroupe un ensemble de
bonnes pratiques et impose un cycle de dveloppement court qui ne dpasse pas
les 120 jours.

Page | 28

Contrairement aux mthodes Scrum ou XP qui sont principalement

bases sur un travail en binme ou en quipe de plusieurs personnes, cette
mthode peut permettre le travail individuel. Etant donn la taille du projet, jai
t mene le raliser en monme.

2 Les phases du projet

Phase 1 Initialisation.
La premire partie de ce projet consistait dfinir le contexte de
dveloppement, et rpondre aux questions concernant la technologie adopter.
Elle reprsente environ 5 % du projet.

Phase 2 Cadrage.
La phase de cadrage consistait dfinir le paramtre et les fonctions
principales que ce premier prototype devait reprendre, en se basant sur une
tude de la documentation existante de lapplication web initiale et dj{
existante. Prenant en considration le besoin principale de lapplication mobile
qui est, et je le rappelle, de rendre les informations de Device-DB disponibles
tre consults tout moment, les premires fonctionnalits ont t limites les
fonctions de recherches et de visualisations. Durant cette phase, jai pu rdiger
un cahier des charges simplifi question de cerner le mieux possible ce qui tait
demand de faire. Elle reprsente environ 10 % du projet.

Phase 3 Design.
Une fois les vues ncessaires prcises, la phase design pouvait
commencer. Elle reprsente environ 25 % du projet, et jai utilis loutil Balsamiq
et sa version dessai pour la ralisation des mockups dinterfaces.

Phase 4 Construction.
Cette phase est constitue de deux sous-phases qui salternaient au fur et
mesure : la conception, et le dveloppement. Cette phase reprsente environ
50% du projet.
Page | 29

Phase 5 Finalisation.
Cette phase reprsente environ 10% du projet. Cest ltape finale et
consiste { dployer lapplication.
En prenant en considration toutes ces donnes, le cycle de vie de ce
projet pourrait tre schmatis de la manire suivante :

Figure 7 : Cycle de vie RAD dtaill

3 La planification du projet
La planification du projet est parmi les phases avant-projet, elle consiste
ordonnancer les actions et le chemin de leur droulement tout au long des
phases constituantes du projet.

3.1 Plan prvisionnel

Le plan prvisionnel que jai propos a t ralis { laide de loutil Gantt
Project, et il est comme suit :

Page | 30

Figure 8 : Les tches

Figure 9 : Diagramme de GANTT

Page | 31

3.2 Plan rel

Cependant, le plan prvisionnel a subi des modifications tout au long du
droulement du projet, surtout durant son avant dernire phase qui est la phase
Construction . Dune part, jai t confronte { des blocages techniques, d
au fait que plusieurs des mthodes que jai utilis pour mon code sont devenues
obsoltes trs rcemment. Je me suis donc retrouve avec un code nonfonctionnel qui devait tre retravaill pour coller aux nouvelles spcifications
dAndroid. Dune autre, tant donn mon niveau dbutant en cette technologie,
jai d me documenter encore plus sur les nouvelles mthodes proposes dans la
documentation officielle.
Le rapport du plan rel se trouve dans lannexe.

II Conception du projet
Ce prototype aura comme source la base de donnes dj tablie pour
lapplication web existante, et gre par ses administrateurs. Vu la taille de cette
structure et sa confidentialit, le diagramme de classe reprsentera que les
tables ncessaires pour la ralisation de ce premier prototype. Les diagrammes
ont t raliss avec loutil PowerAMC.
Certains des diagrammes seront des diagrammes globaux et
reprsenteront, non seulement le prototype, mais galement une application
future en prenant en considration les perspectives et les ajouts potentiels qui
pourront tre inclus par la suite, tandis que dautres seront plus spcifiques et
dtailleront principalement les fonctionnalits de Device-DB Mobile dans sa
premire version.

1 Lacteur
Pour le prototype mobile, lacteur principal sera le client (utilisateur) qui
aura les droits daccs et de lecture sur les informations contenus dans la base
de donnes.

2 Diagramme de packages
Le diagramme de packages montre la dcomposition du systme en deux
principale catgorie : le package de la gestion des devices, et cest la catgorie
Page | 32

sur laquelle va porter la suite de cette conception, ainsi que le package de la

gestion des bugs.
La gestion des bugs regroupe plusieurs fonctionnalits futures qui
consistent principalement signaler et rapporter les bugs techniques et
dfaillants constats sur les diffrents devices.

Figure 10 : Diagramme de packages

Je vais maintenant me focaliser sur le package sur lequel se base la partie

ralisation qui est le package gestion des devices.

3 Diagrammes de cas dutilisation

Le diagramme de cas dutilisation reprsente les fonctionnalits
ncessaires aux utilisateurs.
La partie ralisation portera sur les cas Recherche et Visualisation .
Concernant le cas Cration , vu les objectifs primaires du prototype, son
contenu pourrait tre ajout aux perspectives.

Page | 33

Gestion des devices :

Figure 11 : Diagramme de cas dutilisation Gestion des devices

Cration des devices :

Figure 12 : Diagramme de cas dutilisation Cration des devices

Page | 34

4 Diagrammes de squences
Ce diagramme permet de dcrire les diffrents scnarios dutilisation des
cas dutilisation Recherche et Visualisation .
Recherche :

Figure 13 : Diagramme de squence Recherche

Page | 35

Visualisation :

Figure 14 : Diagramme de squence Visualisation

5 Diagrammes de classes
Ce diagramme reprsente les entits (des informations) manipules par
les utilisateurs.

Page | 36

Figure 15 : Diagramme de classes

Page | 37

6 Schma logiciel
Lapplication dans son intgralit (cest--dire le premier prototype ainsi que
toutes les fonctionnalits qui peuvent lui tre ajoutes) peut tre schmatise de la
manire suivante :

Figure 16 : Schma logiciel global

Page | 38

Ce rapport porte donc sur cette partie :

Figure 17 : Schma logiciel spcifique

Conclusion : Dans ce chapitre, jai prsent la planification initiale suivie pour raliser le projet
ainsi que sa conception en prsentant ses diagrammes package, cas dutilisation, squence. Jai
conclu en prsentant un schma logiciel global dune future application plus complte et dtaille.

Page | 39

Chapitre 3 :
Ralisation
Introduction : Je vais prsenter dans la premire partie lapproche thorique que a t
adopte pour la ralisation du projet, ensuite je parlerai brivement de larchitecture 3tiers avant de passer aux tests effectus sur les web services, et finalement prsenter les
diffrentes IHM de lapplication.

Page | 40

I Approche thorique
Comme lapplication web dorigine, Device-DB Mobile devrait communiquer
avec une base de donnes Oracle qui contient les diverses informations qui
seraient rcupres et utilises.

Base de Donnes
Externe

(Oracle DB)

Comment tablir
la liaison entre
les deux ?

Application Mobile
Android

Figure 18 : Comment tablir la liaison ?

La base de donnes associe habituellement la technologie Android est

SQLite. Permettant le stockage interne, cette dernire a toutefois un espace de
stockage limit, et tant donn le volume des donnes que lapplication est cense
supporter, le mieux serait dutiliser la base de donnes Oracle externe.

Lavantage de cette approche est que lespace de stockage des donnes, avec
une base de donnes externe, peut tre immense, contrairement une base de
donnes stocke directement sur le Smartphone. Cependant, le temps de rponse
et retour des requtes avec une base de donnes externe peut tre largement
suprieur au temps de rponse dune base de donnes interne.

Cette diffrence majeure vient du fait quune application Android ne peut

pas, et ne devrait pas, communiquer directement avec la base de donnes externe.
Pour faire communiquer les deux entits (application et base de donnes) il faut
avoir recours une couche intermdiaire, utilisant souvent un web service, qui
reoit les requtes et sert faire la liaison entre les deux couches pour permettre leur
interaction.

Page | 41

Base de Donnes
Externe

WEBSERVICES
(REST)

(Oracle DB)

Application Mobile
Android

Figure 19 : Lien tablit via un web service

Ce service web en question devrait donc organiser, adapter et traiter les

changes de donnes entre lapplication et la base de donnes externe qui seraient
maintenant possibles. Il peut tre dvelopp avec des technologies comme le PHP,
le .NET, le JavaEE, ou autre. Le choix du langage utilis pour la cration du service
web dpend de plusieurs facteurs notamment le choix de la plateforme (Microsoft
.NET, Apache Axis, )

Les services web, en gnral :

Globalement, un service web est une mthode de communication entre deux
applications ou appareils lectroniques, via le Web. Il existe deux types de services
web: Simple Object Access Protocol (SOAP) et Representational State Transfer
(REST).
SOAP est une spcification dun ensemble de rgles, standards, pour
permettre lchange de messages dans un format XML. REST dcrit un ensemble
de principes architecturaux par lesquels les donnes sont transmises sur une
interface standard (telle que HTTP).

Pour arriver choisir le type de service Web qui convient le plus, entre
SOAP et REST, il faudrait prendre en considration plusieurs facteurs en se basant
sur les fonctions que permet chaque type de service Web. Si les documentations
officielles des deux types ont tendance valoriser et survendre le mrite de chacun
des deux, des sources plus neutres comme le JDN8 ou LeMagIT soccupent de
dresser une liste de fonctions beaucoup plus objective et qui ma permis de faire un
choix : un service web type REST.
8

JDN : Le JournalDuNet.
Page | 42

Pour citer quelques-unes des raisons ayant motiv ce choix :

Les services REST proposent une bonne infrastructure de GET via la
mthode HTTP GET et cela peut amliorer les performances si les donnes
retournes par le service Web ne sont pas rgulirement modifies et ne
sont pas de nature dynamique.
REST est particulirement utile pour les appareils aux profils restreints,
comme les mobiles, pour qui la surcharge de paramtres comme les headers
ou dautres lments SOAP, est complique.
Limplmentation base sur REST est simple compare SOAP.

Lutilisation dun service web REST est la mthode la plus efficace et la plus
utilise pour tablir un lien entre la base de donnes et lapplication mobile, tant
donn que le langage Android ne communique pas directement avec une base de
donnes autre quune base SQLite.
REST peut tre dfinit comme tant un style darchitecture qui repose sur le
protocole HTTP : On accde une ressource (par son URI unique) pour procder
diverses oprations (GET lecture / POST criture / PUT modification / DELETE
suppression), oprations supportes nativement par HTTP.

II Architecture 3-tiers
Larchitecture dune application mobile utilisant une base de donnes distante
pourrait se schmatiser comme suivant :

Page | 43

Figure 20 : Architecture 3-tiers, simplifie (Source : tutorielandroid.)

Page | 44

Lapplication Android reprsente la couche client qui envoie des requtes

une couche intermdiaire (Middleware). Par le bais dun ou plusieurs web service
REST, la communication entre la couche Client et la couche donnes contenant la
base de donnes peut tre tablie.

Une architecture 3-tiers est une architecture client-serveur o les couches

accs aux donnes, interface utilisateur et traitement des donnes sont spares et
maintenue sur des plateformes distantes. Cest une architecture 3 niveaux qui
permet { chacune des couches dtre change ou remplace de manire
indpendante, sans toucher aux autres couches.
Les trois tiers dune architecture 3-tiers sont :
Prsentation : ou la couche client, demandeuse de ressources. Elle est
linterface utilisateur.
Application : ou middleware. Cest la couche logique , qui contient les
fonctionnalits et charge de fournir la ressource en faisant appel un autre
serveur.
Donnes : la couche contenant les bases de donnes et toutes les datas.

Figure 21 : Architecture 3-tiers Mobile

Page | 45

III Environnement technologique

Cette partie servira prsenter les outils utiliss pour la ralisation de ce
projet. Certains dentre eux ont t imposs par lentreprise daccueil tandis que
dautres ont t libre de choix. Les langages utiliss pour la ralisation du service
web et de lapplication sont Java et Android, respectivement.

Oracle Database :
Oracle Database est un systme de gestion de base de donnes relationnel
(SGBDR) qui depuis l'introduction du support du modle objet dans sa version 8
peut tre aussi qualifi de systme de gestion de base de donnes relationnel-objet
(SGBDRO). Pour les premiers tests, cest la version Express 11g qui a t utilise.

Android Studio :
Depuis le 8 Dcembre 2014, Android Studio est devenu lIDE officiel du
dveloppement Android, propos par Google. Entre 2011 et 2014, Eclipse tait
utilis { la place, combin { un plugin et contenant le SDK dAndroid.

Bien que certains utilisent toujours Eclipse et ADT, le choix, pour ce projet,
cest pos sur Android Studio car depuis la sortie de sa premire version stable en
Avril 2015, Google a entirement dlaiss Eclipse qui ne verra plus de mise jour
ou de ralisation de nouvelles versions partir de maintenant. De plus, Android
Studio est bas sur lIDE IntelliJ IDEA qui est, selon les professionnels du domaine,
un environnement de dveloppement beaucoup plus complet, beaucoup plus
performant, quEclipse.

Les diffrences entre Android Studio et Eclipse sont majeures, et ont toutes
motiv ce choix.

Page | 46

Android Studio
Android Studio utilise le
systme build Gradle.
Cest un systme qui se
base sur les concepts
dApache
Ant
et
dApache Maven.
Le design des interfaces
sous Android Studio se
fait plus rapidement et
propose plus doptions
sans avoir passer en
mode XML.

Build

UID9

Eclipse
Eclipse utilise Apache
Ant comme son systme
build principal.

Certains
lments
graphiques ne peuvent
tre insrer que via le
mode XML, et le temps
de
rponse
au
changement
de
linterface est plus lent.

Tableau 1 : Android Studio vs. Eclipse

Concernant la performance et la stabilit des deux, Android Studio bien que

plus performant quEclipse, il ncessite une charge considrable quand il sagit de
la RAM et le CPU de la machine utilise pour le dveloppement. Cest dailleurs
lun des premiers soucis qui ont t rencontr durant la phase dveloppement.

Concernant lapproche choisie pour la cration du service web, le choix sest

pos sur lapproche REST vu quelle est plus convenable que SOAP.
REST - Representation State Transfer :
Lapproche REST est plus simple { comprendre et { mettre en uvre que
SOAP . Daprs Mike Rozlog11, les dveloppeurs qui utilisent cette approche cite
la facilit de dveloppement, lutilisation de linfrastructure Web existante, et le
faible cot de formation comme des avantages cls de ce style. . Au-del de ces
avantages, le choix sest port sur REST car il est communment utilis pour les
applications web. De plus, et contrairement SOAP, il permet de retourner les
10

UID : User Interface Design.

SOAP : Simple Object Access Protocol.
11
Mike Rozlog est un conseiller en services de lInformation avec plus de 10 ans dexprience dans
le domaine.
10

Page | 47

rsultats avec de multiples formats (JASON, XML, etc) tandis que SOAP ne
communique quavec du XML !
Son majeur inconvnient reste cependant est quil est difficile dimplmenter
les protocoles de scurits avec REST, tandis quavec SOAP des protocoles scurit
font partie de ce style par dfaut.

Avantages

Inconvnients

Formats de rponse
Quand utiliser

Exemples populaires

REST
- Relativement simple
implmenter
et

maintenir.
- Linformation peut tre
enregistre par le client
pour viter des appels
rpts.
Fonctionne
uniquement avec les
bases du protocole http.
Y
ajouter
des
protocoles de scurits
peut
tre
plus
compliqu, sauf SSL quil
supporte par dfaut.
- Multiples et varis.

SOAP
Des
protocoles
scurits y sont intgrs
de base : WS-Security12.
- Est dcrit de faon
simple et lisible sous
forme dun document
WSDL.
- Difficile a implmenter
et peu populaire pour le
dveloppement web ou
mobile.
- Ncessite une bande
passante
importante
pour faire circuler les
donnes.
- Un format unique :
XML.
- Pour les applications - Pour des applications
orientes web ou mobile. qui ncessitent une trs
forte scurit.
- Twitter API, LinkedIn - PayPal SOAP API, etc
API, etc
Tableau 2 : REST vs. SOAP

Beaucoup de professionnels du domaine semblent tre daccord sur une

chose : lune des ides principales derrire les Web Services est de pouvoir
simplifier au maximum laccs aux donnes. Cest l{ o REST excelle, en
comparaison SOAP.
12

WS-Security : protocole qui permet dappliquer de la scurit aux web service SOAP.

Page | 48

JSON - JavaScript Object Notation :

JSON est un format dchange de donnes qui respecte une structure pour
vhiculer facilement et lgrement les informations.

Avantages

JSON
La
vitesse
de
traitement.
- La simplicit de mise
en uvre.
- Syntaxe simple parser
et gnrer par la
machine.

XML
- Largement utilis et
reconnu par tous les
langages
de
programmation.
- Il est plus facile lire et
convient mieux pour les
fichiers destins aux non
programmeurs.

Tableau 3 : JSON vs. XML

JSON, associ REST, est plus utilis et prfr pour les applications mobiles
que le format XML vu que ces dernires ncessitent rarement de rcuprer des
donnes fortement structures. JSON est rapide, lger et efficace.

Oracle GlassFish Server :

GlassFish est un serveur dapplication open-source sponsoris par Oracle. Sa
premire version a t lance par Sun Microsystems en 2005 et il est aujourdhui {
sa version 4.
Le serveur utilis pour le dploiement des web services REST est Glassfish.
Lune des raisons qui ont motiv ce choix cest que GlassFish propose une console
dadministration que dautres serveurs dapplications ne proposent pas. Il est
galement parmi les plus rapides quand il sagit de temps dexcution, de
dploiement et de redploiement, et supporte les web services REST par dfaut,
sans avoir lui ajouter quoique ce soit.

Page | 49

NetBeans :
NetBeans est un environnement de dveloppement open-source. Il a t
choisi pour la ralisation des web services REST pour sa facilit dutilisation, sa
riche documentation et le fait quil est rapide et ergonomique.

IV Tests des web services REST

Une fois les web service crs, je devais passer par une priode de test de ces
derniers, pour les vrifier et les valider, question de massurer quils taient
fonctionnels et pourraient tre utiliss sans problmes par la suite.

Figure 22 : Les web services REST

Il existe principalement deux catgories de tests, les tests en bote noire et

les tests en bote blanche. Vu que je suis celle qui a effectu les tests, et tant
donn que jai connaissance du code, ces tests vont sinscrire dans la catgorie
bote blanche .
Bien que jai test un { un tous les web services, jai choisis alatoirement un
seul prsenter dans ce rapport, pour viter une rptition inutile tant donn que
tous les autres ont t test de la mme manire.
Les web service en question est le web service permettant la manipulation
des Manufacturers .

Page | 50

Figure 23 : Web service Manufacturer

Sur cette figure, vous pouvez galement constater que le format dchang
spcifi est JSON.

Le premier type de test effectu tait le test unitaire. Les tests unitaires sont
les tests de blocs de code, que je testais au fur et mesure de la cration des web
services. Jai galement test le rsultat donn via lURI du service.

Page | 51

Figure 24 : Web service Manufacturer, rsultat JSON

Le deuxime type de test tait le test dintgration qui sexcute aussi bien en
bote noire quen bote blanche. Ces tests servent { vrifier que les services
sintgrent bien avec dautres composants, ou systmes. Pour ce test, jai intgr les
web services dans une application JavaEE basique.

Figure 25 : Web service Manufacturer, test JavaEE

V Les Interfaces Homme/Machine (IHM)

Dans la dernire partie de ce chapitre, je vais vous prsenter les quatre
interfaces principales de lapplication mobile. Ces illustrations sont les maquettes
valides et approuve des vues finales, et elles sont plus adquates aux explications
car contiennent le plus de dtails possible.
Ces maquettes ont t ralises avec le logiciel Balsamiq.
Page | 52

1 Authentification (Authetication) :

Figure 26 : IHM - Authentication

Constitue de deux champs textes et un bouton, linterface dauthentification

sert vrifier lidentit de lutilisateur avant de lui donner le droit daccs
lapplication.
Lutilisateur devrait saisir son nom dutilisateur dans le champ login , et
son mot de passe dans le champ password , avant de procder la connexion en
appuyant sur le bouton sign in .

Page | 53

2 Recherche (Search) :

Figure 26 : IHM - Search

Si lauthentification est russie, lutilisateur sera dirig vers la vue de

recherche.
Cette vue permet lutilisateur deffectuer sa recherche des devices. Il peut se
baser sur lun des trois critres : nom du device, son fournisseur, ou le catalogue,
tout comme il peut se baser en prcisant les trois critres.
Lutilisateur devrait entrer le nom entier, ou une partie du nom, du device
dans le champ device name , pour effectuer la recherche par nom. Il devrait
galement slectionn un choix des listes droulantes manufacturer , et/ou
catalog , sil souhaite faire une recherche en se basant sur ces critres.

Page | 54

3 Rsultats de la recherche (Search results) :

Figure 27 : IHM Search Results

Une fois la recherche effectue, si des rsultats correspondants aux critres

existent, lutilisateur sera dirig vers cette vue.
Les rsultats seront affich sur une liste, idalement un datagrid, mais, les
lments graphiques basique dAndroid nen offrent pas, il faudrait ventuellement
avoir recours aux solutions proposes par Xamarin ou AndroidJetPack13.
A partir de cette liste, lutilisateur peut slectionner la ligne correspondante
au device de son choix, pour pouvoir accder une quatrime vue qui contiendra
plus de dtails.

13

Xamarin et AndroidJetPack proposent des solutions payantes pour complter les lments
graphiques dAndroid avec des lments plus performants et plus personnalis. Les prix de
llment DataGrid par exemple peut varier entre 400$ pour une utilisation dans un seul projet, et
1000$ pour une utilisation dans un nombre illimit de projets.
Page | 55

4 Rsultats dtaills (Details) :

Figure 28 : IHM Details

Cette vue donne tous les dtails possibles sur le device. Ces attributs sont
regroups dans cinq diffrents onglets :
Longlet General : contient les informations gnrales sur le device.
Longlet Design : contient les informations caractre graphique sur le
device, comme la largeur et la hauteur de son cran (si cest un Smartphone
par exemple).
Longlet Features : prcise les caractristiques supplmentaires du
device, par exemple sil a une camra ou non.
Longlet Accessories : contient les informations sur les accessoires quun
device peut avoir.
Longlet Additional Information : contient des informations
complmentaire sur un device sil y en a.

Page | 56

Conclusion : Le chapitre ralisation a port sur lapproche thorique suivie pour raliser le
projet, larchitecture adopte qui est naturellement larchitecture 3-tiers pour une application
mobile, puis le chapitre a inclus une brve dmonstration sur les tests effectus sur les web
services et finalement il a prsent les IHMs de lapplication.

Page | 57

Conclusion
_________________________________________________

Mon projet de fin dtudes effectu au sein de lentit Sofrecom Service

Maroc tait une occasion dacqurir de nouvelles connaissances dans le domaine
du dveloppement, et plus prcisment du dveloppement mobile. Ce projet tait
galement une opportunit qui ma permis dintgrer une quipe professionnelle et
dinteragir avec diffrentes personnes.

Ce projet consistait concevoir et crer un prototype mobile Android

permettant la recherche et la visualisation des devices, propres au groupe Orange.
Ce prototype devrait dans un futur proche complter lapplication web dj{
existante et oprationnelle depuis des annes. La question qui se posait tait de
comprendre le fonctionnement de Device-DB web, pour pouvoir y rapprocher le
plus possible le fonctionnement de lapplication mobile.

Prenant ce point comme un point de dpart, jai { laide des orientations et

conseils de mes matres de stage- structur le projet en plusieurs phases, reposant
sur la mthode agile RAD. Dans un premier temps, il fallait dfinir le contexte de
dveloppement mobile et tudier brivement ses limites compar au
dveloppement web. Par la suite, jai attaqu la phase du cadrage qui consistait
dfinir les fonctions principales du premier prototype. Puis il fallait passer la
phase design o jai eu { crer les IHMs qui sadapteront au mieux aux
fonctionnalits prcises durant la phase prcdente. Une fois les vues ncessaires
valides, jai commenc la phase la plus lourde du projet qui est la construction, et
finalement, le projet dbouchera sur la phase finalisation qui sert tester le
produit final.

Les difficults que jai rencontres durant mon stage taient de natures
varies mais, pour ne citer que les principales je dirais que la difficult majeure
Page | 58

tait pour moi de respecter au mieux les plannings tablit, et aussi, essayer de
passer outre les difficults techniques (aussi bien physiques que logiques) que jai
rencontr tout au long du projet.

Comme perspective { ce projet, je souhaiterai pouvoir y ajouter lensemble,

ou du moins une majeure partie, des fonctionnalits proposes dans la version
web, pour le rendre plus complet. Je souhaiterai galement pouvoir lever le niveau
de scurit des web services et y implmenter des couches supplmentaires qui
garantiraient ce but. Et finalement, je souhaiterai que ce prototype soit amlior et
adopt car le mobile devient de plus en plus une ncessit indispensable dans un
monde o la technologie volue sans cesse.

Page | 59

Bibliographie
_________________________________________________

Documents internes Sofrecom :

OUK-SPEC-fonct_D-BD : document des spcifications fonctionnelles.
OUK-SPEC-technique_D-BD :
techniques.

document

des

spcifications

Carte_Fonctionnelle : document de la carte fonctionnelle.

Ouvrages :
ANDROID, de Florent GARIN. Dunod, dition 2, Octobre 2012, 231 pages.
LArt du dveloppement Android, de Mark MURPHY. Pearson, dition 4,
Dcembre 2012, 626 pages.
RAPID Application Development, de James MARTIN. Macmillan Coll Div,
Mai 1991, 736 pages.

Sites Web :
Android :
http://android.developpez.com/cours/
https://developer.android.com/guide/
http://openclassrooms.com/courses/creez-des-applications-pourandroid
Mthodologie Agile :
Page | 60

http://www.commentcamarche.net/contents/477-methodes-agilesrad-xp
http://www.piloter.org/projet/methode/rad.htm

Autre :
http://www.infoq.com/articles/rest-soap-when-to-use-each
http://www.journaldunet.com/
http://www.lemagit.fr/
http://www.lesaffaires.com/
http://www.uml.org/

Page | 61

Annexe : Plan rel du projet

_________________________________________________

Planning DeviceDB Mobile

09/03/15 17/07/15

Rapport Gantt Project

Dates de dbut/fin du projet :

Avance :
Tches :

9 Mars 2015 - 24 Juillet 2015

81%
18

Tches :
Nom

Dure

Date de fin

5
5
16
7
15
1
23
2

Date de
dbut
09/03/15
09/03/15
16/03/15
16/03/15
16/03/15
06/04/15
07/04/15
07/04/15

Phase 1 - Initialisation
tude du contexte gnrale
Phase 2 - Cadrage
Documentation initiale
Rdaction du CDC
Validation du CDC
Phase 3 - Design
Documentation sur les outils de
maquettage
Cration des mockups des
vues/interfaces
Validation des mockups
Phase 4 - Construction
Conception
Dveloppement des services REST
Test des services REST

20

09/04/15

06/05/15

1
49
44
14
2

07/05/15
08/05/15
08/05/15
08/05/15
28/05/15

07/05/15
15/07/15
08/07/15
27/05/15
29/05/15

13/03/15
13/03/15
06/04/15
24/03/15
03/04/15
06/04/15
07/05/15
08/04/15

Page | 62

Dveloppement mobile
Test de l'application mobile
Phase 5 - Finalisation
Dploiement

30
3
7
7

01/06/15
13/07/15
16/07/15
16/07/15

10/07/15
15/07/15
24/07/15
24/07/15

Tableau 4 : Les tches

Diagramme de Gantt

Figure 29 : Diagramme de GANTT rel

Page | 63