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.

Insbesondere trifft man auf JSON bei Webanwendungen und mobilen Apps in Verbindung mit JavaScript, Ajax oder WebSockets zum Übertragen von Daten zwischen dem Client und dem Server.

Serialisierung

Bei einer Abbildung von strukturierten Daten auf eine sequenzielle Darstellungsform, spricht man in der Informatik von einer Serialisierung. Die Serialisierung wird hauptsächlich für die Speicherung von Objekten in Dateien und für die Übertragung von Objekten über das Netzwerk bei verteilten Softwaresystemen verwendet.

Übliche Speichermedien sind nur in der Lage, Datenströme zu speichern. Serialisierung für die Persistenz von Objekten. Hier wird der komplette Zustand des Objektes, inklusive aller referenzierten Objekte, in einen Datenstrom umgewandelt, der anschließend auf ein Speichermedium geschrieben wird.

Nach der Serialisierung liegt ein Objekt mehrfach vor. Sowohl in der externen Darstellung, beispielsweise als Datei als auch im Arbeitsspeicher. Wird nach der Serialisierung eine Änderung am Objekt im Arbeitsspeicher vorgenommen, hat dieses keine Auswirkung auf das serialisierte Objekt in der externen Darstellung.

Die Umkehrung der Serialisierung, also die Umwandlung eines Datenstroms in Objekte, bezeichnet man als Deserialisierung.

In der Linguistik bezeichnet man mit Serialisierung die Art und Weise, wie hierarchische grammatikalische Strukturen in eine lineare Abfolge gebracht sind, damit sie in einer zeitlichen Abfolge sprachlicher Ausdrücke dargestellt werden kann. Diese Reihenfolge kann in verschiedenen Sprachen unterschiedlich sein.

Eine kurze Zeitreise

JSON entstand aus der Notwendigkeit heraus, ein zustandsloses (stateless) Echtzeit-Kommunikationsprotokoll zwischen Server und Browser zu haben, ohne Browser-PlugIns wie Flash oder Java-Applets zu verwenden, die sich Anfang der 2000er Jahre als vorherrschende Methoden, im Einsatz befanden.

Crockford spezifizierte und verbreitete als Erster das JSON-Format. Das Akronym stammt von State Software, ein von Crockford und anderen im März 2001 gegründetes Unternehmen. Die Gründer hatten sich geeinigt, ein System zu entwickeln, dass Standard-Browser-Funktionen nutzte und eine Abstraktionsschicht für Web-Entwickler bereitstellte, um zustandsbehaftete (abstraction layer) Web-Anwendungen zu erstellen, die über eine dauerhafte Duplex-Verbindung zu einem Web-Server verfügten. Sie hielten dafür zwei Hypertext Transfer Protocol (https)-Verbindungen offen und bauten die Verbindung wieder auf, bevor die Standard-Browser-Timeouts eintraten, wenn kein Datenaustausch stattfand. Die Gründer stimmten darüber ab, ob das Datenformat JSML (JavaScript Markup Language) oder JSON (JavaScript Object Notation) genannt und unter welcher Lizenz die Verfügungstellung stattfinden sollte. Die Website JSON.org ging dann im Jahr 2002 online. Im Dezember 2005 begann Yahoo! damit, die ersten Webdienste (Web-Services) in JSON anzubieten.

Vorgänger geht auf ein Spiel für Kinder

Ein Vorläufer der JSON-Bibliotheken wurde in einem Projekt für Kinder, einem digitalen Trading-Spiel namens Cartoon Orbit bei Communities.com (Die Gründer von State hatten alle zuvor bei diesem Unternehmen gearbeitet), für Cartoon Network verwendet, dass ein browserseitiges Plugin mit einem proprietären Nachrichtenformat zur Manipulation von DHTML-Elementen nutzte (Dieses System gehört übriges 3DO). Nach der Entdeckung der frühen Ajax-Fähigkeiten verwendeten digiGroups, Noosh und andere, Frames, um Informationen in das visuelle Feld des Browsers zu übertragen, ohne den visuellen Kontext einer Webanwendung aktualisieren zu müssen. So hatten sie Rich-Web-Anwendungen in Echtzeit erstellt, die nur die Standard https-, HTML– und JavaScript-Fähigkeiten von Netscape 4.0.5+ und IE 5+ verwendeten. Crockford fand darauf heraus, dass JavaScript als objektbasiertes Nachrichtenformat für ein solches System verwendet werden kann. Das System wurde später an Sun Microsystems, Amazon.com und EDS verkauft.

JSON basiert teilweise auf JavaScript und wird häufig auch mit JavaScript verwendet. Dennoch ist es ein sprachunabhängiges Datenformat. Code zum Parsen und Generieren von JSON-Daten ist in vielen Programmiersprachen leicht verfügbar. Auf der JSON-Website sind die JSON-Bibliotheken nach Sprachen geordnet.

Im Oktober 2013 veröffentlichte Ecma International die erste Ausgabe seines JSON-Standards ECMA-404. Im selben Jahr verwendete RFC 7158 ECMA-404 als Referenz. 2014 wurde RFC 7159 zur Hauptreferenz für die Verwendung von JSON im Internet und löste RFC 4627 sowie RFC 7158 ab (wobei ECMA-262 und ECMA-404 als Hauptreferenzen beibehalten wurden). Im November 2017 veröffentlichte ISO/IEC JTC 1/SC 22 ISO/IEC 21778:2017 als internationalen Standard. Am 13. Dezember 2017 hat die Internet Engineering Task Force RFC 7159 durch die Veröffentlichung von RFC 8259, der aktuellen Version des Internet-Standards STD 90, überholt (ersetzt).

Crockford fügte der JSON-Lizenz eine Klausel hinzu, die besagt, dass „die Software für das Gute, nicht für das Böse verwendet werden soll“, um die JSON-Bibliotheken zu öffnen und sich gleichzeitig über Unternehmensjuristen und diejenigen lustig zu machen, die übermäßig pedantisch sind. Ironischer- und lustigerweise führte diese Klausel zu Konflikten der JSON-Lizenz mit anderen Open-Source-Lizenzen, da Open-Source-Software und freie Software in der Regel keine Einschränkungen hinsichtlich des Verwendungszwecks implizieren.

Wie ist JSON aufgebaut?

Die Daten können beliebig verschachtelt werden, beispielsweise ist ein Array (indizierte Liste) von Objekten möglich, die wiederum Arrays oder Objekte enthalten. Als Zeichenkodierung benutzt JSON standardmäßig UTF-8. Auch UTF-16 und UTF-32 werden unterstützt.

JSON und die Typen von Elementen

• null = Nullwert (Wird durch das Schlüsselwort null dargestellt.)
• Boolean = Boolescher Wert (Wird durch die Schlüsselwörter true und false dargestellt. Dies sind keine Zeichenketten. Sie werden daher, wie null, nicht in Anführungszeichen gesetzt.
• Number = Zahl (Ist eine Folge der Ziffern 0–9. Diese Folge kann durch ein negatives Vorzeichen – eingeleitet und durch einen Dezimalpunkt . unterbrochen sein. Die Zahl kann durch die Angabe eines Exponenten e oder E ergänzt werden, dem ein optionales Vorzeichen + oder – und eine Folge der Ziffern 0–9 folgt.)
• String = Zeichenkette (Eine Folge von null oder mehr Unicode-Zeichen. Es beginnt und endet mit doppelten geraden Anführungszeichen („). Es kann Unicode-Zeichen und durch \ eingeleitete Escape-Sequenzen enthalten.
• Array = Anordnung (Beginnt mit [ und endet mit ]. Es enthält eine durch Kommata geteilte, indizierte Liste von Elementen gleichen oder verschiedenen Typen. Leere Arrays sind ebenfalls zulässig.
• Object = Objekt (Beginnt mit { und endet mit }. Es enthält eine durch Kommata geteilte, ungeordnete Liste von Eigenschaften. Objekte ohne Eigenschaften („leere Objekte“) sind ebenfalls zulässig. Das Objekt besteht aus einem Schlüssel und einem Wert, getrennt durch einen Doppelpunkt (Schlüssel : Wert). Die Schlüssel sollten eindeutig sein, da unterschiedliche Parser mit mehrfach vorkommenden Schlüsseln unterschiedlich umgehen. Während ECMA-404 keine Eindeutigkeit voraussetzt, fordert RFC 7159, dass Schlüssel innerhalb eines Objekts eindeutig sind. Folglich ist der Schlüssel eine Zeichenkette und der Wert ein beliebiges Element.

Nicht signifikante Leerraum-Zeichen sind erlaubt, also Leerzeichen (Unicode U+0020), horizontale Tabs (U+0009), Zeilenumbrüche mittels LF und / oder CR (U+000D und U+000A). Diese Zeichen werden außerhalb von Zeichenketten bei der Interpretation ignoriert.

Die Grenzen von JSON

JSON unterstützt nicht alle von JavaScript unterstützten Datentypen. Bei nicht unterstützten Datentypen wird folgendermaßen serialisiert:

• NaN, Infinity und -Infinity werden zu null serialisiert.
• Date-Objekte werden in eine Zeichenkette konvertiert, die einer Datumsformatbeschreibung nach ISO-8601 genügt.
• Function-, RegExp- und Error-Objekte werden verworfen.

Das folgende Beispiel zeigt eine mögliche JSON-Darstellung zur Beschreibung meiner Person.

{
  "Unternehmen": "COEZBAY",
  "Nummer": "2023-23-23-777",
  "Waehrung": "BTC",
  "Inhaber": "CEO"
  {
    "Name": "Oezbay",
    "Vorname": "Cagatay",
    "maennlich": true,
    "Hobbys": ["IT", "Schach", "Basketball"],
    "Alter": 38,
    "Kinder": [],
    "Partner": null
  }
}

Das JSON-Schema

Das JSON-Schema gibt ein JSON-basiertes Format an, um die Struktur von JSON-Daten für die Validierung, Dokumentation und Interaktionssteuerung zu definieren. Es enthält einen Contract für die JSON-Daten, die für eine bestimmte Anwendung erforderlich sind und wie diese Daten geändert werden können.

Das Schema basiert auf den Konzepten des XML-Schemas, ist jedoch JSON-basiert. Wie in XSD (XML Schema Definition) können dieselben Serialisierungs- und Deserialisierungsprogramme sowohl für das Schema als auch für die Daten verwendet werden. Es ist selbstbeschreibend und in einem Internet-Entwurf der Internet Engineering Task Force festgelegt. Für verschiedene Programmiersprachen stehen mehrere Validatoren mit jeweils unterschiedlichen Konformitätsstufen zur Verfügung.

Der Vergleich mit XML

Sowohl JSON als auch XML beschreiben die Struktur eines Datensatzes. Der Datensatz kann weitere Datensätze enthalten. Dadurch sind beliebig tief verschachtelte Strukturen möglich.

In XML sind die einzelnen Knoten der Datenstruktur benannt, während die Knoten in JSON unbenannt bleiben.

Einfache Zeichenketten in XML können sowohl als Attribut eines Elements als auch als eigenständiges Element beschrieben sein. In JSON gibt es diese Unterscheidung nicht. Diese in den meisten Fällen irrelevante Flexibilität führt dazu, dass sich die Struktur von XML-Dokumenten häufig unnötigerweise unterscheidet.

Sowohl für JSON als auch für XML gibt es Beschreibungssprachen, um weiter einzugrenzen, wie „gültige“ Dokumente auszusehen haben. Ganz im Gegensatz zu „wohlgeformten“ Dokumenten.

Die Syntax von JSON ist einfacher gestaltet und erscheint daher oft lesbarer und insbesondere leichter schreibbar. In der Regel produziert JSON auch einen geringeren Overhead im Vergleich zu XML.

Sowohl JSON als auch XML müssen von einem speziellen Parser eingelesen werden. Traditionell ist jedes wohlgeformte JSON-Dokument ein gültiger JavaScript-Ausdruck. Das unaufmerksame Interpretieren von JSON-Dokumenten mit eval() führt jedoch zu Sicherheitslücken, die nicht zu unterschätzen sind.

Sowohl JSON als auch XML sind nicht gut zum Repräsentieren von Binärdaten geeignet, da beide Datenformate als Grundelement zeichenbasiert sind und nicht bytebasiert.

Der Beitrag JSON – Schönheit der einfachen Datenübertragung erschien zuerst auf CEOsBay.