routenberechnung.net

von AFV4TX68RY9KI
Hier wird auf rund 300 Seiten einen umfassender Einstieg in die Softwarearchitektur geboten. Dabei liegt der Schwerpunkt vor allem auf der Einführung in die Materie und darüber hinaus ist es "nützliche Literatur für alle, die in der Software-Entwicklung als Projektleiter, Architekt oder Entwickler tätig sind" (Geleitwort). Der Inhalt ist in drei Teile mit folgenden Themen gegliedert:
Teil I:
- Grundlagen: Warum Softwarearchitektur, Definition und Bedeutung
- Softwarearchitektur und Organisationsstruktur: Architektur vs. Unternehmen, Rolle des Architekten, Architektur und Projektmanagement
Teil II:
- Vorgehen: Vorbereitung, Architekturerstellung
- Eínflussfaktoren: Arten, Spezifikation
- Entwurf: Begriffe, Entwurfsprinzipien, Heuristiken
- Dokumentation: Sichten, UML
- Bewertung: Methoden, Szenariobasierte Bewertung (ATAM)
- Toolbox des Architekten: Vorlagen u. Methoden, Technologien u. Werkzeuge,
- Fallbeispiel
Teil III:
- Produktlinien: Definition, Vorgehen

Die einzelnen Kapitel des Buches sind sehr gut aufeinander aufbauend gestaltet und in jedem Kapitel gibt es eine Einführung (Worum gehts, Warum ist das wichtig) und eine Zusammenfassung. Zu vielen Erläuterungen gibt es kurze Praxisbeispiele. Zunächst werden grundlegende Themen erörtert, z.B. die Bedeutung von SW-Architektur, die Rolle des Architekten und die Einbettung und Wechselwirkung in die Organisation. Diese Informationen sind die Grundlage, um überhaupt zu verstehen, welche Berührungspunkte das Thema Softwarearchitektur hat. Danach wird aus Architektensicht der generelle Entwicklungsprozess vorgestellt: Anforderungsanalyse, Spezifikation der Einflussfaktoren, Entwurf & Dokumentation der Architektur und Umsetzung. Diese Schritte werden in den nachfolgenden Kapiteln einzeln behandelt. Beim Thema UML wird der aktuelle Stand 2.0 kurz beschrieben und die Diagramme, deren Einteilung und Eigenschaften kurz angesprochen. Da in der Softwareentwicklung meist nie genügend Zeit zur Verfügung steht, lautet der Grundtenor immer: die wichtigen Dinge (=hohe Priorität) zu erkennen und dann die richtigen Maßnahmen zu ergreifen (=Risikomanagement). An einem Fallbeispiel wird das Gelernte abschliessend kurz wiederholt.

Das Buch bietet eine breite Einführung und mit dem sehr gut aufeinander aufbauendem Stoff einen guten Einstieg in die Materie. Möchte man jedoch tiefer einsteigen, ist zusätzliche Weiterbildung angesagt. Wie der Titel bereits verrät, lässt sich mit Hilfe dieses Buches jedoch ein gutes Basiswissen aneignen. Nachfolgende Dinge haben mir weniger gut gefallen. Im Kapitel zum Vorgehen wurde das Buch zum ersten Mal esoterisch. Hier ist von Zaubertrank bzw. Magie die Rede, die eine Architektur durch einen "assoziativen, kreativen Prozess des Zaubermeisters" entstehen lässt. Das passt meiner Meinung nach nicht zum ingeneursmässigen Vorgehen zur Erstellung einer strategischen Geschäftsgrundlage für Unternehmen (Architektur ist Teil davon). Das erinnert mich ein wenig an das Prozessdiagramm, mit der Aktivität "hier geschieht ein Wunder" kurz vor der Auslieferung ;-). Ein bisschen kurz gekommen ist für mich das Thema UML - dies wird auf 26(!) Seiten abgehandelt. Hier hätte ich bei dem Titel Softwarearchitektur mehr erwartet. Etwas zusammengeschustert wirkten auf mich die Beispiele. Diese wurden möglicherweise von der jeweils verwendeten Literatur übernommen, anstelle ein durchgängiges Beispiel zu konstruieren. Ebenfalls vermisst habe ich im Kapitel Bewertung Beispiele von Checklisten oder Fragebögen. Hier hätte ich zumindest im Anhang einen Beispielfragebogen oder eine Checkliste erwartet, die die Autoren in ihren Projekten verwenden. Ebenfalls im Kapitel Bewertung wird eine Methode (ATAM - Architecture Tradeoff Analysis Method) sehr detailliert erläutert und eine weitere Methode (SAAM) genannt und das wars dann. Zu diesem Thema gibt es wesentlich mehr Methoden, die wenigstens genannt werden sollten.

Fazit: Als erster Schritt für jeden Architekten sollte zunächst das Umfeld der Softwarearchitektur beleucht werden. Das tut dieses Buch im Allgemeinen sehr gut, leider jedoch mit Schwächen im Detail. "Basiswissen Softwarearchitektur" stellt lediglich die Spitze des Eisberges dar, das eigentliche Wissen entsteht durch viel Recherche und natürlich durch Praxis.
 

von A2773GNWAQG9K8
Ich teile die Meinung der anderen Rezensionen nicht: Das Buch ist langatmig und kommt nicht auf den Punkt. Jedes Kapitel beginnt mit "... wird im Folgenden beschrieben ..." und in den Unterkapiteln wird wiederum stets auf die nachfolgenden Kapitel verwiesen. Man muss schon wirklich suchen, um die Essentials zu finden. Der Schreibstil amerikanischer Autoren (Fowler, Larman, Beck, etc.) ist da wesentlich flüssiger.

Inhaltlich habe ich auch nicht viel mitgenommen, da man die Inhalte zusammengestrichen auf mindestens die Hälfte hätte reduzieren können.  

von A1NU13L3JVH7B3
Das Buch hält was es im Titel verspricht. Es gibt einen sehr flüssig geschriebenen und sehr gut zu lesenden Überblick über das, was heute "state-of-the-art" im Feld Software-Architektur ist. Das Buch gibt damit vor allem einen Überblick, über das, was die Forscher am Software-Engineering-Institute der CMU über das Themengebiet publiziert haben - und das in Deutsch und sehr gut zu lesen. Wesentliche Fragen werden abgedeckt, wie
* wo sollte Architektur in der Projektorganisation aufgehängt sein?
* Wie geht man beim Erstellen einer Architektur idealtypisch vor?
* was sind Einflußfaktoren (non-functional requirements)?
* wie macht man es - wobei die Autoren sehr korrekt anmerken, dass Sie nur Hinweise geben können und auch kein Kochbuch haben - das gibt's ja auch bekanntlich nicht?
* wie dokumentiert man das genaze in der UML
und mehr ... ein Beispiel und ein Exkurs über Software - Product - Line Architekturen runden das ganze ab.

Wie gesagt - für ein Buch, das den Titel Basiswissen trägt, ist das absolut o.k. und eine runde Sache. Nur als Tipp - einiges der Originalliteratur sollte man sich im Nachgang doch noch antun - weil zum Beispiel die Kapitel über non-funtional-requirements oder Architektursichten wegen der Gesamtlänge des Buches im Vergleich zu der Originalliteratur doch etwas zurückfallen - aber ist ja eine Einführung - also o.k.

Advanced topics, die einem im Tagesgeschäft das Leben schwer machen, kommen nicht vor, zum Beispiel
* wie geht man mit der Menge Architekturdokumentation in agilen Prozessen um?
* wie geht man mit Stakeholdern um, die einem die Requirements genau nicht sagen WOLLEN, weil sie sich nicht festlegen wollen, und genau KEINE Committments eingehen wollen, weil sonst jemand kommt und bei Ihnen Nutzeninkasso betreiben will :-)
* wie man Architekturreviews positiv gestaltet - die Abschnitte über Kommunikationsverhalten könnten auch im Basiswissen noch ausgebaut werden - weil es einfach für die Produktivität eines Architekten extrem wichtig ist.
* ebenfalls kein Thema ist "Enterprise-Architecture" - also wie man mit einer größeren Menge Anwendungen gleichzeitig umgeht - in dem Buch geht es um Projektarchitektur..

Nutzen pro Zielgruppe:
* IT-Professionals, die wenig über Architektur wissen - für die ist das Buch eine absolut tolle Einführung
* Erfahrene Projektarchitekten - werden nicht neues erfahren, können das Buch aber zum Beispiel einem weniger erfahrenen Kollegen zur Einarbeitung geben
* Unternehmensarchitekten werden Ihr Aufgabengebiet nicht angesprochen finden - da kann man es auch zur Kommunikation für die Projektarchitekten verwenden.
* und agile Entwickler können es lesen - der Widerspruch zwischen Agilität und umfangreicher Dokumentation wird hier aber auch nicht angesprochen