Ist meine Architektur gut genug?

Softwarearchitektur bewerten – aber wie?

Stefan Toth, Gernot Starke, Phillip Ghadir
Softwarearchitektur bewerten

© shutterstock.com/Kwiatek7

Bei einer Architekturbewertung geht es darum herauszufinden, ob Ihre Architektur für Ihren Kontext gut genug ist. Rahmenbedingungen und Anforderungen sind der Schlüssel für jede Bewertungstätigkeit. Von ihnen ausgehend eröffnet sich eine Menge an Möglichkeiten zur Bewertung von zentralen Entwurfsentscheidungen, gewählten Datenstrukturen oder Technologien, eingehaltenen Prinzipien oder extern zur Verfügung gestellten Schnittstellen.

„Mein Haus, mein Auto, mein Urlaub“: Menschen vergleichen gerne. In elitären Kreisen wird das Hab und Gut verglichen. Der Vergleich mit den extravaganten Urlaubszielen (oder Fernsehern) der Nachbarn ist weit verbreitet, und wenn Sie einen Job haben, vergleichen Sie vielleicht Ihre Leistungen und Ihren Verdienst mit dem Ihrer Kollegen. Auch im Bereich der Softwareentwicklung finden wir genügend Möglichkeiten für Vergleiche. Sie können jede publizierte oder informell vorgestellte Lösung auf Ihr Projekt projizieren und werden sicherlich auf Unterschiede stoßen. Kein System gleicht dem anderen. Onlineshops, Systeme zur Massendatenverarbeitung und Flugsicherungssoftware werden sich sogar in vielen bis allen grundlegenden technischen (architektonischen) Fragestellungen unterscheiden. Trotz dieser Unterschiede kann die gewählte Architektur in allen drei Fällen ideal sein.

Eventtipp

foundation-level-logoadvanced-level-logo

Die Software Architecture Camps der Entwickler Akademie bieten iSAQB-zertifizierte Softwarearchitektur-Trainings – unter anderem mit Phillip Ghadir, Dr. Gernot Starke und Stefan Toth. Alle Details auf www.software-architecture-camp.de.

Bei der Bewertung einer Softwarearchitektur geht es darum herauszufinden, ob Ihre Architektur für Ihren Kontext gut genug ist. Rahmenbedingungen und Anforderungen sind der Schlüssel für jede Bewertungstätigkeit. Von ihnen ausgehend eröffnet sich eine Menge an Möglichkeiten zur Bewertung von zentralen Entwurfsentscheidungen, gewählten Datenstrukturen oder Technologien, eingehaltenen Prinzipien oder extern zur Verfügung gestellten Schnittstellen.

Wir geben Ihnen in den folgenden Abschnitten einige Hinweise, wie Sie Ihre Softwarearchitektur und Implementierung Ihres Systems in diesem Sinne einschätzen können.

Bewertungsmethoden und -techniken

Architekturbewertung

Abb. 1: Bewertungstechniken einsortiert

Das Feld „Architekturbewertung“ wird unterschiedlich abgegrenzt. Grundsätzlich geht es aber immer darum herauszufinden, ob die konzeptionelle und technologische Basis einer Softwarelösung trägt. Dafür bieten sich Ihnen mehrere Techniken und Methoden, die sich in ihrem Fokus, ihrer Aussagekraft und ihrem Einsatzspektrum unterscheiden. Abbildung 1 zeigt einen Überblick.

Zunächst wären klassische Architekturbewertungsmethoden (wie z. B. ATAM) und Kontextanalysen zu nennen (1). Sie betrachten getroffene Entscheidungen und Lösungsvorschläge vor dem Hintergrund qualitativer Anforderungen und Rahmenbedingungen, basieren auf der Einschätzung und Erfahrung der Bewerter und können bereits in frühen Phasen der Entwicklung eingesetzt werden.

Ähnliches gilt für Prüfungen von Entwicklungsansätzen und -prozessen, angenommener Best Practices und Prinzipien (2). In diesem Bereich gibt es jedoch keine allgemein anerkannten Methoden oder Techniken. Die Bewertung beschränkt sich auf individuelle Einschätzungen.

Die Umsetzungsanalyse (3) prüft, ob Softwarearchitektur-Ansätze im Code auch eingehalten werden, bzw. zeigt, welche Architekturansätze der Code enthält. Die meist werkzeuggestützte Umsetzungsanalyse fokussiert dabei auf Strukturierungs- und Abhängigkeitsfragen und kann erst mit einer aussagekräftig umfangreichen Codebasis eingesetzt werden.

Die statische Codeanalyse (4) bedient sich ebenfalls Werkzeugen, um Metriken zu erheben – objektive Anhaltspunkte, die meist Rückschlüsse auf die Wartbarkeit und Erweiterbarkeit von Code gewährleisten. Datenanalysen gehören ebenfalls zu dieser Gruppe von Prüfungen, auch wenn es hierfür weniger Werkzeugunterstützung gibt.

Ressourcenverbrauch, Antwortzeiten oder Lastverhalten untersuchen wir mit dynamischer Analyse (5), die das Verhalten des Systems zur Laufzeit betrachtet. Auch hierbei handelt es sich um werkzeugunterstützte Arbeit, deren Ergebnisse Rückschlüsse auf Architekturkonzepte und Best Practices erlauben.

Architekturbewertungsmethoden (1)

Die klassische Architekturbewertung (etwa nach ATAM – der Architecture Tradeoff Analysis Method) betrachtet getroffene Entscheidungen und Lösungsvorschläge vor dem Hintergrund qualitativer Anforderungen. Sie nutzt die kollektive Erfahrung des Entwicklungsteams, um Risiken früh zu identifizieren, und macht Architekturkompromisse für Stakeholder verständlich. Zentral ist dabei das Konzept von Qualitätsszenarien, das zur genauen Beschreibung von Qualitätsanforderungen und als Bewertungsmaßstab dient (Abb. 2).

Architekturbewertung

Abb. 2: Qualitätsszenarien – Aufbau und generisches Beispiel [1]

Szenarien sind Beispiele für Qualitätsanforderungen und bilden damit eine Basis, auf der sich Entwicklungs- und Kundenseite unterhalten können. Kompromisse zu einschränkenden Rahmenbedingungen können offensichtlich gemacht werden, und ganz nebenbei erhalten Entwickler sowohl brauchbarere Anforderungen als „Performanz ist wichtig“ als auch deren Priorisierung.

Bereits leichtgewichtige Ausprägungen von fundierten Architekturbewertungsverfahren zeigen sehr positive Effekte. Die grundsätzlichen Fragen lauten:

·       Was wollten wir in den vergangenen Iterationen umsetzen?

·       Welche zentralen Entscheidungen wurden deshalb getroffen?

·       Wie wurde das Bild der Gesamtarchitektur verändert?

Architekturbewertung

Abb. 3: Architekturbewertungsworkshops (Reflexion) im Überblick [1]

Abbildung 3 illustriert die Idee etwas detaillierter. Hier wird ein Ablauf eines typischen Bewertungsworkshops gezeigt: Zuerst erfolgt das Zusammenstellen der Inputs-Artefakte und Ideen aus der Architekturarbeit (links) und Anforderungen bzw. Einflüsse (rechts). Im Anschluss daran werden die Inputs inhaltlich bewertet und in Verbindung gebracht. Diese Diskussion generiert eine Reihe von Outputs. Als Teilnehmer kommen Entwickler, die Architekturarbeit geleistet haben, teamfremde Entwickler, Architektur- und Betriebsexperten sowie andere wichtige Stakeholder, wie Kunden, in Frage. Der Teilnehmerkreis kann und sollte in größeren Projekten immer wieder durchmischt werden.

Im Workshop wird zunächst ein kurzer Blick auf die Architektur als Ganzes geworfen, bevor der Blick auf die Anforderungsseite und dort vor allem zu Szenarien schwenkt. Beginnend mit dem höchstpriorisierten Szenario startet eine Durchsprache, in der die Architekturansätze und Entscheidungen vorgestellt und reflektiert werden, die von dem Szenario berührt werden. Die folgende Tabelle zeigt einige Beispielfragen.

Architekturbewertung

Tabelle 1: Beispielfragen in Bewertungsworkshops

Die Reflexion zur geleisteten Arbeit und den eventuellen Seiteneffekten ist der Kern dieser Praktik. Hier werden wichtige Outputs des Workshops generiert: Risiken, die bei den Entscheidungen entdeckt wurden, Kompromisse zwischen Szenarien, Schwachstellen in der Architektur, Nichtrisiken (aufgebrachte, aber entkräftete Risiken) und To-dos. Zentrale Ziele sind die Fokussierung von Kommunikation und Architekturarbeit auf die wirklich wichtigen Aspekte des Vorhabens, die Absicherung zentraler Entscheidungen und die Transparenz von Architekturarbeit bis hin zu den fachlichen Stakeholdern des Projekts.

Prüfung des Entwicklungsansatzes (2)

Die Vorgehens- oder Herangehensweise bei der Umsetzung von Anforderungen lässt sich kaum formal prüfen – dennoch können wir die Eignung eines gewählten Vorgehens oder der etablierten (Architektur-)praktiken für den jeweiligen Problemkontext bewerten: Die im verwendeten Ökosystem gängigen Best Practices oder Muster können wir auf ihre Eignung für die aktuelle Aufgabenstellung bewerten bzw. gezielt auswählen. Ziel sind Entwicklungsansätze, die dabei unterstützen, wichtige Qualitätsanforderungen zu erreichen und architekturrelevante Rahmenbedingungen einzuhalten. Auf Basis der vereinbarten Prinzipien, Konstruktionsregeln oder anderer Vorgaben lassen sich etwa Irrwege vermeiden, Missverständnisse aufdecken und manche Arten von Fehlern – wie zum Beispiel Resource Leaks oder blockierende Kommunikation – vermeiden.

Sowohl in der agilen Entwicklung als auch in vielen Projekten zur Entwicklung von Softwaregewerken gehört das Vereinbaren von Richtlinien für die Umsetzung oftmals zu den abnahmerelevanten Details. Für ausgewählte Metriken werden dabei manchmal Zielgrößen vereinbart, sofern sie nicht durch Konstruktionsregeln automatisch vorgegeben werden können.

Eine Prüfung des Entwicklungsansatzes hilft dabei, die Balance zwischen konkurrierenden Kräften herzustellen und frühzeitig zu erkennen, ob die Vorgaben, Richtlinien, Konstruktionsregeln und Prinzipien zu einer Verfälschung der Zielsetzung führen.

Umsetzungsanalyse (3)

Um Abweichungen zwischen architektonischen Vorgaben und deren Umsetzung im Sourcecode zu finden, können Sie entweder manuelle Analysen vornehmen oder Regeln und Strukturen automatisiert prüfen lassen. Da Sie Abweichungen möglichst schnell erkennen sollten und auch eine gewisse Sicherheit brauchen, sollten Sie automatisierte Prüfungen bevorzugen. Viele Metrikwerkzeuge bieten entsprechende Funktionen und Erweiterungen an (Sonargraph oder Structure101 sind bekannte Vertreter).

Grundlage für automatisierte Umsetzungsprüfungen sind Regeln, die Sie in Werkzeugen hinterlegen können. Diese Regeln werden gegen ein Modell gehalten, das sich die Tools aus dem Sourcecode konstruiert – über Parser- und Analyseschritte. Abbildung 4 zeigt einen schematischen Überblick.

Architekturbewertung

Abb. 4: Umsetzungsprüfung im Überblick

Die grau markierten Teile von Abbildung 4 zeigen die für die Umsetzungsprüfung wichtigsten Elemente. Sie können entweder direkt Regeln hinterlegen oder Diagramme nutzen, um (meistens Struktur-)Regeln aufzustellen. Nach dem Parsen des Sourcecodes überprüfen Werkzeuge unter anderem die hinterlegten Regeln und generieren entsprechende Reports.

Mit dem Fokus auf Strukturregeln und Metriken lassen sich in der Umsetzungsanalyse vor allem Wartbarkeitsaspekte gut abdecken. Darüber hinaus ermöglicht die regelmäßige oder kontinuierliche Verwendung dieser Prüfungen, Sourcecode und Architektur in wichtigen Aspekten synchron zu halten. Laufen Code und Architekturideen hingegen stark auseinander, sind auch Prüfungen auf Architekturebene (siehe Abschnitt „Architekturbewertungsmethoden“) problematisch.

Statische Codeanalyse (4)

Bei der statischen Codeanalyse kommen Qualitätsindikatoren und Metriken zum Einsatz. Sie dienen der objektiven Prüfung von Qualitätseigenschaften, die meist nur schlecht direkt gemessen werden können. Dazu zählen beispielsweise die Änderbarkeit Ihrer Software und, damit zusammenhängend, Themen wie Erweiterbarkeit, Wiederverwendbarkeit, Prüfbarkeit (Testbarkeit) oder Verständlichkeit. All diese Eigenschaften sind zur Entwicklungszeit spürbar und haben Auswirkungen auf die Produktivität bei der (Weiter-)Entwicklung von Software. In weiterer Folge sind auch die Time to Market einzelner Features und die Lebensdauer des Systems betroffen.

Für den richtigen Umgang mit Metriken gibt es seit den 1980er-Jahren Modelle und Prozesse [2], [3]. Die pragmatische Essenz daraus lässt sich in drei Schritten beschreiben:

 1.     Definieren Sie die Ziele, die Sie im Bereich der inneren Qualität haben.

2.     Wählen Sie passende Indikatoren für diese Ziele aus.

3.     Legen Sie die Aus- und Verwertung der Ergebnisse fest.

Diese drei Aufgaben sind durchaus architekturrelevant, da Ziele in puncto Änderbarkeit meist ganze Systemteile oder das Gesamtsystem betreffen und die entsprechenden Indikatoren allen Entwicklern bekannt sein sollten – die Auswertung muss transparent und stabil erfolgen (wobei eine gewisse „Kontrollgruppe“ von nicht veröffentlichten Indikatoren verwendet werden kann, um die Wirksamkeit der gewählten Indikatoren zu prüfen). Sie schaffen mit Qualitätsindikatoren einen Rahmen für Design- und Entwicklungstätigkeiten, der die Wichtigkeit innerer Qualität in Ihrem System widerspiegelt und eine gemeinsame Richtung gibt.

In vielen Projekten wird auf die ersten beiden der obigen Schritte (Ziele definieren und Indikatoren auswählen) verzichtet. Es werden Standardmetriken aus Werkzeugen übernommen und orange und rote Werte bestraft. Das ist aus mehreren Gründen problematisch:

·       Die Verwendung von zu vielen Metriken macht die Auswertung schwieriger und die Ergebnisse schwerer nachvollziehbar.

·       Ohne Auswahl konkreter Metriken bleibt der Blick oft bei zusammenfassenden „Metametriken“ hängen. Die sind häufig so kompliziert zusammengesetzt, dass eine sinnvolle Reaktion auf schlechte Metrikwerte schwierig ist.

·       Standardeinstellungen zu Regeln und Grenzwerte müssen nicht zu Ihrem Projekt und Ihren Qualitätsansprüchen passen. Generell ist das sogar eher unwahrscheinlich.

·       Metriken als Zielvorgabe zu verstehen, ist problematisch, weil Metriken meistens gefälscht – oder positiver ausgedrückt: optimiert – werden können, ohne die tatsächliche Codequalität zu steigern.

Der letzte Punkt gilt nicht für alle Metriken. Die meisten Metriken sind so genannte Frühindikatoren, weisen also auf potenzielle Probleme hin, bevor diese direkt messbar sind. Komplexität, Abhängigkeiten, Klassen- oder Paketgröße, Kohäsion oder Testabdeckung können darauf hinweisen, dass Ihr Code in der Wartung und Weiterentwicklung fehleranfällig ist. Sicher sagt das aber nur ein Spätindikator (z. B. die Bugdichte). Mit Frühindikatoren bekommen Sie ein Werkzeug an die Hand, das früheres Gegensteuern ermöglicht und für Architekturzwecke sehr interessant ist – seien Sie sich jedoch bewusst, dass Sie kein perfektes Maß auswählen! Sie können mit Tests 100 Prozent Codeabdeckung erreichen, ohne ein einziges sinnvolles assert-Statement zu schreiben.

Metriktools wie Sonar, Structure101, SonarGraph oder das Eclipse-Metrics-Plug-in können Metrikergebnisse aufbereiten und „reporten“. Oft geht jedoch mehr: Sie können Reports anpassen, eigene Regeln hinterlegen, Warnungen konfigurieren oder auch in den Build eingreifen. Nutzen Sie diese Möglichkeiten! Sie erhalten so schnelles, stetiges Feedback von Codeseite, können architektonische Änderungen sichtbar machen und dadurch in ihren Auswirkungen verfolgen. Sie sehen etwa effektiv, welche Qualitätseinbußen Sie aufgrund von Performanzoptimierungen hinnehmen müssen und können die entsprechenden Entscheidungen rasch in Frage stellen, falls die Auswirkungen größer sind als vermutet.

Metriken sind nur Indikatoren!
Wir finden es gut und wichtig, während der Entwicklung von Systemen mindestens den Quellcode zu vermessen, möglichst auch Laufzeitanalyse zu betreiben. Aber – es gibt ein Aber: Die ermittelten Werte, insbesondere bei der statischen Codeanalyse, stellen lediglich Indikatoren dar. Wir empfehlen im Umgang mit Metriken folgende Grundregeln – unsere „Metrikmaxime“:
1. Beobachten Sie Metriken grundsätzlich als Zeitreihe, d. h. messen Sie wiederholt und achten insbesondere auf Veränderungen! Hierzu sind Werkzeuge wie SonarQube [4] ihre besten Freunde.
2. Beachten Sie die Korrelation unterschiedlicher Metriken zueinander– beispielsweise die Komplexität und die Anzahl der Fehler, beide Werte bezogen auf Komponenten oder Subsysteme. Besonders hilfreich sind Korrelationen betriebswirtschaftlicher Größen wie Entwicklungs- oder Wartungsaufwände mit Codemetriken wie Komplexität, Kopplung oder Verletzungen von Coding-Style. Schauen Sie mal die Beispiele von [5] an – die zeigen beeindruckende Zusammenhänge.
3. Finden Sie die Ursachen von „schlechten“ Metriken heraus. Das ist oft viel wichtiger als die „Reparatur“ selbst – weil die Beseitigung der Ursache auch zukünftige Probleme verhindern kann.

Dynamische Analyse (5)

Qualitätsmerkmale wie Zuverlässigkeit, Skalierbarkeit oder Sicherheit wirken langfristig und sind erst wirklich spürbar, wenn das System in Betrieb ist. Bis dahin mit Vermutungen zu arbeiten, ist gefährlich und oft auch teuer. Erst mit der Umsetzung im Programmcode haben Sie das zu lösende Problem annähernd vollständig vor Augen: Sie erkennen, wie kompliziert einfache Konzepte werden, welche Daten benötigt werden und wie Ihre Lösungen mit anderen Konzepten Ihrer Software zusammenwirken. Haben Sie wichtige Teile umgesetzt, können Sie mit Tests auch eine erste Idee vom Laufzeitverhalten bekommen.

Die Rückmeldung aus der Implementierung, samt den Erkenntnissen aus Integration und Test, erden Architekturentscheidungen und minimieren den Raum für Annahmen und Spekulationen. Architekturtests stellen allerdings eine Herausforderung dar: Tests zu Qualitätseigenschaften sind oft schwer zu automatisieren – und ohne Automatisierung ist keine günstige Wiederholbarkeit der Tests gegeben. Das macht Regressionstests teuer. Bei der Automatisierung von Tests zu qualitativen Eigenschaften des Systems kann nicht einfach eine Methode mit definierten Ein- und Ausgabeparametern getestet werden. Es sind meist weite Systemteile betroffen, das System muss oft zumindest in Teilen lauffähig sein, Fehlerfälle müssen simuliert werden und einige Tests sind langlaufend.

Bei der dynamischen Codeanalyse kommen häufig so genannte Profiler zum Einsatz. Sie instrumentieren den Code und erlauben so, zur Laufzeit Metriken zu erheben und damit dann Auswertungen – wie zum Beispiel den Grad der Pfadabdeckung oder die Anzahl der Aufrufe einer bestimmten Methode –zusammenzustellen. Ein Technologiemix in der Codebasis (etwa mit Java, anderen JVM-Sprachen, XML, geskripteten Inhalten und verschiedenen Applikationsframeworks) macht die Vermessung zur Laufzeit recht problematisch.

Wie viel Bewertung ist genug?

Wir haben in diesem Artikel eine ganze Reihe an Methoden, Techniken und Tools vorgestellt, die Sie für die Bewertung Ihrer Architektur und deren konkreter Implementierung einsetzen können. Es empfiehlt sich jedoch nicht immer, alle diese Möglichkeiten auszuschöpfen. Architekturbewertung rechtfertigt sich über gefundene Risiken, Kompromisse und Potenziale. In einfachen oder wenig risikoreichen Projekten lohnen sich Bewertungsaktivitäten deshalb für den Kunden weniger.

Abbildung 5 zeigt das „Qualitätsdreieck“ mit einigen wichtigen Attributen der Softwareentwicklung. Sie kennen es wahrscheinlich, trotzdem möchten wir einige Aspekte herausgreifen.

Architekturbewertung

Das Qualitätsdreieck mit Beispielen

Die grundsätzliche Idee des Dreiecks: Es gibt in jedem Projekt einen Kompromiss zwischen hoher Qualität, niedrigen Kosten und Time to Market zu schließen. Das Beste, was Sie typischerweise erreichen können, sind zwei dieser drei Eigenschaften [6]. Wollen Sie schnell zu einer qualitativ hochwertigen Lösung kommen, müssen Sie viel Geld investieren (etwa viele gute Leute bezahlen, Lösungen zukaufen oder Standardlösungen von Spezialisten anpassen lassen). Wollen Sie in kurzer Zeit eine billige Lösung, ist allumfassende Qualität unerreichbar.

Machen Sie sich auf jeden Fall bewusst, in welchem konkreten Spannungsfeld sich Ihr Projekt befindet. Ist der Zielkorridor größer, sind Architekturentscheidungen weniger risikoreich und selbst eine „zufällige Architektur“ vielleicht tragfähig. Je enger das Korsett, desto problematischer sind falsch getroffene, grundlegende Technologieentscheidungen. Bewertungsansätze für Ihre Entscheidungen werden wichtiger. Sie schaffen Sicherheit und senken das Risiko großer Rückschläge.

In der Open-Source-Methode aim42 [7] finden Sie zum Thema Analyse und Bewertung noch einige weitere Praktiken, beispielsweise Details zur Stakeholder-Analyse, der Durchführung von Interviews, Kontextanalyse oder auch Softwarearchäologie – diese Details hätten den Rahmen dieses Artikels leider gesprengt.

Fazit, oder: Wie lernen Sie besser bewerten?

Kommen wir nochmals auf die Fragestellung vom Anfang dieses Artikels zurück: Sie möchten die Angemessenheit Ihrer Architektur für den gegebenen Kontext einschätzen. Wir haben Ihnen eine Reihe möglicher Ansätze vorgestellt – aber am besten würden wir diese (oder noch weitere) Bewertungs-/Prüfungsansätze gemeinsam auf praktische Beispiele anwenden. Genau diese Schritte geht das iSAQB-Advanced-Level-Modul „Architekturbewertung“ [8] weiter und erläutert Konzepte sowie Vorgehensweisen sehr praxisnah und intensiv. Wir wünschen Ihnen viel Erfolg bei der Antwort auf die Frage „Gut genug?“.

Aufmacherbild: SOPOT, POLAND – MAY 06.2013: The Crooked house on the main street of Monte Cassino in Sopot, Poland von shutterstock.com. Urheberrecht: Kwiatek7

Verwandte Themen:

Geschrieben von
Stefan Toth
Stefan Toth
Stefan Toth arbeitet als Entwickler, Softwarearchitekt und Berater bei der embarc GmbH. Seine Schwerpunkte liegen in der Konzeption und der Bewertung mittlerer bis großer Softwarelösungen sowie der Verbindung dieser Themen zu agilen Vorgehen. Er ist Autor zahlreicher Artikel und des Buchs "Vorgehensmuster für Softwarearchitektur". Kontakt: st@embarc.de
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Phillip Ghadir
Phillip Ghadir
Phillip Ghadir (http://innoq.com) ist technischer Leiter der innoQ. Sein Herz schlägt füt methodisches Software Engineering, er ist Gründungsmitglied des International Software Architecture Qualification Board (http://iSAQB.org) und arbeitet als Berater und Trainer für Softwarearchitektur.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: