Open dune73 opened 3 years ago
melchl
commented
3 years ago 25.2.3: "alle verwendeten Funktionen sind in den Spezifikationen definiert." - Ist das realistisch, inklusive aller rekursiven Abhängigkeiten? Müsste vielleicht präzisieren, bis auf welche Ebene das geschehen soll.
christiankiller
commented
3 years ago Denke schon, oder? Wenn man das initial aus javadoc was generiert und dann ergänzt?
melchl
commented
3 years ago Wenn man auf Java-Ebene bleibt, dann könnte das technisch theoretisch machbar sein. Doch Java wiederum ruft ja Funktionen des Betriebssystems auf.
Wortlaut der Vorlage
25. Qualität Quellcode und Dokumentation Der Quellcode und die Dokumentation erfüllen, mindestens die folgenden Qualitätskriterien:
25.1 Nachvollziehbarkeit
25.1.1 Als Nachvollziehbarkeit wird die Stringenz von den Anforderungen bis hin zur Implementierung verstanden.
25.1.2 Alle Anforderungen an das kryptografische Protokoll sind über sämtliche Arbeitsergebnisse im Zusammenhang mit dem Softwareentwicklungsprozess hinweg nachvollziehbar.
25.1.3 Für die Verbindung zwischen den rechtlichen Anforderungen und dem Protokoll, den Spezifikationen sowie der Dokumentation der Architektur gibt es einen Beschrieb.
25.2 Vollständigkeit
25.2.1 Als Vollständigkeit gilt die vollständige Umsetzung der geforderten Funktionen.
25.2.2 Die Software enthält keine mehrdeutigen Verweise (Input, Funktion, Output). Wird dasselbe Element referenziert, wird dazu immer die gleiche Bezeichnung verwendet.
25.2.3 Alle referenzierten Daten und alle verwendeten Funktionen sind in den Spezifikationen definiert.
25.2.4 Es werden alle in den Spezifikationen definierten Funktionen verwendet.
25.2.5 Für jeden Entscheidungspunkt (z. B. bedingte Ausführung) sind die möglichen Alternativen in den Spezifikationen definiert.
25.2.6 Alle Parameter sind in den Spezifikationen definiert und validiert (keine implizite Parameterübergabe).
25.2.7 Alle schwerwiegenden, gemeldeten Fehler werden behoben, bevor mit dem nächsten Schritt im Entwicklungszyklus fortgefahren wird.
25.2.8 Das kryptografische Protokoll, die Spezifikation, das Design und der Quellcode sind aufeinander abgestimmt.
25.3 Kohärenz
25.3.1 Als Kohärenz gilt die Verwendung einheitlicher Verfahren und Notationen bei der Konzeption und der Implementierung.
25.3.2 Die Darstellungen in der Dokumentation entsprechen einer Konvention, die die Softwareentwicklerin oder der Softwareentwickler erstellt hat.
25.3.3 Die Funktionen und die Variablen entsprechen einer Namenskonvention, die die Softwareentwicklerin oder der Softwareentwickler erstellt hat.
25.3.4 Input und Output von Funktionen werden nach einer Konvention behandelt, die die Softwareentwicklerin oder der Softwareentwickler erstellt hat.
25.3.5 Fehler werden nach einer Konvention behandelt, die die Softwareentwicklerin oder der Softwareentwickler erstellt hat.
25.3.6 Die verwendeten Variablentypen sind kohärent.
25.4 Einheitlichkeit der Kommunikation
25.4.1 Als Einheitlichkeit der Kommunikation gilt die Verwendung von standardisierten Protokollen und Schnittstellenroutinen.
25.4.2 Die Regeln für die Kommunikation mit anderen Systemen sind definiert.
25.4.3 Die Kommunikation basiert auf standardisierten Kommunikationsmethoden.
25.5 Einheitlichkeit der Daten
25.5.1 Als Einheitlichkeit der Daten gilt die Eigenschaft, die die Verwendung einer standardisierten Darstellung der Daten ermöglicht.
25.5.2 Die Standarddarstellung der Daten für die Kommunikation mit anderen Systemen wird formell festgelegt.
25.5.3 Für Konvertierungen zwischen den verschiedenen Darstellungen werden Standards festgelegt.
25.5.4 Die Konvertierungsfunktionen sollten in einem Modul zentralisiert werden.
25.6 Erlernbarkeit
25.6.1 Als Erlernbarkeit gilt die Eigenschaft der Software, die es den Benutzerinnen und Benutzern ermöglicht, sich die Bedienung der Software leicht anzueignen.
25.6.2 Personen, die das System betreiben und anwenden, werden geschult und mit der notwendigen Dokumentation bedient.
25.6.3 Die Schulung beinhaltet die Möglichkeit, an einem dafür vorgesehenen System zu trainieren.
25.6.4 Hilfestellungen zur Bedienung sind leicht zugänglich.
25.7 Bedienbarkeit
25.7.1 Als Bedienbarkeit gilt die Nutzungsqualität bei der Interaktion mit dem System.
25.7.2 Die Software ist benutzerfreundlich. Die Benutzerführung richtet sich nach allgemein bekannten Schemen.
25.7.3 Der clientseitige Teil der Software entspricht dem Accessibility Standard eCH- 0059 (eCH-0059: Accessibility Standard Version 3.0 vom 25.06.2020; der Standard kann kostenlos bezogen und eingesehen werden beim Verein eCH, Mainaustrasse 30, Postfach, 8034 Zürich; http://www.ech.ch.).
25.8 Fehlertoleranz
25.8.1 Mit der Fehlertoleranz wird die Weiterführung des Betriebs unter Ausnahmebedingungen ermöglicht.
25.8.2 Fehler werden erkannt und behandelt, damit das Programm ohne Unterbrechung weiterlaufen kann.
25.8.3 Die Fehlerbehandlung (einschliesslich der Erfassung im Protokoll) erfolgt auf derjenigen Ebene, die für die Weiterführung des Betriebs am relevantesten ist. Ein Fehler, der in einer Ebene nicht bearbeitet werden kann, wird in die nächsthöhere Ebene übertragen.
25.8.4 Für die Inputparameter werden Gültigkeitsbedingungen definiert.
25.8.5 Alle Inputparameter werden vor Beginn der Ausführung überprüft.
25.9 Modularität
25.9.1 Als Modularität gilt die Eigenschaft der Software, die eine Struktur von hochgradig unabhängigen Modulen bietet.
25.9.2 Die Aufgabe der einzelnen Module wird klar definiert.
25.9.3 Die Aufgabe der einzelnen Module sollte eng und fokussiert sein und die Aufgaben zweier Module sollten sich nicht überschneiden.
25.9.4 Die Module teilen keine Daten über einen gemeinsamen volatilen Speicher (z. B. globale Variable).
25.10 Einfachheit
25.10.1 Als Einfachheit gilt die Implementierung der Funktionen auf die verständlichste Art. Im Allgemeinen bedeutet dies, dass Praktiken vermieden werden, die die Komplexität erhöhen.
25.10.2 Im Design wird ein Top-Down-Ansatz (hierarchische Struktur) gewählt.
25.10.3 Das Design sieht keine Verdoppelung von Funktionen zwischen den Modulen vor.
25.10.4 Das Design sieht keine globalen Daten vor, d. h. keine Daten, die von allen verwendet werden können, ohne als Parameter übergeben zu werden.
25.10.5 Komplizierte boolesche Kombinationen im Quellcode werden vermieden.
25.10.6 Im Quellcode werden keine Variablen für andere als die ursprünglich vorgesehenen Zwecke wiederverwendet.
25.10.7 Im Quellcode wird die Anzahl von Verschachtelungen so weit wie möglich beschränkt.
25.10.8 Die zyklomatische und kognitive Komplexität im Quellcode wird so weit wie möglich beschränkt.
25.11 Prägnanz
25.11.1 Als Prägnanz gilt, wenn eine Funktion mit einem Minimum an Instruktionen im Quellcode implementiert werden kann.
25.11.2 Die Software enthält keine überflüssigen Abschnitte im Quellcode (sogenannten «Dead Code»).
25.11.3 Der Quellcode enthält keine überflüssigen Variablen.
25.11.4 Der Quellcode enthält keine Wiederholungen.
25.12 Verständlichkeit
25.12.1 Als Verständlichkeit gilt, wenn die Adressatinnen und Adressaten die Zielsetzung, Annahmen, Einschränkungen, Input und Output, Komponenten und Status der Software erkennen können.
25.12.2 Klassen, Funktionen und komplexe Verarbeitungsschritte werden im Quellcode nach einer von der Softwareentwicklerin oder dem Softwareentwickler festgelegten Konvention kommentiert.
25.12.3 Variablen und Funktionen werden mit aussagekräftigen Namen bezeichnet.
25.12.4 Pro Zeile wird eine Anweisung erstellt. Anweisungen, die sich auf mehrere Zeilen beziehen, und mehrere Anweisungen pro Zeile sind zu vermeiden.
25.13 Instrumentierung
25.13.1 Als Instrumentierung gilt eine Eigenschaft der Software, die es erlaubt, ihre Nutzung zu messen oder Fehler zu erkennen.
25.13.2 Die Unit-Tests (Bei einem Unit-Test testet der Entwickler ein Modul unabhängig vom Rest des Programms, um sicherzustellen, dass das Modul die funktionalen Spezifikationen erfüllt und unter allen Umständen korrekt funktioniert. Diese Überprüfung wird bei kritischen Anwendungen als unerlässlich angesehen.) decken alle möglichen Pfade und die zulässigen Werte der Inputparameter ab.
25.13.3 Die Integrationstests decken alle Module ab.
25.13.4 Die Softwaretestszenarien decken alle Module ab.
25.13.5 Fehler und notwendige Informationen werden in Logs protokolliert.
Referenzen
Ziff. 25 Qualität Quellcode und Dokumentation
Die Qualität des Quellcodes und der Dokumentation ist ein zentrales Element für die Sicherheit von E-Voting. In den bisherigen Rechtsgrundlagen wurden entsprechende Anforderungen gestellt. Diese um-fassten jedoch eher allgemeine Umschreibungen, wie etwa die Aufbereitung und Dokumentation nach besten Praktiken und die Umsetzung bestimmter Punkte der Common Criteria. Die bisherigen Qualitätskriterien wurden daher präzisiert. Mit klaren Kriterien soll eine hohe Qualität der E-Voting-Systeme sichergestellt, was wiederum der Sicherheit zugutekommt, indem die Prüfungen aller Akteure sowie der Öffentlichkeit erleichtert werden. Um diese Qualitätskriterien zu definieren, wurde ein Qualitätsmodell für die E-Voting-Systeme erstellt. Dieses Modell basiert auf dem Standard ISO 25010 und auf dem Qualitätsmodell von McCall^13. Die Kriterien wurden nach ihrem Beitrag zu den definierten Sicherheits- und Qualitätszielen ausgewählt.