Zur Auffindung von Problemen ist die Ausschussmethode meistens ein bewaehrtes Mittel. In diesem Fall, ist sie aber nicht besonders benutzerfreundlich, weil man dafuer unverhaeltnismaessig viel Zeit vom Verwender in Anspruch nehmen muss. Zunaechst einmal soll der Benutzer einzelne Datensaetze ausschalten, um zu sehen, ob das Programm mit eingeschraenkter Suche durchlaeuft. Hat man den/die betroffen(d)en Datensatz/Datensaetze ermittelt, wartet man auf weitere Anweisungen des Teams. Nun wird vorgeschlagen, einzelne Produktgruppen aus dem Datensatz zu deaktivieren. Hat man letztendlich ein Produkt gefunden kann das Team endlich in Kraft treten und versucht dann anhand der Erkennungsregeln fuer das Produkt den Fehler zu finden. Das kann schon eine Weile dauern, da es sich schon um einige Regeln handeln koennte und man diese prinzipiell alle durchgehen muss. Im Moment gibt es 113219 Erkennungsregel fuer 3578 Produkte, im Schnitt also 32 Regeln pro Produkt.
Wenn wir vorlaeufig alles zusammenrechnen:
Anzahl der Versuche(SBI) multipliziert mit der Scandauer, plus Anzahl der Versuche(Produkte) mal Scandauer, plus Anzahl der Kontrollen einzelner Erkennungsregeln, plus die Zeit zum Kommunizieren.
Wenn man das beruecksichtigt, kann schon viel Zeit vergehen und die Erfahrung zeigt, dass kaum ein Benutzer bis zum bitteren Ende das Spiel mitmacht. Ergebnis, ein frustierter Benutzer trotz engagiertem Einsatz und ein moegliches verbliebenes Problem im Programm, welches immer noch nicht gefunden wurde.
Diese Kritik soll aufzeigen, dass eine Ausschussmethode normalerweise nur als letztes Mittel dienen sollte und man sich immer im Klaren sein sollte, was man da vom Benutzer verlangt. Das beschriebene Problem tritt bereits seit langer Zeit vereinzelt auf und wenn man ehrlich ist, wurde bisher keine angemessene Loesung mit der Ausschussmethode gefunden.
Daher ist es sehr erfreulich, dass sich jemand bereits der Sache angenommen hat. Der Entwickler hat mit der neusten Version die Fehlersuche deutlich vereinfacht. Also wenn sich schon jemand Gedanken darum gemacht hat und Arbeit darin investiert hat, was hindert einen noch daran, es auch zu verwenden.
Wie es scheint wurde ein neuer Parameter fuer die Kommandozeile eingefuegt, die die Fehlersuche deutlich erleichtern soll:
/verbose
http://forums.spybot.info/showthread.php?t=23560
Damit soll die Anzahl der Scanversuche von Seiten des Benutzers im Idealfall auf einen reduziert werden.(Im Fall von Nibbler waere es denkbar, dass entweder eine Erkennungsregel in mehreren Datensaetzen verwendet wurde oder vielleicht sind mehrere Erkennungsregeln am Problem beteiligt.) In der Statuszeile am unteren Rand wird nun eine Verschluesselungsnummer angeben, die im Falle eines Haengers, die letzte verwendete Erkennungsregel angibt. Das Team kann dann die Erkennungsregel genauer unter die Lupe nehmen. Spaetestens jetzt sollte es als neue Fehlersuchroutine fuer derartige Faelle eingefuehrt werden. Diese Methode ist der Ausschussmethode vorzuziehen, da sie weniger vom Benutzer abverlangt.
Allerdings ist auch damit nicht gewaehrleistet, das man das Problem findet. Schliesslich muss es nicht zwangslaeufig an den Erkennungsregeln liegen. Die Anzahl der gemeldeten vergleichbaren Probleme ist im Vergleich zu den Millionen von Systemen, die mit den selben Datensaetzen problemfrei laufen, verschwindend gering. Damit muesste es offentsichtlich sein, dass die Erkennungsregel allein nicht ausreicht, um spezifische Probleme zu loesen. Aber es kann entscheidende Hinweise liefern, wonach man ueberhaupt suchen soll.
Die Beteiligungsbereitschaft eines Benutzers ist haeufig begrenzt und nichts ist frustrierender als Zeit in etwas zu investieren, dass am Ende zu nichts fuehrt. Ganz besonders, wenn das Problem nur in der Nutzung des Programms selbst liegt und vergleichbare Programme offentsichtlich nicht das Problem aufweisen.
Wenn wir vorlaeufig alles zusammenrechnen:
Anzahl der Versuche(SBI) multipliziert mit der Scandauer, plus Anzahl der Versuche(Produkte) mal Scandauer, plus Anzahl der Kontrollen einzelner Erkennungsregeln, plus die Zeit zum Kommunizieren.
Wenn man das beruecksichtigt, kann schon viel Zeit vergehen und die Erfahrung zeigt, dass kaum ein Benutzer bis zum bitteren Ende das Spiel mitmacht. Ergebnis, ein frustierter Benutzer trotz engagiertem Einsatz und ein moegliches verbliebenes Problem im Programm, welches immer noch nicht gefunden wurde.
Diese Kritik soll aufzeigen, dass eine Ausschussmethode normalerweise nur als letztes Mittel dienen sollte und man sich immer im Klaren sein sollte, was man da vom Benutzer verlangt. Das beschriebene Problem tritt bereits seit langer Zeit vereinzelt auf und wenn man ehrlich ist, wurde bisher keine angemessene Loesung mit der Ausschussmethode gefunden.
Daher ist es sehr erfreulich, dass sich jemand bereits der Sache angenommen hat. Der Entwickler hat mit der neusten Version die Fehlersuche deutlich vereinfacht. Also wenn sich schon jemand Gedanken darum gemacht hat und Arbeit darin investiert hat, was hindert einen noch daran, es auch zu verwenden.
Wie es scheint wurde ein neuer Parameter fuer die Kommandozeile eingefuegt, die die Fehlersuche deutlich erleichtern soll:
/verbose
http://forums.spybot.info/showthread.php?t=23560
Damit soll die Anzahl der Scanversuche von Seiten des Benutzers im Idealfall auf einen reduziert werden.(Im Fall von Nibbler waere es denkbar, dass entweder eine Erkennungsregel in mehreren Datensaetzen verwendet wurde oder vielleicht sind mehrere Erkennungsregeln am Problem beteiligt.) In der Statuszeile am unteren Rand wird nun eine Verschluesselungsnummer angeben, die im Falle eines Haengers, die letzte verwendete Erkennungsregel angibt. Das Team kann dann die Erkennungsregel genauer unter die Lupe nehmen. Spaetestens jetzt sollte es als neue Fehlersuchroutine fuer derartige Faelle eingefuehrt werden. Diese Methode ist der Ausschussmethode vorzuziehen, da sie weniger vom Benutzer abverlangt.
Allerdings ist auch damit nicht gewaehrleistet, das man das Problem findet. Schliesslich muss es nicht zwangslaeufig an den Erkennungsregeln liegen. Die Anzahl der gemeldeten vergleichbaren Probleme ist im Vergleich zu den Millionen von Systemen, die mit den selben Datensaetzen problemfrei laufen, verschwindend gering. Damit muesste es offentsichtlich sein, dass die Erkennungsregel allein nicht ausreicht, um spezifische Probleme zu loesen. Aber es kann entscheidende Hinweise liefern, wonach man ueberhaupt suchen soll.
Die Beteiligungsbereitschaft eines Benutzers ist haeufig begrenzt und nichts ist frustrierender als Zeit in etwas zu investieren, dass am Ende zu nichts fuehrt. Ganz besonders, wenn das Problem nur in der Nutzung des Programms selbst liegt und vergleichbare Programme offentsichtlich nicht das Problem aufweisen.
