| Inhaltsübersicht |
|---|
| Qualitätseigenschaften gemäß ISO 9126 » |
| Kritik an der ISO 9126 » |
| Qualitätseigenschaften gemäß ISO 25010 » |
| Zusammenspiel IEC 62304 » |
Software-Qualitätseigenschaften gemäß ISO 9126
Abb. 1: Übersicht über die ISO 9126 (englisch)
Die ISO 9126 eignet sich, um die Vollständigkeit der System-Anforderungen zu prüfen und zu prüfen, ob die System-Tests alle Aspekte abdecken.
Ausnahme: Da Software-Anforderungen eine Software als Blackbox beschreiben bzw. spezifizierten sollten, sollte der Ast „Wartbarkeit“ („Maintainability“) nicht Gegenstand der Software-Anforderungen sein.
Die Norm wurde inzwischen von der ISO 25010 abgelöst.
Kritik an der ISO 9126
Die ISO 9126 ist hilfreich, denn Sie dient wie oben geschildert als sehr gute Checkliste. Sowohl beim Schreiben der funktionalen Spezifikation (oft Software Requirements Specification genannt) also auch beim Spezifizieren von Testfällen. Das ist wichtig, weil sich die meisten Firmen beim Spezifizieren und Testen v.a. auf die Funktionalität stürzen.
Dass es mehr Aspekte der Softwarequalität gibt, hat auch die IEC 62304 erkannt. Sie übernimmt beispielsweise im Kapitel 5.1. mit den Softwareanforderungen ziemlich dreist die Inhalte der ISO 9126. Sie verweist zumindest auf die ISO 9126.
Abb. 2: Übersicht über die ISO 9126 (deutsch)
Nicht unumstritten ist der Ast mit der Gebrauchstauglichkeit bzw. Benutzbarkeit:
Die ISO 9241 und in ähnlicher Weise die IEC 62366 definieren den Begriff Gebrauchstauglichkeit wie folgt:
„Das Ausmaß, in dem ein interaktives System durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.“
Nun wird man sich fragen, wie man mit einem funktional fehlerhaften System seine Ziele überhaupt erreichen kann. Das geht natürlich nicht.
Würde das bedeuten, dass die Funktionalität ein Unteraspekt der Gebrauchstauglichkeit ist? Die ISO 9126 also falsch ist? Im Sinn der ISO 9241 schon, nicht aber im Sinn der ISO 9126. Denn sie meint eigentlich gar nicht die Gebrauchstauglichkeit, sondern nur die Benutzbarkeit. Dieser Ast zielt also auf die Effizienz und nicht die Effektivität ab. Gebrauchstauglichkeit umfasst alles.
Software-Qualitätseigenschaften gemäß ISO 25010
Die ISO 25010 ist die Nachfolge-Norm der ISO 9126. Zu den Änderungen zählen auch zwei neue Hauptkategorien, die IT-Sicherheit und die Kompatibilität, die beide vorher Aspekte der Hauptkategorie „Funktionalität waren“:
Abb. 3: Übersicht über die ISO 25010 (englisch)
Auch die ISO 25010 ist keine harmonisierte Norm. Wie die ISO 9126 eignet sich diese Norm als Checkliste, um die Vollständigkeit von Software-Systemanforderungen und Software-Systemtests zu überprüfen.
Abb. 4: Checkliste für Software-Anforderungen herunterladen (Bild anklicken)
Eine gute von der ISO 25010 inspirierte Checkliste für Software-Anforderungen hat Ihnen das Johner Institut bereits vorbereitet.
Zusammenspiel von ISO 9126 und IEC 62304
Ein Mitglied im Auditgarant fragt: „Ist die ISO 9126 noch aktuell? Falls ja, muss ich sie einhalten? Und wie steht diese in Beziehung zur IEC 62304?“
Zur Erinnerung: Die ISO 9126 ist eine Norm, welche eine Taxonomie von Software-Qualitätseigenschaften beschreibt. Sie ist aber keine harmonisierte Norm. Genauso wenig ist das deren neuer Nachfolgerin, die ISO 25010. Damit sind beide Normen nicht geeignet, um beim Audit die Erfüllung einer grundlegenden Anforderung vermuten zu lassen.
Aber beide Normen sind als Checkliste geeignet, um die Vollständigkeit der Softwaresystemanforderungen und die der Softwaresystemtests zu prüfen. Es gibt keine formale/normative Beziehung zur IEC 62304, aber die Aspekte, die in deren Kapitel 5.2 (Software-Systemanforderungen) und 5.6/5.7 (Integrations- bzw. Systemtest) genannt werden gehen genau in diese Richtung.
Die Software-Anforderungen (Software Requirements Specification) sollen die Software anhand ihres Verhaltens über deren Schnittstellen beschreiben. Software kennt drei Schnittstellentypen:
- Nutzer-System-Schnittstellen (UI)
- System-System-Schnittstellen (Datenschnittstellen)
- Laufzeitschnittstelle (also zu Hardware, Betriebssystem usw.)
Prüfen Sie Ihre Software-Anforderungen gemäß dieser ISO 25010 Aspekte wie folgt:
| ISO 25010-Aspekt | (G)UI: Nutzer- Schnittstelle |
System- Schnittstellen |
Laufzeit- umgebung |
|---|---|---|---|
| Funktionalität (Functionality) | x | x | x |
| Zuverlässigkeit (Reliability) | x | x | x |
| Gebrauchstauglichkeit (Usability) | x | ||
| (IT-)Sicherheit (Security) | x | x | x |
| Effizienz (Efficiency) | x | x | x |
| Wartbarkeit (Maintainability) | |||
| Portabilität (Portability) | x | ||
| Kompatibilität (Compatibility) | x |
Es fällt auf, dass die Wartbarkeit über keine der Schnittstellen erfahrbar ist. Genau deshalb ist sie auch kein Gegenstand der Software-Anforderungen.
Eine gute Checkliste für Software-Anforderungen können Sie hier herunterladen.
Guten Morgen,
ich möchte ausdrücklich unterstützen, dass man sich zur ISO 25000 er Reihe informiert, es gibt mehrere gute Gründe.
1. Ein hoher Vertreter einer deutschen benannten Stelle gab schon letztes Jahr bekannt, dass seine Stelle nach dem „Stand der Technik“ fragen werde, nicht nur nach harmonisierten, weil die EU mit diesem Hilfsmittel nicht schnell genug dem Stand der Technik hinterher komme.
2. Ein Kunde berichtet, dass in China (!!!) für eine Zulassung seiner Software die Behörde (CFDA) gerade die ISO 25051 heranzieht, obwohl keine Compliance mit dieser Reihe behauptet wurde.
Wie immer wird es zwei min. Gruppen geben: Die einen, die ihre Energie hinein stecken, gegen die Anwendbarkeit der Norm zu argumentieren. Und diejenigen, die einfach mal die Vorteile davon suchen. Eine der Gruppen wird schneller am Ziel sein…
Eine schöne Woche noch
Peter Knipp
Lieber Herr Johner
bezüglich der Nützlichkeit d. ISO9126 resp. 25010 bin ich völlig mit Ihnen einverstanden. Das Qualitätsattribut „Wartbarkeit“ beurteile ich aus folgenden Gründen hingegen anders.
a.) Anforderungen an d. Wartbarkeit können auch an eine Blackbox gestellt werden. Da sehe ich keinen formalen Grund das auszuschliessen.
b.) Es ist gegenwärtig dasjenige Qualitätsattribut, das den deutlichsten Bezug zu den Lebenszykluserwartungen an das Produkt herstellt. Banale Aspekte wie:
– das Ding soll mindestens 10 Jahre im Markt bleiben oder
– es ist nur eine Übergangslösung,
werden am ehesten bei der Bearbeitung der Wartunganforderungen entdeckt. Das diese Anforderungen häufig einen kritischen Einfluss auf die System- und SW-Architektur haben, muss in diesem Blog wohl niemandem erläutert werden.
Man kann sicher darüber diskutieren, wie man das besser in den Standards verankert. Das Risiko Architektur-relevante Anforderungen wegzulassen, würde ich keinesfalls eingehen wollen. Ferner kommt hinzu, dass sich Konzepte wie zentral auf solche Anforderungen abstützen. Wer also seine SW nicht nur technisch sondern auch ökonomisch im Griff behalten möchte, ist gut beraten sich über Wartung früh, sehr viele Gedanken zu machen.
Freundliche Grüsse
Stefan Beisswenger
Sehr geehrter Herr Beisswenger,
ich stimme Ihnen absolut zu: Die Lebensdauer ist ein schönes Beispiel für eine Forderung im Kontext der Wartbarkeit. Allerdings eine schwer prüfbare. Darum ging es mir vor allem.
Ich stimme Ihnen auch zu, dass es „Anforderungen“ gibt, die einen Einfluss auf die Software-Architektur haben. Üblicherweise subsumiert man diese Art nicht in der Software Requirements Specification, sondern in den Rahmenbedingungen, die die Architektur zu kennen und zu berücksichtigen hat.
Der Unterschied mag nur semantisch sein. Im Medizinprodukteumfeld, bei dem die Traceability eine große Rolle spielt, halte ich ihn für einen nennenswerten.
Insgesamt glaube ich, dass wir keinen Dissens haben.
Herzlichen Dank für Ihre wertvollen Gedanken!
Beste Grüße
Christian Johner