Quel est votre processus de révision pour le développement de Rhapsody?

Question

Mon équipe utilise l'outil IBM Rhapsody pour effectuer un développement intégré en temps réel. Malheureusement, nous sommes mécontents de notre processus d'examen actuel.

Plus précisément, nous avons eu des difficultés parce que:

• il y a un manque d'un bon outil de diff pour le diagramme change
• l'outil diff Rhapsody ne génère pas de rapports que vous pouvez utiliser dans un examen
historique du fichier source
• est inégale, car les fichiers source sont produits dans CDEM donc pas configurés dans un VCS à une granularité élevée
• en cours d'exécution diffs sur le code source tractions parfois sans rapport avec les changements effectués par d'autres devs
• parfois changer une propriété d'un élément de modèle modifie des dizaines de fichiers source
• il est facile de changer un fichier source par un changement de propriété et ne pas le savoir

Quelqu'un at-il des conseils pour faire des examens par les pairs sur Rhapsody développement robuste mais sans tracas? Quelles sont les meilleures pratiques et les leçons que vous aimeriez partager? Je ne suis pas à la recherche d'une description de processus mature; Tidbits je ne savais pas serait génial.

Answer 1

Nous utilisons Rhapsody pour le développement au cours des 5 dernières années. Notre processus actuel implique l'utilisation de l'interface COM Rhapsody et l'interface COM Microsoft Word pour vider les packages de révision dans Word pour les revues de conception. Nous le faisons également pour générer la partie du manuel de référence de notre SUM.

Pour le code, nous passons en revue la source générée.

Nous avons placé le modèle dans notre système de contrôle de version et verrouillé les éléments du modèle après leur révision. Si votre outil de contrôle de version ne lit les éléments que lorsqu'ils sont archivés, il vous empêche de modifier accidentellement un élément de modèle.

L'interface COM est également utile pour le vidage du modèle afin de créer des diapositives PowerPoint de diagrammes si vous souhaitez présenter votre conception à un client. Vous devrez modifier les diapositives après leur création, car les images finissent généralement par être un peu drôles, mais cela donne un point de départ rapide.

Answer 2

Nous utilisons Rhapsody dans le même but sur mon lieu de travail. Les revues des changements de modèles sont faites avec un script qui ouvre diffmerge sur deux copies de notre dépôt (une au début des changements, une au plus tard). Cela montre tous les changements pertinents, sans le crust interne ajoute Rhapsody.

Notre référentiel ne suit pas les sources générées, mais nous voyons fréquemment de nombreux changements non pertinents dans les fichiers sbs de Rhapsody. Nous avons commencé à définir les fichiers sbs en lecture seule sur le système de fichiers, puis à les modifier en lecture/écriture à partir du panneau des propriétés de Rhapsody. Cela n'empêche pas les fichiers que vous marquez en lecture/écriture d'être entrés de manière incorrecte, mais cela empêche la modification de fichiers non liés.

Je n'ai toujours pas trouvé un moyen d'arrêter l'insertion de modifications non pertinentes par Rhapsody (par exemple, il ajoute et supprime parfois des champs de nom de fichier entre les sauvegardes, malgré des modifications minimes apportées au modèle). Cela crée beaucoup de conflits de fusion, et j'ai personnellement commencé à prendre environ 5 minutes par commit pour ajouter seulement les changements qui importent.

Answer 3

Il est également possible d'empêcher Rhapsody d'écrire des horodatages dans les fichiers sbs en définissant la propriété CG::General::IncrementalCodeGenAcrossSession sur false. Cela peut aider à réduire la quantité de données inutiles.

Voir this link