PureBoard

Hallo,

ich bin in der "glücklichen" Lage eine Prüfanleitung schreiben zu dürfen. Für diejenigen, die sowas nicht kennen, sei gesagt: Eine Prüfanleitung "DAU"-sicher zu machen strebt mathematisch gesehen gegen 0 Prozent.

Meine Frage nun an alle. Hat jemand von euch Erfahrung mit dem Erstellen und Warten von Prüfanleitungen?
Ich wollte zuerst was mit PB machen. Da nun aber doch sehr schnell ein sichtbares Ergebnis verlangt wird, mache ich es als HTM- Dateien und kompiliere es dann zu eine CHM.
Das sieht halbwegs ansprechend aus. Lässt sich auch relativ einfach warten. Liefert schnell Ergebnisse.

Hat einer von euch einen Vorschlag, wie man es besser machen könnte?

Danke im Voraus

Torsten

> Für diejenigen, die sowas nicht kennen

yo, ich kann mir nix drunter vorstellen...

> Eine Prüfanleitung "DAU"-sicher zu machen strebt mathematisch gesehen gegen 0 Prozent.

yo ok, das gilt für vieles... xD

Ok, also ein bißchen Erklärungsbedarf.
Stellt euch vor, ihr habt ein System (elektrisch, elektronisch, hydraulisch oä.) vor euch. Dieses System soll auf Fehlverhalten untersucht werden. Sind Fehler vorhanden, sollen die Ursachen gefunden und beseitigt werden.

Und hier kommt jetzt eine Prüfanleitung ins Spiel. In dieser Anleitung wird das vorhandene System Schritt für Schritt überprüft und je nach Ergebnis der Prüfung wird zum nächsten Prüfschritt verzweigt.

Als Beispiel: Habe ich damit ungefähr das Prinzip erklären können?

Torsten

yo alles roger. danke.
kannte nur den begriff nicht.

Ich kenne das unter dem Begriff "Expertensystem". Dabei fragt das Programm verschiedene Sachen und je nachdem wird am Ende ein oder mehrere bestimmte Lösungsvorschläge gegeben.

In der Windows-Hilfe ist so ein Ding integriert. Da gibts doch diesen "Problemlösungs-Assistent", der ne Reihe fragen stellt und Lösungen vorgibt. Das ist sowas.


Ja, wie macht man sowas. Nun, stelle ne Liste aller möglichen Probleme zusammen (z.B. Bedienungsfehler, Defekte, etc.).
Dann sortierst du das nach Häufigkeit der Probleme. Also DAU-Probleme kommen öfter vor, deshalb sollten die eher dran kommen als beispielsweise Stromausfälle.
Tja, und dann die Fragen abarbeiten lassen.

Die Antworten, die der User gibt, müssen gespeichert werden. Jede Antwort muss einen bestimmten Wert an das Programm weitergeben, zB "mechanische Problem".

Diese Werte werden mit der Problemlösungsliste verglichen. Hat eine Lösung unter anderem den Wert "mechanisches Problem", dann wird die eher angezeigt als andere Lösungen.

Am Beispiel läßt es sich besser erklären: Lampe (vereinfacht)

Frageliste
A) Schalter gedrückt?
B) Glühbirne funktionsfähig?
C) Strom da?

Antwortliste
Aa) "Ja" -> "Kein-DAU-Fehler"
Ab) "Nein" -> "DAU-Fehler"
Ba) "Ja" -> "Birne-ganz"
Bb) "Nein" -> "Birne-defekt"
Ca) "Ja" -> "Strom-da"
Cb) "Nein" -> "Kein-Strom-da"

Lösungsliste (zuerst die Werte, dann die Lösung)
Ab - Schalter umlegen
Aa,Bb - Glühbirne ersetzen
Aa,Ba,Cb - Strom anlegen
Ab,Ba,Ca - Problemlösung unbekannt

Das Programm muss nur einfach die Werte vergleichen bzw. die Lösung suchen, wo sich die Werte am meisten übereinstimmen.

Viel Erfolg, sowas ist normalerweise ziemlich umfangreich.

Gemacht habe ich das schon einige Male.
Selbst dieses einfache Beispiel mit der Lampe kann (oder muss für den eventuellen Ausbau) man schon in Gruppen einteilen.
Z.B. müssen Bedienfehler ganz klar bei Prüfvoraussetzungen ausgeschlossen werden.

Bis jetzt ist mir aber (für mich) noch nichts Günstigeres eingefallen als Webseiten.

Da kann man den Text (das, was der User machen oder prüfen soll) einfach oben hinstellen. Und per Links wird dann zu anderen Stellen im Dokument oder eben auch zu anderen Dokumenten gesprungen.

Das ganze in eine CHM mit einer vernünftigen Struktur - passt.

Programmiert habe ich das auch schon mal. Ist lange her. Das Programm stellt praktisch ein Frame für Datensätze da, die je nach Auswahl des Users dann angesprungen werden.

Ich habe mir schon mal überlegt, das Ganze als Datenbank zu machen. Datensätze indizieren und darauf zugreifen. (z.B. Klick auf ja oder was anderes -> zugehörigen Index ermitteln -> Datensatz zum Index anzeigen lassen).

Und umfangreich ist es. Sonnenklar. Man muss ja alle Eventualitäten abklappern.

Ich werde bis auf Weiteres mal wie bisher weiter machen. Dann habe ich wenigstens schon mal die Daten eingegeben

Wenn euch noch was einfällt - nur zu

@ Laurin
werde mal diesen "Lampentest" darstellen, wie ich das machen würde. Damit du siehst, was genau ich vorhabe.


Torsten

klar, ne CHM is ne gute oberfläche dafür...

aber wenn man das programmieren will, z.b. mit Requestern...

könnte man nicht die Basis in ne XML packen, und ne Hauptschleife, die daraus Requester macht?

XML - ja, das ist vielleicht eine gute Idee. Die Daten haben ja im Grunde genommen immer das gleiche Format.
Und ich hatte mir das eigentlich so gedacht:
Die ganze GUI des Programms stellt, wenn man so will, einen Requester da. Du hast zentral ein Textgadget, in welchem die Mitteilungen stehen, die der User ausführen oder prüfen soll. Und darunter eine Anzahl von Buttons (je nach Anforderung aktiviert oder nicht) z.B. Ja, Nein oder eventuell eine Liste mit Auswahlmöglichkeiten. (und ganz wichtig ist der Button "Such dir 'nen anderen Job":lol:)
Na mal sehen.

Der kleine Lampentest ist hier zu sehen: www.tmjuk.de/lampentest.htm

Es ist wirklich bloß ein sehr einfaches Beispiel. Eben nur um zu sehen, wie ich es bisher mache.

Und es bringt wie gesagt schnell Ergebnisse und die Wartung ist leicht.
Wenn ich das programmiere, müsste ich natürlich auch einen Editor für die Datenerfassung machen. Und der wäre wahrscheinlich bedeutend umfangreicher als die eigentliche Anzeige.

yo ich denk auch, wenn du das ganze als interface für ein XML-protokoll realisierst,
dann kann das interface jede beliebige Prüfanleitung ausführen/darstellen,
die du als adäquate XML-Datei zur verfügung stellst....

tmjuk hat geschrieben:Der kleine Lampentest ist hier zu sehen: www.tmjuk.de/lampentest.htm

Es ist wirklich bloß ein sehr einfaches Beispiel. Eben nur um zu sehen, wie ich es bisher mache.

Machbar, für mich wäre das allerdings zuviel Aufwand. Du musst ja wirklich jeden Fall berücksichtigen.

Bei meinem System können durch den Wertvergleich zwischen Antworten und Lösungensvorschlägen mehrere Lösungen gleichzeitig vorgeschlagen werden. Falls eine nicht funktioniert, präsentiert das Programm die nächstähnliche Lösung.

Man kann mein System so weit erweitern, dass Lösungsvorschläge während des Frage-Antwortspielchens eingeblendet werden. Allerdings sind da die Lösungen eventuell nicht zum Problem passend. Die richtige Lösung präsentiert das Programm normalerweise erst, wenn genügend Antworten da sind.

Würde man bei meinem Beispiel die Antwort Aa) geben, dann würden als Lösungsvorschläge
Aa,Bb - Glühbirne ersetzen
und
Aa,Ba,Cb - Strom anlegen
angezeigt werden.

Die Sache mit den ähnlichen Werten ist eine Art Puffer bei fehlerhaften Eingaben (macht das Frage-Antwort-Spielchen DAU-sicherer). Falls eine Frage falsch beantwortet wurde (wie DAUs da eben so machen), ist das Programm dennoch in der Lage, die passende Lösung zu finden.
Deine Variante würde wohl zielstrebig bis zum Ende einen falschen Weg gehen.

Das Programm ist eigentlich recht simpel. Sowas sollte man ohne Probleme innerhalb eines Tages in PB programmieren können. Nur die Datenbank füttern kann ewig dauern. Die Wartung ist auch nicht unbedingt leicht. Sobald eine Frage & Antwort hinzukommt, kann es sein, dass man bei dutzenden Lösungen die Werte ändern muss. Da ist dein System wartungsfreundlicher.


Edit:
Mir fällt gerade auf, dass mein System zum Problem passende Fragen stellen kann. Abhängig von den ersten Antworten kann das Programm ja schon eine Vorauswahl der möglichen Lösungen liefern. Jetzt braucht es nur noch diese Lösungen betreffende Fragen stellen, um die Auswahl weiter zu verkleinern.
Dann ist das allerdings ein echtes Expertensystem.

Edit 2:
Die Sache mit dem Editor ist recht einfach. Im Grunde ist es ja "nur" das Anzeigeprogramm mit Schreibunterstützung. Ok, es müssten ein paar mehr Sachen angezeigt werden (zB die Werte usw.), aber das dürfte kein großes Problem sein.