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

Présentation au sujet: "Présentation du Processus Objet “en Y” d’Alcatel CIT"— Transcription de la présentation:

1 Présentation du Processus Objet “en Y” d’Alcatel CIT
SRD/R&D/Tools & Technologies

2 Introduction de l'OO à Alcatel CIT
Fin 97 1998 Fin 98 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 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

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

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 LDS.pr files Configuration Management target machine Hardware Code generator existing code Programmer's Guide 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
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 LDS88 pour LDS92/96 + NT ==> besoins : - spécifications ETSI (LDS92/96) - ASN1, INAP (BCC:Nantes, BST:Roumanie) GEODE : pour T NT pour 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

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