Donc, vous faites basiquement l'architecture de la solution. À ma connaissance, il n'y a pas de méthodologies - du moins aucune qui soit succinctement décrite en quatre pages ou moins (ce qui m'intéresse).
Pour répondre à votre question:
1 - Comprendre les contraintes
L'évidence est la compréhension du problème que vous essayez de résoudre et le contexte.
Vous pouvez avoir une main libre ou vous pourriez être contraint par les normes existantes - où je travaille (dans un gouvernement) nous avons beaucoup de différentes technologies et systèmes, et il y a une hiérarchie quand nous regardons quelque chose d'autre; la technologie que nous préférons et la technologie que nous essayons de développer.
Zachman est un cadre d'architecture d'entreprise; vous pourriez trouver cela intéressant, mais je doute qu'il aura beaucoup de pertinence au niveau de la solution, en particulier. TOGAF en est un autre.
2 - Vues
La seule chose sur TOGAF (et Zachman) est qu'il a le concept de "vues" différentes, par exemple:
- vue de la sécurité
- vue des données
- vue technologique
- vue de l'application
- proc vue ess
- vue soutien
- vue opérationnel
- vue de facturation
- vue de l'utilisateur
performances
- , etc ...
droit à l'avant vous voulez penser soigneusement à quelles vues sont pertinent pour le système que vous planifiez/architectes. Au fur et à mesure que le projet/système se développe, vous devez garder cela à l'esprit; ils aideront à guider les décisions majeures. J'aime aussi cette façon de penser parce qu'elle fonctionne dans le sens de «diviser une conquête» - briser un grand puzzel en plus petits.
3 - Modélisation
Je n'ai pas entendu parler d'utiliser des boules de styromousse avant, mais l'idée de la modélisation des relations d'une manière tactile semble très attrayant - mais si c'est un grand système que vous pourriez avoir besoin d'un très grand chambre :)
Les tableaux blancs sont ma façon préférée d'explorer la relation entre les classes (et tout, vraiment). Je vous conseille vivement d'avoir un appareil photo numérique avec vous, ou un téléphone avec une caméra intégrée; J'utilise ce dernier, je prends des photos du tableau blanc au besoin et ensuite les synchroniser avec mon ordinateur après la réunion et j'envoie des copies aux participants. Il est très facile de capturer l'information et vous donne l'air très professionnel. UML est très utile, mais vous devrez peut-être choisir les bits que vous utiliserez en fonction de votre public - cela dépend de la manière dont vous voulez regarder les choses.
Formellement les systèmes de modélisation dans un outil de modélisation (et en utilisant formel UML, par opposition à simplement diagramming, par exemple Visio) est également très utile. Si vous n'êtes pas familier avec cette façon, vous y trouverez un seuil de douleur que vous devez passer, mais il est généralement la peine quand:
- le système est au-dessus d'une certaine taille/complexité, ou
- vous avez beaucoup de petits systèmes avec lesquels travailler.
4 - Méthodologie du projet
Je suis un grand fan de agile/SCRUM. Je cherche des façons d'appliquer des principes agiles à l'architecture sln - mais je n'ai encore rien.
J'ai assisté à une bonne session à Tech-Ed l'année dernière (ARC202 Défier le rôle de l'architecte avec Kevin Francis) - J'ai une écriture here.
Ce fut une excellente séance - c'est la première fois que je l'ai jamais vu quelqu'un expliquer comment une (solution?) Architecte devrait engager dans un projet - quelle que soit la méthode. Kevins un avocat Agile - et son discours axé sur cela, ce qui en fait deux fois comme bon: comment adapter l'architecture et Agile.