- Arbeiten Sie durch Anforderungen getrieben an Ihrer Softwarearchitektur
- Passen Sie den Architekturaufwand effektiv an Ihr Projekt an
- Profitieren Sie von aktuellen Erkenntnissen zu Zusammenarbeit und Vorgehen
- Verzahnen Sie Softwarearchitektur wirksam mit der Implementierung
- Integrieren Sie Architekturpraktiken erfolgreich in zeitgemäße Vorgehensmodelle
- Im Internet: www.swamuster.de
Moderne Projekte setzen auf dynamische Zusammenarbeit, hohe Flexibilität und Ergebnisorientierung. Eng verzahnt mit dem Kunden werden qualitativ hochwertige Produkte erstellt. Herangehensweisen für Softwarearchitektur müssen sich weiterentwickeln, um in diesen Umfeldern gut zu funktionieren. In der Praxis ist das bereits beobachtbar: Entwicklungsteams kümmern sich gemeinsam um Architekturaufgaben, Architektur wird 'Just-in-time' entschieden und bettet sich in den üblichen Priorisierungsprozess von Anforderungen und Tätigkeiten. Die Theorie hingegen hat an dieser Stelle noch etwas aufzuholen.
Dieses Buch beschreibt leichtgewichtige Bausteine guter Architekturarbeit, die problemorientiert eingesetzt werden können, um das eigene Projekt zu verbessern. In der bewährten Struktur von Mustern wird ein übliches Problem geschildert und mit einer methodischen Lösung versehen. Die Muster referenzieren aufeinander und sind sowohl einzeln als auch in Kombination einsetzbar. Insgesamt entsteht das Bild einer neuen Architekturdisziplin: Einer Disziplin, die sich nicht um den einen Architekten dreht, die sich gut in agile Projekte bettet, die Zielorientierung fördert und Pragmatismus großschreibt.
AUS DEM INHALT //
Risikogetriebene Softwarearchitektur // Rollen und Verantwortung // Qualitätsszenarien // Technische Schulden // Kanban und Backlogs // Architekturvision // Der letzte vernünftige Moment // Architekturprinzipien // Analoge // Modellierung // Architecture Owner // Architekturcommunities // Umsetzungsprüfung
Systemvoraussetzungen für E-Book inside: Internet-Verbindung und Adobe-Reader
Stefan TOTH unterstützt Projekte und Unternehmen als Softwareentwickler, -architekt und Berater. Der effektive und pragmatische Umgang mit Entwurfsfragen und weitreichenden Entscheidungen ist dabei ein zentrales Thema. Seine Erfahrungen gibt er regelmäßig in Form von Vorträgen und Fachartikeln weiter.
Stefan TOTH unterstützt Projekte und Unternehmen als Softwareentwickler, -architekt und Berater. Der effektive und pragmatische Umgang mit Entwurfsfragen und weitreichenden Entscheidungen ist dabei ein zentrales Thema. Seine Erfahrungen gibt er regelmäßig in Form von Vorträgen und Fachartikeln weiter.
Inhalt 6
Geleitwort 8
1Einleitung 12
1.1 Kurze Motivation 12
1.2 Vorgehensmuster als Mittel der Wahl 13
1.3 Gegenstand: Softwarearchitektur 14
1.4 Mission Statement 15
1.4.1 Abgrenzung zu anderen Büchern 16
1.4.2 Für wen ich dieses Buch geschrieben habe 18
1.5 Dieses Buch richtig verwenden 19
1.5.1 Ein grober Überblick 19
1.5.2 Patterns lesen 20
1.5.3 Patterns anwenden 20
1.5.4 Agil und Lean sind Fremdwörter? 23
1.6 Webseite 25
1.7 Danksagung 25
2Einstieg samt Wegweiser 26
2.1 Die inhaltliche Vision 27
2.1.1 Durch Anforderungen getrieben 27
2.1.2 Vom Aufwand her dem Problem angemessen 28
2.1.3 Von aktuellen Erkenntnissen zu Zusammenarbeit und Vorgehen beeinflusst 29
2.1.4 Gut mit der Implementierung verzahnt 30
2.1.5 Einfach in aktuelle Vorgehensmodelle integrierbar 32
2.1.6 Warum Design alleine nicht hilft 33
2.1.7 Warum agiles Vorgehen alleine nicht hilft 34
2.2 Muster im Überblick 36
2.2.1 Kapitel.3 – die Basis für Architekturarbeit 36
2.2.2 Kapitel.4 – richtig entscheiden 36
2.2.3 Kapitel.5 – Zusammenarbeit und Interaktion 39
2.2.4 Kapitel.6 – Abgleich mit der Realität 39
2.2.5 Muster kategorisiert 42
2.3 Muster im Vorgehen einsortiert 43
2.4 Muster und die Architektenfrage 46
2.4.1 Die theoretisch beste Rollenverteilung 48
2.4.2 Die praktisch beste Rollenverteilung 50
2.5 Kurze Einführung ins Fallbeispiel 54
3Die Basis für Architekturarbeit 56
3.1 Initialer Anforderungs-Workshop 59
3.2 Anforderungspflege-Workshops 64
3.3 Szenarien als Architekturanforderungen 68
3.4 Szenarien kategorisieren 73
3.5 Technische Schulden als Architekturanforderungen 77
3.6 Architekturarbeit im Backlog 85
3.7 Architekturarbeit auf Kanban 88
4Richtig entscheiden 94
4.1 Architekturarbeit vom Rest trennen 96
4.2 Der letzte vernünftige Moment 101
4.3 Gerade genug Architektur vorweg 106
4.4 Architekturentscheidungen treffen 112
4.5 Release-Planung mit Architekturfragen 121
4.6 Risiken aktiv behandeln 127
4.7 Im Prinzip entscheiden 134
4.8 Ad-hoc-Architekturtreffen 138
5Zusammenarbeit und Interaktion 144
5.1 Informativer Arbeitsplatz 146
5.2 Gemeinsam entscheiden 151
5.3 Analog modellieren 157
5.4 Stakeholder involvieren 163
5.5 Wiederkehrende Reflexion 170
5.6 Architecture Owner 177
5.7 Architekturcommunities 183
6Abgleich mit der Realität 190
6.1 Frühes Zeigen 192
6.2 Realitätscheck für Architekturziele 197
6.3 Qualitative Eigenschaften testen 202
6.4 Qualitätsindikatoren nutzen 212
6.5 Code und Architektur verbinden 223
6.6 Kontinuierlich integrieren und ausliefern 231
6.7 Problemen auf den Grund gehen 236
Literaturverzeichnis 242
Stichwortverzeichnis 248
2Einstieg samt Wegweiser
Auf den nächsten Seiten tauchen Sie in die inhaltliche Vision des Buchs ein. Die übergreifende Idee hinter den 29 Vorgehensmustern für Softwarearchitektur ist in Abschnitt 2.1 detailliert dargestellt und mit den Konzepten der übrigen Kapitel verbunden. Nach diesem vielleicht wichtigsten Abschnitt des gesamten Buchs biete ich Ihnen verschiedene Zugänge zu den enthaltenen Vorgehensmustern:
? ? Für Pragmatiker gibt Abschnitt 2.2 – „Muster im Überblick“ einen sachlichen Überblick: Einer Kapitelzusammenfassung folgt jeweils ein Verzeichnis der enthaltenen Vorgehensmuster, inklusive Problem und Kurzbeschreibung.
? ? Für Methodiker kommt Abschnitt 2.3 – „Muster im Vorgehen einsortiert“ gerade recht: Ich stelle hier ein generisches Entwicklungsvorgehen vor, das beschreibt, wie und wann Softwarearchitekturarbeit sinnvoll ist. In dieses Vorgehen integriere ich anschließend die Vorgehensmuster dieses Buchs.
? ? Für Rollenfreunde bietet Abschnitt 2.4 – „Muster und die Architektenfrage“ eine musterübergreifende Antwort auf die Frage, ob und wenn ja, welche Arten von Architekten, in zeitgemäßen Entwicklungsprojekten gefragt sind.
Zum Abschluss stelle ich kurz das Fallbeispiel vor, das Sie durch alle Vorgehensmuster begleiten wird (Abschnitt 2.5).
? ?2.1 Die inhaltliche Vision
Hinter den Vorgehensmustern dieses Buchs steht eine konsistente Vision zeitgemäßer Softwarearchitekturarbeit. Bereits die in Abschnitt 1.3 genannten Definitionen von Softwarearchitektur scheren nicht alle Softwareentwicklungsprojekte über einen Kamm. Menge und Ausprägung von grundlegenden, risikoreichen Fragestellungen sind von Projekt zu Projekt unterschiedlich. Zeitgemäße Softwarearchitektur erkennt diese Individualität auf vielen Ebenen an und greift aktuelle Strömungen der Softwareentwicklung auf. Zeitgemäße Softwarearchitektur ist:
1.Durch Anforderungen getrieben
2.Vom Aufwand her dem Problem angemessen
? ? In dynamischen Umfeldern nicht behindernd
? ? In architektonisch risikoreichen Projekten ausreichend fundiert
3.Von aktuellen Erkenntnissen zu Zusammenarbeit und Vorgehen beeinflusst
4.Gut mit der Entwicklung verzahnt
5.Einfach in aktuelle Vorgehensmodelle integrierbar
? ? Iterativ leistbar
? ? In aktuellen Konzepten des Vorgehens verankert
? ? Frei von behindernden oder umständlichen Ergänzungen
Ich greife diese Punkte im Folgenden auf, beschreibe sie etwas detaillierter und referenziere auf wichtige Vorgehensmuster.
2.1.1?Durch Anforderungen getrieben
Wenn Sie eine fachliche Methode ausimplementieren oder ein neues Feld im UI vorsehen, orientieren Sie sich an Wünschen und Anforderungen des Kunden. Dasselbe sollten Sie tun, wenn Sie Technologien auswählen oder Fremdsysteme anbinden. Was auch immer die grundlegenden Fragestellungen in Ihrem Projekt sind: Lassen Sie sich von Anforderungen leiten.
Qualitätsanforderungen kommt dabei eine besondere Bedeutung zu. Sie beschreiben die nichtfunktionalen Aspekte der zu erstellenden Lösung, also wie eine Funktionalität bereitgestellt werden soll.1 Soll die Funktionalität ohne Unterbrechung zur Verfügung stehen, sind Zuverlässigkeit und Verfügbarkeit wichtig. Wollen wir in Zukunft mehr Benutzer mit unserer Funktionalität beglücken, ist Skalierbarkeit spannend. Wollen wir verhindern, dass Unbefugte heikle Funktionalität nutzen, ist Sicherheit ein Thema. Diese Qualitätsmerkmale beziehen sich oft auf weite Systemteile oder sogar das Gesamtsystem. Zuverlässigkeit lässt sich nicht durch eine neue Klasse oder Komponente sicherstellen, die gesamte Anwendung und deren Basis müssen entsprechenden Prinzipien gehorchen.
Qualität ist somit meist querschnittlich und betrifft viele Projektmitarbeiter. Wir erreichen Qualitätsmerkmale durch den Einsatz der richtigen Technologien, Plattformen, Frameworks, Muster oder die breite Adaptierung von Arbeitsweisen. Das ist grundlegende Arbeit am Fundament. Entsprechende Entscheidungen sind weitreichend und oft aufwendig in der Umsetzung. Wir sind damit mitten in der Architekturdomäne und es ist wenig überraschend, dass Qualitätsanforderungen als die Architekturanforderungen gesehen werden.
Wie dieses Buch hilft Jedes Projekt, egal wie leichtgewichtig oder agil, muss seine qualitativen Anforderungen kennen. In diesem Buch stelle ich einen leichtgewichtigen Ansatz zur Verankerung und gemeinsamen Bearbeitung dieser Anforderungen vor. Den Start macht Kapitel 3 – „Die Grundlage von Architekturarbeit“. Die wichtigsten Muster für diesen Teil der Vision: ? ? 3.1 – Initialer Anforderungs-Workshop ? ? 3.3 – Szenarien als Architekturanforderungen ? ? 3.6 – Architekturarbeit im Backlog ? ? 4.4 – Architekturentscheidungen treffen |
2.1.2?Vom Aufwand her dem Problem angemessen
Stellen Sie sich ein Produktentwicklungsprojekt vor, das auf einem bekannten Technologiestack aufsetzt. Es gibt ein passendes, unternehmensspezifisches Applikationsframework, das einzige Umsetzungsteam hat bereits ähnliche Projekte durchgeführt und kennt die Domäne. Der Projektplan ist realistisch und der Aufwand ist überschaubar. Dieses Projekt kommt wohl mit weniger Architekturaufwänden aus als ein großes Projekt für die Umsetzung einer neuartigen Flugsicherungssoftware. Im ersten Projekt ergeben sich wahrscheinlich weniger risikoreiche Fragestellungen. Das Umfeld ist weniger komplex, das zu lösende Problem und der Lösungsweg sind recht gut verstanden. In Projekt zwei sind einige Komplexitätstreiber zu finden – Architekturarbeit wird spannender. Bild?2.1 zeigt, wie sich Architekturaufwände und Komplexitätstreiber die Waage halten sollten.
Arbeit an der Softwarearchitektur hat das Ziel, gute Entscheidungen zum richtigen Zeitpunkt zu treffen und das Risiko einer falschen Entscheidung zu minimieren. Zu hohe Aufwände machen Projekte schwerfällig, langsam und aufwendiger als nötig. Erstellen Sie etwa einen Prototypen für eine einfach umzusetzende Anforderung, verzögern Sie die Umsetzung und die damit verbundene Rückmeldung. Ihr Aufwand hat zudem wenig bis keinen Nutzen. Solche „Irrwege“ behindern vor allem in weniger komplexen, dynamischen Projekten und machen sie starrer als nötig.
Auf der anderen Seite führt zu wenig Arbeit an der Softwarearchitektur zu zufälliger Architektur und potenziell zur Verfehlung wichtiger Projektziele. In architektonisch risikoreichen Projekten muss folglich ausreichend fundierte Architekturarbeit geleistet werden.
Wichtig ist die richtige Balance, die sich für jedes Projekt anders gestaltet.
Bild?2.1?Das richtige Maß für Softwarearchitekturarbeit
Wie dieses Buch hilft Das richtige Maß an Softwarearchitekturarbeit ist in jeder Projektphase interessant. In diesem Buch bespreche ich einerseits die Menge an vorab zu leistender Architekturarbeit, andererseits zeige ich, wie Sie bei konkreten Fragestellungen entscheiden, ob Architekturarbeit notwendig ist und wann diese Arbeit erfolgen sollte. Die wichtigsten Muster für diesen Teil der Vision: ? ? 4.1 – Architekturarbeit vom Rest trennen ? ? 4.2 – Der letzte vernünftige Moment ? ? 4.3 – Gerade genug Architektur vorweg |
2.1.3?Von aktuellen Erkenntnissen zu Zusammenarbeit und Vorgehen beeinflusst
Auch wenn die Wurzeln der Disziplin noch weiter zurückreichen, Softwarearchitektur ist ein Kind der 1990er-Jahre. Im universitären Umfeld und mit großer finanzieller Unterstützung des amerikanischen Verteidigungsministeriums wurden Muster, Sprachen und Methoden erarbeitet2. Weil Rollen- und Prozessmodelle ihre Blütezeit erlebten, konnte man die Disziplin relativ leicht einem „Architekten“ zuschlagen.
Die Softwareentwicklung hat seit den 1990er-Jahren viel gelernt. Agile Softwareentwicklung, Lean Development oder auch die Organisationstheorie beinhalten viele Erkenntnisse zu Zusammenarbeit, Komplexität und Dynamik. Auch Softwarearchitektur kann als Disziplin von diesen Erkenntnissen profitieren.
Wie wäre es mit Praktiken, die es ermöglichen, Architekturaufgaben effektiv auf mehrere Schultern zu verteilen? Praktiken, die dynamische Projekte nicht bremsen? Was...
Erscheint lt. Verlag | 26.11.2014 |
---|---|
Sprache | deutsch |
Themenwelt | Mathematik / Informatik ► Informatik |
Schlagworte | Agil • Entwickler • Entwurfsmuster • Patterns • Projektmanagement • Scrum • Softwarearchitektur |
ISBN-10 | 3-446-44315-0 / 3446443150 |
ISBN-13 | 978-3-446-44315-0 / 9783446443150 |
Haben Sie eine Frage zum Produkt? |
![PDF](/img/icon_pdf_big.jpg)
Größe: 14,8 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: PDF (Portable Document Format)
Mit einem festen Seitenlayout eignet sich die PDF besonders für Fachbücher mit Spalten, Tabellen und Abbildungen. Eine PDF kann auf fast allen Geräten angezeigt werden, ist aber für kleine Displays (Smartphone, eReader) nur eingeschränkt geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür einen PDF-Viewer - z.B. den Adobe Reader oder Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür einen PDF-Viewer - z.B. die kostenlose Adobe Digital Editions-App.
Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
![EPUB](/img/icon_epub_big.jpg)
Größe: 9,2 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise
Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich