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

28 septembre 2000 Alcatel CIT SRD/R&D/T&T - Présentation Processus Objet 1

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

SRD/R&D/Tools & [email protected]


Introduction de l'OO à Alcatel CIT

Fin 97

Déroulement despremiers “ProjetsPionniers”

Dossierderetourd'expé-rience

Contrat deProjetPionnier

1998 Fin 98 1999...

Généralisation+Guide de conduitedes projets objetDéfinition d’un

ProcessusObjet


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

Etablissementdu Contrat

Analyse Générale

Production= Codage

+ T.U.+ Essais d'intégration

Essais Fonctionnels

Essais d'ensemble

DR1

DR4

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

Modélisation duProblème :ConceptualisationAnalyseStatique & Dynamique

Modélisation desComposants d'ArchitectureDiagrammes d'AnalyseStatiques & Dynamiques

Modèle de ConceptionGénération de CodeTests unitairesIntégration/Validation

Objets Métiers du Domaine Objets TechniquesRéutilisables

Règles

Problème Solution(s)


Déroulement du Processus Objet

Conceptualisation & Pré-spécification

Conc. préliminaire

Spécification incrémentale

Maquettage

Architecture

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

target machine Hardware

Programmer's Guideexisting code

OS features

ConfigurationManagement

C files error files

LDS.pr files

Code generator


Evolution du générateur

Modèles + non formel LDS

Code C

architecturearchitecture

UML / XMI UML

Code C/C++

1999 2001Generator Generator


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

UML

POP-Wizard / WADS

Implementation

Documentation

Configuration Management

Visual C++, Embedded & native C++, Java

ClearCase

ValidationSTP Rose 98i / Rose 2000 / (Objecteering)

HTML

CodeWizardProgramming rules


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

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

Documents

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