Grundbegriffe von Softwarearchitektur

Definition

Es befinden sich zahlreichen Definitionen von Softwarearchitektur. Wir beschränken uns deshalb nur auf zwei davon:

1. Die grundlegenden Konzepte oder Eigenschaften eines Systems in seiner Umgebung, verkörpert in seinen Elementen, Beziehungen und in den Prinzipien seines Designs und seiner Entwicklung. (ISO/IEC/IEEE 42010)
2. Die Softwarearchitektur einer Software oder Computersystems ist die eine oder mehrere Strukturen des Systems, welche die Softwareelemente, die extern sichtbaren Eigenschaften dieser Elemente und die Beziehungen zwischen ihnen, umfassen. (Bass, Clements, Kazman Software Architecture in Practice, Addison Wesley, 2003.) 

Aufgaben von Softwarearchitekten

Softwarearchitekten haben die Aufgabe die Softwarearchitektur aktiv zu gestalten und ihre Umsetzung und Wirksamkeit sicherzustellen. Dabei sollen sie im Wesentlichen die folgenden Ziele in einem Projekt erreichen:

• Unterstützung von Entwurf, Implementierung, Pflege und Betrieb des Systems
• Erfüllbarkeit der funktionalen Anforderungen sicherstellen
• Qualitätsanforderungen in gewünschtem Maße erreichen
• Komplexität systematisch reduzieren
• Architekturrelevante Richtlinien für Implementierung und Betrieb spezifizieren

Die Arbeit eines Architekten kann dabei in sechs Tätigkeiten gegliedert werden:

• Anforderungen klären
• Strukturen entwerfen
• Querschnittskonzepte erstellen
• Architekturen bewerten
• die Umsetzung begleiten
• Architekturen kommunizieren

Der erste Schritt „Anforderungen klären“ stellt dabei die Schnittstelle unter anderem zum Requirements Engineering dar. Hierbei probiert der Architekt herauszufinden, welche Anforderungen architektonisch relevant sind.

ASR: Architektonisch bedeutende Anforderungen

Architecturally Significant Requirements (ASRs) umfassen die wichtigsten architektonischen Anforderungen. Dabei ist es egal, ob es sich um Funktionale oder nicht Funktionale Anforderungen handelt. Somit sind ASRs Anforderungen, die sich direkt auf das Architekturdesign auswirken.

Ein Architekt sollte alle NFRs mit den Stakeholdern abgestimmt und dokumentiert haben. Es ist üblich, dass eine funktionale oder nichtfunktionale Anforderung in unterschiedlichen Phasen des Software-Lebenszyklus den Status einer ASR erlangen oder verlieren kann.

Sein Entwurf und insbesondere seine Entwurfsentscheidungen sollten daher transparent machen auf Basis welcher ASRs eine Entscheidung oder ein Entwurf beruht, um Nachvollziehbarkeit zu erlangen und eine wirksame Architektur sicherzustellen.

Um diese zu erreichen, sollen Softwarearchitekten diese Anforderungen stets überprüfen und die Unterschiede und Besonderheiten erklären. Insbesondere der PO, RE und BA, aber auch andere Akteure, sollten für ein besseres Verständnis und eine bessere Kommunikation sensibilisiert werden .

Einige gängige Quellen für ASRs sind,

• Anforderungsdokumentation (z.B. Product Backlog)
• Vereinbarung zum Servicelevel (SLA)
• Fachwissen
• Anwendbare Standards, Richtlinien oder Richtlinien

 Solange ASRs in der Dokumentation vorhanden sind, können sie von Softwarearchitekten analysiert und verbessert werden. Sind sie jedoch nicht oder unvollständig dokumentiert, so besteht das Risiko einer unwirksamen Architektur. Eine unwirksame Architektur ist nicht in der Lage die funktionalen und nichtfunktionalen Anforderungen zu erfüllen und stellt nicht nur ein signifikantes Projektrisiko dar, sondern ist mit fortschreitender Projektlaufzeit zudem teuer zu ändern.

Architecturally Significant Requirements (ASRs) müssen deshalb Vorrang bei der Identifizierung und Dokumentation haben, um das Architekturdesign in die richtige Richtung zu leiten.

Agile Requirements Engineering

Wie bereits zuvor etabliert sollen Anforderungen nicht nur korrekt erhoben werden, sondern auch verständlich kommuniziert und ihre Erreichung geprüft werden. Dabei sind Anforderungen stetig um Wandel und bedürfen Pflege.

Agile Requirements Engineering ist ein kooperativer, iterativer und inkrementeller Ansatz, der dies erreichen soll. Er gliedert sich groß in zwei Phasen: Die Definitionsphase (Anforderungserstellung) und die eigentliche Umsetzungsphase (Entwicklung). Im Gegensatz zu den herkömmlichen Vorgehensweisen laufen die beiden Phasen, Definition und Implementierung, parallel ab.

Daraus ergeben sich viele Vorteile. Zu diesen Vorteilen gehört die schnelle und flexible Reaktion auf veränderte oder neue Gegebenheiten.

Dies wird dadurch gewährleistet, dass die Anforderungsbeschreibung nie abgeschlossen und während der gesamten Entwicklungsdauer ständig neu erfasst und angepasst wird. Das heißt, wenn einzelne Aspekte eines Prozesses von den akzeptablen Grenzen abweichen oder das resultierende Produkt nicht akzeptabel ist, muss der Prozess oder die erzielten Ergebnisse angepasst werden. Eine Anpassung sollte so schnell wie möglich erfolgen, um weitere Abweichungen zu reduzieren. Dieser Ansatz folgt vier Zielen:

1. Kenntnis der relevanten Anforderungen auf einem angemessenen Detaillierungsgrad (zu jedem Zeitpunkt während des Systementwicklungsprozesses).
2. Ausreichende Übereinstimmung über Anforderungen unter den Stakeholdern erreichen.
3. Erfassen und Dokumentieren der Anforderungen gemäß der Einschränkungen und Vorgaben der Organisation.
4. Durchführung aller anforderungsbezogenen Aktivitäten gemäß den Prinzipien des agilen Manifests.

Requirements Engineering Aktivitäten sind sehr weit gefächert und von der Art des zu entwickelnden Systems und der Organisationsspezifikation abhängig. Nichtsdestotrotz gehören auch im agile Requirements Engineering folgende vier zentrale Tätigkeiten, die von IREB etabliert wurden, dazu:

 

• Anforderungserhebung: Die Anforderungen werden anhand unterschiedlicher Methoden möglichst effizient, vollständig und fehlerfrei ermittelt. Auch Detaillierung und Verfeinerung gehören dazu.
• Anforderungsdokumentation: Die Anforderungen müssen adäquat und qualitativ hochwertig beschrieben werden, um die Anforderungsspezifikation mit allen relevanten Anforderungen entstehen zu lassen.
• Anforderungsprüfung und -abstimmung: Die Anforderungsspezifikation wird auf ihre Gesamtqualität geprüft. Dazu gehört auch die inhaltliche Abstimmung mit den Stakeholdern.
• Anforderungsverwaltung: Auch Anforderungsmanagement genannt, geht es bei der Verwaltung der Anforderungen darum, sie zur Nutzung bereitzustellen, die Versionsstände zu pflegen, eine Priorisierung zu erstellen, etc.

Der Unterschied zwischen Requirements Engineering und Requirements Management

 Die Begriffe Requirements Engineering und Requirements Management werden oft fälschlicherweise als Synonym verwendet. Wenn man von einem ganzheitlichen Requirements-Engineering-Ansatz spricht, muss man das streng genommen immer im Sinne des Anforderungsmanagements tun. Rückblickend auf die bereits genannten vier zentralen Aktivitäten bezieht sich Requirements Engineering hauptsächlich auf die ersten drei Punkte. Requirement Engineering, was ins Deutsche übersetzt wird, bedeutet Anforderungsmanagement und umfasst damit die vierte zentrale Aktivität.

Die beiden Fachtermini sind jedoch untrennbar miteinander verbunden und gehen Hand in Hand mit Requirements Management: Ohne Ermittlung gibt es keine Verwaltung und ohne effiziente Verwaltung und Aufbereitung hat die Ermittlung von Anforderungen keinen Nutzen.

Die Product Owner (PO), Business Analyst (BA) und Requirements Engineer (RE) Rollen

 Agiles Requirements Engineering geschieht nicht ad-hoc, sondern über unterschiedlichen Rollen. In der Praxis kommt es oft vor, dass es nur eine Rolle gibt (wie PO, BA, RE oder alle zusammen). Unabhängig davon wie viele Rollen in der Praxis vorhanden sind, kann die Unterteilung genutzt werden, um die unterschiedlichen Tätigkeiten und Verantwortlichkeiten des Requirements Engineering und Management gewinnbringend zu gliedern und die eigene Arbeit zu strukturieren.

Der Product Owner ist für die Wertsteigerung, genauer gesagt die Rentabilität (= ROI, Return of Investment) verantwortlich, nicht nur was das Produkt angeht, sondern auch in Bezug auf das Projektteam. Es handelt sich also um eine anspruchsvolle Aufgabe. Hierbei sind ihm drei zentrale Aufgaben zugeordnet:

1. Vertretung der Kundeninteressen
2. Zusammenarbeit mit dem Entwicklungsteam und Scrum Master
3. Verwaltung des Product Backlogs

Dabei sollte er die richtige Funktionalität in der richtigen Priorität ins Projekt bringen. Daraus abgeleitet sollte er die folgenden Skills und Aufgaben meistern können:

• Stakeholder Analyse
• Erhebungstechniken
• Konfliktmanagement
• Priorisierung (z.B. Priority Poker)

Ähnlich zur PO-Rolle sollte der Business Analyst (BA) über Kreativitäts- und Erhebungstechniken verfügen. Zudem unterstützt er den Product Owner bei der Erhebung fachlicher Anforderungen, deren Akzeptanzkriterien und der Prüfung, ob und wie die Anforderungen zu den Geschäftsprozessen passen.

Zu guter Letzt kümmert sich der Requirements Engineer (RE) für die nachhaltige Spezifizierung von Anforderungen und ihre Übersetzung in das technische Umfeld.

Alle drei Rollen sollten über die folgenden Skills verfügen:

• Stakeholder Analyse
• Kreativitätstechniken
• Erhebungstechniken (typischerweise mittels Befragung, Design Thinking, Persona usw.),
• Dokumentationstechniken
• Modellierung (typischerweise mittels UML)
• Priorisierung von Anforderungen

Alle diese Skills können je nach Bedarf und Aufgabengebiet verwendet werden.

 

Welche verschiedenen modernen Techniken in Requirement Engineerings eingesetzt werden können, sehen wir uns im nächsten und letzten Teil der Blog-Serie an. Wir freuen uns schon Sie wiederzusehen.

 

Quellen

• Sommerville, Ian (2009). Softwareengineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
• Andreas Wintersteiger, Scrum Schnelleinstieg
• McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN 9780134686653.
• https://t2informatik.de/
• North, Introducing Behaviour Driven Development
• Dan North et al.: Question about Chapter 11: Writing software that matters. (Nicht mehr online verfügbar.) Archiviert vom Original am 7. November 2009; abgerufen am 9. November 2011 (englisch): „The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition“
• Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
• “Lessons learned: Using Scrum in non-technical teams”. Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
• Ken Schwaber; Jeff Sutherland. “The Scrum Guide”. Scrum.org. Retrieved October 27, 2017.
• https://www.scrum.org/
• http://agilemanifesto.org/
• https://www.isaqb.org/
• https://swissq.it/agile/die-rollen-des-po-re-und-ba-im-vergleich/

 

 

Abbildungen

Abbildung 9: https://media.geeksforgeeks.org/wp-content/uploads/20200704172739/Untitled-Diagram160.png

Einführung und Überblick

Requirements Engineering und Softwarearchitektur sind in der Welt der Softwareentwicklung Tätigkeitsbereiche, die große Teilverantwortungen tragen, um Softwareentwicklungsprojekte erfolgreich abzuschließen. Letztlich geht es darum, die Kundenbedürfnisse zu erfüllen und den Kunden zufrieden zu stellen. Um dies zu erreichen, muss man den Kunden richtig verstehen und wissen, was er tatsächlich braucht.
In diesem Stadium sind Anforderungen und deren Management Hauptakteure im Softwareentwicklungsprozess .
Anforderungen sind in Softwareprojekten das Abbild der Kundenwünsche. Sie dienen als zentrale Briefings für fast alle weiteren Tätigkeiten. Die korrekte Erhebung, Erfassung, Überprüfung, Pflege und Verfeinerung von Anforderungen beeinflusst folglich den gesamten Software-Lebenszyklus und ist somit entscheidend für den Erfolg von Softwareentwicklungsprojekten.
Im Software-Lebenszyklus sind die Phasen der Anforderung und der Softwarearchitektur direkt aufeinander folgend und daher besonders stark miteinander verzahnt, fehlerhaftes Anforderungsmanagement hat dementsprechend direkte, schwerwiegende Folgen auf architektonische Entscheidungen.

An dieser Stelle geht es nicht nur darum, dass der Requirements Engineer oder der Product Owner die richtigen Anforderungen (von den Kunden) aufgenommen hat, vielmehr geht es darum, dass der Softwarearchitekt den Product Owner richtig versteht und die von ihm bereitgestellten Anforderungen überprüft und analysiert, um darauf aufbauend seine architektonische Entscheidung treffen zu können.
In den folgenden Abschnitten geben wir einen Überblick über Anforderungsmanagement und Softwarearchitektur, bzw. wie sie sich einander ergänzen und gegenseitig beeinflussen. Dazu betrachten wir die beiden Rollen des Softwarearchitekten und eines Product Owners, sowie ihre Verantwortlichkeiten und Aufgaben in Softwareentwicklungsprojekten. Zuvor klären wir einige Grundbegriffe.

Arten von Anforderungen

In der Literatur gibt es viele Unterteilungen oder Klassifizierungen von Anforderungen. Zum Zwecke dieses Inhalts betrachten wir nur zwei (bekannte) Hauptkategorien, funktionale (FR) und nicht-funktionale Anforderungen (NFR).
Nichtfunktionalen Anforderungen fallen wiederum in zwei Kategorien: Die Qualitätsanforderung oder Qualitätskriterien und die Einschränkungen (eng. constraints)

Funktionale Anforderungen

Das „WAS“ legt die Funktionale Anforderungen fest, was das Produkt tun soll. Ein Beispiel:
„Das System soll die geleisteten Arbeitsstunden eines Mitarbeiters für einen bestimmten Zeitraum berechnen.“
Das bedeutet, dass sich die funktionalen Anforderungen lediglich auf die Verhaltensergebnisse beziehen, die die Funktionalität des Systems oder der Software liefern soll.

Nichtfunktionale Anforderungen (NFRs)

Die nicht-funktionalen Anforderungen (NFR) beschreiben, wie gut das System die Leistung erbringen soll und unter welchen Rahmenbedingungen und sind eine Herausforderung für jeden PO. Sie werden typischerweise in zwei Bereiche untergliedert:
• Qualitätskriterien
• Einschränkungen

Qualitätskriterien

… sind Anforderungen, die sich auf ein Qualitätsproblem beziehen, das nicht durch funktionale Anforderungen abgedeckt ist.
Diese werden (z.B. nach Volere) in Ausführungsqualität und Weiterentwicklungsqualität gegliedert.

Ausführungsqualität (während des Betriebs / zur Laufzeit)

• Zuverlässigkeit (Systemreife, Wiederherstellbarkeit, Fehlertoleranz)
• Aussehen und Handhabung (Look-and-feel)
• Benutzbarkeit (Verständlichkeit, Erlernbarkeit, Bedienbarkeit)
• Leistung und Effizienz (Antwortzeiten, Ressourcenbedarf, Wirtschaftlichkeit)

• Sicherheitsanforderungen (Vertraulichkeit, Informationssicherheit, Datenintegrität, Verfügbarkeit)
• Korrektheit (Ergebnisse fehlerfrei)

Weiterentwicklungs- und Evolutionsqualität

• Betriebs- und Umgebungsbedingungen
• Wartbarkeit, Änderbarkeit (Analysierbarkeit, Stabilität, Prüfbarkeit, Erweiterbarkeit)
• Portierbarkeit und Übertragbarkeit (Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit)
• Flexibilität (Unterstützung von Standards)
• Skalierbarkeit (Änderungen des Problemumfangs bewältigen)

Eine andere Aufteilung von Nichtfunktionalen Anforderungen findet man in der ISO 25010. Hier werden die Qualitätsanforderungen anhand 8 Kriterien beschrieben.

Einschränkungen

… sind Anforderungen, die den Lösungsraum über das hinaus beschränken, was zur Erfüllung spezifizierter funktionaler Anforderungen und Qualitätsanforderungen erforderlich ist.

Es gibt verschiedene Arten von Einschränkungen, z.B. zeitliche Terminplanbeschränkung, regulatorische oder gesetzliche Beschränkungen usw.

In Softwareprojekten spricht man von Einschränkungen, wenn Faktoren wie Zeit, Geld, Umfang (das sogenannte „Magische Dreieck“) oder Ressourcen, wie Ausrüstung oder Personalmangel das Projekt beeinflussen.

 

Die Einschränkungen hängen auch von dem Tätigkeitsbereich des Unternehmens sowie den Dienstleistungen ab, welches es anbietet.

Im Gesundheitswesen beispielsweise können bestimmte Vorschriften oder Gesetze die Qualität von Software oder sogar die Implementierung der gesamten Softwarearchitektur beeinträchtigen.

Aus allen diesen Gründen ist es wichtig, dass sich der Softwarearchitekt bereits zu Beginn des Projekts mit den verschiedenen Einschränkungen auseinandersetzt und mit den Key Rollen abklärt.

 

Wir freuen uns schon, Sie beim nächsten Artikel unserer Blog-Serie wieder begrüßen zu dürfen – dem Agile Requirements Engineering und seine Rollen.

 

Quellen

• Sommerville, Ian (2009). Softwareengineering (9th ed.). Addison-Wesley. ISBN 978-0-13-703515-1.
• Andreas Wintersteiger, Scrum Schnelleinstieg
• McGreal, Don; Jocham, Ralph (June 4, 2018). The Professional Product Owner: Leveraging Scrum as a Competitive Advantage. Addison-Wesley Professional. ISBN 9780134686653.
• https://t2informatik.de/
• North, Introducing Behaviour Driven Development
• Dan North et al.: Question about Chapter 11: Writing software that matters. (Nicht mehr online verfügbar.) Archiviert vom Original am 7. November 2009; abgerufen am 9. November 2011 (englisch): „The phrase ‘BDD is TDD done well’, while a nice compliment, is a bit out of date. […] BDD has evolved considerably over the years into the methodology we describe in the book. Back when it was focused purely on the TDD space– around 2003-2004 – this was a valid description. Now it only covers a small part of the BDD proposition“
• Schwaber, Ken; Sutherland, Jeff (November 2017), The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game, retrieved May 13, 2020
• “Lessons learned: Using Scrum in non-technical teams”. Agile Alliance. May 18, 2018. Retrieved April 8, 2019.
• Ken Schwaber; Jeff Sutherland. “The Scrum Guide”. Scrum.org. Retrieved October 27, 2017.
• https://www.scrum.org/
• http://agilemanifesto.org/
• https://www.isaqb.org/
• https://swissq.it/agile/die-rollen-des-po-re-und-ba-im-vergleich/

 

Abbildungen

Abbildung 1: https://cdn-images-1.medium.com/max/1200/1*ApoaIZicyU0b7Jgg9MMJhw.jpeg

Abbildung 2: ITech Progress CPSA-Foundation Kurs (Präsentation) – Kapitel 1: Grundbegriffe – Einordnung der Softwarearchitektur in Software-Lebenszyklus

Abbildung 3: https://www.softwareone.com/-/media/global/social-media-and-blog/content/requirements-engineering-4-graph1.png?mw=1024&rev=bc1dea2cb4d145c79f1f5b544e3a10cd&sc_lang=de-at&hash=43114D2C3FE79F36503891506BDBA9FA

Abbildung 4: https://www.nasa.gov/images/content/549928main_jfk_speech_226.jpg

Abbildung 5: https://www.nasa.gov/sites/default/files/styles/side_image/public/62297main_neil_on_moon_full.jpg?itok=1c8GTfbJ

Abbildung 6: https://miro.medium.com/max/1762/0*ohypH8bVpf2O0uIc.png

Abbildung 7: https://www.researchgate.net/profile/Lina-Garces/publication/326584873/figure/fig2/AS:652083346808834@1532480193500/Standard-ISO-IEC-25010-Software-product-quality-model-and-system-quality-in-use-model.png

Abbildung 8: https://i.pinimg.com/originals/a1/3c/ed/a13cedd07eb87e2fab0baa483d9877fd.png