Instructions: Décisions importantes en termes d'analyse et de conception
Ces instructions décrivent les éléments importants à prendre en compte lors de la personnalisation des aspects d'analyse et de conception du processus.
Relations
Description principale

Détermination de l'utilisation des produits

Décidez quels produits  utiliser et comment les utiliser.  En plus d'identifier les produits à utiliser, il est également important de personnaliser chaque produit à utiliser afin qu'il soit adapté aux besoins du projet. 

Le tableau ci-dessous précise les produits d'analyse et & de conception qui sont recommandés et ceux qui sont considérés comme facultatifs (qui peuvent être utilisés uniquement dans certains cas). Pour des questions relatives à la personnalisation, voir la section s'y rapportant dans la page de description du produit.

Produit Objet

Personnalisation (facultatif, recommandé)

Modèle d'analyse (Classe d'analyse) Un modèle d'analyse est utile pour mieux comprendre les requêtes avant de prendre des décisions relatives à la conception. Dans les systèmes complexes, il peut être maintenu pour fournir une vue d'ensemble conceptuelle du système.

Facultatif.

Dans beaucoup de projets, un modèle de conception initial est utilisé à la place du modèle d'analyse.

Dans les projets qui créent effectivement un modèle d'analyse, il s'agit généralement d'un artefact temporaire qui va évoluer en modèle de conception.

Carte de navigation, Prototype d'interface utilisateur

Les projets ayant une interface utilisateur large et complexe devraient considérer l'utilisation d'une conception d'interface utilisateur.

Facultatif.

Une conception d'interface utilisateur plus informelle peut suffire aux efforts fournis sur des projets plus petits.

Modèle de conception

La plupart des systèmes, y compris les petits systèmes, devraient être conçus avant d'être implémentés afin d'éviter de devoir retravailler dessus à cause d'erreurs de conception car cela est coûteux. Les modèles visuels permettent de communiquer la conception facilement. Les outils utilisés pour la rétro-conception et la génération de code peuvent assurer une cohérence avec le modèle d'implémentation et éviter trop d'efforts.

Recommandé pour la plupart des projets.

Sur les projets plus petits, l'utilisation d'outils automatisés n'est pas critique, elle peut avoir une productivité à long terme.

Classe de conception ; Package de conception

Les classes et les packages représentent une partie élémentaire de toute conception orientée objet. La conception orientée objet est l'approche de conception standard utilisée pour la plupart des projets.

Recommandé pour la plupart des projets.

Les principales questions relatives à la personnalisation concernent les stéréotypes utiliser (vous pouvez trouver cela dans les Instructions relatives à la conception).

Réalisation de cas d'utilisation

Fournit un pont à partir des cas d'utilisation vers la conception.

Recommandé pour la plupart des projets.

Interface

Les interfaces sont généralement utilisées pour définir le comportement indépendamment des composants à forte granularité qui effectuent ce comportement.

Recommandé pour la plupart des projets.

La conception basée sur les composants devient une approche de conception standard.

Sous-système de conception

Les sous-systèmes de conception sont utilisés pour encapsuler le comportement à l'intérieur d'un composant qui fournit les interfaces. Ils sont utilisés pour encapsuler les interactions de classes et/ou d'autres sous-systèmes.

Recommandé pour la plupart des projets.

Les sous-systèmes sont souvent très utiles pour élever le niveau d'abstraction de la conception. Ils facilitent la compréhension des systèmes.

Evénement

Peut être utile pour les systèmes qui répondent à beaucoup d'événements externes. Recommandé pour les systèmes en temps réel.

Protocole

Requis pour les systèmes en temps réel. Recommandé pour les systèmes en temps réel.

Signal

Peut être utile pour les systèmes qui requièrent un accès concurrent et sont déclenchés par un événement.

Requis pour les systèmes en temps réel.

Peut être utile pour les systèmes qui requièrent un accès concurrent et sont déclenchés par un événement.

Recommandé pour les systèmes en temps réel.

Capsule

Utilisé pour les systèmes en temps réel mais peut s'avérer utile pour la modélisation et la conception de tout système ayant un degré d'accès concurrent très élevé.

Recommandé pour les systèmes en temps réel.

Modèle de données Utilisé pour décrire la structure logique et éventuellement physique de l'information persistante.

Recommandé pour les projets utilisant une base de données.

Modèle de déploiement Montre la configuration des noeuds de traitement en cours d'exécution, les liens de communication entre eux et les instances de composants et les objets qu'ils contiennent.

Facultatif.

Beaucoup de systèmes ont de multiples noeuds de traitement et doivent donc traiter le modèle de déploiement. Vous pouvez cependant trouver une section s'y rapportant dans le document d'architecture logicielle. Il n'a pas besoin d'exister en tant qu'artefact identifié séparément.

Bien-fondé de la conception d'architecture Utilisé pour déterminer s'il existe une solution qui satisfasse les requêtes importantes du point du vue de l'architecture. Recommandé pour la plupart des projets.

Beaucoup de projets vont utiliser un bien-fondé de la conception d'architecture pour déterminer la faisabilité des requêtes. Cela peut se faire sous différentes formes :

  • une liste des technologies connues qui semblent appropriées à la solution
  • un schéma d'un modèle conceptuel d'une solution
  • une simulation de solution
  • un prototype exécutable
Architecture de référence Les architectures de référence accélèrent le développement et réduisent les risques en réutilisant les solutions qui ont fait leurs preuves.

Recommandé pour la plupart des projets.

Si du matériel approprié d'architecture de référence existe, cela peut considérablement accélérer le développement et réduire les risques.

Document d'architecture logicielle (SAD) Le document d'architecture logicielle fournit une présentation complète de l'architecture du système. Cette présentation aide à comprendre le système et à répertorier les décisions clés relatives à l'architecture.

Recommandé pour la plupart des projets.

Une présentation de niveau élevé de l'architecture logicielle sert pour tous les systèmes sauf les plus petits. Les systèmes complexes requièrent généralement un niveau de détail plus élevé et davantage de vues que les projets plus petits.

Prototype d'interface utilisateur Utilisé pour exposer et tester la fonctionnalité et la convivialité avant que le développement réel ne démarre. C'est un moyen très efficace de valider la conception avant que trop de temps ne soit perdu.

Recommandé pour la plupart des projets.



Quels rapports utiliser

La décision à prendre sur les rapports à utiliser va dépendre des outils de rapports disponibles pour le projet. Si des outils de génération de rapports sont disponibles, nous préconisons de générer des rapports pour les produits orientés modèle comme les classes de conception et les réalisations de cas d'utilisation. Des rapports existants dans la configuration de votre processus RUP sont disponibles dans les pages descriptives du produit ou regroupés sous le produit en question dans le navigateur d'arborescence.

Comment réviser

Décidez du niveau de revue à utiliser pour chaque produit à utiliser.  Décidez en particulier de la manière de réviser et d'approuver les résultats d'analyse et & de conception, et jusqu'où les résultats seront révisés.  

Les avantages d'une revue lors de l'analyse et & de la conception :

  • Elle détecte les problèmes impossibles, ou très difficiles à repérer lors des tests. comme par exemple les questions de style et d'agencement. 
  • C'est un moyen d'appliquer un style de modélisation commun et une opportunité pour les individus d'apprendre les uns des autres. 
  • Elle détecte des incidents qui ne seraient repérés que plus tard dans le projet lors des tests.

Les inconvénients d'une revue lors de l'analyse et & de la conception :

  • Cela prend du temps et demande des ressources. 
  • Elle est facilement mal utilisée si elle n'est pas bien gérée.

Les facteurs qui peuvent être modifiés pour la revue de l'analyse et & de la conception sont les techniques, les ressources et la portée de la revue. Les exemples suivants montrent ce que vous pouvez décider de faire sur votre projet.

  • Décider que les changements locaux d'un sous-système sont révisés par un pair uniquement, qui conduit l'inspection et rend les résultats sur papier.
  • Décider quelles parties de la conception ne seront pas du tout révisées ; par exemple, décider de réviser seulement certaines classes pour chaque membre du projet et espérer que cela assure que la qualité du style est identique au reste des résultats.
  • Décider que le document d'architecture logicielle sera révisé par un client lors d'une autre réunion.
  • Décider de recourir à des réunions de revue formelles pour tout changement d'une interface importante, c'est-à-dire une interface qui affecte le travail de plusieurs membres du projet.

Pour en savoir plus sur les niveaux de revue, voir Instructions : niveaux de revue

Générer ou ne pas générer de code

Votre façon d'effectuer la conception est différente selon que vous générez du code à partir du modèle de conception ou non. Si vous générez du code, la conception doit être très détaillée. Par contre, si vous ne générez pas de code à partir de la conception, celle-ci n'a pas besoin d'être très détaillée. Au contraire, il faut synchroniser les détails dans la conception avec le code manuellement.