Referenzfälle und Abrechnungsdokumentation: Unterschied zwischen den Versionen

 
(11 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
=Warum gibt es die Referenzfälle und Abrechnungsdokumentation?=
<br />


===Ziele===
===Ziele===
#Qualitätssicherung gegen Regressionen
#Qualitätssicherung gegen Regressionen
#einheitliches Vorgehen bei Neuinbetriebnahmen und Systemerweiterungen
#einheitliches Vorgehen bei Neuinbetriebnahmen und Systemerweiterungen
#Verbesserung des Hotline-Prozesses bei Berechnungsanfragen
#Verbesserung des Hotline-Prozesses bei Berechnungsanfragen


=Referenzfälle=
===Referenzfälle===
 
Unter Referenzfall wird eine beispielhafte Dienstplan-Situation verstanden, deren Ergebnis festgehalten und als richtig erkannt ist.
Unter Referenzfall wird eine beispielhafte Dienstplan-Situation verstanden, deren Ergebnis festgehalten und als richtig erkannt ist.
Wir unterscheiden drei Arten von Referenzfällen:


*QA: Referenzfälle zur Qualitätssicherung, zum Testen von Neu-/Umprogrammierungen
Wir unterscheiden verschiedene Arten von Referenzfällen:
*Checkliste: Die Berechnungsdetails, welche in der Abrechnungscheckliste festgehalten wurden, werden in einfachen Fällen in allen Details dargestellt
*Snapshot: Export aus dem laufenden Betrieb, welcher für Regressionstests herangezogen wird.


{{AlexBild|Referenzfall - Ergebnis sofort sichtbar|[[Datei:Referenzfall.png|800px]]|grüne Felder in den Summen -> Ergebnis korrekt; rote Felder -> Ergebnis ist nicht korrekt}}
*Referenzfälle zum Testen von Neu-/Umprogrammierungen
===QA Workflow===
*Berechnungsdetails, welche in der Abrechnungscheckliste festgehalten wurden, werden in einfachen Fällen in allen Details dargestellt
Zur Qualitätssicherung von Neu-/Umprogrammierungen (zB. nach der Umsetzung von Angeboten) muss einerseits getestet werden, ob die gewünschten Änderungen richtig funktionieren und andererseits ob alles, was vorher funktioniert hat, nach wie vor funktioniert. Mehr [[QA Workflow|hier]]
*Komplette Echtsysteme, um die Abrechnungsergebnisse auch bei zukünftigen neuen Programmversionen oder Programmierungen im Kundenmodul zu garantieren


===Referenzfälle Checkliste===
{{AlexBild|'''Referenzfall - Ergebnis sofort sichtbar'''|[[Datei:Referenzfall.png|800px]]|grüne Felder in den Summen -> Ergebnis korrekt; rote Felder -> Ergebnis ist nicht korrekt}}
Bei Neuinbetriebnahmen gibt es immer ein Organisationsgespräch auf dessen Basis die [[Abrechnungscheckliste]] AUFBAU erstellt wird. Sobald es diese Checkliste gibt, muss es für die Berechnungsspezialitäten des Kunden Referenzfälle geben. Diese decken den gesamten Inhalt der Abrechnungscheckliste ab.
<br />


Im laufenden Betrieb kann es durch Angebote, Projekte oder umfassende manuelle Korrekturen zu einer Erweiterung der Abrechnungscheckliste kommen. In diesem Fall müssen sowohl die Abrechnungscheckliste Aufbau als auch die Referenzfälle erweitert werden.
====Qualitätssicherung bei Neuinbetriebnahme====
Bei Neuinbetriebnahmen gibt es immer ein Organisationsgespräch auf dessen Basis die [[Abrechnungscheckliste]] erstellt wird. Sobald es diese Checkliste gibt, werden für die Berechnungsspezialitäten des Kunden Referenzfälle angelegt. Diese decken den gesamten Inhalt der Abrechnungscheckliste ab.


Diese Referenzfälle Checkliste müssen folgendermaßen gespeichert werden:
Im laufenden Betrieb kann es durch Angebote, Projekte oder umfassende Korrekturen zu einer Erweiterung der Abrechnungscheckliste kommen. In diesem Fall werden sowohl die Abrechnungscheckliste als auch die Referenzfälle erweitert.


//DROPBOX/Office/Kunden-Schriftverkehr/Kundenordner/Referenzfälle/Checkliste/Aufbau_Kunde_Bereich.zip (bfx_config + db)
====Automatische Tests====
Die abgelegten Referenzfälle werden automatisch bei jeder neuen Programmversion getestet und jedes veränderte Berechnungsergebnis wird geprüft.


====Richtlinien für Checkliste====
===Abrechnungsdokumentation===
*Pro Abrechnungscheckliste gibt es einen eigenen Dienstplan
**Bezeichnung "Referenzfälle (Monat + Jahr)" (z.B. "Referenzfälle (Juli 13)")
*Es gibt ein eigenes Summenschema "Garantierte Summen"
** enthält alle Summen, welche für den Kunden relevant sind, und bei den Regressionstests kontrolliert werden
** DRZ-Bilanz + Summen für Lohnartenumschlüsselung + wichtige/relevante Summen für Referenzfälle
*Pro Überschrift in Checkliste gibt es eine Überschrift bei Referenzfälle
** farbliche Hinterlegung mittels Berufsgruppe
*Referenzfälle müssen analog zur Abrechnungscheckliste durchnummeriert sein
**für eventuelle Verweise in Checkliste
*Referenzwerte müssen gesetzt sein
*Referenzwerte müssen "grün" sein (siehe Bild weiter oben, ein rotes Feld = ein Wert wird noch falsch berechnet)


==Automatische Tests==
Unter einer Abrechnungsdokumentation verstehen wir die Dokumentation der Abrechnungsdetails beim Kunden nach einem normierten Muster. Wir nennen dieses Dokument "Abrechnungscheckliste".
Die im Kunden-Schriftverkehr abgelegten Referenzfälle werden automatisch getestet bei jedem Release, wenn folgendes beachtet wird:


* Datenbank muss "wired tiger" sein"
* Alle Modulpfade werden vom Programm gefunden: Rechte-Maus-Klick auf _.bfx_CONFIG_QA -> "QA:Module aktualisieren" -> es muss "OK" angezeigt werden
** eventuelle Fehler durch Anspruchsmodule --> siehe X:\Obsolete
* Rechte-Maus-Klick auf _.bfx_CONFIG_QA -> "QA: neu berechnen und vergleichen" -> es darf kein ERROR im _.recompute.log enthalten sein
* Ordner umbenennen in "#RefDB_Name_des_Referenzfalles" für Referenzfälle (Aufbau, spez. Angebote, etc) bzw. "#RegDB_Name_des_Kunden" (für ganze Datenbanken vom Kunden bei denen alle Summen gesetzt sind)
* Den gesamten Ordner zu einem '''.zip''' Archiv hinzufügen (Name muss dann #RefDB_Name_des_Referenzfalles.zip bzw. #RegDB_Name_des_Kunden.zip sein)
**nur QA Config-File liegen lassen - Es darf nur 1 Config in der zip-Datei liegen - Version im Dateinamen (zB: _.bfx_CONFIG_QA<span style="color:green">_2017</span>) ist erlaubt
** im Zip dürfen keine anderen Dateien liegen (keine recompute.log, keine Word-Dateien)
=== Referenzfälle mit Zeiterfassung ===
Bei Referenzfällen mit Zeiterfassung kann das Datum, mit welchem man in das Programm einsteigen möchte "eingefroren" werden, indem man das config-File um folgende Zeile erweitert:
  , "freeze" :
    { "time" : "TT.MM.JJJJ HH:MM"
    }
=Abrechnungsdokumentation=
Unter einer Abrechnungsdokumentation verstehen wir die Dokumentation der Abrechnungsdetails beim Kunden nach einem normierten Muster. Wir nennen dieses Dokument "Abrechnungscheckliste".
Es werden zwei Arten von Abrechnungschecklisten unterschieden:
Es werden zwei Arten von Abrechnungschecklisten unterschieden:
* Abrechnungscheckliste Aufbau
* Abrechnungscheckliste Work in Progress (WIP)


===Abrechnungscheckliste Aufbau===
*Abrechnungscheckliste Aufbau
Die gesamten Abrechnungsmodalitäten des Kunden werden basierend auf einem Organisationsgespräch in diese Checkliste eingetragen. Diese Checkliste bildet die Grundlage der Abrechnungseinstellungen/Programmierungen.
*Abrechnungscheckliste Work in Progress (WIP)
Diese Checkliste muss folgendermaßen gespeichert werden:


//DROPBOX/Office/Kunden-Schriftverkehr/Kundenordner/Abrechnungscheckliste_Aufbau_Kunde.doc
====Abrechnungscheckliste Aufbau====
Die gesamten Abrechnungsmodalitäten des Kunden werden basierend auf einem Organisationsgespräch in diese Checkliste eingetragen. Diese Checkliste bildet die Grundlage der Abrechnungseinstellungen/Programmierungen.  


Falls beim Kunden einzelne Bereiche/Berufsgruppen o.ä. nicht gleichzeitig mit dem restlichen System in Betrieb genommen werden, wird für jeden Bereich eine eigene Abrechnungscheckliste Aufbau erstellt.
Falls beim Kunden einzelne Bereiche/Berufsgruppen o.ä. nicht gleichzeitig mit dem restlichen System in Betrieb genommen werden, wird für jeden neuen Bereich eine eigene Abrechnungscheckliste erstellt.


//DROPBOX/Office/Kunden-Schriftverkehr/Kundenordner/Bereich1/Abrechnungscheckliste_Aufbau_Bereich1_Kunde.doc
====Work in Progress (WIP)====
Bei manchen bestehenden Kunden gibt es teilweise keine Abrechnungsdokumentationen. Das Wissen über diverse Abrechnungsmodalitäten beim Kunden wird durch den laufenden Wartungsbetrieb bzw. durch Projekte erworben und soll laufend dokumentiert werden.


Abrechnungscheckliste Aufbau am Beispiel Wien Herz-Jesu:
[[Datei:Ordnerstruktur1.png|800px]]
===Work in Progress (WIP)===
Bei bestehenden Kunden gibt es selten Abrechnungsdokumentationen. Das Wissen über diverse Abrechnungsmodalitäten beim Kunden wird durch den laufenden Wartungsbetrieb bzw. durch Projekte erworben und soll laufend dokumentiert werden.
Diese Dokumentation erfolgt in der Abrechnungscheckliste Work in progress. Diese ist zu Beginn der Aufzeichnungen leer und wird durch die Informationen aus dem laufenden Kundenkontakt befüllt. ("Das was ich gerade weiß")
Diese Dokumentation erfolgt in der Abrechnungscheckliste Work in progress. Diese ist zu Beginn der Aufzeichnungen leer und wird durch die Informationen aus dem laufenden Kundenkontakt befüllt. ("Das was ich gerade weiß")


Diese Checkliste muss folgendermaßen gespeichert werden:
:
//DROPBOX/Office/Kunden-Schriftverkehr/Kundenordner/Abrechnungscheckliste_WIP_Kunde.doc
 
Abrechnungscheckliste WIP am Beispiel Wien BHS:
 
:[[Datei:Ordnerstruktur2.png|800px]]
 
=== Vorlage ===
Für die Abrechnungschecklisten gibt es eine Vorlage. Diese ist im Ordner "Kunden-Schriftverkehr" zu finden:


:[[Datei:Abrechnungscheckliste_Vorlage.PNG|900px]]
====Änderungsrichtlinien====


=== Änderungsrichtlinien ===
Werden Änderungen in den Dokumenten vorgenommen, sind diese jeweils mit Name und Datum der Person zu versehen, welche die Änderungen vorgenommen hat. Dieses Vorgehen ermöglicht es auch im Nachhinein nachzuvollziehen, wann und von wem Änderungen durchgeführt wurden, um bei Fragen einen direkten Ansprechpartner zu haben.


Werden Änderungen in den Dokumenten vorgenommen (insbesondere in der WIP Abrechnungscheckliste), sind diese jeweils mit Name und Datum der Person zu versehen, welche die Änderungen vorgenommen hat. Dieses Vorgehen ermöglicht es auch im Nachhinein nachzuvollziehen, wann und von wem Änderungen durchgeführt wurden, um bei Fragen einen direkten Ansprechpartner zu haben.
Die Änderungen müssen folgendermaßen gekennzeichnet werden:
Die Änderungen müssen folgendermaßen gekennzeichnet werden:


:[[Datei:Aenderungen.png|500px]]
:[[Datei:Aenderungen.png|500px]]




Wurde die Checkliste geändert, muss sie im Anschluss dem Kunden zur Kontrolle zugesendet werden. Somit wird sichergestellt, dass sowohl Bitfactory als auch der Kunde auf dem neusten Stand der Abrechnungsdokumentation sind.
Wurde die Checkliste geändert, muss sie im Anschluss dem Kunden zur Kontrolle zugesendet werden. Somit wird sichergestellt, dass sowohl Bit Factory als auch der Kunde auf dem neuesten Stand der Abrechnungsdokumentation sind.
 
=Prozess für Berechnungsanfragen via Hotline=
 
{{AlexBildDunkel|'''Prozess bei internen Hotlineanfragen'''|[[Datei:Prozess_Referenzfaelle.jpg]]|}}
 


[[Kategorie:Referenzfälle]]
===Bit Factory interne Zusatzinfos===
[[Intern:QA Workflow|Link zur Checkliste für Referenzfälle]]

Aktuelle Version vom 29. Juli 2021, 07:19 Uhr


Ziele

  1. Qualitätssicherung gegen Regressionen
  2. einheitliches Vorgehen bei Neuinbetriebnahmen und Systemerweiterungen
  3. Verbesserung des Hotline-Prozesses bei Berechnungsanfragen

Referenzfälle

Unter Referenzfall wird eine beispielhafte Dienstplan-Situation verstanden, deren Ergebnis festgehalten und als richtig erkannt ist.

Wir unterscheiden verschiedene Arten von Referenzfällen:

  • Referenzfälle zum Testen von Neu-/Umprogrammierungen
  • Berechnungsdetails, welche in der Abrechnungscheckliste festgehalten wurden, werden in einfachen Fällen in allen Details dargestellt
  • Komplette Echtsysteme, um die Abrechnungsergebnisse auch bei zukünftigen neuen Programmversionen oder Programmierungen im Kundenmodul zu garantieren
Referenzfall - Ergebnis sofort sichtbar
Referenzfall.png
grüne Felder in den Summen -> Ergebnis korrekt; rote Felder -> Ergebnis ist nicht korrekt


Qualitätssicherung bei Neuinbetriebnahme

Bei Neuinbetriebnahmen gibt es immer ein Organisationsgespräch auf dessen Basis die Abrechnungscheckliste erstellt wird. Sobald es diese Checkliste gibt, werden für die Berechnungsspezialitäten des Kunden Referenzfälle angelegt. Diese decken den gesamten Inhalt der Abrechnungscheckliste ab.

Im laufenden Betrieb kann es durch Angebote, Projekte oder umfassende Korrekturen zu einer Erweiterung der Abrechnungscheckliste kommen. In diesem Fall werden sowohl die Abrechnungscheckliste als auch die Referenzfälle erweitert.

Automatische Tests

Die abgelegten Referenzfälle werden automatisch bei jeder neuen Programmversion getestet und jedes veränderte Berechnungsergebnis wird geprüft.

Abrechnungsdokumentation

Unter einer Abrechnungsdokumentation verstehen wir die Dokumentation der Abrechnungsdetails beim Kunden nach einem normierten Muster. Wir nennen dieses Dokument "Abrechnungscheckliste".

Es werden zwei Arten von Abrechnungschecklisten unterschieden:

  • Abrechnungscheckliste Aufbau
  • Abrechnungscheckliste Work in Progress (WIP)

Abrechnungscheckliste Aufbau

Die gesamten Abrechnungsmodalitäten des Kunden werden basierend auf einem Organisationsgespräch in diese Checkliste eingetragen. Diese Checkliste bildet die Grundlage der Abrechnungseinstellungen/Programmierungen.

Falls beim Kunden einzelne Bereiche/Berufsgruppen o.ä. nicht gleichzeitig mit dem restlichen System in Betrieb genommen werden, wird für jeden neuen Bereich eine eigene Abrechnungscheckliste erstellt.

Work in Progress (WIP)

Bei manchen bestehenden Kunden gibt es teilweise keine Abrechnungsdokumentationen. Das Wissen über diverse Abrechnungsmodalitäten beim Kunden wird durch den laufenden Wartungsbetrieb bzw. durch Projekte erworben und soll laufend dokumentiert werden.

Diese Dokumentation erfolgt in der Abrechnungscheckliste Work in progress. Diese ist zu Beginn der Aufzeichnungen leer und wird durch die Informationen aus dem laufenden Kundenkontakt befüllt. ("Das was ich gerade weiß")

Änderungsrichtlinien

Werden Änderungen in den Dokumenten vorgenommen, sind diese jeweils mit Name und Datum der Person zu versehen, welche die Änderungen vorgenommen hat. Dieses Vorgehen ermöglicht es auch im Nachhinein nachzuvollziehen, wann und von wem Änderungen durchgeführt wurden, um bei Fragen einen direkten Ansprechpartner zu haben.

Die Änderungen müssen folgendermaßen gekennzeichnet werden:

Aenderungen.png


Wurde die Checkliste geändert, muss sie im Anschluss dem Kunden zur Kontrolle zugesendet werden. Somit wird sichergestellt, dass sowohl Bit Factory als auch der Kunde auf dem neuesten Stand der Abrechnungsdokumentation sind.

Bit Factory interne Zusatzinfos

Link zur Checkliste für Referenzfälle