+49 621 595702 0 info@itech-progress.com
Architekturdokumentation – Schluss mit „Das war schon immer so“

Architekturdokumentation – Schluss mit „Das war schon immer so“

März 31, 2021 | Medthodik und Vorgehensweise, Methodisch, Softwarearchitektur, Trainings & Workshops

Das Dokumentieren einer Softwarearchitektur ist für den Projekterfolg unabdinglich. Entwürfe, Entscheidungen und Lösungen müssen nachvollziehbar und wirkungsvoll festgehalten werden. Hierzu gehört idealerweise auch die Beschreibung der verworfenen Alternativen. Denn es stellt sich die Frage, wer nach einem Monat oder auch länger noch alle Gründe weiß, weshalb man sich nun für die eine oder andere Variante entschieden hat. Oder eben auch gegen die eine oder anderen Variante.

Typische Fragen in Softwareprojekten sind beispielsweise:

„Wie sieht das Schichtenmodell aus?“

„Welche Design Patterns wurden verwendet?“

„Welche externen Webservices werden verwendet?“

„Wieso habt Ihr das so gemacht? Ist das nicht zu kompliziert?“

 

Und wenn die Antworten dann lauten:

„Das war schon so, als ich ins Projekt kam.“

„Es wurde in einem Meeting entschieden.“

„Es gibt keine Dokumentation, weil wir agil vorgehen.“

…dann entfachen immer wieder die gleichen Diskussionen. Durch die Entwürfe, die Diagramme und die Konzepte der Architekturdokumentation sollen allen Projektbeteiligten bessere Antworten auf diese Fragen in Softwareprojekten parat stehen. Eine ausführliche Architekturdokumentation kann also sehr klärend wirken, die Kommunikation unterstützen und Konflikte vorbeugen. Der Softwarearchitekt hat folglich die Aufgabe, eine angemessene Lösung zu entwerfen, um eine Nachvollziehbarkeit und gleichzeitig Lerneffekte zu gewährleisten.

Für alle Arten von Architekturdokumentation gelten daher einige übergreifende Anforderungen und Regeln, die Sie bei der Erstellung solcher Dokumente berücksichtigen sollten. Softwarearchitekten benötigen dabei ein grundlegendes Verständnis der Beschreibung von Softwarearchitekturen. Lernen Sie effektiv und praxisorientiert Softwarearchitekturen zu dokumentieren und zielgruppengerecht zu kommunizieren. Erfahren Sie, wie die Architekturdokumentation zu einem integralen Kommunikations- und Arbeitsmittel wird. Lernen Sie architekturrelevante Einflussfaktoren und zentrale Entscheidungen festzuhalten.

Unser 2-tägiges Softwarearchitektur-Training ‚Architekturdokumentation (ADOC)‘ vermittelt neben fachlichen Aspekten auch die wichtigen organisatorischen und sozialen Faktoren der Architekturdokumentation. Neben den Grundbegriffen der Architekturdokumentation bekommen Sie das Wissen rund um die Bestandteile, Vorgehensmodelle, Werkzeuge, Vorgaben und Bewertung an die Hand.

Am Ende dieses Softwarearchitektur-Trainings haben Sie das Rüstzeug, um die Architekturdokumentation eines mittleren oder großen Systems zu erstellen, zu bewerten und das Vorgehen zur Dokumentation eines solchen Systems zu definieren. Das Softwarearchitektur-Training ‚Architekturdokumentation (ADOC)‘ deckt einen Bereich der methodischen Kompetenzen des CPSA Advanced Levels (CPSA-A) ab und ist entsprechend beim iSAQB lizenziert. Wenn Sie die CPSA-A Zertifizierung anstreben, können Sie sich mit der Teilnahme 20 Credit Points anrechnen lassen.

Hier kommen Sie zu weiteren Informationen und zur Anmeldung.

Bei Fragen beraten wir Sie gerne unter training@itech-progress.com oder +49 621 595702 41

OOP digital 2021 – wir sind dabei!

OOP digital 2021 – wir sind dabei!

Feb. 1, 2021 | Methodisch, Technisch, Trainings & Workshops

✓ Full Day Tutorial mit Mahbouba Gharbi und Tom Asel
 
✓ Digitaler Austausch mit unserem Team via 1:1 Chat über Softwarearchitektur, Trainings, Consulting, Projektunterstützung und Karrieremöglichkeiten 
 
✓ Verlosung eines iSAQB CPSA Trainings Ihrer Wahl über unsere Präsenz im Event Hub
 
✓ 100€ Rabattcode für alle Trainings über unsere Präsenz im Event Hub

Unter dem Motto „Back to the Future“ findet die diesjährige OOP rein digital statt und wir sind wie immer mit dabei! Wir freuen uns bereits aus dem Home Office heraus mit Ihnen in den Austausch zu kommen. Sie finden unsere Teammitglieder über den 1:1 Chat oder Sie besuchen ITech Progress und die ITech Academy direkt im Event Hub.

Full Day Tutorial: 
Wardley Maps als Werkzeug in der Architekturanalyse –
Eine Group Mapping Session für Architekten und Entscheider
 
Datum und Uhrzeit:
Mo, 08.02.2021 von 10:00 – 17:00 Uhr
 
Mit:
Mahbouba Gharbi und Tom Asel
 
Publikum:
Maximal 30 Teilnehmer*innen
l
Abstract:

Der Workshop richtet sich sowohl an interessierte Einsteiger:innen als auch an bereits erfahrene Mapper. Im Plenum werden Wardley Maps als Werkzeug in der Toolbox der Software-Entwickler:innen diskutiert und im Rahmen einer ausgiebigen Group-Mapping-Session in der Praxis erprobt. Am praktischen Beispiel der Digitalisierung eines Möbelhauses wird gezeigt, wie Maps dabei helfen, Lagebewusstsein zu schaffen, Risiken zu erkennen und eine Strategie zu entwickeln.

Wir untersuchen die Systemlandschaft, führen eine Architekturanalyse durch und verorten die Ergebnisse wieder auf unserer Landkarte.

Der Workshop zeigt, warum Trägheit ein Unternehmen scheitern lassen kann, wie Softwarearchitektur und Unternehmens-Strategie zusammenhängen und wie Wardley Maps dabei helfen, beides zu kommunizieren.

.
Jetzt Vortrag vormerken
Clean Code als Architekturaufgabe

Clean Code als Architekturaufgabe

Dez. 15, 2020 | Methodisch, Softwarearchitektur, Softwareentwicklung, Technisch, Trainings & Workshops

Clean Code als Architekturaufgabe – Wer nun fragend zum Himmel oder an die Zimmerdecke schaut, sei an das gleichnamige Buch von Robert Martin erinnert, in dem ein erster zielführender Standard für sauberen Quellcode geschaffen und mit einer Vielzahl sachdienlicher Hinweise zu dessen Strukturierung ausgestattet wurde. Tatsächlich beschreibt Clean Code aber nicht nur eine Arbeitsweise, sondern auch eine Bewusstseinshaltung des Entwicklers dahingehend, sich selbst und Nachfolgende nicht mit faktisch unzureichender Codequalität, unsinnigen Entscheidungen und unpräzisen Designs zu belasten. Der Clean-Code-Entwickler übernimmt Verantwortung nicht nur für das Endprodukt, sondern auch für dessen „inneren Werte“ im Hinblick auf Verständlichkeit und Wartbarkeit.

Zugegeben, das alles bezieht sich auf den Entwickler und seine Arbeit. Es mag deshalb in der Tat verwirren, wenn Architekten angeregt werden, sich mit Clean Code als Verbesserungsansatz in der Softwarearchitektur zu beschäftigen. „Was geht mich der Code an?“ lautet meist die Antwort. „Das ist Sache des Programmierers!“ Die Antwort ist ebenso richtig wie falsch: Mit Clean Code zu arbeiten ist eine strategische Architekturentscheidung, die sinnvollerweise begründet in der Konzeptphase getroffen und vom Management abgesegnet wird. Die Entscheidung wird zumeist im Hinblick auf die langfristige Codequalität und die Weiterentwicklungskosten gefällt, und sie ist anspruchsvoll, wie wir noch sehen werden. Sie kann in einem Projekt eine erhebliche Tragweite entwickeln und Auswirkungen bis hin zur personellen Besetzung der Teams.

Wenn Clean Code eine Architekturvorgabe an ein Projekt ist, liegt sie auch im Verantwortungsbereich des Architekten. Softwarearchitekten in Clean-Code-Projekten sollten deshalb auch in der Lage sein, die Einhaltung der Anforderungen im Projekt zu steuern und den Code auf konsequente Umsetzung zu prüfen, beispielsweise mit Tools wie Sonarqube. Und damit öffnen wir schon mal die ersten beiden Schubladen der Konfliktkommode. Denn zum einen sehen Entwickler die tägliche Codehygiene gerne als einen Teil ihrer Intimsphäre an und verzichten nur zu gerne auf „väterliche“ Kontrollgänge des Architekten. Zum anderen nagt die Umsetzung von Clean Code unaufhörlich speziell an der Ressource, die für den Entwickler ohnehin die knappste ist: Zeit. Zumindest ein leiser Protest im Team scheint damit vorprogrammiert. Aber hatte jemand behauptet, der Job des Softwarearchitekten sei ein leichter?

Es gibt noch eine dritte Schublade, nicht minder relevant: Clean Code als Anforderung muss nicht nur dem Projektteam vermittelt, sondern auch dem Management verkauft werden. Auch das kann durchaus schwierig werden. Moderationsfähigkeit und Überzeugungskraft gehörten deshalb ebenso zum Handwerk des Architekten, wie das methodische und technische Wissen.

Auf dieser Basis stellt sich für uns nicht die Frage, ob Clean Code seinen Platz in einem fortgeschrittenen Architekturtraining haben sollte oder nicht, sondern lediglich, in welchem Umfang und welchem Tiefgang das Thema besprochen gehört. In unserem iSAQB-akkreditierten Training „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ befähigen wir die teilnehmenden ArchitektInnen zur Entscheidungsfindung, ob und wann Clean Code in einem Projekt Sinn ergibt. Weiterhin werden die wesentlichen Grundlagen und Tools sowie weiterführende Literatur vorgestellt, um eine Beschäftigung mit dem Thema über die Schulung hinaus zu ermöglichen.

ITech Progress ist „Top-Arbeitgeber Mittelstand 2021“

ITech Progress ist „Top-Arbeitgeber Mittelstand 2021“

Dez. 1, 2020 | Über uns

FOCUS-BUSINESS hat uns in Kooperation mit dem Arbeitgeberbewertungsportal kununu.com zum „Top-Arbeitgeber Mittelstand“ ausgezeichnet. Wir freuen uns sehr über diese besondere Auszeichnung und bedanken uns bei allen Kolleginnen und Kollegen, die uns durch ihr Feedback qualifiziert haben.

Auf Basis zahlreicher Bewertungsparameter wie beispielsweise der Weiterempfehlungsrate oder auch dem Bewertungsdurchschnitt bei rund 900.000 deutschen Unternehmen und deren Kununu-Bewertungen, werden die Top-Arbeitgeber gekürt.

Sie suchen eine neue Herausforderung?

Wir sind immer offen für hoch motivierte, neugierige Menschen, die sich weiterentwickeln wollen in einem spannenden, anspruchsvollen und innovativem Arbeitsumfeld.

Zu unserer Karriereseite

Prüfungsstress im Projekt: Welche NOTE bekommt meine Architektur?

Prüfungsstress im Projekt: Welche NOTE bekommt meine Architektur?

Nov. 10, 2020 | Methodisch, Softwarearchitektur, Trainings & Workshops

Der Abnahmetermin für die Software steht bevor und das Review der Softwarearchitekturen sorgt für schlaflose Nächte. Eine Architekturbewertung soll durchgeführt werden um die Stärken und Schwächen der Softwarearchitektur zu ermitteln. Wurden die relevanten Qualitätsmerkmale erfüllt und alle Ziele erreicht?

Grundlegend geht es bei der Architekturbewertung darum, herauszufinden, ob eine Softwarearchitektur die in sie gesetzten Erwartungen erfüllt oder nicht. Was sind die Stärken und Schwächen einer Architektur und welche Risiken und Probleme ergeben sich daraus?

Als Vergleich zur Softwarearchitekturbewertung nehmen wir einmal die Bewertung von sportlichen Leistungen. Genau wie bei der Softwarearchitektur lassen sich auch sportlichen Leistungen je nach Disziplin mehr oder weniger gut beurteilen. Wer läuft schneller? Wer springt höher? Wer wirft weiter? Wer schießt mehr Tore?  Diese Fragen sind noch einfach zu beantworten. In der Softwarearchitektur sind die Fragen natürlich ein wenig anders: Wie viele gefundene Fehler gibt es pro Paket? Wie hoch ist der Resscourcenverbrauch? Wie viel Zeit wird für die Verarbeitung bestimmter Funktionen oder Anwendungsfälle benötigt?

Doch nicht alle Fragen sind immer so leicht zu beantworten. Die Bewertung von Turniertänzern oder Eiskunstläufern ist schon etwas komplizierter und lässt sich nicht nach einfachen Zahlen bemessen, sondern funktioniert nach einem komplizierten Schema. Die Qualität entscheidet!

Wie ist das nun in der Softwarearchitektur? Gibt es hier sowas wie Messlatten und Schiedsrichter? Wie sieht hier das Ergebnis aus? Im Sport ist das klar: Der Gewinner bekommt die Goldmedaille.

  • Wie zuverlässig läuft das System?
  • Wie sicher ist das System?
  • Kann die Software ihr Leistungsniveau unter festgesetzten Bedingungen über einen bestimmten Zeitraum aufrechterhalten?
  • Wie sparsam ist die Software zur Lösung eines festgelegten Problems bezüglich der Ressourcen, Zeitverhalten bei Anfragen und Bearbeitungen sowie Speicherplatz?
  • Wie hoch ist der Aufwand zur Fehlerbeseitigung, zur Umsetzung von Verbesserungen oder zur Anpassung an Umgebungsveränderungen?
  • Ist die Software auch auf anderen Systemen (Hard- und Software) einsetzbar?

In der Softwarearchitektur gibt es verschiedene Methoden und Werkzeuge, die zu unterschiedlichen Zeitpunkten eingesetzt werden können. Bei der Bewertung einer Architektur gibt es jedoch zwei Ansätze: der qualitative Ansatz und der quantitative Ansatz.

 

Qualitativer Ansatz zur Architekturbewertung

Der qualitative Ansatz ermöglicht eine Bewertung nach Beschaffenheit oder Güte der Softwarearchitektur und hilft frühzeitig Risiken zu identifizieren, die die Erreichung der Qualitätsziele gefährden können. Ein Qualitätsmodell (wie z.B. ISO 25010) kann verwendet werden. Das ISO Modell definiert acht Qualitätsmerkmale: Benutzbarkeit, Effizienz, Funktionale Eignung, Kompatibilität, Sicherheit, Übertragbarkeit, , Wartbarkeit und Zuverlässigkeit.

Die qualitative Bewertung sollte jedoch regelmäßig und so früh wie möglich stattfinden. Eine der führenden Methoden im Bereich der Softwarearchitekturbewertung ist ATAM. ATAM seht für Architecture Tradeoff Analysis Method und bezeichnet eine Szenario-basierte Methode zur Bestimmung der Stärken, Schwächen und den getroffenen Kompromissen einer Softwarearchitektur. Ein ATAM-Workshop dauert in der Regel 3 – 4 Tage und wird gemeinsam mit den Stakeholdern durchgeführt.

 

Quantitativer Ansatz zur Architekturbewertung

Der quantitative Ansatz ist eine Bewertung der Artefakte in Zahlen und kann helfen, kritische Teile innerhalb von Systemen zu identifizieren. Im Gegensatz zur qualitativen Bewertung liefert sie keine Aussage über die Funktionsfähigkeit der Software. Zur Bewertung wird eine Reihe von Messungen und Metriken verwendet, wie beispielsweise die Anzahl der geänderten Anforderungen pro Zeiteinheit, die Anzahl der Testfälle, die Anzahl der gefundenen Fehler pro Paket, die Anzahl der neuen Codezeilen oder die Zyklomatische Komplexität. Der Vorteil ist, dass die Messungen automatisierbar sind und leicht wiederholt werden können. Es besteht jedoch auch die Gefahr von Missdeutungen, da ein fachlicher und technischer Kontext benötigt wird, um vergleichbar zu sein. Gesammelte Daten aus Vergleichsprojekten können hierbei hilfreich sein.

Insgesamt gesehen ist die Architekturbewertung ein wichtiges Hilfsmittel zur Bestimmung der Qualität einer Software bei der es aber weniger darum geht die Architektur zu benoten, sondern eher mehr Durchblick zu bekommen.

 

Sie möchten noch mehr erfahren?

Das 2-tägige iSAQB-akkreditierte Training „Architekturbewertung (AWERT)“ vermittelt das notwendige Wissen und die Fähigkeiten, um Softwarearchitekturen bewerten zu können. Ziel ist die Beantwortung der Frage: Wie findet man heraus, ob eine Architektur die Erwartungen erfüllt?

Zu den Terminen