Lehrplan „Grundlagen der Software- Architektur“ - bei BITPlan!
Lehrplan „Grundlagen der Software- Architektur“ - bei BITPlan!
Lehrplan „Grundlagen der Software- Architektur“ - bei BITPlan!
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Lehrplan</strong> <strong>„Grundlagen</strong> <strong>der</strong> <strong>Software</strong>-<strong>Architektur“</strong><br />
Bewertung<br />
Wie wäge ich meine Architekturentscheidungen<br />
ab?<br />
60<br />
Eine Architektur zu definieren ist, das Finden des „besseren Übels“. Ähnlich wie <strong>bei</strong> <strong>der</strong> Erstellung<br />
eines fachlichen Modells gibt es Wi<strong>der</strong>sprüche zwischen Anfor<strong>der</strong>ungen. Wo sich in diesem Falle<br />
Anwen<strong>der</strong> (Stakehol<strong>der</strong>) noch relativ einfach einigen können, da sie sich in ihrer Domäne befinden<br />
und damit eine Entscheidung gut abwägen können, ist diese Kompromissfindung im Rahmen <strong>der</strong><br />
Architekturerstellung sehr viel schwieriger. Die Lösung einer Anfor<strong>der</strong>ung kann <strong>der</strong> an<strong>der</strong>en zunächst<br />
wi<strong>der</strong>sprechen. Ein geeigneter Kompromiss ist zu finden.<br />
Hier werden die noch offenen Fragen „Wie wäge ich meine Architekturentscheidungen ab? Welche<br />
Kriterien gibt es? Wie viel Zeit sollte ich wann verwenden? Wann ist eine Architektur gut, wann richtig?“<br />
geklärt.<br />
Die Priorisierung von Anfor<strong>der</strong>ungen hilft das Wichtige vom weniger Wichtigen zu trennen. Nicht das<br />
Thema, das für den Professional for <strong>Software</strong> Architecture spannend ist, ist das wichtigste, son<strong>der</strong>n<br />
das, das dem Anwen<strong>der</strong> am meisten <strong>bei</strong> seiner Lösung hilft und wofür er zu zahlen bereit ist.<br />
Die meisten Entscheidungen können nicht auf dem Papier getroffen werden. Das Vorgehen des<br />
„Durchstichs“ (Proof of concept) hat sich bewährt. Die entscheidende Frage, „was muss gehen, damit<br />
die Architektur funktioniert?“ wird geklärt. Mit (verhältnismäßig) wenig Aufwand wird eine hohe<br />
Sicherheit für die weitere Ar<strong>bei</strong>t erzielt.<br />
Der Professional for <strong>Software</strong> Architecture for<strong>der</strong>t die Stakehol<strong>der</strong> auf, die Vielzahl von Anfor<strong>der</strong>ungen<br />
zu priorisieren. Am Ende einer Iteration steht ein lauffähiges System o<strong>der</strong> zumindest ein Durchstich<br />
mit diesen Funktionen.<br />
Beim Abwägen mehrerer Lösungen klärt <strong>der</strong> Professional for <strong>Software</strong> Architecture die Fragen:<br />
• Kann damit die Anfor<strong>der</strong>ung erfüllt werden?<br />
• In welchem Maße?<br />
• Zeichnet sich eine Lösung beson<strong>der</strong>s aus?<br />
• Wie zukunftssicher ist die Lösung?<br />
• Welche Folgen hat die Lösung?<br />
• Sind für die Stakehol<strong>der</strong> die Folgen nützlich/unwichtig/unakzeptabel?<br />
v1.0 Seite 31 von 46<br />
© iSQI – Veröffentlichung, auch auszugsweise, nur mit schriflicher Genehmigung
Change language