Principes et conseils :
|
Partie de l'enchaînement d'activités |
Commentaires |
---|---|
Conception de l'interface utilisateur | Certains projets décident de ne pas concevoir l'interface utilisateur. Une raison à cela peut être que l'interface utilisateur est facile à développer. Si vous décidez de ne pas procéder à la conception de l'interface utilisateur, cela signifie que vous ne développez pas de carte de navigation et de prototype d'interface utilisateur. |
Conception de la base de données | Uniquement utilisée si les entités vont être stockées dans des bases de données. Si vous décidez de ne pas concevoir de bases de données, cela signifier que vous ne développez pas de modèle de base de données. |
Documenter les décisions dans le cadre du processus spécifique au projet.
Prenez une décision sur les artefacts à utiliser et comment les utiliser. Le tableau ci-dessous décrit les artefacts obligatoires et ceux utilisés uniquement dans certains cas. Pour des informations plus détaillées sur comment personnaliser chaque artefact, et une discussion des avantages et inconvénients de l'artefact en question, lisez la section intitulée "Personnalisation" de chaque artefact.
Pour chaque artefact, décidez comment il doit être utilisé : Doit, Devrait, Pourrait ou Ne fera pas.
Artefact | Objet |
Personnalisation (Facultative, Recommandée) |
---|---|---|
Modèle d'analyse (Classe d'analyse) | Un modèle d'analyse est utile pour mieux comprendre les exigences avant de prendre de décisions sur la conception. Sur ces systèmes complexes, il peut être entretenu pour fournir une vision conceptuelle du système. |
Facultative Dans de nombreux projets, un modèle de conception initial est utilisé à la place du modèle d'analyse. Dans les projets qui créent un modèle d'analyse, il s'agit généralement d'un artefact temporaire qui évolue en modèle de conception. |
Les projets avec une interface utilisateur étendue et complexe doivent envisager la conception de celle-ci. |
Facultative Une conception plus informelle de l'interface utilisateur peut être suffisante dans des efforts de développement plus petits. |
|
Modèle de conception |
La plupart des systèmes, même les plus petits, doivent être conçus avant d'être implémentés afin d'éviter un remaniement coûteux dû à des erreurs de conception. Des modèles visuels permettent de diffuser facilement la conception. Des outils pour de génération de code et de rétro-conception peuvent assurer une cohérence avec le modèle d'implémentation et économiser des efforts. |
Recommandée pour la plupart des projets. Dans les plus petits projets, l'utilisation d'outils automatisés n'est pas essentielle, mais présente des avantages à long terme sur la productivité. |
|
Les classes et packages constituent un élément de base dans toute conception orientée objet. La conception orientée objet est l'approche de conception standard utilisée dans la plupart des projets. |
Recommandée pour la plupart des projets. Les principaux problèmes de personnalisation concernent la décision des stéréotypes à utiliser (cela peut être capturé dans les principes de conception). |
|
Etablir un pont entre cas d'utilisation et conception. |
Recommandée pour la plupart des projets. |
|
Les interfaces servent généralement à définir le comportement indépendamment de gros composants qui réalisent le comportement. |
Recommandée pour la plupart des projets. La conception orientée composant devient une approche de conception standard. |
|
Les sous-systèmes de conception servent à encapsuler le comportement dans un composant qui fournit les interfaces. Il sert à encapsuler les interactions de classes et/ou d'autres sous-systèmes. |
Recommandée pour la plupart des projets. Les sous-systèmes sont souvent utiles pour élever le niveau d'abstraction de la conception. Ils facilitent la compréhension des systèmes. |
|
Peut être utile pour les systèmes qui réagissent à de nombreux événements externes. | |
|
Peut être utile pour les systèmes qui requièrent une simultanéité et qui sont commandés par des événements. |
Recommandée pour les systèmes en temps réel. Peut être utile pour les systèmes qui requièrent une simultanéité et qui sont commandés par des événements. |
Modèle de données | Utilisé pour décrire la structure logique et éventuellement physique de l'information persistante. |
Recommandée pour les projets utilisant une base de données. |
Modèle de déploiement | Montre la configuration des noeuds de traitement au moment de l'exécution, les liens de communication entre eux, et les instances de composants et objets qui résident dessus. |
Facultative. De nombreux systèmes ont plusieurs noeuds de traitement et doivent par conséquent traiter le modèle de déploiement. Cependant, il peut être capturé comme une section du document sur l'architecture logicielle et n'a pas besoin d'exister en tant qu'artefact identifié séparément. |
Bien fondé architectural | Utilisé pour déterminer s'il existe une solution qui satisfait les exigences importantes pour l'architecture. | Recommandée pour la plupart des projets.
De nombreux projets utiliseront le bien-fondé architectural pour déterminer la faisabilité des exigences. Il peut prendre de nombreuses formes, par exemple:
|
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 des solutions éprouvées. |
Recommandée pour la plupart des projets. Si une Architecture de référence appropriée existe, elle peut considérablement accélérer le développement et réduire les risques. |
Document sur l'architecture logicielle (SAD) | Le Document sur l'architecture logicielle sert à fournir une vue complète sur l'architecture du système. Cette présentation générale aide à comprendre le système, et à capturer les décisions clés en matière d'architecture. |
Recommandée pour la plupart des projets. Une présentation détaillée de l'architecture logicielle est utile pour tous les systèmes sauf les plus petits. Les systèmes complexes requièrent généralement un plus grand niveau de détail et plus de vues que les projets les plus petits. |
Prototype d'interface utilisateur | Utilisé pour exposer et testez les fonctionnalités et la facilité d'utilisation avant que le véritable développement ne commence. Il s'agit d'un moyen efficace de valider la conception avant de gaspiller trop de temps. |
Recommandée pour la plupart des projets. |
Personnaliser chaque artefact selon les besoins du projet. La personnalisation est traitée dans la section personnalisation de la page de description des artefacts
La décision des rapports à utiliser dépendra des outils d'établissement de rapports disponibles pour le projet. Si ces outils sont disponibles, nous recommandons la génération de rapports pour les artefacts orientés modèles, comme les classes de conception, les réalisations de cas d'utilisation. Les rapports existants dans votre configuration RUP sont disponibles à partir des pages de description des artefacts ou groupés sous l'artefact en question dans la fonction de visualisation d'arbre d'objets fenêtre.
Décider du niveau de révision de chaque artefact Décider comment réviser et approuver les résultats d'Analyse et Conception, et dans quelles mesures les résultats seront révisés.
Les avantages d'une révision de conception sont les suivants :
Les inconvénients d'une révision de conception sont les suivants :
Les facteurs qui peuvent être altérés sont les techniques de révision, les ressources, et la portée. Voici quelques exemples de ce sur quoi vous pouvez prendre des décisions dans votre projet :
Pour plus d'informations sur la révision et les différentes sortes de révisions, voir Recommandations de travail : Révisions.
La façon dont vous concevez varie en fonction de si vous générez ou pas un code à partir du modèle de conception. Si vous générez un code, la conception doit être très détaillée. Autrement, si vous ne générez pas de code à partir de la conception, il n'y a pas besoin que la conception soit très détaillée. Au contraire, les détails de la conception doivent être synchronisés manuellement avec le code.
RUP (Rational Unified Process)
|