Swar

• Generische Produkte

• Maßgeschneiderte Produkte

• Plattformen

“allgemeine Software-lösungen”

Eigenständige Systeme, die an jeden Kunden, der sie kaufen möchte, vermarktet und verkauft werden

Spezifikationen werden von Softwareentwicklungsfirma getroffen

“Individual Software”

Software, die von einem bestimmten Kunden in Auftrag gegeben wird, um seine eigenen Anforderungen zu erfüllen

Spezifikationen liegen in den Händen von Kunden

Systeme mit Basisfunktionalitäten in den andere Partner Produkte, Dienstleistungen oder Software anbieten

Einmalige Zahlung

Abonnement Modell

Freemium: einige grundlegende Funktionen sind kostenlos, für weitere Funktionen muss man zahlen

Pay-per-use: je nach Nutzungsdauer oder Anzahl

• Bereitstellung in der IT-Infrastruktur des Unternehmens (“on premise”)

• Auslagerung in die Cloud durch das Unternehmen selbst:

• Bereitstellung für den Kunden durch den Softwareentwickler und Angebot als “Software-as-a-Service

Unternehmen gehört alles selbst

maximale Kontrolle, aber auch maximaler Bedienungsaufwand

zB Moodle im HTWG Rechnungszentrum

Unternehmen kontrolliert die Anwendungsdaten

Unternehmen bestimmt, wann die Software aktualisiert werden soll

weniger Kontrolle über die Infrastruktur, aber viel weniger Betriebsaufwand

zB Digitale Dörfer Plattform

minimale Kontrolle

minimaler Aufwand für den Betrieb

zB Microsoft Office 365

Wasserfallmodell

Inkrementelle Entwicklung

Integration und Konfiguration

typische plan-getriebene Modell

alle verschiedenen Aktivitäten werden getrennt und nacheinander ausgeführt

Definition der Anforderung bis ins kleinste Detail

Entwurf des Systems mit Festlegung des Aufbaus, der Technologie und Wahl fertiger Komponenten

Implementierung und Testen auf Unit-Ebene

Integrations- und Systemtests, auch Zusammenspiel verschiedener Module und Systeme

Betrieb und Wartung

Software wird nicht als einziges großes Produkt entwickelt, sondern als eine Abfolge von einer ersten Minimalversion, gefolgt von Inkrementen, die weitere Funktionen hinzufügen

Spezifikation, Entwicklung und Validierung werden mit Blick auf das nächste Inkrement durchgeführt

Ist übliche Methode in agilen Prozessen

System wird aus vorhandenen konfigurierbaren Komponenten zusammengesetzt

Vermeidet oder minimiert die eigene Entwicklung

Das eigentliche Softwareprodukt wird erst nach einem langen Zeitraum erstellt

Zu diesem Zeitpunkt

• können erst echte Benutzertests durchgeführt und kritische Designfehler oder missverstandene Anforderungen aufgedeckt werden

• können sich die Anforderungen wieder geändert werden

• können Technologien bereits veraltet sein

AM WICHTIGSTEN: Zu diesem Zeitpunkt erfordern alle Änderungen einen großen Aufwand

Die Kosten für die Anpassug an sich ändernde Kundenanforderungen sind geringer, denn der Umfang der Analyse und der Dokumentation, die neu erstellt werden müssen ist viel geringer als beim Wasserfallmodell

Es ist einfacher Kundenfeedback zum aktuellen Stand der Entwicklung zu erhalten, denn die Kunden können diesen vorgeführt bekommen und direkt Feedback geben

Eine schnellere Lieferung und Bereitstellung von Software ist möglich, da man bereits Zwischenversionen installieren kann

Der Prozess ist nicht sichtbar und messbar

• Wenn Systeme schnell entwickelt werden, ist es nicht kosteneffizient, ausführliche Dokumentation zu jeder Version des Systems zu erstellen

Systemstruktur neigt dazu, sich zu verschlechtern, wenn neue Inkremente hinzugefügt werden

Eigenständige Anwendungssysteme, die für den Einsatz in einer bestimmten Umgebung konfiguriert sind

Webservices, die nach Standards entwickelt werden und über das Netzwerk aufgerufen werden

Komponenten-Frameworks wie .NET, Spring

Software-Bibliotheken

Geringe Kosten und Risiken, da weniger Software von Grund auf entwickelt werden muss

SChnellere Lieferung und Bereitstellung des Systems

Kompromisse bei den Anforderungen sind unvermeidlich, so dass das System möglicherweise nicht den tatsächlichen Bedürfnissen der Nutzer entspricht

Man hat keine Kontrolle über die Entwicklung von wiederverwendeten Systemelementen

Fertige Komponenten haben in der Regel viel mehr Funktionen als tatsächlich benötigt

• EIn von einem Stakeholder wahrgenommes Bedürfnis

• Eine Fähigkeit oder Eigenschaft, die ein System haben muss

• Eine dokumentierte Darstellung eines Bedürfnisses, einer Fähigkeit oder einer Eigenschaft

Eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen eines Systems hat oder von diesem System betroffen ist

Eine Anforderung bezüglich eines Ergebnisses oder Verhaltens, das von einer Funktion eines Systems bereitgestellt werden soll

Jede Anforderung, die keine funktionale Anforderung ist, wie z.B. Qualitätsattribute, Geschäftsziele und Randbedingungen/Einschränkungen

Sie beziehen sich oft auf das ganze System als Ganzes und nicht auf einzelne Funktionen oder Dienste

Systematischer und disziplinierter Ansatz zur Spezifikation und Verwaltung von Anforderungen mit dem Ziel, die Wünsche und Bedürfnisse der Stakeholder zu verstehen und das Risiko minimieren, ein System zu liefern, das diese Wünsche und Bedürfnisse nicht erfüllt

Endbenutzer

Systemverantwortliche

Systembesitzer

Systementwicklungsteam

Systemtest-,Betriebs- und Support-Teams

Interne und externe Stakeholder

Als [Nutzertyp] [möchte ich], [damit]

"Als [Benutzertyp]": Für wen bauen wir das Produkt? Das Team sollte ein gemeinsames Verständnis davon haben, was dieser Nutzertyp ist, und idealerweise eine gewisse Empathie für diesen Nutzertyp entwickelt haben.

− "möchte ich": Hier beschreiben wir ihre Absicht - nicht die Funktionen, die sie verwenden. Was ist es, das sie tatsächlich erreichen wollen? Diese Aussage sollte frei von Implementierungsdetails sein (insbesondere sollte sie keine Teile der Benutzeroberfläche beschreiben).

− "damit": Wie passt ihr unmittelbarer Wunsch, etwas zu tun, in ihr Gesamtbild? Was ist der Gesamtnutzen, den sie zu erreichen versuchen? Was ist das große Problem, das gelöst werden muss?

Analyse und Planung: Treiber ermitteln

Auswahl des erforderlichen Inputs für den Architekturentwurf, verschiedene Anliegen

Systematisch als Architektur-Treiber aufschreiben

hat Bezug zu:

• Anforderungen

• Validierung/Qualitätssicherung

Investition: Entwurf, Modellierung und Rekonstruktion

• In die Architektur investieren

• Design-Entscheidungen treffen, Lösungskonzepte erstellen

• diese über Architekturmodelle und Dokumentation festhalten

Vorhersage: Vertrauen aufbauen

Vertrauen in die Architektur schaffen, indem man die bisher modellierte Architektur durch Was-wäre-wenn-Diskusiionen, Prototypen oder Simulationen überprüft

Ableitung: Entscheidungen verbreiten

das System realisieren, dabei die Implementierung anleiten

Artefakte werden generiert

Governance: Reflektieren

Prüfen, ob die Architektur angemessen ist durch systematische Architekturbewertugen

ggf. unterstützt durch Tools

Lifecycle

Initiatives

Assets

Lebenszyklus der Software, d.h. Erstellung, Entwicklung und Außerbetriebnahme

Vergangenheit: Bereits bestehendes System und technische Schulden

Gegenwart: Die aktuelle Weiterentwicklung der Software, um das nächste Inkrement zu erzeugen

Zukunft: mittel- bis langfristige Planung, auch geplante Lebensdauer der Software

Initiativen beschreibt die Planung der zu erledigenden Aufgaben. Diese sind typische Projektmanagement-Themen, aber auch Softwarearchitkten müssen diese Rahmenbedingungen beachten

Ressourcen: die verfügbaren Personen

Zeitplan: Der Zeitplan, Beginn, Ende des Projekts, Zwischenergebnisse

Das Budget: Das verfügbare Budget zur Finanzierung des Projekts

Ergebnis des Projekts

Wert: Wert für Kunden und für das Entwicklerunternhemen

Menge: Umfang der Lösung

Qualität: Qualität der Lösung. Wie gut/schnell/zuverlässig funktioniert das System?

Geschäftsziele

• vom Unternehmen des Kunden/Auftraggebers

• vom Entwicklungsunternehmen

Qualitätsattribute

• Laufendes System

• System in der Entwicklung

die wichtigsten funktionle Anforderungen

• hervorstechende Eigenschaften

• solche, die das System “lebensfähig” machen

Randbedingungen (Constraints)

• Anforderungen an das System aus der Fachbereich

• Organisatorische, rechtliche und technische Randbedingungen

• Kosten und Zeit

Die komplexität eines Systems beherrschen

Ein System in überschaubare Teile zerlegen

Wichtigstes Tool: Zerlegung/Dekomposition

Funktionale Zerlegung

Datengetriebene Zerlegung

Deployment-getriebene Zerlegung

Technologie-getriebene Zerlegung

Team-/Aktivitäts-getriebene Zerlegung

Welche verschiedenen Funktionen erfüllt das System?

Wie können komplexe Funktionen in kleinere funktionale “Einheiten” zerlegt werden?

Welche unterschiedlichen Daten werden von dem Systm verarbeitet?

Wie hängen bestimmte Daten mit anderen Daten zusammen?

Wie können Daten aus anderen Daten zusammengesetzt werden?

Dient zur Modellierung der Schnittstellen von Teilsystemen

Organisiert das System in Schichten mit zugehörigen Funktionen, die mit jeder Schicht verbunden sind

Eine Schicht stellt Dienste für die darüber liegende Schicht bereit

Kerndienste auf unterster Schicht

Eine Schicht darf nur auf Schichten unterhalb der aktuelln Schicht zugreifen

Erlaubt den Austausch ganzer Schichten solange die Schnittstelle erhalten bleibt

Redundante Funktionen können in jeder Schicht zur Verfügung gestellt werden, um die Zuverlässigkeit des Systems zu erhöhen

In der Praxis ist es oft schwierig, eine saubere Trennung zwischen den Schichten zu gewährleisten

Es kann vorkommen, dass eine übergeordnete Schicht direkt mit untergeordneten Schichten interagieren muss, anstatt über die unmittelbar darunter liegende Schicht

Performance kann ein Problem darstellen, da eine Service-request durch viele einzelne Ebenen hindurchwandern muss

In einer Client-Server-Architektur ist die Funktionalität des Systems in Dienstanbieter und Dienstnutzer aufgeteilt

Server teilen ihre Ressources mit den Clients

Clients komunizieren normalerweise über ein Netzwerk

Folgt den Design-Prinzipien Trennung der Zuständigkeiten und Teile Herrsche

Komplizierte Funktionen können allen CLients zur Verfügung gestellt werden und müssen nicht einzeln implementiert werden

Updates auf dem Server sind sofort auf allen Clients verfügbare

Funktionalitäten kann auf mehrere Serber aufgeteilt werden, die über ein Netzwerk verteilt werden können

Server können zu Single Points of Failure werden, da sie anfällig für Denial-of-Service ANgriffe oder Ausfälle sind

Leistung kann unvorhersehbar sein, da sie sowohl vom Netz als auch vom System abhängt

Continuous Integration, Continuous Deployment, Continuous Delivery

DevOps

Cloud Deployment

Serverless Computing

Microservices

Low-Code/Low-Code Development

Kontinuierliche Integration des System mit anderen Systemen und/oder Code-Teilen

Nach jedem commit wird der Code auf einem Build-Server compiliert und zusammengestellt

Nsach erfolgreicher continuous integration und weiteren Akzeptanztests wird der Code in eine Staging-Umgebung deployt, wo das System für weitere Tests bereitsteht

Nach erfolgreicher coninuous integration und weiteren Akzeptanztest wird der Code in eine Staging-Umgebung und auch in die Produktionsumgebung deployt

Continuous Integration

− stellt sicher, dass Build und Test auf einem "sauberen" System laufen (da Ihr lokaler

Entwicklungscomputer möglicherweise eine eigene Konfiguration hat)

− ist aktueller Stand der Technik

− es gibt mehrere Lösungen, die auch in GitHub und GitLab integriert werden können

Continuous Deployment

− ist sehr empfehlenswert für Systeme mit einer gewissen Komplexität, z. B.

• mehrere zu integrierende Systeme

• Testteam arbeitet unabhängig vom Entwicklungsteam

• agile Projekte (Staging-System kann dem Kunden gezeigt werden)Continuous Delivery

− erfordert mehr Aufwand bei der Einrichtung und sehr gute automatisierte Integrations- und

Systemtests

− Hauptvorteil: Releases für das Produktivsystem sind keine Besonderheit mehr, da sie häufig und regelmäßig erfolgen

Gemeinsame Ownership und somit gemeinsame Verantwortung

Automatisierung von Arbeitsabläufen, dadurch schnelles Feedback

Schließt die Kluft zwischen verschiedenen Teams

Macht das Entwicklungsteam auf Betriebsprobleme aufmerksam

erzwingt Automatisierung

beschleunigt den Release-Prozess

Feinkörnige Dienste

Individuell entwickelt, individuelle Technologien; individuell eingesetzt, individuell releast

Teams arbeiten unabhängig voneinander, mit unterschiedlichen Technologien und sogar Architekturen

Teams sind Experten für ihren Bereich

Teamsbetreiben auch ihre Dienste

Sehr flexibler Ansatz

Hervorragend geeignet für die Skalierung von einzelner Dienste

Hohe Komplexität bei Deployment und Betrieb

Datenredundanz und potenzielle Probleme mit der Datenkonsistenz

Abstraktion

Teile und Herrsche

Einheitlichkeit

Redundanzen reduzieren

Trennung der Zuständigkeiten

− Extraktion der wesentlichen Elemente

− Gemeinsame Eigenschaften von ähnlichen "Objekten" erkennen

• Eigenschaften,diefürdasSystem nicht relevant sind, außer Acht lassen

− Ähnliche Verarbeitungsschritte identifizieren

− Verwendung gemeinsamer Design-

Prinzipien für das gesamte System

− Verschiedene Teile des Systems haben ihre eigenen Zuständigkeitsbereiche

− Eine Aufgabe in kleinere Teilaufgaben aufteilen und deren Lösungen zu einer Gesamtlösung kombinieren

Wiederverwendung von Teilen des Systems, wenn möglich und sinnvoll

Software@Runtime

Data+Functions

Data+Functions@Runtime

Software@Devtime

Data@Devtime

Functions@Devtime

Environment@Runtime

Deployment + Activities

Environment@Runtime

Environment@Devtime

Environment@Devtime

Linearer Datenfluss durch verschiedene Vorgänge

Operationen verarbeiten Eingabedateien und erzeugen Ausgabedateien

Design-Prinzipien: Einheitlichkeit, Kapselung, Trennung von Zuständigkeiten, Teile und herrsche

Einfache, funktional motivierte Aufteilung des Systems

einfache und ähnliche Schnittstellen

Externes Modul muss die Steuerung des Systems übernehmen, ebenso die übergreifende Fehlerbehandlung

Filter wandeln Eingangs- in Ausgangsdaten um

Rohre Transportieren und puffern Datenströme

Einfache Struktur, leicht zu implementieren

lose Kopplung oder geringe Abhängigkeiten der Filter untereinander

Fehlerbehandlung: Da die Filter sich nicht kennen, ist die Behandlung von “Folgefehlern” schwierig

Konfiguration oder Initialisierung der gesamten Verarbeitungskette erfordert eine zentral Steuerung

Ungeeignet für interaktive Systeme

Alle Daten in einem System werden in einem zentralen Repository verwaltet, auf das alle Systemkomponenten zugreifen können

Komponenten interagieren nicht direkt sondernnur über das Repository

Design-Prinzip: Hohe Kohäsion

Verwenden, wenn große Mengen an Informationen erzeugt werden

Komponenten können unabhängig sein - sie müssen nicht von der Existenz anderer Komponenten wissen

Alle Daten können einheitlich verwaltet werden

Repository ist single point of failure, so dass sich probleme im repository auf das gesamte system auswirken

Verteilung des Repository auf mehrere Computer kann schwierig sein

Erlaubt parallele Leseanfragen

Ein replica kann ein defektes primary ersetzen

Höherer Aufwand bei der Bearbeitung von Schreibanfragen

Replicas müssen die verfügbarkeit des Primary prüfen und die Übernahme koordinieren

Command: Schreibender Zugriff auf Daten

Query: Lesender Zugriff auf Daten

Commands und Queries sind auf globaler Ebene getrennt

Unterschiedliche Zuständigkeit der Dienste

Design-Prinzipien: Abstraktion, Trennung der Zuständigkeiten

Hohe Flexibilität

Command-Datenmodell kann unabhängig vom Query-Modell geändert werden

Zentrale Überwachung aller Datenänderungsvorgänge

Stark erhöhte Komplexität im Vergleich zu eiiner Standard-Datenbank

Dezentralisierte Systeme, bei denen Berechnungen von jedem beliebigen Knoten im Netz durchgeführt werden können

Fehlertolerant und robust

kaum kontrollierbar durch offizielle Stellen

Hängt von einer ausreichenden Beteiligung ab

Daten können inkonsistent oder schwer zu finden sein