Passionné de nouvelles technologies... la gestion de projets informatiques est mon métier...

L'émergence et la popularité grandissante des technologies objet (méthodes, architectures et langages) influence fortement la gestion et l'organisation de nos projets. La mise en place d'un nouveau projet doit être progressive, faisant migrer les systèmes actuels vers de nouvelles architectures (CORBA, ActiveX COM/DCOM, JavaBeans RMI).
Les exigences qualité des nouveaux systèmes se formalisent chaque jour d'avantage mettant en place des principes , des procédures et des outils de plus en plus rigoureux sur la mesure de la qualité de notre production (Normes qualité).
La gestion du projet doit mettre en avant le respect des concepts immanents objet et garantir ainsi l'obtention de produits de qualité.

Dans la nature, les systèmes complexes sont toujours des évolutions de systèmes plus simples.

Gestion de production

Pour répondre à ces exigences chaque cycle de production enchaîne les phases suivantes :

1. Rédaction d'un Plan qualité (Principes de production : suivi, mesure et contrôle de la qualité de la production)
2. Rédaction d'un Plan de production (Méthodes, Procédures, Ressources et Outils de production)
3. Analyse (Formalisation du besoin : Modélisation et cas d'utilisation)
4. Conception (Décomposition du besoin en adéquation avec un Plan d'architecture)
5. Compilation (Assemblage des modules identifiés lors de la phase de conception)
6. Test (Contrôle de l'assemblage et adéquation avec le besoin)
7. Recette (Comparaison entre le prévu et le réalisé, mesure des écarts)

Les phases 4 et 5 peuvent être substituées par une phase de choix de produit.

Chaque produit, qu'il soit microscopique ou macroscopique, présente le même cycle de production.
Une vue d'ensemble d'un produit global, comme la vue détaillée d'un de ses sous-produits présente la même physionomie de cycle de production.
Les produits s'enrichissent à chaque itération, dans leur complétude et leur qualité.

Les différentes phases se succèdent pour former un cycle de production. Des jalons fixent la fin d'une phase et le début de la phase suivante. Chaque itération est représentée par le déroulement d'un cycle de production.
L'ensemble des cycles est représenté par des cercles concentriques. La chronologie des cycles commence du centre vers l'extérieur. Le centre représente le produit existant, la création du produit ou le premier prototype du produit. Plusieurs cycle peuvent être en cours dans différentes phases pour différentes évolutions de produit. Ainsi l'Analyse du produit X d'évolution V2 peut être en cours alors que le produit X d'évolution V1 est en phase de compilation. Le produit X V2 ne tient pas compte de l'expérience de production du produit X V1. En effet la fin de la phase de recette du produit X V1 n'est pas prononcée. Il y a étanchéité entre les phases et les cycles non archivés.

Chaque nouveau cycle est identifié par un numéro d'archivage (ou numéro d'évolution). Ce numéro permet de distinguer chaque nouvelle évolution d'un produit.
La phase suivante au cours d'un même cycle n'autorise pas d'influencer ou d'altérer les phases précédentes préalablement fixés par leur jalon respectif de fin de phase (production archivée non modifiable). C'est à dire qu'on ne revient jamais en arrière.
Chaque phase du cycle est lui même représenté par un ou plusieurs cycles de production. Durant chaque phase est élaboré un produit. Ce Produit est la fourniture principale initiatrice de la phase suivante.
La phase de conception fait apparaître un ensemble de sous produit qui devront être assemblés durant la phase de compilation. Chaque sous-produit possède son propre cycle de production. Durant la phase de conception il est possible d'identifier des produits déjà présents dans le système. Ces produits pourront alors être réutilisés tels quels, faire l'objet d'une nouvelle évolution avant d'être assemblés. Pour certains produits génériques ou paramétrables il sera nécessaire de préciser les valeurs des paramètres du produit à assembler.
Les Processus et les tâches de chaque phase sont spécifiques à de la nature du produit.
Un cycle ne concerne qu'un seul produit ou composante du système. Ce produit est obligatoirement un assemblage de sous-produits.
La phase de compilation n'est toujours qu'une phase d'assemblage de produits stabilisés et acceptés durant la phase de recette de leur cycle respectif.

Un des 4 prononcés de recette suivant doit être émis en fin de cycle pour chaque produit archivé :

1. Accepté : La produit accepté peut être assemblé durant la phase de compilation du cycle moins élémentaire l'ayant identifié durant la phase de conception.
2. Accepté avec réserve : Le produit accepté peut être assemblé durant la phase de compilation du cycle moins élémentaire l'ayant identifié durant la phase de conception. Mais attention ce produit présente des anomalies pouvant être tolérées dans certaines conditions d'utilisation qu'il est important de consulter avant tout assemblage.
3. Refusé : Le produit n'est pas conforme aux critères de recette. Un nouveau cycle doit être envisagé afin de corriger sa non conformité. Ce produit archivé ne pourra jamais être assemblé au sein d'un produit plus macroscopique.
4. Abandonné : Le produit ne peut définitivement pas être conforme aux critères de recette. Ce produit archivé ne pourra jamais être assemblé au sein d'un produit plus macroscopique.

• Les cycles et les phases ont des délais réduits.
• Les enchaînements des cycles et des phases sont automatiques.
• Les produits issus d'une phase ou d'un cycle sont directement exploitables sans traduction.
• La disponibilité des produits est immédiate.
• Les produits sont documentés : manuels de référence, d'utilisation, d'installation et d'exploitation.
• Plusieurs évolutions d'un même produit sont disponibles simultanément.
• La substitution d'une évolution de produit par une évolution compatible du même produit est facile.
• La substitution d'un produit par un autre produit compatible est facile.
• La recherche des produits suivant différents critères ou à partir des caractéristiques d'un produit est possible.
• La navigation d'un produit vers un autre produit lié est facile.
• La comparaison de plusieurs évolutions d'un même produit, plusieurs produits est possible.
• L'identification de chaque produit est unique.
• L'archivage et d'édition des produits est simple.
• L'interface des produits est standardisée.
• Les formalismes, les méthodes et les procédures sont standardisées.
• Les architectures sont uniformes : objets distribuables pouvant communiquer de manière asynchrone.
• Les spécifications des cas d'utilisation est des scénarios de test sont formalisées. Le déroulement des tests est automatique et reproductible.
• Chaque test est indépendant et il correspond à l'appel d'un service d'un produit.
• Le résultat d'un test est correct ou incorrect.
• Le prononcé de recette du produit est uniquement fonction des résultats des tests.
• La planification et le compte rendu d'avancement est automatique : évaluations des charges, charges consommées, affectation des ressources, synchronisation des cycles et phases de production.
• Les cycles et les phases sont indépendants : Produits en entrée => Produits en sortie.
• Seule la phase de conception offre une approche descendante puis ascendante et peut être mise en attente de produits d'assemblage. Il est préférable de concevoir un produit à partir de produits existants et maîtrisés.

• Demande de création ou modification de produit
• Plan qualité
  Principes de production, mesures et contrôles qualité
• Plan de Production
  Méthodes, Procédures, Ressources et Outils de production
  Planning prévisionnelles
• Formalisation du besoin, Cas d'utilisation et Scénarios de test
• Plan d'architecture et Sous-produits (sources d'assemblage)
• Compilation (statistique sur l'assemblage du produit)
• Résultats de test
• Prononcé de Recette
• Relevé périodique de suivi de production
  charges prévisionnelles, % d'avancement, difficultés rencontrées etc.)

• Identifiant & Numéro d'archivage
• Prononcé de la recette
• Manuel de référence
• Manuel d'utilisation
• Manuel d'installation
• Manuel d'exploitation

De la qualité et de la formalisation de cette documentation dépendra la qualité du produit et donc de sa réutilisation.

Les principes de cette gestion de production sont cohérents avec les principes d'architecture de services proposés.
Chaque produit ou objet

• a un identifiant unique complété par un numéro d'archive,
• est catalogué dans des Annuaires,
• décrit ses conditions d'utilisation et d'exploitation,
• peut être référencé pour construire d'autres produits,
• peut référencer plusieurs produits,
• est persistant,
• n'a d'existence que parce qu'il est composant d'au moins une autre produit,
• présente une séparation claire entre l'interface et l'implémentation,
• permet une abstraction simplificatrice de ses mécanismes et de son architecture.

1. Plan qualité (PQPO)

   Le plan qualité va préciser les principes de production :
   • définition et objectif de la qualité
   • cycle de production
   • approvisionnement des produits
   • livraison des produits
   • planification et suivi de la production
   • mesures de la conformité des produits
   • contrôles de la conformité des produits
   • identification, traçabilité, archivage des produits
   • décomposition des produits

    

2. Plan de production

   Le plan de production va préciser les méthodes, les normes et les standards, les procédures, ressources et les outils nécessaires à la production.
   Le plan de production estime les coûts (produits, charges, ressources) et planifie (synchronisation et délais) les phases du cycle de production.
   Le Plan de production respecte les principes énoncés dans le Plan qualité.

    

3. Analyse

   L'analyse va recueillir et formaliser le besoin. L'analyse établit les cas d'utilisation du produit. Un ensemble de scénarios illustre les cas d'utilisation. Ces cas d'utilisation serviront au déroulement de tests du produit.
   Durant l'analyse une première partie de la documentation du produit est produite :
   
   • une vue interne : Dossier d'analyse du besoin & Dossier de tests et de recette,
   • une vue externe : le manuel de référence & la manuel d'utilisation du produit.

   Les cas d'utilisation et scénarios clarifient et valident l'analyse. Ces cas d'utilisation permettent de découvrir les objets et leur interface.
   Le dossier de tests et de recette précise la fonction de détermination du prononcé de recette du produit en fonction des résultats des tests.
   Le résultat d'un test est correct ou incorrect. L'analyse respecte les consignes du Plan de production.

    

4. Conception

   La Conception décompose le besoin en un ensemble de besoins plus élémentaires qui devront être assemblés conformément un Plan d'architecture du produit.
   Les besoins élémentaires identifiés, il faut déterminer pour chaque besoin s'il faut réutiliser ou adapter un produit existant ou développer un nouveau produit. Le choix de produits ou de sous-produits s'effectue durant cette phase. Plusieurs Plans d'architecture peuvent être évalués utilisant des sous-produits différents, connus ou inconnus, exitants ou inexistants

   Le Plan d'architecture comporte différentes vues qui clarifient et valident la cohérence de l'architecture choisie :

   • une vue logique faisant abstraction de la technique se concentre sur le besoin fonctionnelle de l'utilisateur
     (Abstraction, Encapsulation, Uniformité, Ergonomie)
   • une vue des processus précise les contraintes de synchronisation des demandes de service et les interactions avec l'extérieur (IHM)
     (Disponibilité du système, Fiabilité, Robustesse, Performance)
   • une vue de réalisation organise la production en rapport au Plan de production
     (Modularité, Lisibilité, Maintenabilité)
   • une vue de déploiement précise la distribution physique du produit en fonction de ses pré requis logiciels et matériels
     (Instanciation, Distribution, Répartition, Interconnexion)

   Les scénarios issus des cas d'utilisation sont complétés en intégrant l'architecture interne du produit. Ces scénarios valide l'architecture.

   Durant la conception la seconde partie de la documentation du produit est produite :

   • une vue interne : les différentes vues du Plan d'architecture du produit,
   • une vue externe : le manuel d'installation et le manuel d'exploitation du produit.

   Les objets issus de l'analyse ou objets métier sont assemblés avec des objets techniques ou génériques liés aux contraintes physiques de l'architecture.
   Ces objets techniques apportent un ensemble de services aux objets métier :

   • les objets de présentation (affichage, immpression),
   • les objets d'interaction (Interface Homme Machine, synchronisation des communications avec d'autres objets),
   • les objets de persistence (Historisation des propriétés d'états stables et cohérents),
   • ...
   Les services objet communs de l'architecture CORBA assurent les fonctionnalités communes aux objets.

    

5. Compilation

   La compilation représente l'assemblage de produit répondant aux besoins élémentaires conformément aux consignes décrites dans le Plan d'architecture du produit.
   C'est en fin de compilation qu'apparaît une nouvelle archive du produit.

    

6. Test

   Le test déroule chacun des scénarios issus des cas d'utilisation décrits durant l'analyse et complétés durant la phase de conception. Pour chaque scénarios sont identifiées les divergences entre les mesures réellement observées et les résultats théoriquement attendus.
   Le résultat d'un test est correct ou incorrect.
   Chaque test est indépendant et il correspondant à l'appel d'un service du produit.

    

7. Recette

   La recette contrôle les résultats du déroulement des tests et se prononce sur la qualité du produit. Ce prononcé détermine le devenir du produit et son utilisation potentielle par d'autres fourniture.
   Le prononcé de recette du produit est uniquement fonction des résultats des tests. Les critères de recette sont déterminés durant la phase d'analyse. La description des symptômes ayant permis de juger le test incorrect n'est pas prise en compte pour la détermination du prononcé de recette. Seules les valeurs correctes et incorrectes des résultats des tests déterminent le prononcé de recette.