Ladies & Gentlemen - Ganz gleich, wie beschwerlich das Gestern war, stets kannst du im Heute von Neuem beginnen. (Buddhistische Weisheit). Die Buddhisten sind soweit ich weiss nicht zwangsläufig anerkannte Experten im Dokumentieren von Software, aber recht haben sie trotzdem. Nachdem nun einige Doku-seiten erstellt wurden, haben Andrea, Christoph und ich angefangen die CRs 3.01 in die Doku einzupflegen. Dabei gab's weitere Erkenntnisse: 1. Im Bereich "Benutzeroberfläche" sollten keine Prozesse implizit dokumentiert werden. Pro Feld sollte beschrieben werden was da drin steht, aber nicht woher die Daten kommen und wo sie wie weiter verwendet werden. Als Stütze kann folgende Regel gelten: falls ein CR denkbar ist welcher das UI in Umbrella.net nicht ändert, aber eine Änderung in der Doku "Benutzeroberfläche" bedingt, dann wurde da vermutlich zuviel rein-dokumentiert. Gutes Beispiel: IATA-Bereich / Hier wird der IATA-Bereich ausgewählt. Es stehen die IATA-Bereiche Domestic, Europa, Interkontinental und '-' (kein IATA-Bereich) zur Verfügung Weniger gutes Beispiel: IATA-Bereich / Es stehen die IATA-Bereiche Domestic, Europa, Interkontinental und '-' (kein IATA-Bereich) zur Verfügung. Beim Anwenden der TAF-Modelle wird für Flugtickets zuerst die IATA-Area des Tickets gegen diesen Bereich verglichen. Falls kein Treffer gefunden wird sucht die Logik nach einem passenden Detail mit IATA-Area = '-'. Wird auch da nichts gefunden wird keine TAF-Position erstellt. Anderfalls wird eine TAF-Position mit dem Betrag der Gebühr + ggf. Segmente erstellt und direkt unter der Flugposition eingefügt. Auf der Commercial Lasche wird die TAF-Position mit dem Flug verlinkt. 2. Unter den "Arbeitsprozessen" sollten keine Geschäftsprozesse dokumentiert werden. Letzter umfassen oft mehrere Schritte in verschiedenen Bereiche und sprengen damit den Scope der UI-bezogenen "Arbeitsprozesse". Als Stütze kann folgende Regel gelten: pro Button auf dem UI gibt's ein Arbeitsprozess. Die Prozesse "Speichern" und "Abbrechen" kann man sich ggf. sparen. Gutes Beispiel: Doceditor - Rechnung speichern ... in diesem Prozess werden alle geänderten Rechnungsdaten gespeichert. Folgende Validierungen werden ausgeführt ... Folgende Datenänderungen passieren ggf. automatisch im Hintergrund ... Weniger gutes Beispiel: Manuelle Flugposition erfassen und mit Gebühr verknüpfen ... in Doceditor Neue Position auswählen, Flug auswählen, Rechnung speichern, auf Commercial Lasche wechseln, dort Gebühr verknüpfen, ... 3. Es wird in der Doku wohl eine Gruppe von Doku-Seiten brauchen welche nicht an einem bestimmten UI hängen. Kandidaten sind die nächtlichen Batch-Prozesse (BTA/TAMARA Export, CRM, EFTPOS-Balancing, ..). Ggf. macht es auch Sinn eine Gruppe von typischen Geschäftsprozesse exemplarisch zu dokumentieren. Ganz allgemein kann man sagen: wenn wegen den beiden Punkten oben relevante Information nicht in die Doku einer bestimmten UI-Seite reinpasst, dann braucht's eine separate Doku-Page, die nicht UI-bezogen ist. Ggf. macht es Sinn bei den nächsten 2-3 Doku-Pages die relevanten Bereich vorher kurz mit mir oder Christoph zu besprechen, dann können wir in Zukunft den Bedarf an Überarbeitung gering halten. Gruss Simon -- ____________________________________ WaNT GmbH Herr Simon Niederberger Aberenrain 30 6340 Baar T: 0417 401 437 E: mailto:simon.niederberger@want.ch W: http://www.want.ch