Le bien-fondé de la conception architecturale désigne une solution, qui peut encore être simplement conceptuelle, pour les exigences significatives sur le plan de l'architecture qui ont été identifiées au début de la phase de création. 
Rôle :  Architecte logiciel 
Caractère facultatif/Occurrence:  Le bien-fondé de la conception architecturale peut être omis lorsque le domaine du problème est bien compris, les exigences bien définies, le système a des précédents et son développement est estimé à faibles risques. 
Canevas et rapports : 
     
Exemples : 
     
Représentation UML :  Sans objet.
Informations supplémentaires :   
Entrée d'activités :    Sortie d'activités :   

Objet Haut de la page

L'objet du bien-fondé de la conception architecturale est de déterminer s'il existe une solution satisfaisant aux exigences significatives sur le plan de l'architecture, ou si cette solution est susceptible d'exister. 

Représentation Haut de la page

Le bien-fondé de la conception architecturale peut revêtir plusieurs formes, par exemple : 

  • une liste des technologies connues (structures, patterns, architectures exécutables) qui semblent adéquates pour une solution
  • une esquisse d'un modèle conceptuel de solution utilisant une notation telle que UML
  • une simulation de solution
  • un prototype exécutable

Calendrier Haut de la page

Le bien-fondé de la conception architecturale est (facultativement) développé lors de la phase de création afin de déterminer la faisabilité du projet, évaluer les risques techniques associés à son développement, et formuler et affiner les exigences significatives sur le plan de l'architecture.

Responsabilité Haut de la page

L'architecte logiciel est responsable du bien-fondé de la conception architecturale. 

Personnalisation Haut de la page

La décision de la nécessité ou non d'un bien-fondé de la conception architecturale et de sa forme repose sur les considérations suivantes :

  • Compréhension du domaine concerné : si le domaine n'est pas familier, cet artefact peut non seulement explorer les solutions possibles mais aussi aider le client et les organismes de développement à comprendre et à clarifier les exigences.
  • Nouveauté du système : si l'organisme de développement a déjà construit beaucoup de systèmes de ce genre, la construction de cet artefact ne devrait pas être nécessaire. Il devrait être possible de fonder sa faisabilité sur les architectures et les technologies de référence existantes.
  • Présence d'exigences considérées comme particulièrement coûteuses, même si le domaine est familier et que le système a des précédents, par exemple : exigence de débits de transaction hyperélevés ou de fiabilité extrême.

Plus les risques sont élevés et plus les efforts à investir lors de la phase de création dans cette activité de synthèse de l'architecture (avec des attentes de résultats plus réalistes à partir des modèles produits et évalués), seront élevés afin de pouvoir convaincre toutes les parties prenantes de la justification de son budget et de la poursuite vers la phase d'élaboration. Toutefois, il est de règle que tous les risques ne puissent pas être éliminés dans cette phase. La phase de création ne doit pas être déformée pour représenter une phase d'élaboration de facto.



RUP (Rational Unified Process)   2003.06.15