Beschleunigte Softwaretechnik: Warum sich Architekten mit Effizienz und Effektivität beschäftigen...
-
Upload
martin-lehmann -
Category
Technology
-
view
779 -
download
0
Transcript of Beschleunigte Softwaretechnik: Warum sich Architekten mit Effizienz und Effektivität beschäftigen...
Beschleunigte Softwaretechnik: Warum sich Architekten mit Effizienz und
Effektivität beschäftigen müssen – und wie Best Practices dabei helfenMartin Lehmann, Accso GmbH – iSAQB Architekturtage November 2013, Leipzig
Beschleunigte Softwaretechnik: Warum sich Architekten mit Effizienz und
Effektivität beschäftigen müssen – und wie Best Practices dabei helfenMartin Lehmann, Accso GmbH – iSAQB Architekturtage November 2013, Leipzig
2
Über meine Person
� 42 Jahre
� Studium der Informatik an der Universität Würzburg
� Berufsstart 1997
� Einstieg bei sd&m 2001
� Verschiedene industrielle Softwareprojekte als Architekt, Projektmanager, Berater
� Mitarbeit bei sd&m Research zu Quasar von 2006-2007
� Seit 2010 Mitglied der Geschäftsleitung und CTO bei der
Accso – Accelerated Solutions GmbH in Darmstadt
www.accso.de
� Accso ist Fördermitglied des iSAQB seit 2013,
Mitarbeit in den Arbeitsgruppen Marketing und Internationalisierung
3
Beschleunigte IT-Lösungen und hochkarätige
Technologie- und Architekturberatung
Unser Angebot
� Individuelle Softwarelösungen für IT-Kernsysteme (Schwerpunkte: Java/JEE, .NET, Open Source, RIA, u.a.)
� Technologie- und Architektur-Beratung (Schwerpunkte: IT-Architektur und -Modernisierung, EAM, SOA,
BPM, Security, u.a.)
� Management von Software-Projekten
� Integration dedizierter Software-Produkte (Schwerpunkte: CMS, Portal)
Unsere Kunden
� Wir entwickeln individuelle Softwarelösungen für die Kernkompetenzen unserer Kunden und beraten in
aktuellen Fragestellungen von Technologie und Architektur.
� Accso arbeitet branchenübergreifend für namhafte Unternehmen, dazu zählen Deutsche Telekom,
Deutsche Bahn, Deutsche Flugsicherung, Deutsche Wetterdienst, DekaBank, AOK, ZDF, SWR, HR, WDR,
DuMont-Verlag, HRS, Maxdome, Vodafone und weitere.
4
Beschleunigte IT-Lösungen und hochkarätige
Technologie- und Architekturberatung
Fakten
� Gegründet 2010 in Darmstadt
� GmbH mit Kapitalbeteiligung des Landes Hessen
� Geschäftsführung: Jürgen Artmann,
Dr. Markus Voß
� Niederlassungen: Darmstadt, Köln
Unsere Mitarbeiter
� 68 Mitarbeiter (Stand 1.9.2013)
� Software-Ingenieure und IT-Berater
� Exzellent ausgebildet (fast alle Mitarbeiter haben
einen Hochschulabschluss, jeder sechste mit
Promotion)
� sehr erfahren (> 80% mit mehr- bzw. langjähriger
Berufserfahrung)
� hoch motiviert
Mitarbeiter
Umsatz
0
10
20
30
40
50
60
70
Jul 10 Jan 11 Jul 11 Jan 12 Jul 12 Jan 13 Jul 13
0
1.000.000
2.000.000
3.000.000
4.000.000
5.000.000
6.000.000
2010/11 2011/12 2012/13
5
Individuelle Kernsysteme in dynamischen Umfeldern entwickeln wir
sicher, mit hoher Qualität und besonders effizient
standardisierend
(Commodity)
differenzierend
(individuelle Kernsysteme)
Zielsetzung
des Projekts
Wesen des Projekts
interaktiv
dynamisch
innovativ
flexibel
eher kleiner
prozessorientiert
standardisierbar
arbeitsteilig
eher größer
Wettbewerbsfaktor
in diesem Bereich:
Minimierung der
Stückkosten durch
Offshoring
Unser wichtigster
Wettbewerbsfaktor:
Effizienz im Vorgehen
durch Beschleunigte
Softwaretechnik (BeST)� Erstellung individueller Softwarelösungen
für IT-Kernsysteme (Java-Technologie, .NET,
Open Source)
� Management von Software-Projekten
� IT-Beratung (Technologie und Architektur)
� Integration dedizierter Software-Produkte
6
BeST: Gesamtübersicht der Elemente und effizienter Techniken
Analyse Architektur Entwicklung Test Umgebung Projekt-
management
Vorgehensstrategie
� Refactoring
� Continous
Integration,
Deployment and
Delivery (Cx)
� RAD-Frameworks
(Grails, Lift, Roo)
� Polyglot Program-
ming (mit Groovy,
Scala, Clojure, ...)
� Vorkonfigurierte
integrierte
Werkzeuge out-of-
the-box (DSI)
� Virtualisierung
� Cloud-Computing
� Infrastructure as
Code
� DevOps
� Agile Methoden
(Scrum, Kanban)
� Lean Planning and
Controlling
� Forciertes
Umfangs-
Management
� Agile Spezifikation
� Effiziente
Moderations-,
Kommunikations-
und
Dokumentations-
techniken
� Modellgetriebene
Spezifikation
(MDx)
� Agile Architektur
� Referenzarchitek-
turen
� Skalierbare und
offene SW-
Architektur nach
True-SOA Prinzip
� Trade-Off Methode
für Software-
Architektur (ATAM)
� Test first
� Testgetriebene
Entwicklung (TDx)
� Test-
Automatisierung
� Testprozess-
optimierung
� Projektspezifische Methodenauswahl
und Methodenanwendung
� Agilitätsprofil (Reglermodell)
� Kontextspezifische BeST-Practices
An
gem
ess
en
he
itG
an
zhe
itlic
hke
it
BeST-Framework
BeST-Training
BeST-Praktika BeST-Foundation BeST-Module
Tea
m-O
rie
nti
eru
ng
Be
ST
-Ph
ilo
sop
hie
7
Beschleunigte Softwaretechnik (BeST) entwickelt etablierte
Softwaretechnik weiter - hin zu mehr Effizienz und Effektivität.
Beschleunigte
Softwaretechnik
Etablierte
Softwaretechnik
Frühe
Software-
entwicklung
� Definierte Vorgehensweisen und Prozesse
� Standardisierte Methoden, Architekturen,
Programmiersprachen, Komponenten, Frameworks
und Werkzeuge
� Wiederholbar, messbar, steuerbar
� Ad-hoc Vorgehensweisen, keine Standardisierung
� Kaum Aussagen über Ergebnisqualität und Einhaltung von
Zeit- und Budgetvorgaben möglich
� Basiert auf etablierter Softwaretechnik
� Betont besonders die Aspekte Effizienz und
Effektivität
� Ganzheitlich (optimiert alle Dimensionen),
Angemessen („quick“, aber nicht „dirty“),
Team-Orientiert (fordert exzellente Skills)
8
Beschleunigte Softwaretechnik (BeST) liefert einen Ordnungsrahmen.
BeST-Prinzipien(die Grundideen)
BeST-Framework(die Organisation)
BeST-Practices(die konkreten Hilfestellungen)
9
Einen Schritt zurück:
Software-Engineering - Nichts Neues, sondern altbekannt?!
Friedrich L. Bauer,dt. Informatik-
Pioneer
(u.a. Erfinder
des Stacks)
Definition für Software-Engineering
im Zuge der Diskussion zu „Software Crisis“, 1968:
Establishment and use of sound engineering
principles to obtain economically software that is
reliable and works on real machines efficiently.
Nato-Konferenz 1968 in Garmisch
10
Vorgehensstrategie
An
aly
se
Arc
hit
ek
tur
En
twic
klu
ng
Test
Pro
jek
tma
na
ge
me
nt
Um
ge
bu
ng
Die Domänen (=Hauptaufgabengebiete) des Software-Engineerings
11
Es gibt zwei Wege, sich dem Begriff Architektur zu nähern
Strukturorientiert:
Architektur ist,
wie ein System
aufgebaut ist.
Aufgabenorientiert:
Architektur ist,
was ein
Architekt tut.
12
Für beide Interpretationen von Architektur gibt es wertvolle
BeST-Practices
Strukturorientiert:
Architektur ist,
wie ein System
aufgebaut ist.
Aufgabenorientiert:
Architektur ist,
was ein
Architekt tut.
13
Aufgabenorientierte Herangehensweise an Architektur
Aufgabenorientiert:
Architektur ist,
was ein
Architekt tut.
Strukturorientiert:
Architektur ist,
wie ein System
aufgebaut ist.
14
Effizienz (es richtig machen) und Effektivität (das Richtige machen)
Allgemein:
Es geht nicht um eine möglichst
große Menge an Code oder Doku
bei gleichem Aufwand oder um
irgendeine Lösung bei möglichst
geringem Aufwand.
Es geht um eine, den eigentlichen
Kundenanforderungen
angemessene Lösung bei
möglichst geringem Aufwand.
Zudem ist überhaupt nur dann mit
einer signifikanten Steigerung der
Effizienz und Effektivität zu
rechnen, wenn das Projekt
ganzheitlich in allen Aspekten auf
Effizienz getrimmt wird.
1 2
Effizienz = Ertrag
Aufwand
In Software-Projekten:
Effizienz = Effekt
Projektaufwand
Ertrag = Effekt =Kundennutzen bzw.
Kundenzufriedenheit
15
Aristoteles
Das Ganze ist mehr als die
Summe seiner Teile.
Grundprinzip und erste Leitplanke: Ganzheitlichkeit im Vorgehen!
(frei nach) John Nash
Einzelne lokale Optimierungen
führen nicht zu einem globalen
Optimum.
16
Grundprinzip und erste Leitplanke: Ganzheitlichkeit im Vorgehen!
Beschleunigte Softwaretechnik ist
ganzheitlich, berücksichtigt also
alle Domänen der Softwaretechnik
über den gesamten Lebenszyklus
der Lösung.
Architektur steht demnach nicht
alleine (im Elfenbeinturm),
sondern muss mit allen Domänen zusammenarbeiten, um die
die Poteniale zur Effizienzsteigerung
auszuschöpfen.
Genau (nur) daraus ergibt sich ein wesentlicher Teil ihres Mehrwerts.
17
Vorgehensstrategie
BeST-Framework
An
aly
se
Arc
hit
ek
tur
En
twic
klu
ng
Test
Pro
jek
tma
na
ge
me
nt
Um
ge
bu
ng
BeST-Prinzip
Ganzheitlichkeit
� Wir betrachten alle Domänen
der Softwaretechnik im Sinne
von Hauptaufgabenbereichen
� Die Darstellung impliziert
keine zeitliche Abfolge der
einzelnen Tätigkeiten
(im Sinne eines Wasserfall-
modells).
� Sie ist unabhängig vom
konkreten Vorgehensmodell
BeST-Framework: Wir betrachten alle Domänen (=Hauptaufgabengebiete)
des Software-Engineerings ganzheitlich
18
Be
ST-Fram
ew
ork: Zie
le, A
ufgab
en
, Me
tho
de
n
Domäne Architektur
Ziele(warum?)
Aufgaben(was?)
Methoden(wie?)
Artefakte(was,womit?)
19
Do
mä
ne
Arc
hit
ek
tur
Zie
le(w
aru
m?
)
Au
fga
be
n(w
as?
)
Me
tho
de
n(w
ie?
)
Art
efa
kte
(wa
s,w
om
it?
)
BeST-Practices sind die eigentlichen und wesentlichen Hilfsmittel
BeST-Practices ...
... unterstützen konkret bei der
Auswahl geeigneter Methoden
zur Lösung einer Aufgabe
... geben konkrete Hinweise,
wie die gewählte Methode
genau anzuwenden ist
... und beziehen sind dabei oft
auf einen speziellen
Projektkontext bzw. sind nur in
diesem wirklich „best“.
20
BeST-Framework: Ziele, Aufgaben, Methoden
Analyse Architektur Entwicklung
Test Umgebung Projektmanagement
21
BeST beschäftigt sich innerhalb der Domäne Architektur
mit allen Aufgaben des Architekten
Minimierung von
Risiken
Stabilität und
FlexibilitätZie
le Angemessenheit von
Weg und Lösung
Nachvollziehbarkeit
von Entscheidungen
Hohe Qualität der
Lösung
Beschleunigung
(Effizienz und
Effektivität)
Dokumentieren und
Kommunizieren
Au
fga
be
n
Orientierung geben und Leitplanken etablieren
Prüfen und
bewerten
Lösungsarchitektur
entwerfen
Anforderungen
berücksichtigen
Beraten und begleiten
Me
tho
de
n
Anforderungen bewerten,
priorisieren und verfolgen
Rahmenbedingungen und
Einflussfaktoren beachten
Risiken identifizieren und
einschätzen
Lösungsideen entwickeln
Architektur strukturiert
entwerfen
Technische Konzepte ,
Technologien, Produkte
auswählen
Architektursichten
erstellen
Architektur angemessen
dokumentieren
Architektur den Stakeholdern
präsentieren
Architektur im Team etablieren
und entwickeln
Architekturreviews durchführen
(lassen)
Messkriterien für
Architektur definieren
Erfüllung von
Architekturrichtlinien prüfen
Architektur szenarienbasiert
bewerten (lassen)
Architekturprinzipien
festlegen
Architekturstrategie
festlegen
Aufwand schätzen und
Planung unterstützen
Machbarkeit, Kosten und
Nutzen betrachten
Projektsteuerung und –
organisation unterstützen
Implementierung
(beg)leiten
Testbarkeit und Kritikalität
bewerten
Qualitätsziele für
Architektur festlegen
Richtlinien für Entwicklung
festlegen
22
Diese Aufgaben erfordern Abstimmung mit allen
Domänen, d.h. Kommunikation mit allen Stakeholdern.
Architekt
Entwicklerteam
PL / PM
Betrieb
andere
DienstleisterProduktanbieter
CIO / Architekturboard
Fachbereich
Produktmanager
Auftraggeber
Projektteam Kunde
Externe
leitet,
begleitet
berichtet,
unterstützt
berät, klärt,
stimmt ab,
präsentiert,
„verkauft“
wählt aus,
leitet an,
kontrolliert
Architecture is
about People
(Norman Foster)
23
BeST Practice #1 im Sinne der Ganzheitlichkeit:
Alle Aufgabenbereiche des Architekten berücksichtigen!
Ganz viele Hebel der Effizienzsteigerung liegen in den begleitenden Aktivitäten des Architekten neben
dem reinen Entwurf der Lösungsarchitektur – insbesondere beim Management der Anforderungen.!
� Der Architekt tut viel mehr,
als nur die Lösungsarchitektur
zu entwerfen.
� Er ist Jongleur, Diplomat, Berater,
Moderator, Verkäufer, Trainer, …
� ... und insbesondere ist er
derjenige, der die eigentlichen
Kundenanforderungen
herauskitzeln und die
Lösungsarchitektur dazu passend
effizient entwickeln kann.
!
24
Auch höchste Motivation im selbstorganisierten Team ersetzt nicht die
Erfahrung eines Experten.!
BeST Practice #2 für „Beraten und Begleiten“:
Ausgewiesener Architekt als „Architecture Owner“ im Team
Architektur benötigt Erfahrung!
Daher muss der Architekt
begabt sein und
fähig und
bereit zu wissenschaftlich-
theoretischer Schulung. …
(Vitruv)
Architektur ist Teamsache!
Das agile Manifest: Die besten
Architekturen, Anforderungen und
Entwürfe entstehen durch
selbstorganisierte Teams.
Architecture should be a team effort.
(Scott Ambler)
Widerspruch?
Nein!
Architecture Owner
25
Strukturorientierte Herangehensweise an Architektur
Aufgabenorientiert:
Architektur ist,
was ein
Architekt tut.
Strukturorientiert:
Architektur ist,
wie ein System
aufgebaut ist.
26
Grundprinzip und zweite Leitplanke: Angemessenheit im Vorgehen!
Vilfredo Pareto
Pareto-Prinzip
(80-20-Regel)
Aufwand Ertrag
Peter Drucker
Es ist immer wieder
verblüffend, wie viele
Dinge wir tun,
die, wenn wir
sie nicht mehr tun,
keinem abgehen.
Jack Welch
Do first priority
things first,
do second priority
things never.
27
An
aly
se
Arc
hit
ek
tur
En
twic
klu
ng
Test
Um
ge
bu
ng
Pro
jek
tma
na
ge
me
nt
Vorgehensstrategie
BeST-Framework: Wir wählen die Methoden anhand der Projektspezifika
angemessen aus
BeST-Framework
� Mit den Mitteln der
Vorgehensstrategie wird das
konkrete Projektvorgehen
abhängig vom Projektkontext,
d.h. den speziell für das Projekt
geltenden Einflussfaktoren
optimal im Sinne der Effizienz
zugeschnitten
� Dabei werden Methoden der
einzelnen fachlichen Domänen
ausgewählt und spezifisch
zugeschnitten angewendet
� Zusammen mit der Festlegung
des Agilitätsprofils entsteht das
konkrete Vorgehensmodell
BeST-Prinzip
Angemessenheit
28
Agilität ist keine spezielle Methode, kein spezielles Vorgehensmodell.
Agilität ist eine Vorgehens- und Management-Philosophie.
Reicht nicht das „Wundermittel“ Agilität?
vs.
Agil Generalstabsmäßig
Projekte können gar nicht vollständig vorab durchgeplant
und Produkte nicht vollständig vorab spezifiziert werden.
Deswegen muss ein Projekt iterativ umgesetzt werden
und auf Änderungen, die auf jeden Fall kommen werden,
muss flexibel reagiert werden können.
Projekte müssen top-down durchgeplant werden, bevor
sie durchgeführt werden.
Produkte müssen vollständig spezifiziert werden, bevor
sie umgesetzt werden.
Die besten Lösungen entstehen ausselbst organisierenden Teams.
Teams brauchen eine Organisation mit klar definierten Rollen und Zuständigkeiten.
Es herrscht eine Kultur des Vertrauens. Alle relevanten Dinge sind vertraglich zu regeln.
29
Besser: Effizienz und Effektivität, Angemessenheit und Agilität kombiniert
Effizienz und Effektivität erzielen wir durch
Angemessenheit im Sinne einer
situationsgerechten und projektspezifischen Auswahl
aus den verschiedenen Handlungsalternativen:
So agil wie möglich, so generalstabsmäßig wie nötig.
Individuals and interactions over
Working software over
Customer collaboration over
Responding to change over
We have come to value:processes and tools
comprehensive documentation
contract negotiation
following a plan
So viel
wie
möglich
So viel
wie
nötig
Das entspricht auch dem Geist des „Agilen Manifests“
That is, while there is value in the items on the
right, we value the items on the left more
max.
min.
30
Besser: Effizienz und Effektivität, Angemessenheit und Agilität kombiniert
Vollständige Vorab-Planung
Vollständige Vorab-Spezifikation
Strikte Organisation und Rollenteilung
Kein Vertrauen
Agilitätsprofil (Reglermodell)
Keine Vorab-Planung
Keine Vorab-Spezifikation
Vollständige Selbstorganisation
Volles Vertrauen
Jedes Projekt ist anders: Projektkontext und Einflussfaktoren
unterscheiden sich von Projekt zu Projekt.
Entsprechend gibt es für jedes Projekt ein spezifisches optimales Agilitätsprofil im Hinblick
auf Effizienz und Effektivität seiner Durchführung.
31
Jedes Projekt ist anders, aber für quasi alle Projekte gelten einige
grundlegende Erkenntnisse.
Anzahl Projekttypen
Total agil Total generalstabsmäßig
� Grundlegende Aspekte der Planung und Spezifikation sollten in einer
frühen Projektphase vorab festgelegt werden (Basiskonzeption bzw. Envisioning).
Die Entwicklung der Details sollte danach iterativ erfolgen (in Iterationen bzw. Sprints).
� Grundlegende Aufgaben der Planung und Spezifikation sollten von Experten ihres Fachs
durchgeführt oder unterstützt werden, die damit auch Ergebnisverantwortung übernehmen
(z.B. Architecture Owner).
32
(Strukturorientierte) Software-Architektur nach IEEE 1471
Architecture is defined as the fundamental
organization of a system, embodied in its
components, their
relationships to each other
and to the environment,
and the principles governing its design and evolution.
33
Eine kleine Verschärfung hilft, sich auf das Grundsätzliche zu konzentrieren
Architecture is defined as the fundamental
organization of a system, embodied in its
types of components, their
types of relationships to each other
and to the environment,
and the principles governing its design and evolution.
34
In der Unterscheidung zwischen dem Grundsätzlichen und den Details
liegt der Hebel für die Effizienz
All architecture is design but not all design is architecture.
Architecture represents the significant design decisions
that shape a system, where significant is
measured by cost of change.
„Architektur“ „Design“
grundsätzlich
wesentlich
signifikant
teuer zu ändern
die Details
Vorschlag zur Benennung:
Grady Booch
35
Damit folgt „Architektur“ insbes. den nicht-funktionalen Anforderungen.
„Design“ entsteht als deren konkrete Instanziierung und Verfeinerung.
Analyse(in Form von Funktionen,
Aktivitäten, Prozessen, Domänen,
Anwendungsfällen, Services)
Design(Spezifische detaillierte
Komponenten, Beziehungen
und Interaktionen)
Architektur(Arten von Komponenten,
Beziehungen und
Interaktionen)
Referenz-
Architekturen(z.B. Quasar)
Auswahl und
Zuschnitt
Instanziierung und
Verfeinerung
Vom „was“
zum „wie“
Strukturierung
Technologien(z.B. JEE)
Implementierung
Auswahl
System(Code)
Strukturierung
funktional nicht-funktional
Anforderungen(Was Stakeholder wollen)
Auswahl
Auswahl
37
Analogie zum Bauwesen
Ich möchte ein neues Gotteshaus bauen.
Die Gemeinde von Köln soll dort den Gottesdienst
feiern können (funktionale Anforderung).
Im Inneren soll es möglichst hell sein
(nicht-funktionale Anforderung).
Gotische Architektur
(rote Elemente in der Abbildung):• Wir verwenden Spitzbögen, Kreuzrippengewölbe,
Strebewerke und Strebepfeiler
• Kreuzrippen und Strebewerk verwenden wir als
tragende Elemente. Das erlaubt eine Minimierung
der Wandflächen und eine Maximierung der
Fensterflächen. Dadurch wird es hell.
Der Kölner Dom
Design des Kölner Doms
38
Am Beispiel der Software-Entwicklung
Requirements
@Stateless@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class BookManagerImpl implements BookManager {
@PersistenceContextprivate EntityManager em; void edit(Book book);
void destroy(Book book);Book findById(Long id);List findAll();Book create(Book book);List findByTemplate(Book book);
}
Software-System (in JEE)
Software-Architektur (nach Quasar)cd Application Kernel Interactions
«A Component»
Dialog
A-Component 1
A-Component 2 A-Component 3
UseCase 1.1
UseCase 2.1
UseCase 1.2
UseCase 2.2 UseCase 2.3 UseCase 3.1 UseCase 3.2
A-Controller
2.1
A-Entity 2.1
A-Controller
2.2
A-Entity 2.2 A-Entity 2.3
A-Controller
3.1
A-Controller
3.2
A-Controller
3.3
A-Entity 3.1 A-Entity 3.2 A-Entity 3.3
Software-Design
Konkrete A-Komponenten,
A-Fälle, A-Verwalter, A-Entitätenclass Library
datamanagement
borrowing
registration
reminding
accounting
«use case»
Reminding
«use case»
Registration
«use case»
Accounting
«entity class»
Invoice
«use case»
Borrowing
«use case»
BookManagement
«use case»
Search
«entity class»
BookOnStock
«entity class»
Loan
«entity class»
Book«entity class»
Customer
«entity class»
Reminder0..1
-loan
1
*
-customer 1
*
-bookOnStock
1
*
-book 1
ud Library
Accounting Application
Library Application
Librarian
Customer
Accountant
Reminding
Accounting
Borrowing
Registration
Book Management
Search
39
BeST Practice #3 im Entwurf: Sich das Grundsätzliche
explizit anhand der NFAs klar machen
Es ist entscheidend, dass der Architekt die/seine Software-Architektur grundsätzlich
versteht und über die passenden Grundstrukturen zielgerichtet entlang konkreter
nicht-funktionaler Anforderungen entscheiden kann.
Wie viel
brauche ich wirklich
und mit welchen Architekturmustern erreiche ich das?
!
Es soll
hell sein!
Execution Qualities Evolution Qualities
Performance, Security, Usability Testability, Maintainability, Extensibility, Scalability
40
BeST Practice #4 im Entwurf: „Architektur“ vorab und „Design“
immer iterativ – unabhängig vom speziellen Vorgehensmodell
, Sprint IterationBasiskonzeption
Das Wesentliche frühzeitig klären. Die Details dann klären, wenn sie „dran“ sind.!
Iterativ das
„Design“(die Details)
Vorab die
„Architektur“(das Wesentliche)
, Envisioning
41
Strukturorientierte Herangehensweise an Architektur
Aufgabenorientiert:
Architektur ist,
was ein
Architekt tut.
Strukturorientiert:
Architektur ist,
wie ein System
aufgebaut ist.
42
BeST Practice #5 im Entwurf: Separation of Concerns –
Software-Architekturen in mindestens 2 Dimensionen entwerfen
Schicht
Schicht
Schicht
fachliche
Komponente
fachliche
Komponente
fachliche
Komponente
fachliche
Komponente
Für jedes Software-Element (Paket, Klasse, Interface, …) ist somit klar, wo es hingehört.
Technische Schichtenarchitektur haben alle Projekt – dedizierte fachliche
Komponenten aber nur wenige. Dabei ist das mindestens genau so wichtig.!
43
Eine klare Architektur ist damit auch wesentliches Strukturierungsmittel
für die Planung (von Iterationen und Teamgröße/-aufbau etc.)
Beispiel:
Entwicklungsprojekt bei Accso
- Entwicklung von Backend-Services
- 200 PT Aufwand, nur 7 Wochen Zeit
- 9 Mitarbeiter (6 FTE), von 0 aufzubauen
(darunter 3 Erfahrene, 4 Neueinsteiger)
- Agiles Vorgehen (Mischung aus Scrum
und Kanban)
Backlog-Board
Karten = Tasks bezogen auf Schichten
Kartenfarbe = Fachliche Komponente
44
BeST Practice #6 im Entwurf:
Referenzarchitekturen nutzen und zuschneidencd Quasar Architecture
Al ternatives
«Abstract T Component»
Client Management«A Component»
Dialog
«Abstract T Component»
Application Kernel Facade
«A Component»
Application Component
«Abstract T Component»
Authorization
«Abstract T Component»
Transaction
«Abstract T Component»
Persis tence
Al ternatives
Klare Trennung zwischen Architektur von der Implementierungs-
technologie! Referenzarchitekturen enthalten grundlegende rein
architektonische Strukturierungen als Vorlage und „Pattern“.
!
45
BeST Practice #6a im Entwurf: Referenzarchitekturen auf die
speziellen nicht-funktionalen Anforderungen zuschneiden
Beispiel: Quasar
- z.B. bei reduzierten Anforderungen an Oberflächenkomplexität
- z.B. bei reduzierten Anforderungen an Plattformunabhängigkeit
- z.B. bei reduzierten Anforderungen an die Komplexität der Geschäftslogik
- z.B. bei reduzierten Anforderungen an Technologieunabhängigkeit
(Einlassen auf moderne Enterprise Technologien wie JEE oder .NET)
Der Trade-Off
zwischen Anforde-
rungen und
architektonischer
Komplexität muss
explizit erfolgen.
Das benötigt viel
Erfahrung.
!
46
Softwarearchitektur:
Das ist die Königsdisziplin
des Software-Engineering.
Ernst Denert(im Vorwort zum „Quasar“-Buch)
47
aber
48
Lassen Sie uns in Kontakt bleiben …
• www.accso.de
• twitter.com/accso
• Facebook• blog.accso.de
Begeisterung für die
anspruchsvollen Aufgaben unserer Kunden
Individuelle
Kernsysteme
Beschleunigte
SoftwaretechnikTeam≡≡≡≡