rapport_recarton.docx - Free

haltingbarberInternet and Web Development

Aug 15, 2012 (4 years and 8 months ago)

586 views

1


Etudiant

:
Rémi CARTON

Suiveur


: Fahed ABDALLAH

GI06 ICSI

Printemps 2008










D
EVELOPPEMENT ET EVOL
UTION DE SIMULATEURS

D
'
APPLICATIONS













Sopra Group

Tour Manhattan, La Défense

Responsable

: Stéphane TRICOLORE

2


I.

Remerciements

Ce stage chez
Sopra a été très formateur, mais au
-
delà du stage lui
-
même, j’ai beaucoup appris des
personnes avec qui j’ai eu la chance de travailler.

Je tiens tout d’abord à remercier toutes les personnes qui m’ont aidé durant ce stage, et plus
particulièrement

:



Alex
a
ndre Moret,
Stéphane Tricolore
et Vi Olivet
pour m’avoir accueilli au sein de l’équipe
DGP et plus largement chez Sopra, ainsi que pour m’
avoir fait confiance au travers des
différents projets.



Romaric Blatrix, pour sa disponibilité et son dévouement enver
s les stagiaires



Santiago de San Primo ainsi que Philippe Baye, pour leurs avis éclairés sur les difficultés
techniques



L’équipe Foot+, et notamment Maxime Harnois et Marie
-
Sandrine Daubigney



Et toute l’équipe Portail DGP,
Renaud,
Joël, Xavier,
Pony, Arnau
d, Vince
nt, Tommy, Anaïs,
Franck, Yvonnick et Lucille
pour leur bonne humeur au quotidien



Et
finalement

l’équipe Maroc Télécom pour leur humour et les parties de foot en salle
endiablées

!




3


II.

Sommaire

I.

Remerciements

................................
................................
................................
............................

2

III.

Résumé technique

................................
................................
................................
........................

4

IV.

Présentation de l’entreprise

................................
................................
................................
.........

5

A.

Historique

................................
................................
................................
............................

5

B.

Implantation

................................
................................
................................
.............................

5

C.

L’organisation de la société

................................
................................
................................
.....

5

V.

Stage

................................
................................
................................
................................
............

6

A.

Sujet du stage et démarche

................................
................................
................................
..

6

VI.

Le projet DGP

................................
................................
................................
.............................

7

A.

Cadre et contexte

................................
................................
................................
.................

7

B.

Métho
dologie de travail

................................
................................
................................
.........

10

C.

Architecture et fonctionnement du portail DGP

................................
................................
....

20

D.

Le projet TIC

................................
................................
................................
.....................

23

E.

Développement de simulateurs de services dans le cadre de DGP

................................
.......

24

VII.

Le projet FOOT+

................................
................................
................................
.......................

31

A.

Contexte du projet

................................
................................
................................
.............

31

B.

Acteurs du projet

................................
................................
................................
...................

31

C.

Objectifs

................................
................................
................................
................................

32

D.

Travail sur l
e projet Foot+

................................
................................
................................
.

32

E.

Conclusion sur le projet Foot+

................................
................................
..............................

34

VIII.
Bilan du stage

35

IX.

Table des illustrations

................................
................................
................................
................

36

X.

Glossaire des acronymes

................................
................................
................................
...........

37

XI.

Bibliographie

................................
................................
................................
.............................

38




4


III.

Résumé technique


Dans le cadre de l'évolution du système d'information de SFR, Sopra Group est responsable du
développement du portail d'accès des distributeurs (revendeurs). Ce portail met en relation des
informations issues de différents sous
-
systèmes applicatifs.

Il
permet au distributeur d'avoir accès aux fiches des clients, qui le redirigent vers d'autres sous
-
systèmes applicatifs lui permettant notamment de réaliser des actes de vente ou de souscription.


Pour le développement et l'intégration de ce portail, il est

nécessaire de simuler un certain nombre
de flux et de services. Ces simulateurs (appelés familièrement 'bouchons') vont permettre de reproduire
le comportement de l'application dans l'environnement de production, de simuler des comportements
erronés ou en
core des pannes.

Le défi technique de ces bouchons est la reproduction de comportements sur la base de
spécifications d'interface, dans des mécanismes et des technologies variés: simulation de SSO,
d'applications, de flux, de résistance à la charge; dans l
e but d'assurer l'interopérabilité du portail.

5


IV.

Présentation de l’entreprise

A.

Historique

Créée en 1968 par Pierre Pasquier et François Odin, Sopra Group fait partie des premières Sociétés
de Services en Ingénierie Informatique françaises. Dès l’origine, Sop
ra a connu un développement
rapide et une forte croissance jusqu’en 1978. Au cours des années 79
-
84, la société de taille nationale
est déjà positionnée sur les grands marchés
,

mais connaît quelques turbulences
,

et doit faire face à une
situation de crise.

Puis, à partir de 1984 et durant cinq années, la société est refondée autour d’un
projet d’entreprise : faire de Sopra une entreprise industrielle gagnante. Cet objectif fut largement
atteint à la fin des années 80. Après quelques années de période favora
ble, Sopra connut deux années
difficiles et dut prendre de nouvelles décisions quant à son avenir en 1996. Renforcement du capital,
croissance externe, progression du résultat, Sopra projette de devenir une société de taille
internationale en 2002 et crée
ainsi Axway, filiale de l’activité Progiciel.

Aujourd’hui, Sopra Group est reconnu en tant qu’intégrateur de systèmes et de solutions ainsi qu’en
outsourcing applicatif. L’outsourcing applicatif concerne principalement la gestion des logiciels et
progiciel
s d’une entreprise, avec la particularité que l’entreprise reste propriétaire de ses programmes.
L’acquisition d’Orga Consultants a permis la création d’un cabinet de conseil en stratégie et
management européen
, tandis
Axway ouvre la société à l’internatio
nal

et notamment les Etats
-
Unis
.


Sopra compte 12

000 collaborateurs, et a réalisé un chiffre d’affaires d’1 milliard d’euros en 2007,
il est à noter que les 2/3 du chiffre d’affaires se font toujours en France.


B.

Implantation

Sopra Group couvre le territoi
re français par le biais de plus de 18 agences et est également présent
en Allemagne, Espagne, Irlande, Italie, Portugal, Royaume
-
Uni et Suisse. La filiale Axway positionne
le groupe au niveau mondial : Amérique du Nord, Amérique du Sud, Europe, Inde et Au
stralie.


C.

L’organisation de la société

Sopra Group possède une structure de pilotage à trois niveaux

:



Le niveau 1 ou direction générale intervient au niveau stratégique et supervise les niveaux
opérationnels.



Le niveau 2 correspond aux divisions et filial
es de l’organisation de Sopra. Chaque division ou
filiale possède un pouvoir de dé
cision budgétaire et comptable, elle

regroupe plusieurs agences.



Le niveau 3 est constitué par les agences
,

celles
-
ci

représentent les unités économiques de base
de Sopra. Ch
aque agence est autonome
,

tant au niveau ressources humaines que budgétaire.
Elles assurent également la facturation et le recouvrement des créances.




6


V.

Stage

A.

Sujet du stage

et démarche

En génie informatique, il est relativ
ement facile de trouver un
stage, j’ai pu passer plusieurs
entretiens, et j
’ai

finalement

choisi ce stage car il correspondait à plusieurs des objectifs que je m’étais
fixé en débutant ma recherche

: il fallait q
u’il

soit dans une optique d’embauche, afin d’assurer
l’implication de
l’entreprise et la technicité du travail à accomplir, il fallait qu
’il soit dans un domaine
dynamique et porteur,
utilisant des technologies d’aujourd’hui
,

que j’aurais à apprendre et à maîtriser,
dans le cadre d’un projet
complexe dans le domaine des syst
èmes d’information (ma filière). Etant
donné que je cherchais un stage dans une optique d’embauche, je me suis aussi intéressé aux
perspectives d’évolution, que ce soit en termes de responsabilités ou de salaire.

1.

Sujet

:

Rattaché à l'unité de services Fron
t Office & Business Intelligence, basée à la Défense, vous
intégrerez une équipe d'ingénieurs, encadrée par un chef de projet, chargée de réaliser des tâches de
développement dans le cadre d'une évolution du portail distributeurs Grand Public de SFR : évol
ution
consistant à mettre en place un système de notification des applications connexes sur le portail. Ce
portail est un portail d'accès aux applications du distributeur (Accès internet, extranet et intranet).

Votre stage aura pour objet la participation

aux différentes phases du projet (conception, réalisation,
qualification, livraison).

Intérêts du stage :



Mise en situation dans le cadre d'un projet d'intégration de systèmes, piloté selon les méthodes
Sopra Group.



Acquis fonctionnel dans un secteur de p
ointe. Le projet offre une visibilité sur le métier des
distributeurs d'un grand opérateur en téléphonie mobile et sur l'infrastructure mise en
œuvre

par
cet opérateur.



Acquis humain par le travail en équipe (organisation en équipes projets).



Acquis techno
logique sur les outils de développement.

Technologies :


Java J2EE, Webser
vices, Oracle, LDAP, MQ Series



7


VI.

Le projet DGP

A.

Cadre

et contexte

1.

Le projet de SFR, rôle de Sopra

Le projet DGP (Distributeurs Grand Public) s’inscrit dans le cadre de la refonte du
système
d’information de SFR, c’est la division Télécoms qui

en

a la responsabilité
.

Celle
-
ci

effectue essentiellement des projets au forfait
,

ou de la tierce maintenance applicative

(TMA). Elle est divisée en deux marchés :



Le Marché 1 : projets au forfai
t, TMA pour le groupe Orange.



Le Marché 2 : projets au forfait, TMA, régie pour les clients SFR, Neuf Cegetel.

Lorsqu’un client désire ne plus effectuer la maintenance de ses applications en interne, il délègue ce
travail à un prestataire : c’est ce qui es
t appelé une TMA. Le passage d’un projet en TMA se déroule
en plusieurs phases :



Le lancement : le client transfère progressivement ses responsabilités et son autonomie à Sopra
Group. Les équipes projet Sopra doivent installer l’environnement de travail :
outils,
convention de service, système de contrôle.



La Maintenance Opérationnelle : Sopra Group contrôle et dirige la totalité des activités de la
TMA : Maintenance Corrective, Evolution, Conseil et prévention.

Le projet de refonte du système d’information

de SFR consiste à redévelopper un certain nombre
d’applications pour y intégrer des besoins nouveaux, et en améliorer le

comportement, ce projet
s’inscrit plus particulièrement dans la refonte des applications liées à l’intranet des distributeurs
(revende
urs).

SFR est l’un des principaux clients de la division Télécom, d’autres projets de grande envergure (tel
que le projet BIOS, gestion des clients) sont actuellement en phase de lancement chez Sopra.

Dans le cadre de ce projet de refonte de l’intranet,
différents sous
-
systèmes applicatifs (SSA) sont
concernés, la refonte de chacun des SSA est prise en charge par une SSII différente. Certaines
applications sont plus centrales que d’autres, il est nécessaire qu’à terme, chaque SSA communique
parfaitement a
vec les autres

pour assurer un bon fonctionnement de l’application.



8


2.

DGP en résumé

Le projet répond à une demande du Group SFR de réaliser une évolution de son portail distributeurs
Grand Public. Ce portail est destiné aux distributeurs en charge de la co
mmercialisation des offres du
domaine de la mobilité. Il fournit un point d’accès unique (internet, extranet, intranet) aux applications
utilisées par les distributeurs SFR dans le cadre de leur activité de vente
,
selon leur
s

habilitation
s
.

Il permet d’inf
ormer sur l’état de disponibilité des applications
,

et répond au souhait de la direction
commerciale de disposer d’un outil permettant d’informer rapidement et simultanément des sous
groupes ou l’ensemble des distributeurs.

Des fonctionnalités de type admi
nistration et statistiques sont également disponibles
pour les
distributeurs internes (plusieurs types de distributeurs existent, tels que interne SFR ou Grand Public
pour les revendeurs autres que SFR).

Le but premier du portail était de fournir un accès
unique à l’ensemble des services proposés aux
distributeurs. Aujourd’hui, il ne fournit pas seulement un accès

à des services, il évolue pour

intégrer
des services. Le service clé est l’application Accueil Client qui permet la consultation et la gestion
d
’un compte client. On
y
retrouve aussi un module d’administration,

de statistique et de formation. On
utilise les termes Portail, Accueil Client ou DGP pour désigner l’équipe et le projet.

Ce projet a
été
démarré il y a 3 ans
;

les développements actuelleme
nt en cours concernent le lot n°2.
On appelle ‘lot’ un ensemble d’évolutions rassemblées dans une livraison conséquente, ils rythment le
développement de l’application car ils représentent des jalons pour le projet.

Le développement de chacun des lots adop
te un fonctionnement similaire à un projet de
développement à part entière, avec les différentes phases (conception, réalisation, qualification,
livraison).

En marge de ces lots, on dénombre un certain nombre de projets ou sous
-
projets liés à DGP, tels
que

le TIC (tests d’intégrations), ou les bouchons de performance.

La taille de l’application a pour conséquence une certaine difficulté de prise en main du sujet, il est
difficile d’avoir une bonne vision d’ensemble du projet au démarrage.



9


3.

Equipe projet
‘Portail’

Le projet Portail DGP regroupe une quinzaine de personnes

(voir
fig. 1
)
, réparties sur Paris (la
Défense) et Renne
s
. Historiquement la plus grosse partie
de l’équipe se trouvait à Paris, mais
récemment la tendance s’est inversée, cela s’est traduit par la nomination au cours de l’année d’un
nouveau directeur de projet
(à Rennes)
qui a remplacé Alexandre Moret au cours du premier semestre
2008.

Cette situat
ion particulière amène fréquemment à devoir recourir au téléphone, ou à des outils de
visualisation à distance (à l’image de VNC) pour débloquer certaines situations. Cela oblige également
à faire les réunions de projet avec
un système de conférence (via t
éléphone)
.



fig. 1.

Organigramme de l’équipe Portail


En plus de DGP, c
ertains projets proches sont également pris en charge
par
l’équipe Portail, tels que
EDEN ou SPARTE, aussi les membres de l’équipe sont
-
ils amenés à travailler sur un au
tre projet que
l’accueil client certaines semaines. Il est courant de donner un coup de pouce temporaire
,

pour finir un
développement en retard et ainsi respecter
une

livraison

par exemple
.



Directeur de Projet

Alexandre Moret / Patrice Rolland

Chef de Projet

Stéphane Tricolore

Chef de Projet adjoint

Franck Gottini

Architecte

Philippe Baye

Architecte

Santiago

De San Primo

Equipe

10


B.

Méthodologie de travail

La taille de l’équipe et celle du projet

imposent
une certaine rigueur, tant au niveau de
l’organisation de l’équipe et du projet, que dans le développement. Ce stage m’a permis de découvrir
quelques méthodes de travail. Selon les méthodes utilisées, l’implication du client est plus ou moins
imp
ortante, et le pilotage de celui
-
ci sur le projet se fait de plus ou moins loin selon les libertés laissées
au maître d’œuvre
par le client.
De manière synthétique
,

on considère dans le cadre de ce projet que la
MOA est SFR, alors que la MOE est l’ensemble

des responsable
s

du projet du côté Sopra Group.

1.

Cycles

du projet

Le projet portail
DGP,
à l’instar de nombreux projets
,

est divisé en plusieurs lots, compte tenu de
l’ampleur de la tâche, ces lots permettent d’intégrer petit à petit les
fonctionnalités
et les interactions
avec les différents SSA.

Le cycle des lots est rythmé par 4 phases

:


a)

Conception

La conception est la phase de rédaction des spécifications générales, ainsi que des spécifications
fonctionnelles. Ces tâches sont réalisées par des perso
nnes ayant une bonne connaissance du
fonctionnement actuel de l’application. Elle consiste à définir toutes les fonctions que l’application va
devoir remplir à la fin du lot.

Les spécifications générales se font sur la base d’une proposition commerciale f
aite à SFR par
Sopra, cette proposition est le résultat de négociations sur les fonctions à implémenter, les délais ainsi
que les choix techniques les plus importants. C’est une phase
cruciale,

qui va conditionner la réussite
du lot voire du projet, il fau
t un équilibre judicieux entre la faisabilité

ainsi que

les contraintes de
délais et de coût.

La particularité du projet portail
-

qu’on retrouve dans un certain nombre de projets entre Sopra et
SFR, mais plus rarement avec les autres clients
-
, est que
l
es
spécifications
sont

rédigée
s

entièrem
ent
par les équipes Sopra Group. SFR valide ensuite ces spécifications, ou les fait modifier si elles ne
correspondent pas à la proposition initiale faite avec Sopra.

Sur l’accueil client, je n’ai pas eu à faire de c
onception, l’architecture du service étant déjà définie
et détaillée dans un dossier d’architecture (DAT), en revanche, sur les projets satellites (et plus petits
projets), j’ai eu la chance de pouvoir déterminer moi
-
même les solutions à adopter pour répon
dre à une
problématique. Dans ces situations
-
ci, et selon l’importance de la solution, il était généralement
judicieux d’en discuter avec d’autres développeurs ou un architecte pour faire valider la solution, il
vaut mieux passer un peu plus de temps sur l
’élaboration de la solution, d’un point de vue conceptuel,
que de tomber sur un obstacle qui va gêner la progression, voire devoir faire repenser la solution et
recommencer.



11


b)

Réalisation

La conception va principalement impliquer les architectes et les réd
acteurs des spécifications
(souvent appelés ‘fonctionnels’, par opposition aux ‘techniques’
:

les architectes et les développeurs).
En revanche la réalisation va impliquer tous les acteurs de l’équipe projet, elle nécessite une bonne
communication entre tou
s les membres de l’équipe pour que le résultat soit celui attendu lors de la
conception.

Durant
la phase de réalisation, certains problèmes techniques nécessitent la collaboration de
plusieurs membres de l’équipe

: si un développeur rencontre un problème p
articulier, par exemple une
fonctionnalité impossible à réaliser à cause du temps ou des technologies, il va consulter le chef de
projet ou un responsable fonctionnel pour trouver un contournement possible, ou une manière de
s’approcher du résultat initial
ement voulu. L’architecte va également intervenir dans la résolution de
ce problème car il a en général plus de recul et plus d’expérience, ainsi qu’un bagage technique plus
important que celui des développeurs dans les SSII, souvent plus jeunes.

C’est une

des phases qui a occupé la plus grande part de mon temps, avec la qualification
notamment.

c)

Qualification

Cette phase est

cruciale
, elle va confronter les spécifications et le travail réalisé. Il faut valider que
chaque fonction, et
que
chaque règle de ges
tion (comportement attendu) de l’application est bien
implémentée de manière conforme aux spécifications fonctionnelles. En outre, durant cette phase,
chaque erreur ou bogue est répertorié et signalé aux développeurs en charge de la fonctionnalité. En
cas
de doute il faut alors se référer aux spécifications, et si besoin à un responsable fonctionnel.

Pour ne pas biaiser les spécifications, la personne qui va qualifier une fonction doit en ignorer le
fonctionnement technique, et idéalement en savoir le moin
s possible, pour tester les mauvaises
utilisations ou les manques d’ergonomie. Chez Sopra ce sont principalement les développeurs qui
se
chargent de la qualification.

C’est pour cela qu’en général sur un projet avec plusieurs développeurs,
ceux
-
ci vont s’é
changer les rôles pour la qualification, un développeur qualifie les fonctionnalités
développées par un autre. En cas d’anomalie par rapport aux spécifications, la qualification de la
fonctionnalité devra être recommencée lors d’une nouvelle série de tests
.

Certaines évolutions de l’application peuvent avoir des incidences sur des fonctionnalités
développées durant une livraison antérieure, des tests supplémentaires peuvent
-
être alors rajoutés à la
campagne de qualification

:

on les appelle

tests de non ré
gression (TNR).

Les tests sont faits en suivant une fiche de test, ces fiches de tests sont rédigées à la suite des
spécifications, par une personne responsable de la campagne de test, cependant il est courant que le
développeur qui a une idée plus précise

de la fonctionnalité à tester et des étapes du test, complète ou
rédige le test, une fois le développement fini. La personne chargée du test doit suivre la fiche de test
pas à pas, et en pr
incipe il n’y a besoin d’aucune connaissance
, même si certaines fi
ches de tests sont
un peu techniques et nécessitent parfois une aide extérieure.

C’est pour cette raison qu’en général les personnes qui arrivent dans une équipe font de la
qualification, cela ne nécessite que très peu de connaissances de l’application, et

donne très vite une
idée du fonctionnement général. Dans le cadre de mon stage, j’ai commencé par de la qualification
avant de commencer à développer des outils annexes à l’accueil client.

12


Cette phase est très importante dans le processus qualité de l’app
lication, et permet de restreindre le
nombre d’anomalies qui seront détectées chez le client (qui impliquent une sanction financière du côté
Sopra si les anomalies sont qualifiées de ‘majeures’ ou de ‘bloquantes’, voir la catégorisation des
anomalies plus
loin). Malheureusement, c’est la phase qui précède la livraison, et lorsque les délais
sont mal calculés, ou qu’un retard a été accumulé, cette phase est parfois faite parallèlement à la fin de
la réalisation, ou parfois très allégée, ce qui a souvent une
très forte incidence sur la qualité de la
livraison. Cependant certaines livraisons ne peuvent pas être retardées, et c’est un risque que doit
parfois prendre le chef
de projet pour assurer une livraison à l’heure. Ce choix est bien souvent
préjudiciable a
ussi bien au client qu’à l’équipe de développement.

d)

Livraison

La livraison est la dernière phase du projet, avec SFR elle peut se faire par FTP pour les petites
livraisons (évolutions), ou sur un support matériel (CD/DVD).

Une livraison sur le projet DGP va avoir pour conséquence une sorte «

d’arrêt sur image

» de tous
les fichiers sources, et de tous les fichiers de documentation. Ceci se traduit par la création d’une
nouvelle branche sur le gestionnaire de
versions
, afin d
e pouvoir revenir à une version antérieure si
besoin. Ceci est nécessaire car une version peut nécessiter une correction alors qu’une nouvelle
version est en développement, ce n’est alors pas la nouvelle version qui est
re
livrée, mais une version
corrigée
de l’ancienne.

La livraison va comporter tous les documents nécessaires à l’utilisation de l’application (notamment
les manuels pour les utilisateurs, et les manuels d’installation). A ces documents sont ajoutés les
résultats de la campagne de tests, de ce
tte manière SFR va pouvoir vérifier quels tests ont été passés, et
va pouvoir repasser les tests pour vérifier que son installation est correcte et que tout fonctionne
comme prévu.



13


e)

Le pilotage du projet

Le système de pilotage est commun à tous les projets. Il permet par le biais de différentes réunions
d’obtenir une vue globale sur l’application pour les différents acteurs : équipe projet, directeur de
surveillance, client.

D’un point de vue général, le
système de
p
ilotage Sopra Group est représenté par le graphique ci
-
dessous

:



fig. 2.

Système de
p
ilotage Sopra


Ce système est implémenté par le biais de réunions organisées :

Le V1 est un point de pilotage hebdomadaire. C’est généralement une réunion qui se p
asse le lundi
matin avec l’équipe projet et dirigée par le chef de projet. Chaque personne indique l’état
d’avancement sur son travail et doit évaluer son
RAE
(
reste à engager
). Cette réunion permet à
l’équipe de connaître le travail de chacun et d’être in
formée globalement de l’avancement du projet et
des prochaines évolutions.

Le V2 ou point de pilotage mensuel, est une réunion qui se déroule entre le chef de projet et le
directeur de surveillance. Cette réunion permet de vérifier les objectifs et l’avanc
ement du projet par
rapport aux estimations initiales.

Le PMS (Point Mensuel de Surveillance), est une réunion durant laquelle les décisions nécessaires à
la réalisation du projet sont étudiées.

Le PPC (Point Périodique Client) est une réunion où le clien
t prend connaissance de l’avancement
du projet. C’est également l’occasion de récapituler les actions en cours et à venir.



14


2.

Spécificités techniques du développement

Ce projet, de par ses dimensions et sa durée (et le fait qu’il soit une TMA), va impliquer

un certain
nombre d’aspects plus ou moins spécifiques dans le développement. Certains sont en effet courants
dans les projets de développement de sociétés de service, tandis que d’autres sont plus particuliers à
Sopra et au projet DGP.

a)

Dimensions du proje
t

La durée de développement de ce projet, et la taille de l’équipe impliquée, fait qu’il est assez
volumineux, en termes de fichiers sources notamment. L’intégration d’une nouvelle fonctionnalité va
souvent nécessiter des modifications sur de nombreux fich
iers, en plus de ces modifications, un certain
nombre de mécanismes doivent être respecter pour que le projet garde une cohésion et soit plus simple
à maintenir, il faut donc parfois faire abstraction de ses propres méthodes de développement et
solutions p
our s’adapter à celles employées habituellement. Il faut par
fois par exemple renoncer à des
algorithmes concis et élégants au niveau du code, pour les remplacer par des algorithmes plus lourds,
mais beaucoup plus simples à comprendre et maintenir. De sorte

qu’il faut trouver un équilibre entre la
concision et les solutions très longues.

Contrairement aux exercices à l’école où l’objectif est souvent la rapidité de développement, en
entreprise il faut surtout mettre l’accent sur la lisibilité du code.

Le pro
jet rassemble plusieurs centaines de fichiers source, et d
eux principales difficultés

vont
découler de ces dimensions

:



Se repérer dans l’arborescence gigantesque et savoir où modifier de préférence



Intégrer parfaitement son code à l’application


b)

Gestion des sources,
gestion des versions

Comme dans tout projet de développement, une gestion des sources efficace permet un gain de
temps considérable, elle permet également d’éviter l’anarchie, et de minimiser les erreurs dues à un
travail en parallèle
sur les mêmes fichiers. Cependant, même si la gestion des sources par voie
logicielle va permettre de minimiser les erreurs et les conflits, il incombe toujours aux développeurs de
s’arranger entre eux pour s’assurer de ne pas modifier les mêmes fonctionna
lités au même moment
sous peine d’avoir des erreurs parfois difficile à diagnostiquer.

Les systèmes de gestion de versions « traditionnels

» sont utilisés chez Sopra

:



CVS, pour les projets anciens (DGP par exemple)



SVN, pour la plupart des projets lancés
récemment

La gestion des versions est un problème central pour un projet de la taille de DGP, le nommage et la
mise à jour des fichiers est faite de manière rigoureuse, car une
mauvaise manipulation

dans la mise à
jour des versions peut entraîner des erreu
rs qui vont bloquer l’ensemble de l’équipe dans le
développement, le temps qu’elle
s

soi
en
t corrigée
s

ou annulée
s
.

D’un point de vue personnel, j’ai trouvé que la formation de génie logiciel à l’UTC ne mettait pas
assez l’accent sur ces outils, ce sont en g
énéral sur l’initiative des groupes de projet qu’ils sont utilisés,
je pense qu’il aurait été intéressant que certaines UVs de développement à projet (type NF28, LO11)
se doten
t d’un système de type SVN et
l’imposent dans la gestion des projets de fin de s
emestre.

15


c)

Conventions et bonnes pratiques

Dans le cas de DGP, les conventions de développement (sur la façon de coder) ont été imposées à la
fois par le client, et par le principal architecte du projet. Celui
-
ci est particulièrement rigoureux sur la
format
ion des nouveaux arrivants, de manière à ce qu’ils développent en suivant les règles du projet.

Ici encore, c’est un équilibre qu’il faut trouver entre conventions de codage lourdes (par exemple le
typage des variables dans leur nom, comme
strNomDeVariable
), et les conventions de codage usuelles
et moins contraignantes (par exemple les majuscules sur les noms de classes). Il est amusant de
constater que les générations s’opposent un peu sur ce sujet. En effet, si les conventions de codage
avec le type de la

variable dans le nom étaient courantes et très pratiques dans les vieux langages (non
objet) dotés d’environnement de développement
simples
, elles peuvent paraître obsolètes à l’heure des
langages objet quasi
-
pur comme java, et des environnements de dével
oppement «

intelligents

»
comme Eclipse qui vont permettre de connaître très rapidement le type d’une variable.

d)

Tests unitaires

Les tests unitaires sont laissés à la charge du développeur, c’est à lui de s’assurer que ce qu’il
développe fonctionne, de sort
e que le nombre d’anomalie
s

présentes en phase de qualification soit
minimal.
Sous la pression des délais, ces tests unitaires sont parfois réduits à un strict minimum, mais
c’est u
n pari risqué, dans la mesure où

la gestion d’une anomalie en phase de qual
ification ou pire,
après un retour du client, est beaucoup plus longue à corriger (il faut se réapproprier le code, ce qui est
généralement plus long).

e)

Catégorisation des anomalies

La détection des anomalies (mauvais fonctionnement de l’application
) se
fait durant la phase de
qualification, durant les installations une fois l’application livrée chez le client, et dans le pire des cas,
en production, c'est
-
à
-
dire lorsque l’application est utilisée par les utilisateurs finaux.

Ces anomalies sont regroupées

en plusieurs catégories

:



Mineure
s

(anomalies visuelles discrètes, fautes d’orthographe). Ces anomalies sont
généralement discrètes et ne gênent pas l’utilisateur.



Majeures (anomalies visuelles importantes, erreurs de comportement, règle de gestion
manqua
nte, affichage de messages d’erreurs intempestifs). Ces anomalies provoquent une gêne,
mais l’application fonctionne.



Bloquantes (erreurs empêchant le fonctionnement de l’application). Ces anomalies empêchent
tout ou une partie de l’application de fonction
ner comme elle devrait.

Les anomalies majeures et bloquantes détectées après la phase de qualification (par SFR ou un sous
-
traitant de SFR) entraîne des sanctions auprès de Sopra. Les anomalies mineures sont corrigées et la
correction est faite pour la liv
raison

suivante
, il en va parfois de même pour les anomalies majeures.
En revanche les anomalies bloquantes impliquent une correction au plus vite, non détectées avant la
production (cas très rares), elles peuvent être catastrophique
s

et entraîner de très
lourdes pertes pour le
client, ou l’exploitant de l’application.

Dans le cas de SFR, un dysfonctionnement d
u système intranet paralyse la souscription de
nouveaux contrats, et représente de très lourdes pertes d’argent.

Ceci met en évidence l’importance de

la phase de qualification, ainsi que de la phase de pré
-
production (installation test chez le client).

16


f)

Journaux et logs

Les logs sont principalement utilisés pour vérifier le fonctionnement de l’application, ils permettent
de faciliter le débogage.

Ils ra
lentissent considérablement l’application (écriture sur le disque), c’est pourquoi l’équipe DGP
utilise
Log4J

qui permet de configurer les logs

: taille

maximum
, emplacement, format des lignes,
horodatage, niveaux de détails etc.

L’utilisation des niveaux

de détails va permettre de développer en prenant en compte les différents
stades de vie de l’application, le niveau
DEBUG

va par exemple permettre de simplifier le
développement, ainsi que la recherche de l’origine de problèmes (typiquement, si l’applicat
ion
rencontre un problème en pré
-
production, et que l’équipe DGP n’arrive pas à déterminer la source du
problème avec les explications de l’équipe qui gère la pré
-
production, ceux
-
ci vont modifier le niveau
de logs et envoyer les résultats). Le niveau ERRO
R va permettre de
superviser
les erreurs, ces erreurs
vont être rem
ontées automatiquement à l’équipe en charge de l’exploitation, qui saura quelles mesures
prendre. Différents niveaux d’erreurs intermédiaires peuvent être utilisés selon les situations.


g)

Le

processus d’intégration des applications SFR

Le processus d’intégration chez SFR se fait en plusieurs étapes, le processus habituel de mise en
production d’une application se fait avec une pré
-
production puis une mise en production. Chez SFR,
les contrain
tes de disponibilités et de fonctionnement font que plusieurs étapes sont nécessaires avant
la mise en production. Au cours de ces étapes, des erreurs peuvent être remontées à Sopra. Les
configurations de l’application vont varier, Sopra ne dispose pas des

services ni des données SFR,
mais des spécifications de fonctionnement, la plupart des sous
-
systèmes applicatifs sont uniquement
simulés pour le développement et les tests.



17


3.

Organisation de la qualification

: Quality Center

Quality Center (de Mercury, un
e filiale de HP)
est l'environnement de
q
ualification utilisé depuis
peu chez Sopra. Il permet :



de référencer et automatiser les tests,



de faciliter la communication entre les différents acteurs du projet,



de standardiser et gérer l'intégralité du process
us de qualification.

Quality Center est décomposé en 3 interfaces, les
Requirements
, le
Test Plan

et le
Test Lab
. Les
requirements

vont définir les exigences auxquelles devront répondre les tests, ces exigences
correspondent aux fonctionnalités décrites d
ans les spécifications. Dans le test plan, des lots de tests
sont définis, ces lots correspondent à une série de test qui va répondre à une exigence des
requirements
.
Dans le test lab, les scénarios de test (ou fiches de tests, voir
fig. 3
) sont décrits et organisés dans une
arborescence selon les fonctionnalités qu’ils couvrent.


fig. 3.

Une fiche de test Quality Center

Un exemple de test

:

1.

S’authentifier auprès de l’accueil client

2.

Accéder à la page de recherche client

3.

Rechercher le client Jean DUPONT

4.

Ouvrir la fiche de test trouvée et vérifier que le prénom affiché est bien «

Jean

»

Une partie
Anomalies

liste les anomalies recensées, en les reliant aux tests durant lesquels elles on
t
été découvertes. Cette partie est consultée régulièrement par les développeurs pendant la phase de
qualification, pour prendre en charge les corrections le plus rapidement possible.



18


4.

Documentation et gestion des connaissances

a)

Documents

La documentation
du projet est un des pans importants d’un projet, la documentation de DGP se
compose
principalement
des fichiers suivants

:

Le MUT, le manuel utilisateur, destiné au client pour qu’il connaisse les comportements attendus de
l’utilisateur.

Le
MIS
, manuel d’
installation, destiné au client pour qu’il puisse installer l’application sur ses
serveurs (l’installation n’est pas faite par l’équipe DGP)

Les SFG, spécificat
ions fonctionnelles générales,
un des documents les plus importants, il va servir
de référence p
our les développeurs et le client, il décrit les fonctionnalités de l’application.

Les SFD, spécifications fonctionnelles détaillées, détaillent chacune des règles de gestion qui sont
utilisées par l’application pour aboutir au fonctionnement (voir la sect
ion
Nommage des règles de
gestion
).

Le DAT, dossier d’architecture, spécifie l’architecture utilisée par l’application, aussi bien
technique (technologies, protocoles), que matérielle (espace disque, puissance et mémoire requises).

Les DSI, ou dossiers de
spécification d’interface, vont décrire exhaustivement les interfaces de
chacun des services de l’application destiné
s

à être utilisé
s

par d’autres applications via
des protocoles
de communication

(webservice sur HTTP, xml sur file MQSeries, etc.)

Les
FEX/
MEX
, fiches d’exploitation et manuel d’exploitation, sont destinés aux personnes chargé
e
s
de l’exploitation de l’application, pour gérer les cas de panne, les routines de maintenance, et toutes les
situations exceptionnelles.

b)

Nommage des règles de gestion



Nomenclature

Champ

Type

Description

ACC0F01T02R01

Eléments de
formulaire

Saisie
utilisateur

Tous les caractères saisis par l’utilisateur sont
automatiquement mis en
majuscule

sur le poste client.


Ce contrôle
FRONT OFFICE

est

réalisé dynamiquement lors
de la saisie de l’utilisateur par l’intermédiaire de masque de
saisie.


fig. 4.

Une règle de gestion dans les SFD

Les règles de gestion se présentent comme sur la
fig. 4
, la nomenclature est la suivante

:



ACC0 : Domaine 0



F01 : Fonction 01



T02 : Traitement 02



R01 : Règle 01

Cette nomenclature est reprise dans le nommage des fiches de test du plan de
qualification.



19


c)

Gestion des connaissances

La gestion des connaissances est encore très sommaire sur le projet DGP, c’est un travail qui
demande un certain temps, mais le temps gagné lors de la recherche d’une information par la suite
compense largement le

temps passé à rédiger. DGP s’est tout récemment doté d’un Wiki, où tout le
monde peut contribuer, cet outil est encore à ses débuts, mais il fera gagner un temps considérable aux
nouveaux venus sur le projet, ou aux personnes qui se chargeront d’effectuer

une évolution sur un
domaine de DGP dont ils n’ont pas l’habitude.

C’est un des points faibles du projet de mon point de vue, mais l’équipe projet a pris conscience de
cette faiblesse et le wiki devrait largement la réparer d’ici quelques mois. Ce type de

système de
gestion de connaissances est d’autant plus important que l’équipe est séparée sur deux sites (Rennes et
Paris), et qu’il n’est pas toujours pratique de téléphoner ou de déranger quelqu’un pour avoir une
information qu’il aurait suffit d’écrire
une fois pour toute
s

sur le wiki.

La communication interne au
-
delà de l’espace de travail se fait via téléphone ou email, il manque
chez DGP un système de messagerie instantanée, à l’image de celle utilisée par SFR dans le projet TIC
(la suite Office Commu
nication de chez Microsoft). Durant certaines phases difficiles du projet
EDEN (qualification sur Rennes et Paris, 5 personnes), le nombre important de redémarrage
s

nous a
poussé à installer une messagerie Jabber
1
, qui s’est avérée très pratique pour comm
uniquer rapidement.
Cependant ce type d’installation à l’échelle de l’équipe DGP n’a jamais été décidé, malgré l’existence
d’un serveur Jabber sur l’intranet.






1

http://www.jabber.org

20


C.

Architecture et fonctionnement du portail DGP

L’intranet distributeur

est un ensemble d’applications offertes aux distributeurs. Ces applications,
ou sous
-
systèmes applicatifs, sont complémentaires et communiquent entre elles par divers protocole.
L’architecture globale de l’intranet distributeur est relativement complexe,
et pour ce stage, le point de
vue de DGP suffit (certains SSA ne sont pas utilisés directement par DGP) voir la figure ci
-
dessous,
qui schématise le fonctionnement de DGP.


fig. 5.

Schéma simplifié de DGP

La fonction principale du portail est de fournir un point
d’accès au distributeur (voir section
DGP en
résumé
).

Les principales applications avec lesquelles le portail s’interface sont

:



Les annuaires

qui contiennent les informations des distributeurs

et des internes
(AUD et AUI,
annuaires universels distributeu
rs et internes)



Les bases de données d’informations client Clarify/SIGC



ORIAN, qui regroupe de nombreuses informations liées à l’application et aux clients (parfois
redondantes avec SIGC)



L’application de vente et de souscription (V&S), qui va permettre au

distributeur de réaliser
des actes de gestion sur le compte du client (comme lui souscrire une offre, lui ajouter une
option, etc.).



L’application SSO Siteminder
2
??TXL?SHUPHW?GH?SDVVHU?G¶XQH?DSSOLFDWLRQ?j?O¶DXWUH?DYHF?XQH?VHXOH?
authentification.






2

http://www.netegrity.com/france

21


1.

Quelque
s données techniques sur l’architecture



DGP fonctionne sur un serveur Sun Solaris



L’ensemble du développement se fait en JAVA/J2EE



serveur d’application IBM WebSphere



Le développement sur fait sur BEA WebLogic (en cours de migration partielle vers Eclipse
)



Les flux entre applications se font en http, IBM MQSeries sur JMS, et WebServices

Le principal avantage du Java est la portabilité,
le code

est identique

entre l’environnement de
développement et le
serveur de qualification / production. Seule la configu
ration va varier.

2.

L’authentification

La mire de login de DGP permet des accès depuis 3 origines

:



Intranet



Internet



Extranet

Ces origines correspondent au mode de connexion et au type d’utilisateur, qu’il soit interne SFR ou
distributeur, et vont également

varier selon le type de distributeur.

La sécurité est plus ou moins renforcée selon les risques, ainsi un client intranet est sur un réseau
qui est considéré comme plus sûr, le contrôle à l’entrée est
réduit

: c’est une mire à 2 champs qui ne
nécessite qu
e le numéro et le mot de passe du point de vente.

En revanche pour internet et extranet, une calculatrice (petit boîtier qui génère des clefs
d’authentification)
est utilisée

po
ur sécuriser l’authentification, voir mire de connexion
interne
t/extranet
ci
-
dessous (KARA est le nom de l’intranet des distributeurs).



fig. 6.

Mire de connexion à 3 champs



22


3.

Le portail

Le portail est une page qui permet d’accéder aux applications pour lesquelles l’utilisateur est
habilité, notamment l’accueil client.

4.

L’accueil clie
nt

L’accueil client permet de consulter et de modifier un compte client, l
a recherche permet au
distributeur de rechercher le compte d’un client déjà existant, o
u d’en créer un le cas échéant.

Les fiches clients donnent accès aux actes de gestion disponib
les pour le client concerné, selon les
types d’abonnement du client,
ces actes permettent de faire des


«

débranchements

», ou passages de
contextes à d’autres sous
-
systèmes applicatifs de DGP, la fiche client ne se chargeant que des liens
vers

ces sous
-
sy
stèmes applicatifs.

En guise d’exemple, voici le cas de la souscription à une nouvelle offre

:



Le distributeur clique sur l’acte de gestion correspondant à la souscription.



La fiche client commence le passage de contexte en envoyant à l’application V&S un

entête
http contenant un nombre minimum d’informations.



Un échange sur une file MQ (file de message) se fait entre l’accueil client et V&S pour passer
les informations du client nécessaires à V&S.



Le distributeur arrive sur une page de souscription de l’a
pplication V&S sans s’y être
authentifié

(grâce au SSO).



Cette page de souscription à l’offre est pré
-
remplie avec les informations obtenues par le
passage de contexte, le distributeur n’a plus qu’à vérifier puis valider la souscription.

Dans toute la procédure de souscription, à partir du moment où le client existe déjà, les seules
informations entrées par le distributeur auront été les informations permettant de retrouver la fiche du
client

: le distributeur y gagne en productivité.

Mon

développement sur l’accueil client a principalement concerné les fiches, mais j
’ai eu à réaliser
sur la page de recherche quelques petites modifications d’ergonomie, ceci illustre le fait que de temps
en temps on soit amené à travailler sur une partie du
projet qui n’est pas au cœur de son travail (en
général le front office est réservé à un membre de l’équipe

spécialisé
), mais il arrive qu’en fonctions
des urgences ou des indisponibilités des uns ou des autres, on ait à travailler sur un terrain inhabitue
l.
De nombreuses fois mon stage m’a prouvé que la polyvalence et la capacité à s’adapter est une des
principales qualités que doit posséder un ingénieur en informatique.

Le fait d’avoir des connaissances dans de nombreux domaines est utile également par l
a suite dans
le cadre de la gestion de projets (chef de projet par exemple), afin de pouvoir correctement chiffrer le
temps de travail nécessaire pour les différentes tâches, et d’optimiser les plannings.



23


D.

Le projet TIC

Le TIC, ou projet TIC (tests d’int
égration cœur), est un projet de SFR qui vise à réaliser une
installation de l’intranet des distributeurs intégrant l’ensemble des applications mises à jour.

L’objectif du TIC est de s’assurer que les applications communiquent bien entre elles, le
dévelop
pement de chaque application s’étant fait sur la base de DSI et de simulateurs, il arrive que les
DSI aient été incomplets ou mal interprétés. La difficulté pour les développeurs
est

de s’en rendre
compte puisqu’ils ne disposent pas des applications pour r
éaliser des tests deux
-
à
-
deux en interne.

Le TIC se déroule dans des locaux de SFR réservés aux prestataires, un certain nombre de serveurs
sont dédiés à l’installation des applications (elles fonctionnent
toutes
sur des systèmes Solaris)
.

1.

Le rôle de l’éq
uipe portail au TIC

a)

Installation et tests
de DGP

DGP est un des composants centraux de l’intranet, c’est le point d’entrée sur l’intranet des
distributeurs. Pendant le TIC, de nombreuses erreurs de communication entre les applications ont été
décelées grâc
e aux tests 2 à 2.

Dans ce cas de figure, il faut déterminer l’origine du problème pour déterminer quelle application
doit être corrigée. L’erreur peut également provenir du DSI qui décrit l’interface entre ces deux
applications, dans ce cas la correction
doit se faire d’un commun accord entre les équipes des deux
applications et de SFR.

Un des plus gros problèmes dans la correction d’erreurs décelées au TIC était de réussir à
reproduire le problème dans l’environnement de production.

Durant le TIC mon rôl
e a été de remplacer un des ingénieurs devant se rendre sur place, les objectifs
qui m’étaient fixés
étaient

les suivants

:



Représenter l’équipe portail au TIC



Détecter les anomalies et corriger les éventuelles erreurs de configuration



En cas d’erreur dans

l’application elle
-
même, diagnostiquer son origine, ainsi que le moyen de
la reproduire



Fournir des comptes
-
rendus de l’a
vancement de l’installation et de la correction d’erreur aux
responsables du projet TIC

b)

Configuration des simulateurs SSO

SFR a confié une mission supplémentaire à l’équipe portail

: en plus du développement de l’accueil
client, l’équipe a été chargée de la mise au point d’un simulateur de SSO. Celui
-
ci était destiné
uniquement au TIC, en effet, l’application Siteminder qui s
e charge du SSO n’est installée qu’en
production.

J’ai été chargé de la configuration des simulateurs SSO (appelés familièrement «

bouchons

») pour
le TIC, ainsi que de l’ajout de fonctions supplémentaires à ce simulateur (voir section «

simulateur de
SSO

» plus loin).



24


c)

Résultats du TIC

SFR a investi beaucoup d’argent dans ce projet, mais ces tests leur ont certainement permis
beaucoup d’économie
s
, étant donné le nombre d’anomalies trouvées dans les différentes applications.
Peu d’anomalies ont été
trouvées sur DGP, mais la correction

de celles trouvées

ont en revanche
demandé un temps de correction assez long (erreurs d’interprétation du DSI).

Le TIC a été pour moi une expérience très intéressante, puisque j’ai pu me rendre chez le client en
tant qu
e prestataire, et voir le projet sous un autre jour que celui du développement ou de la
qualification. Ce fut une très bonne expérien
ce de communication, et j’ai apprécié de me voir confier
de telles responsabilités malgré mon statut de stagiaire.

E.

Développ
ement de simulateurs de services dans le cadre de
DGP

1.

Problématique

Pour le développement de l’accueil client, il est nécessaire de simuler les services avec lesquels il
communique.

Il est impératif pour les développeurs de pouvoir vérifier que les messag
es envoyés par l’accueil
client aux autres services

sont bien formés

; de la même manière, il faut pouvoir vérifier que les
messages reçus des autres par l’accueil client sont bien interprétés.

2.

Principe des simulateurs

Les simulateurs ont pour objectif de
reproduire les réponses que feraient les services simulés
, afin
de tester les messages so
rtants et les messages entrants, ce sont des applications à part entière qui
tournent sur un serveur. Il est important de noter que les simulateurs n’ont pas pour obje
ctif de simuler
intégralement l’application, uniquement le flux, c'est
-
à
-
dire que les réponses sont parfois incohérentes
par rapport à ce qui se produirait avec une vraie application, le but étant

simplement de tester
l’échange (voir figure ci
-
dessous).


fig. 7.

Principe d’un simulateur

pour l’accueil client

Prenons l’exemple d’un simulateur de SIGC (l’application qui gère la base de données des
informations client), SIGC est capable de renvoyer un ou plusieurs résultats selon l
a recherche

: pour
Accueil Client

Simulateur

Jeux de données

Question

Réponse

25


une recherche portant sur le nom il peut y avoir plusieurs résultats, alors que pour une recherche
portant sur un numéro de carte SIM, seul un résultat peut exister. Dans le cas du simulateur il n’est pas
impossible que celui
-
ci renvoie
plusieurs résultats sur une recherche qui ne devrait en renvoyer qu’un.
En effet, le simulateur a un certain nombre de réponses prévues à l’avance, qui correspondent à des
questions prédéfinies, il n’y a pas de mécanisme de recherche.

En d’autres termes,
si le simulateur reconnaît une question qu’il a dans ses jeux de données, il
répond la r
éponse qui lui a été prédéfinie, alors que l
e vrai fonctionnement de SIGC serait une
recherche dans toute une base de données.

Les jeux de données doivent permettre de
couvrir
l’ensemble des tests de la qualification.


3.

Simulateur de SSO

Certains simulateurs sont plus complexes qu’un simple simulateur «

Question/Réponse

», même
s’ils conservent le même principe de question/réponse et jeux de données, ils peuvent être doté
s de
fonctionnalités qui les rapprochent plus de l’application qu’ils simulent, c’est le cas du simulateur de
SSO.

a)

Principe et existant

Dans l’intranet distributeur, l’accès à chacune des applications est protégé. Chaque application peut
être utilisée indé
pendamment des autres, mais la plupart du temps le distributeur va naviguer entre
plusieurs applications et utiliser les mécanismes de débranchement et de passage de contexte.
Le SSO
permet d’éviter au distributeur d’avoir à se connecter à chaque applicati
on, cependant ce SSO n’est
pas disponible au TIC, c’est pourquoi SFR a demandé à l’équipe portail de Sopra de réaliser un
«

bouchon

», qui permettra de mimer le comportement d’un SSO pendant les tests du TIC.

Le bouchon SSO a été développé plus d’un an ava
nt le début du TIC, il a été délaissé car peu utilisé
pour le développement, à l’approche du début du TIC, certaines fonctionnalités se sont avérées
manquantes, notamment l’utilisation d’un LDAP à la place de fichiers

texte pour la gestion d’une
partie des

jeux de données.



26


b)

Architecture de la solution

Le fonctionnement du bouchon SSO avant que je ne le reprenne en main était le suivant

:


fig. 8.

Fonctionnement du bouchon SSO

Le bouchon va consister en une sorte de serveur http qui va relayer les requêtes si l’ut
ilisateur est
authentifié par une session, et lui présenter une mire de login s’il n’est pas identifié.

Les requêtes
relayées sont enrichies d’entêtes http identiques à
ceux

qui seraient mis


par l’application Siteminder
simulée.

L’authentification se prés
ente de la même manière que pour DGP et les autres applications de
l’intranet

(nombre de champs de la mire selon la provenance du distributeur). Il est donc nécessaire
pour cette solution d’installer et de configurer un bouchon SSO pour chacune des applica
tions, et dans
chacun des modes de connexion (au TIC, seuls l’intranet et l’internet sont testés, pas d’extranet).

L’authentification se fait avec les
jeux de données

: des fichiers textes qui contiennent les
combinaisons de valeurs possibles des champs de

la mire.

Chaque application de l’accueil client est capable de reconnaître les entêtes http envoyés par
S
iteminder, les requêtes enrichies avec les entêtes du bouchon vont faire en sorte que l’application
concernée fasse une authentification silencieuse.

Le principal inconvénient de cette solution est le mode de fonctionnement du serveur http, en effet à
chaque débranchement d’une application vers une autre, un nouveau bouchon est ajouté en relai. Cet
inc
onvénient n’est pas vraiment gênant
étant donné que
les tests du TIC vont se limiter à des
navigations de l’accueil client vers une application (par exemple de l’accueil client vers la vente et la
souscription), il n’y aura donc qu’un maximum de 2 bouchons en même temps.

Chaque installation du bouchon doit être configurée en fonction des URLs de chaque application,
du mode de connexion,
et
des paramètres du LDAP
entres autres
. Pour que l’autologin soit effectif, les
installations du bouchon doivent partager un même réperto
ire de fichiers de sessions.

27




c)

Evolutions

La première évolution que j’ai faite sur le simulateur SSO a été l’ajout d’une fonctionnalité LDAP,
cette fonctionnalité permet une authentification via soit LDAP, soit les fichiers texte. Ceci permet
d’utiliser u
n jeu de donnée partagé avec celui de l’application simulée, tout en simplifiant la création
de nouveaux utilisateurs au niveau du bouchon. La principale difficulté a été d’intégrer cette évolution
en modifiant au minimum le fonctionnement du reste du bouc
hon, ce qui n’a pas été très facile étant
donné le nombre important de paramètres qui sont réutilisés du LDAP, et qui avant étaient communs à
tous les utilisateurs sur le fichier texte. La difficulté résidait également dans l’architecture un peu
anarchique

(le bouchon a été crée sur la base d’un serveur http modifié), qui s’est révélée très peu
pratique pour trouver où faire les modifications et les ajouts.

Le deuxième ajout a été fait pendant le TIC

: pouvoir paramétrer les entêtes envoyés, et le format
de
s entêtes selon l’application concernée. Cet ajout a été motivé par les difficultés rencontrées sur
l’interprétation des entêtes http fai
ts

par les autres applications que DGP (qui n’avaient pas de SSO
pour tester). Durant le TIC, il est également apparu q
ue le nom de domaine sur lequel poser les
cookies qui permettent le débranchement devait être paramétrable, ce qui n’était avant pas le cas et
posait un certain nombre de problèmes.

4.

Simulateurs de services génériques benchmark

a)

Problématique

Pour pouvoir
réaliser des tests de charge sur ses applications de l’intranet distributeur, SFR a
exprimé à Sopra le besoin d’avoi
r des simulateurs de benchmark

;

il faut que chaque service avec
lequel communique l’application à tester soit bouchonné, avec des bouchons
dont le temps de réponse
soit le plus petit possible, et capables de supporter jusque 30.000 requêtes à l’heure (une moyenne de 8
requêtes par seconde).

b)

Objectifs

Les objectifs sont multiples, voici un résumé du cahier des charges des bouchons

:



Temps de r
éponse minimum (dans tous les cas inférieur à 2 secondes).



Charge importante, 30.000 requêtes par heure.



Bouchons génériques

: chaque service doit être facilement implémentable.



Stand
-
alone

: les bouchons doivent pouvoir être lancé sans moteur de servlet o
u moteur
d’application.




Pas d’installation

: seulement une configuration.



Capables de supporter des messages sur les protocoles MQSeries, et au format WebService.



Les jeux de données peuvent être réduits, mais ils doivent pouvoir être possible d’ajouter d
es
données facilement.

c)

Architecture choisie

La première partie de la création de ces bouchons a été réalisée par Arnaud Penvern, il s’est chargé
de modifier un simulateur déjà existant (annuaires universels), pour l’adapter à nos besoins, et créer un
simul
ateur générique. Avec l’aide d’un architecte, ils ont convenus d’utiliser des fichiers textes à la
place des bases de données habituellement utilisées pour les simulateurs. L’inconvénient des bases de
données est que le maintien de l’ensemble des jeux de d
onnées est assez laborieux, et l’insertion des
jeux de données demande une bonne connaissance du fonctionnement de la base

; de plus les fichiers
texte doivent permettre d’accroître la réactivité du simulateur.

28


Nous avons décidé de séparer l’architecture d
u simulateur en deux architectures distinctes, selon les
protocoles utilisés (MQSeries et Webservice), le mécanisme de gestion de la réception des messages
étant très différents. Arnaud a réalisé les simulateurs MQ en adoptant l’architecture suivante

:


fig. 9.

Architecture des bouchons performance génériques MQSeries


(
schéma
fait

par A.Penvern
)



MQSeries

Bouchon

Parseur

Recherche

Communication

Thread

Thread

Listen
er

Thread

Thread

Thread

Portail DGP

Annuaire

Annuaire

File de question

File de réponse

Répertoire de stockage des
fichiers






0600000001_0001024595_10000.xml


0600000002_0001024595_0.xml


0600000003_0001024595_0.xml


0600000001_0001024596_10000.xml


0600000002_0001024596_0.xml


0600000003_0001024596_0.xml


0600000004_0001024596_0.xml


0600000005_0001024596_0.xml




29


Etant donné le nombre important de services à simuler en utilisant ces bouchons, l’accent a été m
is
particulièrement sur la généricité

: ces bouchons doivent non seulement permettre à des non
-
développeurs d’ajouter simplement des jeux de données et de les faire fonctionner, mais ils doivent
également permettre à des développeurs d’ajouter de nouveaux
services sans avoir à connaître le
fonctionnement du bouchon, c’est pourquoi nous avons choisi d’adopter une architecture en plusieurs
parties distinctes

:



Procédure principale (écoute des messages, et lancement des procédures de traitement)



Procédure de t
raitement d’un message (parser et récuperation de la réponse en fichier texte)



Procédure de réponse

L’objectif étant que la création d’un nouveau service géré par le bouchon se fasse simplement en
ajoutant une classe dans la procédure de traitement, et en
modifiant un fichier de configuration.

La procédure de traitement a un fonctionnement simple (voir
fig. 9
)

:



Le contenu du message est reçu depuis la procédure
principale (qui a lancé un traitement)



le
parser

du service simulé lit le message



les informations extraites par le
parser

sont listées



La liste de ces informations détermine une unique réponse qui est envoyé à la procédure de
réponse

Un
parser

est lié à u
n service simulé, ainsi le même bouchon va permettre de simuler autant de
se
rvices qu’il y a de parsers,
chacun des services doit disposer de son jeu de données.

Java a été choisi pour implémenter cette architecture, ce choix est contestable en termes de
p
erformances, on aurait pu lui préférer le C++, mais les délais de livraison, la grande portabilité et les
habitudes de développement ont finalement fait pencher pour la combinaison Java/Eclipse.


d)

Création d’un parser

La création d’un parser se fait sur la
base du DSI du service concerné, le parser a pour fonction
d’extraire les informations utiles à la détermination de la réponse à renvoyer (certaines informations
du message seront ignorées).

Selon la nature du message (XML ou texte), le parser sera différe
nt, mais il doit disposer d’un
certain nombre de méthodes pour être utilisable par la procédure principale, (il implémente donc une
interface prédéfinie).

e)

Création d’un jeu de données

Les jeux de données fonctionnent sur un principe simple

:

La liste des c
ritères utilisés pour le choix de la réponse est dans le nom du fichier réponse, celui
-
ci
contient la réponse qui doit être envoyée (et uniquement celle
-
ci).

Sur la base du DSI du service à simuler, on va donc créer un fichier d’aide à la création de jeux
de
données. La solution la plus simple s’est avérée être d’utiliser un tableur doté de quelques macros
rudimentaires (nécessaires pour le remplissage et le formatage du message).

30


f)


g)


h)

Créer un service

La création d’un service va donc se faire de la manière su
ivante



Création du parser



Création d’un fichier d’aide à la création de jeux de données (tableur)



Création de jeux de données



Configuration du bouchon pour qu’il prenne en compte le nouveau service.

i)

Partie

WebService

Il a fallu étendre les principes d’un
bouchon déjà existant, pour faire un bouchon générique MQ,
techniquement le plus difficile a été d’implémenter la généricité et les mécanismes de récupération de
fichiers, la création d’un listener MQ étant bien maîtrisée.

En revanche pour la partie webser
vice du bouchon, la difficulté consistait en la reproduction d’un
certain nombre de mécanisme
s

d’un webservice, tout en
l’
adaptant
à
l’architect
ure du bouchon de
performance (aux

trois procédures

: principale, traitement et réponse).

La création d’un webse
rvice
est relativement simple en java

en utilisant un moteur de servlet
comme TomCat, cependant on aurait dans ce cas supprimé la notion d’exécution
stand
-
alone
,
puisqu’il aurait fallu déployer le simulateur sur le moteur de servlet.

La seule solution a do
nc été de redévelopper les mécanismes de base de communication des
WebService, afin de pouvoir les adapter aux besoins du simulateur. La solution a donc été une routine
principale qui écoute sur un port l’arrivée de message, et utilisant des mécanismes de
thread

pour
démarrer les procédures de traitement
.

De ce fait, il a fallu redévelopper un serveur http simplifié pour interpréter le contenu du message,
et faire en sorte que le bouchon soit ensuite capable d’interpréter les enveloppes SOAP, et
d’en
extra
ire le message (soit un

parsing HTTP,
un

parsing SOAP, et enfin le parsing du service

concerné
).
Le bouchon doit ensuite refaire la procédure inverse pour produire un message HTTP sur

la base du
message de réponse, il doit donc faire une enveloppe SOAP, pu
is une enveloppe HTTP
.

Le tout devant se faire en utilisant des procédures les plus simples possibles pour optimiser la
vitesse de traitement.

Les nombreuses UVs de la filière ICSI traitant du XML m’ont beaucoup aidé dans cette tâche, en
me donnant une bo
nne vision d’ensemble des technologies XML utilisées par un webservice (XML
schéma et SOAP notamment).

Le reste du fonctionnement est similaire à celui utilisé par la partie MQSeries du bouchon
performance, ce sont les mêmes interfaces qui sont utilisées,
de cette façon l’ajout d’un service pour le
bouchon de performance est identique en Webservice, seule la configuration va varier. Le schéma
général du fonctionnement du simulateur benchmark est représenté
fig. 10
, la partie communication va
varier entre les versions MQ et Webservice, en revanche le parser et la recherche utilisent le même
mécanisme.


31



fig. 10.

Fonctionnement du simulateur
performance

VII.

Le projet FOOT+

A.

Contexte

du projet

Le client de ce projet est Canal+, ce projet est le 2
ème

confié à Sopra. Comme Canal+ est un nouveau
client, Sopra fait quelques concessions.

Canal+ a exprimé le besoin de
pouvoir
diffuser
l
es matchs de L1

(football)

en streaming sur internet.
L
es droits sur les matchs de L1 sur internet sont répartis entre Orange et Canal+, Orange a développé
un système similaire
. La particularité de ce projet est qu’il a été démarré très tard (démarrage du projet
début juin, la L1 démarrant début août).
Ce qui
fait environ de début juin à mi
-
juillet pour la
réalisation (soit de mi
-
juin à début juillet pour le développement).

Cette particularité a
eu

de nombreuses conséquences sur le mode de développement.


B.

Acteurs du projet

1.

Sopra

Sopra a dû monter très rapidemen
t une équipe disponible et capable de prendre en main le projet.
La
division Télécom prend en charge les projets liés aux médias, aussi l’équipe
a été composée de
personnes issues de projets Télécom (VPN SFR, et Portail), la composition est la suivante

:



U
n directeur de projet



Un chef de projet



Un responsable fonctionnel



Un architecte



Un intégrateur HTML



Deux développeurs

(mon rôle)

32


Dans les petits projets, les tâches sont moins cloisonnées, ce qui m’a permis d’avoir un bien
meilleur point de vue sur les
métiers de chef de projet, d’architecte et de responsable fonctionnel. Ce
projet m’a permis de clarifier les évolutions professionnelles que je pourrais suivre dans mon métier
d’ingénieur.

2.

Canal+

Canal+ a rempli le rôle de la maîtrise d’ouvrage, cependant
contrairement à des projets comme
DGP où le maître d’ouvrage pilote le projet de loin, les contraintes de délais ont obligé Canal+ a
s’impliquer très fortement et à être très disponible pour le projet, la rédactions des spécifications
n’ayant pas été faite

avant le démarrage en juin. Cette façon de procéder se rapproche de la
«

méthode
agile

»
, le principal objectif étant d’obtenir une réactivité maximum du client
,

afin de

minimiser les
pertes de temps dues à des
manques d’information.


Ce projet est donc t
rès différent du projet portail, puisque les décisions

et échéances

sont à très court
terme.

3.

Akamai

Akamai héberge et fournit les flux vidéo qui vont être diffusés par Foot+, Akamai est également
responsable de la
création des DRMs,
mais
c’est Foot+ qui le
s distribue auprès des utilisateurs
habilités.

4.

Jet

Jet est l’entreprise responsable de l’hébergement du site Foot+, c’est dans les locaux de Jet (sur un
serveur qu’ils fournissent) que se fait l’installation du site.

C.

Objectifs

Les objectifs sont différents

de DGP, dans le cas du projet Foot+, le principal objectif est de réussir
à rendre le site fonctionnel pour le début de la ligue1. Les choix techniques ont souvent été portés vers
la rapidité de développement plutôt que des solutions plus longues mais pl
us évolutives.

La perspective d’une généralisation vers une plateforme de streaming a été posée par Canal+
(notamment la possibilité de réutiliser le site pour un futur site Rugby+).

Les objectifs sont donc les suivants

:



Fournir un site capable de diffu
ser les matchs de L1 pour début août 2008 (2 mois de
projet,
soit un mois de développement seulement
)
.



Intégration du site dans l’ensemble des sites Canal+ (notamment la gestion des offres, des
logins et du SSO Canal+)
.



Intégrer la L1, puis permettre l’ajo
ut d’autres ligues par la suite (notamment la Champion’s
League).



Développer de manière à ce que le site puisse évoluer vers une forme plus générique de site de
streaming d’activités sportives.



Jusque 400 requêtes par seconde et 60.000 matchs diffusés dans

un weekend.

L’équilibre doit donc se faire entre la rapidité de développement, l’évolutivité, et les performances.

D.

Travail sur le projet Foot+

Contrairement au projet DGP, j’ai pu avoir une vision d’ensemble sur ce projet, puisque j’y ai

participé depuis le démarrage.

33


1.

A
rchitecture

Les choix d’architecture se font fait via des discussions entre les membres de la partie technique de
l’équipe (architecte et les développeurs). J’ai eu la chance de participer aux différents choix techniques
d
ont

voici un résumé

:



Le choix de la plateforme et les besoins matériel
s

(le système Red Hat était imposé par
l’hébergeur)



Langage

:
PHP5 avec le Framework Zend
3

(PHP Objet)



Logiciels

:
Apache, MySQL, OpenSSL



Technologies

:
Combinaison de Flash et de Windo
ws Media Player pour la gestion du flux
vidéo et des DRMs



Développement avec WampServer
4

2.

Mise en place du poste de développement

J’ai eu pour responsabilité de mettre en place le poste de développement, c'est
-
à
-
dire un
environnement de développement pour l
e projet, qui est installé sur le poste de chacun des membres
de l’équipe.

Cela implique

:




le choix des logiciels



l’architecture de l’installation sur le poste



la création d’un dépôt SVN



La configuration du poste (serveur web, base de données, php)

3.

Réalis
ation du processus d’authentification

Ma principale responsabilité dans le développement du site Foot+ a été la réalisation du processus
d’authentification, ainsi que la gestion du SSO Canal+.

Les connaissances que j’ai acquises durant le TIC notamment sur

le fonctionnement du SSO m’ont
beaucoup aidé dans la réalisation du SSO Foot+.

4.

WebService

: client et fournisseur en php

De la même manière, le fait d’avoir eu à développer un bouchon webservice

m’a aidé à la rédaction
de la WSDL des webservices client et

fournisseur de foot+, ainsi qu’à leur développement. Même si
depuis PHP5, l’interface du webservice est simple à réaliser à partir du moment où la WSDL est
complète.







3

http://framework.zend.com/

4

http://www.wampserver.com/

34



fig. 11.

Page d’accueil d
e Foot+

E.

Conclusion sur le projet Foot+

Le projet Foot+ a été une
très bonne conclusion à mon stage, il m’a permis de confronter des
technologies différentes dans l’utilisation et le développement de mécanismes clefs des systèmes
d’informations. L’expérience que j’ai acquise avec mon travail sur DGP m’a aidé à prendre e
n

main ce
projet difficile.

Le projet est actuellement en production à l’adresse
www.footplus.fr

(voir capture d’écran).


35


VIII.

Bilan du stage

D’un point de vue professionnel, ce stage m’a beaucoup apporté, j’y ai découvert

le métier
d’ingénieur dans les systèmes d’information, ainsi que les postes vers lesquels je pourrais évoluer. J’ai
eu la chance de travailler avec des ingénieurs très compétents, qui m’ont aidé à progresser et qui ont su
partager leurs connaissances. J’a
i découvert le milieu des services, très différent de mes autres
expériences professionnelles. J’ai également découvert le travail dans les systèmes d’informations, et
je ne regrette pas d’avoir choisi cette filière, après avoir longuement hésité avec les
systèmes et
réseaux.

D’un point de vue
technique, j’ai beaucoup appris

:

des technologies, des
processus
, mais aussi des
méthodes, des façons de gérer mon temps, de gérer mes priorité
s
, ainsi que la communication en
entreprise. J’ai apprécié le fait de toujours être traité comme un ingénieur et non pas
comme
un
stagiaire, de m’être vu confier des responsa
bilités et des tâches critiques, d’avoir pu participer aux
décisions.
Au niveau per
sonnel je suis ravi du stage, l’ambiance au travail a été remarquable, elle a
grandement facilité mon intégration à l’équipe

et au projet.


Ces 6 mois chez Sopra ont débouché sur une proposition d’embauche, mais j’ai choisi de la décliner,
car si ce travai
l m’aurait beaucoup plu, j’ai en revanche eu plus de mal à m’habituer au mode de vie de
Paris.




36


IX.

Table des illustration
s


fig. 1.

Organigramme de l’équipe Portail

9

fig. 2.

Système de pilotage Sopra

13

fig. 3.

Une fiche de test Quality Center

17

fig. 4.

Une règle de gestion dans les SFD

18

fig. 5.

Schéma simplifié de DGP

20

fig. 6.

Mire de connexion à 3 champs

21

fig. 7.

Principe d’un simulateur pour l’accueil client

24

fig. 8.

Fonctionnement du bouchon SSO

26

fig. 9.

Architecture des bouchons performance génériques MQSeries

28

fig. 10.

Fonctionnement du simulateur performance

31

fig. 11.

Page d’accueil de Foot+

34




37


X.

Glossaire des a
cronymes

AUD

:

Annuaire universel des distributeurs, LDAP qui contient les informations des
distributeurs.

AUI

:

Annuaire universel des
internes, LDAP qui contient les informations des internes SFR.

CVS

:

Concurrent Versions System
, système de gestion de versions, ancêtre de SVN
.

DAT

:

Dossier d’architecture, document qui expose l’architecture utilisée par le service ou
l’application pour
remplir sa/ses fonction(s).

DRM

:

Digital Rights Management, système d
e gestion des droits sur les œuvres numériques,
ce système permet de contrôler l’utilisation d’un média (nombre de visualisations, dates, copies…).

DSI

:

Document de spécification d’int
erface, document qui décrit l’interface d’un service
accessible par un protocole de communication.

JMS

:

Java Message Service permet d’envoyer et de recevoir des messages entre applications
ou composants Java.

MQ

:

Service de messagerie d’IBM qui permet d
’envoyer et de recevoir des messages entre
applications utilisant le principe des files.

RAE

:

Reste à engager, terme de pilotage de projet, temps nécessaire pour terminer une tâche.

SSA

:

Sous
-
système applicatif, une application du système d’information,
telle que DGP,
Clarify ou ORIAN pour SFR (portail et recherche, gestion des informations clients, tarifs et historique
client).

SVN

:

Subversion, système de gestion de versions basé sur les principes de CVS
.

TIC

:

Tests d’Intégration Cœur, un projet de SFR

qui vise à faire un test de l’ensemble des
SSA de l’intranet distributeur développés par les différentes SSII (Atos, Sopra, CapGemini et Logica)
.

TMA

:

Tierce Maintenance Applicative, maintenance d’un logiciel ou d’une application par
un prestataire extér
ieur à l’entreprise qui possède l’
application.

TNR

:

Tests de non régression, lors d’une évolution d’une application, ces tests sont utilisés
pour vérifier que les fonctionnalités implémentées avant l’évolution sont toujours conformes.

VS

:


Vente et Sousc
ription, application de l’intranet distributeur développée par Logica,
elle permet aux distributeurs de faire des actes de vente ou de souscriptions d’offres.




38


XI.

Bibliographie

Principales ressources qui m’ont aidé durant mon stage

D
ELANNOY
Claude,
Programmer en Java
, Eyrolles

En ligne

:

Documentation Java
,
http://java.sun.com


Documentation LDAP
,
http://www.openldap.org

Documentation WSDL
,
http://www.w3.org/TR/wsdl

Documentation Zend Framework
,
http://framework.zend.com

Documentation PHP
,
http://fr.php.net

,
http://www.manuelphp.org


Documentation XML Schema
,
http://xmlfr.org