Das Notes Forum
Domino 9 und frühere Versionen => Entwicklung => Thema gestartet von: emadowo am 07.02.06 - 15:04:33
-
Hallo miteinander!
Ich muß alle eigenprogrammierten Datenbanken dokumentieren. Hat einer von euch einen Ansatz, wie so etwas aussieht? Selbstverständlich habe ich dieses Forum schon durchforstet, aber nichts geeignetes gefunden.
Es würde mir schon reichen, wo ich dazu Informationen finde.
Im Internet ist immer nur von Programmierungen von Software oder von Datenbanken im allgemeinen was zu finden, von "Notes-Datenbanken" nicht speziell. Notes-DBs sind aber m.E. keine "Standard-Software" und auch keine "Datenbank" im Sinne von BSI, Ordnungsmäßigkeitsfragen und wie das Zeugs alles heißt.
Wer weiß Rat? Danke!!!
-
Hallo,
nutz doch die Gestaltungsübersicht (Synopsis).
Es gibt natürlich auch professionelle Tools (z. B. Teamstudio).
mfg
R. Zaske
-
Hi,
Mir stellt sich zuerst die Frage, "Was verstehst Du unter dokumentieren?"
Andreas
-
Die Anforderung sollte wirklich genauer beschrieben werden - Dokumentation ist auf jeden Fall ein sehr dehnbarer Begriff.
Auf jeden Fall ist weder die Synopse noch eine Teamstudio Analyzer DB in irgendeiner Form eine Dokumentation, sondern eine andere Aufbereitung des Codes. Sehr, sehr hilfreich, wenn man sowas braucht, aber ebenso leicht und automatisch in genau dem Moment generiert, wenn man sie tatsächlich braucht.
Bernhard
-
Danke für die Tipps!
Die Gestaltungsübersicht habe ich dank dieses Forums :-> "entdeckt" und die ist auch sehr gut. Darin steht aber ja nichts
- wer die DB programmiert hat
- warum es diese DB gibt
- welchen Zweck die DB im Arbeitsablauf erfüllen soll
- warum Gruppe xy das Recht/die Rolle zx haben darf
usw.
Und genau das meine ich: mir würde es reichen, wenn ich
a) die Gestaltungsübersicht und
b) im "Über diese Datenbank" die Versionsführung darstelle und
c) im "Benutzen dieser Datenbank" das "Handbuch" einstelle
alles ausdrucke und in einen Ordner lege. Das wäre meine Doku.
Aber: reicht dies gesetzlichen Anforderungen aus? Ist ein Prüfer einer Prüfungsgesellschaft zufrieden damit? Da gibt es so Begriffe wie "Programmierrichtlinien", "Software-Abnahme und Freigabeverfahren".
Dazu suche ich Hilfe.
-
Ist ein Prüfer einer Prüfungsgesellschaft zufrieden damit?
Das hängt vom Prüfer/Branche/etc. ab...
Dinge wie "Programmierrichtlinien", "Software-Abnahme und Freigabeverfahren" sollten im Unternehmen geklärt sein. Große Unternehmen haben dafür eine Betriebsorganisation und Arbeitsanweisungen (die wiederum in solchen Fällen von der IT-Abteilung erstellt werden).
Kann ein umfassendes Thema mit ein/zwei weiteren Notesdatenbanken werden, z.B.
-Arbeitsanweisungen
-Softwareaufträge (Abschnitte für die Prüfung durch Innenrevision/Betriebsrat/Datenschützer/Auftraggeber nicht vergessen)
-Testprotokolle
-Abnahme/Freigabe
-Dokumentation (bei uns ein sehr umfangreiches Formular :P ...)
-Benutzerführung/Handbuch
-
Wie Bernhard richtig sagte, ist Dokumentation ein sehr weiter Begriff.
Im Notes-Bereich kann unterschieden werden in:
- Anwender-dokumentation
- Administrator-Dokumentation
- Entwickler-Dokumentation. Und nein. Mit Synopsis oder Teamstudio erzeugte Snapshots sind keine Entwickler-Dokumentation. Das brauchst du eigentlich überhaupt nicht zu erstellen, weil das jeder dann aus der Datenbank erstellen kann, wenn er es braucht.
Für die EndanwenderdokumentatioN:
- einführendes Kapitel über die groben Ziele der Datenbank.
- Dann Hilfe Beschreibung anhand von Anwendungsfällen oder User-Stories.
Auf jeden Fall sortiert nach Rollen in der Datenbank.
Beispiel: Du denkst über die Dokumentation für die ISP-Portal-Version einer Reisekostenabrechnungsanwendung nach->
Eine zusammengehörige Aufgabe aus Sicht eines Endanwenders ist das Erstellen und Einreichen eines Reisekostenabrechnungsdokument. Dafür muss er gegebenenfalls mehrere Masken ausfüllen. Er kann zwischenspeichern und irgendwann auf "Einreichen". Dies sollte am besten alles als ein Unterkapitel beschrieben werden. Aus Sicht des Anwenders zusammengehörige Funktionalitäten zusammenfassen!
Versetze dich ernsthaft in die Lage eines Endanwenders. Denke nicht gönnerhaft "ach, der Dau" über ihn. Der Endanwender ist der Grund, warum du Geld bekommst.
Benutze Screenshots. Heute kann man auch ganz gut Flash-Filmchen erstellen.
Meist gibt es eine gesonderte Admin-Doku, in der gesonderte administrative Aufgaben wie Rechtevergabe, Monitoring, Trouble Shooting, Konfiguration in der DB beschrieben werden (ACL setzen, Konfigurationsdokumente, LOG-Datenbanken, was bei Migration auf anderen Server zu beachten-> wenn überhaupt).
Entwickler-Dokus sind selten.
-
Aber: reicht dies gesetzlichen Anforderungen aus? Ist ein Prüfer einer Prüfungsgesellschaft zufrieden damit? Da gibt es so Begriffe wie "Programmierrichtlinien", "Software-Abnahme und Freigabeverfahren".
Dazu suche ich Hilfe.
Dies ist alles sehr schwammig. Auch inhouse Richtlinien werden oft unterlaufen, da sie einfach nicht an die oft sehr komplexe Realität angepasst sind.
Ich hab schon Software-Abnahme und Freigabeverfahren erlebt, die sich schön auf dem Papier anhörten, in der Realität aber nur genau ein Gesetz beinhalteten:
Eine Menge Manager können Zeiten für nichtgeleistete Arbeit buchen und wenn was schief läuft, ist der externe Entwickler schuld.
Freigabe und Abnahme ist ein anderes Thema als Dokumentation. Es gibt heutzutage wirklich höchstspannende, praxisnahe und lesenswerte Literatur zum Thema Akzeptanztests, funktionale Tests, Integrationstests, Dokumentation, etc.
Du kannst es aber fürs erste mit gesunden Menschenverstand versuchen:
- Software muß getestet werden
- Software muß beschrieben werden. Und zwar nach Rollen gegliedert. Kein Endanwender interessiert sich für Admin-Doku und umgekehrt. Versuch dich in die Lage der einzelnen Leute zu versetzen. Versuch es so zu beschreiben, wie die Person die Datenbank wahrnimmt. Die sehen nicht einzelne Felder oder Buttons. Die sehen zusammengehörige Prozesse.
Axel
Gruß Axel
-
zum Thema Endanwender-Doku :
Wir (d.h. die IT) schreiben schon seit Jahren keine Endanwender-Doku mehr. Bei Anwendungen, die eine solche Doku benötigen, wird die Fachabteilung mit eingebunden und ist für eine solche Doku zuständig. Natürlich leisten wir Hilfestellung, aber dann eben eher technisch als inhaltlich.
Und für uns hat sich das bewährt. Es ist IMO recht schwer, sich als ITler in die Arbeitswelt eines Anwenders hineinzuversetzen. Vor allem wenn die Arbeitswelt von Abteilung Abteilung komplett unterschiedlich ist.
Ich sehe das natürlich jetzt durch die Brille der internen IT-Abteilung. Für einen externen Dienstleister zieht das in den meisten Fällen ja nicht.
Soll nur als Anregung dienen.
-
Hallo miteinander!
Bin überwältigt von der Anzahl "Gelesen" und den Antworten. Vielen Dank dafür, ich konnte schon Anregungen mitnehmen! :)
Gruß
Earchy