Was ist eine gute Methode zur Bewertung von Lightweight-Architekturen?

Ich bin mit Architekturbewertungsmethoden wie der ATAM ( Technical Architecture Tradeoff Analysis Method) und der CBAM ( Business Oriented Cost Benefit Analysis Method) vertraut . Diese Methoden sind jedoch recht umfangreich: Sie schreiben mehrere Brainstorming-Sitzungen, Präsentationen, die Entwicklung einer Vielzahl von Szenarien vor, in denen Kompromisse beschrieben werden usw. Sie sind zwar für Projekte einer bestimmten Größe nützlich, aber für interne Projekte oder Desktop-Anwendungen, die normalerweise typisch sind, zu groß Entwickelt von einer Handvoll Entwicklern (oder weniger), die, obwohl sie klein sind, einige ziemlich steile Qualitätsbeschränkungen aufweisen (Leistung, Skalierbarkeit, Anpassungsfähigkeit).

Eine typische Praxis, die ich in der Vergangenheit angewendet habe, besteht darin, dass ein Entwickler (oder der Architekt, falls ein Team einen hat) eine allgemeine Architektur für die Anwendung erstellt und diese dann mit dem Rest des Teams auf einem Whiteboard bespricht eine Pseudo-UML-Notation, die leicht zu zeichnen und zu verstehen ist. Dies führt normalerweise zu Rückmeldungen und einigen Iterationen der Architektur. Aber es ist in der Regel etwas zu informell, was dazu führt, dass alle möglichen Annahmen getroffen werden, die sich später als falsche Entscheidungen herausstellen können.

Methoden wie ATAM zwingen normalerweise alle Beteiligten, tief über die Architektur nachzudenken, was zu Diskussionen führt, bis sich zumindest alle darüber einig sind, was die Architektur genau ist .

Hat jemand Erfahrung mit der Bewertung von Architekturen im Vorfeld? Wenn ja, was sind bewährte Verfahren?

Der Schlüssel zur leichten Bewertung liegt darin, die richtigen Dinge zur richtigen Zeit zu bewerten. Ich kenne zwei Möglichkeiten, um dies effektiv zu tun. Bei der szenariobasierten Bewertung verwenden Sie Szenarien mit Qualitätsattributen und Anwendungsfälle, um die Bewertung voranzutreiben, wobei Sie sich nur auf die Qualitätsattribute mit hoher Priorität konzentrieren. Mit der risikobasierten Bewertung identifizieren Sie Risiken und lassen die identifizierten Risiken Ihre Architekturdesignaktivitäten steuern.

Ich kann zwei Bücher empfehlen, die diese beiden (etwas verwandten) Ansätze untersuchen.

Architecting Software Intensive Systems von Anthony Lattanze führt in die Architecture Centric Design Methodology ein und deckt leichte szenarienbasierte Auswertungen ab. Sie können Lattanze aus dem Workshop zu Qualitätsattributen des SEI erkennen, und es gibt ähnliche Ideen.

Nur genug Softwarearchitektur: Ein risikogesteuerter Ansatz von George Fairbanks führt einen risikogesteuerten Ansatz zum Entwerfen und Bewerten der Architektur eines Softwaresystems ein. Es gibt auch einige kostenlose Kapitel auf seiner Website, wenn Sie eine Vorschau wünschen. Obwohl die Prinzipien in diesem Buch sofort anwendbar sind, gibt es für den Ansatz keine spezifische Methode, sodass Sie Ideen aus anderen Bereichen kombinieren müssen. Ich empfehle den kontinuierlichen Risikomanagementansatz des SEI zur Identifizierung / Priorisierung von Risiken.

Die Grundidee hinter diesen Ansätzen besteht darin, dass Sie die Kosten für die Bewertung (und das Design) senken, indem Sie die Bewertung im Laufe der Zeit durchführen, anstatt bis zum Ende zu warten. Dies ist sicherlich etwas schwerer als das Reden über ein Whiteboard, aber es ist bei weitem nicht so teuer wie ein ausgewachsenes ATAM. Und wenn Sie sich wohl fühlen, können Sie Praktiken auswählen, die Ihren spezifischen Anforderungen entsprechen.

Unabhängig davon, welchen Ansatz Sie verwenden, um die Bewertung voranzutreiben, ist die allgemeine Idee dieselbe ...

Bevor du anfängst:

• Qualitätsattributszenarien oder -risiken, priorisiert (kann informell sein, wenn das alles ist, was Sie haben)
• Klare Definition für Go / No-Go-Entscheidung (woher wissen Sie, dass die Architektur "gut genug" ist)
• Letzter Schnitt der Architekturbeschreibung (das Artefakt, das Sie bewerten)

Setzen Sie sich für eine Evaluierungssitzung:

• Der Architekt gibt einen Überblick über die Architektur
• Gehen Sie durch eine Ansicht und zeigen Sie, wie das Szenario oder Risiko erfüllt ist
• Probleme werden aufgezeichnet, um später behoben zu werden
• Die Rollen und das allgemeine Verfahren ähneln denen einer Fagan-Inspektion (Architekt oder Autor, Moderator, Rekorder).
• Die Sitzung kann je nach Größe Ihres Systems nur ein oder zwei Stunden dauern.

Sobald die Sitzung beendet ist:

• Überprüfen Sie identifizierte Probleme und stellen Sie fest, ob die Go / No-Go-Kriterien erfüllt sind. Im Allgemeinen dauert es ungefähr 3 Bewertungen, um alles zu klären. Wenn dies nicht der Fall ist, verfeinern und experimentieren Sie weiter (oder verringern Sie die Architekturrisiken).
• Dies ist keine "Alles oder Nichts" -Bewertung - verschiedene Teile Ihrer Architektur könnten "bestehen", während andere noch verfeinert werden müssen.

Um Ihnen ein Gefühl dafür zu geben, wie der szenarienbasierte Ansatz aussehen könnte, gibt es einige öffentliche Dokumentationen aus einem Schlusssteinprojekt, an dem ich in der Graduiertenschule gearbeitet habe. Die Dokumentation ist etwas grob, könnte jedoch einige Beispiele für den szenariobasierten Ansatz im Kontext von ACDM enthalten. Wir waren ein 5-köpfiges Team und haben eine typische webbasierte Anwendung erstellt, etwa 35 KLOC Java / GWT.

Ich mag zunächst informelle Whiteboard-Diskussionen. Ich schreibe gerne nur den Teil der Anwendung, der heute benötigt wird, und lasse dann die Architektur während der Implementierung schrittweise entstehen. Es ist eher so, als würde man die Architektur finden, als vorher zu versuchen, sie zu erfinden. Dieser Ansatz erfordert nicht viel Vorabbewertung und hilft Ihnen, sich auf das Wesentliche zu konzentrieren (funktionierende Software bereitzustellen).

Wenn Ihre nicht funktionalen Anforderungen dies erfordern (Speicherbeschränkungen, Antwortzeiten, Anzahl gleichzeitiger Benutzer usw.), müssen Sie dies natürlich bei der Implementierung des Systems berücksichtigen.