GÉNIE LOGICIEL N o 82 SEPTEMBRE 2007 RETOUR … · Puis, on a réalisé une analyse du contexte organisationnel avec l’équipe de développement et la direction, ... évaluations

G É N I E L O G I C I E L N o 8 2 S E P T E M B R E 2 0 0 7

RETOUR D’EXPÉRIENCE

40

1. INTRODUCTIONL’évolution constante de la technologie informa-tique pousse les entreprises à mettre en place deschangements technologiques qui peuvent avoir unimpact important sur la technologie utilisée et surles personnes responsables de la mise en œuvre.Ces changements technologiques doivent répondreà des besoins et doivent suivre les orientations tech-nologiques de l’entreprise afin de bien s’intégrer àson plan d’affaires. Malheureusement, beaucoupd’entreprises réalisent ces changements technolo-giques sans effectuer une analyse de risques et sansconsidérer les impacts sur le fonctionnement del’organisation. Ceci peut souvent mener à un échec.Cet échec ne dépend pas seulement de la techno-

logie utilisée : il peut résulter d’un changementexécuté trop rapidement ou sans planification adé-quate, d’une mauvaise analyse des besoins ou d’unemauvaise utilisation des ressources humaines etmatérielles.

La société Media B2B est spécialisée dans l’ex-ploitation de sites d’affaires électroniques et four-nisseur de solutions d’affaires. En 1996, MediaB2B a lancé son premier site de commerce élec-tronique, ECommerce BF, et a mis en place la pre-mière version de son architecture logicielle. Depuis,Media B2B continue à faire évoluer son architec-ture logicielle pour mieux répondre aux besoins deperformances, de fiabilité, de sécurité, de stabilité

Étude de cas :Évaluation de la Migration

d’une Architecture Logicielled’une Société de Commerce

ÉlectroniqueY A Q U E L I N E C O R R A L E S E T C L A U D E Y . L A P O R T E

Résumé : Une migration logicielle est un processus consistant à changer un logiciel d’un environnement à un autreou d’une version de base vers une autre, en effectuant les adaptations nécessaires pour que le système continue defonctionner correctement. L’équipe de développement du site de commerce électronique ECommerce BF a effec-tué une migration d’architecture logicielle afin de mieux répondre aux besoins croissants de sa clientèle. Ce sitecompte plus de 3 600 clients dans plus de 60 pays.

Cette évaluation a inclus les aspects concernant le volet technique de la migration d’architecture logicielle etd’autres aspects tels que le processus de gestion de la migration, l’impact que ces migrations ont sur l’équipe dedéveloppement, ainsi qu’une évaluation du contexte organisationnel. Pour faciliter l’évaluation de la migration,on a effectué une analyse de l’architecture logicielle. Puis, on a réalisé une analyse du contexte organisationnelavec l’équipe de développement et la direction, pour ensuite évaluer le processus de migration ainsi que la ges-tion du projet.

Mots clés : migration logicielle, architecture logicielle, système d’information.


41

qu’une brève analyse des principaux critères dequalité de l’architecture.

• Présentation de l’analyse de la migration logi-cielle du site ECommerce BF, de la motivation,des risques, des coûts ainsi que de l’analyse de laconvergence de la migration avec le processusd’affaires de la compagnie.

• Présentation de l’analyse du processus de migra-tion d’architecture logicielle et de la gestion duprocessus ainsi que des objectifs technologiqueset stratégiques de la migration.

• Présentation des résultats de l’évaluation du pro-cessus de migration d’architecture logicielle, desconclusions et des recommandations pour desmigrations logicielles futures.

2. PRÉSENTATION DU SITE ECOMMERCE BFLe site ECommerce BF a été développé en suivantune architecture 3-tiers J2EE (Java 2 Enterprise Edi-tion) qui sépare l’interface de l’utilisateur de l’en-semble des fonctionnalités offertes, du traitement desapplications et de la base de données. Le systèmed’ECommerce BF repose sur l’architecture logiciellede Media B2B et utilise cette architecture pour le trai-tement de l’information ainsi que pour les aspects desécurité, confidentialité et autres. L’utilisation de l’ar-chitecture de Media B2B avantage le site ECommerceBF, car ce dernier peut profiter de l’expertise de l’ar-chitecture, de sa stabilité ainsi que de toutes les misesà jour et améliorations qui sont effectuées. La figure1 montre l’architecture du système utilisé par le siteECommerce BF.

2.1 MODÉLISATION DU SITE

La logique d’affaires nécessaire au fonctionnementd’ECommerce BF est supportée par l’architecturelogicielle de Media B2B, ce qui permet à l’équipede développement d’ECommerce BF de concen-


Tableau I : Description des sites de Media B2B

de ses sites d’affaires électroniques et pour s’adap-ter aux changements constants de la technologieinformatique. Media B2B exploite 13 sites d’af-faires électroniques différents avec plus de 7 000compagnies membres, dans plus de 60 pays. Letableau I présente une brève description de chacunde ces sites. Les noms de la société et des sites ontété modifiés pour assurer la confidentialité.

Afin de répondre aux besoins croissants de sesclients, ECommerce BF effectue périodiquementdes migrations d’architecture logicielle, ce qui luipermet d’améliorer les services et de poursuivre sonévolution technologique. Pour le site ECommerceBF, les migrations d’architecture logicielle n’ontjamais été complètement estimées ou quantifiées.Ce projet a permis d’évaluer l’impact des migra-tions technologiques afin d’aider la direction àappuyer les décisions futures quant à la nécessitéd’effectuer des migrations d’architecture logicielle.En effectuant une évaluation des migrations d’ar-chitecture logicielle et de l’impact que ces change-ments ont sur l’équipe de développement, la directionpourra mieux comprendre la pertinence du change-ment d’architecture logicielle et obtiendra un rapportdétaillé des bénéfices de tels changements en termesde productivité, d’amélioration du travail, de la faci-lité d’utilisation des nouveaux outils, des gains enperformances et en qualité.

Le plan de l’article est le suivant :• Présentation du site ECommerce BF, de ses fonc-

tionnalités, de son architecture et de son évolution. • Présentation des résultats de l’évaluation du

contexte organisationnel d’ECommerce BF.• Présentation de l’architecture logicielle de Media

B2B et description des aspects techniques du sys-tème, de sa modélisation, de son évolution ainsi


42


Tableau II : Caractéristiques du site ECommerce BF

Figure 1 : Architecture dusystème d’ECommerce BF


43

trer ses efforts à l’évolution fonctionnelle du siteselon les besoins du marché.

Pour l’ajout des nouvelles fonctions, ECommerceBF utilise un cycle de développement comprenantquatre phases principales tel qu’illustré à la figure 2.

Pour chaque version d’ECommerce BF, lesdocuments suivants sont produits : les spécifica-tions des fonctionnalités, le plan d’assurance-qua-lité, le plan de mise en production ainsi que lecalendrier d’avancement du projet.

2.2 ÉVOLUTION DU SITE

Depuis les débuts, une vingtaine de versionsd’ECommerce BF ont été mises à la dispositiondes clients à un rythme d’au moins trois nouvellesversions par année. Ces versions visent principa-lement à ajouter de nouvelles fonctionnalités pourrépondre aux exigences du marché.

Afin de donner une idée de l’ampleur de l’évo-lution d’ECommerce BF ainsi que des différentesmigrations logicielles ayant été effectuées au coursdes dernières années, le tableau III présentequelques exemples des différentes versionsd’ECommerce BF à partir de la version 5.6 de l’ar-chitecture (Tableau III).

3. ÉVALUATION DU CONTEXTEORGANISATIONNEL

Ce chapitre présente les résultats de la mini éva-luation de la maturité du processus de développe-ment selon le modèle du CMMI®2 (CapabilityMaturity Model Integration) [1] et les résultats desévaluations des facteurs humains.

3.1 ÉVALUATION DU PROCESSUS

Nous avons effectué une mini évaluation avec ladirectrice du site. Cette évaluation consistait en unquestionnaire sur les différentes pratiques logicielles

au sein de l’équipe de développement d’ECommerceBF. Les domaines de processus évalués sont :• Gestion des exigences : processus par lequel on

établit comment l’entreprise gère les exigences duproduit et de ses composants afin de déterminersi le produit final répond aux exigences initiales.

• Planification des projets : processus qui sert à éta-blir et gérer des plans qui déterminent les activitésdu projet.

• Suivi et contrôle de projets : processus danslequel le projet est suivi dans toutes ses étapes, desorte que des actions correctives soient prisesquand le projet s’écarte du plan initial.

• Assurance qualité logicielle : processus qui four-nir aux équipes et aux gestionnaires une visionobjective du processus utilisé par le projet ainsique sur les produits en élaboration.

• Gestion de la configuration logicielle : processusqui vise à maintenir l’intégrité des produits duprojet tout au long de son cycle de vie.

Nous avons fait les constats suivants :• Le projet est défini selon les exigences du client,

il est documenté et suivi tout au long de son cyclede vie. Par contre, il n’existe pas une politiquepour la gestion des exigences.

• La planification du projet de l’équipe d’ECom-merce BF est satisfaisante. Cependant, le suiviest presque inexistant dans l’organisation.

• Pour l’assurance-qualité, les objectifs sont établis,les personnes concernées sont identifiées et lesproblèmes sont adressés correctement. Par contre,il n’existe pas de procédures en ce qui a trait auplan d’assurance-qualité dans l’organisation.

• Pour la gestion de la configuration, un plan est éta-bli et les lignes directrices sont utilisées pour chaquenouvelle version. Les ressources sont allouées et lesresponsabilités sont assignées. Il n’y a pas de miseen œuvre du processus pour le suivi ou le contrôle.

• La définition et la documentation des projets sontélaborées correctement.


Figure 2 : Cycle de développement d’ECommerce BF


44

Nous avons aussi constaté qu’il serait judicieux,pour ECommerce BF, d’améliorer sa gestion desprocessus pour arriver à un meilleur contrôle del’implantation et du suivi des projets. Il faut profiterde l’expérience du personnel pour transmettre leursavoir dans les autres équipes.

3.2 LES FACTEURS HUMAINS

Afin de mieux établir le profil des personnes res-ponsables de la mise en place de la migration logi-cielle, plusieurs évaluations ont été réalisées enutilisant les outils développés par la société amé-ricaine Implementation Management Associates(IMA) [2]. Ces évaluations visent à mesurer la ges-tion des changements d’une organisation et à pré-dire les points à améliorer pour des changementsfuturs. Les évaluations aident à déterminer la syner-gie d’une équipe de travail, sa capacité à effectuerun changement et la probabilité de succès pour cechangement. Le tableau IV énumère quelques outilsd’évaluation.

3.2.1 Évaluation des commanditaires (sponsors)L’évaluation des commanditaires permet d’éva-luer le niveau et le type d’engagement dont ilsdoivent faire preuve afin d’assurer le succès de lamise en œuvre d’un projet de changement. Parexemple, on demande aux personnes qui subirontle changement proposé d’évaluer, sur une échellede 1 à 5, l’affirmation suivante : le commandi-taire fait preuve d’une implication personnelle etd’un engagement important au sujet de ce chan-gement. On calcule les scores de chaque personneconcernée et on calcule la moyenne pour chaquequestion. Le score représente la probabilité desuccès de mise en œuvre du projet de change-ment. Un score élevé signifie que le succès demise en œuvre de ce changement est tout à faitprobable. Un score moins élevé signifie que desstratégies doivent être développées, car le niveauet le type d’engagement des commanditaires peu-vent menacer le succès de la mise en œuvre duchangement.


Tableau III : Principales fonctionnalités de quelques versions d’ECommerce BF à partir de la version 5.6 de l’architecture

Tableau IV : Outils d’évaluation des changements de la société IMA


45

D’après l’évaluation, nous pouvons conclure que :• les commanditaires sont engagés dans les chan-

gements au niveau de l’organisation,• les développeurs ont de la difficulté à comprendre

les messages transmis par les commanditaires,car ils ne comprennent pas l’impact ou le bien-fondé des changements demandés,

• les commanditaires manquent de conviction ence qui a trait à leurs attitudes envers les change-ments : les employés sentent qu’ils sont en faveurdu changement, mais ils ne perçoivent pas leursengagements face à ce qu’ils demandent,

• le système de renforcement s’opère principale-ment au niveau de l’équipe et non individuelle-ment.

On a proposé que la direction analyse en pro-fondeur les répercussions des changements propo-sés. Le tout pourrait se faire en produisant un plande projet plus détaillé et mieux adapté à chaqueéquipe de travail. Ce plan pourrait utiliser plus effi-cacement les canaux de communication avec leséquipes de travail. Il faudra s’assurer que l’équipede migration saisisse le bien-fondé des change-ments en plus de faire connaître les critères de suc-cès pour mener à bien le projet.

3.2.2 Évaluation de la culture de l’organisationCet outil permet d’évaluer si le changement à mettreen place est cohérent avec la culture de l’organisa-tion. On peut aussi identifier des facteurs de résis-tance aux changements proposés.

Selon les résultats des évaluations, ECommerceBF jouit d’une structure de travail flexible, ce quil’aidera lorsque viendra le temps de faire face àdes problèmes technologiques ou professionnels.On y favorise beaucoup la collaboration entre lesgens, ce qui rend l’organisation plus réceptive auxdemandes de changements de ses clients.

Par contre, les opinions des employés sur lamigration d’architecture logicielle sont mitigées :ils ont des opinions très divergentes sur le sujet etil n’existe pas de vision à long terme en ce qui a traità l’avancement professionnel des employés.

Puisque l’équipe ECommerce BF a un bonesprit d’équipe, il faut profiter de cette force pourfavoriser l’intégration des changements à mettreen œuvre. L’opinion des employés en ce quiconcerne la position d’ECommerce BF face auxchangements, est mitigée. Donc, l’intégration denouvelles technologies devrait se faire en utilisantles employés favorables aux changements pour queceux-ci convainquent les employés plus réticents.

3.2.3 Évaluation du niveau de stressL’évaluation du niveau de stress permet de mieuxcomprendre le stress où les changements futursauront lieu. Pour ECommerce BF, les facteurs ayant

eu la plus grande influence sur le stress organisa-tionnel sont l’implication des employés, les nou-velles mises en œuvre du contrôle de qualité et lesnouvelles techniques introduites. Le stress de lavie professionnelle est faible, ce qui contribue posi-tivement à l’adaptation face aux changements.

L’utilisation des résultats des évaluations duniveau de stress aidera l’organisation à mieux quan-tifier les migrations et, par conséquent, à mieux esti-mer et déléguer les activités reliées aux changementstechnologiques. L’organisation doit suivre de près lestress organisationnel pour que celui-ci ne viennepas détériorer le climat de travail dans l’entreprise.

3.2.4 Évaluation des agents de changementL’évaluation des agents de changement permet dedéterminer le profil des personnes qui seront res-ponsables de mettre en place un changement com-plexe. Les évaluations indiquent que le niveau decompétence de l’équipe des agents de changementest modéré. Nous avons remarqué qu’en général,l’entreprise dispose d’un climat qui favorise l’in-tégration des changements grâce au niveau d’en-gagement des intervenants.

Fait intéressant : les employés perçoivent lesagents de changement comme des gens ayant debonnes attitudes pour diminuer le stress organisa-tionnel. Il faudrait exploiter cette situation avanta-geuse.

3.2.5 Évaluation des personnes visées par le chan-gementCet outil vise à évaluer le degré d’adaptation auchangement de chacune des personnes impliquéesdans le projet afin d’établir le niveau de résistanceau changement.

Nous avons mesuré un grand écart entre lespersonnes évaluées. Nous avons jugé que le faitd’avoir deux personnes plus craintives et deux plusfonceuses face aux changements, pourrait aider àéquilibrer la synergie de l’équipe.

Toutes les personnes évaluées sont d’accordsur la nécessité des migrations logicielles et ellesestiment que ce changement sera implanté avecsuccès. De plus, elles ne sentent pas que ce chan-gement est lié à leurs performances, mais plutôt àun besoin spécifique de l’organisation.

Tenant compte du fait que les répondants ontune certaine habitude des évolutions constantes ausein des projets sur lesquels ils travaillent et qu’ilssont favorables à ces changements, la compagniepourra profiter de cette ouverture pour mener avecsuccès chaque changement qu’elle veut mettre enplace. Elle pourrait identifier la ou les personnesclés pouvant favoriser la réussite du nouveau pro-jet et les motiver pour qu’elles agissent en tant que



46

promoteurs du changement. Il faudrait égalementpenser à concevoir un plan permettant d’encoura-ger les employés réticents pour les motiver à adop-ter le projet et faciliter ainsi l’avancement deschangements.

3.2.6 Évaluation du système de renforcementCette évaluation vise à établir si le système actuelde renforcement, par exemple les récompenses et larémunération, de la compagnie s’aligne avec lesattentes et aspirations des membres de l’équipe.

Nous avons remarqué que les employés, quiont rempli le questionnaire, avaient des préférencesopposées au système de renforcement proposé parl’entreprise. Par exemple, les employés manifestentune préférence pour avoir des congés plus longs,pratique qu’ils ne perçoivent pas comme répandueau sein de l’entreprise.

Par rapport aux tâches allouées, à la recon-naissance au travail et au renforcement intrinsèque,nous avons observé une certaine concordance entrece que la compagnie offre et ce que les employéspréfèrent.

En général, nous avons observé que les répon-dants souhaiteraient avoir plus de responsabilités,d’influence et de participer à la résolution de pro-blèmes importants. La compagnie devrait mieuxconnaître et récompenser les capacités profession-nelles de ses employés.

Nous jugeons que l’utilisation des moyensd’encouragements monétaires au lieu du système decadeaux proposé par l’entreprise réglerait le pro-blème des encouragements tangibles. Nous propo-sons que les tâches offertes soient plus variées, carcela est considéré comme prioritaire par la plupartdes répondants.

4. PRÉSENTATION ET ANALYSEDE L’ARCHITECTURE LOGICIELLE

La tendance de l’informatique des dernières annéesa amené l’architecture logicielle à jouer un rôlecentral dans le génie logiciel. La définition « The

software architecture of a program or computingsystem is the structure or structures of a system,which comprise software elements, the externallyvisible properties of those elements, and the rela-tionships among them » [8] donne une bonne idéede ce qu’une architecture doit comporter. L’archi-tecture logicielle est une clé essentielle de la réus-site d’un projet logiciel. Il est important de bienanalyser les raisons menant à sa conception, quece soit les influences techniques, sociales, d’af-faires ou les propriétés auxquelles le système doitrépondre : performances, fiabilité, disponibilité,sécurité ou autres.

4.1 DESCRIPTION DU SYSTÈME

La version 5.9 de l’architecture est basée sur unestratégie de développement favorisant la réutilisa-tion des composants. Cette stratégie de dévelop-pement est connue dans le marché du logiciel pourla facilité à faire évoluer le système par séquenceou version, ainsi que pour l’amortissement du coûtde développement grâce à un taux élevé de réutili-sation [8].

4.1.1 Modélisation de l’architecture logicielleAfin de mieux présenter la modélisation de l’ar-chitecture logicielle, cette section donne une des-cription des différents éléments qui la constituenten essayant d’utiliser la notion de Langage de des-cription d’architecture (« Architecture DescriptionLanguage » - ADL).

L’architecture version 5.9 est divisée en compo-santes qui sont regroupées selon la fonctionnalité àlaquelle elles doivent répondre. Ainsi, on trouve unréférentiel (« framework »3), appelé Media B2B OpenServer (MOS) qui contient les modules suivants :Request Management (gestion de requêtes), MediaB2B Presentation Layer (MPL – couche de présenta-tion), Media B2B Business Layer (MBL – couche duservice d’affaires), Media B2B Communication Layer(MCL – couche de communication), Server Plug-ins(serveur de plugiciels), le Inter-Server Communication(communication entre serveurs), et le framework &utilities (outils de gestion).

Le référentiel MOS intègre les composantessuivantes afin d’offrir une application serveur :• La composante Request Management est res-

ponsable de la réception des requêtes externes,de leur authentification, de leur acheminementet de l’autorisation de leur exécution.

• La composante Presentation Layer est la couchequi contient toute la logique de présentation.Aucun processus d’affaires n’y est traité. Cettecouche fournit trois composants : l’Input hand-ler qui contient des objets représentant les para-mètres d’entrée, le Presentation Controller quicontrôle le traitement du contenu dynamique et lePresentation View, qui transforme les objets repré-sentés en contenu dynamique.


Figure 3 : Composantes de l’architecture logicielle


47


Tableau V : Exemples de fonctionnalités de la version 5.9 de l’architecture

Tableau VI : Attributs de la qualité

• La composante Business Service Layer est lacouche d’implémentation englobant toute lalogique d’affaires de l’architecture. Elle renfermedeux niveaux de conception : le Media B2B Busi-

ness Service (MBS), qui sert à définir les fonc-tionnalités d’affaires, à les isoler de la logiquede présentation, à contrôler le flux de données etle Media B2B Business Entity (MBE), respon-


48

sable de la persistance des entités d’affaires dansla base de données. Pour accéder aux entités, cettecouche contient également les Business Func-tional Objects (BFO) qu’implémentent les règleset les opérations d’affaires et les Business DataAccess (BDA) qui permettent d’accéder directe-ment aux données.

• La composante Communication Layer est lacouche permettant la communication des com-posants avec les systèmes externes, que ce soit enentrée ou en sortie. Cette couche isole les che-mins de communications des clients d’avec lesystème de Media B2B.

• Les Server Plug-ins sont des composants qui sontautomatiquement chargées au démarrage du ser-veur. Elles sont utilisées par les couches d’af-faires et de communication pour effectuer leurtraitement et par la couche de présentation pourgénérer des rapports.

• La composante Inter-Server Communication faci-lite la communication entre les serveurs. Elleenglobe deux services : l’Open Server Services(OSS) qui simplifie le processus d’établissementdes connexions entre deux serveurs et le MediaB2B Distributed Services (MDS) réseau fédéra-teur4 permettant le partage de services, données etévénements à travers les serveurs d’une manièresûre et efficace.

• Les Frameworks & Utilities sont des outils faci-

litant la gestion des « settings », de la mémoirecache des données, du traitement des documentset de la gestion des messages.

4.1.2 Fonctionnalités de l’architecture logicielleLe tableau V présente quelques exemples des prin-cipales caractéristiques ou fonctionnalités de l’ar-chitecture selon chacune de ses composantes, ainsique les améliorations élaborées dans la version 5.9,par rapport aux versions antérieures de l’architecture.

4.1.3 L’architecture selon les critères de qualitéLa conception de l’architecture logicielle d’un sys-tème doit répondre aux besoins de qualité commeles performances, la fiabilité, la sécurité, l’inté-grité et l’évolutivité. Plusieurs méthodes, commeATAM, « Architecture Tradeoff Analysis Method »[12], ou ABAS, « Attribute-Based Architecture »[13], permettent d’analyser l’architecture selon sesattributs de qualité et font ressortir les points cri-tiques de la conception. Les principaux attributsde la qualité sont énumérés dans le tableau VI :

Nous donnons quelques exemples des attributsde la qualité de la version 5.9 de l’architecture dansle tableau VII. Le niveau de priorité de chaque attri-but est élaboré en suivant la nomenclature « (X,Y) »où la première lettre indique l’importance de l’ob-jectif et la deuxième, le niveau du risque. Cette


Tableau VII : Exemples d’attributs de qualité de la version 5.9 de l’architecture

Tableau VIII : Identification des coûts en heures de la migration de l’architecture logicielle


49

affectation de priorité utilise l’échelle H (haut),M (moyen) et B (bas).

5. ANALYSE DE LA MIGRATION LOGICIELLELa plupart des entreprises s’efforcent de faire évo-luer leur système informatique pour mieux répondreaux exigences du marché, à la fulgurante évolutionde la technologie, et pour s’adapter aux nouveauxstandards. Media B2B offre des services à plusieursréseaux d’affaires, ce qui l’oblige à chercher à sedoter d’une infrastructure commune pour offrir lesmêmes services dans les différentes plates-formes.

Un processus d’affaires se définit comme une« Suite cohérente d’activités et d’opérations com-merciales qu’entretient une entreprise ou une orga-nisation avec des tiers, traduisant les besoins deses clients et les exigences de son environnement,et tenant compte ou non de ses activités internesde manière à les agencer selon une logique de créa-tion de valeur » [10]. Un processus d’affaires inclutles différentes activités d’une organisation pourrépondre efficacement aux besoins de ses clients.Une entreprise n’a pas qu’un seul processus d’af-faires mais plusieurs processus clés qui s’harmo-nisent entre eux pour atteindre ses objectifs et pourproduire de la valeur pour ses clients.

5.1 BESOINS TECHNIQUES

Une architecture logicielle est conçue pour répondreaux spécifications fonctionnelles et aux attributsde qualité nécessaires au logiciel. Dans le cas étu-dié, il s’agit de répondre aux besoins du site ECom-merce BF. L’architecture logicielle de Media B2Bdoit répondre aux besoins fonctionnels de l’en-semble de ses différents réseaux d’affaires et nonpas à un seul. Chacun des réseaux a des raisonsdifférentes pour migrer d’une version d’architectureà une autre. Dans le cas d’ECommerce BF, certainsbesoins techniques ont motivé la migration :• ECommerce BF avait besoin de performances et

de fiabilité pour répondre aux exigences du mar-ché qu’elle dessert. Ainsi, un des principauxobjectifs de la migration d’architecture logicielled’ECommerce BF était l’amélioration de lacharge, de la sécurité et des performances ;

• le nombre de lignes d’inventaire avait atteint unelimite de 2 giga-octets, ce qui rendait impératifune division de la base de données et cette fonc-tionnalité n’était offerte qu’à partir de la version5.9 de l’architecture ;

• il fallait continuer à améliorer les services desécurité du site à savoir la gestion du contrôled’accès, la gestion des sessions, la gestion desmots de passe et l’amélioration du système dedétection des intrus.

5.2 COÛT DU PROJET DE MIGRATION

Afin d’établir une référence pour des migrationsfutures, nous avons estimé les coûts de la migration

logicielle en termes d’heures utilisées pour cha-cune des étapes identifiées.

Pour l’identification des coûts, nous avons uti-lisé les activités du processus de développementrecommandées par la norme ISO/CEI 12207 [22].Cette norme définit les activités du processus dedéveloppement, à savoir analyse des spécifications,conception, code, intégration, tests, installation etacceptation. Même si la norme identifie les étapesdu processus de développement logiciel et pas cellesd’une migration, il nous apparaît que certaines deces étapes doivent être prises en considération lorsdes migrations. Car, avant tout, une migration estun processus de modifications d’un logiciel et ilest nécessaire de s’assurer que ce dernier soit gérécomme un processus logiciel incluant les diffé-rentes phases d’analyse, de développement et detests. Le tableau VIII énumère le coût, en heures,des activités de migration. Le nombre d’heuresd’analyse et spécifications a été identifié à la suitede rencontres avec les développeurs et la directricedu site. Le nombre d’heures de formation a étéidentifié à la suite de rencontres avec les dévelop-peurs et la direction du site.

5.3 ANALYSE DU RETOUR SUR INVESTISSEMENT

Il est possible que l’investissement effectué puisse nepas avoir de retombées tangibles. De plus, elles sontdifficilement mesurables. Mais ces changements peu-vent générer des bénéfices en termes de diminutiondes coûts de maintenance ou de fonctionnement, enplus des améliorations dans les attributs de qualité dusite. Même si ces changements ne se traduisent pasen argent, ils ajoutent une valeur au processus d’affairesde la compagnie. Les paragraphes suivants décriventles avantages de cette migration.

5.4. UTILISATION DE TECHNOLOGIES CONCURRENTIELLES. Une des principales raisons pour lesquelles l’ar-chitecture logicielle a évolué continuellement résidedans l’implémentation de nouvelles technologiesnécessaires au fonctionnement des différentesplates-formes pouvant améliorer la qualité de l’ar-chitecture et faciliter le développement des sites.Pour ECommerce BF, migrer vers une nouvelleversion de l’architecture permet de profiter de cestechnologies - surtout pour les nouvelles fonction-nalités - sans avoir à modifier tout le code en place.

5.5 DIMINUTION DE L’EFFORT POUR SUPPORTER

LES ANCIENNES TECHNOLOGIES UTILISÉES. Considérant que lors de la migration à la version 5.9de l’architecture, ECommerce BF n’a eu à réaliserque des adaptations mineures à la configuration etquelques modifications au code, cet avantage perd dela valeur. Il faut noter que la nouvelle version de l’ar-chitecture doit continuer de supporter des technologiesayant été implémentées dans plusieurs versions anté-rieures et qui peuvent ne plus s’avérer compétitivesdans le marché informatique. Toutefois, si ECom-



50

merce BF utilise les outils de la nouvelle architecturepour développer ses nouvelles fonctionnalités, cetavantage peut augmenter avec le temps.

D’après la lecture du code Java des différentesversions d’ECommerce BF, nous avons observé unecroissance lente dans l’utilisation des nouvelles tech-nologies. En général, le codage des fonctionnalitésutilisant la nouvelle technologie est exécuté dans lapremière version migrée, pour ensuite s’arrêter ouévoluer très lentement. Ce constat permet de penserque la diminution des coûts de maintenance desanciennes technologies peut s’étendre sur plusieursversions, sauf si on prend des mesures pour conver-tir l’ancien code.

5.6 AMÉLIORATION DES ATTRIBUTS DE QUALITÉ. En migrant vers cette version de l’architecture logi-cielle, ECommerce BF profite des améliorations desattributs de qualité, ce qui peut se traduire par uneamélioration des services que le site offre à ses clients.

Avec plus de 190 000 recherches par jour, larecherche constitue une des fonctionnalités critiquesd’ECommerce BF. Nous avons analysé la variabilitédu temps de réponse des recherches effectuées àl’intérieur d’une période d’un mois. Comme lemontre la figure 4, après la migration (mois 0), letemps de réponse à une recherche a légèrement aug-menté pour ensuite rester plus ou moins stable.

5.7 RISQUES DE LA MIGRATIOND’ARCHITECTURE

LOGICIELLE

Tout projet logiciel comporte plusieurs risques pou-vant affecter le processus (délai du projet, coûts

estimés, etc.) ou les résultats (c.-à-d. le logiciel nerépond pas aux spécifications initiales). Ces risquesont une incidence sur le déroulement du projet et,s’ils sont mal gérés, ils peuvent mener à l’échecdu projet.

Le tableau IX énonce, à titre d’exemples,quelques risques identifiés, leur impact dans le pro-cessus de migration ainsi qu’un résumé de l’ap-proche ou de la solution qui a été prise lors de lamigration.

6. ANALYSE DU PROCESSUS DE MIGRATIONDU SITE VERS LA NOUVELLE

Une migration logicielle doit assurer qu’une foisle processus terminé, l’application continuera àfonctionner comme avant la migration. Il estdonc très important de décrire les comporte-ments de l’application et ses caractéristiquesavant la migration, pour posséder des mesuresqui permettront d’établir le succès ou l’échecde la migration. Mais ces aspects ne sont pas lesseuls indicateurs de succès du projet. Il est éga-lement important d’évaluer d’autres facteurs clésdu projet et d’identifier les objectifs avant ledébut du processus, pour bien cibler les pro-blèmes à résoudre et évaluer si ces objectifs ontété atteints à la fin du projet.

6.1 LE SUCCÈS OU L’ÉCHEC DU PROJET DE MIGRATION

DE L’ARCHITECTURE LOGICIELLE

Au Canada, selon une étude menée par KPMGCanada [24] auprès de 1 450 organisations, 87%des projets ont dépassé leur échéancier de plus de30%, plus de 56% des projets ont dépassé leur bud-get et 45% n’ont pas atteint leurs objectifs.

Pour déterminer le succès de la migration logi-cielle, il ne faut pas seulement évaluer le respect deséchéanciers et du budget. Il faut également éva-luer la gestion du processus dans l’ensemble, lagestion du personnel et son implication dans le pro-jet, car ces aspects sont critiques au niveau du pro-jet et ils peuvent assurer sa réussite. Afin de mieuxrépondre aux besoins de cette évaluation, nousavons évalué les critères de succès ou d’échec, sui-vants : la définition des objectifs et des besoins,


Figure 4 : Évolution mensuelle de temps de réponse(le mois 0 représente le mois de la migration)

Tableau IX : Exemples de risques identifiés pour la migration de l’architecture logicielle


51

l’analyse de la gestion du projet de migrationincluant l’implication des développeurs, le respectdes échéanciers et du budget et le soutien de ladirection. Nous estimons que lors d’un processus demigration logicielle, il faut considérer l’aspecthumain, de façon à ce que les personnes respon-sables de la migration puissent mettre à la dispo-sition du projet toutes leurs compétences et queces dernières évoluent en parallèle avec la migra-tion. Pour évaluer cet aspect, nous examineronsles activités de formation, d’accompagnement etde support qui ont été offertes aux membres del’équipe de développement.

6.1.1 Identification des objectifs de la migrationde l’architecture logicielleDans un projet de migration d’architecture logi-cielle, un des principaux avantages est d’utiliserles attributs de qualité qu’offre une infrastructurelogicielle et de profiter de l’évolution technolo-gique de cette dernière. Comme l’expliquent plu-sieurs auteurs, une architecture logicielle peutrépondre aux besoins d’un ou plusieurs logicielsqui gagnent à l’expérience et à la solidité de l’ar-chitecture logicielle, ainsi qu’à la réduction descoûts de développement et de maintenance[8][20][21].

Selon l’analyse des différents documents, nousavons pu établir que les principaux objectifs tech-nologiques de la migration d’architecture logicielled’ECommerce BF étaient :• amélioration des performances ;• amélioration de la distribution des charges.• amélioration des opérations :

- gestion des erreurs ;- contrôle de traces et des temps morts, distinc-

tion entre les erreurs du serveur et des erreursdes usagers ;

- système de détection des intrus ;- gestion des erreurs de synchronisation.

• amélioration du système de facturation.

6.1.2 Gestion du projet de migrationLa gestion d’un projet a pour objectif de conduirele projet à terme, en satisfaisant ou dépassant lesexigences initiales et en utilisant son savoir-faire etses habiletés de gestion. La gestion d’un projet a dif-férentes fonctions [26] : • La planification, incluant les activités et les pro-

cessus devant être accomplis ; l’organisation,qui détermine quel travail doit être accompli, larépartition des tâches et l’assignation des res-ponsabilités ;

• la sélection de l’équipe, avec un leader qui puisseentraîner et guider les membres de son équipe àbien réaliser le projet ;

• la gestion, qui doit permettre de mener le projetà terme dans une atmosphère positive et moti-vée ;

• le contrôle, qui permet de mesurer et évaluer l’ac-complissement de chacune des étapes du projet.

Un projet de migration d’architecture logicielledoit être géré comme les autres projets informa-tiques, en tenant compte des contraintes qui peuventsurvenir au cours du projet, tout en considérant lesrisques liés au changement. Une migration logi-cielle doit être vue comme un projet de change-ment où il faut spécifier les besoins, communiquer,former, documenter et démontrer l’importance duchangement pour le motiver et le justifier commeun avantage pour le processus d’affaires de l’en-treprise.

6.1.3 Planification de la migration d’architecturelogicielleLors de la planification d’un projet, il faut définirles objectifs, les activités à réaliser, la gestion desrisques, la préparation du budget et le plan de déve-loppement [26]. Comme nous l’avons mentionné,la planification de la migration d’architecture logi-cielle a été incluse à l’intérieur des documents degestion de projets d’ECommerce BF. Les lignesdirectrices de ce qui devait être inclus lors de lamigration ainsi que les objectifs se retrouvaientégalement dans ces documents. La planificationinitiale prévoyait un effort de dix jours de déve-loppement pour assurer la migration.

6.1.4 Gestion de facteurs tactiques« Les décisions tactiques consistent à jouer sur lesmoyens, à modifier les actions spécifiques pours’adapter aux incidents de parcours et continuer àobtenir les avantages prévus sur le terrain. L’en-semble des tactiques s’inscrit dans la stratégie ;celle-ci assigne à chacune son rôle, sa place dans ledispositif, son type de développement et ses limites.La stratégie prévoit aussi nécessairement la coor-dination, l’éventuel degré de subordination et deconvergence des tactiques entre elles. » [10]. Pourbien gérer les facteurs tactiques d’une migrationlogicielle, nous devons prendre en considérationles activités de consultation et l’acceptation du pro-jet par le client, la gestion des employés incluant lesstratégies de gestion du changement, de formationet de soutien ; le contrôle et la rétroaction du pro-jet ; le plan de communication ; la gestion desrisques et la correction de problèmes. Nous décri-vons ci-dessous quelques activités :

6.1.5 Consultation et acceptation du projet parle clientLe processus d’une migration d’architecture logi-cielle doit être réalisé de manière à ce que les clientsne voient aucun changement dans le comportementde leur application. La norme ISO/CEI 12207 [27]précise que lors du processus d’identification et derésolution des problèmes, le client ne doit pasconnaître ou déterminer la nature du problème defonctionnement du nouveau système, ni demander



52

sa correction. Le projet doit donc fournir les outilset les processus pour trouver, attribuer, corriger etfermer les dossiers d’erreurs. Une migration d’ar-chitecture logicielle doit être testée et validée pours’assurer que les fonctionnalités continuent à fonc-tionner correctement.

6.1.6 Gestion des employésLa culture organisationnelle peut avoir un impactsur la gestion des employés qui doivent mettre enœuvre le changement. Comme nous l’avons vu à lasection 1.4.1.1, ECommerce BF jouit d’une struc-ture de travail flexible, favorisant la gestion desproblèmes d’ordre technologique ou profession-nel, ainsi que la gestion des employés. L’équiped’ECommerce BF possède un bon esprit d’équipeet cette force aide à la mise en place des change-ments.

Pour la migration d’architecture logicielle, lesmembres de l’équipe d’ECommerce BF - six au total- ont été impliqués, ce qui a permis une meilleure dis-tribution des rôles et l’exploitation des forces dechacun des membres, tout en effectuant un suiviconstant sur l’avancement du projet.

6.1.7 Gestion du changement« L’objectif de la gestion du changement est defaciliter le passage d’un système sociotechniqueexistant à un système visé » [28]. Pour faciliter lechangement, il faut le faire comprendre à traverstoute l’organisation et surtout à l’équipe qui doit lemettre en place. Ceci permettra d’augmenter ledegré d’adaptation au changement des employéset de diminuer la résistance au changement. Commenous l’avons vu à la section 1.4.1.5, l’évaluation del’adaptation personnelle au changement effectuéauprès de l’équipe d’ECommerce BF, nous a mon-tré une diversité dans la façon de percevoir le chan-gement et ce, même si toutes les personnes étaientd’accord sur la nécessité d’effectuer des migra-tions logicielles. Pour faciliter le changement, ladirection d’ECommerce BF a assigné les rôles entenant compte des forces des membres de l’équipe.

Ainsi, elle s’est assurée que le processus s’accom-plirait plus facilement. La migration d’architecturelogicielle a été perçue par les membres de l’équipecomme un processus nécessaire qui avait peu d’im-pacts sur le fonctionnement d’ECommerce BF.

6.1.8 La formationL’objectif de la formation est de faciliter la prise encharge du nouveau produit par les utilisateurs etleur appropriation des nouvelles règles et procé-dures [28]. Dans le cas de la formation donnée lorsde la migration de l’architecture logicielle, l’ob-jectif était de faciliter l’assimilation des nouvellestechnologies mises en place par la version 5.9 del’architecture et d’inciter l’utilisation des nouvellespratiques, afin de motiver la continuité de laméthode utilisée à l’intérieur de l’entreprise. Enplus de la formation, les développeurs ont eu accèsà un système de référence interne, accessible vial’Intranet de l’entreprise, ainsi qu’à un support del’équipe d’infrastructure.

6.1.9 Soutien de la direction« On peut observer deux attitudes selon le degréde soutien de la direction pour un projet : le sou-tien et l’implication. Le soutien consiste à encou-rager l’adoption du nouveau système ou de lanouvelle technologie par une attitude positive etbienveillante. L’implication consiste à prendre desmesures pour assurer l’assimilation du nouveausystème et un fonctionnement efficace et efficient »[28]. Quand la direction se limite à un soutien,aucune planification n’est faite à l’avance, les chan-gements s’opèrent en accord avec les initiativesindividuelles avec peu de contrôle. Quand on parled’implication, on fait référence à la planification duprojet et à la gestion du changement.

Pour ce qui est de la migration d’architecturelogicielle sur laquelle porte ce document, on peutdire qu’il y a eu un peu d’implication de la part dela direction, ce qui aurait pu rendre plus difficile laréussite du projet. Le projet était prévu dans la pla-nification des projets pour les années 2004-2005

Tableau X : Éléments d’un guide de migration



53

et on avait estimé l’effort et les ressources néces-saires pour le mettre en place. Par contre, aucundocument ne faisait référence à la gestion du chan-gement.

7. RECOMMANDATIONSPOUR LES MIGRATIONS FUTURES

Afin de maximiser les chances de succès lors d’unemigration future, nous proposons les principalesrecommandations suivantes.

7.1 PROMOUVOIR LES MIGRATIONS D’ARCHITECTURE

Promouvoir la migration d’architecture des siteset de l’inscrire dans sa stratégie d’atteinte des objec-tifs d’affaires, car une architecture logicielle com-mune permet aux sites de la compagnie de profiterde l’expertise acquise par l’infrastructure, de sastabilité et de toutes les améliorations et correctifseffectués lors de son évolution.

7.2 AMÉLIORER L’ACCÈS À LA DOCUMENTATION

Indexer la documentation disponible pour rendre saconsultation plus accessible. De plus, l’équipe d’ar-chitecture logicielle devrait créer un outil dedéploiement pouvant indiquer facilement les étapesqui doivent être suivies pour mener à bien la migra-tion et ce, en utilisant l’expérience de chacun dessites qui ont effectué la migration.

7.3 DÉVELOPPER UN GUIDE DE MIGRATION D’ARCHITEC-TURE LOGICIELLE

Développer un guide de migration qui tiennecompte des leçons apprises lors des migrations pré-cédentes et qui contiendrait les indications précisessur la procédure de migration. Ce guide pourraitcontenir de l’information énumérée au tableau X.

7.4 DÉFINIR UN PLAN DE MIGRATION

Définir un plan de migration qui favorise l’utili-sation des apprentissages et de l’expérience acquiselors des migrations précédentes. Afin de faciliter lamigration, on pourrait établir un plan de migrationqui inclurait les éléments suivants :• Analyse et spécification de la migration :

- Identification des principaux changements àeffectuer ;

• développement de la démarche de migration :- pour chaque module, identification des chan-

gements, détermination des processus, de pro-cédures et des étapes à suivre pour lamigration ;

- définition de la documentation de migrationoù il sera indiqué la démarche qui doit être sui-vie lors de la mise en œuvre de la migration ;

- développement des outils nécessaires à la migra-tion ;

• formation technique, en indiquant les modifica-tions aux composants logiciels, les changementsqui doivent être faits au niveau du code, de laconfiguration ou du système en général ;

• exécution de la migration, incluant la modifica-

tion du code, de la configuration et de la conver-sion des données si nécessaire ;

• validation et vérification de la migration, incluantles tests d’intégration qui assurent que le systèmecontinue à fonctionner comme avant la migra-tion ;

• rétrospective et évaluation de la migration.

8. CONCLUSIONLa réussite d’une migration logicielle ne dépendpas que de la technologie, mais aussi des processusde gestion et de gestion du changement ainsi qued’une bonne utilisation des ressources humaineset matérielles. Malgré l’exposition aux risques, unemigration d’architecture logicielle peut être maî-trisée grâce aux habiletés des gestionnaires et àleur expertise dans la gestion de projet. De plus,l’intégration active et la distribution des respon-sabilités dans l’équipe de développement permet-tent à cette dernière de s’impliquer davantage dansle changement à mettre en place et d’assurer saréussite.

9. RÉFÉRENCES[1] The CMMI Web Site. Carnegie Mellon. Soft-

ware Engineering Institute. http://www.sei.cmu.edu/cmm. (Consulté le 30 octobre 2006)

[2] Implementation Management Associates(IMA). http://www.imaworldwide.com/home.asp. (Consulté le 25 octobre 2006)

[3] Capability Maturity Model Integration(CMMI), Version 1.1, (2002), CMU/SEI-2002-TR-029, ESC-TR-2002-029

[4] Évaluation de la culture de l’organisation.IMA Implementation Management Asso-ciates, Inc. Lakewood, Etats-Unis, 1998

[5] Évaluation des sponsors. IMA Implementa-tion Management Associates, Inc. Lakewood,États-Unis, 1998.

[6] Test de stress organisationnel. IMA Imple-mentation Management Associates, Inc. Lake-wood, États-Unis, 2000.

[7] Évaluation des agents de changement. (1998).IMA Implementation Management Associ-ates, Inc. Lakewood, États-Unis, 1998

[8] L. Bass, P. Clements & R. Kazman : Soft-ware architecture in practice (2nd ed.) ;Boston, Pearson Education Inc., 2003

[9] D. Garlan, R. Monroe & D. Wile : Acme: Anarchitecture description language ; Compu-ter Science Department, Carnegie MellonUniversity, 1997

[10] Office québécois de la langue française.Le grand dictionnaire terminologique.http://www.grandictionnaire.com. (Consultéle 13 septembre 2006)

[11] Wikipedia. http://fr.wikipedia.org. (Consultéle 10 août 2006)

[12] R. Kazman, M. Klein & P. Clements : ATAM:Method for architecture evaluation. ; Techni-



54

cal Report. CMU/SEI-2000-TR-004. CarnegieMellon. Software Engineering Institute, 2000.

[13] M. Klein, R. Kazman, L. Bass, J. Carrière,M. Barbacci et H. Lipson : Attribute-basedarchitecture styles ; Software Architecture,Proceedings of the First Working IFIP Con-ference on Software Architecture, 1999.

[14] M. A. Côté, W. Suryn, R. Martin et C. Y.Laporte : Evolving a corporate softwarequality assessment exercise: A migration pathto ISO/IEC 9126 ; Software Quality Profes-sional, vol. 6, n° 3, ASQ, 2004.

[15] ISO/CEI 9126 -1, Software Engineering –Product Quality - Part 1: Quality Model,2001, Organisation internationale de nor-malisation/Commission électrotechniqueinternationale, Genève,Suisse.

[16] Unified Modeling Language. http://www.uml.org. (Consulté le 20 novembre 2006)

[17] IBM Rational Software. http://www-306.ibm.com/software/rational. (Consulté le20 novembre 2006)

[18] Borland Together. http://www.borland.com/us/products/together/index.html. (Consultéle 20 novembre 2006)

[19] L. Kontogiannis, J. Martin, K. Wong, R. Gre-gory, H. Müller & J. Mylopoulos : Codemigration through transformations: An expe-rience report ; Université de Victoria, Uni-versité de Toronto.

[20] D. Dikel, D. Kane et J. R. Wilson : Softwarearchitecture, organizational principles andpatterns (1st Ed.) ; N.J., Prentice-Hall Inc.,2001

[21] I. Jacobson, M. Griss et P. Jonson : Softwarereuse: Architecture, process, and organiza-tion for business success ; New York, ACMPress, 1997

[22] ISO/IEC 12207: 1995. Standard for Infor-mation Technologie - Software life cycle pro-cesses - Implementation considerations, avril1998.

[23] The Standish Group. « The CHAOS Report(1994) ». http://www.standishgroup.com/sample_research/chaos_1994_1.php. (Con-sulté le 12 novembre 2006)

[24] KMPG. « Que s’est-il passé ? L’échec desprojets de technologie de l’information »,1997. http://www.kpmg.ca. (Consulté le 12novembre 2006)

[25] Organisation de coopération et de dévelop-pement économiques (OCDE) : « Gestiondes grands projets d’informatisation dans lesecteur publi : définitions et concepts ».http://www.oecd.org/document/41/0,2340,fr_2649_37441_1916393_1_1_1_37441,00.html.(Consulté le 12 novembre 2006)

[26] M. J. Christensen et R. H. Thayer : The pro-ject manager’s guide to software engineer-ing’s best practices (1st Ed.) ; IEEE ComputerSociety, 2001

[27] ISO/IEC 12207.0: 1996. Standard for Infor-mation Technologie - Software life cycle pro-cesses. 1996.

[28] C. Morley : Management d’un projet sys-tème d’information (4e éd) ; Paris : ÉditionsDunod, 2004

[29] R. Agarwal, M. Tanniru et D. Wilemon : Assi-milating information technology innovations:Strategies and moderating influences ; IEEETransactions on Engineering Management,vol. 44, n° 4, novembre 1997.

[30] M. R. Barbacci et R. Kazman : SoftwareArchitecture Evaluation Panel ; SoftwareEngineering Institute, Carnegie Mellon Uni-verity.

[31] M. Corrales, Y. Corrales, M. Foisy et H.Zaky : Évaluation du niveau de maturité del’organisation. Évaluation du processus demigrations technologiques et son impact dansl’équipe de développement ; École de tech-nologie supérieure, 2004

[32] The Standish Group ; http://www.standish-group.com. (Consulté le 12 novembre 2006)

[33] L. Zhu L., M. Ali Babar et R. Jeffery : Min-ing patterns to support software architectureevaluation ; National ICT Australia Ltd. etUniversity of New South Wales, Australie.

[34] L. Zhu, M. Ali Babar et R. Jeffery : A frame-work for classifying software architecture eval-uation methods ; National ICT Australia Ltd.et Université de New South Wales, Australie.

NOTES

1 Entièrement en français2 ® Marque enregistrée ou inscrite sur le Registre

des marques de commerce par l’Université Car-negie Mellon de Pittsburgh.

3 « Framework » est traduit en français par « logi-ciel intégré » : logiciel d’application qui com-bine sur un même support les logiciels courantsd’un bureau » [10]. Ce terme est utilisé dans leprésent article pour en faciliter la compréhen-sion.

4 Réseau fédérateur, traduction de l’anglais « back-bone » défini comme « la partie centrale surlaquelle repose un réseau de télécommunicationcaractérisé par son haut débit, qui permet d’in-terconnecter des réseaux plus petits, à l’intérieurd’une entreprise, d’une région ou de vastes ter-ritoires » [10].

5 Une clé étrangère est un champ de base de don-nées de type clé primaire inscrit dans une tablesecondaire ou table fille permettant la jointure àla table primaire ou table parent [11].

6 Le modèle de communication est le moyen utilisépour classifier et identifier comment l’informa-tion est gérée dans la communication.

7 « Proxy » traduit en français par « serveur man-dataire » : élément de coupe-feu servant d’inter-médiaire entre le navigateur d’un internauteutilisant un réseau local et le serveur Web qu’il



55

veut consulter, permettant ainsi de sortir du réseaulocal et d’y entrer, sans mettre en danger la sécu-rité de ce dernier [10].

8 « Load balancing » est traduit en français par« équilibrage de charge » : distribution de tâchesou de communications au sein d’un réseau pouren améliorer les performances.


L'AFTI - Depuis sa création en 1991, l'AFTI a pour vocation d'accompa-gner les jeunes diplômés vers un premier emploi dans une entreprise dehaute technologie.

Implanté à Orsay en région parisienne, le Centre de Formation d'Apprentis AFTI propose auxjeunes une solution qui concilie une montée en compétence dans des domaines particulière-ment pointus avec une réelle expérience professionnelle.

De plus en plus d'entreprises leaders sont partie prenante de cette nouvelle dynamique :Thales, Renault, Alcatel-Lucent, France Telecom, MBDA, Osiatis, SFR, ATOS Origin sontmembres de l'AFTI. Plus largement, une centaine de sociétés, dans des domaines les plusdivers, sont au cœur du projet éducatif. Toutes partagent le même niveau d'exigence profes-sionnelle et l'ambition de participer activement à la « montée en puissance » des jeunesembauchés.

L'Ingénierie logicielle et l'alternance - L'ETGL est la formation d'ingénieur logiciel de l'AFTI.Elle propose l'apprentissage par alternance sur deux ans. Le rythme, 5 mois en centre de for-mation puis 7 mois en entreprise sur les deux années, est ajusté au cycle de vie de productionlogiciel et choisi pour son efficacité. Il permet aux entreprises de se doter d'ingénieurs logicieladaptés à leurs exigences opérationnelles.

La Formation - Les formations sont de type professionnelles, par modules de 2 à 7 jours. Àcôté des techniques et langages de base (de l'assembleur, à C#/.Net en passant par la concep-tion objet et J2E), l'apprenti découvre et applique les méthodologies (gestion de projet, deconfiguration sous ClearCase, des exigences sous DOORS, CMMI, revues de pairs…). Les for-mateurs sont issus des entreprises, et chaque formation est ainsi l'occasion de lier un contenuà une expérience vécue. Au delà des travaux pratiques, ce sont les projets, répartis sur la pério-de, qui permettent aux apprentis de mettre en application leurs connaissances pour en fairede vraies compétences. Ils appréhendent ainsi l'ensemble du cycle de développement, maisaussi, lors de jeux de rôle, les différentes responsabilités (interfaces, planification, qualité,configuration, recette client).

Les missions confiées - Les missions confiées par les entreprises sont variées. Si la premièrepériode débute souvent par de la maintenance logicielle (corrective ou évolutive) et de l'IHM,les entreprises n'hésitent plus à confier les spécifications et la conception à un apprenti ETGL,ou un développement logiciel complet, une recette client…

L'Ingénierie Système - L'ETGL prend également en compte l'évolution vers l'ingénierie sys-tème, au travers d'une option, proposée sous forme de projet. En partenariat avec leCNES/PlanèteSciences, l'AMSAT et l'IUT de Ville d'Avray, les apprentis doivent lancer un ballonatmosphérique. Ils disposent ainsi d'un vrai client, vrai co-traitant et vrai sous-traitant, pour unprojet où le maître mot est la multidisciplinarité (environnement, mécanique, électronique,logiciel).

Contact - www.cfa-afti.com [email protected] (responsable pédagogique)

[email protected] (relations entreprises)

Documents

GÉNIE LOGICIEL N o 82 SEPTEMBRE 2007 RETOUR … · Puis, on a réalisé une analyse du contexte organisationnel avec l’équipe de développement et la direction, ... évaluations