Eigenentwicklung dokumentieren

Hallo,
wie geht ihr mit diesen Thema um. Sprich man passt in NAV an bzw. entwickelt ganze Prozess neu.
Wie dokumentiert ihr das für euch bzw. für die Benutzer und welche Werkzeuge verwendet ihr dafür.

Z.B. eine Erklärung der Felder auf eine Page und wie der ganze Prozess funktioniert.

Danke und lg
stony

Kommt drauf an. Je nach Bedarf oder Anforderung des jeweiligen Kunden. Manchmal Handbuch in Word, das aber i. d. R. dann vom Kunden geschrieben wird. Die NAV Hilfe haben wir noch nie angepasst, die wird von den Kunden / Anwendern erfahrungsgemäß ohnehin nie verwendet.

Ich kann da aus eigener Erfahrung den "Object Manager Advanced" von IDYN.nl uneingeschränkt empfehlen.

Die Anforderungen nehmen wir in OTRS auf, und die OTRS-Ticket-ID verwenden wir dann als OMA-Projektnr., welche dann auch in den Objekten und dem C/AL-Code zur Dokumentation verwendet wird.
Da man zu einem Ticket eventuell ein paar Tage später nochmal eine Nachbesserung programmiert, enthält die OMA-Projektnr. noch eine fortlaufende Nummer.
In dem OMA-Projekt wird auch immer die URL zu dem OTRS-Ticket hinterlegt, so dass auch noch Jahre später nachvollzogen werden kann, wer wann was warum gefordert hat, und wie es dann umgesetzt wurde.

Da wir gerade dabei sind, unsere 7 Jahre alte, hochgradig angepasste NAV5.0-Lösung auf NAV2017 zu bringen, erfahren wir, wie sinnvoll diese Entscheidung vor 8 Jahren war, da selbst heute noch die ältesten Anpassungen im Detail nachvollziehbar sind.
Ebenso können wir über die OMA-Projekte (bzw. notfalls über die OMA-Funktion "Search String in C/AL Code") wirklich alle Stellen ausfindig machen, welche für diese Anforderung mal angepasst wurden, selbst wenn Teile davon heute auskommentiert sind.

Das OTRS-Ticketsystem war nicht von Anfang an im Einsatz, aber anhand der OMA-Projektnr. können wir erkennen, ob die Anforderung in OTRS, SharePoint oder in Word geschriebenen Spezifikationen definiert ist.
Beispiel:
#CR123-01: Initiale Anpassung (-01) aus dem Word-Dokument CR123 (ChangeRequest) auf dem Dateiserver
#SP456-02: Zweite Anpassung (-02) zu dem SharePoint-Listeneintrag mit der eindeutigen Nummer 456
#2012060310000789-01: Erste Anpassung (-01) zum OTRS-Ticket 2012060310000789.

Fazit:
Man sollte ein zentrales "Anforderungs-Verwaltungs-System" verwenden, welches auch in 10 Jahren noch existiert, damit man die Hintergründe zu der Anforderung nachschlagen kann. (Bei uns: OTRS)
Man sollte ein einfach zu bedienendes, vollumfängliches Quellcode-Verwaltungs-System verwenden, bei dem man quasi nicht vergessen kann, eine Änderung zu protokollieren. (Bei uns: OMA)

Ich hatte die Frage so verstanden dass es um Anwender Doku geht. Die Dokumentation der Programm-Code-Änderungen machen wir auch über ein Ticketsystem und entsprechende Verweise in der Doku der Objekte. Aber mehr manuell und nicht so automatisiert verlinkt wie Timo.

Ach so.
Typischer Programmierer-Fehler, wir denken einfach zu technisch.

Für die Anwender erstellen wir (jedoch nicht die Programmierer) die Dokumentation in Word und legen diese dann als PDF auf einem zentralen (für Anwender schreibgeschützten) Verzeichnis ab.
Zukünftig werden die Prozessabläufe zusätzlich noch in einer Prozess-Modellierungs-Software abgebildet.
Und wenn alles so läuft, wie wir es uns wünschen, dann können die PDF-Dateien mit der Anwender-Doku direkt aus der Prozess-Modellierungs-Software aufgerufen werden.
Der Anwender klickt sich bis zu dem gewünschten Prozess durch und ruft von dort die Anwender-Doku auf.

Das klingt im ersten Moment nach sehr viel Arbeit. Ist es auch.
Es zahlt sich aber im Geschäftsalltag aus, da die Anwender wissen, wo sie die Dokumentation zu dem entsprechenden Geschäftsprozess finden.
Dies entlastet den Support und reduziert die "Ausfallzeit" der Anwender, da sie schneller die Antwort auf ihre Frage finden.
Und spätestens beim nächsten größeren Upgrade holt man die Kosten und die Zeit ganz schnell wieder heraus, da man ja alle individuellen Prozesse an zentraler Stelle sauber beschrieben hat.
Die Anzahl und Dauer der erforderlichen Workshops reduziert sich dann erheblich, da man nur noch bewerten muss, ob dieser Prozess so noch benötigt wird, technisch anders abgebildet werden kann/muss oder durch neue Features im NAV-Standard abgebildet werden kann.

Hallo zusammen,

Als Partner bzw. Entwickler in eigener Sache habe ich es möglichst auf 4 Dinge geachtet:
1) Dokumentation im Code: Anfangsmarke / Eigener Code / Endemarke
2) Objekte: In allen angepassten Objekten eine kleine Änderungsdoku im Kopf inkl. Versions-Nr.
3) Anwender-Doku: Word- bzw. pdf-Dokument mit dem was der Anwender über den Prozess wissen muss, evtl. mit Screen-Shots
4) technische Doku: Interne Beschreibung der Eigenentwicklung mit allen angepassten Tabellen, Abhängigkeiten und Prozess-Abläufen.

Das ist zwar viel Arbeit, aber wie schon gesagt, es lohnt sich !

Grüße
ATLAN

Hallo zusammen,

gibt es im Bezug auf die Dokumentation im Quellcode von Microsoft Vorgaben, wie man dies Strukturieren sollte?

gibt es im Bezug auf die Dokumentation im Quellcode von Microsoft Vorgaben, wie man dies Strukturieren sollte?

Microsoft gibt intern nur vor, wie neuer Code auszusehen hat:
https://blogs.msdn.microsoft.com/nav/20 ... openhagen/
https://msdn.microsoft.com/en-us/dynami ... ing-format
ABER Microsoft selbst dokumentiert die Änderungen nicht, weder im Code noch im Documentation Trigger. Und Microsoft macht an uns deshalb auch keine Vorgaben.

Vielen Dank