urbanisation-si

urbanisation-si

Les points de vue et les vues TOGAF ou comment montrer que les préoccupations et les exigences des parties prenantes sont prises en compte

TOGAF recommande en phase préliminaire d'identifier les vues architecturales et les points de vue pertinents pour le cycle ADM (Architecture Development Method) afin de satisfaire les préoccupations et les exigences des différentes parties prenantes

 

diagramme-de-classe-uml-concepts-de-base-architecture-entreprise-togaf-01.PNG

 

Les « parties prenantes » (individus, des équipes ou organisations) ont des rôles clés dans le système ou des préoccupations à ce sujet ; par exemple, en tant qu'utilisateurs, développeurs ou gestionnaires.

Les différentes parties prenantes ayant des rôles différents dans le système, ils auront des préoccupations différentes.

 

Les « préoccupations » sont les intérêts clés qui sont d'une importance cruciale pour les parties prenantes du système et déterminent l'acceptabilité du système.

Les préoccupations peuvent concerner tout aspect du fonctionnement, du développement ou de l'exploitation du système, y compris des considérations telles que la performance, la fiabilité, la sécurité, la distribution et l'évolutivité.

 

Définition d’une vue

Une « vue » est une représentation d'un système entier du point de vue d'un ensemble connexe de préoccupations.

 

En capturant ou en représentant la conception d'une architecture de système, l'architecte créera généralement un ou plusieurs modèles d'architecture, en utilisant éventuellement différents outils.

Une vue comprendra des parties sélectionnées d'un ou de plusieurs modèles, choisis de manière à démontrer à un intervenant ou à un groupe de parties prenantes que leurs préoccupations sont prises en compte de manière adéquate dans la conception de l'architecture du système.

 

Définition d’un point de vue

Un "point de vue" définit la perspective à partir de laquelle une vue est prise.

Plus spécifiquement, un point de vue définit : comment construire et utiliser une vue (au moyen d'un schéma ou d'un modèle approprié) ; les informations qui devraient apparaître dans la vue ; les techniques de modélisation pour exprimer et analyser l'information ; et une justification de ces choix (par exemple, en décrivant le but et le public cible de la vue).

 

Une vue est ce que vous voyez.

Un point de vue est l'endroit où vous regardez - le point de vue ou la perspective qui détermine ce que vous voyez.

 

Les points de vue sont génériques et peuvent être stockés dans des bibliothèques pour être réutilisés.

Une vue est toujours spécifique à l'architecture pour laquelle elle est créée.

Chaque vue a un point de vue associé qui la décrit, au moins implicitement.

 

Préoccupations et exigences

Les termes « préoccupation » et « exigence » ne sont pas synonymes.

Une préoccupation est un domaine d'intérêt.

Ainsi, la fiabilité du système pourrait être une préoccupation / un domaine d'intérêt pour certaines parties prenantes.

 

La raison pour laquelle les architectes doivent identifier les préoccupations et les associer aux points de vue, est de s'assurer que ces préoccupations seront traitées d'une manière ou d'une autre par les modèles de l'architecture.

 

Par exemple, si le seul point de vue sélectionné par un architecte est un point de vue structurel, les problèmes de fiabilité ne sont presque certainement pas traités, car ils ne peuvent pas être représentés dans un modèle structurel.

 

Dans ce contexte, les parties prenantes peuvent avoir de nombreuses exigences distinctes : différentes catégories d'utilisateurs peuvent avoir des exigences de fiabilité très différentes pour les différentes capacités du système.

Les préoccupations sont la racine du processus de décomposition en exigences.

Les préoccupations sont représentées dans l'architecture par ces exigences.

Les exigences doivent être SMART (Specific Measurable Achievable Realistic Time-bound).

 

Voir notre article sur la modélisation des exigences,

 

Conclusion

Les vues d'architecture sont donc des représentations de l'architecture globale en termes significatifs pour les parties prenantes.

Ils permettent à l'architecture d'être communiquée et comprise par les parties prenantes, afin qu'ils puissent vérifier que le système répondra à leurs préoccupations.

 

Rhona Maxwel

@rhona_helena

  

"Toutes les choses intelligentes ont déjà été pensées.

Ce qu’il faut à présent, c’est essayer de les repenser."

Johann von Goethe

 

 

Articles conseillés :

 

SysML : tutoriel ( tutorial - didacticiel ) Le diagramme de package (partie 2) 

 

Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)

 

Les fondamentaux de la modélisation d'un Système d'Information : le bon usage des modèles

 

Le Big-Mac de l'urbanisation SI

 

Le référentiel TOGAF sous toutes ses coutures : le « Continuum d'Entreprise » et la réutilisation de l'architecture

 

TOGAF pour les nuls.



09/03/2018
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 179 autres membres