Entstehung

Obwohl das Konzept der Softwarearchitektur so alt ist wie die Softwareentwicklung selbst, gewann der Begriff „Softwarearchitektur“ erst in den späten 1980er Jahren an Bedeutung. Der Credit für die Etablierung dieses Konzepts geht an Computerwissenschaftler wie David Parnas, Mary Shaw und Fred Brooks, die erkannten, dass eine strukturierte Herangehensweise an die Softwareentwicklung notwendig ist, um komplexe Systeme zu verwalten.

Die Forscher bemerkten, dass die steigende Komplexität von Softwareprojekten eine genaue Planung und Organisation erfordert. Damit begann das Zeitalter der Softwarearchitektur, in dem die Gestaltung eines Systems genauso wichtig wurde wie die Implementierung des Codes selbst.

Was ist Softwarearchitektur?

Softwarearchitektur bezeichnet die Struktur eines Softwaresystems, das seine Elemente, die Eigenschaften dieser Elemente und die Beziehungen zwischen ihnen umfasst. Sie bietet einen Plan, der die Arbeitsweise des Systems und die Kommunikation zwischen seinen verschiedenen Teilen definiert. Die Softwarearchitektur legt auch die Regeln und Vorgaben für die Softwareentwicklung und -wartung fest, um sicherzustellen, dass das Endprodukt den Anforderungen entspricht.

Umsetzung

Die Implementierung folgt einer systematischen Methode. Sie beginnt mit der Anforderungsanalyse, in der die funktionalen und nicht-funktionalen Anforderungen des Systems definiert werden. Anschließend wird das Systemdesign erstellt, das die Hauptkomponenten des Systems und ihre Interaktionen definiert. Dieses Design dient als Blaupause für die Entwicklungs- und Wartungsphase.

Es ist wichtig zu beachten, dass die Architektur flexibel genug sein muss, um Änderungen zu ermöglichen, da die Anforderungen oft variieren können. Daher sind iterative Entwicklungsansätze wie Agile (Siehe Agile Manifest) und (DevOps) oft geeignet für die Implementierung der Softwarearchitektur.

Wichtige Punkte bei der Umsetzung der Softwarearchitektur

Die Umsetzung der Softwarearchitektur erfordert sowohl technische als auch organisatorische Kompetenzen. Hier sind einige Punkte, die zu berücksichtigen sind:

• Verständnis der Geschäftsziele: Die Architektur sollte auf den Geschäftszielen und Anforderungen basieren und nicht nur auf technologischen Überlegungen.
• Verwendung von Design Patterns: Design Patterns sind bewährte Lösungen für gemeinsame Designprobleme. Ihre Verwendung kann die Entwicklungszeit verkürzen und die Qualität des Endprodukts verbessern.
• Dokumentation: Eine gut dokumentierte Architektur erleichtert die Kommunikation innerhalb des Entwicklungsteams und die Wartung des Systems. Auch fällt es den Entwicklern durch eine gute Dokumentation leichter, sich in den verschiedenen Komponenten zurechtzufinden.
• Berücksichtigung von Nicht-Funktionalen Anforderungen: Neben den funktionalen Anforderungen sind auch Nicht-Funktionale Anforderungen wie Sicherheit, Leistung und Skalierbarkeit entscheidend. (Siehe in diesem Zusammenhang auch „Nicht funktionale Tests„)

Fazit

Die Softwarearchitektur spielt eine entscheidende Rolle in der Softwareentwicklung. Sie bietet einen strukturierten Ansatz, um komplexe Systeme zu verwalten und zu warten. Durch die Berücksichtigung der oben genannten Punkte können Entwickler eine effektive und effiziente Architektur erstellen, die den Anforderungen gerecht wird und die langfristige Wartung des Systems erleichtert.

Der Beitrag Softwarearchitektur – Entstehung, Bedeutung und Best Practices erschien zuerst auf CEOsBay.

Das V-Modell ist ein Prozessmodell in der Softwareentwicklung, das sich durch seine konsistente Systematik auszeichnet. Es hat seinen Ursprung in der Verifikation und Validierung von Software. In diesem Beitrag versuche ich die Besonderheiten dieses Modells zu erläutern, die es zu einer effektiven Methode für die Entwicklung qualitativ hochwertiger Software machen.

Per Definition handelt es sich um ein lineares Verfahren zur Softwareentwicklung, das die Beziehung zwischen jedem Entwicklungsstadium und seinem entsprechenden Teststadium definiert. Es legt die Abfolge der Entwicklungsschritte in einer Art V-Form dar, wobei die linke Seite des „V“ die Entwicklung und die rechte Seite die Integration und das Testen der Software darstellt.

Phasen im V-Modell

Die linke Seite des V-Modells beinhaltet die Anforderungsdefinition, System- und Software-Design sowie die Implementierung der Software. Jede Phase auf der linken Seite hat eine korrespondierende Phase auf der rechten Seite, in der das Testen durchgeführt wird.

1. Anforderungsdefinition: In dieser Phase werden die Anforderungen des Benutzers, des Systemanwenders oder des Kunden erfasst und dokumentiert. Dies bildet die Grundlage für die anschließende Entwurfsphase.
2. Funktionaler Systementwurf bzw. Systemdesign: Hier werden die Architektur und das High-Level-Design des Systems erstellt. Folglich die Anforderungen auf Funktionen und Dialogabläufe des neuen Systems abgebildet. Man kann auch von der Definition der Hauptkomponenten des Systems und ihre Interaktion sprechen.
3. Technischer Systementwurf bzw. Software-Design: In dieser Phase wird der detaillierte Entwurf der Software erstellt. Sie umfasst die Ausarbeitung der Einzelheiten der Software, die Erstellung von Algorithmen, Schnittstellen zur Systemumwelt und die Datenstrukturplanung. Man spricht auch von Komponenten, die möglichst unabhängig voneinander entwickelt werden können.
4. Komponentenspezifikation: In dieser Phase werden für jedes Teilsystem Aufgabe, Verhalten, innerer Aufbau und Schnittstellen zu anderen Teilsystemen definiert.
5. Programmierung: In dieser Phase wird der Code für die Software geschrieben. Sie basiert auf den Design-Entscheidungen, die in den vorherigen Phasen getroffen wurden. Jeder spezifizierte Baustein (Unit, Klasse usw.) wird in einer Programmiersprache (Siehe C++, Java, JavaScript) entwickelt (programmiert bzw. implementiert).

Auf der rechten Seite des V-Modells finden die entsprechenden Testphasen statt.

1. Komponenten- bzw. Unit-Test: Hier wird der Code auf Ebene der elementauf Fehler überprüft. Jede Funktion oder Methode wird einzeln getestet, um sicherzustellen, dass sie korrekt arbeitet.
2. Integrationstest: In dieser Phase wird überprüft, ob die verschiedenen Teile der Software richtig zusammenarbeiten.
3. Systemtest: Hier wird das gesamte System getestet, um sicherzustellen, dass es als Ganzes funktioniert.
4. Akzeptanztest bzw. Abnahmetest: Dieser Test wird durchgeführt, um zu überprüfen, ob das System die ursprünglich festgelegten Anforderungen erfüllt.

Vorteile des V-Modells

Die Vorgehensweise des V-Modells bietet verschiedene Vorteile. Durch die strikte Trennung von Entwicklungs- und Testphasen ist eine klare Struktur gegeben, die es den Entwicklern ermöglicht, sich auf eine Aufgabe zur Zeit zu konzentrieren. Zudem erlaubt das Modell eine frühe Fehlererkennung und -behebung, da jeder Entwicklungsschritt von einem spezifischen Test begleitet wird.

Fazit

Das V-Modell ist ein wichtiger Bestandteil der Softwareentwicklung. Durch seine systematische und strukturierte Herangehensweise hilft es Entwicklerteams, qualitativ hochwertige Software zu erstellen und gleichzeitig effizient zu arbeiten. Obwohl es nicht in jedem Entwicklungsprojekt zum Einsatz kommt, kann es in den richtigen Kontexten einen erheblichen Beitrag zur Verbesserung der Softwarequalität und -effizienz leisten. Insbesondere ist es nicht zu empfehlen, wenn Agilität und Flexibilität gefordert sind, wie beispielsweise in Start-ups oder bei der Entwicklung von Webanwendungen. Doch in Sektoren, in denen Robustheit, Sicherheit und Zuverlässigkeit der Software von zentraler Bedeutung sind, hat sich das V-Modell als äußerst wertvoll erwiesen.

Der Beitrag V-Modell in der Softwareentwicklung – Leitfaden erschien zuerst auf CEOsBay.

Was ist Design Thinking?

Es ist im Grunde genommen eine problemlösende Methode, die darauf abzielt, innovative Lösungen zu entwickeln, indem sie sich auf die menschliche Erfahrung, Experimente, Zusammenarbeit und kreatives Denken konzentriert. Es ist nicht nur auf Produktdesign beschränkt. Man kann es auf alle Bereiche des Lebens anwenden, in denen innovative Lösungen erforderlich sind.

Kurze Zeitreise

Der Ursprung des Konzepts lässt sich auf das letzte Jahrhundert zurückverfolgen und ist eng mit mehreren führenden Denkern und Institutionen verknüpft.

Die frühe Verbindung kann man auf den britischen Designer und Theoretiker John Christopher Jones zurückführen, der in den 1960er Jahren die Idee vorstellte, dass Design ein Denkprozess ist, der nicht auf die Gestaltung von Produkten beschränkt ist.

In den 1970er Jahren prägte der amerikanische Architekt und Städteplaner Horst Rittel den Begriff „wicked problems“ für komplexe Probleme, die nicht man nicht durch herkömmliche lineare oder logische Ansätze lösen konnte. Diesen Begriff hat man später in den Prozess des Design Thinking integriert.

Die Popularisierung und Weiterentwicklung des Konzepts kann man der Stanford University und dem Hasso-Plattner-Institut für Design (besser bekannt als die „d.school“) zuschreiben. Den Begriff selbst haben jedoch erstmals David M. Kelley, dem Gründer von IDEO und Professor an der Stanford University sowie Tim Brown, dem CEO von IDEO, in die Geschäftswelt eingeführt. Sozusagen, die Ersten, die Design Thinking als Methode für Innovation und für die Problemlösung definierten und systematisierten.

Es ist demnach nicht nur auf die historischen Persönlichkeiten und Institutionen beschränkt. Es ist ein dynamisches und sich ständig weiterentwickelndes Feld, das Beiträge von Designern, Forschern, Pädagogen und Praktikern aus der ganzen Welt beinhaltet.

Seit der Entstehung hat sich Design Thinking von einer Nischenmethode zu einer weit verbreiteten Praxis entwickelt, die in einer Vielzahl von Kontexten Anwendung findet. Von Produkt- und Servicedesign über soziale Innovation, bis hin zu strategischer Planung und Bildung.

Die Prinzipien des Design Thinking

Es basiert auf fünf Kernprinzipien:

1. Empathie für den Nutzer: Hier geht es darum, die Bedürfnisse und Erwartungen der Nutzer zu verstehen, um Lösungen zu finden, die wirklich relevant und effektiv sind.
   
2. Definieren des Problems: Hier wird das Problem klar und präzise definiert, um den Fokus auf die tatsächlichen Herausforderungen zu legen.
   
3. Ideenfindung: In diesem Schritt generiert man möglichst viele Lösungsansätze, ohne sie zu bewerten. Der Zweck besteht darin, kreatives Denken und die Innovation zu fördern.
   
4. Prototyping: Hierbei setzt man ausgewählte Ideen in konkrete Modelle um, um zu sehen, wie sie in der Praxis funktionieren.
   
5. Testen: In dieser Phase testet man die Prototypen auf ihre Effektivität und gegebenenfalls nimmt man noch Anpassungen vor.

Warum ist Design Thinking wichtig?

In einer sich schnell verändernden Welt sind traditionelle Methoden oft nicht mehr ausreichend, um neue Herausforderungen zu bewältigen. Es bietet einen flexiblen und kreativen Ansatz, der es Unternehmen und Individuen ermöglicht, Probleme zu lösen und Innovationen zu entwickeln, die den Bedürfnissen der Nutzer entsprechen.

Durch die Einbeziehung des Nutzers in den Designprozess und die Förderung des kreativen Denkens kann Design Thinking dazu beitragen, Produkte und Dienstleistungen zu schaffen, die wirklich auf die Bedürfnisse der Nutzer abgestimmt sind. Dies kann zu einer höheren Kundenzufriedenheit und zu einem nachhaltigen Geschäftserfolg führen.

Wie man Design Thinking in der Praxis anwendet

Die Anwendung von Design Thinking erfordert ein offenes Denken, Experimentierfreude und die Bereitschaft, aus Fehlern zu lernen. Im Folgenden sind einige Schritte, die man befolgen kann, um es in einer Organisation zu implementieren:

Man beginnt mit Schulungen und Workshops, um das Bewusstsein für Design Thinking zu schaffen und um die notwendigen Fähigkeiten zu entwickeln.

Zielsetzung ist die Förderung einer Kultur der Kreativität und Offenheit, in der neue Ideen willkommen sind und bei der man Fehler als Lernchancen sieht.

Design Thinking-Tools und -Techniken, wie Brainstorming, Storyboarding, Nutzerinterviews und Prototyping helfen dabei, kreative Lösungen zu entwickeln.

Es empfiehlt sich, vielfältige Teams zu bilden, die verschiedene Perspektiven und Fähigkeiten einbringen, um kreative Lösungen zu entwickeln bzw. um die Betrachtung von Herausforderungen aus verschiedenen Blickwinkeln zu ermöglichen.

Schließlich kann man den Erfolg von Design Thinking-Initiativen messen, um zu sehen, ob sie zu den gewünschten Ergebnissen führen und wo man gegebenenfalls ansetzt, um weitere Anpassungen vorzunehmen.

Zusammenhang Design Thinking und DevOps

Der Zusammenhang zwischen Design Thinking und DevOps liegt in ihrer gemeinsamen Ausrichtung auf kontinuierliche Verbesserung, Benutzerorientierung und Kollaboration. Man kann Design Thinking am Anfang des Produktentwicklungsprozesses anwenden, um Benutzerbedürfnisse zu verstehen, Probleme zu definieren und innovative Lösungen zu entwerfen. Im Anschluss kann man DevOps nutzen, um diese Lösungen schnell und effizient zu entwickeln, zu testen und zu releasen, wobei man auch eine Kultur der Zusammenarbeit und des kontinuierlichen Verbesserns fördert.

Wenn man Design Thinking und DevOps zusammen anwendet, kann es dabei helfen, Produkte und Dienstleistungen zu erschaffen, die nicht nur technisch hochwertig und zuverlässig sind, sondern auch die Bedürfnisse und Erwartungen der Benutzer in einem größeren Umfang erfüllen. Diese Synergie kann zu höherer Benutzerzufriedenheit, schnellerer Markteinführungszeit und insgesamt besseren Geschäftsergebnissen führen.

Fazit:

Design Thinking ist eine mächtige Methode, um Innovation zu fördern und um Probleme zu lösen. Indem man Empathie für den Nutzer entwickelt, kreatives Denken fördert und durch iterative Prozesse lernt, kann man Produkte und Dienstleistungen entwickeln, die wirklich den Bedürfnissen der Kunden entsprechen.

Ganz unabhängig davon, ob man ein neues Produkt entwickelt, eine Dienstleistung verbessert oder eine geschäftliche Herausforderung bewältigen möchte, Design Thinking kann dabei helfen, effektive und innovative Lösungen zu finden. Es ist eine Reise, die Neugier, Empathie und Mut erfordert, aber die Ergebnisse können es wert sein.

Der Beitrag Design Thinking – Kreativität und Innovation fördern erschien zuerst auf CEOsBay.

Übrigens ist BDD aus der testgetriebenen Entwicklung hervorgegangen. Über BDD bzw. Behavior Driven Development habe ich bereits gestern geschrieben.

Klassisch und fast schon nostalgisch hat man und praktiziert man die Entwicklung heute noch nach dem Wasserfall- oder dem V-Modell-Prinzip. Man entwickelt die Tests parallel zum und unabhängig vom zu testenden System oder sogar erst nachdem die Anwendung „fertiggestellt“ wurde. Aufgrund dieser Tatsache resultiert meist daraus, dass der Code schwer testbar ist und somit der Aufwand für die Tests verhältnismäßig hoch ausfällt. Darüber hinaus kommt es auch vor, dass die Tests nicht die gewünschten oder erforderlichen Testabdeckungen und Ergebnisse liefern, die man sich erhofft.

Dies kann unter anderem daran liegen, dass die fehlende oder mangelnde Testbarkeit des Systems auf die Nutzung von Fremdkomponenten zurückzuführen ist. Auch die Verweigerung einer Investition in nicht-funktionale Programmteile seitens der Entscheider bzw. Unternehmensführung kann ein Grund dafür sein. So im Sinne von, „Arbeit, von der man später im Programm nichts sieht, seien vergeudete Ressourcen.“ Die Erstellung von Tests unter Zeitdruck, rein um die gewünschte Testabdeckung zu erzielen ist ebenfalls ein Grund dafür. Nicht selten, ist es aber auch die Nachlässigkeit und mangelnde Disziplin der Entwickler bei der Testerstellung. An dieser Stelle sein auch das White-Box-Testing zu erwähnen, den ich aber in einem zukünftigen Beitrag thematisieren werde.

Die Methode der testgetriebenen Entwicklung versucht den Nachteilen entgegenzuwirken und dabei auch ein auf die Aufgabenstellung der Software besser angepasstes und wartbareres Softwaredesign zu liefern.

Alles in allem ist es eine Tatsache, dass man bei der Anwenung von testgetriebener Entwicklung im Schnitt bis zu 45 Prozent aller Fehler erkennen bzw. vermeiden kann. Im Vergleich dazu, werden beim reinen Einsatz von Unittests im Schnitt nur bis zu 30 Prozent der Fehler erkannt.

Wie funktioniert TDD?

Bei der testgetriebenen Entwicklung ist zwischen dem Testen im Großen (Integrationstests, Systemtests, Akzeptanztests) und dem Kleinen Modultests (Unit Tests) zu unterscheiden.

Testgetriebene Entwicklung mit Unit-Tests (Stichwort Tests First bzw. Middle-Out-TDD)

Man schreibt Unit-Tests in der Regel vor der eigentlichen Entwicklung der Anwendung. Es ist nicht festgelegt, ob der Entwickler, der die Implementierung vornimmt, auch die Unit-Tests erstellt. Es ist erlaubt, dass mehrere fehlschlagende Unit-Tests gleichzeitig existieren. Die Umsetzung des von einem Unit-Test geforderten Verhaltens in der Anwendung kann zeitlich verschoben werden.

Die Methode Tests First kann als Vorstufe der testgetriebenen Entwicklung betrachtet werden.

TDD nach Kent Beck

Man entwickelt Unit-Tests und die mit ihnen getesteten Units stets parallel. Die eigentliche Entwicklung erfolgt in kleinen, wiederholten Mikroiterationen. Eine solche Iteration, die nur wenige Minuten dauern sollte, hat drei Hauptteile, die man im englischen schlicht als Red, Green und Refactor bezeichnet.

1. Red: Schreibe einen Test, der ein neues zu programmierendes Verhalten (die Funktionalität) prüfen soll. Dabei fängt man mit dem einfachsten Beispiel an. Ist die Funktion schon älter, kann dies auch ein bekannter Fehler oder eine neu zu implementierende Funktionalität sein. Dieser Test wird vom vorhandenen Programmcode erst einmal nicht erfüllt und muss folglich fehlschlagen.
   
2. Green: Ändere den Programmcode mit möglichst wenig Aufwand ab und ergänze ihn, bis er nach dem anschließend angestoßenen Testdurchlauf alle Tests besteht.
   
3. Räume dann im Code auf (Refactoring): Entferne Wiederholungen (Duplizierten Code), abstrahiere wo nötig, richte ihn nach den verbindlichen Code-Konventionen aus. In dieser Phase darf kein neues Verhalten eingeführt werden. Nach jeder Änderung werden die Tests ausgeführt. Der Fehlschlag der Tests verbietet es, die offenbar fehlerhafte Änderung in den bereits genutzten Code zu übernehmen. Ziel des Aufräumens ist es, den Code schlicht, elegant und verständlich zu machen.

Diese drei Schritte wiederholt man so lange und so oft, bis die bekannten Fehler bereinigt sind, der Code die gewünschte Funktionalität liefert und dem Entwickler keine sinnvollen weiteren Tests mehr einfallen, die vielleicht noch scheitern könnten. Die so behandelte programmtechnische Einheit (Unit) wird dann als einstweilen fertig angesehen. Die gemeinsam mit ihr geschaffenen Tests werden beibehalten, damit auch nach künftigen Iterationen und Änderungen getestet werden kann, ob die schon erreichten Aspekte des Verhaltens weiterhin erfüllt werden.

Damit die – auch Transformationen genannten – Änderungen in Schritt 2 zum Ziel führen, muss jede Änderung zu einer allgemeineren Lösung führen. Sie darf also nicht etwa nur den aktuellen Testfall auf Kosten anderer behandeln. Tests, die immer mehr ins Detail gehen, treiben den Code so zu einer immer allgemeineren Lösung. Die Beachtung der Transformationsprioritäten führt dabei regelmäßig zu effizienteren Algorithmen und damit Anwendungen. Die konsequente Befolgung dieser Vorgehensweise ist eine evolutionäre Entwurfsmethode, indem jede der einzelnen Änderungen bzw. Iterationen das System von Natur aus weiterentwickelt.

Testgetriebene Entwicklung mit System- oder Akzeptanztests (Stichwort Outside-In-TDD)

Wie bereits erwähnt, entwickelt man Systemtests bei der testgetriebenen Entwicklung immer vor dem System selbst oder aber man erstellt zumindest das Konzept dafür. Aufgabe der Systementwicklung ist bei testgetriebener Entwicklung nicht mehr, wie klassisch, schriftlich formulierte Anforderungen zu erfüllen, sondern spezifizierte Systemtests zu bestehen.

Akzeptanztestgetriebene Entwicklung (ATDD)

ATDD ist zwar mit testgetriebener Entwicklung verwandt, unterscheidet sich jedoch in der Vorgehensweise von testgetriebener Entwicklung. Akzeptanztestgetriebene Entwicklung ist ein Kommunikationswerkzeug zwischen dem Kunden bzw. den Anwendern, den Entwicklern und den Testern. Es soll sicherstellen, dass die Anforderungen gut beschrieben sind. Akzeptanztestgetriebene Entwicklung verlangt keine Automatisierung der Testfälle, wenngleich diese für das Regressionstesten hilfreich sind. Die Tests bei akzeptanztestgetriebener Entwicklung müssen dafür auch für Nicht-Entwickler lesbar sein. Die Tests der testgetriebenen Entwicklung können in vielen Fällen aus den Tests der akzeptanztestgetriebenen Entwicklung abgeleitet werden.

Der Beitrag TDD – Test Driven Development – Qualitativ hochwertige Software von Anfang an erschien zuerst auf CEOsBay.