Um Softwarequalität nach ISO 9126 geht es in der
einhundertdreiundachzigsten Episode des IT-Berufe-Podcasts. TL;DR
Softwarequalität bedeutet, dass Software die Anforderungen erfüllt,
die an sie gestellt werden. Ich gehe mit dir die sechs
Qualitätsmerkmale der ISO 9126 und ihre Unterpunkte durch, die du
als IT-Azubi in der Anwendungsentwicklung für die Praxis und die
AP2 kennen solltest. Dazu gehören konkrete Maßnahmen wie Code
Reviews und automatisierte Tests, mit denen du die Qualität während
der Entwicklung und im späteren Betrieb sicherst. Die ISO 9126
wurde durch die ISO 25010 abgelöst, wobei viele ihrer Begriffe
übernommen wurden. Kapitelmarken [00:00:00] Softwarequalität in
Praxis und Prüfung [00:03:34] Qualität als Übereinstimmung mit
Anforderungen [00:05:00] Stakeholder:innen und Anforderungen
priorisieren [00:06:37] Funktionale und nicht-funktionale
Anforderungen [00:08:50] Maßnahmen zur Qualitätssicherung
[00:10:22] Code Reviews und Tests [00:12:56] Entwicklungsprozess
und Dokumentation [00:14:30] Statische Codeanalyse, Pair
Programming und Bug-Tracker [00:16:02] Automatisierte
Qualitätssicherung mit CI/CD [00:17:16] ISO 9126 und ihre
Nachfolgerin ISO 25010 [00:19:25] Die sechs Qualitätsmerkmale der
ISO 9126 [00:20:47] Funktionalität und ihre Unterpunkte [00:25:26]
Benutzbarkeit und verständliche Oberflächen [00:30:35] Änderbarkeit
und langfristig wartbarer Code [00:32:01] Analysierbarkeit und
Modifizierbarkeit [00:34:20] Testbarkeit durch Dependency Injection
[00:36:12] Stabilität und Regressionstests [00:38:15] Effizienz:
Ressourcenverbrauch und Laufzeit [00:42:03] Wo sich das Optimieren
lohnt [00:43:46] Übertragbarkeit auf andere Umgebungen [00:47:43]
Koexistenz und konfigurierbare Netzwerkports [00:49:27]
Zuverlässigkeit: Fehlertoleranz und Reife [00:52:22]
Wiederherstellbarkeit nach Fehlern [00:54:37] Schwerpunkte für die
Anwendungsentwicklung [00:56:14] Ausblick auf ISO 25010 [00:56:39]
Shownotes und Newsletter Inhalt Definition von Qualität Qualität
ist der Grad der Übereinstimmung mit den Anforderungen. Da
verschiedene Stakeholder unterschiedliche Anforderungen an unser
Projekt haben, ist die Qualität recht subjektiv. Alle Stakeholder
zu 100% zufrieden zu stellen, wird in einem echten Projekt wohl
nicht möglich sein. Maßnahmen zur Qualitätssicherung Die
Softwarequalität kann mit verschiedenen konkreten Maßnahmen während
der Entwicklung sichergestellt werden. Diese nicht vollständige
Liste enthält einige Maßnahmen, die Prüflinge auch in ihrem eigenen
Abschlussprojekt anwenden können. Audits Code Reviews Testmethoden
Entwicklungsprozess Dokumentation Statische Codeanalyse Pair
Programming Bugtracking Continuous Integration/Delivery/Deployment
Softwarequalität nach ISO 9126 Funktionalität Angemessenheit
Interoperabilität Ordnungsmäßigkeit Richtigkeit Sicherheit
Änderbarkeit Analysierbarkeit Modifizierbarkeit Testbarkeit
Stabilität Übertragbarkeit Anpassbarkeit Austauschbarkeit
Installierbarkeit Koexistenz Effizienz Verbrauchsverhalten
Zeitverhalten Zuverlässigkeit Fehlertoleranz Reife
Wiederherstellbarkeit Benutzbarkeit Attraktivität Bedienbarkeit
Erlernbarkeit Verständlichkeit Literaturempfehlungen Hier gibt es
diese Podcast-Episode noch einmal als Video bei YouTube: Links
Permalink zu dieser Podcast-Episode RSS-Feed des Podcasts Video zur
Podcast-Episode bei YouTube ISO/IEC 9126 in der Wikipedia
Zusammenfassung Anforderungen erfüllen Wenn ich die Qualität meiner
Software bewerte, prüfe ich, wie gut sie die Anforderungen erfüllt.
Diese stammen von verschiedenen Stakeholder:innen, also Personen,
die ein berechtigtes Interesse am Projekt haben. Weil jede Person
eigene Anforderungen mitbringt, hängt das Urteil über die Qualität
von ihrer Perspektive ab. Bei einem Passagierflugzeug braucht ein:e
Pilot:in beispielsweise verständliche Instrumente im Cockpit. Für
eine:n Passagier:in spielt die Beinfreiheit eine Rolle.
Anforderungen können miteinander konkurrieren, weshalb du ihre
Priorität festlegen und festhalten solltest, von wem sie stammen.
Eine User-Story hält diesen Zusammenhang fest: "Als Rolle möchte
ich Funktionalität, damit …". Die Rolle zeigt, wer die Anforderung
stellt; die Begründung beschreibt ihren Zweck. Funktionale und
nicht-funktionale Anforderungen Funktionale Anforderungen
beschreiben, welche fachlichen Aufgaben die Software erfüllen soll.
Eine Rechnungswesen-Software muss beispielsweise Buchungssätze
verarbeiten und eine Bilanz erstellen können. Nicht-funktionale
Anforderungen betreffen Eigenschaften wie die Geschwindigkeit oder
die Frage, wie gut sich der Code später ändern lässt. Für einen
Buchungssatz lässt sich etwa festlegen, wie lange die Software
dafür brauchen darf. Die ISO-Normen und deine Prüfung Die ISO 9126
beschreibt international standardisierte Kriterien für
Softwarequalität. Sie wurde durch die ISO 25010 abgelöst, die viele
Begriffe übernimmt und weitere Kriterien enthält. Hier behandle ich
die ISO 9126 mit den deutschen Begriffen. Auch die englischen
Bezeichnungen gehören zum IT-Alltag, insbesondere beim Lesen von
Fachliteratur. Für die AP2 als Fachinformatiker:in
Anwendungsentwicklung solltest du alle sechs Hauptmerkmale
aufzählen und erklären können. Zu jedem Hauptmerkmal solltest du
außerdem ein bis zwei Unterpunkte kennen. Konkrete Beispiele helfen
dir, im Fachgespräch zu beschreiben, was du in deinem
Abschlussprojekt umgesetzt hast. Die sechs Qualitätsmerkmale der
ISO 9126 Funktionalität Bei meiner Rechnungswesen-Software prüfe
ich unter diesem Merkmal, ob sie die vorgesehenen Geschäftsprozesse
fachlich erfüllt. Dazu gehören fünf Unterpunkte: Angemessenheit:
Die Software bildet die Aufgabe mit einem passenden Aufwand ab. Wie
viele Schritte zum Buchen erforderlich sind, sollte zur Aufgabe
passen. Interoperabilität: Über Schnittstellen arbeitet die
Software mit anderen Anwendungen zusammen. Beispielsweise müssen
Buchhaltungsdaten an die Software einer Steuerberater:in
übermittelt werden können. Ordnungsmäßigkeit: Die Software hält
geltende Vorgaben ein, etwa die Grundsätze der ordnungsgemäßen
Buchführung oder einschlägige Standards. Richtigkeit: Fachliche
Ergebnisse müssen korrekt sein. Bei der Rechnung 5 + 3 muss das
Ergebnis 8 herauskommen, was sich mit einem Unit-Test prüfen lässt.
Sicherheit: Die Software schützt Daten und setzt erforderliche
Berechtigungen um. Wenn eine Überweisung ab einer bestimmten Summe
genehmigt werden muss, braucht sie dafür ein Rollen- und
Berechtigungskonzept mit entsprechender Authentifizierung.
Benutzbarkeit Wer mit deiner Software arbeitet, soll die
vorgesehenen Aufgaben gut erledigen können. Die ISO 9126
unterscheidet dabei vier Unterpunkte: Attraktivität: Eine
ansprechend gestaltete Oberfläche trägt dazu bei, dass
Anwender:innen mit der Software arbeiten möchten. Bedienbarkeit:
Die Software berücksichtigt Barrierefreiheit und die Erfahrung der
jeweiligen Anwender:in. Für Einsteiger:innen kann ein Assistent
hilfreich sein, während sich Hilfen nach dem Einstieg ausblenden
lassen sollten. Erlernbarkeit: Dokumentation und eingeblendete
Hilfen unterstützen neue Anwender:innen dabei, sich einzuarbeiten.
Verständlichkeit: Begriffe und Abläufe müssen nachvollziehbar sein.
Ein ausgeschriebenes "Umsatzsteuer" erleichtert das Verständnis
eines Formularfelds, dessen Beschriftung sonst nur "UST" lautet.
Abkürzungen können außerdem mehrdeutig sein, wie DSL für "Digital
Subscriber Line" und "Domain-Specific Language". Änderbarkeit Wenn
ich nach einem halben Jahr wieder an meinem Code arbeite, muss ich
mich erneut darin zurechtfinden. Dieses Merkmal betrifft die
Entwickler:innen, die die Software langfristig pflegen und
erweitern. Analysierbarkeit: Fehler und ihre Ursachen lassen sich
nachvollziehen. Logdateien können dafür den Zeitpunkt eines Fehlers
sowie eine Exception mit Stacktrace festhalten. Modifizierbarkeit:
Der Code lässt sich mit überschaubarem Aufwand anpassen. Design
Patterns und die SOLID-Prinzipien unterstützen das. Beim
Open-Closed-Prinzip erfolgt eine Erweiterung beispielsweise über
eine zusätzliche Klasse, während bestehende Klassen unverändert
bleiben. Testbarkeit: Wie du den Code gestaltest, beeinflusst, wie
gut sich einzelne Komponenten testen lassen. Durch Dependency
Injection erhält eine Klasse ihre Abhängigkeiten von außen. Im Test
kann dann eine Fake-Datenbank über ein Interface übergeben werden,
sodass die Komponente isoliert geprüft werden kann. Stabilität:
Nach einer Änderung sollen die bereits vorhandenen Funktionen
weiterhin arbeiten. Regressionstests prüfen das und können bei
jedem Build in einer CI/CD-Pipeline laufen. Auch indirekte
Abhängigkeiten zwischen Komponenten müssen dabei berücksichtigt
werden. Effizienz Für meine Anwendung muss ich abwägen, welche
Anforderungen an Laufzeit und Ressourcenverbrauch bestehen. Dabei
können Zielkonflikte entstehen, etwa wenn ein Algorithmus durch
zusätzlichen Speicher schneller arbeitet. Verbrauchsverhalten: Hier
geht es um begrenzte Ressourcen wie Arbeitsspeicher oder
Netzwerkbandbreite. Auch der Platz auf der Festplatte zählt dazu.
Zeitverhalten: Dazu gehören die Laufzeit und die Komplexität von
Algorithmen, die sich mit der Big-O-Notation beschreiben lässt. Ein
In-place-Sortieralgorithmus arbeitet auf dem vorhandenen Array.
Andere Verfahren benötigen zusätzlichen Speicher. Welche Lösung
passt, hängt unter anderem von der Datenmenge und davon ab, wie
häufig die Aufgabe ausgeführt wird. Beim Optimieren solltest du
Zeit dort investieren, wo sie sich auf die Anwendung auswirkt. Bei
einer Web-Anwendung können Netzwerkwege oder das Rendern im Browser
die Antwortzeit bestimmen. Für eine Echtzeitanwendung,
beispielsweise den Notaus einer Maschine, müssen die vorgegebenen
Reaktionszeiten zuverlässig eingehalten werden. Hoher
Ressourcenverbrauch wirkt sich außerdem auf den Stromverbrauch und
auf andere Anwendungen aus. Übertragbarkeit Wenn meine Software in
einer anderen Umgebung laufen oder später abgelöst werden s
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.