Was sind Microservices?

Microservices sind ein Architekturstil, bei dem eine Anwendung nicht als ein großes, monolithisches System entwickelt wird, sondern aus vielen kleinen, voneinander unabhängigen Diensten besteht. Jeder dieser Services erfüllt eine klar abgegrenzte Aufgabe – zum Beispiel Benutzermanagement, Zahlungsabwicklung oder Produktsuche – und kommuniziert mit den anderen über klar definierte Schnittstellen (meistens per HTTP/REST oder Messaging).

Vorteile von Microservices

Unabhängigkeit der Teams
Da jeder Service separat entwickelt und bereitgestellt werden kann, können Teams autonom arbeiten, ihre bevorzugten Technologien wählen und Änderungen schneller umsetzen.

Skalierbarkeit
Nicht die ganze Anwendung muss hochskaliert werden – nur die Services, die es wirklich brauchen. So kann zum Beispiel der Suchservice bei Lastspitzen getrennt von anderen Komponenten skaliert werden.

Fehlertoleranz
Ein Fehler in einem Service muss nicht gleich die gesamte Anwendung lahmlegen. Durch geeignete Maßnahmen (z.B. Circuit Breaker, Retry-Strategien) können Microservices robuster werden.

Schnellere Releases
Dank unabhängiger Deployments lassen sich einzelne Komponenten aktualisieren, ohne das ganze System neu auszrollen.

Herausforderungen

Komplexität der Kommunikation
Wo früher einfache Funktionsaufrufe genügten, müssen heute Netzwerkanfragen, Timeouts, Fehlertoleranz und Datenkonsistenz zwischen Services bedacht werden.

Monitoring und Debugging
In einer Microservices-Architektur ist es schwieriger, den Überblick zu behalten. Gute Logging-, Tracing- und Monitoring-Tools sind Pflicht.

Datenmanagement
Jeder Service verwaltet idealerweise seine eigene Datenbank. Dadurch entstehen neue Herausforderungen bei der Konsistenz und bei komplexen Abfragen.

DevOps- und Infrastruktur-Aufwand
Continuous Integration, Deployment, Containerisierung (z.B. Docker), Orchestrierung (z.B. Kubernetes) – wer Microservices ernst meint, muss auch die passende Infrastruktur beherrschen.

Wann lohnt sich der Einsatz?

Microservices sind kein Allheilmittel. Für kleine Teams oder überschaubare Anwendungen kann ein gut strukturierter Monolith die bessere Wahl sein. Der Umstieg darauf lohnt sich vor allem, wenn:

• mehrere Teams gleichzeitig an der Anwendung arbeiten,
• Skalierbarkeit ein zentrales Thema ist,
• einzelne Komponenten sich unterschiedlich schnell entwickeln,
• Continuous Delivery aktiv betrieben wird.

Fazit

Microservices bieten enorme Vorteile in Sachen Flexibilität, Skalierbarkeit und Geschwindigkeit – bringen aber auch mehr Komplexität mit sich. Wer den Schritt wagt, sollte sich der technischen und organisatorischen Anforderungen bewusst sein. Mit einer guten Strategie und den richtigen Tools können Microservices jedoch ein echter Gamechanger sein.

Der Beitrag Microservices – Was steckt hinter dem Architekturtrend? erschien zuerst auf CEOsBay.

Was ist SOA?

Die serviceorientierte Architektur ist ein Ansatz zur Softwareentwicklung, bei dem man Anwendungen als eine Sammlung voneinander unabhängiger Dienste strukturiert. Jeder Dienst bietet eine klar definierte Funktionalität an, die man über standardisierte Schnittstellen ansprechen kann. Diese Dienste sind lose gekoppelt, was bedeutet, dass sie unabhängig voneinander entwickelt, aktualisiert und skaliert werden können.

SOA basiert auf einer Reihe von Prinzipien:

• Lose Kopplung: Dienste sind nicht direkt voneinander abhängig, sondern kommunizieren über definierte Schnittstellen. Siehe auch meinen Beitrag „API – Nahtlose Verbindungen für Innovationen„.
• Wiederverwendbarkeit: Ein einmal entwickelter Dienst kann in verschiedenen Anwendungen oder Prozessen genutzt werden.
• Interoperabilität: Dienste können unabhängig von der zugrunde liegenden Technologie miteinander kommunizieren.
• Modularität: Anwendungen werden in kleinere, eigenständige Einheiten zerlegt.

Vorteile von SOA

SOA bietet eine Reihe von Vorteilen für Unternehmen, insbesondere in komplexen IT-Landschaften:

• Flexibilität: Durch die lose Kopplung der Dienste können Änderungen oder Erweiterungen vorgenommen werden, ohne dass das gesamte System betroffen ist.
• Skalierbarkeit: Einzelne Dienste können unabhängig voneinander skaliert werden, je nach Bedarf.
• Wiederverwendbarkeit: Vorhandene Dienste kann man in neuen Kontexten nutzen, was Entwicklungsaufwand spart.
• Bessere Wartbarkeit: Durch die Modularität der Architektur kann man Fehler schneller beheben und Updates einfacher durchführen.

Herausforderungen und Best Practices

Trotz der zahlreichen Vorteile gibt es einige Herausforderungen bei der Implementierung von SOA:

• Komplexität: Die Verwaltung vieler unabhängiger Dienste kann anspruchsvoll sein.
• Performance: Da Dienste häufig über Netzwerke kommunizieren, kann dies zu Latenzen führen.
• Sicherheit: Die Absicherung der Kommunikation zwischen Diensten ist essenziell, insbesondere in verteilten Systemen.

Um diesen Herausforderungen zu begegnen, sollte man einige Best Practices befolgen:

• Standardisierte Schnittstellen verwenden: APIs sollten gut dokumentiert und standardisiert sein.
• Service-Governance etablieren: Regeln für die Nutzung und Verwaltung von Diensten helfen, Chaos zu vermeiden.
• Monitoring und Logging: Eine gute Überwachung der Dienste ist entscheidend, um Probleme frühzeitig zu erkennen und zu beheben.

SOA vs. Microservices – Ist SOA veraltet?

Viele moderne Entwickler bevorzugen heutzutage Microservices gegenüber SOA, da sie eine noch granularere und flexiblere Architektur bieten. Während SOA oft große, in sich geschlossene Dienste definiert, setzt der Microservices-Ansatz auf sehr kleine, spezialisierte Services, die über leichtgewichtige Protokolle (z.B. REST oder gRPC) kommunizieren.

Einige Unterschiede zwischen SOA und Microservices:

• Granularität: Microservices sind feingranularer als klassische SOA-Dienste.
• Kommunikation: Während SOA häufig auf komplexe Middleware (z.B. Enterprise Service Bus, ESB) setzt, nutzen Microservices oft einfache REST– oder gRPC-Schnittstellen.
• Bereitstellung: Microservices erlauben eine unabhängige Bereitstellung und Skalierung einzelner Services, während SOA eher in größeren Einheiten verwaltet wird.
• Technologievielfalt: Microservices-Architekturen erlauben eine breitere Wahl an Technologien und Programmiersprachen für einzelne Services.

Alternativen zu SOA

Neben Microservices gibt es weitere Architekturansätze, die für verschiedene Szenarien geeignet sein können:

• Monolithische Architektur: Eine traditionelle Architektur, bei der die gesamte Anwendung als eine einzige Einheit entwickelt wird. Dies kann für kleinere Anwendungen sinnvoll sein, ist aber weniger skalierbar.
• Serverless Computing: Dienste werden nur bei Bedarf ausgeführt, was eine kosteneffiziente und skalierbare Alternative darstellt.
• Event-Driven Architecture: Anwendungen bestehen aus lose gekoppelten Komponenten, die auf Events reagieren, was eine hohe Skalierbarkeit ermöglicht.

Fazit

SOA bleibt auch in Zeiten moderner Architekturen ein relevantes Konzept, insbesondere für Unternehmen mit bestehenden monolithischen Systemen. Dennoch gilt es heute als weniger agil (Siehe meinen Beitrag „Agile Manifest – Die bessere Art der Softwareentwicklung„) als Microservices, die mehr Flexibilität und Unabhängigkeit bieten. Abhängig von den Anforderungen eines Unternehmens kann SOA weiterhin eine geeignete Lösung sein, insbesondere wenn man bestehende Systeme integrieren muss. Wer sich jedoch für eine zukunftssichere, hochgradig skalierbare Architektur interessiert, sollte Alternativen wie Microservices oder Serverless-Ansätze in Betracht ziehen.

Der Beitrag SOA (Serviceorientierte Architekturen) erschien zuerst auf CEOsBay.

Was ist ein Stub?

Ein Stub stellt in der Softwareentwicklung eine temporäre Implementierung einer Methode oder Funktion dar, die die tatsächliche Funktionalität noch nicht enthält, sondern lediglich dazu dient, die Entwicklung weiterer Komponenten zu ermöglichen. Stubs geben also vorläufige Antworten zurück und simulieren das Verhalten einer Komponente, die in einer späteren Entwicklungsphase durch die tatsächliche Implementierung ersetzt wird.

Entstehung von Stubs

Das Konzept des Stubs entstand aus dem Bedürfnis heraus, verschiedene Teile eines Systems unabhängig voneinander zu entwickeln. Wenn beispielsweise ein Entwicklerteam an einer Funktion arbeitet, die Daten von einem noch nicht implementierten Service benötigt, ermöglicht ein Stub die Fortsetzung der Arbeit, ohne auf die Fertigstellung dieses Services warten zu müssen.

Stubs in der Praxis

Ein häufiges Einsatzgebiet von Stubs ist das Testen von Software. Wenn man eine bestimmte Funktion oder Methode testen möchte, ohne von anderen, noch nicht fertiggestellten Teilen der Software abhängig zu sein, können Stubs zum Einsatz kommen. So lassen sich isolierte Tests durchführen, die sich nur auf den zu testenden Code konzentrieren.

Beispiel: Ein Entwickler möchte die Funktionalität einer Anwendung testen, die Wetterdaten von einem externen Anbieter abruft. Da der externe Service noch nicht verfügbar ist, implementiert der Entwickler einen Stub, der vorgetäuschte Wetterdaten zurückgibt. Dadurch kann er die Anwendung testen, als würde sie bereits mit dem echten Service kommunizieren.

Stub-Einrichtung

Die Einrichtung eines Stubs kann je nach verwendetem Framework oder Tool variieren. Allgemein gilt jedoch:

1. Identifizieren der Funktion oder Methode, die durch den Stub ersetzt werden soll.
2. Implementieren des Stubs mit einem vorläufigen Rückgabewert oder einer Antwort.
3. Einrichtung von Tests oder der Anwendung so, dass der Stub anstelle der tatsächlichen Implementierung verwendet wird.

Fazit

Stubs spielen eine wichtige Rolle in der Softwareentwicklung, insbesondere beim Testen und bei der parallelen Entwicklung von Komponenten. Sie ermöglichen es Entwicklern, effizienter zu arbeiten und sicherzustellen, dass ihre Codes korrekt funktionieren, selbst wenn andere Teile des Systems noch in Arbeit sind.

Der Beitrag Stub – Brücken bauen in der Code-Welt erschien zuerst auf CEOsBay.

Definition Kernel

Der Kernel bildet das zentrale Bindeglied zwischen der Computerhardware und den Softwareanwendungen. Er verwaltet die Hardware-Ressourcen, darunter Prozessor, Arbeitsspeicher und Speichermedien und ermöglicht es, dass verschiedene Softwareanwendungen auf diese Ressourcen zugreifen können.

Entstehungsgeschichte Kernel

Die Geschichte des Kernels geht Hand in Hand mit der Entwicklung der ersten Betriebssysteme. In den frühen Tagen der Computertechnologie bestand die Notwendigkeit, eine Schnittstelle zu schaffen, die den effizienten Zugriff von Software auf Hardware ermöglicht. So entstand der erste rudimentäre Kernel. Mit der Zeit und mit wachsender Komplexität von Hardware und Software hat es sich stetig weiterentwickelt, um den wachsenden Anforderungen gerecht zu werden.

Arten von Kernels

Es existieren unterschiedliche Typen von Kernels:

1. Monolithische Kernels: Bei dieser Art werden alle grundlegenden Systemdienste wie Dateisystem, Netzwerk und Prozesskommunikation in einem einzigen, großen Kern implementiert. Ein Beispiel hierfür ist Linux.
2. Mikrokernel: Hierbei handelt es sich um einen minimalistischen Kernel. Die meisten Systemdienste laufen als eigenständige Prozesse. Beispiele hierfür sind Minix und QNX.
3. Hybridkernel: Dieser Kernel-Typ kombiniert Elemente von monolithischen Kernels und Mikrokernels. Ein bekanntes Beispiel ist das gute alte Windows NT, XP, 7, 8, 10 und auch die Server-Varianten.

Aufsetzen des Kernels

Das Aufsetzen eines Kernels kann sich je nach System und Anforderungen unterscheiden. Im Allgemeinen folgt man jedoch diesen Schritten:

1. Quellcode herunterladen: Zunächst lädt man den Quellcode des gewünschten Kernels herunter.
2. Konfigurieren: Mittels Konfigurationswerkzeugen passt man den Kernel an die eigenen Bedürfnisse an.
3. Kompilieren: Der angepasste Quellcode wird kompiliert, um eine ausführbare Version des Kernels zu erstellen.
4. Installation: Kompiliert kann man es nun auf dem Zielsystem installieren.

Beispiele und Anwendung

Das bekannteste Beispiel für einen Kernel ist wohl der Linux-Kernel. Millionen von Servern und Desktop-Computern weltweit nutzen Linux. Der Quellcode des Linux-Kernels ist frei verfügbar bzw. Open Source, weshalb viele Entwickler und Unternehmen es an ihre spezifischen Anforderungen anpassen und weiterentwickeln.

Zusammenfassend lässt sich sagen, dass es das Herzstück jedes Betriebssystems bildet. Er steuert und verwaltet den Zugriff auf die Hardware und ermöglicht so den Betrieb von Softwareanwendungen. Wer tiefer in die Welt der Kernels einsteigen möchte, dem stehen unzählige Ressourcen und Community-Plattformen zur Verfügung.

Der Beitrag Kernel – Herzstück des Betriebssystems erschien zuerst auf CEOsBay.

Die Entstehungsgeschichte von UNIX

Die Geschichte beginnt in den 1960er Jahren bei den Bell Labs, einer Forschungseinrichtung von AT&T. Hier suchten Ken Thompson und Dennis Ritchie nach einem neuen Betriebssystem, dass den Anforderungen an Flexibilität und Effizienz genügen sollte. 1969 entwickelten sie die erste Version von UNIX, geschrieben in der Programmiersprache Assembly. Innerhalb weniger Jahre schrieben sie es in C um, einer neuen Sprache, die sie ebenfalls bei Bell Labs entwickelten. Diese Neugestaltung machte UNIX zu einem der ersten Betriebssysteme, die auf verschiedensten Hardware-Plattformen laufen konnten.

Die Besonderheiten von UNIX

Eines der Hauptmerkmale ist die Modularität. Das System folgt dem Prinzip „Alles ist eine Datei“, was eine intuitive Interaktion mit Geräten und Prozessen ermöglicht. Das Herzstück, der Kernel, verwaltet die Hardware-Ressourcen, während die Shell als Benutzerschnittstelle dient. Dank dieser Architektur kann es nahezu unbegrenzt erweitert und angepasst werden.

UNIX besticht zudem durch seine Befehlszeilenschnittstelle (CLI). Hier ein einfaches Beispiel zur Veranschaulichung:

ls -l | grep "txt" | wc -l

Dieser Befehl listet alle Dateien auf (ls -l), filtert diejenigen heraus, die „txt“ im Namen haben (grep "txt") und zählt die Ergebnisse (wc -l).

Nutzen und aufsetzen

UNIX-Systeme finden sich heute in verschiedenen Varianten und Distributionen, von denen Linux und macOS die bekanntesten sind. Interessenten können beispielsweise eine Linux-Distribution wie Ubuntu oder Debian leicht auf ihrem Computer installieren.

Hier sind einige der beliebtesten Linux-Distributionen, die man herunterladen kann:

1. Ubuntu: Eine der bekanntesten und benutzerfreundlichsten Distributionen.
   • Download-Link für Ubuntu
2. Debian: Ein stabiles und robustes System, das als Grundlage für viele andere Distributionen dient, einschließlich Ubuntu.
   • Download-Link für Debian
3. Fedora: Ein weiteres beliebtes Betriebssystem mit regelmäßigen Updates.
   • Download-Link für Fedora
4. CentOS: Eine kostenlose Variante von Red Hat Enterprise Linux (RHEL) und oft in Unternehmensumgebungen zu finden.
   • Download-Link für CentOS
5. openSUSE: Eine robuste und zuverlässige Option für Desktops und Server.
   • Download-Link für openSUSE
6. Arch Linux: Geeignet für erfahrene Benutzer, die ein minimalistisches und hochkonfigurierbares System bevorzugen.
   • Download-Link für Arch Linux

Es gibt natürlich viele weitere Linux-Distributionen, und welche am besten geeignet ist, hängt von den spezifischen Anforderungen und Vorlieben ab.

Wenn man an „reinem“ UNIX interessiert ist, kann man sich auch BSD-Systeme ansehen, wie FreeBSD, OpenBSD oder NetBSD. Diese sind enger mit den historischen UNIX-Systemen verwandt als Linux.

• Download-Link für FreeBSD
• Download-Link für OpenBSD
• Download-Link für NetBSD

Es ist zu beachten, dass die Installation und Konfiguration dieser Systeme Kenntnisse in der Systemadministration erfordern können.

Um es aufzusetzen:

1. Auswählen einer passenden Distribution.
2. Herunterladen des Installationsimages.
3. Erstellen eines bootfähigen USB-Sticks.
4. Booten von dem Stick und Installationsanweisungen folgen.

Einmal installiert, bietet es eine robuste und leistungsstarke Umgebung für alle Arten von IT-Anwendungen, von der Webentwicklung bis zur Datenanalyse.

Fazit

UNIX hat die Landschaft der Betriebssysteme maßgeblich geprägt und bietet auch heute noch eine solide Grundlage für moderne IT-Lösungen. Seine Flexibilität, Robustheit und Modularität machen es zu einer ersten Wahl für viele Entwickler und IT-Experten weltweit. Wer in die Welt von UNIX eintauchen möchte, findet in den zahlreichen Distributionen und Ressourcen online einen idealen Einstieg.

Der Beitrag UNIX – Das Betriebssystem, das die IT-Welt veränderte 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.