Was ist Syntax?

Der Begriff stammt aus dem Griechischen und bedeutet so viel wie „Zusammenstellung“ oder „Ordnung“. In der Linguistik beschreibt Syntax die Regeln, nach denen Wörter in einer Sprache zu sinnvollen Sätzen angeordnet werden. In der Informatik bezeichnet sie die Struktur und Grammatik von Programmiersprachen.

Ob in einer natürlichen Sprache wie Deutsch oder in einer Programmiersprache wie Python – ohne eine klar definierte Syntax wäre die Verständigung unmöglich oder zumindest erheblich erschwert.

In der Sprache

In der menschlichen Sprache sorgt die Syntax dafür, dass wir verständliche und korrekte Sätze bilden können. Ein einfaches Beispiel:

• Richtig: „Der Hund jagt die Katze.“
• Falsch: „Hund die Katze der jagt.“

Im zweiten Fall ist der Satz grammatikalisch falsch und schwer verständlich. Auch wenn alle Wörter vorhanden sind, fehlt die korrekte Anordnung, um den Satz sinnvoll zu machen.

Syntax in der Programmierung

In der Informatik bestimmt die Syntax einer Programmiersprache, wie man Code schreiben muss, damit der Computer versteht und weiß, was es ausführen soll.

Hier ein Beispiel mit Python:

Korrekt:

print("Hallo, Welt!")

Falsch:

print "Hallo, Welt!"

Der zweite Code führt zu einem Syntaxfehler, da moderne Versionen von Python Klammern für die print-Funktion verlangen.

Warum ist Syntax so wichtig?

Es ist die Basis für klare und eindeutige Kommunikation – sei es in der Sprache oder in der Programmierung. Ist sie fehlerhaft, kann sie zu Missverständnissen oder sogar kompletten Fehlfunktionen führen. In der Programmierung kann ein kleiner Fehler in der Syntax dazu führen, dass ein ganzes Programm nicht läuft oder unerwartete Fehler produziert.

Fazit

Egal ob in der natürlichen Sprache oder in der Programmierung – sie ist unerlässlich für eine funktionierende Kommunikation. Während sie in der Sprache Flexibilität erlaubt, ist sie in der Informatik oft streng festgelegt. Wer sich mit Syntax auskennt und sie beherrscht, hat sowohl in der Kommunikation als auch in der Programmierung einen entscheidenden Vorteil.

Hast du schon einmal Syntaxfehler erlebt? Teile deine Erfahrungen in den Kommentaren!

Der Beitrag Syntax – Unsichtbares Regelwerk der Kommunikation und des Codes erschien zuerst auf CEOsBay.

Definition – Strukturelle Tests

Auch bekannt als White-Box-Tests oder Glasbox-Tests, konzentrieren sich auf die interne Perspektive einer Softwareanwendung. Im Gegensatz zu funktionalen Tests, die nur die Anforderungen von Außen prüfen, bieten strukturelle Tests eine vollständige Prüfung der internen Logik und Struktur einer Anwendung.

Notwendigkeit

Es gibt mehrere Vorteile. Sie identifizieren verborgene Fehler, die andere Testmethoden möglicherweise übersehen, erhöhen die Codeabdeckung und verbessern die Qualität der Software. Sie ermöglichen auch eine bessere Identifizierung von Problembereichen, wodurch man effektivere Fehlerbehebungsmaßnahmen einleiten kann.

Durchführung von strukturellen Tests

Strukturelle Tests erfordern ein gründliches Verständnis der internen Softwarearchitektur. Dies schließt Wissen über Datenflüsse, Kontrollstrukturen, Schnittstellen und weitere Details ein. Tester führen eine detaillierte Analyse der Codebasis durch, um Schwachstellen und mögliche Fehlerquellen zu identifizieren. Anschließend erstellt man geeignete Testfälle und führt diese aus, um die Funktionsweise der Anwendung zu überprüfen.

Typen – Strukturelle Tests

Verschiedene Typen struktureller Tests richten sich an spezifische Bereiche der Codebasis. Einige der gängigen Arten sind Kontrollflusstests, Datenflusstests, Pfadtests und Schleifentests. Jeder dieser Tests konzentriert sich auf ein bestimmtes Aspekt des Codes und liefert wichtige Informationen über dessen Leistung und Zuverlässigkeit.

Fazit

Zusammenfassend lässt sich sagen, dass strukturelle Tests ein effektives Mittel sind, um die Qualität und Zuverlässigkeit von Softwareanwendungen zu gewährleisten. Durch eine detaillierte Überprüfung der internen Struktur einer Anwendung tragen sie dazu bei, verborgene Fehler zu identifizieren und sicherzustellen, dass alle Komponenten korrekt funktionieren. Mit ihrer Hilfe kann das Vertrauen in die entwickelte Software erhöht und das Risiko von Fehlern reduziert werden. Es lohnt sich also, in diese Tests zu investieren und sie als festen Bestandteil des Softwaretestprozesses zu etablieren.

Der Beitrag Strukturelle Tests in der Softwareentwicklung erschien zuerst auf CEOsBay.

Die Wurzeln des Pestizid-Paradoxons liegen in der Landwirtschaft. Wenn ein Bauer ständig dasselbe Pestizid verwendet, um seine Ernte zu schützen, entwickeln schließlich die Schädlinge, die überleben, eine Immunität gegen dieses spezifische Pestizid. Im Laufe der Zeit verliert das Pestizid seine Wirksamkeit. Analog dazu, in der Softwareentwicklung, wenn Entwickler und Tester immer wieder dieselben Tests anwenden, werden sie nur die Fehler finden und beheben, die diese Tests identifizieren können.

Das Pestizid-Paradoxon in der Softwareentwicklung verweist also auf die Notwendigkeit, kontinuierlich neue und verschiedene Testfälle zu erstellen. In der modernen agilen Entwicklung (Siehe Beitrag „Agiles Manifest„), bei der man Software kontinuierlich ändert und verbessert, muss das Testen Schritt halten und sich anpassen.

Mit der Zeit entdecken Testfälle weniger und weniger Bugs, genau wie Pestizide, die ihre Wirksamkeit gegen Schädlinge verlieren. Um Qualität und Sicherheit zu gewährleisten, muss man die Testszenarien daher regelmäßig überprüfen und aktualisieren. Ebenso muss man neue Tests entwickeln, um auf veränderte oder neue Funktionen zu reagieren.

Ein weiterer zentraler Aspekt des Pestizid-Paradoxons in der Softwareentwicklung ist die Notwendigkeit einer vielfältigen Teststrategie. Dazu gehören Funktionstests, Integrationstests, Leistungstests, Sicherheitstests und Benutzerakzeptanztests. Ein vielfältiges Test-Portfolio, das verschiedene Aspekte und Ebenen der Software abdeckt, erhöht die Wahrscheinlichkeit, dass mehr Fehler entdeckt und behoben werden.

Das Pestizid-Paradoxon ist somit eine starke Erinnerung daran, dass Veränderung in der Softwareentwicklung nicht nur unausweichlich, sondern notwendig ist. Es lehrt uns, dass wir uns nicht auf bewährte Testverfahren verlassen sollten. Es macht Sinn, ständig neue Methoden und Ansätze zu entwickeln und anzuwenden, um Softwarequalität und -sicherheit zu gewährleisten.

Der Beitrag Pestizid-Paradoxon – Resistenz von Bugs und Fehlern erschien zuerst auf CEOsBay.

Was ist eine API?

Eine API (Application Programming Interface) ist eine Sammlung von Protokollen, Routinen und Tools zur Interaktion zwischen verschiedenen Softwareanwendungen. Vereinfacht ausgedrückt, ermöglicht eine API die Kommunikation zwischen zwei Softwareanwendungen, indem sie dem Entwickler die Möglichkeit bietet, bestimmte Funktionen oder Daten einer Anwendung zu verwenden, ohne sich um deren interne Implementierung kümmern zu müssen.

Funktionsweise von APIs

APIs ermöglichen die Kommunikation zwischen Anwendungen, indem sie standardisierte Anfragen und Antworten verwenden. In der Regel bezeichnet man eine Anwendung, die eine API bereitstellt, als Server. Die Anwendung, die die API nutzt, bezeichnet man als Client. Der Client sendet eine Anfrage an den Server, der diese Anfrage bearbeitet und daraufhin eine Antwort zurücksendet.

Die Kommunikation erfolgt meist über das https-Protokoll und basiert auf einem Request-Response-Modell. Eine API-Anfrage enthält normalerweise Informationen wie die gewünschte Aktion, die zu verwendenden Daten und den Authentifizierungsschlüssel. Die Antwort beinhaltet dann das Ergebnis der Aktion, zusammen mit den angeforderten Daten, falls vorhanden.

Arten von APIs

Es gibt verschiedene Arten von APIs, je nach Zugriffsbeschränkungen und Anwendungsbereich. Hier sind einige der gebräuchlichsten Typen:

Öffentliche APIs: Auch als externe oder offene APIs bekannt, sind APIs, die für die Öffentlichkeit zugänglich sind. Entwickler können sie nutzen, um angebotene Dienste in ihre Anwendungen zu integrieren.

Private APIs: Diese APIs sind nur für einen bestimmten Entwicklerkreis oder innerhalb eines Unternehmens zugänglich. Entwickler verwenden sie, um interne Prozesse und Dienstleistungen zu unterstützen.

Partner-APIs: Partner-APIs sind für eine ausgewählte Gruppe von Entwicklern oder Unternehmen zugänglich, die eine Partnerschaft oder Geschäftsvereinbarung mit dem API-Anbieter eingegangen sind.

API-Protokolle und Datenformate

APIs nutzen verschiedene Protokolle und Datenformate, um Anfragen und Antworten zu strukturieren. Die gebräuchlichsten sind:

REST (Representational State Transfer): Ein Architekturstil, der auf der Verwendung von standardisierten https-Anfragen und Antworten basiert. REST-APIs sind ressourcenorientiert und relativ leicht verständlich. Man verwendet sie häufig mit JSON (JavaScript Object Notation) als Datenformat.

SOAP (Simple Object Access Protocol): Ein älteres Protokoll, das auf XML-basierten Nachrichten beruht und strenge Regeln für die Kommunikation vorschreibt. SOAP-APIs sind tendenziell komplexer als REST APIs, bieten jedoch eine höhere Sicherheit und formelle Spezifikationen.

GraphQL: Eine relativ neue API-Technologie, von Facebook. Im Gegensatz zu REST und SOAP ermöglicht GraphQL eine flexiblere Datenabfrage, indem der Client genau die benötigten Informationen anfordern kann. GraphQL verwendet eine eigene Abfragesprache und unterstützt sowohl Lese- als auch Schreiboperationen.

gRPC: Ein von Google entwickeltes API-Framework, das auf Protocol Buffers, als binäres Datenformat setzt und für hohe Leistungsfähigkeit und Skalierbarkeit optimiert ist. gRPC eignet sich besonders für Mikroservices und hochperformante Anwendungen. Ich gehe davon aus, dass ich darüber in naher Zukunft einen separaten Beitrag schreibe.

API-Authentifizierung und -Sicherheit

Um den Zugriff auf APIs zu kontrollieren und deren Sicherheit zu gewährleisten, kann man verschiedene Authentifizierungs- und Autorisierungsmechanismen einsetzen. 

Einige der gängigen Methoden sind:

API-Schlüssel: Ein einfacher und weit verbreiteter Ansatz, bei dem der Entwickler einen eindeutigen Schlüssel erhält, den man bei jeder API-Anfrage übermittelt, um den Zugriff zu autorisieren.

OAuth: Ein offener Standard für Authentifizierung und Autorisierung, der es ermöglicht, Anwendungen den Zugriff auf Benutzerdaten von Drittanbietern zu gewähren, ohne dass die Anwendung das Passwort des Benutzers kennen muss. Sozialen Netzwerke und große Webdienste wie Google und Facebook nutzen häufig OAuth.

JWT (JSON Web Tokens): Eine kompakte, selbstständige Methode zur sicheren Übertragung von Informationen zwischen Parteien in Form von Objekten. Man nutzt JWTs häufig in Kombination mit OAuth und anderen Authentifizierungsschemata.

Best Practices bei der Verwendung von APIs

Die erfolgreiche Nutzung von APIs erfordert einige Best Practices, um sicherzustellen, dass Anwendungen effizient und sicher arbeiten:

Dokumentation: Eine gut dokumentierte API erleichtert Entwicklern das Verständnis und die Integration der API in ihre Anwendungen.

Fehlerbehandlung: Eine robuste Fehlerbehandlung ist entscheidend, um sicherzustellen, dass Anwendungen auch bei unerwarteten Fehlern oder Ausfällen der API korrekt funktionieren.

Ressourcenmanagement: Bei der Verwendung von APIs ist es wichtig, auf Ressourcenmanagement zu achten. Dies erreichet man beispielsweise, indem man Ratenbegrenzungen (Rate Limiting) einhält, um die Anzahl der Anfragen pro Zeiteinheit zu begrenzen und die Belastung des API-Servers zu reduzieren.

Sicherheit: Bei der Arbeit mit APIs sollte man auf die Sicherheit der Anwendung und der API achten. Durch die Verwendung von Verschlüsselungstechniken und sicheren Authentifizierungsmethoden lässt sich dies relativ einfach realisieren.

Zukünftige Trends bei APIs:

APIs gewinnen weiterhin an Bedeutung, da sich die Technologielandschaft weiterentwickelt. Um neue Anforderungen und Herausforderungen zu bewältigen, müssen sich auch die APIs weiterentwickeln.

Einige zukünftige Trends bei APIs sind:

Hypermedia-APIs: Ein aufkommender Trend im Bereich der REST APIs ist die Verwendung von Hypermedia-Elementen zur Dynamisierung der API-Kommunikation. Hypermedia-APIs stellen Links und Aktionen in den API-Antworten bereit, um den Client zur Verfügung stehende Funktionen und Ressourcen dynamisch zu erkennen. Dadurch kann man die Kopplung zwischen Client und Server reduzieren.

API-Orchestrierung: Mit der zunehmenden Verbreitung von Mikroservices und verteilten Systemen gewinnen die API-Orchestrierung und -Aggregationen immer mehr an Bedeutung, um eine effiziente Kommunikation und Integration zwischen verschiedenen Diensten zu gewährleisten.

Edge-Computing und APIs: Mit der zunehmenden Verbreitung von IoT-Geräten und Edge-Computing-Technologien ist die Rolle von APIs bei der Bereitstellung von Echtzeitdaten und Funktionen für Geräte am Netzwerkrand essenziell.

KI-gestützte APIs: Integration von künstlicher Intelligenz und maschinellem Lernen, um leistungsfähige Funktionen wie Spracherkennung, Computer Vision bzw. Bildanalyse und datengesteuerte Vorhersagen bereitzustellen.

API-Sicherheit und Datenschutz: Angesichts der wachsenden Besorgnis über Datensicherheit und Datenschutz nimmt man APIs zunehmend unter die Lupe, um sicherzustellen, dass sie den geltenden Datenschutzbestimmungen entsprechen und angemessene Sicherheitsmaßnahmen implementieren.

Fazit

APIs sind ein grundlegendes Element moderner Softwareentwicklung und ermöglichen eine effiziente und skalierbare Kommunikation zwischen verschiedenen Anwendungen und Diensten. Durch das Verständnis der verschiedenen API-Typen, Protokolle, Datenformate und Best Practices können Entwickler ihre Anwendungen effektiv erweitern und mit externen Diensten integrieren. Indem man auf API-Dokumentation, Fehlerbehandlung, Ressourcenmanagement und Sicherheit achtet, kann man sicherstellen, dass die API-Integration erfolgreich ist und zur Verbesserung der Gesamtanwendung beiträgt.

Der Beitrag API – Nahtlose Verbindungen für Innovationen erschien zuerst auf CEOsBay.

Was ist Clean Code?

Clean Code bezieht sich auf den Ansatz, Code so zu schreiben, dass er leicht verständlich, wartbar und erweiterbar ist. Das Konzept wurde von Robert C. Martin, auch bekannt als „Uncle Bob“, in seinem Buch „Clean Code: A Handbook of Agile Software Craftsmanship“ populär gemacht. Im Kern geht es darum, Softwareentwicklung als Handwerk zu betrachten und stets auf hohe Qualität und Präzision in der Codegestaltung zu achten.

Warum ist es wichtig?

Sauberer Code bietet verschiedene Vorteile, sowohl für den Entwickler selbst, für das gesamte Team und meiner Meinung nach auch für die ganze Welt.

• Verständlichkeit: Clean Code ist einfacher zu lesen und zu verstehen. Das hilft Entwicklern, sich schneller mit dem Code vertraut zu machen und Fehler oder Verbesserungsmöglichkeiten schneller zu erkennen.
• Wartbarkeit: Sauberer Code ist leichter zu warten, da er klar strukturiert und weniger anfällig für Fehler oder unerwartete Probleme ist.
• Effizienz: Da Clean Code einfacher zu verstehen ist, kann das Team schneller arbeiten und die Produktivität steigt.
• Zusammenarbeit: Ein sauberer Code erleichtert die Zusammenarbeit im Team, da jeder den Code anderer Entwickler leichter lesen und verstehen kann.

Prinzipien von Clean Code

Es gibt viele Prinzipien und Praktiken, die beim Schreiben von sauberem Code helfen können. Einige der wichtigsten sind:

• Lesbarkeit: Der Code sollte leicht lesbar und verständlich sein. Das bedeutet, dass man Variablen, Funktionen und Klassen sinnvoll benamt und ihre Funktion leicht erkennbar ist. Kommentare setzt man sparsam ein, um den Code nicht zu überfrachten.

• Einfachheit: Man hält den Code so einfach wie möglich, ohne unnötige Komplexität oder Verwirrung. Das bedeutet, dass man sich auf das Wesentliche konzentrieren und abstrakte Konzepte wie Design Patterns oder Funktionen nur verwendet, wenn sie tatsächlich nützlich sind.

• Modularität: Man teilt den Code in kleine unabhängige Module auf, die jeweils eine bestimmte Funktion erfüllen. Dadurch wird der Code leichter zu verstehen und zu warten.

• Wiederverwendbarkeit: Man schreibt den Code so, dass die Wiederverwendbarkeit gewährleistet ist. Dies bedeutet, dass Funktionen oder Klassen, die eine bestimmte Aufgabe erfüllen, generisch genug sind, um in verschiedenen Situationen Verwendung zu finden.

Clean Code in der Praxis

Hier sind einige konkrete Schritte, die man beim Schreiben von Clean Code in der Praxis beachten sollte:

• Variablen-, Funktions- und Klassennamen: Man wählt sinnvolle, beschreibende Namen, die klar machen, was eine Variable, Funktion oder Klasse macht. Die Vermeidung von Abkürzungen oder unverständliche Namen ist eines der obersten Gebote.

• Single Responsibility Principle (SRP): Jede Funktion oder Klasse sollte nur eine einzige Verantwortung haben. Dies bedeutet, dass sie nur einen Aspekt des Problems lösen sollte, um den Code einfacher und leichter zu warten.

• Funktionen und Methoden: Man hält Funktionen und Methoden kurz und konzentrieren sich darauf, dass sie eine einzige Aufgabe erfüllen. Eine Funktion oder Methode sollte in der Regel nicht länger als 20 Zeilen sein, um ihre Verständlichkeit zu gewährleisten.

• KISS (Keep It Simple, Stupid) Prinzip: Man versucht, den Code so einfach wie möglich zu halten und unnötige Komplexität zu vermeiden. Wenn es eine einfachere Lösung gibt, zieht man diese der komplexeren vor.

• Don’t Repeat Yourself (DRY) Prinzip: Man vermeidet doppelten Code, indem man wiederverwendbare Funktionen oder Klassen erstellt. Das verringert die Wahrscheinlichkeit von Fehlern und macht den Code leichter zu warten.

• Code-Kommentare: Man sollte Kommentare dazu verwenden, den Zweck und die Funktionsweise von Code-Teilen zu erläutern, die nicht sofort offensichtlich sind. Man sollte jedoch nicht zu viele Kommentare schreiben, da dies den Code unübersichtlich machen kann.

• Fehlerbehandlung: Die Implementierung einer angemessenen Fehlerbehandlung sollte unabdingbar sein, um unerwartete Probleme zu erkennen und angemessen darauf zu reagieren. Die Verwendung von Exceptions und try-catch-Blöcken, kann eine gute Lösung darstellen, um Fehler abzufangen und entsprechend darauf zu reagieren.

• Testgetriebene Entwicklung (TDD): Man schreibt zuerst Tests, bevor man den eigentlichen Code entwickelt. Auf diese Weise kann man sicherstellen, dass die Implementierung den gewünschten Anforderungen entspricht und weniger fehleranfällig ist. Siehe hierzu meinen Beitrag über Test Driven Development.

• Kontinuierliche Integration (CI) und Continuous Deployment (CD): Man verwendet CI/CD-Tools, um den Code regelmäßig zu testen und automatisch zu deployen. Dies stellt sicher, dass der Code immer auf dem neuesten Stand ist und das man potenzielle Probleme schnell erkennen kann.

Fazit

Im Grunde genommen ist dies für mich eine relativ neue Angelegenheit, da ich in der Vergangenheit schon recht of den Code einfach reingehackt habe, da ich mich unter Zeitdruck gefühlt habe. Ich ertappe mich hin und wieder immer noch dabei und dies sehr oft, wie ich auf alte Gewohnheiten und Muster zurückgreife. Doch dies sollte sich hoffentlich in den nächsten Monaten und Jahren auf ein Minimum reduzieren lassen. Ich bin davon überzeugt, dass Clean Code ein wesentlicher Bestandteil einer erfolgreichen Softwareentwicklung ist. Indem man sich auf Lesbarkeit, Einfachheit, Modularität und Wiederverwendbarkeit konzentriert, kann man den eigenen Code nicht nur leichter verstehen, sondern auch schneller und effizienter arbeiten. Durch die Anwendung der oben genannten Prinzipien und Praktiken kann man den Code verbessern und letztendlich zu erfolgreichen, wartungsfreundlichen Softwareprodukten beitragen.

Der Beitrag Clean Code – Elegante Lösungen für effiziente und wartungsfreundliche Software erschien zuerst auf CEOsBay.

Kurze Zeitreise

Die ISO-Norm 25010 ist aus dem Bedürfnis heraus entstanden, ein international anerkanntes und einheitliches Rahmenwerk für die Bewertung und Verbesserung von Software- und Systemqualität bereitzustellen. Die Geschichte von ISO 25010 ist eng mit der Entwicklung der ISO/IEC 25000-Serie (SQuaRE) verbunden, die sich aus früheren Standards und Modellen zur Softwarequalität entwickelt hat.

Entstehung

Und wenn man es genau nimmt, geht die Geschichte noch weitaus früher los. Und zwar mit McCall’s Quality Model aus dem Jahr 1977. Dieses Modell definierte 11 Qualitätsfaktoren, wie Zuverlässigkeit, Effizienz und Wartbarkeit, die die Softwarequalität beeinflussen bzw. mit Boehm’s Quality Model aus dem Jahr 1978. Wobei letzteres Modell sieben Hauptqualitätsmerkmale vorschlug, die die Softwarequalität beeinflussen. Dabei beispielsweise die Portabilität, Zuverlässigkeit und Verständlichkeit.

Die Internationale Organisation für Normung (ISO) und die Internationale Elektrotechnische Kommission (IEC) entwickelten gemeinsam den ISO/IEC 9126-Standard, der man 1991 veröffentlichte. Dieser Standard führte ein hierarchisches Qualitätsmodell ein, dass aus sechs Hauptqualitätsmerkmalen (Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Wartbarkeit und Übertragbarkeit) und mehreren Unterkriterien bestand. ISO/IEC 9126 legte den Grundstein für die Entwicklung der ISO/IEC 25000-Serie und ISO 25010.

ISO/IEC 25000-Serie

Die ISO/IEC 25000-Serie, auch als Systems and Software Quality Requirements and Evaluation (SQuaRE) bekannt, hat man entwickelt, um die verschiedenen Standards und Modelle zur Softwarequalität zu konsolidieren und eine umfassende, international anerkannte Normenserie für Software- und Systemqualität zu schaffen. Die Entwicklung von SQuaRE begann im Jahr 2001 und beinhaltete die Überarbeitung und Erweiterung des ISO/IEC 9126-Standards.

Folglich fand die Veröffentlichung von ISO 25010 im Jahr 2011 statt und ersetzte den früheren ISO/IEC 9126-Standard. Es führte zwei Qualitätsmodelle ein. Das Produktqualitätsmodell und das Qualitäts-in-Use-Modell. Die Hauptqualitätsmerkmale des Produktqualitätsmodells hat man von sechs auf acht erweitert, und die Unterkriterien hat man entsprechend aktualisiert. Sicherheit war nunmehr ein eigenständiges Hauptqualitätsmerkmal und die bestehenden Hauptqualitätsmerkmale hat man weiter verfeinert bzw. erweitert, um die Qualität von Software- und Softwaresystemen umfassender zu erfassen.

Die Entstehung von ISO 25010 ist das Ergebnis von jahrzehntelanger Forschung, Entwicklung und Konsolidierung von Best Practices und Standards zur Bewertung und Verbesserung der Software- und Systemqualität.

Sei der Veröffentlichung, hat ISO 25010 als zuverlässiger und anerkannter Standard für die Beurteilung der Softwarequalität gedient und den Entwicklern, Testern und Projektmanagern dabei geholfen, qualitativ hochwertige Produkte zu entwickeln und bereitzustellen.

Die dynamische Norm

Die ISO/IEC 25000-Serie und ISO 25010 sind nicht statisch. Man überprüft und aktualisiert die Inhalte kontinuierlich, um sich den stetig ändernden Anforderungen der Software- und Systementwicklung anzupassen. Die International Organization for Standardization (ISO) und die International Electrotechnical Commission (IEC) arbeiten gemeinsam daran, die Standards auf dem neuesten Stand zu halten und sie an neue Technologien, Methoden und Best Practices anzupassen.

Es ist wichtig zu beachten, dass man die ISO-Normen in einem Konsensprozess entwickelt, bei dem Experten aus verschiedenen Ländern und Organisationen zusammenarbeiten. Dies stellt sicher, dass die Normen umfassend und von hoher Qualität sind und die Bedürfnisse der verschiedenen Interessengruppen berücksichtigen.

Qualitätsmodelle

ISO 25010 bietet zwei Qualitätsmodelle: das Produktqualitätsmodell und das Qualitäts-in-Use-Modell. Das Produktqualitätsmodell bezieht sich auf die Qualität des Softwareprodukts selbst, während das Qualitäts-in-Use-Modell die Qualität aus der Perspektive des Endbenutzers bewertet.

Produktqualitätsmodell

Das Produktqualitätsmodell besteht aus acht Hauptqualitätsmerkmalen, die wiederum in mehrere Unterkriterien unterteilt sind. Die Hauptqualitätsmerkmale sind:

Funktionalität

Die Fähigkeit der Software, die geforderten Funktionen zu erfüllen, mit den Unterkriterien:

• Angemessenheit
• Richtigkeit
• Ordnungsmäßigkeit
• Interoperabilität
• Sicherheit

Leistungsfähigkeit

Die Fähigkeit der Software, in Bezug auf Leistung, Verarbeitungsgeschwindigkeit und Reaktionszeit auf Anforderungen zu reagieren. Mit den Unterkriterien:

• Zeitverhalten
• Ressourcenausnutzung

Kompatibilität

Die Fähigkeit der Software, in einer gemeinsamen Umgebung mit anderen Systemen oder Softwareprodukten zu interagieren. Mit den Unterkriterien:

• Koexistenz
• Interoperabilität

Benutzbarkeit

Die Fähigkeit der Software, von Benutzern effizient und zufriedenstellend genutzt zu werden. Mit den Unterkriterien:

• Verständlichkeit
• Erlernbarkeit
• Bedienbarkeit
• Attraktivität
• Barrierefreiheit

Zuverlässigkeit

Die Fähigkeit der Software, korrekt und zuverlässig zu funktionieren. Mit den Unterkriterien:

• Reife
• Fehlertoleranz
• Wiederherstellbarkeit

Sicherheit

Die Fähigkeit der Software, Vertraulichkeit, Integrität und Verfügbarkeit von Daten und Ressourcen zu gewährleisten. Mit den Unterkriterien:

• Vertraulichkeit
• Integrität
• Nichtabstreitbarkeit
• Rechenschaftspflicht
• Authentizität

Wartbarkeit

Die Fähigkeit der Software für Modifikationen und Verbesserbarkeit. Mit den Unterkriterien:

• Modularität
• Wiederverwendbarkeit
• Analysierbarkeit
• Modifizierbarkeit
• Testbarkeit (Hier möchte ich gerne auf TDD und BDD verweisen)

Übertragbarkeit

Die Fähigkeit der Software, von einer Umgebung in eine andere übertragen zu können. Mit den Unterkriterien:

• Anpassungsfähigkeit
• Installierbarkeit
• Konformität
• Austauschbarkeit

Qualitäts-in-Use-Modell

Das Qualitäts-in-Use-Modell beschreibt die Qualität aus der Perspektive des Endbenutzers und besteht aus fünf Hauptqualitätsmerkmalen:

Effektivität

Die Fähigkeit der Software, Benutzern dabei zu helfen, ihre Ziele präzise und vollständig zu erreichen.

Effizienz

Die Fähigkeit der Software, Benutzern zu ermöglichen, ihre Ziele mit angemessenen Ressourcen und minimalem Aufwand zu erreichen.

Zufriedenheit

Das Ausmaß, in dem die Software die Anforderungen und Erwartungen der Benutzer erfüllt.

Freiheit von Risiken

Die Fähigkeit der Software, potenzielle Schäden für Benutzer, Geschäftsprozesse oder die Umwelt zu minimieren.

Kontextabdeckung

Die Fähigkeit der Software, in verschiedenen Benutzer-, Organisations- und Umweltkontexten einsetzbar zu sein.

Fazit

Die ISO-Norm 25010 ist ein wertvolles Instrument zur Bewertung und Verbesserung der Qualität von Softwareprodukten und -systemen. Die Qualitätsmerkmale und Unterkriterien des Produktqualitätsmodells und des Qualitäts-in-Use-Modells ermöglichen eine umfassende Analyse und Bewertung verschiedener Aspekte der Softwarequalität. Softwareentwickler und Projektmanager können diese Modelle nutzen, um Qualitätsanforderungen zu definieren, Probleme zu identifizieren und Verbesserungen im Entwicklungsprozess umzusetzen. Dadurch entstehen qualitativ hochwertige Softwareprodukte, die den Bedürfnissen der Endbenutzer gerecht sind und zu einer höheren Zufriedenheit und besserer Performance beitragen.

Der Beitrag ISO-Norm 25010 – Leitfaden für herausragende Softwarequalität und vertrauenswürdige Systeme erschien zuerst auf CEOsBay.

Man verwendet den Ausdruck Modultest unter anderem bei frühen Teststufen, in denen man die inneren, detailliertesten Komponenten der Software testet. Gemäß Software Validation & Verification Plan sind diese Tests nur für Module mit geringer Kritikalität nicht notwendig. Im Grunde genommen bei Fehlern, die dem User nur geringfügige Unannehmlichkeiten bereiten.

In einer Abstraktion der verwendeten Programmiersprache, spricht man von Komponente oder Softwarebaustein. Den Test eines solchen einzelnen Softwarebausteins bezeichnet man auch allgemeiner als Komponententest.

Als Testbasis kann man in der Regel die komponentenspezifische Anforderung und das Softwaredesign der Komponente (auch Komponentenspezifikation genannt) heranziehen. Für Whitebox-Testfälle oder um Aussagen zur Codeüberdeckung zu erhalten, kann man zusätzlich den Sourcecode einer Komponente analysieren und diesen als Testbasis verwenden. Wobei dabei auch Tools wie Jacoco helfen können. Ob die Komponente auf einen Testfall richtig reagiert, muss man allerdings auch hier auf Basis der Design- und Anforderungsdokumente beurteilen.

Typische Testobjekte sind wie bereits beschrieben Programmunits, -Module bzw. Klassen. Aber auch Kommandozeilenskripte des Betriebssystems (Shell-Skripte), Datenbankskripte, Datenkonvertierungs- oder Migrationsprozeduren, Datenbankinhalte sowie Konfigurationsdaten können Testobjekte sein. Kennzeichnend ist in der Regel der isolierte Test eines einzelnen Softwarebausteins. Dies dient primär, um komponentenexterne Einflüsse beim Testen auszuschließen. Alle so ermittelten Fehler kann man so dem spezifischen Modul zuordnen.

Klar zu unterscheiden ist auf jeden Fall der Integrationstest, den ich in einem separaten Beitrag thematisiere. Bei einem Integrationstest konzentriert man sich auf die Wechselwirkung mit Nachbarkomponenten.

Die Erstellung solcher Tests ist in der Regel die Aufgabe eines Programmierers. Dies liegt zum einen daran, dass man ein ausgeprägtes Verständnis für die Programmiersprache in der die Anwendung geschrieben ist haben muss. Und zum anderen daran, dass man meist auch einen Testtreiber benötigt, dessen Programmierung in der Regel auch der Entwickler übernimmt.

Einordnung im Testprozess

Algorithmen auf Unitebene besitzen meist nur eine begrenzte Komplexität und man kann sie über klar definierte Schnittstellen aktivieren. Daher kann sie mit relativ wenigen Testfällen weitgehend vollständig testen. Dies gilt als Voraussetzung für die anschließende Teststufe. Dem Integrationstest, um dort die Testfälle auf das integrierte Zusammenwirken größerer Funktionsteile oder der gesamten Anwendung ausrichten zu können. Die modulspezifischen Detailkonstellationen lassen sich damit auf Stichproben beschränken, was die Anzahl der erforderlichen Testfälle signifikant reduziert.

Zum Vergleich: Ein Gerät wird erst dann als Ganzes getestet, wenn die Funktionsfähigkeit seiner Einzelteile gesichert ist.

Test des Vertrages und nicht der Algorithmen

Man testet bei Modultests gemäß dem Design-by-contract-Prinzip möglichst nicht die Interna einer Methode, sondern nur ihre externen Auswirkungen (Rückgabewerte, Ausgaben, Zustandsänderungen, Zusicherungen). Sind die internen Details der Methode geprüft (dies wird als White-Box-Testing bezeichnet), kann der Test fehlschlagen, obwohl sich die externen Auswirkungen nicht geändert haben. Daher empfiehlt man in der Regel das sogenannte Black-Box-Testing, bei dem man sich auf das Prüfen der externen Auswirkungen beschränkt.

Was sind die Vorteile von Unit Tests?

• Mittels automatisierter Unittests kann man im Schnitt 30 % der Fehler erkennen. Bei der Verwendung von TDD (Test Driven Development) kann man im Schnitt 45 % und im besten Fall 85 % der Fehler vermeiden.
• Fehler erkennt man durch Modultests bereits während der Entwicklung. Die durch Unittests vermiedenen Fehlerkosten sind daher gemäß der Rule of Ten (Dazu später mehr) um ein Vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen.
• Im Falle eines Fehlers kann man diesen sehr viel genauer eingrenzen und damit schneller finden und beheben.
• Die Tests erfüllen den Zweck einer lebenden Dokumentation. In Kombination mit einer sinnvollen Benamung der Objekte (Clean Code) können zusätzliche Dokumentationsmaßnahmen entfallen.
• Da einzelne Module nur wenige mögliche Codeausführungspfade besitzen, muss man viel weniger mögliche kombinatorische Ausführungspfade berücksichtigen als bei anderen Testarten. Bei übergeordneten Tests kann man sich dann stichprobenartig auf die wichtigsten Ausführungspfade konzentrieren und damit die Anzahl dieser Tests deutlich reduzieren.
• Da man nur einzelne Module testet, kann man Modultests, oft um mehrere Größenordnungen, schneller und damit öfter (bzw. kontinuierlich) ausführen als andere Testarten.
• Wenn man Fehler mit einem Test absichert, kann man den erneuten Auftritt des gleichen Fehlers verhindern.
• Durch die Fehlerreduktion ergeben sich Geschwindigkeitsvorteile in der Entwicklung in mittleren bis großen Softwareprojekten.
• Da man Abhängigkeiten zwingend vermeiden muss, um einen Modultest zu ermöglichen, bleibt der Code verhältnismäßig schnell änderbar. Hierdurch kann man schneller auf wechselnde Anforderungen reagieren. Siehe Agile Manifest 😉
• Da automatisch ausgeführte Tests um mehrere Größenordnungen schneller sind als manuelle Tests, reduziert sich der Zeitaufwand für das Testen deutlich. Hierdurch kann man die Entwicklungsstufen schneller durchlaufen und die Release-Zyklen signifikant verkürzen.

Was sind die Nachteile von Unit Tests?

• Bei der Implementierung neuer Funktionen muss man nicht nur die Funktion implementieren, sondern auch die dazugehörenden Tests vorbereiten bzw. definieren. Dadurch ergibt sich ein oft mehrfacher Implementierungsaufwand.
• Bei Änderungen muss man nicht nur die geänderten Funktionen, sondern auch die dazugehörenden Tests anpassen. Insbesondere bei der Entwicklung von Prototypen, bei der sich die Codebasis schnell verändert, ist das Testen daher oft eher ein Hindernis.
• Da man die Funktionalität der Tests verwendet, ist in den IDEs schwerer ersichtlich, ob eine Funktionalität keine Verwendung mehr findet und ob man es daher entfernen kann.
• Weisen die Tests untereinander Abhängigkeiten auf (z. B. durch gemeinsame Testdaten), so können einzelne Änderungen an der Codebasis eine Vielzahl von Tests beeinflussen, was den Änderungsaufwand mit der Größe der Codebasis exponentiell erhöht.

Fehlerkosten 10er Regel (Rule of ten)

Die Zehnerregel der Fehlerkosten besagt, dass je weiter ein Fehler sich unentdeckt in die späten Phasen des Werdegangs eines Produktes oder Prozesses bewegt – oder gar bis zum Kunden –, desto höher steigen die Kosten zur Behebung des Fehlers. Eindrucksvoll untermauert durch die Ergebnisse einiger Studien aus den 70er Jahren in Japan, USA und Großbritannien, die sich mit den Ursachen von Produkt- bzw. Qualitätsmängeln beschäftigten. Alle Analysen lieferten nahezu die gleichen Ergebnisse: Ca. 70 % aller Produktmängel hatten ihre Ursache bereits in der Entwicklung, Konstruktion und Arbeitsvorbereitung. Der Herstellungsprozess selbst hat bezüglich der Endqualität des Produktes offensichtlich eher einen sekundären Einfluss. Eine VDMA-Studie zum Thema „Qualitätsbezogene Kosten“ Anfang der 90er Jahre in der Bundesrepublik Deutschland bestätigt dieses Ergebnis.

Die Zehnerregel der Fehlerkosten oder „Rule of ten“ sagt aus, dass sich die Fehlerkosten für einen nicht entdeckten Fehler von Stufe zu Stufe der Wertschöpfung um den Faktor 10 erhöhen. Je früher ein Fehler entdeckt und beseitigt wird, desto kostengünstiger ist dies für die Organisation und schlussendlich auch für den User bzw. Kunden.

Ansonsten sind diese auch in der DIN 55350-11 im Rahmen des Qualitätsmanagements festgehalten. Doch darauf gehe ich in einem separaten Beitrag ein.

Wo sind die Grenzen der Unit Tests?

Unit Tests können (wie jeder Test) die Fehlerfreiheit der getesteten Units, Module usw. nicht garantieren oder nachweisen, sondern lediglich unterstützen. Die Grenzen von Unit Tests liegen primär nur in den Fällen vor in denen man Fehler finden kann, zu deren Entdeckung die verwendeten Tests geeignet sind. Eine Softwarekomponente, die „grün“ testet, ist also nur bedingt fehlerfrei.

Das Merkmal von Code, „grün“ zu testen, und durchaus auch der Wunsch nach diesem Ergebnis, kann dazu führen, dass man tatsächlich (unbewusst) nur so viel testet, bis alle Tests „grün“ sind. Module, die keine fehlschlagenden Modultests haben, als fehlerfrei zu behandeln, ist ein Fehlschluss in der Praxis des (TDD) Test Driven Development.

Um eine ausreichende Testabdeckung zu erzielen, lohnt es sich u.U., vor dem Erstellen der Testfälle Refactoring-Maßnahmen anzuwenden. Dies erst nach abgeschlossenen Unit Tests (für den alten Code) zu tun, schafft Raum (wie jede Änderung im Code) für neue Fehlerrisiken und kann deshalb wiederholtes Testen erforderlich machen.

Wenn der Autor von Unit Tests mit dem Autor der Module identisch ist, können Denkfehler in der Implementierung auch im Test erscheinen und verpasst gegebenenfalls die Chance, diese aufzudecken. Wenn es sich um dieselbe Person handelt, kann man die vorrangige Entwicklung der Tests ebenfalls nicht garantieren, da sowohl die beabsichtigte Funktionsweise des Codes als auch die zukünftige Gestalt bereits im Gedankengut des Testautors und späteren Codeautors präsent sein können. Dies kann im Extreme Programming durch „Test Ping-Pong“ abgefangen werden, bei der sich Entwickler bei der Implementierung der Funktionalität und der Tests abwechseln.

Bei der Entwicklung von Modultests können Testfälle entstehen, die der Zielsetzung und dem Charakter von Modultests nicht oder nur zum Teil entsprechen. Wie bei der Programmierung existieren daher auch für die Entwicklung von Modultests Anti-Pattern, die man möglichst vermeiden sollte.

Der Beitrag Unit Tests – Fundament für stabile und effiziente Software erschien zuerst auf CEOsBay.

Features

Im Wesentlichen unterscheiden sich die beiden Versionen im Funktionsumfang. Hierzu von der Ultimate Version unterstützte Sprachen: Java, Groovy, Kotlin, Scala, Python and Jython, Cython, Ruby and JRuby, Rust, PHP, Go, Dart, SQL, HTML, XML, JSON, YAML, XSL, XPath, Markdown, JavaScript, TypeScript, CSS, Sass, SCSS, Less, Haml, Slim, Liquid

Wobei zu beachten ist, dass die Ultimate Edition von IntelliJ IDEA neben den nativ unterstützten Sprachen, einige der Sprachen lediglich durch den Einsatz von PlugIns unterstützt. In der Community Edition sind auch einige Sprachen gar nicht berücksichtigt. Eine explizite bzw. genaue Differenzierung möchte ich in diesem Beitrag nicht vornehmen. Also sind die Angaben bzgl. der Features mit Vorsicht zu genießen.

Auch ist zu beachten, dass lediglich die Ultimate Edition von IntelliJ IDEA die umfangreiche Framework Unterstützung mitbringt. Im Enterprise Umfeld sind diese in der Regel unabdingbar.

Auch bei den Build Tools gibt es Unterschiede. Besonders auffällig ist dabei die Tatsache, dass npm zwar in der Ultimate Edition läuft, jedoch nicht in der Community Edition. Ich habe es auch in der Community Version zum Laufen gebracht. Dennoch ist dies mit Vorsicht zu genießen, da ich aufgrund von Fehlern dennoch auf die Ultimate Edition geswitched bin.

Versionskontrolle

Auf die Funktionsfähigkeit bei der Versionskontrolle bzw. bei Cloud-basierten Diensten wie Git, GitHub, Subversion, Mercurial und Team Foundation Server kann man sich verlassen. Bei Perforce ist man zumindest in der Community Edition verlassen.

Deployment

Während die Community Edition lediglich Docker für das Deployment unterstützt sind es mit der Ultimate Edition Kubernetes, Java Applications Servers als auch Docker.

Codevervollständigung

Die Codevervollständigung ist eine Funktion, die vor allem Programmieranfängern sehr entgegenkommt. Nur wenige werden als Coder geboren, oder!? Da vergisst man schon mal schnell eine import-Anweisung, IDEA aber nicht. Meistens weist IntelliJ einen auf den Fehler hin und schlägt Korrekuren vor. Dies gilt auch für nicht verwendete Importe, die IntelliJ entsprechend einer manuellen Zustimmung entsorgt.

Es nimmt einem den Grossteil der Tipparbeit ab, damit man sich dem Programmdesign widmen kann und nicht über korrekt formulierte JAVA-Anweisungen nachdenken muss. Ich muss gestehen, dass ich mich bisher noch nicht wirklich mit JAVA auseinandergesetzt habe. Doch dies hole ich derzeit nach und auch darüber gibt es in der nahen Zukunft einen Beitrag.

Code Layout Manager

Den Code Layout Manager weiß man spätestens dann zu schätzen, wenn man im eigenen Quelltext nicht mehr durchblickt oder fremden Quelltext bearbeiten muss. Dann kann man Text markieren und von IDEA neu formatieren lassen. Dies geht relativ intelligent von statten.

Refactoring

Auch die Refactoringfähigkeiten von IntelliJ sind nicht zu unterschätzen. Wer die Funktionen einmal in Aktion erlebt hat, der möchte sie nicht mehr missen. Dazu gehören u.A. das Renaming, Move, Introduce Explaining Variable, Extract Method usw.

Fazit

Ich arbeite noch nicht lange mit dem Programm. Doch IntelliJ hat scheinbar in enger Kooperation mit den Anwendern ein relativ gutes Produkt entwickelt, mit dem man gut im Enterprise Umfeld arbeiten kann. Besonders die große PlugIn Bibliothek als auch die individuelle Erweiterbarkeit durch eine offen gelegte API haben mir persönlich sehr gefallen. Dadurch ist es auch möglich eigene PlugIns für IntelliJ zu schreiben und diese zu selbst zu implementieren.

Der Beitrag IntelliJ IDEA – Die intelligente und leistungsstarke Entwicklungsumgebung erschien zuerst auf CEOsBay.

Blockchains werden in der Regel von einem Peer-to-Peer-Computernetzwerk (P2P) als öffentliches verteiltes Buch verwaltet, in dem die Knoten gemeinsam ein Konsensalgorithmusprotokoll befolgen, um neue Transaktionsblöcke hinzuzufügen und zu validieren. Obwohl Blockchain-Datensätze nicht unveränderlich sind, da Blockchain-Forks möglich sind, können Blockchains an sich als sicher angesehen werden und stellen ein Beispiel für ein verteiltes Computersystem mit hoher byzantinischer Fehlertoleranz dar.

Was hat es mit dem byzantinischen Fehler auf sich?

Als byzantinischen Fehler bezeichnet man in der Informationstechnik Fehler, bei denen sich ein System beliebig falsch verhält. Beispielsweise schickt ein Server gelegentlich falsche Antworten und erreicht gelegentlich falsche Systemzustände. Ein byzantinischer Fehler beschreibt im Allgemeinen ein schwer zu erfassendes Fehlermodell. In Mehrprozessor-Systemen bezeichnet der byzantinische Fehler eine Fehlerklasse. Falls eine Komponente an verschiedene Prozessoren unterschiedliche (protokollkonforme) Ergebnisse liefert, spricht man von einem byzantinischen Fehler.

Wer hat es erfunden und wofür?

Die erste Blockchain wurde von einer Person, oder einer Gruppe von Personen, unter dem Namen bzw. dem Pseudonym Satoshi Nakamoto im Jahr 2008 geschaffen. Dieser sollte als öffentliches verteiltes Hauptbuch für Bitcoin-Kryptowährungstransaktionen dienen. Dieser Arbeit basiert auf früheren Arbeiten von Stuart Haber, W. Scott Stornetta und Dave Bayer. Der Source Code ist Open Source und kann auf GitHub unter https://github.com/bitcoin/bitcoin eingesehen. Die Implementierung der Blockchain in Bitcoin, machte es zur ersten digitalen Währung, die das Problem der doppelten Ausgaben ohne die Notwendigkeit einer vertrauenswürdigen Behörde bzw. Institution oder eines zentralen Servers löste. Das Bitcoin-Design hat andere Anwendungen und Blockchains inspiriert, die für die Öffentlichkeit zugänglich sind und von Kryptowährungen bzw. NFT Projekten in großem Umfang genutzt werden. Die Blockchain kann als eine Art Zahlungsschiene betrachtet werden.

Zentrale Einheiten einer Blockchain

Distributed-Ledger-Technologie (DLT)

Alle Netzwerkteilnehmenden haben Zugriff auf ein verteiltes „Kontobuch“ (distributed Ledger) mit nicht manipulierbaren Datensätzen der Transaktionen. In diesem gemeinsam genutzten Kontobuch werden Transaktionen nur ein einziges Mal aufgezeichnet, wodurch die für traditionelle Unternehmensnetzwerke typische Doppelarbeit entfällt.

Nicht manipulierbare Datensätze

Keiner der Teilnehmenden kann eine Transaktion verändern oder manipulieren, nachdem diese im gemeinsam genutzten Kontobuch aufgezeichnet wurde. Falls ein Transaktionsdatensatz einen Fehler enthalten sollte, muss eine neue Transaktion hinzugefügt werden, die diesen Fehler korrigiert, und beide Transaktionen sind in der Folge sichtbar.

Smart Contracts

Um Transaktionen zu beschleunigen, wird ein Regelwerk – Smart Contract genannt – in der Blockchain gespeichert und automatisch ausgeführt. Ein Smart Contract kann beispielsweise Bedingungen für die Übertragung von Unternehmensanleihen, Bedingungen für eine zu zahlende Reiseversicherung und vieles mehr definieren. In dem Beitrag von gestern gehe ich Explizit auf dieses Thema ein.

Fazit

Bei einer Blockchain hat man als Mitglied eines nur auf Mitglieder begrenzten Netzwerks die Sicherheit, dass man präzise und termingerechte Daten erhält und das die vertraulichen Blockchain-Datensätze nur mit den anderen Netzmitgliedern geteilt werden, denen man ausdrücklich den Zugriff gewährt hat. Von allen Netzmitgliedern wird Konsens zur Korrektheit der Daten verlangt und sämtliche validierten Transaktionen sind nicht manipulierbar, weil sie permanent aufgezeichnet werden. Niemand kann eine Transaktion löschen oder ändern. Dies stellt eine immense Sicherheit dar.

Bei einem verteilten Kontobuch, dass von Mitgliedern eines Netzwerks gemeinsam genutzt wird, entfällt der Bedarf nach einem zeitaufwendigen Abgleichen von Datensätzen. Und zur Beschleunigung von Transaktionen lässt sich ein Regelwerk – Smart Contract genannt – in der Blockchain speichern und automatisch ausführen. Dies wiederum steigert die Effizienz ungemein. Häufig vergeudet man wertvolle Arbeitszeit mit der Pflege von Duplikaten, Datensätzen und mit Validierungen anderer Anbieter. Traditionelle Aufzeichnungssysteme können anfällig für Betrugsversuche und Cyberangriffe sein. Eingeschränkte Transparenz kann die Verifizierung von Daten behindern. Und durch das IoT (Internet of Things = Internet der Dinge) sind das Volumen von Transaktionsdaten explosionsartig gestiegen. All dies verlangsamt die Prozesse bzw. das Geschäft, belastet das Ergebnis – und bedeutet, dass wir bessere Methoden benötigen. Hier kann die Blockchain Abhilfe schaffen.

Der Beitrag Blockchain – Dezentralisierte, transparente und vertrauenswürdige Systeme erschien zuerst auf CEOsBay.