Présentation du Processus Objet “en Y” d’Alcatel CIT

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

2. 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

3. 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

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

5. 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

6. 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

7. 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

8. Documents-produits du Processus Objet • Requirements Formal Document generatedcontains traceability with requirements in TRS (Document de Formalisation des Besoins) • Software and Reused Components Document • Software Specification Document generatedcontains 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 generatedcontains 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)

9. 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)

10. 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

11. 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

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

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

14. 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

15. Outils et AGLs pour l'Objet Validation STP Rose 98i / Rose 2000 / (Objecteering) UML HTML POP-Wizard / WADS Documentation Visual C++, Embedded & native C++, Java Implementation ClearCase Configuration Management Programming rules CodeWizard

16. 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

17. 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…)