OOP 2024 – wir sind dabei!

OOP 2024 – wir sind dabei!

OOP digital 2024 – wir sind dabei!

H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH

Es ist gut, unseren Geist gegen den von anderen zu reiben und zu polieren.

Michel Eyquem de Montaigne

Wir blicken auf eine Woche voller interessanter und bereichernder Gespräche bei der OOP in München zurück!

Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.
H. Tiemeyer präsentiert die Kernkompetenzen der ITech Progress GmbH
Was ist die OOP? SOFTWARE MEETS BUSINESS – eine führende Fachkonferenz für Softwarearchitekten mit angeschlossener Messefläche die immer Januar in München stattfindet. Immer? Dies war das erste Jahr nach der Pandemie in dem die Messe wieder zu gewohnter Zeit stattfand. Sie ist der ideale Ort, um auf dem Laufenden zu bleiben, Inspiration zu sammeln und wertvolle Kontakte zu knüpfen.
Neben neuen Kontakten haben wir uns aber auch insbesondere gefreut, alte Bekannte widerzutreffen – es ist einfach ein grandioser Event des Austausches!
Ein besonderes Highlight am Stand war natürlich das Gewinnspiel für eine iSAQB-lizensierte Schulung!
Holger Tiemeyer steht während seinem Vortrag auf der Bühne. Hinter ihm ist die Präsentation auf einer Leinwand zu sehen.

Wir freuen uns jetzt schon auf nächstes Jahr!

Requirements for Software Architects

Requirements for Software Architects

Requirements for Software Architects

Moderne Techniken des Requirement Engineerings

 

Herzlich Willkommen zum letzten Teil unserer Blog-Serie, in der wir moderne Techniken des Requirement Engineerings vorstellen.

Techniken

Wir haben nun erklärt, worum es sich bei Anforderungen handelt und wie die Reise einer Anforderung von Erhebung bis zur Architektur aussieht und wer daran beteiligt ist. Wir haben auch gesehen, welche Risiken damit einhergehen, wenn Anforderungen nicht genügend Aufmerksamkeit entgegengebracht wird.
Im Folgenden möchten wir nun einige Techniken aufzeigen, welche die Arbeit mit Anforderungen vereinfachen oder verbessern können.

Agile Techniken zum Erstellen, Pflegen und Priorisieren von Funktionalen Anforderungen
Produktvision

Die Produktvision ist das langfristige Ziel, das ein Unternehmen anstrebt. Ziel ist es, ein Produkt zu schaffen, das einen Zweck erfüllt. Produktvision beschreibt, was herauskommen soll also das „Was“.

Eine von den besten und klar ausformuliertesten Visionen stammt von J.F. Kennedy – die erste Mondlandung.

 President Kennedy speak to Congress on May 25th, 1961

Commander Neil Armstrong working at an equipment storage area on the lunar module, Credits: NASA

Ein Team mit einer guten, klaren, greifbaren Produktvision kann ein besseres Produkt entwickeln als ein Team ohne Vision oder nur mit einer vagen Vorstellung davon, wohin die Reise gehen soll.

Stakeholder Analyse

Es ist einer der wichtigsten Aufgaben eines Product Owners (BA, RE), als auch des Softwarearchitekten, diejenigen zu identifizieren, die in einem Projekt involviert sind. Es gibt viele verschiedene Methoden für die strukturierte Stakeholder Analyse. Zur gezielten Stakeholder-Identifikation kann die Stakeholder Matrix ungemein helfen:

Stakeholder Gewichtung – Wie behandle ich meine Stakeholder?

Überwachung (geringes Interesse, geringe Einfluss und somit Auswirkung):

Diese Stakeholder sollten gezielt informiert werden, ohne mit ihnen unrelevante Informationen zu teilen. Eine sorgfältige Abstimmung der Kommunikation mit diesen Partnern ist notwendig, um Relevanz sicherzustellen.

Zufriedenstellen (viel Einfluss, geringes Interesse):

  • Es ist wichtig, ausreichend Zeit in diese Anspruchsgruppen zu investieren, um ihre Zufriedenheit zu gewährleisten, ohne jedoch ein Gefühl der Überlastung zu erzeugen.

Informieren (geringe Wirkung, hohes Interesse):

  • Informieren Sie diese Stakeholder entsprechend. Und sammeln Sie relevante Daten, um größere Probleme zu vermeiden. Stakeholder dieser Kategorie stehen Projektdetails oft kritisch gegenüber.

In engem Kontakt bleiben (hohe Wirkung, hohes Interesse):

  • Diese Stakeholder sind Hauptakteure. Sie sollten vollständig in das Projekt eingebunden werden. Nehmen Sie sich genug Zeit, um sie zufrieden zu stellen.
Persona

Mithilfe von Personas versucht man einen bestimmten Anwendertyp zu beschreiben. Dabei versetzt man sich in die Person hinein, um seine Situation zu verstehen und daraus seine Bedürfnisse zu definieren. Eine Persona ist ein gutes Mittel, um Anforderungen zu erheben. Ihre Nutzung ist oft sinnvoll, wenn Kundenbefragungen (ein Werkzeug für die Anforderungserhebung) unmöglich sind. Zudem wird Persona bei großen Produkten/Systemen genutzt, die von einer breiten Gruppe Endnutzern bedient werden.

Beispiel:

Herr Mathias ist 45, verheiratet und hat zwei Kinder. Er arbeitet als Qualitätsbeauftragter für die Bundesagentur für Arbeit. Er fährt jeden Morgen Zug von Mannheim nach Frankfurt und ist stolz darauf, seit 15 Jahren einen bedeutenden Beitrag zur Effizienz und Wirksamkeit der Agentur geleistet zu haben. In seiner Freizeit verbringt er Zeit mit seinen Freunden in einer Gaststätte in der Altstadt, wo sie lebendige Gespräche führen und gemeinsame Interessen teilen.

In diesem Beispiel ist die Beschreibung der Persona kürzer gehalten. In der Praxis kann diese eine komplette Seite befüllen. Wichtig bei der Verfassung von Personas ist die Empathie, also die Berücksichtigung von besonderen Details und Emotionen. Nur so kann man einen Kunden oder Endnutzer richtig verstehen.

Agile Techniken zum Dokumentieren von Anforderungen
Anwendungsfälle (Use Cases)

Use Cases beschreiben eine Anforderung oder Features eines Produktes aus Kundensicht.

Ziel ist, eine (erste) Beschreibung der Funktionalität des zu entwickelnden Produkts in der Sprache des Kunden zu bekommen.

Das hat einige Vorteile:

  • Kundenbedürfnisse können besser und richtig verstanden werden, da sie in seinen eigenen Worten ausgedrückt werden
  • Es ist eine gute Entscheidungsbasis für die Priorisierung von Anforderungen
  • Missverständnisse verringern sich, sodass keine unerwünschten Anforderungen in das Produkt aufgenommen werden.
  • Scope: Nur das aufzunehmen, was auch zum System gehören sollte

Nach der Festlegung der verschiedenen Anwendungsfälle, die vom Kunden oder mit ihm zusammen formuliert wurden, können diese Anwendungsfälle weiter detailliert und verfeinert werden.

An dieser Stelle kommen Use Case Dokumente (Name des Anwendungsfalls, Vorbedingungen, Normalablauf, Alternativablauf, Nachbedingungen) und UML (z.B. Anwendungsfall Diagramm, Aktivitätsdiagram) ins Spiel, um die Anforderungen an das System zu verdeutlichen und zu visualisieren. In den weiteren Schritten (Softwarearchitekten Rolle) kommen auch weitere Diagramme zur Darstellung und Definition von internen Strukturen und Abläufen, um die Softwarearchitektur zu visualisieren.

User Stories

User Stories (Nutzergeschichten) sind prägnante Beschreibungen eines Features aus Anwendersicht. Wichtig dabei ist, dass sie in ein bis zwei Sätzen formuliert werden.

Die Story soll erzählen, warum der Anwender eine bestimmte Funktionalität benötigt und welche Ziele oder Nutzen er damit erzielen kann. Im Gegensatz zu den klassischen Techniken im Requirements Engineering gibt die User Story nicht die Lösung vor, wie das Feature umgesetzt wird, sondern nur das, was umgesetzt (benötigt) wird. In einer User Story wird kein „Wie“, sondern nur das „Was“ beschrieben. Dokumentiert werden sollte von der User Story der Hintergrund, Begründung, Ziele oder Nutzen, warum dieses bestimmte Feature implementiert werden soll.

Im agilen Umfeld hat sich ein Satz-Musteretabliert, dass es immer drei Hauptelemente sind, die den Wert einer Funktionalität in ihrer Nutzung abbilden: Rolle, Feature und Begründung (Wert/Nutzen usw.).

Die Formulierung kann wie folgt aussehen:

Als <Rolle> möchte ich <Feature>, weil <Begründung>

Als <Rolle> möchte ich <Feature>, um <Nutzen / Wert> zu bekommen.

 

Beispiele:

  1. Als pendelnder Passagier möchte ich häufig gebuchte Zugsstrecken möglichst schnell wieder buchen können, um Zeit beim Buchen zu sparen.
  2. Als Personalleiter möchte ich die beantragten Urlaubsanträge direkt im System unterschreiben können, um den Urlaub genehmigen zu können, ohne die Urlaubsanträge herunterladen zu müssen.
Agile Techniken zur Spezifikation von User Stories
Story Mapping

Priorisierung von Anforderungen und die Pflege von Product Backlog Einträgen (=PBI Product Backlog Items) gehören zu den alltäglichen Aufgaben eines Product Owners. Story Mapping ist ein sehr gutes Werkzeug, um diese Herausforderung zu meistern.

Die Methode kann man sowohl zu Beginn, um überhaupt User Stories ableiten zu können, als auch während des Entwicklungsprozesses verwenden. Da es im agilen Umfeld in jedem Falle iterativ und schrittweise entwickelt wird, werden nach jedem Kundenfeedback oder erforderlichen Anpassung neue User Stories entstehen.

Eine Story Map besteht aus zwei Dimensionen (horizontale und vertikale). In der ersten horizontalen Dimension stehen die groben Anforderungen. In der zweiten vertikalen Dimension werden diese Anforderungen verfeinert. Je tiefer man geht, desto mehr nimmt der Detaillierungsgrad zu. Ziel ist es, eine Anforderung aus Sicht des Kunden in verfeinerten und kleinen Tasks zu zerlegen, um diese dann umsetzen zu können. Das Story Mapping kann daher auch als Verwaltungstechnik verstanden werden.

 

Agile Techniken zur Verwaltung von Anforderungen
Epics

Die erstellten User Stories kann man jetzt (oder alternativ in einem Schritt vorher) in Epics zusammenfassen. Diese Epics gruppieren zusammenhängende User Stories. Dabei erfolgt die Zusammenfassung zum Beispiel basierend auf übergeordneten Geschäftszielen oder der Möglichkeit, sie als eigenständige, bepreiste Dienstleistungen anzubieten. Zum Beispiel könnten User Stories wie „Antragstellung für Kindergeld“, „Antragsprüfung durch Sachbearbeiter“ und „Kindergeldauszahlung“ unter dem Epic „Kindergeldverwaltung“ gebündelt werden.

Vorteile:

  • Divide et impera“: Das gesamte zu entwickelnde System kann zu Beginn des Projektes in Teilbereiche erfasst werden.
  • Projektstrukturierung, das heißt, es können Teile des Systems zu Projektbeginn abstrakt beschrieben werden, ohne früher ins Detail gehen zu müssen.
  • Ein wichtiger Vorteil bei der Verwendung von Epics ist die Kontrolle über das Fachkonzept oder Product Backlog (User Stories Liste). Ansonsten kann man bei größeren Projekten, verbunden mit einem Product Backlog mit hunderten User Stories, schnell den Überblick verlieren.
Techniken zur Identifikation von architekturrelevanten Anforderungen

Einige der effektivsten Methoden, um ASRs zu ermitteln, sind:

  • Fragebogen / Checkliste
  • Stakeholder-Befragungen
  • Qualitätsattribut-Workshops (QAW)*
Strukturiertes Interview

Ein strukturiertes Interview kann helfen blinde Flecken bei der Erhebung von insbesondere nichtfunktionalen Anforderungen zu identifizieren und wird mit Stakeholdern individuell durchgeführt. Dennoch müssen gefundene Anforderungen nach einem Interview noch hinsichtlich ihrer Relevanz für die Architektur eingeschätzt werden. Auch helfen Anforderungen noch nicht zwingend ein messbares und entscheidbares Merkmal (z.B. in Form eines Qualitätsszenarios) abzuleiten. Dies kann bei Bedarf allerdings auch als Teil des Interviews mit den Stakeholdern durchgeführt werden.

Diese Technik macht sich zunutze, dass es viele Aufstellungen und Kategorisierungen möglicher Qualitätsanforderungen gibt. Die Befragung anhand von bestehenden Aufstellungen zu gestalten, hilft Stakeholdern oft Bereiche von Anforderungen zu identifizieren, welche sie zuvor nicht in Betracht gezogen haben.

 Einige Modelle für die Strukturierung von qualitativen Merkmalen sind zum Beispiel

Ein beispielhafter Ablauf für ein Interview kann wie folgt aussehen:

Für das Interview wird für jede Kategorie eine beispielhafte Anforderung an das System vorbereitet.

Danach wird dem Stakeholder das Ziel des Interviews und die Methode vorgestellt.

Im Anschluss wird zusammen mit dem entsprechenden Stakeholder das Modell Kategorie für Kategorie durchgegangen. Sind von diesem Stakeholder in dieser Kategorie bereits Anforderungen bekannt, so wird eine Kategorie ggf. ausgelassen.

Dabei werden alle entstehenden Anforderungen aufgenommen. Bei der Aufnahme von Anforderungen wird zusätzliche gefragt, wie die Anforderung dem Stakeholder hilft, sein Ziel zu erreichen. So wird die Relevanz der Anforderung verifiziert, da diese Art von Interview die Gefahr birgt eine übergroße Menge an Anforderungen zu erzeugen. Zudem wird es möglich einen Überblick über die unterliegenden Interessen des Stakeholders zu erlangen. Zuletzt wird sich beim Stakeholder für seine Zeit bedankt.

Im Anschluss an das Interview werden die aufgenommenen Anforderungen mit bestehenden Dokumentationen abgeglichen und neue Anforderungen aufgenommen. Sollten Anforderungen im Widerspruch zu bisher erfassten Anforderungen stehen, so wird Rücksprache mit dem Stakeholder und ggf. PO, BA und RE gehalten. Zuletzt werden die Anforderungen hinsichtlich architektureller Signifikanz bewertet.

Techniken zur Abnahme von Anforderungen

BDD

 

Die verhaltensgesteuerte Entwicklung, auch als anforderungsgetriebene Softwareentwicklung bezeichnet, wurde erstmals 2003 von „Dan North“ beschrieben und ist seitdem weitergewachsen. Dan North entwickelte auch das erste Framework zur Implementierung von BDD in JBehave.

BDD ist eine weitere agile Softwareentwicklungstechnik, die die Zusammenarbeit zwischen verschiedenen Beteiligten, insbesondere beim Gespann Softwarearchitekt / Product Owner / Business Analyst, in Softwareentwicklungsprojekten verbessert. Bei der verhaltensorientierten (verhaltensgetriebenen) Entwicklung werden bei der Anforderungsanalyse Softwareaufgaben, Ziele und Ergebnisse in einer definierten textuellen Form erfasst, die später als automatisierte Tests durchgeführt werden können.

Auf diese Weise kann überprüft werden, ob die Software korrekt implementiert wurde oder weitere Anpassungen benötigt werden.

Die Softwareanforderungen werden in Szenarien formuliert, typischerweise als “Wenn-Dann”-Klauseln“. Dieser Ansatz basiert auf der Sprache des domänengesteuerten Designs (DDD-Domain-Driven Design).

Ziel ist es, ein gemeinsames Verständnis zu entwickeln und einen Übergang von den technischen Anforderungen zur Implementierung zu erleichtern.

Gemäß BDD verwendet man für die Verhaltens-Spezifizierung ein Format, das von User-Story-Spezifikationen (Als Rolle…)  abgeleitet wird.

Jede User Story sollte in gewisser Weise der folgenden Struktur folgen:

Titel

Ein expliziter Titel

Narrativ / Erzählung

Eine kurze Einführung mit folgendem Aufbau:

Als: die Person oder Rolle, die aus der Funktion einen Nutzen zieht;

möchte Ich: die Funktion / Feature;

damit: der Nutzen oder Wert der Funktion.

Akzeptanzkriterium

Eine Beschreibung jedes spezifischen Szenarios der Erzählung mit der folgenden Struktur:

Gegeben: der Anfangskontext zu Beginn des Szenarios in einem oder mehreren Abschnitten;

Wenn: das Ereignis, das das Szenario auslöst;

Dann: das erwartete Ergebnis in einer oder mehreren Klauseln.

Beispiel

Szenario 1: Rückgegebene Ware kommt wieder ins Lager

  • Gegeben ist, dass ein Kunde eine schwarze Hose gekauft hat
  • Und wir daraufhin 3 schwarze Hosen im Lager hatten,
  • Wenn er die Hose zurückgibt und dafür einen Gutschein erhält,
  • Dann werden wir 4 schwarze Hosen im Lager haben.

Es ist ratsam, dass Softwarearchitekt, Business Analyst und Entwickler zusammenarbeiten, um die Szenarien zu entwerfen und die daraus resultierenden Ergebnisse in einem separaten Dokument festgehalten werden.

Fazit

Anforderungen sind ein, wenn nicht der, treibende Faktor der Softwareentwicklung. Deswegen ist die Erhebung, Dokumentation, Spezifikation und Verwaltung der Anforderungen eine der wichtigsten Tätigkeiten in der Softwareentwicklung.

Trotzdem sind auch gute Anforderungen noch kein Garant für Erfolg, wie wir an der Dynamik zwischen Anforderungserhebung und Deklaration als architekturrelevanter Anforderung erkennen können. Offene Kommunikation und ein gemeinsames Verständnis über die Anforderungen und dem was daraus gemacht wird, inklusive entsprechender Abnahmen sind also ebenso essenziell.

Dies zeigt die Notwendigkeit für Requirements Engineer, Product Owner, Business Analyst und Softwarearchitekten zusammenzuarbeiten und eine gemeinsame Sprache und Basis zu finden, um den Anforderungen im Interesse des Projekterfolges Konsistenz zu verleihen, nicht nur einmalig, sondern iterativ und fortwährend.

Damit schließt unsere Blog-Serie zu Requirements for Software Architects auch ab. Vielen Dank fürs Lesen!

 

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://www.nasa.gov/topics/history/features/kennedy_moon_speech.html

Abbildung 2: https://astrobiology.nasa.gov/missions/apollo-11/

Abbildung 3: Stakeholder Gewichtung — Wie behandle ich meine Stakeholder? | FelixKlauke (medium.com)

Requirements for Software Architects

Requirements for Software Architects

Requirements for Software Architects

Agile Requirements Engineering und seine Rollen
 

 

Willkommen zurück zum zweiten Artikel in unserer Blog-Serie „Requirements for Software Architects“. Wir widmen uns in diesem Beitrag dem agilen Requirements Engineering und seinen Rollen.

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.

Abbildung 9: Architecture in Technical Perspective View

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

Requirements for Software Architects

Requirements for Software Architects

Requirements for Software Architects

Mit Requirements Engineering zu den besten Anforderungen

 

 

Herzlich Willkommen zu unserer neuen Blog-Serie, Requirements for Software Architects!
Erfahren Sie in dieser dreiteiligen Reihe etwas über die Signifikanz von Anforderungen Ihrer Kunden, die verschiedenen Rollen des Agile Requirement Engineerings und moderne Techniken.

Abbildungs 1: Wie Projekte wirklich funktionieren

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.

Abbildung 2: Software-Lebenszyklus

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.
Anforderungen Definition und Grundbegriffe

„Requirement“ (englisch) bedeutet so viel, wie „Vorausgesetztes“ oder „verpflichtendes Erfordernis“, aber auch Erwartung. Wie bei vielen Begriffen aus der IT-Welt gibt es für den Begriff „Anforderung“ zahlreiche Definitionen.

Requirements Engineering Board (IREB) definiert Anforderung hingegen als:
• ein Bedürfnis, das von einem Stakeholder wahrgenommen wird.
• eine Fähigkeit oder Eigenschaft, die ein System haben soll.
• eine dokumentierte Darstellung eines Bedarfs, einer Fähigkeit oder eines Eigentums.

Für das International Institute of Business Analysis (IIBA) ist eine Anforderung eine brauchbare Darstellung eines Bedürfnisses, die in der Regel durch Dokumente beschrieben wird.
Daraus abgeleitet können Anforderungen als eine Aussage über den zu erreichenden Merkmalen oder die zu erbringenden Leistungen für eine Software oder System definiert werden.

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)

Abbildung 3: Gute vs. schlechte Anforderungen

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.

Abbildung 7: Standard ISO/IEC 25010. Software product quality model

1. Funktionale Eignung
  • Funktionelle Vollständigkeit
  • Korrekte Funktionalität
  • Angemessene Funktionalität
2. Verlässlichkeit
  • Reife
  • Verfügbarkeit
  • Fehlertoleranz
  • Wiederherstellbarkeit
3. Leistungseffizienz
  • Zeitverhalten
  • Ressourcennutzung
  • Kapazitätsaufwand
4. Nutzbarkeit
  • Angemessene Erkennbarkeit
  • Erlernbarkeit
  • Bedienbarkeit
  • Schutz vor Fehlbedienung durch den Nutzer
  • User-Interface Ästhetik
  • Zugänglichkeit
5. Wartbarkeit
  • Modularität
  • Wiederverwendbarkeit
  • Analysierbarkeit
  • Modifizierbarkeit
  • Testfähigkeit
6. Sicherheit
  • Datenschutz
  • Integrität
  • Unmanipulierbarkeit
  • Administrationsfähigkeit
  • Authentifizierbarkeit
7. Kompatibilität
  • Co-Existenz (zu weiterer Software)
  • Interoperabilität
8. Portierbarkeit
  • Anpassungsfähigkeit
  • Installierbarkeit
  • Austauschbarkeit
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.

 

Abbildung 8: Das magische Dreieck

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

Native Cloud Application (NCA) – Entwicklung unter den Wolken

Native Cloud Application (NCA) – Entwicklung unter den Wolken

Waldemar Artes

Waldemar Artes hat langjährige Erfahrung als Anwendungsentwickler. Er unterstützt Kunden als Senior-Entwickler bei der Umsetzung und Instandhaltung von Fachanwendungen. Er interessiert sich für technischen Fortschritt und alles, was uns weiterbringt.

Nichts hat die Art und Weise, wie in der IT-Welt Software konzipiert und entwickelt wird in den letzten Jahren so sehr verändert wie Microservices. Heutige Anwendungen müssen in einem Cluster von mehreren Knoten funktionieren, dynamisch platzierbar, skalierbar und fehlertolerant sein.

Microservices wiederum bilden die Basis von Cloud Native Applikationen. Die einzelnen Microservices sind voneinander unabhängig und können auf mehreren Servern an verschiedenen Standorten laufen. Cloud Native Anwendungen nutzen diese lose gekoppelten Cloud Services. Bei Cloud Native handelt es sich um einen Ansatz, der gewährleisten soll, dass Anwendungen für die Cloud-Computing-Architektur entworfen und entwickelt werden. Die Besonderheiten der Cloud-Computing-Architektur sollen zum Vorteil der Anwendungen genutzt und alle Möglichkeiten voll ausgeschöpft werden. Für diese Art von Anwendungen wird oft die Abkürzung NCA verwendet, welche für Native Cloud Application steht.

Eine Native Cloud Application ist ein echtes Multitalent

Native Cloud Applications haben zahlreiche Vorteile. Sie sind weder an eine spezielle Hardware noch an bestimmte Betriebssysteme gebunden, lassen sich leicht skalieren, sind einfach zu deployen, und sie sind georedundant. „Redundanz“ heißt, dass mindestens eine zusätzliche Ressource als Back-up für den Notfall vorhanden ist. In der Kombination mit „Geo“ bedeutet es, dass diese Ressourcen zusätzlich räumlich voneinander getrennt sind. Nur so kann wirklich sichergestellt werden, dass auch bei schwerwiegenden technischen Problemen an dem einen Ort noch immer ein intaktes Back-up an einem anderen Ort verfügbar ist. Laut Bundesamt für Sicherheit in der Informationstechnik (BSI) sollten es sogar mindestens 200 km sein, um auch vor Naturkatastrophen gut geschützt zu sein.

Die vier zentralen Bestandteile der Entwicklung einer Native Cloud Application: DevOps, Continuous Delivery, Microservices und Container

Vier zentrale Bestandteile für die Entwicklung einer Native Cloud Application

 

  • DevOps ist die Zusammenarbeit zwischen Entwicklung und Betrieb mit dem Ziel, den Auslieferungsprozess zu automatisieren.
  • Continuous Delivery erlaubt die schnellere und zuverlässigere Auslieferung von Software mit weniger Risiken
  • Microservices ist ein Architekturansatz, in dem eine Anwendung als Verbund von mehreren kleinen Services gebaut wird.
  • Container bieten leichtgewichtige Virtualisierung. Sie sind schneller und effizienter als normale Virtualisierung. Container können miteinander verknüpft und gemeinsam orchestriert werden.

Diese vier Prinzipien erlauben es gemeinsam, schnell und risikoarm eine verteile Anwendung zu entwickeln, auf verteilter Infrastruktur auszuliefern und zu betreiben. Als Infrastruktur kann zum Beispiel Amazon Web Services oder Microsoft Azure genutzt werden.

Herausforderungen bei der Entwicklung und dem Betrieb von NCAs

Die Entwicklung einer Native Cloud Application bringt neue Herausforderungen mit sich, die ein Umdenken in der Entwicklung erfordern.

 

  • Persistente Datenablage: Container lassen sich nur kaum zur Datenhaltung nutzen, da diese sehr flüchtig sind. Wird ein Container gelöscht oder abgebaut, sind die Daten auch weg. Persistente Daten sollten deshalb außerhalb der Microservices gehalten werden. Auf diese Daten kann dann mittels einer Service-Schnittstelle zugegriffen werden.
  • Integration der Services: Verteilte Anwendungen bringen eine eigene Komplexität mit sich. So müssen die einzelnen Microservices über Server oder sogar Cloud-Provider hinweg miteinander integriert werden. Sie müssen sich gegenseitig finden und die Kommunikation soll fehlertolerant verlaufen.
  • Monitoring: NCAs können aus mehreren hundert bis tausend einzelnen Microservices bestehen. Umso wichtiger ist es, alle im Blick zu behalten. So müssen Werte wie Auslastung und Antwortzeiten beobachtet werden, um die Stabilität des gesamten Produktes zu gewährleisten.
  • Cloud Lock-in vermeiden: Durch die Einfachheit in ihrer Bedienung passiert es schnell, dass man sich von einem einzigen Cloud-Provider abhängig macht. Dessen sollte man sich bei der Planung bereits bewusst sein und so viele Industrie-Standards wie möglich anstelle von proprietären Lösungen nutzen.
  • Bauen von Pipelines zum Ausliefern der NCAs: NCAs arbeiten typischerweise in der Cloud. Möglicherweise sogar bei mehreren Cloud-Providern. Das erschwert das Ausliefern von NCAs, da diese stark verteilt sind und miteinander integriert werden müssen. Zudem können unterschiedliche Microservices unterschiedliche Abhängigkeiten fordern. Es werden Pipelines benötigt, die die einzelnen Microservices dorthin und in der benötigten Redundanz deployen, wo sie gebraucht werden.

Vorteile einer Native Cloud Application

Mit all den Herausforderungen, um eine Native Cloud Application zu entwickeln und zu Betreiben stellt sich immer die Frage: Ist es den Aufwand wert? Was sind die Vorteile?

 

  • Kosten: Wird die Anwendung auf einem Cloud-Anbieter betrieben, zahlt man nur das, was verbraucht. So können die Kosten für den Betrieb in nicht-aktiven Zeiten gesenkt werden.
  • Skalierbarkeit: Native Cloud Applications sind durch ihre Microservice-Architektur stark skalierbar. So können einzelne Microservices bei Bedarf dupliziert werden.
  • Kundennähe: NCAs können auf Servern weltweit betrieben werden. So müssen Anwender die Daten nicht über die ganze Welt verschicken und die Latenz sinkt.
  • Life-Cycle: NCAs können schneller und mit weniger Aufwand und Kosten aktualisiert werden. Dadurch erhöht sich die Auslieferungsgeschwindigkeit und das Time-To-Market sinkt.
  • Robustheit: NCAs können georedundant betrieben werden, wodurch Ausfälle bei lokalen technischen Problemen deutlich verringert werden.

Tools für Entwicklung und Betrieb einer Native Cloud Application

Die Cloud Native Computing Foundation ist eine neutrale Plattform für die meisten Open-Source-Projekte, die dabei helfen, die Herausforderungen und Probleme bei der Entwicklung und im Betrieb einer Native Cloud Application zu meistern. Darunter fällt das Orchestrierungstool Kubernetes, sowie das Monitoring-Tool Prometheus.

Die CNCF stellt eine Übersicht über alle Projekte, Tools und Provider zur Verfügung, die bei der Entwicklung, Auslieferung und Betrieb von NCAs helfen.

Was Softwarearchitekt:innen beachten müssen

Das Sicherstellen der ACID-Eigenschaften (Atomic, Consistency, Isolated, Durability) bei der Datenhaltung ist in hoch verteilten Anwendungen mit mehreren Datenbanken sehr schwierig bis unmöglich. In der Regel kann für eine gewisse Zeit auf Konsistenz der Daten verzichtet werden. In diesen Fällen sind Datenbanken mit BASE-Eigenschaften (Basically Available, Soft state, Eventual consistency) interessant, denn hier wird die Datenkonsistenz im Laufe der Zeit hergestellt. Ein gutes Beispiel ist Twitter, da auf dieser Plattform die Follower-Zahlen nicht in Echtzeit aktualisiert werden.

Softwarearchitekt:innen müssen entscheiden, für welche Daten Konsistenz benötigt wird und für welche nicht. Genauso müssen Sie darauf achten, die richtige Anzahl und Größe zu finden, da sie miteinander integriert werden. So sollte vermieden werden, aus reiner Bequemlichkeit neue Microservices zu implementieren. Microservices sollten immer nur eine Funktion erfüllen.

Je mehr Microservices es gibt, desto schwieriger und wichtiger wird es, diese zu beobachten. Wichtige Daten wie Durchlaufzeiten und Aufrufe pro Zeiteinheit können kritische Bereiche, Fehler und Flaschenhälse aufdecken. Monitoring-Lösungen wie der ELK-Stack helfen dabei, die verteilten Metriken zu sammeln, zentralisieren und visualisieren. So können auch Grenzwerte gesetzt werden, deren Überschreitung oder Unterschreitung einen Alarm auslösen. Diese Grenzwerte sollten aber auch immer wieder evaluiert und angepasst werden.

Best Practices bei der Entwicklung und Betrieb von Native Cloud Applications

Die Microservices einer NCA sollten sauber in zustandlose Services und zustandsbehaftete Services getrennt werden. Zustandslose Services können problemlos dupliziert und wieder abgebaut werden, ohne den Zustand der Anwendung zu ändern.

Microservices sollten nach Möglichkeit auch keine Anforderungen an das zu Grunde liegende System wie beispielsweise SSDs oder GPU haben. So lassen sie sich simpel in verschiedenen Umgebungen deployen.

Bei der Entwicklung der NCAs ist es wichtig, so viel wie möglich zu automatisieren. Das hilft, die vielen Microservices und die verteilte Natur einer solchen Anwendung beherrschbar zu machen. Infrastructure-as-Code automatisiert die Bereitstellung der Infrastruktur. Dieser Code kann und sollte auch mit versioniert werden. Das garantiert, dass jeder Service immer und in jeder Umgebung für ihn passend konfigurierte Infrastruktur besitzt.

Wenn dann ein weitverbreiteter Standard zur Kommunikation benutzt wird, wie etwa HTTP, können Microservices mit Technologien und Sprachen entwickelt werden, die am besten zur Aufgabe passen.

Fazit

Native Cloud Applications erlauben es den großen Internetgiganten wie Google und Twitter global ihre Services anzubieten, schnell Änderungen und neue Funktionen an die Nutzer:innen zu bringen. Herausforderungen, die sie mit sich bringen, lassen sich durch bereits etablierte Entwurfsmuster und Open Source Tools und Projekte ohne große Schwierigkeiten meistern. Die Hürden bei der Entwicklung und dem Betrieb einer Anwendung in der Cloud werden immer geringer, sodass heute jeder die Möglichkeit hat NCAs zu entwickeln und zu betreiben.

Training zu ‘Infrastruktur, Container und Cloud Native (CLOUDINFRA)‘

Unser 3-tägiges Training ‘Infrastruktur, Container und Cloud Native (CLOUDINFRA)‘ vermittelt das notwendige Wissen und die Fähigkeiten, um dynamische Cloud Native Architekturen konzipieren und implementieren zu können. Es werden zentrale Themen wie Container Application Design, Logging/Monitoring/Alerting, Container Native Storage, Möglichkeiten zur UI Integration sowie Container Manager vorgestellt. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture – Advanced Level (CPSA-A) nach dem iSAQB-Programm anstreben, erhalten Sie für dieses Training 20 Credit Points im Kompetenzbereich Technologie und 10 Credit Points im Kompetenzbereich Methodik.

Termine zum Training 'Infrastruktur, Container und Cloud Native (CLOUDINFRA)'

ITech Academy stellt 10 neue Trainings vor!

ITech Academy stellt 10 neue Trainings vor!

Neue Trainings in den Bereichen: Softwaremodellierung, Softwareentwicklung und Softwarearchitektur

Wenn Sie unsere ITech Academy bereits kennen, wissen sie bestimmt, dass Softwarearchitektur ein untrennbarer Teil unserer DNA und vor allem unsere Leidenschaft ist! Das spiegelt sich auch in unserem großen Angebot an iSAQB-akkreditierten Softwarearchitektur Trainings wider. Von den Grundlagen bis hin zu fortgeschrittenen Trainings sind alle relevanten und aktuellen Themen aus der Welt der Softwarearchitektur vertreten. Als IT-Beratungsunternehmen beraten wir unsere Kunden neben innovativen Architekturparadigmen wie Microservices und Cloud Architekturen seit über 17 Jahren auch in allen Phasen ihrer IT-Projekte, von der Konzeption über den Entwurf und die Implementierung bis hin zu Testing, Fertigstellung und Qualitätssicherung.

Wir als ITech Progress haben uns mit der ITech Academy einen Ort geschaffen, um genau diese langjährige Erfahrung in den Bereichen Softwaremodellierung, Softwareentwicklung und Softwarearchitektur in Form von theoretischem und praktischem Wissen weiterzugeben. Denn einer unserer Grundsätze lautet: Wissensmonopole sind für uns tabu!

Aus diesem Grund haben wir 10 neue Trainings und Workshops nach eigenem Lehrplan entwickelt, die jetzt ein Teil unseres Academy-Portfolios sind! In allen Trainings und Workshops steckt das Beste aus unserer Arbeit und Erfahrung mit komplexen Systemen, bewährten Tools, Technologien, Architekturen und den Best Practices der Softwareentwicklung und -architektur. Und all das: Immer auf dem neuesten Stand!

Das sind die neuen Trainings und Workshops:

Softwaremodellierung

Objektorientierter Softwareentwurf mit UML und Objektorientierung

Dieses 3-tägige Grund- und Aufbautraining richtet sich an alle Softwareentwickler:innen und –architekt:innen im objektorientierten Umfeld, die UML als effektives Entwurfs-, Planungs- und Kontrollinstrument einsetzen möchten.

Softwareentwicklung

SQL & DB Design (5 Tage inkl. Workshopzeit)

Java und OOP (5 Tage inkl. Workshopzeit)

html und CSS (3 Tage inkl. Workshopzeit)

JEE (3 Tage inkl. Workshopzeit)

Programmieren für Fortgeschrittene mit JAVA

Diese Trainings eignen sich ideal zur Mitarbeiterbefähigung, wenn in Ihrem Unternehmen beispielsweise noch Legacy-Systeme genutzt werden und der Umstieg auf zeitgemäße Technologien und Architekturen erfolgen soll.

Softwarearchitektur

Methodischer Fokus:

Enterprise Application Integration Patterns

In diesem 2-tägigen Training für Softwareentwickler:innen und -architekt:innen lernen sie Enterprise Application Integration (EAI) Patterns kennen, um Geschäftsfunktionen entlang der Wertschöpfungskette eines Unternehmens, die über diverse Applikationen auf verschiedenen Plattformen verteilt sind, zu integrieren.

Design Patterns

In diesem 2-tägigen Training für Softwareentwickler:innen und -architekt:innen lernen sie das Konzept und den Sinn von Entwurfsmusstern kennen.  Wir geben Ihnen aus unserer jahrelangen Projekterfahrung eine Auswahl wichtiger Entwurfsmuster an die Hand und führen sie mithilfe verschiedener Methoden in die praktische Anwendung.

Technologischer Fokus:

Clean Code

In diesem Training lernen Sie die Werte, Regeln und Prinzipien kennen, auf denen die Handwerkskunst der Softwareentwicklung fußt und können damit dem Sprichwort „Wie der Meister, so das Werk“ folgend, sauberen, änderbaren, testbaren und objektorientierten Code entwickeln.

Kommunikativer Fokus:

Führungskräfteentwicklung

In diesem 2-tägigen branchenübergreifenden Training geben wir Führungskräften das Know How für situationsgerechte Kommunikation, Reflexion und Verantwortungsdelegation als aktive Bestandteile einer effektiven und erfolgreichen täglichen Arbeit mit. Teilnehmer:innen erlernen, die eigenen Rollen und Ziele zu definieren und darauf aufbauend Ihr Verhalten auszurichten.

So nehmen Sie an unseren neuen Trainings und Workshops teil

Vorläufig ist das neue Portfolio nur in Form von Inhouse-Trainings (auch remote) buchbar, aber wir freuen uns auf Ihre direkte Rückmeldung, wenn Interesse an offenen Terminen besteht! Kommen Sie hierfür gerne über die unten angegebenen Kontaktmöglichkeiten auf uns zu oder melden Sie sich für unseren monatlichen Newsletter an, um keine Termine und Neuigkeiten zu verpassen. Aus unserer Erfahrung heraus wissen wir, dass eine Lernatmosphäre außerhalb des eigenen Standortes eine echte Bereicherung für das Team sein kann, weshalb wir Ihnen an unseren Standorten in Ludwigshafen und Nürnberg gerne auch großflächige, modern ausgestattete Schulungsräume zur Verfügung stellen.

Sie haben Interesse an den neuen Trainings oder eine Frage?

Dann rufen Sie uns bitte unter +49 621 595702 41 an, schreiben Sie eine E-Mail an training@itech-progress.com oder schicken Sie uns über das Kontaktformular eine schriftliche Anfrage:

5 + 14 =