Présentation du Processus Objet “en Y” d’Alcatel CIT SRD/R&D/Tools & Technologies Philippe.Larvet@alcatel.fr

Introduction de l'OO à Alcatel CIT Fin 97 1998 Fin 98 1999... Contrat de Projet Pionnier Déroulement des premiers “Projets Pionniers” Dossier de retour d'expé- rience Généralisation + Guide de conduite des projets objet Définition d’un Processus Objet

Conduite des Projets OO Tous nos projets sont sous “Assurance Qualité” Le Système Qualité “Direction Technique” est la référence en “méthode” de conduite de projets Tous les documents utilisés pour un projet Objet y sont référencés : Procédure de Gestion de projet Guide de conduite de projet Objet Procédure des phases du cycle de développement Objet (description détaillée du Processus Objet) Guide de modélisation UML Procédure de gestion de la Base de Composants

Positionnement du P.O. dans le cycle en V Alcatel CIT DR4 Etablissement du Contrat Essais d'ensemble DR1 Analyse Générale Essais Fonctionnels Production = Codage + T.U. + Essais d'intégration Processus Objet

Processus de développement Objet Le Processus Objet est un processus générique, instancié pour chaque projet Particularités de ce processus : spécification par parties (incréments et prototypage) parallélisation des activités de spécification et d'analyse de l'architecture (cycle en Y) “component-based” (Base de Composants) “model-driven” : génération de documentation et de code à partir des modèles UML traçabilité complète des exigences -> code métriques pour l'amélioration continue du processus

Principe du Processus Objet Double exploitation du Cahier des Charges : Expression des Besoins Solution(s) Problème Modélisation du Problème : Conceptualisation Analyse Statique & Dynamique Modélisation des Composants d'Architecture Diagrammes d'Analyse Statiques & Dynamiques Règles Objets Métiers du Domaine Objets Techniques Réutilisables Modèle de Conception Génération de Code Tests unitaires Intégration/Validation

Déroulement du Processus Objet Conceptualisation & Pré-spécification Spécification incrémentale Architecture Maquettage Conc. préliminaire Conc. détaillée Codage, TU, Intégration Validation

Documents-produits du Processus Objet Requirements Formal Document generated contains traceability with requirements in TRS (Document de Formalisation des Besoins) Software and Reused Components Document Software Specification Document generated contains traceability with requirements in TRS (Document de Spécification) Software Architecture Requirements Document generated Software Architecture Document generated Software Integration Plan (Plan d’intégration) Detailed Software Design Document generated contains traceability with requirements in TRS (Dossier de Conception Détaillée) Unitary Tests Document (Document de Test Unitaire) Software Qualification Handbook (Cahier de Qualification) Software Acceptance Test Handbook (Cahier de Recette)

Justification du Processus Objet “en Y” L'utilisation d'un langage OO ne suffit pas pour faire de l'objet. Notre Processus Objet “en Y” permet : d'obtenir un “retour sur investissement” par la réutilisation (composants) de fractionner les spécifications d'organiser la division du travail et la parallélisation des activités de mesurer le développement (métriques) d’améliorer le processus lui-même (continuous process improvement)

Intégration de l’existant dans les projets Objet Dans quasiment tous les cas, les projets Objet sont, in fine, intégrés à un existant non objet On distinguera deux catégories de projets Objet : 1) Les projets “tout objet” principe : serveur de services, développé en OO (UML, C++, Java, CORBA) connecté à un existant non objet “détourage” de l’existant + interfaces + intégration 2) Les projets “semi-objet” fortement intégrés à l’existant analyse objet UML, développement en LDS96 (par exemple) dans certains cas, ré-ingénierie vers UML d’un existant non-objet

Utilisation d’UML pour implémenter du code non-objet Utilisation d’un générateur maison LDS->C Analyse objet avec UML Traduction de l’architecture UML vers une architecture LDS96 (outil interne) (system, blocks, process, services, procedures, etc.) Ecriture complémentaire du LDS96 “full formal” fonctionnel Paramétrage du générateur avec des éléments non fonctionnels (application du cycle en Y) Génération de 100% du code C Le code C généré n’est JAMAIS retouché manuellement

Environnement du générateur OS features LDS.pr files Configuration Management target machine Hardware Code generator existing code Programmer's Guide error files C files

Evolution du générateur Modèles + non formel LDS UML / XMI UML architecture architecture Generator Generator 1999 2001 Code C Code C/C++

Les projets OO Alcatel CIT Plusieurs projets OO ont été réalisés selon cette approche Administration Agent Q3 pour plate-forme Unix Téléphonie mobile norme GPRS Temps-réel embarqué, gestion de stations d’énergie Serveur de Base de données télécom Nouvelle fonction de traitement d’appel UML->LDS96 Ré-ingénierie de logiciel traitement d’appel LDS88->UML->LDS96

Outils et AGLs pour l'Objet Rose 98i / Rose 2000 / (Objecteering) Validation STP UML HTML POP-Wizard / WADS Documentation Visual C++, Embedded & native C++, Java Implementation ClearCase Configuration Management Remarques : SOLANGE : pour 1997 - LDS88 pour 1998 - LDS92/96 + NT ==> besoins : - spécifications ETSI (LDS92/96) - ASN1, INAP (BCC:Nantes, BST:Roumanie) GEODE : pour T1 98 - NT pour 1998 - prise en compte MSC : (Message Sequence Chart) ==> besoins: - remplacement ASCOT - usage : spécifications, scénarios de tests (fonctionnel,séquentiels de test(EF,EE)) ClearCase : pour T1 98 (spécifique=«merge graphique») UML : lien avec «Orienté Objet» pour 1999 ==> «Screen» : plateforme de développement de services (basé TINA) Programming rules CodeWizard 4

Formation et déploiement d’UML Formations préliminaires à UML dans “Tools & Technologies” (managers, décideurs, chefs de projet) Formation des équipes SYSTEME (analyse UML) Formation des développeurs “just in time”, selon les besoins des projets (analyse, conception, développement) “Contrat de Projet” signé entre le Projet et T&T pour assurer la réussite du projet (tuteurs + experts) le transfert de savoir-faire Application de la règle du 1/3 L’essaimage UML se fait naturellement, au fil des projets

En guise de conclusion Processus mature, opérationnel, industriel, mais non figé. Actuellement en cours de déploiement dans SRD un dispositif de déploiement “grand V” est nécessaire 4000 ingénieurs concernés, actuellement moins de 100 touchés Le principe du “cycle en Y” ne pose pas de problème existentiel aux équipes (habitude du Generator LDS ?). L’approche itérative/incrémentale/model-driven passe bien. L’existence/utilisation d’une Base de composants réutilisables est bien vécue. La culture UML, en revanche, est un peu plus longue à s’imposer (plusieurs années ont été nécessaires pour LDS…)