Domino 9 und frühere Versionen > Entwicklung

Dokumentation Eigenprogrammierte Datenbanken

<< < (2/2)

sloe:
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

flaite:
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.

flaite:

--- Zitat von: earchy am 07.02.06 - 16:14:35 ---
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.

--- Ende Zitat ---
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

Driri:
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.

emadowo:
Hallo miteinander!

Bin überwältigt von der Anzahl "Gelesen" und den Antworten. Vielen Dank dafür, ich konnte schon Anregungen mitnehmen! :)

Gruß
Earchy

Navigation

[0] Themen-Index

[*] Vorherige Sete