Formation d’Ingénieur Maître - fimcachan.free.frfimcachan.free.fr/Map2003/mapsyurdakul.pdfDans sa volonté de moderniser ses méthodes de développement, Ericsson utilise depuis

Formation d’Ingénieur Maître Sami Yurdakul

Session 2003

Déploiement du Langage SDL dans les systèmes de réseaux de télécommunication

Formation d’Ingénieur – Maître 2003 Mémoire d’Activité Professionnelle - Sami Yurdakul 2 / 70

MEMOIRE D’ACTIVITE PROFESSIONNELLE

Nom de l’auditeur : Sami Yurdakul

Fonction : Développeur Logiciel Télécoms

Durée du Projet : 6 mois +1 anDates: janvier – juillet 2001

janvier – décembre 2002

Nom de l’entreprise : Ericsson puis Teleca Solutions

Adresse : Teleca1, rue Galvani 91300 Massy

Tél. : 01 64 53 40 00Service : Développement Réseaux IntelligentsNom du Responsable : Pierre ZiniFonction : Responsable Département

Libellé du Projet : Déploiement du Langage SDL dans les systèmes de réseaux de télécommunication

Résumé :

Dans sa volonté de moderniser ses méthodes de développement, Ericsson utilise depuis quelquesannées SDL (Specification and Description Language) pour concevoir et réaliser le logiciel descommutateurs de réseaux de télécommunications. SDL est un langage informatique formel etstandard permettant de décrire graphiquement les spécifications et les conceptions de systèmesdistribués, de leur architecture jusqu’à leur fonctionnement dynamique.

Je me suis investi dans cette tâche à plusieurs niveaux.Ma participation dans les différents projets mettant souvent en œuvre ce langage, a concerné aussibien la conception que le développement, la coordination technique, le test, le support, et laformation. J’en ai tiré une double expérience : celle des systèmes sur lesquels je travaillais, avec leursfonctionnalités et leurs protocoles, et une certaine expertise dans le langage et logiciel SDL.J’ai ainsi aidé, en étroite collaboration avec d’autres experts, à l’amélioration et à l’adaptation deSDL dans les Méthodes et Outils de développement spécifiques à Ericsson notamment dans uncycle de développement itératif et incrémental.

J’ai choisi d’illustrer cette expérience à travers deux projets représentatifs et complémentaires. Lepremier, Prototype SDL pour l’Espagne, a eu pour but de former une équipe à ce langage etd’évaluer son utilisation sur un système existant. Ensuite, j’ai obtenu un rôle de coordination SDLdans un projet à grande échelle, préparant la téléphonie de troisième génération : Mobile SwitchCenter 3.0.

Mots clés : SDL, Conception, Modélisation, Simulation, Coordination, Méthodes, Outils, CycleItératif et Incrémental.Date de la Soutenance : 4 septembre 2003Nombre de pages : 56 Notes du destinataire :



AAvvaanntt PPrrooppooss

Bien que mon employeur actuel soit la société Teleca Solutions, ce mémoire porte surles activités que j’ai entreprises lors de ma carrière au sein de la société Ericsson France.

En juin 2002, Ericsson France a cédé son département Recherche & Développementauquel j’appartenais à Teleca Solutions, nouvelle filiale du groupe Teleca, société de prestationde services. Mon expérience professionnelle concerne donc essentiellement la période précédent ce transfertd’activités. De plus, Ericsson est jusqu’à présent l’unique client de Teleca Solutions, et monenvironnement de travail n’a pas encore été sensiblement affecté par ce changement.

C’est pourquoi je ne parlerai dans ce mémoire de Teleca Solutions qu’uniquement dansle but de comprendre les enjeux se présentant à moi pour l’avenir.

Mes fonctions, missions, et activités seront analysées dans le contexte d’Ericsson.



SSoommmmaaiirree1. INTRODUCTION ________________________________________________________________ 6

2. FORMATION ET PARCOURS PROFESSIONNEL _____________________________________ 72.1. COMMENTAIRE DE MON PARCOURS UNIVERSITAIRE __________________________________________ 82.2. COMMENTAIRE DE MON PARCOURS PROFESSIONNEL _________________________________________ 8

3. PRÉSENTATION D’ERICSSON ET DE TELECA ______________________________________ 103.1. LA SOCIÉTÉ ERICSSON _______________________________________________________________ 103.2. ERICSSON FRANCE __________________________________________________________________ 143.3. LA SOCIÉTÉ TELECA SOLUTIONS _______________________________________________________ 143.4. PRÉSENTATION DU SERVICE IN-SSF_____________________________________________________ 15

4. MES ACTIVITÉS PROFESSIONNELLES ____________________________________________ 164.1. MES FONCTIONS ____________________________________________________________________ 164.2. SPECTRE DES ACTIVITÉS ______________________________________________________________ 174.3. CRITÈRES DE PERFORMANCES _________________________________________________________ 184.4. MES INTERLOCUTEURS INTERNES ET EXTERNES ____________________________________________ 19

5. DÉPLOIEMENT DU LANGAGE SDL DANS LES SYSTÈMES DE RÉSEAUX TÉLÉPHONIQUES 215.1. DEUX PROJETS, DEUX FACETTES DU DÉPLOIEMENT _________________________________________ 215.2. SDL _____________________________________________________________________________ 225.3. LE PROJET PROTOTYPE SDL EN ESPAGNE ________________________________________________ 235.4. LE PROJET MOBILE SWITCH CENTER 3.0 _________________________________________________ 335.5. BILAN TECHNIQUE DE MES ACTIVITÉS____________________________________________________ 38

6. OPTIMISATIONS MISES EN ŒUVRE ______________________________________________ 396.1. OPTIMISER LE TRAVAIL D’ÉQUIPE_______________________________________________________ 396.2. OPTIMISER LES OUTILS _______________________________________________________________ 396.3. OPTIMISER LE PRODUIT_______________________________________________________________ 40

7. LES COMPOSANTES DU MÉTIER D’INGÉNIEUR-MAÎTRE ___________________________ 417.1. LE DÉVELOPPEMENT LOGICIEL _________________________________________________________ 417.2. GESTION DE PROJET _________________________________________________________________ 427.3. SOUTIEN ET TRANSMISSION DU SAVOIR __________________________________________________ 437.4. EVALUATION DES COÛTS _____________________________________________________________ 437.5. RÉCAPITULATIF DES COMPOSANTES DE L’INGÉNIEUR ________________________________________ 44

8. THÈME D’ETUDE : LES OUTILS LOGICIELS DE L’INGÉNIERIE CONCOURANTE _______ 458.1. INTRODUCTION _____________________________________________________________________ 458.2. DÉFINITION DE L’INGÉNIERIE CONCOURANTE OU SIMULTANÉE ________________________________ 458.3. L’INGÉNIERIE CONCOURANTE ET LES INDUSTRIES __________________________________________ 468.4. L’INGÉNIERIE CONCOURANTE ET ERICSSON_______________________________________________ 468.5. LES OUTILS LOGICIELS DE L’INGÉNIERIE CONCOURANTE _____________________________________ 478.6. CONCLUSION : INGÉNIERIE CONCOURANTE OU CONCEPTION PARALLÈLE ? _______________________ 51

9. CONCLUSION TECHNIQUE _____________________________________________________ 52

10. CONCLUSION GÉNÉRALE ______________________________________________________ 53

BIBLIOGRAPHIE ___________________________________________________________________ 54

TABLE DES ILLUSTRATIONS ________________________________________________________ 55

ANNEXES _________________________________________________________________________ 56



GGlloossssaaiirreeAXE 10 Système de commutation numérique (local, de transit, ou international) pour téléphonie

fixe ou mobile.Brainstorming Technique de travail consistant à rassembler un groupe de personnes afin que naissent, de

leur confrontation, des idées nouvelles.Non Régression(test de)

Test ayant pour but de vérifier que la nouvelle version du produit fonctionne avec les casde tests relatifs à la version précédente (compatibilité antérieure).

PLEX Langage propriétaire d’Ericsson basé sur l’exécution de tâches dédiées au commutateurAXE10, en réponse à une réception de message.

ReverseEngineering

Méthode de programmation, parfois automatisée, consistant à partir d’un programme écriten langage d’une couche inférieure pour le réécrire en langage de couche supérieure(exemple : écrire du C à partir de l’assembleur).

Statechart Diagramme d’état représentant une vue comportementale du système et décrivant defaçon formelle et modulaire les transitions.

Workpackage « Lot de travail » : module d’un projet autour d’une fonctionnalité ou d’un groupe defonctionnalités.

Workshop Forum, présentation, formation, atelier de discussion.

DDiiccttiioonnnnaaiirree ddeess SSiigglleessATM Asynchroneous Transfer Mode Technologie de transport de voix et de données.ASN.1 Abstract Syntax Notation .1 Langage normalisé et abstrait de spécification de la

structure des données échangéesCORBA Common Object Request Broker

ArchitectureArchitecture d’objets distribués répondant aux besoinsd’homogénéisation du développement etd’interopérabilité (voir IDL).

CTI Computer & Telephony Integration Commutation Téléphonie & Informatique pourentreprises.

GPRS General Packet Radio Services Technologie visant à fournir un accès simple et rapide àl’information dans un réseau Telecom ( évolution duGSM).

GSM Global System for Mobilecommunications

Norme de Téléphonie Mobile

HMSC High level Message Sequence Chart Diagramme regroupant des MSC (Message SequenceChart).

IDL Interface Description Language Langage décrivant l’interface des objets, c’est-à-direleur nom, leurs méthodes et leurs attributs, de façonindépendante du langage d’implantation.

IN-SSF Intelligent Network – Service SwitchingFunction

Architecture de réseaux permettant une plus grandefacilité d’introductionde nouveaux services.SSF est la partie de commutation des services du réseaude téléphonie.

IP Internet Protocol Protocole largement utilisé pour transporter les donnéesMSC Mobile Switch Center Centre Téléphonique de Commutation du réseau mobileMSC Message Sequence Chart Diagramme décrivant le séquencement des messages

échangés entre des processus dynamiques (voir SDL).SDL Specification and Description Langage Langage de spécification et de description.TTCN Tree and Tabular Combined Notation Langage de notation de cas de tests.UIT Union Internationale des

TélécommunicationsOrganisme officiel de réglementation desTélécommunications.

UML Unified Modeling Language Langage de modélisation objet unifié.UMTS Universal Mobile Telecommunications

SystemNorme de téléphonie mobile permettant d’avoir desservices multimédias à débits très élevés (voir GSM etGPRS).



1. Introduction

Au cours de ma carrière de cinq années au sein d’Ericsson, j’ai participé au développementlogiciel des commutateurs placés au cœur des réseaux de télécommunication, au travers denombreux projets internationaux.

Dès le début, je me suis spécialisé dans un domaine ; SDL (Specification and DescriptionLanguage), un langage standard permettant de spécifier et de décrire de façon formelle etgraphique des systèmes distribués réagissant sur des événements, de les modéliser, et degénérer certains langages cibles, dont le C, le C++ et surtout le langage propriétaire d’Ericssongrâce à certaines adaptations logicielles.J’ai activement contribué au déploiement progressif de ce langage, qui a considérablementmodifié le paysage du développement chez Ericsson.

Je débuterai donc ce mémoire d’activité professionnelle par un historique de mon parcoursuniversitaire et professionnel. Puis, je présenterai dans ses grandes lignes le groupe Ericsson etses produits (notamment le commutateur numérique AXE10) de l’échelle mondiale jusqu’àl’ensemble de mon service. Pour finir cette partie, je parlerai des différents aspects de mesactivités et missions.

Avant de proposer deux projets complémentaires et représentatifs de mon implication dans ledéploiement de SDL, j’introduirai sommairement ce langage et ses caractéristiques.J’approfondirai ensuite les tenants et aboutissants du projet Prototype SDL qui s’est déroulé àEricsson Madrid durant six mois. Durant ce projet, j’ai eu pour mission de former une équipede cinq personnes sur ce langage, avec l’objectif de conclure sur une utilisation future.Je montrerai après cela l’importance qu’a pris SDL dans le projet suivant : Mobile SwitchCenter 3.0, et quel rôle j’ai eu dans un projet d’une ampleur conséquente.

Nous verrons aussi quelles optimisations supplémentaires j’ai apportées à ces projets. Jerecapitaliserai ensuite les fonctions de l’ingénieur mises en relief par ma participation audéploiement de SDL dans le cycle de développement du produit logiciel.

Je terminerai alors par une réflexion sur les outils logiciels de l’Ingénierie Concourante. Ainsinous verrons que SDL est au cœur d’une suite de logiciels s’inscrivant dans une nouvelle façonde concevoir.

Cela me permettra de conclure sur les enjeux d’aujourd’hui et de demain et de déterminer enquoi mes connaissances et mes compétences peuvent me permettre d’y répondre.



2. Formation et parcours professionnel

Ci-dessous est résumé mon parcours universitaire puis professionnel. Il est suivi d’uncommentaire chronologique détaillé.

Stage entrepris au CEA de Saclay :Expérimentation de vitesse departicules

Baccalauréat Scientifique (série D)Lycée Descartes à Antony (92)

DUT Génie Electrique et Informatique Industrielle 2IUT de Cachan (94)

1ère année Ecole d’Ingénieur IFSIC de Rennes

Licence ProfessionnelleSystèmes Electroniques Informatisés (SEI)IUT de Cachan (94)

Développeur Logiciel TelecomCDI TELECA SOLUTIONS Massy(91)Transfert d’activités du département R&D d’Ericsson France

Stage entrepris dans la sociétéCTM (appareils pour le cinéma etla télévision) à GennevilliersCommande d’une carte vidéo àpartir d’un PC puis d’un micro-contrôleur 68HC11

1992

1994

1995

1997

JuilletAoût1997

Sept1997

Réalisation d’un logiciel en Visual C++CDD, société PERICHROM (instrumentation scientifique)

Nov.1997

Développeur Logiciel TelecomCDI EERRIICCSSSSOONN FFrraannccee Massy (91)Projets de Développements

Systèmes Réseaux Intelligents de téléphonie fixe et mobile:• Exemples de fonctionnalités mises en œuvre :

Identification d’appel,Portabilité du Numéro,Taxation,Migration vers 3ème Génération de Téléphonie (UMTS).

• Phases: Spécification, Conception, Codage, et Tests (unitaires et d’intégration).Spécialisation en langage SDL (plate-forme Telelogic Tau)

• au cours des projets de développement• Méthodes et Outils

Déplacements en Europe

Juin2002

Commande d’enrouleur de pellicule avec un micro-contrôleur68HC11CDD suivant le stage SEI, société CTM

2003



2.1. Commentaire de mon parcours universitaire

J’ai engagé mes études en 1992 par un DUT en Génie Electrique et InformatiqueIndustrielle (GEII2), passé à Cachan, afin de m’orienter vers des études technologiques. Il est ànoter que mon stage de fin d’année, qui s’est déroulé au CEA de Saclay, sur l’expérimentationde vitesse de particules, m’a démontré que mes connaissances pouvaient s’adapter à desdomaines parfois appartenant plus à la recherche scientifique qu’à l’industrie proprement dite.

Mon intérêt s’est alors orienté plus vers l’informatique industrielle que l’électronique, etj’ai donc poursuivi mes études en m’inscrivant à l’IFSIC de Rennes : Institut de FormationSupérieur d’Informatique et (Télé)Communications.

Malheureusement, cette première année s’est soldée par un échec, mais un échec formateur.Sans doute n’étais-je pas prêt à maîtriser le niveau de raisonnement informatique etmathématique requis. Cependant, je me suis rendu compte par la suite à quel point cette annéen’a pas été perdue sur le plan universitaire et personnel.

La licence professionnelle Systèmes Electroniques Informatisés (SEI), proposée parl’IUP de Cachan, m’a offert l’année suivante un bon compromis entre ma poursuite d’étudesavortée et l’entrée dans le monde du travail à bac + 2. Cette fois encore, le stage de fin d’annéem’a apporté une expérience non négligeable.

Il s’est effectué au sein de CTM (Compagnie des Travaux Mécaniques), à Gennevilliers,société produisant des machines pour le monde du cinéma et de la télévision (chaînes demontage de films, sous-titrage, etc.). J’ai créé une maquette commandant une carte vidéo/audioafin de hacher numériquement un signal audio, au moyen d’un micro-contrôleur 68HC11 deMotorola. Mon travail a été apprécié et mon employeur m’a proposé un CDD pour les quelquesmois suivants.

2.2. Commentaire de mon parcours professionnel

Au cours de ce CDD dans l’entreprise CTM, j’ai réalisé un prototype – toujours avec le68HC11- de contrôleur de dérouleur de pellicules. Cependant, aucun poste intéressant n’étantvacant dans cette entreprise, j’ai commencé à chercher un emploi à durée indéterminée.

En attendant d’obtenir un tel contrat, l’entreprise Perichrom - dont l’activité résidedans la production et la vente d’appareils de mesure de Chromatographie en Phase Gazeuse-m’a proposé un CDD de quelques mois.J’ai ainsi réalisé quelques programmes écrits en Visual C++, permettant par exemple decontrôler à partir d’un PC un robot manipulant des flacons de liquides.

C’est sans difficulté que j’ai trouvé par la suite un emploi intéressant en novembre1997, au sein d’Ericsson France.



A mon embauche, j’ai intégré le département de Recherche & Développement et plusprécisément le service des Réseaux Intelligents (système logiciel de Services de TéléphonieFixe).Là, j’ai eu l’opportunité d’intégrer une équipe travaillant sur un projet innovant. Ce projets’appuyait sur les méthodes de travail en vigueur mais au lieu de réaliser le logiciel dans lelangage propriétaire d’Ericsson, il proposait d’utiliser un langage graphique, standard et évoluéqui est le sujet de ce mémoire : SDL.

Ensuite, en 1999, j’ai intégré un projet plus « traditionnel » , ce qui m’a permis derenforcer mes connaissances dans le métier de base d’Ericsson. J’ai accepté la propositiond’aller à Madrid durant trois mois afin de transférer leurs connaissances sur le système pourque notre département en France puisse en assumer la nouvelle responsabilité.

Entre-temps, le langage SDL commençait à faire ses preuves et ses « convertis »,partout dans le monde Ericsson. Par conséquent des méthodes non plus locales mais globalesdevaient être sérieusement mises en œuvre. Pour cela, je suis allé en janvier 2000 une semaineà Aachen (Aix-la-Chapelle) en Allemagne, afin de participer à un brainstorming∗ et unworkshop∗ sur le sujet.

Fort de cette avancée, j’ai participé en 1999-2000 à un nouveau projet utilisant SDL.

Puis, en 2001, Ericsson Madrid m’a proposé une mission de six mois. Le projet que j’aiintégré était le premier dans le département à mettre en place le langage SDL. Il devait à sonterme permettre d’anticiper de futurs développements en SDL.

Or, depuis l’année 2000 environ, un travail important et ambitieux dans les Systèmesdes Commutateurs pour la Téléphonie Mobile avait été dirigé par Ericsson Allemagne afin deconvertir des centaines d’unités de logiciel en SDL. C’est ainsi qu’en 2002, j’ai travaillé enFrance sur le projet Mobile Switch Center 3.0, dans un projet qui a duré environ un an.

Tous ces projets ont eu pour objectif de répondre aux besoins des opérateurs en termesde services pour les abonnés. Cela concernait par exemple la présentation du nom de l’abonnésur le combiné téléphonique, la portabilité du numéro (changer d’opérateur en gardant le mêmenuméro), ou encore la facturation de ces services.

Mais suite à la crise des Télécoms survenue en 2001, Ericsson France a cédé en juin2002 son département R&D à une SSII suédoise : Teleca.

Jusqu’à maintenant, 2003, cela n’a pas changé sensiblement notre quotidien puisque nouscontinuons à travailler pour Ericsson (notre client principal). Mais ce nouveau contexte, ainsique le changement d’activité prévu à moyen terme, a rendu le moment des plus opportuns pourmoi de réaliser la Formation d’Ingénieur-Maître que j’avais depuis longtemps envisagée.

∗ voir glossaire



3. Présentation d’Ericsson et de Teleca

Comme cela a été expliqué dans l’avant propos de ce mémoire, je ferai maintenant uneprésentation d’Ericsson suivie d’une rapide présentation de Teleca.

3.1. La Société Ericsson

3.1.1. Ericsson Monde

Ericsson est une multinationale d’origine suédoise, existant depuis 125 ans (1876),présente dans 140 pays, avec un chiffre d’affaires de plus de 24,6 milliards d’euros en 2001 etest parmi les leaders dans le domaine des Télécommunications.

Quand on parle d’Ericsson, le grand public pense immédiatement « téléphone portable »et beaucoup de gens sont persuadés que son activité se limite principalement à cela.Or, les terminaux (mobiles ou fixes) n’ont toujours été qu’une partie très mineure de saproduction, et ne fait même plus partie de ses activités depuis la création de la nouvelle entitéSony-Ericsson.Le métier d’Ericsson, c’est donc surtout d’équiper la plupart des opérateurs téléphoniques et lesentreprises en infrastructures et réseaux téléphoniques.

Ericsson est un des premiers fournisseurs mondiaux d’infrastructures mobiles,permettant ainsi d’assurer 40% des appels GSM dans le monde actuellement. Il a signé 60%des accords GPRS* conclus dans le monde jusqu’ en 2002 et est impliqué dans plus de 30accords commerciaux UMTS*.Ericsson est aussi le numéro 1 mondial de la téléphonie fixe avec 250 millions de lignesinstallées dans 127 pays.

Plus de 15% du Chiffre d’Affaires est consacré chaque année à la Recherche & Développementdepuis plus de 10 ans.

* voir Dictionnaire des sigles



3.1.2. Organisation du Groupe

Ericsson a une organisation matricielle, illustrée par la figure 1, répartie en :• secteurs géographiques pour assurer la proximité avec ses clients,• secteurs d’activités pour prendre en compte les besoins spécifiques de chaque marché.

1. Secteurs géographiquesLa nouvelle répartition géographique mise en place en septembre 2001 est fondée surune logique de service et de proximité.Ainsi, trois régions ont vu le jour dans la nouvelle répartition :

- Europe, Afrique et Moyen-Orient,- Amérique,- Asie, Pacifique.

De plus a été mise en place la notion de Grands Comptes pour gérer les 6 clients les plusimportants :

- Deutsche Telecom (Allemagne),- TIM (Italie),- France Telecom (France),- Telefonica (Espagne),- Vodafone (Grande-Bretagne),- Hutchinson (USA).

2. Secteurs d’activitésEricsson est structuré autour de trois pôles d’activités :

- les opérateurs de réseaux,- les solutions Entreprise,- les produits grand public (aujourd’hui gérés par la nouvelle entité Sony-

Ericsson).

Figure 1 Organisation du Groupe Ericsson (simplifiée)

Grands Comptes ClientsSecteurs de Marché

AsiePacifique Amériques

EuropeAfriqueMoyenOrient

DeutscheTelecom

FranceTelecom

TelecomItalia Telefónica Vodafone Hutchison

Opérateurs Réseaux

Solutions Entreprises

Produits Grand Public



3.1.3. Ericsson et les réseaux téléphoniques

Un produit très important qui est un peu le fer de lance d’Ericssondans les réseaux de télécommunication est l’AXE 10. C’est un commutateur(local, de transit, ou international) numérique, complet et performant,pouvant traiter en temps réel d’importants volumes de trafic (par exempledes appels téléphoniques).

Il est présent dans tous les types de réseaux téléphoniques, comme le montre de manièresimplifiée la figure 2.

Figure 2 Les applications du commutateur AXE 10 dans les différents réseaux téléphoniques

Par signalisation, on entend tous les messages transitant dans les réseaux ; qu’ils serventà signaler une sonnerie chez l’appelant, le décrochage du combiné, ou de façon plus complexela transition de paquets de données. Lors de ma mission en Espagne pour mettre en place le projet Prototype SDL, présenté dans cemémoire, j’ai intégré le département responsable d’un sous-système de ce réseau gérant leprotocole de signalisation « C7 ».

Réseau deSignalisation

RéseauIntelligent

RéseauMobile

RéseauPrivéVirtuel

Business Comm.

Réseau Public FixeRéseau Public

Numérique(ISDN : Integrated ServicesSwitching Digital Network)



Quant aux Réseaux Intelligents, ils sont constitués de deux points : la partiecommutation et la partie contrôle de services. La première va appeler la seconde selon certainsévénements (par exemple la réception de chiffres envoyés en appuyant sur les touches dutéléphone), et peut ainsi exécuter certaines actions selon le scénario inscrit dans le contrôleur deservices, comme diriger l’appel vers un autre numéro. C’est ainsi que sont réalisés de nombreux services tels que :- les appels de masses (exemple : téléthon, télé-achat) ;- l’identification de l’appelant par le nom en liste blanche ;- la portabilité du numéro qui permet à l’abonné de changer d’opérateur tout en gardant le

même numéro ;- la conférence à plusieurs ;- etc…C’est dans la première partie, celle de commutation, que se situe l’activité de mondépartement : IN SSF, Intelligent Network Service Switching Functions.

Cependant, nous avons eu aussi en 2001 la responsabilité d’une partie du système du réseaumobile ce qui m’a permis de travailler sur le projet Mobile Switch Center 3.0, que je détailleraidans la suite de ce mémoire.

Pour être adaptée aux applications spécifiques de chaque réseau, la partie logicielle ducommutateur possède une architecture modulaire constituée de différents systèmes.

Ainsi un de ces systèmes contient les fonctions de commutation de services pour les réseauxintelligents, tandis qu’un autre prend en charge un protocole de communication propre aumobile, etc…

Ces systèmes sont complexes, et eux-mêmes décomposés en sous-systèmes, voire ensous – sous-systèmes, jusqu’à la décomposition en blocs.Un bloc va contenir le code à exécuter pour une ou plusieurs fonctions, c’est donc l’unité quiest attribuée à un ou plusieurs développeurs lors d’un projet.



3.1.4. Ericsson France

Présent dans l’hexagone depuis 1911, Ericsson France S.A. est située à Massy (Essonne) etpropose des solutions bout en bout pour ses clients, qu’ils soient opérateurs de réseaux fixes etmobiles ou entreprises.

Les activités et les produits dédiés aux opérateurs sont respectivement:• la conception et l’ingénierie de réseaux, l’installation, la mise en service de

systèmes, la formation et la maintenance ;• des systèmes de commutation AXE pour les réseaux fixes, des plates-formes et

des services en architecture Réseaux Intelligents, des systèmes d’exploitation etde maintenance de réseaux, et des solutions d’accès (Boucle Locale Radio,ADSL).

Les Solutions pour l’Entreprise se traduisent par :• Le conseil, la conception, le développement, le marketing, la vente,

l’installation, et le support produit ;• Sa gamme de produits : des systèmes de commutation MD Evolution, des

logiciels de Couplage Téléphonie Informatique, ainsi que le sans-fil numérique.

3.2. La Société Teleca Solutions

Le groupe Teleca, fort de ses 1200 personnes présentes dans toute l'Europe au travers deses différentes filiales a pour objectif global d'apporter la compétence de ses équipes dans lesdomaines suivants :

• Réseaux – développement d'infrastructures (relais, commutateurs, routeurs, modems,etc.)

• Opérateurs – accès aux réseaux et services réseaux – auprès des opérateurs detéléphonie mobile, ISP, etc.

• Equipements – par exemple téléphone mobile, PDA, systèmes de contrôle etéquipements médicaux – les équipements utilisés pour communiquer sur le réseau.

• Services – les applications et services supportés par les équipements et fournis enréseau.

Ses clients viennent principalement de l’industrie des Télécoms mais aussi de l’aéronautique,l’automobile, la médecine, la défense, la TV numérique, …

La Société à Actions Simplifiées Teleca Solutions (environ 150 personnes) reprend doncprincipalement les activités du département Recherche & Développement d’Ericsson France(développement Réseaux Intelligents et Solutions Entreprises), et a pour principal clientaujourd’hui le groupe Ericsson.



3.3. Présentation du service IN-SSF

L’organigramme de la figure 3, qui n’a pas changé lors du transfert d’Ericsson versTeleca, permet de situer le service dans lequel je travaille : le développement de systèmes deRéseaux Intelligents sur le central AXE (sur le diagramme : design AXE IN-SSF, IntelligentNetwork Service Switching Function).

Figure 3 Organigramme de la R&D Ericsson / Teleca

Ce service, constitué actuellement de 30 personnes environ, techniciens ou ingénieurs, agit encollaboration avec le service System Management, composé d’une dizaine d’ingénieurs, quimet en place les projets, analyse l’architecture et les impacts.Les tests d’intégration et la maintenance des produits finis sont assurés par le service ProductSupport, avec 10 techniciens et ingénieurs.

D’autres domaines sont couverts par la direction des opérations : le développement de systèmespour le commutateur de données asynchrones ATM∗, ainsi que le commutateur Téléphonie /Informatique d’entreprise dénommé MD Evolution. Enfin, un département appelé InnovationLaboratory (I-Lab sur le diagramme) travaille sur de nouvelles technologies telles que le Wapet BlueTooth.

∗ voir Dictionnaire des sigles

Direction des Opérations

- Administration- Qualité- ...

- Ressources Humaines- Finances

AXE IN-SSF(Réseaux Intelligents)

System Management Design Product Support

ATATM(Voix Sur IP)

I-Lab(Nouvelles

Technologies)

MD Evolution(CTI)



4. Mes activités professionnelles

4.1. Mes fonctions

En tant que technicien supérieur en études logicielles (software), je me suis vu confierl’étude d’objets principalement unitaires (blocs fonctionnels), dans l’environnement de travailpropre à la partie logicielle du commutateur AXE-10.

Dans le cadre de la fonction de technicien supérieur en études logicielles, mes missions ont étéde développer, au sein des projets, des fonctions liées aux différents services téléphoniques,dans la partie commutation d’appel.

A partir de choix d’architectures et de spécifications techniques qui m’étaient fournies et pourun sous-système ou un sous-ensemble donné, je devais:

assurer, dans le cadre de normes définies, la conception détaillée d’un module, d’unensemble de base ;

réaliser ou faire réaliser les programmes, maquettes de base ou éléments de base ;

réaliser ou faire réaliser les tests unitaires dans le cadre méthodologique défini ;

assurer la maintenance des produits ;

élaborer la documentation technique associée aux produits.

A ce niveau, les activités et décisions nécessitent un support hiérarchique (supervision du chefde projet) ou fonctionnel (collaboration avec des Ingénieurs Systèmes).

Grâce à mon implication dans le langage SDL, on m’a rapidement assigné un titreparticulier: celui d ’ « expert SDL ».

Quelques années plus tard, j’ai également assumé la fonction de coordinateur SDL .

Cependant j’ai parallèlement poursuivi les activités citées précédemment, telle qu’elles sontréellement définies par mon poste. Nous verrons au cours de ce mémoire, et dès la sectionsuivante, quelles activités et compétences impliquent ces titres honorifiques, pour ensuiteanalyser en quoi elles sont des composantes de l’Ingénieur-Maître.



4.2. Spectre des activités

Une synthèse de mes activités est proposée en figure 4, sur laquelle on peut voir monimplication dans les différents domaines du développement.

Figure 4 Spectre de mes activités

Je suis donc intervenu dans la phase de l’analyse des besoins des versions successives del’outil de développement de SDL en exprimant des idées d’amélioration, et en analysant lesspécifications.

Lors de certains projets, je me suis également investi dans les phases de spécification, derédaction et de validation des nouvelles versions des documents de méthodes et de processus detravail liés à SDL.

Mais surtout j’ai participé à différents projets, essentiellement lors de la conceptionfonctionnelle et détaillée, jusqu’au codage. J’ai également assuré le suivi des produits lors dutest.De plus, j’ai pu à certaines occasions assurer une coordination technique de notre équipe avecd’autres équipes grâce à mes connaissances sur les systèmes développés.Enfin, de par mes compétences en SDL, j’ai assuré la coordination SDL avec les autres équipesdes projets et j’ai apporté mon soutien à mes collègues.

Projet Y

Version 4Version 3

… …

Version 4Version 3

Validation desdocuments… Rédaction des

documents

Spécificationdes besoins …

Définition deProcess et

Méthodes dedéveloppement

SDL

Outils dedéveloppement

SDL

Projet XPhases :(-Spécification)-Conception (Fonctionnelle et Détaillée)-Codage(Tests)

+ Coordination Technique

Activitésliées à SDL

Validation desdocuments Rédaction

des documents

Spécificationdes besoins

Développementde fonctionnalités

pour l’AXE10

temps



4.3. Critères de Performances

En adéquation avec l’ensemble des missions évoquées au chapitre précédent, lesmoyens (liés ou non à SDL, suivant l’activité) de valoriser et mesurer mes performances étaientles suivants:

• Répondre aux Points d’Actions donnés par le manager du projet ou le coordinateurtechnique supérieur ;

• Respecter les phases du cycle en V ;

• Rendre compte des problèmes techniques rencontrés par moi ou mon équipe ;

• Rendre compte des réunions et conférences téléphoniques auxquelles je participe ;

• Estimer et/ou Respecter les délais des activités ;

• Répondre aux Rapports de Fautes écrits sur mon produit dans les délais imposés ;

• Proposer des alternatives et solutions en cas de difficultés ou d’objectifs à atteindre ;

• Respecter les taux minimum d’erreurs relevées lors des tests d’intégration.

En plus de ces critères relativement identifiables, il y a bien sûr d’autres critères moinsdirectement mesurables comme la qualité de la conception (en profitant notamment de ce quepeut apporter SDL, et en essayant de limiter au maximum la charge du calculateur), lesinitiatives bénéfiques pour le projet et le suivi et l’accompagnement de l’équipe dedéveloppement.



4.4. Mes interlocuteurs internes et externes

Comme nous avons pu le constater au travers du spectre de mes activités, les relationsque j’ai eues dans mon travail quotidien étaient diverses, dépendant surtout du point de vue oùon se situe : spécifiquement SDL ou développement en général. Elles dépendaient aussi de lanature et de la complexité du projet.

Ces multiples relations sont représentées sur la figure 5. Elles sont regroupées dans troisensembles : le monde R&D Ericsson, Telelogic, et mon entourage immédiat (site local).

Figure 5 Mes interlocuteurs

Centre de compétences SDLOutils et Méthodes

Designers et CoordinateursTechniques (SDL ou non)

Autres :administration,service informatique,direction,…

Equipe de développement- Chef de Projet- Design- System Management- Product Support

Site Local(Ericsson France / Teleca Solutions)Ericsson Monde



Un projet de développement implique habituellement les trois services du départementAXE IN-SSF : je suis donc en relation avec le System Management dès la première phase duprojet, lorsqu’il s’agit d’en établir les spécifications.J’ai aussi une relation à la fois transversale au sein de mon équipe du Design concernée par leprojet, et verticale avec l’équipe de Management du projet.Enfin, et quasiment dès le début du projet, je travaille avec les testeurs appartenant au serviceProduct Support, pour répondre à leurs questions, ou leur en poser, corriger les fautes qu’ilstrouvent, et pour leur demander occasionnellement de tester une partie spécifique du code.

Autour de cela, je suis en contact avec l’administration (secrétariat, gestion de ressources) et leservice informatique (installations, licences).

Je suis aussi parfois en contact direct avec notre fournisseur d’outils logiciels SDL : Telelogic.Ce groupe, spécialisé dans les solutions pour le cycle de développement logiciel des produits,est lié par des accords de vente et de partenariat à Ericsson.

Au niveau international, je suis en contact avec d’autres développeurs, testeurs, ousystem managers sur d’autres sites. Les moyens de communications sont principalement lesréunions téléphoniques et le courrier électronique, mais il m’est arrivé aussi de me déplacer àl’étranger et inversement nous recevons régulièrement nos collègues de différents pays.

En ce qui concerne SDL, je suis inscrit à un forum électronique (mailing-list) ayant pourbut de partager questions et réponses, problèmes et solutions.Comme je participe à l’amélioration des outils et méthodes SDL, je suis en contact avec lescentres de compétence concernés (équipes associant experts d’Ericsson et de Telelogic).

Lors du projet Mobile Switch Center 3.0, j’étais en contact avec les coordinateurstechniques des sous – projets parallèles et notre coordinateur technique au niveau projet.

Après avoir situé ma position hiérarchique dans l’entreprise et mes relations internes etexternes, nous allons maintenant développer mes activités au travers de deux projets.



5. Déploiement du Langage SDL dans les systèmes de RéseauxTéléphoniques

5.1. Deux projets, deux facettes du déploiement

Je n’aborderai pas dans ce mémoire les fonctionnalités mises en œuvre durant mesdifférents projets, comme les services téléphoniques (affichage de numéro de l’abonné parexemple), ni les protocoles de télécommunications, ni même les technologies comme cellesliées à l’UMTS.Le sujet de ce mémoire étant l’introduction de SDL dans le cycle de développement logicieldes réseaux téléphoniques d’Ericsson, c’est essentiellement sous cet angle que je vais exposerle compte-rendu de mes activités.

Cependant, mon investissement dans cette tâche est une somme d’activités et de projets(environ 5 ans de travail) qu’il serait fastidieux de détailler chronologiquement.C’est pourquoi j’ai choisi de centrer mon compte-rendu d’activités sur deux projetsreprésentatifs et complémentaires.

Dans le projet Prototype SDL en Espagne, par lequel je débuterai, nous verrons quelle a étéla portée de mes compétences, dans un petit projet qui a beaucoup dépendu de moi.

Le projet suivant, Mobile Switch Center 3.0, a été très long (environ un an) et complexe. Jel’aborderai par le côté organisationnel, toujours en me focalisant sur SDL, pour mettre enévidence mon rôle que j’analyserai ensuite en tant que composantes de l’Ingénieur-Maître. Dece projet on notera ainsi quelques points intéressants que nous reprendrons dans le thèmed’étude.

Mais avant tout, il est utile d’aborder en quelques mots le langage SDL.



5.2. A propos de SDL

Pour plus d’information, vous trouverez en annexe un explicatif détaillé de ce langage etses applications.

Présentation du langage SDLSDL est un langage formel de modélisation, orienté objet etgraphique utilisé pour spécifier et concevoir des systèmesréactifs. On peut assimiler un système SDL à un ensemble deprocessus communicants par signaux. Le comportement dechaque process est représenté par une machine à états finisétendue.

Origine et historique de SDLSDL est un langage développé par l'Union Internationale des Télécommunications (UIT) àpartir de 1972. La première version officielle date de 1976. La grammaire du langage estdécrite par une norme bien spécifique : la Z100 de l'UIT.

Intérêt de SDLLe langage SDL permet de décrire un système sans ambiguïté. Outre l'amélioration de lacomplétude des modèle de spécifications ou de conceptions, cette caractéristique permetégalement la simulation et la validation d'un système. Ainsi les erreurs sont détectéesbeaucoup plus tôt dans le cycle de développement si on compare à une approchetraditionnelle.Une deuxième implication de l'utilisation de SDL est la possibilité de générer du code àpartir d'un modèle, permettant ainsi d’exécuter de grandes parties d'une application. On notera seulement 5 dimensions du langage :Structure, Communication, Données, Comportement, Héritage.

Résumé des caractéristiques du langage SDLCe langage est :

- un Standard UIT (Union Internationale des Télécommunications) ;- un Langage formel ;- Orienté Objet ;- Facilement testable ;- Portable ;- Réutilisable.

Il est utilisé principalement dans les domaines des télécommunications, de l'aéronautique etde l'espace, dans l'automobile et même dans la finance.Deux activités techniques sont principalement concernées par SDL :

- le développement de systèmes réactifs,- la modélisation et la vérification d'architecture système.

Il est à noter qu’un autre langage complémentaire décrit le fonctionnement et lecomportement séquentiel d’un système. Cet autre langage s’appelle Message SequenceChart (MSC), mais pour simplifier nous le considérerons ici comme faisant partieintégrante de SDL.



5.3. Le projet Prototype SDL en Espagne

5.3.1. Le Contexte du projet

Le centre décisionnaire de la Recherche et Développement recommande fortement - depuisenviron l’année 2000 – l’utilisation de SDL pour les blocs unitaires nouvellement créés, avecce que cela implique en compétences et besoins en formation.

Ce projet, basé à Madrid, est donc le résultat de cette stratégie visant à introduire denouveaux processus de travail dans les systèmes de l’AXE10. Le Système de Signalisation(CCS, Common Chanel Signalisation) étant développé là-bas, il leur fallait se préparer auxnouvelles recommandations.

C’est ainsi que j’ai intégré une équipe de six personnes : quatre nouveaux embauchés, uneconfirmée, et moi, étant la seule personne à connaître SDL.Nous étions directement sous la direction du responsable du département R&D de ce système.

5.3.2. Les objectifs du Projet

Les objectifs du projet étaient de mettre en place une structure permettant de travailler avecSDL. C’était donc un projet expérimental, ayant un objectif d’apprentissage, d’évaluation, et depréparation au futur.

• Acquérir les compétences en SDL. Pour cela nous avons choisi un bloc déjà existant en langage « classique » propriétaired’Ericsson et nous l’avons retranscrit en SDL en respectant le cycle de développement d’unprojet réel.Bien entendu, je m’étais implicitement fixé comme objectif d’apprendre moi-mêmebeaucoup grâce à ce projet.

• Evaluer les performances en fonctionnement réel.Une fois les principes acquis, il s’agissait d’évaluer :

- Si SDL pouvait contribuer à réduire les délais et les coûts, et améliorer laqualité ;

- Si le code dédié au commutateur AXE 10, automatiquement généré par SDL(grâce à un outil mis au point par Ericsson et Telelogic), présentait desperformances, une taille mémoire, et une lisibilité acceptable ;

- Si les outils logiciel et les méthodes SDL alors existantes étaient applicables auSystème de Signalisation.

• Se Préparer à de futurs projets recommandés en SDL.Enfin, ce projet devait permettre au département espagnol de se préparer au futur

dans le cas où SDL serait retenu. L’équipe devait ainsi pouvoir être autonome au terme deces six mois, c’est-à-dire être capable de mettre en place d’éventuels futurs projetsdéveloppés en SDL.



Ces objectifs étaient donc ceux du projet, et le sont aussi, implicitement et dans unemoindre mesure, pour tout projet développé avec SDL.

C’est pourquoi j’aimerais ajouter à cela les objectifs que nous , développeurs SDL pour lessystèmes de commutation AXE10, nous sommes fixés à plus long terme :

- permettre une génération de code efficace et optimisée, ce qui va permettre undéveloppement allant de la conception (donc de la modélisation) jusqu’au codage, defaçon continue ;

- intégrer SDL dans les méthodes de développement (cycle en V et cycle incrémental etitératif) ;

- intégrer SDL dans l’environnement de développement (outils périphériques, bases dedonnées, …) ;

- convaincre et former le personnel concerné.

5.3.3. Les Contraintes du Projet

J’ai dénombré les contraintes suivantes, que j’ai étendues pour certaines à tout projet utilisantSDL:

• Produire un code machine optimal tout en exploitant le langage SDL ;• Gérer le partage de ressources ;• Respecter les délais.

• Produire un code machine optimal tout en exploitant le langage SDL

Une contrainte importante, inhérente à tout projet développé en langage SDL pourdes systèmes temps réel, est le respect des caractéristiques liées au code machine.En effet, le temps d’exécution des instructions est primordial dans un système devant gérerdes milliers voire des millions de tâches en même temps.

Il fallait jouer sur deux tableaux à la fois : d’une part exploiter les possibilités de SDL, c’està dire être cohérent, clair et pertinent à ce niveau, et d’autre part ne pas perdre de vue lecode final en appliquant des règles de codage SDL permettant in fine une exécution duprogramme rapide, efficace, et cohérente (le code généré ne devant jamais être modifié à lamain, sous peine d’être écrasé à la prochaine génération).

C’était donc un équilibre parfois difficile à obtenir, mais pas impossible.

Cette contrainte s’appliquait d’autant plus à notre projet que nous devions réécrireen SDL un bloc déjà existant en code cible (PLEX), c’est à dire faire du reverseengineering, et le comparer à l’original.Cela avait pour but d’une part de mieux comprendre SDL en faisant une corrélation et unecomparaison directe entre le modèle et la cible, et d’autre part d’évaluer les performancesen fonctionnement.



• Gérer le partage de ressources

Pour ce projet nous étions six personnes à développer en même temps un seul bloc,ce qui est assez rare. Nous avons donc dû trouver une solution pour faciliter le partage defichiers et le travail en commun.

Pour cela, j’ai d’une part joué sur la décomposition architecturale d’un modèle SDL,en assignant chaque développeur à une composante du modèle, et j’ai d’autre part proposéd’utiliser l’outil logiciel de gestion de configuration ClearCase de Rational.Ainsi nous avons pu avoir une base de travail commune, gérer les versions, et éviter lesconflits de modifications.

• Respecter les délais

Cette contrainte est évidemment inhérente à tout projet, mais d’autant plus notablequ’un délai de 6 mois est tout juste suffisant pour former une équipe sur SDL, de façon à cequ’elle soit autonome.

Or, ce système était totalement inconnu pour moi (et peu connu pour les nouveauxembauchés), et le projet devait respecter le même déroulement qu’un projet traditionnel.Heureusement l’apprentissage de ce nouveau langage et la manipulation de ses outils ontaidé à motiver suffisamment l’équipe pour atteindre les objectifs.



5.3.4. Le Processus de développement

Dans ce chapitre, nous allons voir dans un premier temps que SDL permet une nouvelleapproche du cycle de développement et des processus de travail.Ensuite je présenterai le processus de développement que nous avons choisi pour le projetPrototype SDL.

Les développements logiciels du commutateur AXE10 ont suivi le cycle en V bienconnu de l’industrie, jusqu’à ces dernières années.Ce cycle contient essentiellement les phases de spécification, de conception, de codage, et detests (la recette ne nous impliquant pas directement).

De ce cycle, tel qu’il était adapté dans notre travail, on peut souligner quelques inconvénients :

- les phases de tests viennent tardivement, il faut pour cela coder au moins une partie, etréaliser un dump (code machine compilé et lié) ;

- beaucoup de documents, et finalement peu de code, sont produits. Cela n’est pas unemauvaise stratégie, mais les documents sont souvent écrits sans éditeur réellement adapté,et ne sont pas toujours entièrement fiables car il ne correspondent pas toujours à la réalité.

En revanche, la mise en œuvre du langage SDL implique une nouvelle façon de travailler.

En tant que langage de modélisation, SDL permet de faire abstraction de détails, enplaçant les définitions et les descriptions à certains niveaux de hiérarchie. C’est ce qu’onappelle le concept Top-To-Down.

De plus, il est recommandé de travailler avec SDL selon un cycle itératif, en raffinant lemodèle étape par étape et en incluant à chaque fois plus de détails.

L’intérêt de suivre ces recommandations est que l’on peut anticiper au maximum la simulationdu modèle ; on peut donc tester plus tôt les fonctionnalités.

Enfin, la continuité du travail est améliorée. En effet avec SDL on utilise le mêmelangage et le même support pour décrire de façon informelle et globale le comportement duprogramme et pour le détailler progressivement afin d’en générer le code. En revanche la méthode classique demandait d’écrire un document à base de texte et de figurespour ensuite coder à part le programme.

En ajoutant au modèle SDL des chapitres, des diagrammes, et des textes disposés selon desrègles de documentation, le modèle devient un document. Puisqu’ avec des règles de codage on peut générer le langage propriétaire d’Ericsson, on peutvraiment dire que le document EST le code ; on a une correspondance naturelle entre le code etsa description.



Toutes ces considérations ont conduit à un nouveau cycle, basé sur le cycle en V. On considèreles phases de conception développées avec SDL comme une partie venant s’incorporer aucycle (plug-in). La figure 6 représente ce nouveau cycle.

Figure 6 Le processus de développement logiciel de l’AXE10 avec SDLOn remarque que la phase de codage est intégrée à la conception détaillée, et que le test unitairen’est plus après le codage, mais dans une boucle itérative. De plus, les tests d’intégration sontexécutés en parallèle de la conception, par incréments, et non plus après.

J’ai appliqué la méthode itérative décrite précédemment autant que possible lors duprojet Prototype SDL. Pour répondre aux objectifs, le processus de développement du projet était le suivant :

1. Spécification et Préparation2. Conception Fonctionnelle SDL3. a. Conception SDL Détaillée itérativement

b. Simulation et test unitaire des parties non SDL4. Tests de non régression5. Mesures de caractéristiques6. Bilan

Je vais donc maintenant décrire le contenu de ces phases au travers des activités du projet.

Productiondu Dump

Spécifications

ConceptionFonctionnelle

SDL

IF ..THEN- - - -

source(langageEricsson)

Générationautomatique

Itérations :Ajout dedétails

Testd’intégration

Recettes

ConceptionDétaillée

et CodageSDL

---..-

....

.

---

.

Analyse,Simulation,Validation

(Test Unitaire)

Scripts de tests

documentimprimé

Modèle

SDL plug-in



5.3.5. Préparation du projet

Tout d’abord, j’ai commencé par prendre connaissance du système de Signalisationdéveloppé à Ericsson Madrid. Cela était essentiel pour la rédaction du cahier des charges.

Dans cette phase, je devais évaluer les délais des différentes phases du projet, les outilslogiciels à utiliser, et le choix du bloc devant servir de support au développement. En effet, je devais sélectionner parmi les blocs du système celui qui convenait le mieux entermes de volume, de complexité et de fonctionnalités, et qui était accompagné de mesures etde tests de non régression* exploitables.

Il a fallu ensuite mettre en place l’environnement de travail : installer la dernière versionde la plate-forme logicielle de développement SDL et définir l’arborescence des répertoires detravail avec l’outil ClearCase (gestion de configuration).

5.3.6. Préparation et accompagnement de l’équipe

Dans un premier temps il m’a fallu enseigner les bases de SDL, ainsi que son applicationau développement dans Ericsson, aux membres de l’équipe.J’ai donc dispensé une semaine de cours avec exercices dès le début du projet.

Cela n’était pas la première fois – mes premiers cours en compagnie d’un de mes collèguesdatent de 1998, juste après le premier projet en SDL – ni la dernière fois : on m’a demandé deréitérer mon enseignement à d’autres personnes d’Ericsson Madrid à la fin du projet PrototypeSDL, puis il y a peu de temps (fin 2002) à quelques personnes de Teleca Solutions.

Bien évidemment, mon enseignement a été constant lors du projet Prototype SDL. J’aiaccompagné l’équipe quotidiennement, et j’ai beaucoup appris moi-même ce faisant.

Accompagner et encadrer l’équipe de designers (environ 2 à 5 personnes) est une fonctionessentielle d’expert SDL, et je l’ai toujours assumé (selon mes compétences grandissantes) aucours des différents projets, et un peu plus officiellement au cours du dernier projet, MobileSwitch Center 3.0.

* Voir Glossaire



5.3.7. Conception Fonctionnelle puis Détaillée

Avant de connaître SDL, l’équipe pensait que le projet ne se contenterait que de traduirele code du bloc existant en SDL, et que ce langage n’intervenait pas lors de la phase antérieuredécrivant les fonctions du (ou des) blocs. J’ai donc souligné l’importance d’exploiter les atoutsde SDL dès cette phase.

Nous avons donc traduit le document décrivant les fonctions, selon les instructions derédactions de modèles SDL (et je ne parle plus de « document » proprement dit).

Cette tâche est parfois ardue, elle demande un esprit de synthèse et d’organisation. Il fautmodéliser selon une certaine modularité et hiérarchie de détails.

Par exemple on peut créer une cartographie de scenarii avec des diagrammes HMSC (HighLevel Message Sequence Chart). Ces scenarii sont alors détaillés dans des diagrammes MSC(Message Sequence Chart) et les diagrammes peuvent ainsi s’emboîter (une HMSC contientd’autres HMSC qui contiennent des MSC contenant à leur tour des MSC…). Un exemple dediagramme HMSC et MSC est proposé sur la figure 7.

Figure 7 Conception fonctionnelle avec SDL : diagrammes HMSC et MSC

J’ai ensuite montré comment définir l’architecture du bloc, son environnement et ses interfaces.Cela a permis de répartir les responsabilités de chacun selon cette architecture, en assignantchaque personne à une composante du bloc. J’ai alors incité le groupe à commencer dès cetteétape la définition du bloc au niveau fonctionnel, sans entrer dans les détails. Cela a permis dedébuter quelques simulations basiques.

Send_Request

Request_Success Request_Fail

hmsc Perform_Servicemsc Send_Request

client server database

request

lookup

wa



C’est sous cette forme que j’ai estimé important d’inspecter ensemble le document afin de levalider, selon les normes documentaires en vigueur (voir chapitre Revue, Inspection, et LectureCroisée).

Par la suite, nous avons progressivement détaillé chaque processus ou fonction, et noussommes ainsi passés petit à petit d’un modèle fonctionnel, indépendant du code cible, à unmodèle physique, qui prenne en compte les contraintes de son environnement.

En effet, le processeur du commutateur AXE 10 possède des fonctionnalités propres qu’il estessentiel de considérer au plus tôt des spécifications.C’est un système multitâches, dédié et rapide. Par conséquent, il faut par exemple gérer lesvariables avec attention (en utilisant le plus possible les registres), gagner du temps sur la saisiede la mémoire (gestion des pointeurs), ou encore faciliter l’optimisation de la mémoire cache.

Il faut donc appliquer au modèle SDL de nombreuses règles de codage spécifiques pour générerun code suffisamment performant.J’ai donc sensibilisé l’équipe sur la bonne application de ces règles, et cela m’a permiségalement de réfléchir à certaines améliorations à y apporter.

Cette bonne application des règles de codage est aussi essentiel au bon déroulement de lasimulation SDL. La difficulté réside dans le fait que la simulation passe par une génération desource en langage C tandis que la production du code final passera par le langage propriétaired’Ericsson. Il y a donc certaines considérations à prendre en compte lors de ces activités.La simulation est donc un outil de debogage et permet de faire du test fonctionnel et unitaire, envérifiant automatiquement les diagrammes MSC.En revanche, elle ne permet pas de s’affranchir du test d’intégration, qui prend en compte lesconditions réelles du système (avec des émulateurs et des maquettes).Plus d’information au sujet de la simulation est disponible en annexe.

Le document de test unitaire déjà existant a été utilisé comme base de simulation dans leprojet Prototype SDL. Comme il était très volumineux, cela a rendu la phase de simulationassez longue, mais profitable : plus de 30 fautes ont ainsi été découvertes.



5.3.8. Revue, Inspection, et Lecture Croisée

Une revue est une lecture par une autre personne du travail d’un développeur, afin devérifier que celui-ci est sur la bonne voie.

L’inspection est plus formelle : elle réunit plusieurs participants, et a pour butd’approuver ou non le document. J’ai proposé de tirer partie de SDL lors de la préparation des inspections. Il est en effetrecommandé de vérifier les points suivants :- être sûr que le modèle est correctement analysé et compilé ;- avoir simulé le modèle si possible.

La lecture croisée et minutieuse du code, quant à elle, s’appuie sur une liste devérification (checklist). J’ai pu montrer durant tous les projets qu’il est bien plus aisé de fairecette vérification sur un modèle SDL que sur le code cible comme les développeurs ontl’habitude de le faire.

L’approbation des documents techniques met en place les jalons permettant de passerd’une étape à l’autre, et de connaître l’avancement du projet.C’est par ce moyen qu’on défini le plan d’assurance qualité.

J’ai régulièrement participé aux inspections, en tant qu’auteur des documents,modérateur et/ou inspecteur. J’ai donc moi-même approuvé certains documents, bien que celafasse partie des fonction de l’ingénieur.

5.3.9. Application des Méthodes

Dans le cadre de l’apprentissage et du soutien donné à l’équipe, j’ai veillé à ce que lesméthodes soient appliquées tout au long des projets, ou tout du moins l’essentiel – la pratiquedifférant parfois quelque peu de la théorie.C’est un peu le rôle du responsable des Méthodes assigné au projet, mais ma spécialité en celangage m’a impliqué dans cette tâche. J’ai donc souvent assisté le Responsable Méthodes, enlui expliquant les principes de SDL.

Ensuite, j’ai montré aux membres de l’équipe les guides (style guides) donnant quelquesrecommandations sur la notation du code (hongroise), la disposition des diagrammes, la façonde créer des scripts de simulation, ou encore l’archivage des documents générés par SDL.

Lors du projet visant à mettre en place les premières méthodes SDL, en 1999, j’aiparticipé à l’inspection de presque tous les guides et documents d’instruction de travail.Lors de ce projet, j’ai également eu pour responsabilité d’écrire l’instruction de travail (WorkInstruction) relative à la simulation et la validation. Ce document a ensuite été inspecté etvalidé par le groupe d’experts.



5.3.10. Intranet du projet

Pendant le déroulement du projet, il s’est vite avéré nécessaire de rédiger et de rassemblerles différentes informations utiles. Il était intéressant aussi de présenter notre projet au reste desdéveloppeurs d’Ericsson.

C’est donc de ma propre initiative que j’ai mis en place un petit site intranet sur notreprojet. Ce site intranet contient donc essentiellement les liens vers les rapports, les documentset les fichiers SDL, une section « Trucs et Astuces » recensant les informations utiles et lesquestions ouvertes, ainsi que les cours que j’ai dispensés à ce moment.

5.3.11. Résultats du projet

A la fin du projet, les membres de l’équipe ont passé les tests de non régression sur lebloc.Les tests ont été effectués avec la plate-forme d’émulation de l’AXE10, et une partiedirectement en salle de maquettes.Cette phase s’est déroulée rapidement et sans difficultés ; seulement 7 fautes ont été trouvéessur 315 scenarii, ce qui montre une qualité de développement satisfaisante.

Ensuite, des mesures de caractéristiques ont été effectuées. Nous avons commencé parcomparer la taille du programme généré par SDL avec l’original. Il n’y a pas eu de grandedifférence concernant l’allocation mémoire. Il y avait légèrement plus d’instructions générées,mais la taille du code machine final (l’équivalent de l’assembleur) était identique.

Enfin, des mesures de charge du processeur et des temps d’exécution ont eu lieu. C’étaitun peu le moment de vérité, qui allait certifier ou non l’intérêt de SDL pour le département. Lescomparaisons ont été satisfaisantes : nous avons constaté une légère augmentation des chiffres(environ 4% en moyenne, jusqu’à 8% maximum, et nous avons même gagné 1 % sur certainstests par rapport aux tests originaux).

Mais la plus grande satisfaction ne se chiffre pas. Tous les membres de l’équipe ontvécu une très bonne expérience, grâce à ce projet innovant et motivant. En règle générale, tous les designers ayant travaillé avec SDL n’aiment pas retourner à desprojets devant développer de manière plus traditionnelle.

Le rapport final, que j’ai aidé à rédiger, a été très utile aux projets suivants, notammentau responsable SDL du projet total Mobile Switch Center 3.0 , pour convaincre le centre dedéveloppement du bien-fondé de cette approche, et surtout de la nécessité d’aller plus loin ;l’étape suivante étant l’harmonisation avec des méthodes et outils périphériques (bases dedonnées, logiciel d’édition de code source par exemple).



5.4. Le projet Mobile Switch Center 3.0

5.4.1. Contexte

Le principal contexte de ce projet, qui s’est déroulé de février 2002 à janvier 2003, estl’avènement de l’UMTS*. Les réseaux téléphoniques ne peuvent évidemment pas migrer dujour au lendemain vers la troisième génération de téléphonie. C’est une évolution qui se fait peuà peu, étape par étape. Dans cet état intermédiaire, différentes technologies cohabitent dans lesréseaux de communication, et des passerelles doivent être installées.

Cependant l’UMTS n’a pas eu le succès escompté, et les demandes en réseaux IP(signalisation et transport de données) a décru. Le GSM est donc toujours une applicationmajeure de ce type de réseau. En conséquence, il fallait délivrer une version permettant à la foisd’adapter un peu le réseau à l’UMTS, mais misant surtout sur des services attractifs qui sontsources de revenu pour les opérateurs.

Le point du réseau mobile qui commute les appels est le Mobile Switch Center. Il doitdonc être mis à jour pour prendre en compte plus de protocoles et les passerelles multimédia.Nous avons été impliqués dans cette tâche en tant que responsables du Module Applicatifpermettant d’interroger une base de donnée avant la commutation d’appel.

5.4.2. Les objectifs du projet

Le projet total se devait de suivre un plan de développement (business case) centréautour du marché GSM, tout en focalisant les fonctionnalités de l’UMTS sur certains servicesimportants (localisation d’appel, applications multimédia), et en accompagnant l’évolution del’architecture des réseaux du mobile, plus basé sur l’IP.

Ces objectifs ont été réalisés par le développement de fonctions propres aux réseauxtéléphoniques GSM et UMTS que nous ne détaillerons pas ici.

5.4.3. Les contraintes du projet

Nous avons du nous former rapidement au monde du mobile, puisque nous avons acquisla responsabilité de ce système au début de ce projet, suite au transfert de cette activité enprovenance de Suède. Cependant le transfert de connaissances et de responsabilités s’estdéroulé sans encombre et n’a pas perturbé le projet.

L’équipe française était assez réduite aux vues de la taille du système à mettre à jour: deuxingénieurs de développement, trois ingénieurs Système, trois testeurs, un responsable deconfiguration (pour la gestion de versions et de documents), une responsable méthodes etqualité, le chef de projet local, et moi, assumant des fonctions de coordination. C’est pourquoi j’ai participé à plusieurs tâches de natures différentes au cours de ce projet. * Voir Dictionnaire des sigles



5.4.4. Le processus de développement du projet

Un des grands intérêts de ce projet a résidé dans son processus de développement.Comme beaucoup de systèmes, et par conséquent d’équipes, étaient développés en parallèle,l’aspect de coordination était primordial.

De plus, beaucoup de nouveaux outils étaient utilisés à tous les niveaux :développement SDL, gestion de version et de configuration, test, etc. Ces outils, ainsi que lesméthodes associées, ne bénéficiaient donc pas tous d’une maturité à toute épreuve. Enconséquence, la progression du projet s’appuyait sur un réseau de compétences adéquates.

Cette organisation s’est reflétée par la structure matricielle des sous-projets, telle qu’elle estprésentée sur la figure 8.

Figure 8 Maillage Projets – Métiers

On peut y remarquer les relations entre les différents métiers permettant la conduite du sous-projet de façon locale.

Pour lier ces métiers entre sous-projets, des coordinateurs formaient un réseau transversal, etles chefs de chaque sous-projet local étaient en contact entre eux (durant la phase dedéveloppement) et avec le directeur du projet total, qui lui a gardé ses fonctions du début à la

Directeur Projet

…Développement TechnologiqueAXE10

Déploiement Méthodes

Gestionde

Configuration

SDL Test DesignChefProjetLocal

Module d’Application Y

Gestionde

Configuration

SDL Test Design ChefProjetLocal

Moduled’Application X

Communication interne au métier

Communication dans le groupe fonction

Communication dans le groupe projet



fin du projet. D’autres métiers entrent en relation avec ce maillage : les méthodes devant êtreappliquées ou mises à jour, différents outils, la technologie évolutive du produit (par exemplepour prendre en compte les caractéristiques des nouveaux processeurs utilisés dans lecommutateur), etc…

L’idée était donc de développer a la fois le produit et les moyens de le réaliser, de façonparallèle et incrémentale.

De plus, les composantes à développer ont été identifiées sous formes de workpackages,c’est à dire des fonctionnalités élémentaires, certaines dépendant d’autres, livrées selon uncalendrier bien précis, par incrément. Ces incréments permettent de tester et corriger les fautesle plus tôt possible.

Tous les quatre ou cinq incréments, une livraison est faite à une autre équipe qui vérifie tout ledéveloppement intégré chez le client ou dans des centres d’essais spécialisés et on met ainsi enplace peu à peu le produit final.

Une représentation très simplifiée de ce qu’on appelle un plan d’anatomie résume cette gestionde projet sur la figure 9. Les flèches indiquent une dépendance.

Figure 9 Workpackages et Incréments

Ce découpage en sous-projets permet donc une évolution simultanée de la conception, de laréalisation, du test, et de la recette.

Inc3

TaxationPour Japon

FonctionLocali-sation

CorrectionFautes

ProtocoleX

ProtocoleY

Work-Package

2Equipe A

Work-Package

3Equipe C

Work-Package

4Equipe A

UMTS

Inc26

Inc14

Work-Package

1Equipe C

Work-Package

5Equipe B

Work-Package

6Equipe B

NouveauProcesseur

Work-Package

7Equipe C

25/04/2002

12/07/2002

01/09/2002



5.4.5. Développement du système Data Base Query Application Module

Coordination SDL

J’ai participé activement aux conférences téléphoniques hebdomadaires de coordinationSDL. Ces réunions impliquaient une personne par site pour le projet, soit presque unedizaine, plus le coordinateur du projet total responsable de ce réseau. Nous avons égalementeu quelques réunions physiques en Allemagne.

Tout ce qui avait trait à SDL était discuté durant ces réunions. D’abord en relation avecle projet (avancement, problèmes, questions), mais aussi tout ce qui pouvait donner lieu àune information utile à savoir ou une amélioration à apporter.J’ai régulièrement transmis et appliqué ces informations à mon équipe et rendu compte del’essentiel durant les réunions hebdomadaires du projet local.

Grâce à un tel réseau actif, le déploiement de SDL dans le développement des produitsEricsson a fait un bond prodigieux.

Mise en œuvre des Workpackages

Il fallait transformer les blocs unitaires de notre système afin de maîtriser les séquencesde messages de signalisation propres au réseau IP.

Dans le cas du réseau IP il faut transporter la voix avec des protocoles différents decelui du réseau traditionnel, c’est ce que l’on entend par Voix-sur-IP. Le passage de voix àIP se fait par des passerelles (Media Gateway). Cela implique des modifications dans lagestion des messages indiquant par exemple quand l’abonné décroche.

Pour cela, j’ai étudié et mis en œuvre avec mes collègues des machines d’étatscomplexes et cela a fait l’objet d’un workpackage conséquent (il y en avait six au total, surune durée de presque un an).Comme il n’y avait que deux ingénieurs de développement dans notre équipe, moinsexpérimentés que moi, le chef de projet local m’en a confié une partie importante.

En tant que coordinateur SDL, j’ai aussi supervisé l’ensemble des autres workpackages.

Amélioration du code existant

Pour permettre une mise à jour de ces blocs, j’ai pris la décision d’en simplifier ladisposition SDL, pas toujours optimale ni cohérente (le code était trop éclaté et les variablesmal utilisées), tout en mesurant les risques de tels changements. Cela a été fait encollaboration avec le reste de l’équipe.

Le générateur de code propriétaire Ericsson apportait de nouvelles possibilités toutau long du projet dans le but d’améliorer les performances du code final. Suite auxdécisions des réunions de coordination SDL, mes collègues et moi avons adapté lesdiagrammes SDL en conséquence.



Documents rédigés

Au cours de ce projet, j’ai rédigé plusieurs documents techniques (qu’ils soient SDL ounon), dont certains devant évaluer les coûts de développement (délais nécessaires).

J’ai jugé nécessaire, après concertation des autres membres de l’équipe, de réécrire undocument (provenant d’un projet précédent) décrivant quelques fonctionnalités complexesdu workpackage principal. J’ai donc pris en charge ce document technique, en appliquant les règles de rédaction et lespossibilités propres à SDL. J’ai ajouté ainsi des diagrammes de haut niveau qui jouaient lerôle de « cartographie » des autres diagrammes décrivant les séquences de messages.Cette réorganisation du document a été difficile, car il a fallu maîtriser l’aspectcomportemental de tous les blocs concernés.Cependant nous avons amélioré la qualité du document et sa compréhension. Nous avonségalement repéré des fautes potentielles, et le document a pu servir de point d’entrée à lasimulation.

Harmoniser SDL et les outils de développement

Le développement SDL d’un système, de sa conception jusqu’au test, se fait au moyend’une palette d’outils logiciels (organisateur, éditeurs, analyseur, simulateur, générateur decode, etc.), vendue par Telelogic.

Cette plate-forme s’inscrit elle-même dans une plate-forme de développement propre àEricsson, avec différents types de bases de données, des éditeurs de sources de programme,des émulateurs et simulateurs plus dédiés, etc.

Les enjeux et la taille du projet total ont beaucoup contribué au déploiement de SDL. Ainsi, on a pu mettre en place des bases de données propres à SDL, et intégrer SDL auxoutils déjà existants.

Par exemple, un logiciel propre à Ericsson permet de stocker et de modifier dans une basede données la définition de messages entre les blocs unitaires. Nous avons fait en sorte quece logiciel intègre la syntaxe SDL.

De même nous avons simplifié la possibilité d’ouvrir un bloc SDL développé par un autreprojet, en intégrant les blocs archivés dans la production.

Mon rôle dans cette harmonisation s’est joué au travers de la coordination SDL, enexpliquant au reste de l’équipe ce qu’il fallait faire pour profiter de ces possibilités, et enprenant moi-même en charge localement les migrations de bases de données nécessaires.

Test et Recettes du projet Mobile Switch Center 3.0

Les tests système concernant le travail effectué localement ont été menés tout au longdu projet sans problème majeur. Des tests d’intégration étaient par ailleurs effectuésrégulièrement en Allemagne.La déviation des coûts par rapport au budget établi initialement n’a pas dépassé 0,05 %.



5.5. Bilan technique de mes activités

Le projet Prototype SDL m’a permis tout d’abord donné le sentiment d’avoir une réelleinfluence et responsabilité au sien d’une équipe, en la guidant et en l’aidant au quotidien, maisaussi en obtenant de la part du reste de l’équipe des informations essentielles.Cela m’a demandé d’être clair, concis, méthodique, et pédagogue.

J’ai pu jouir d’une grande liberté dans la pratique de SDL, ce qui m’a permisd’approfondir et de perfectionner mes connaissances, et de découvrir certains points àaméliorer. J’ai donc fait preuve de savoir-faire dans l’analyse des besoins.

De plus, j’ai pu connaître des personnes et un pays différent. J’ai ainsi pu pratiquer mon anglaiset acquérir quelques bases rudimentaires en espagnol. J’ai pu montré mes capacitésd’adaptation à un nouvel environnement de travail et de vie au quotidien.

Le projet Mobile Switch Center 3.0 m’a montré ce qu’était un projet de premièreimportance pour un groupe international, avec les enjeux mondiaux que nous connaissons tous.La conjoncture difficile m’a obligé à maîtriser au mieux les coûts, en ciblant les priorités dansles nombreuses tâches m’incombant.

L’aspect communicatif m’a concerné sur le premier plan avec mes rôles decoordination, à la fois à l’intérieur de l’équipe locale et à l’extérieur en prenant pleinement partà un réseau actif et efficace de spécialistes réellement motivés pour faire avancer les choses.

Cela s’est fait sans se dissocier d’une compétence technique sur le système développé,en étant impliqué sur tous les points du cycle de développement. J’ai aussi pris de nombreusesinitiatives tout en les soumettant au reste de l’équipe et au chef du projet.

En ce qui concerne mon investissement dans SDL en général, il m’a apporté de grandessatisfactions. L’étude et la pratique de ce langage (appuyé par des outils conviviaux etpuissants) est motivante et plaisante. En travaillant sur un langage standard et largement utilisédans des secteurs d’activités variés, j’ai pu avoir une expérience non pas limitée à Ericsson,mais ouverte sur d’autres secteurs.



6. Optimisations mises en œuvre

6.1. Optimiser le travail d’équipe

Il est maintenant nécessaire, pour un projet, d’avoir un responsable dans le domaine deSDL (comme il y a un responsable de Gestion de Configuration, ou des Méthodes), afin defaire l’interface entre tous les intervenants de son déploiement, préparer le travail des membresde l’équipe, et l’accompagner.

Ce rôle m’a amené à optimiser le travail de l’équipe de par mes compétences.

Nous avons vu que cela s’est traduit par la revue approfondie du travail de conception, lapréparation de la simulation, l’application de règles de codage (notation hongroise, dispositiondes déclarations) et bien d’autres activités inhérentes aux phases de développement.

J’ai aussi aidé à l’élaboration de checklist propre à SDL, et j’ai rédigé quelques guidespour aider les membres de l’équipe, par exemple pour lister les étapes nécessaires à la livraisond’une version du programme SDL et son code PLEX généré, en accord avec les règles degestion de versions.

Je me suis également attaché à mettre en place certaines activités non obligatoires, commepar exemple la représentation des processus SDL sous forme de diagrammes d’états.Les processus sont parfois complexes et une représentation de leurs états et transitions aident àles analyser et les comprendre.

C’est donc une autre représentation, totalement identique à celles que l’on rencontre dansle langage UML, qu’on utilise pour résumer le fonctionnement dynamique d’un process.

Un autre exemple d’optimisation utile à l’équipe est la préparation de la SimulationSDL. Comme le temps de faire une phase de simulation SDL complète et efficace n’était pastoujours alloué, j’ai ciblé au mieux les tests pour relever les fautes potentielles le plus en amontpossible. Cela a permis de préparer quelques scripts SDL qui ont été repris ensuite par lesautres développeurs.

6.2. Optimiser les outils

Maîtriser les bases de SDL et les mettre en place dans certains projets de développement ducommutateur AXE10 constitue déjà une optimisation des processus de travail en soi.En effet, ces projets gagnent à utiliser SDL, en termes de temps et de qualité, surtout une foisles compétences acquises et la structure mise en place (c’est à dire pour des blocs nouveaux oudéjà convertis en SDL).

Cependant, l’outil élaboré par Telelogic, appuyé par Ericsson, n’a pas été parfait dès lespremiers jours, et est loin de l’être encore aujourd’hui.Ainsi, lorsque mes collègues (du projet ou non) ou moi rencontrions des erreurs, que ce soit surla plate-forme générale de Telelogic (gestion de fichiers, éditeurs, simulateur, …), sur les



fichiers d’aide, ou sur l’outil de génération de code, il m’a fallu les rassembler et écrire desfiches de fautes, et en assurer le suivi.

Lorsque venait la phase de spécification de la nouvelle version complète de la plate-formeSDL, je proposais certaines améliorations rédigées selon un formulaire particulier. Certainesd’entre elles provenaient de fiches de fautes, et d’autres de notre expérience des précédentsprojets, ou encore des caractéristique des nouveaux processeurs du commutateur AXE10 (parexemple à propos du fonctionnement de la mémoire cache). Celles-ci étaient alors analysées, etacceptées selon leur pertinence et le budget alloué.

Le projet Prototype SDL, comme tous les autres projets que j’ai connus, a permis dedéceler de telles fautes et améliorations que nous avons listées sur l’intranet et dans le rapportfinal.

6.3. Optimiser le produit

Enfin, j’essaie autant que possible d’améliorer la qualité des produits développés, enproposant des alternatives et des solutions au cours des projets. Cela m’a amené par exemple àproposer une nouvelle version d’un groupe de blocs, qui pourrait profiter des progrès récentsdes outils SDL.

J’ai rédigé pour cela un rapport d’étude, qui sera sans pris en compte si ce groupe de blocs estouvert dans un prochain projet, et si le budget le permet.

Un autre exemple concerne une librairie (« package »), utilisée par le projet Mobile SwitchCenter 3.0, permettant de coder et décoder des messages selon un certain protocole. Commecette librairie était initialement écrite en langage dédié, j’ai mis au point une version intégrableau modèle SDL. Suite à mon travail, un document d’instructions a été réalisé pour faciliterl’utilisation de telles librairies par les développeurs de différents centres de développement.



7. Les composantes du métier d’Ingénieur-Maître

Nous avons vu dans un premier temps quelles étaient les fonctions qui m’étaient attribuées,telles que les définissait mon emploi de référence, à savoir celles d’un technicien supérieur enétudes logicielles.

Puis, nous avons rapidement pu observer que ma spécialisation dans le langage SDL mepermettait d’avoir une influence et des responsabilités plus vastes.L’aboutissement de mon rôle d’expert en SDL s’est traduit par la Coordination SDL.Je vais donc maintenant détailler les différentes composantes de mes activités techniques etcelles liées à la coordination SDL.

7.1. Le développement logiciel

Pour concevoir et réaliser les fonctions et unités logicielles dont j’avais la charge, j’aiapprofondi mes connaissances concernant le langage SDL et son environnement dedéveloppement tout au long de ma carrière.

Je devais pouvoir développer et simuler un système, une fonction ou une unité en SDL defaçon claire et efficace. Pour cela, j’ai optimisé mon travail afin de produire un code machinedédié et performant tout en exploitant au mieux les possibilités offertes par les outils SDL.

J’ai aussi élaboré des cahiers des charges sur certaines fonctions à développer, en coopérationavec les ingénieurs du System Management, à partir de documents de spécifications écrits enamont.

J’ai assuré le suivi et la maintenance de mes applications, jusqu’à la prise en charge par leservice concerné (Product Support). Cela s’est traduit par la réponse aux rapports de fautesécrits par les testeurs, la rédaction et le test de la correction en code machine, ou patch, àapporter.

Enfin, en tant qu’expert et coordinateur, j’ai proposé l’utilisation de certains outilss’inscrivant dans l’ingénierie Système : gestion de versions de fichiers, outils de bases dedonnées, ou même obtention de licences permettant une meilleure simulation SDL.Je devais donc constamment être informé des nouvelles versions des logiciels adéquats, de cequ’elles apportaient (Release Notes), et je devais m’assurer de leur installation. Je suisaujourd’hui impliqué dans la migration des réseaux de Teleca afin de se détacher desinfrastructures d’Ericsson, car je dois tester dans le nouvel environnement les outilsfonctionnant autour de SDL et ayant des connections avec le monde Ericsson.



7.2. Gestion de projet

Au-delà du développement unitaire d’un sous-système, j’ai pu prendre la responsabilité,du point de vue SDL, de systèmes entiers, composés de fonctions et unités assignées aux autresmembres de l’équipe, ingénieurs ou techniciens supérieurs.En d’autres termes, j’avais la charge d’assurer le bon déroulement du projet sous l’angle SDL.J’étais donc impliqué à tous les niveaux : cahiers des charges fonctionnels, conceptionfonctionnelle et détaillée, gestion de configuration, méthodes, vérification et tests. Bienentendu, cette tâche impliquait d’avoir une bonne connaissance, voire une bonne maîtrise desfonctionnalités du système, indépendamment du langage.

Aussi, dans les projets impliquant plusieurs équipes dans différents pays, à forte consonanceSDL, tel le projet Mobile Switch Center 3.0, mon rôle a-t-il été défini comme celui deCoordinateur SDL.Je jouais le rôle d’interface entre mon équipe, incluant le chef du projet local, avec lesresponsables R&D de l’environnement SDL, et je réglais avec eux les problèmes dûs auxcorrections, aux versions, et aux licences.Ainsi, je devais, d’une part, coordonner toutes les activités liées à SDL dans le projet local, etd’autre part participer à des réunions internationales sur le sujet (workshops). Et surtout, j’aiparticipé activement et régulièrement aux conférences téléphoniques et aux réunionsconcernant SDL et le projet.

Au cours de tous les projets, j’ai participé régulièrement à des réunions avec les membres del’équipe pour discuter de certains points, concernant ou non SDL. J’ai aussi régulièrementorganisé moi-même certaines réunions lorsque nous rencontrions certains problèmes, réels oupotentiels, ou bien lorsqu’il y avait des informations utiles à partager. Ces réunions (partéléphone ou physiques) avaient aussi pour but d’inspecter ensemble les documents techniques,afin de les valider le cas échéant.

Ainsi je rendais compte régulièrement à l’équipe, au chef de projet local, et au coordinateur duprojet total, de mon travail de coordination ou de développement.J’ai participé à la rédaction du rapport de fin de projet, ma plus grande participation à ce jourétant pour le projet SDL Prototype, puisque je l’ai encadré du début à la fin en coopérationavec la chef d’équipe.

Du point de vue hiérarchique, mon rôle de coordinateur m’assignait à l’équipe de managementdu projet local.



7.3. Soutien, Communication et transmission du savoir

Comme je l’ai illustré précédemment, j’ai été parmi les premiers à participer à des projetsSDL au sein d’Ericsson, et la proportion d’utilisateurs de ce langage est encore faible.C’est pourquoi j’ai toujours formé, conseillé, et assisté d’autres personnes de façon interne eten participant à un forum (mailing list) commun à la R&D.Pour ce faire, j’ai préparé et présenté des séances de formation sur plusieurs jours, àplusieurs reprises (une fois par an en moyenne), que je n’ai cessé d’améliorer en fonction del’évolution du déploiement de SDL au sein d’Ericsson.

Comme cela a été illustré par le projet Prototype SDL, j’ai pris en charge l’élaboration dusite intranet du projet. Dans le projet Mobile Switch Center 3.0, j’ai ajouté au site existantquelques présentations Powerpoint sur différents sujets.

De plus, j’ai écrit et participé aux inspections de documents de méthodes concernant SDLau sein des projets de développement de systèmes de commutateurs AXE10.Je me tenais donc régulièrement informé des nouvelles versions de ces méthodes et jem’assurais de leur suivi par les membres de l’équipe, ou du moins de ce qui était applicable etessentiel.

De même, je m’employais aussi souvent que possible à la supervision du travail desmembres de l’équipe lors des activités liées à SDL.

J’ai aussi régulièrement écrit quelques Rapports de Fautes et Spécifications d’Exigencessur la plate-forme de développement SDL. Une fois ces rapports pris en compte dans unenouvelle version, j’ai assuré le suivi de ces fautes ou améliorations.

D’autre part, la dimension internationale de la compagnie et du monde destélécommunications m’a mené à parler et écrire anglais quotidiennement.

7.4. Evaluation des coûts

Le coût est un critère omniprésent et le développement de systèmes de télécommunicationsn’y échappe pas.Je devais donc donner régulièrement à mon chef de projet local des estimations de délais, doncde coûts, en termes de « Man-Hours » pour des tâches que des membres de l’équipe ou moi-même devions exécuter tout au long des différents projets.Je devais prendre en considération le temps que SDL allait d’abord faire perdre (puisqu’ilfallait convertir des blocs, former le personnel, etc.), pour le gagner par la suite.

Depuis la création de la nouvelle société Teleca Solutions, j’ai pris contact avec lesfournisseurs des plates-formes de développement SDL, et d’autres gammes de produits :Telelogic, mais aussi de petites entreprises.Pour l’instant, Ericsson nous fournit toujours les licences nécessaires, mais il est importantd’avoir ces contacts pour préparer le futur.J’ai donc dû prendre en compte le coût des licences au moyen des différents devis(« packaging de licences »).



7.5. Récapitulatif des composantes de l’ingénieur

Les composantes de mon métier ont plusieurs facettes. SDL est la spécialité principale,mais derrière cette expertise se cachent des fonctions d’appui et de coordination, considéréescomme celles d’un membre de l’ équipe managériale, plus que celles d’un technicien supérieur.Un autre aspect est la connaissance plus technique des systèmes de télécommunications, de sesnormes, de ses applications, et des méthodes de travail pour les développer.

Mais le monde évolue, et mon environnement de travail en témoigne. Le déploiement deSDL au sein d’Ericsson restera peut-être une composante de mon métier mais je dois metourner vers d’autres objectifs, puisqu’Ericsson n’est qu’un de nos clients dorénavant.

C’est pourquoi il est intéressant de pressentir quelles sont les autres applications du langageSDL et d’autres langages similaires ou connexes dans l’industrie, et comment elles s’inscriventessentiellement dans une volonté de modéliser, concevoir, et valider des systèmes distribués –activités primordiales de l’Ingénierie Concourante.

C’est sur ce thème que j’étudierai ces enjeux.



8. Thème d’Etude : Les Outils Logiciels de l’Ingénierie Concourante

8.1. Introduction

L’application de SDL est loin de se limiter au développement logiciel de commutateurtéléphonique, tel que je l’ai connu au sein d’Ericsson.

En effet, si on regarde quels sont les secteurs d’industries mettant en œuvre des langagesformels de spécification tels que SDL, on s’aperçoit qu’ils sont multiples et variés :télécommunications, automobile, défense, nucléaire, aérospatial, transport, et même finance.Or, ces industries ont vu leurs moyens de conception se modifier profondément cette dernièredécennie afin de répondre à de nouveaux défis.

Nous verrons dans ce thème d’étude que ce changement peut s’expliquer par l’arrivée del’Ingénierie Concourante, dite aussi Simultanée, que nous définirons brièvement dans unpremier temps.J’analyserai ensuite comment cette nouvelle organisation s’est traduite dans monenvironnement de travail et mes fonctions, que j’ai présentés précédemment.Enfin, j’apporterai quelques solutions logicielles, centrées autour de SDL, qui accompagnentl’Ingénieur Système durant les activités de conception, comme la Modélisation et la Validation,et qui répondent aux besoins de l’Ingénierie Concourante.Je terminerai cette étude par un récapitulatif des langages standards en relation avec SDL avantde conclure.

8.2. Définition de l’ingénierie concourante ou simultanée

La définition la plus universellement admise est celle de l ’Institute Defense Analyses,centre de recherche pour la défense américaine, publiée en 1986.Il définit l’ingénierie concourante comme une approche systématique pour concevoir unproduit prenant en considération, dès le début, tous les éléments de son cycle de vie depuis lapremière expression du besoin jusqu’au retrait de service.

L ’Ingénierie Concourante est une nouvelle analyse qui intègre lors du processus dedéveloppement une grande variété de domaines et de méthodologies de gestion de projets.

Parmi ces domaines on compte la qualité, le marketing, l’étude de production, l’ergonomie,la maintenance, etc. Des représentants de ces différents métiers sont réunis sur un plateaucommun, afin de concourir à la conception du produit avec une meilleure qualité et surtout desdélais plus courts.



8.3. L’Ingénierie Concourante et les industries

L’Ingénierie Concourante est née dans l’industrie aéronautique et automobile dans lesannées 1985-1990, puis s’est étendue aux autres industries et PME/PMI dans les années 90.

La conception de la Twingo a été menée selon ce principe pour lapremière fois au sein de Renault. Par exemple, les intervenants spécialistes de l’acoustique n’ont pasattendu la validation de la conception pour débuter leurs études, grâceaux informations et aux prototypes, tandis que d’autres équipestravaillaient sur l’Analyse des coûts et de la Valeur. Le succès de ceplateau d’intervenants a ensuite donné lieu à la mise en place duTechnoCentre de Renault.

En effet, la conception et la réalisation de nouveaux produits est rendue complexe par lademande croissante de nouveaux services faisant appel à de nouvelles technologies, de plus enplus électroniques et informatiques (voir les systèmes embarqués mis en réseaux dansl’automobile et l’avionique) . Une nouvelle dimension dans la complexité apparaît : leséquipements peuvent parfaitement fonctionner de manière indépendante, mais connectésensemble, comment s’assurer de ne pas avoir d’interférence fonctionnelle (j’appuie quatre foissur l’autoradio et les essuie-glaces se mettent en marche !) ?

De plus l’insatisfaction du client, ou une défaillance majeure, peuvent avoir des effetscatastrophiques sur l’entreprise : le logiciel embarqué se doit d’avoir une sécurité accrue.

A cela s’ajoutent des temps de conception et de mise sur le marché toujours plus courts,face à une concurrence accrue.

Face à cette situation, les grandes entreprises dont l'activité porte sur la conception et laréalisation d'ensembles complexes ont été les premières à modifier leur structure en intégrantde nouveaux outils et l'ensemble des informations relatives au cycle de vie des produits afind'optimiser le triptyque « coûts - délais – qualité ».

8.4. L’Ingénierie Concourante et Ericsson

J’ai pu observer les indices de cette démarche, de façon plus concrète et plus proche, lors duprojet Mobile Switch Center 3.0. Nous avons vu que les enjeux de ce projet étaient multiples etau cœur de la troisième génération de téléphonie, avec une intégration progressive des réseauxUMTS et IP dans le réseau mobile GSM. La gestion des moyens mis en œuvre (méthodes etoutils de développement) a accompagné le projet tout en évoluant avec lui.

Cette organisation s’est reflétée par une structure matricielle des sous-projets, avec unmaillage métiers – projets, et impliquant une coordination de tous les domaines.Cette gestion de projets est similaire à celle décrite par Christophe Midler dans son livre« L’auto qui n’existait pas » (voir bibliographie) relatant la conception de la Twingo.



Pour synchroniser et coordonner toutes ces équipes, on a introduit la notion deworkpackages, et de plan d’anatomie établissant des incréments. Ainsi la conception a puévoluer tout au long du projet, et le plan d’anatomie n’a cessé d’être mis à jour.

Cette rectification constante est un élément de l’ingénierie concourante : comme il faut gérerles conflits entre les différents métiers (dans l’automobile le spécialiste du design pourra êtrecontre l’économie établie par l’analyse de la valeur) on converge sans cesse vers descompromis ou des décisions tranchées.

Cela s’est traduit dans notre projet par de nombreuses Requêtes de Changement (ChangeRequest), également justifiés par la complexité du projet.

8.5. Les outils logiciels de l’Ingénierie Concourante

L’Ingénierie Concourante est un sujet très vaste, qui fait référence à de nombreux outils etméthodes de qualité, de gestion de projet, de développement, de production, etc.Je limiterai ici cette étude à la contribution du Génie Logiciel aux activités suivantes del’Ingénieur Système: partage de l’information, modélisation, validation, et gestion deschangements.

Bases de Données Techniques

Le partage de l’information nécessite de lourdes infrastructures informatiques. Un Systèmede Gestion de Données Techniques permet la circulation, le partage et l’exploitation detoutes les informations relatives aux produits. Des outils spécialisés (CAO, FAO, GPAO,etc.) communiquent via ce système à la Base de Données Techniques, intégrant maquettesnumériques, nomenclatures, documents, bibliothèques, etc. On parle maintenant plus dePDM (Product Data Management) avec des outils comme Oracle, mais l’idée reste lamême.

Lors de l’Analyse des besoins, les exigences sont stockées dans la Base de DonnéesTechniques et seront exploitées et enrichies tout au long du cycle de développement à desfins de traçabilité.

Modélisation et Génération de Code

Le prototypage, ou modélisation, permet aux différentes équipes de formuler de façonformelle les exigences. Cette phase se compose de deux étapes : le prototypagefonctionnel (ou conception fonctionnelle), puis le prototypage physique (ou conceptiondétaillée).

Comme nous l’avons vu dans le compte-rendu de mes activités, le premier consiste àreprésenter, investiguer, et vérifier le comportement du Cahier Des Charges Fonctionnelpuis le second prend en compte les conditions matérielles (en l’occurrence lescaractéristiques du langage dédié, donc du processeur propre au commutateur de réseauxtéléphoniques d’Ericsson).



Le comportement d’un système réactif et distribué se modélise très bien au moyen d’unlangage basé sur les machines à état comme les Statechart∗ de Harel, SDL ou encore UML.

Les Statechart* ne peuvent être appliqués qu’à des systèmes peu complexes, et il estdifficile de réutiliser des automates déjà créés sans recourir au copier – coller.UML est un outil de modélisation aujourd’hui incontournable pour la représentationorientée objets, et peut être utilisé en amont de SDL.

SDL est particulièrement bien adapté à la modélisation physique et au codaged’applications distribuées. Il décrit aussi bien l’architecture du système (vision statique dumodèle) que son comportement (vision dynamique du système).

Un autre avantage est la génération de codes cibles , dont le C, le C++, et le C-micro pourles systèmes embarqués.

Il est capable aussi de décrire et intégrer plusieurs protocoles de communications,largement utilisés dans le monde des Télécoms mais aussi dans le développement orientéobjets : citons l’ASN.1 (Abstract Notation Syntax), MSC (Message Sequence Chart), IDL(Interface Description Langage), et Corba (Common Object Request Broker Architecture).Cet aspect lié à l’interface est essentiel pour faire face à la mise en commun de différentsdomaines d’application.

On peut observer que les deux langages et outils de modélisation que sont SDL et UMLsont en train de converger : la version SDL2000 est intégrée dans la version UML 2.0,mieux adaptée au Temps Réel.

Le principal fournisseur de SDL est Telelogic, qui intègre aussi aujourd’hui UML danssa suite, s’établissant ainsi comme le concurrent de la suite Rose de Rational.

La RATP utilise quant à elle la méthode B, langage formel de modélisation assezsimilaire. Les méthodes de modélisation telles que SA-RT, prédécesseur de UML, ne sontplus vraiment utilisées car elles sont informelles et ne permettent donc pas de formuler lespropriétés à vérifier sur le modèle. Enfin, il existe un autre langage formel de modélisationqui est utilisé par exemple par le CEA : Intermediate Format (IF).

Vérification et Validation

Les modèles fonctionnels et physiques doivent être simulés et validés dès que possible,comme nous l’avons constaté lors de la présentation de mes projets. Cette dernière activitéest aussi connue sous le nom de Model Checking. Elle permet de vérifier le comportementde processus communicants en réalisant toutes les exécutions rendues possibles par lemodèle et en vérifiant des propriétés sur ces états.

∗ voir glossaire



La validation permet d’obtenir une sécurité élevée du système (on parle aussi derobustesse), ce qui est devenu un critère primordial dans de nombreux domainesd’industrie.

Plusieurs outils de Model Checking commencent à être utilisés à l'échelon industrielpour des applications critiques en sûreté. La suite Tau de Telelogic, incluant SDL, en estune. La suite StateMate Magnum de I-Logix est aussi largement utilisée dans de nombreuxsecteurs de l’industrie.

Génération de Tests

Les activités liées au test peuvent être sensiblement améliorées si l’on met en œuvre unlangage de test standardisé comme TTCN (Tree and Tabular Combined Notation) ouencore TGV (Test Generation with Verification technology). Comme TTCN est unstandard, de nombreuses suites de tests sont disponibles sur le marché, pour les protocolesde télécommunications essentiellement (Bluetooth, UMTS, bus IEEE 1394, etc.)

Les scenarii de tests TTCN peuvent être automatiquement générés à partir du modèle SDL.Ils servent ainsi à passer les tests unitaires et les tests d’intégration. C’est ce qu’on appelledes tests de conformité, qui répondent à la question "Est-ce que le produit réalisé répondaux exigences ?"

Gestion des Changements et des Versions

Enfin, un cycle d’activités d’ingénierie qui se déroulerait sans retour en arrière et sansretouche est certainement trop idéal et irréaliste. On peut s’attendre à des évolutions despécifications ou de technologies, ou tout simplement à des itérations d’implémentation ouà des erreurs à corriger. Il est nécessaire de prendre en compte ces changements pour faireévoluer les modèles et les tests de non régression sur le produit.

Cette gestion des changements, ou de configuration, s’appliquera aussi bien pendant ladurée du cycle de développement (par exemple un an), que pendant la durée de vie de lafonction qui peut aisément dépasser une dizaine d’années.

Telelogic propose depuis peu de temps des solutions dans ce domaine, qui se veulent plustransparentes et simples d’utilisation que l’outil ClearCase du leader en ce domaine:Rational.



SDL et autres langages

En résumé, l’ingénierie concourante implique quatre aspects pratiques :

1. Communication et coordination : un système moderne de gestion de données, allié avecun outil de gestion des changements (versions), assure le développement en parallèle.

2. Standardisation : comme différentes technologies sont développées en même temps, etcomme l’industrie se modernise, il faut intégrer les interfaces entre les systèmes.

3. Modélisation : le prototype est l’élément commun aux intervenants, permettant deformuler et de comprendre la même chose, si possible jusqu’à la génération de code.

4. Vérification : les tests doivent être faits au plus tôt, sur le modèle et grâce au modèle.

Les différents langages centrés autour de SDL et répondant à ces besoins sont rappelés surla figure 10.

Figure 10 Relations entre SDL et autres langages

UML

MSCASN.1IDL

SDL TTCN

Produit Test duSystème

Spécifications Spécifications

Validation

Réutilisation

Spécifications

Réutilisation

Validation

Génération deTestsGénération de

Code

Test deConformité

Gestion deschangements

Génération deCode

ASN.1 : Abstract Syntax Notation1 (décrit des types et compositionsde données)

IDL : Interface DescriptionLangage (entrées et sorties desobjets)

MSC : Message Sequence Chart(diagramme séquentiel desmessages, utilisé pour décrire desprotocoles et des comportements)

SDL : Specification andDescription Langage

TTCN : Tabular Tree CombinedNotation (description de suite detests)

UML : Unified Modeling Langage(spécification, modélisation desobjets)



8.6. Conclusion : Ingénierie Concourante ou conception parallèle ?

Doit-on donc parler d’Ingénierie Concourante, ou seulement de travail incrémental etparallèle ?La définition de l’Ingénierie Concourante n’est pas unique, et possède différentes facettes.Sans doute est-elle explicitement appliquée par Ericsson à un niveau très haut dedéveloppement de gammes de produits, surtout dans le domaine de la téléphonie de troisièmegénération, et peut-être plus implicitement au niveau du développement logiciel.Le principe de développement en parallèle existe depuis fort longtemps, cependant depuisquelques années on peut observer quelques changements, au niveau des outils et des processusde travail.

L’Ingénierie Concourante implique une organisation en maillage métiers - fonctions,une forte communication et coordination, le recours à la modélisation et au prototypage, unegestion des données techniques et variées et une gestion des tâches en parallèle. Mon rôle decoordinateur pour des projets de taille importante prend tout son sens dans ce contexte.

La mise en œuvre de méthodes formelles, et des moyens de tester et valider un modèlerépond aux besoins de l’ingénierie concourante. Elle s’inscrit dans les activités de l’IngénierieSystème, et se matérialise par les méthodes et outils proposés par le génie logiciel.

SDL s’inscrit dans une suite de logiciels accompagnant l’Ingénieur Système tout au long ducycle de développement, de l’écriture textuelle de l’analyse des besoins, jusqu’aux phases detests, en passant même par la génération de code, comme l’illustre la figure 4.

Les outils et méthodes présentées dans cette étude peuvent s’appliquer aussi bien au logicielembarqué pour l’automobile, aux fonctions avioniques, aux serveurs WAP ou UMTS, auxsystèmes d’aiguillage ferroviaire ou au métro METEOR de la RATP. Il faut souligner l’enjeuactuel des Systèmes Embarqués dans l’industrie, avec ce que cela implique de modélisation etde validation logicielle.

Telelogic a racheté de nombreuses entreprises dans beaucoup de pays (comme le spécialistefrançais de SDL Verilog et le leader de la gestion de configuration américain Continuus) afinde proposer des solutions complètes dans ce domaine.

Il est donc important de connaître ces techniques et leurs contextes dans l’hypothèse d’unéventuel partenariat entre Telelogic et Teleca, ou tout simplement pour satisfaire nos futursclients.



9. Conclusion Technique

Les réseaux de télécommunication sont de différentes natures, et Ericsson a mis au pointun système présent à de nombreux points de ces réseaux : le commutateur numérique AXE10.Ses applications sont multiples, et prennent une nouvelle dimension aujourd’hui avec lamigration vers les réseaux UMTS et le « tout en IP ».

Le langage développé et implémenté dans ce commutateur, par Ericsson, estpropriétaire. Il a peu évolué depuis les années 70 : il est textuel et relativement basique.Cependant il est dédié, et répond donc aux besoins propres à ces réseaux : il peut gérer desmilliers d’appels et de transferts de données en même temps et effectuer des routages versd’autres points du réseau. Certains outils périphériques, eux aussi dédiés, ont été développés ,par exemple pour faciliter la tâche des testeurs.

Mais aujourd’hui, il faut concevoir plus vite, et ensemble. Le génie logiciel a fait desprogrès considérables dans le domaine graphique, dans la simulation, dans la génération decode, etc.SDL est un langage ayant de tels attributs. De plus, il a été mis au point par le monde destélécommunications ; il est très proche du langage d’Ericsson et il suffit d’en adapter legénérateur de code pour en faire un outil puissant de modélisation fonctionnelle ET physique.

SDL est maintenant bien implanté dans le développement logiciel du commutateurAXE10, et il commence à être harmonisé avec certains outils périphériques. Développer enSDL un bloc n’est plus une originalité locale, c’est un processus coordonné et normalisé.Ses atouts par rapport à la méthodologie classique sont indéniables, que ce soit au niveau de ladocumentation modélisée ou de la possibilité de tester rapidement.

C’est dans ce contexte que je me suis employé à mettre en place des méthodes, desoutils logiciels et des documents concernant ce langage dans le développement logiciel au seind’Ericsson. Parallèlement, j’ai constamment exercé des tâches relatives aux différentes phasesdes projets.

Mes compétences en SDL et la maîtrise de mon environnement de travail m’ont mené àavoir des fonctions de soutien, d’accompagnement du personnel, de formation, et de gestiondes méthodes et des outils au sein d’un projet.



10. Conclusion générale

Mon travail au sein du département de Recherche & Développement au sein d’Ericsson,puis de Teleca, m’a permis de bien comprendre les différentes activités du cycle dedéveloppement, en l’occurrence de produits dédiés aux réseaux de télécommunications.J’ai compris l’importance de décrire, documenter, modéliser les fonctionnalités d’un systèmeavant d’effectuer un codage clair et efficace.

J’ai rapidement été considéré comme expert SDL ; cela ne m’a pris que quelques moispour maîtriser ce langage tant il était intuitif, logique, et somme toute assez simple. C’est plutôt un travail à tous les niveaux, et une suite d’initiatives personnelles, qui m’ontpermis d’évoluer, et d’acquérir une connaissance des réseaux de télécommunication, desprotocoles, du C, d’Unix, des logiciels utilisés par Ericsson, et bien sûr et surtout des relationshumaines, en faisant par exemple activement partie d’un réseau international d’experts.

Cette expérience m’a aussi permis de connaître différents pays et cultures et de travailleren collaboration avec mes collègues d’ici ou d’ailleurs, en les accompagnant dans leur travailvoire en les aidant à se former, que ce soit en français, en anglais voire même en espagnol .

La conjoncture économique actuelle a mis en veilleuse les ambitions qui avaient pour butde promouvoir de nouvelles méthodes de travail ; on préfère se recentrer sur des valeurs« sûres » plutôt qu’innovantes. Cependant SDL continue d’être très présent, notamment dans lenouveau projet Mobile Switch Center 4.0.

Heureusement, les applications de tels langages ne sont pas réservés à Ericsson, ni mêmeau seul domaine des télécommunications. L’éditeur principal de ce langage, Telelogic, proposetoute une gamme de suites logicielles, allant de la gestion de changements à la validation enpassant par la modélisation, et plus encore. Telelogic travaille avec de nombreux domainesd’industries comme la Défense, l’Automobile, l’Aérospatiale, l’électronique, etc.

Mes connaissances devraient donc me permettre d’élargir mes horizons, de m’instruire surde nouveaux domaines voire sur de nouveaux métiers.Le diplôme d’Ingénieur-Maître me permettra de valider mon expérience au sein d’Ericssonpour débuter une nouvelle carrière plus évolutive, donc mieux adaptée a la prestation de serviceau sein de Teleca.



BBiibblliiooggrraapphhiiee

Ingénierie Concourante / Simultanée :

L’auto qui n’existait pas, Management des projets et Transformation de l’entrepriseChristophe Midler Edition InterEditions

Management des Nouveaux Projets Sandrine Fernez-Walch Edition AFNOR

Documents internes :

Work Instructions : Simulation and Validation using SDLReview & Inspection with SDL

Rapports Finaux de projets : Prototype SDLDBQAM (DataBase Query Application Module), Mobile SwitchCenter 3.0

Manuels internes : Telelogic : Introduction to SDL Ericsson : SDLtool Tutorial for Testers

SDL StyleGuide

WWeebb BBiibblliiooggrraapphhiiee

A propos de SDL : IEC: Specification and Description Language (SDL)

http://www.iec.org/online/tutorials/sdl/index.html SDL-2000 Tutorial

http://www.informatik.hu-berlin.de/~holz/SDLTutorial/SAMTutorialFinal.html SDL Forum

http://www.sdl-forum.org/SDL/index.htm

A propos de UML : UML Organization

http://www.uml.org

Les entreprises : Ericsson France

http://www.ericsson.fr Teleca France

http://www.teleca.fr Telelogic

http://www.telelogic.com Rational

http://www.rational.com

Ingénierie Concourante / Simultanée :Les technologies clés - Ingénierie simultanée

http://www.evariste.org/100tc/1996/f117.html

http://www.iec.org/online/tutorials/sdl/index.html

http://www.informatik.hu-berlin.de/~holz/SDLTutorial/SAMTutorialFinal.html

http://www.sdl-forum.org/SDL/index.htm

http://www.uml.org/

http://www.ericsson.fr/

http://www.teleca.fr/

http://www.uml.org/

http://www.ericsson.com/

http://www.evariste.org/100tc/1996/f117.html



TTaabbllee ddeess IIlllluussttrraattiioonnss

Figure 1 Organisation du Groupe Ericsson (simplifiée) __________________ 11

Figure 2 Les applications du commutateur AXE 10 dans les différents réseaux

téléphoniques ___________________________________________________ 12

Figure 3 Organigramme de la R&D Ericsson / Teleca ___________________ 15

Figure 4 Spectre de mes activités ____________________________________ 17

Figure 5 Mes interlocuteurs ________________________________________ 19

Figure 6 Le processus de développement logiciel de l’AXE10 avec SDL _____ 27

Figure 7 Conception fonctionnelle avec SDL : diagrammes HMSC et MSC ___ 29

Figure 8 Maillage Projets – Métiers _________________________________ 34

Figure 9 Workpackages et Incréments ________________________________ 35

Figure 10 Relations entre SDL et autres langages_______________________ 50



AAnnnneexxeess

En annexe sont proposés quelques exemples de présentations SDL pour Ericsson et Teleca,extraits des modules suivants : - Introduction to SDL ;- MSC Basics ;- SDL Basics ;- Simulation with SDL ;- Validation with SDL.



TELECA Sami Yurdakul Introduction to SDL Module 1. 1 - Slide 1

Introduction toSDL


History of SDL

1972 - CCITT study group

1976 - First Recommendation

1984 - Data and structure introduced

1988 - SDL reaches maturity as an FDT (Formal

Description Technique)

1992 - Object orientation introduced

2000 - Links to UML and improvement in the use

of SDL for implementation




SDL Application Areas

Hi Jane

Intelligent Networks

Datacoms

Network Management

Switching

Services

Automotive

Aerospace

UMTSAccess Networks

GSM

Terminals

Application Areas


Benefits of SDLSDL is:

A language of engineers Standardised Formal Able to maintain, analyse, verify, validate and simulate specifications and to generate code

SDL consists of: A graphical representation -> Higher Quality Different abstraction levels




Telelogic Tau

SDL Editor

Utilities Analyzer

Link ManagerViewers

OMEditor

State ChartEditor

(H)MSCEditor

Text Editor

Simulator

CodegeneratorOrganizer

Validator TTCNLink


MSCs (Message Sequence Charts) in SystemDevelopment

Requirements capture

Specification of use-case scenarios

Behaviour verification of SDL specifications

MSCs have several design-level uses:




An MSC Specification


Basic MSC

A graphical (and textual) trace and specification

language

Focuses on the communication behaviour

Message inter-exchange between communicating

entities and their environment

Standardised in ITU-T Recommendation Z.120




Basic MSCMSC SEIZURE

MCSEblockMCSEenvironment

IDLE

ProcessCreation

SEIZEMCSE

SEIZEMCSER

Instance KindInstance Head

Condition

Message

Action

Instance Timeline

Instance End

MSC Heading

environment


Inline Nesting and MSC Reference Expression

EXC:Error occursduring connection

FOAM MTAP

IDLE

APCONNECT

CONNECTED

OptInitiate_ Alarm

APERROR

APCONNECT

CONNECTED

APCONNECTED

APCONNECTED

1

1

2

2

exc

loop

OPT:Alarm is initiatedwhen connection fails

LOOP:Recurrentattempts to reconnect.




High Level MSC (HMSC)

A road map approach

Better overview of more complicated behaviour.

Shows how MSCs are related by conditions

Consists of references to other HMSCs and MSCs


HMSC Idle

UserRejected

UserAccepted

UnlockedReset

UnlockedTimeout

UnlockedUnclosed

DoorUnlocked

User codeIncorrect

Start

ConnectionPoint

MSCReference

End

TextSymbol

Idle

User codeCorrect

Idle




SDL language consists of ...

• AArchitecture

• BBehaviour

• CCommunication

• DData


Components of an SDL System

Process Processes are defined as nestedhierarchical state machines

System

The System is where all blocks areconnected to each other and to theenvironment

Block

Blocks are a set of processes andother blocks grouped together

Procedures may be recursivelyimplemented, they can be both local totheir process or global

Procedure

Procedure




System and Environment


Block Interaction




Block Level


Process Creation without and with Parameters




Input Queue of Signals, Save


Parameters in Input and Output Signals




Simple Predefined Sorts in SDL (1/ 3)

Boolean True or False

Character ‘a’, ‘-’, ‘P’, ‘2’, ‘%’

Charstring ‘abc 123’, ‘@%!?!$’

Integer -88, -2, 0, 5, 100000

Natural 5, 173, 100000

Real -2.354, 0.9834, 23.0


Executing a Simulation

Starting an SDT Simulator

Using the SDT Simulator User Interface

Tracing simulations

Executing a simulation

Sending signals

Viewing options

Setting Breakpoints

In this module the following basic functionality will bedescribed:




Tracing a Simulation

Show SDL Symbol

SDL Trace (SDL Editor) MSC Trace (MSC Editor) Text Trace (Log in Simulator UI)

Show Next / Prev SDL Symbol


The Coverage Viewer




Simulation vs Validation

Coverage of a Simulation Coverage of a Validation


Validation

Check the interfaces

Check process creation and termination

Check for deadlocks

Check for output errors

Check that variable ranges are respected

Check for unwanted implicit signal consumption

Check for loops

Validation is performed to:




Controlling the State-Space by definingTest Values

. . . . . . . .

Integer=0 Integer=1Integer = Infinity Integer = Infinity


Exploration Algorithms

Exhaustive Exploration

Bit-State Exploration

Random-Walk

Power-Walk

The different Exploration Algorithms are automaticand are suitable for different stages of theValidation: