Seite 2: Beispiel

Inhaltsverzeichnis

Verdeutlichung am Beispiel

Als Nächstes sollte die Anwendung in Komponenten unterteilt werden. Hilfreich bei der Klassenbildung ist die Orientierung an den Geschäftsprozessen. Bei der Klassenbildung ist darauf zu achten, dass Komponenten mit unterschiedlicher Einschätzung auch differenziert betrachtet werden. Erst durch die Differenzierung kann eine angemessene Maßnahmenplanung für die Komponente oder den Geschäftsprozess erfolgen. Bei einer überwiegend hohen bis sehr hohen Einstufung sollte man die Aufteilung der Geschäftsprozesse hinterfragen. Das ist normalerweise ein Indiz für eine zu grobe Trennung.

Die Handhabung wird nun anhand des Beispiels "Einsatz einer Telefonaufzeichnung für das Telefonbanking in einer Bank" durchgespielt. Das Ergebnis der Bewertung sollte wie in Tabelle 5 oder in ähnlicher Form festgehalten werden, damit die Einschätzung für das Projektteam jederzeit transparent und nachvollziehbar ist. Die Bewertung sollte der Projektleiter gemeinsam mit dem Fachbereich kritisch hinterfragen.

Bezeichnung	pers. Daten	Grundwert	Schutzbedarf
Telefonbanking: Aufzeichnung und Entgegennahme eines Kundenauftrags	x	Vertraulichkeit	sehr hoch
		Integrität	sehr hoch
		Verfügbarkeit	hoch
User-Neuanlage-Berater	-	Vertraulichkeit	gering
		Integrität	normal
		Verfügbarkeit	gering
Logfile für IT-Betrieb	-	Vertraulichkeit	gering
		Integrität	gering
		Verfügbarkeit	gering

Nach der Feststellung des Schutzbedarfs und dem daraus resultierenden Risiko lässt sich diese Einstufung im Projekt zur Planung der weiteren Maßnahmen heranziehen. Das Beispiel der Software-Prüftechniken demonstriert das nun.

Im Beispielprojekt haben sich die Projektleitung und das Testmanagement im Wesentlichen auf die folgenden Prüfarten verständigt:

1. Whitebox-Test durch die Entwickler
2. Blackbox-Test durch die Tester in den Ausprägungen [2] Ad-hoc- und funktionsorientierter Test

Auf weitere Prüftechniken und -stufen (u. a. Anwendungs-, Integrationstest) geht der Artikel zur Erläuterung der risikobasierten Vorgehensweise nicht ein. Sie sind im jeweiligen Projekt natürlich auch zu beachten.

Mit dem Whitebox-Test stellt der Entwickler die grundsätzliche Funktionsfähigkeit seiner Software mit Codeanalyse und -Reviews sicher. Erst nach dem bestandenen Whitebox-Test übergibt er die Software an das Testmanagement. Das Testteam ermittelt anschließend im Blackbox-Test die Testfälle anhand der Anwendungs- beziehungsweise Systemdokumentation. Im funktionsorientierten Test kommen die Äquivalenzklassenbildung, Ursachen-Wirkungs-Analyse, Entscheidungstabellen und die Grenzwertanalyse zum Einsatz. Bei der Testdatenerstellung berücksichtigen die Tester mindestens die Unter-, Ober- und Mittelwerte bei den Eingabedaten.

Beim Ad-hoc-Test wird auf eine systematische Vorgehensweise verzichtet, stattdessen bildet man übliche Geschäftsvorfälle ab. Bei der Testdatenerstellung ziehen die Beteiligten typische beziehungsweise praxisrelevante Werte heran. Durch den Verzicht beim Ad-hoc-Test auf Dokumentation und systematische Herangehensweise lässt sich mit dieser Prüftechnik deutlich Aufwand sparen. Die zwei Ansätze unterscheiden sich damit wesentlich in der Testabdeckung. Beim funktionsorientierten Ansatz wird im Vergleich zum Ad-hoc-Test eine deutlich höhere Testabdeckung erreicht. Ohne die zuvor durchgeführte Kategorisierung wären nun unter Risikogesichtspunkten für alle Komponenten ein Whitebox-Test und der funktionsorientierte Test durchzuführen. Alles andere wäre hinsichtlich des Qualitätsergebnisses zufällig.

Nach Festlegung des Schutzbedarfs und der Prüftechniken kann die Zuordnung der Prüftechnik erfolgen. Die Schutzbedarfsausprägung "Vertraulichkeit" hat nur indirekt Auswirkungen auf den Testumfang. Vielmehr sind daraus entsprechende Sicherheitsanforderungen abzuleiten. Die Vertraulichkeit lässt sich in dieser Betrachtung vernachlässigen. Die Zuordnung sollte gemeinsam mit dem Auftraggeber beziehungsweise Fachbereich erarbeitet werden. Auf Basis der Zuordnung in Tabelle 6 kann man nun die konkret anzuwendende Prüftechnik auswählen. Das Ergebnis der Prüftechnikauswahl für Beispielkomponenten dokumentiert Tabelle 7. Bei einer abweichenden Einstufung der Ausprägung Verfügbarkeit und Integrität wird die höchste Schutzbedarfskategorie ausgewählt.

Schutzbedarfsausprägung	Schutzbedarfskategorie	Prüftechniken
Verfügbarkeit	hoch/sehr hoch	Whitebox-, funktionsorientierter Test
Verfügbarkeit	Normal	Whitebox-, Ad-hoc-Test
Verfügbarkeit	Gering	Whitebox-Test
Integrität	hoch/sehr hoch	Whitebox, funktionsorientierter Test
Integrität	Normal	Whitebox-, Ad-hoc-Test
Integrität	Gering	Whitebox-Test

Komponente	Schutzbedarf	Anzuwendende Testfallermittlungsart
Telefonbanking: Aufzeichnung und Entgegennahme eines Kundenauftrags	sehr hoch	Whitebox-, funktionsorientierter Test
User-Neuanlage-Berater	normal	Whitebox-, Ad-hoc-Test
Logfile für den Betrieb	gering	Whitebox-Test