Der Ablauf, vom Erstellen des Differenzprotokolls bis zur Ermittlung des Protokollstatus, besteht aus 4 selbständigen Schritten, die zwischendurch erweitert und beeinflusst werden können mit eigenen Stylesheets, Prozeduren oder Programmen. Durch deren Einfluss und den Einsatz von Teilbewertungen kann die Bewertung intelligenter und spezifischer gemacht werden.
Auf dieser Seite werden Möglichkeiten und Beispiele gegeben, wie man die Bewertung auf Basis der Tabellen zusätzlich mit eigenen Mitteln intelligenter machen und somit das Ergebnis der Bewertung beeinflussen kann.
Abhängig vom Benutzerkreis und seinen Rollen, kann ein Bewertungsschritt eine andere Zielsetzung haben und damit spielen dann auch Differenzen eine unterschiedliche Rolle. In den Beispielen wird unter Berücksichtigung des Benutzerkreises versucht, verschiedene Abläufe zu definieren.
Die Bewertungsschritte können eingeschränkt werden, indem die Bewertungen nur für bestimmte DiffNamen und/oder Kategorien durchgeführt werden.
Ziel: Ermitteln, ob bestimmten Arten von Differenzen akzeptiert werden und einen Protokollstatus OK liefern.
Beispiel: Wenn die komplette Bewertung einen Protokollstatus „NotOK“ liefert, könnte eine erneute Durchführung des PS-Schrittes nur für die Kategorie „Definition“ eine Aussage liefern, ob diese Differenzen in Ordnung waren und einen Protokollstatus „OK“ liefern.
n diesem Absatz werden die verschiedenen Anpassungsmöglichkeiten vorgestellt. Zu jeder Möglichkeit wird ein Ziel und Beispiel mit einer Anpassung aufgezeigt.
Wenn einige oder alle drei EDB-Tabellen nicht in der TAA.MDB liegen, sondern in Rochade oder Flatfiles, ist es möglich, den Inhalt der Tabellen und somit die Kategorien, Gewichtungen und Stati spezifischer zu definieren. Der TstDiff meldet sich mit seinem Kontext an Rochade an, und damit ist es möglich Tabellen abzulegen, die je Projekt, je Stufe, je Auftrag und ggf. je Benutzer unterschiedlichen Inhalt haben. Die Rochadeprozedur die den Tabelleninhalt zurückliefert, könnte auf Basis dieser Daten entscheiden, welchen Inhalt die Tabelle hat. Denkbar wäre die Ablage unternehmensweiter Einträge und projektspezifischer Einträge. Die Rochadeprozedur fügt diese dann zu einer Tabelle zusammen.
Ziel: Durch kontextabhängige Tabellen erreicht man projektspezifische Bewertungen, oder Bewertungen zugeschnitten auf Benutzergruppen.
Beispiel: In Rochade sind die Einträge für DCAW allgemein definiert, die mit Änderungen der Definition und Oopse zu tun haben (DiffNamen: BsarType, OopsCount, ParmObjt, ParmClass, ParmDstr etc.). Je Projekt sind Einträge definiert, die mit Änderungen an Objektinhalten und Conditions zu tun haben ((DiffNamen: ParmItemCount, ParmField, CndTitle, CndArg etc.). Die allgemeinen Einträge für die Tabellen DDST und DPST beinhalten nur die einfachen Regeln und je Projekt gibt es hierfür spezifische Einträge, wo DiffName, Kategorie, Gewichtung und/oder Status definiert sind.
Bei allen drei Bewertungsschritten spielen die „DiffNamen“ insofern eine entscheidende Rolle, dass Differenzen die keinen „DiffName“ haben nicht bewertet werden. Durch das Wegnehmen oder Ändern des „DiffName“ kann gesteuert werden, ob und welche Einträge in den Tabellen für diese Differenz gelten. Man könnte z.B. ein Stylesheet oder ein Programm entwickeln, das auf Basis von eigenen Regeln den „DiffName“ ändert oder wegnimmt und damit nur einen Teil des Protokolls bewerten.
Ziel: Durch das Anpassen der DiffNamen erreicht man eine Filterung der Differenzen. Das kann zum Beispiel eine projektspezifische Filterung oder eine Filterung für Benutzergruppen sein.
Beispiel: Die Änderung an einem Modul soll auf zwei unterschiedliche Arten abgenommen werden. Beide sollten auf andere Differenzen achten. Das Programm könnte die XML-Datei nehmen und hieraus zwei XML-Dateien machen und für die Differenzen andere oder keine DiffNamen vergeben und somit zwei auf die jeweils wesentlichen Differenzen eingeschränkte Protokolle produzieren und bewerten lassen. Am Ende könnten diese Bewertungen wieder im Originalprotokoll zurück integriert werden, vorausgesetzt, sie überlappen sich nicht.
Die Zuordnung der Kategorien kann benutzt werden, um fachliche Sichten auf Datenobjekte zu spezifizieren. Wenn Änderungen an Felder zusammenhängen, könnte man diese Felder einer eigenen Kategorie zuordnen. Zu beachten ist allerdings, dass ein erneutes Ausführen des CW-Schrittes die Kategorie ändert, wenn ein Eintrag für den „DiffName“ gefunden wird. Ziel: Durch das Anpassen der Kategorien erreicht man eine Gruppierung von Differenzen, die zusammen betrachtet werden müssen. Hiermit kann man Differenzen Gruppieren nach z.B. technischen und fachlichen Differenzen. Die technischen Differenzen interessieren Konfigadministratoren und Anwendungsentwickler. Fachliche Differenzen interessieren die Anwendungsentwickler und deren Anwender bzw. Fachbereich. Beispiel: Die Parameterobjekte SNLBND, SNLVEV, SNLVEL und SNLRIS beinhalten die Verträge und die dazu gehörenden Risiken. Durch das Zuordnen der Felder dieser Parameter zur Kategorie „Vertrag“ wird die Möglichkeit geschaffen, Sichten und Bewertungen zu Vertragsänderungen zu formulieren auf Basis der Kategorie.
Die Differenzen werden durch die Bewertungsschritte einzeln betrachtet. Das Verfahren erlangt eine höhere Aussagekraft bzw. Qualität und wird intelligenter gemacht, wenn ein Programm die Gewichtungen zuordnet auf Basis von Zusammenhängen. Zu beachten ist allerdings, dass ein erneutes Ausführen des CW-Schrittes die Gewichtung ändert wenn ein Eintrag gefunden wird.
Ziel: Durch das Anpassen der Gewichtungen beeinflusst man den Differenzstatus, indem die Differenzen als leicht oder schwerwiegend eingestuft werden.
Beispiel: Wenn im Parameterobjekt SNLVEV ein Satz hinzugefügt wird, sollte in SNLVEL auch ein zusätzlicher Satz vorhanden sein. Falls das nicht gegeben ist, könnte bei beiden Parametern die Gewichtung „Severe“ an die Differenz „ParmItemCount“ zugeordnet werden; ansonsten z.B. die Gewichtung „Info“, weil es sich um ein Modul handelt, das Verträge hinzufügt.
Ob eine Differenz erlaubt ist wird durch den Status ausgedrückt. Differenzen die erwartet werden, wie z.B. ein Timestamp, werden akzeptiert. Entsprechend werden Differenzen die nicht erwartet werden als fehlerhaft gekennzeichnet, da sie nicht akzeptiert werden. Zu beachten ist allerdings, dass ein erneutes Ausführen des DS-Schrittes den Status ändert ,wenn ein Eintrag gefunden wird.
Ziel: Durch das Anpassen des Differenzstatus beeinflusst man den Protokollstatus, indem die korrekten oder erwarteten Differenzen akzeptiert werden und die fehlerhaften oder unerwarteten Differenzen nicht akzeptiert werden.
Beispiel: Nachdem der Schritt zum Erstellen des Differenzstatus ausgeführt ist, wäre z.B. ein Eingriff denkbar, der den ermittelten Status überprüft und ändert, um einen Protokollstatus „OK“ zu erreichen. Eine mögliche Anwendung wäre der manuelle Eingriff des Sachbearbeiters, der die Differenzen prüfen soll, nachdem der erste Bewertungsdurchlauf ein Protokollstatus „NotOK“ geliefert hat.
Nachdem die maschinelle Bewertung einen Protokollstatus ermittelt hat, sollte bei einem NotOK die weitere Bewertung manuell durchgeführt werden. Zu beachten ist allerdings, dass ein erneutes Ausführen des PS-Schrittes den Protokollstatus wieder ändert.
Ziel: Verwalten von Differenzprotokollen und archivieren von Protokollen die in Ordnung sind.
Beispiel: Bei einer Übergabe werden 5 Differenzprotokolle erstellt. Drei davon haben die Bewertung OK und zwei haben die Bewertung NotOK. Die mit Bewertung OK können anschließend ins Archiv verschoben werden. Die mit Bewertung NotOK erfordern Bearbeitung. Man könnte diese Protokolle solange liegen lassen, bis sie mit OK bewertet sind und dann ins Archiv verschieben.
Zwischen den einzelnen Schritten gibt es verschiedene Einflussmöglichkeiten. Hier werden die beschriebenen Möglichkeiten aufgelistet: Schritt 1: Erstellen eines Differenzprotokolls
Schritt 2: Zuordnen der Kategorien und Gewichtungen
Schritt 3: Zuordnen eines Status an Differenzen
Schritt 4: Zuordnen eines Status an das Protokoll
Hier sei noch darauf hingewiesen, dass jeder Schritt N-mal durchgeführt werden kann und jeder Schritt nicht alle Differenzen berücksichtigen muss, sondern ein Schritt eingeschränkt durchgeführt werden kann. Nicht jede der genannten Möglichkeiten muss genutzt werden. Bevor eine Möglichkeit umgesetzt wird, sollte klar sein wie der Bewertungsverlauf ist. In den untenstehenden Beispielen wird versucht, mögliche Abläufe zu schildern.
Abhängig vom Benutzerkreis und seiner Rolle, kann ein Bewertungsschritt eine andere Zielsetzung haben und damit spielen dann auch Differenzen eine unterschiedliche Rolle. In den Beispielen wird unter Berücksichtigung des Benutzerkreises versucht verschiedene Abläufe zu definieren.
Abhängig vom Benutzerkreis und verfolgtem Ziel sollte der Inhalt der verwendeten MdB-Tabellen (DCAW, DDST, DPST) überprüft werden.
Die Bewertung von Differenzen bei Konfig hat hauptsächlich zum Ziel, zu ermitteln, ob Änderungen an einem Service- bzw. Subsystem die laufenden Anwendungen in einer höheren Stufe beeinträchtigen.
Zu 1) Änderungen an der Definition sollten eigentlich nicht auftreten, wenn vom Projekt eine aktuelle Referenzaufzeichnung geliefert worden ist. Wenn es Differenzen dieser Art gibt, könnten andere Systeme die diese API-Module der Subsysteme nutzen inkorrekt funktionieren, wenn sie diese veränderte Definition nicht berücksichtigt haben. Ein Beispiel wäre die Umbenennung von Feldern. Zu 2) Eine Änderung mit der Kategorie Qualität deutet mehr oder weniger auf Oopse hin. Wenn die Anzahl der Oopse sich erhöht hat, könnte das auf mögliche Probleme oder eine fehlerhafte bzw. instabile Implementierung des Moduls hinweisen. Zu 3) Eine Änderung mit der Kategorie Condition ist nur dann interessant, wenn zusätzlich Conditions gesetzt worden sind oder wenn sich die Severity einer Condition geändert hat. Zu 4) Eine Änderung mit der Kategorie Performance hat bei Subsystemen zur Folge, dass die Systeme die diese Subsysteme verwenden, bei der Nutzung sich ebenso in der Performance verbessern bzw. verschlechtern. Zu 5) Eine Änderung mit der Kategorie Content hat bei Subsystemen zur Folge, dass Daten die ein Modul liefert anders sind, was bei einem aktuellen Referenzstand auf ein fehlerhaftes Funktionieren des Moduls deuten kann.
Bei einer Betrachtung der Differenzen aus der Sicht von Konfig, gibt es nur 2 Gewichtungen für Differenzen; entweder „Info“ oder „Severe“. Der Einfluss der hier ausgeübt werden soll bezieht sich auf das Ändern der Gewichtungen. Hierzu sind folgende Ansätze denkbar:
Punkt 2) ist noch umzusetzen. Punkt 3) Die Bewertungsschritte können Teilbewertungen sein
Die Bewertung von Differenzen bei einem Projekt hat hauptsächlich zum Ziel, zu ermitteln, ob die technische und fachliche Weiterentwicklung der Systeme die Differenzen verursacht, die zu erwarten waren.
Zu 1) Eine Änderung mit der Kategorie Controlflow deutet auf zusätzliche Module oder in deren Funktionalität veränderte Module hin. Auf Projektebene spielt das Zusammenspiel im ganzen Ablauf eine große Rolle. Zu 2) Eine Änderung mit der Kategorie Qualität deutet mehr oder weniger auf Oopse hin. Wenn die Anzahl Oopse sich erhöht hat, könnte das auf mögliche Probleme oder eine fehlerhafte bzw. instabile Implementierung des Moduls hinweisen. Zu 3) Eine Änderung mit der Kategorie Condition ist nur dann interessant, wenn zusätzlich Conditions gesetzt worden sind, oder wenn sich die Severity eine Condition geändert hat. Wenn allerdings die Conditions benutzt werden, um Informationen zwischen Modulen auszutauschen, deuten Änderungen oder zusätzliche Conditions auf eine mögliche Änderung des Ablauf hin (siehe Punkt 1). Zu 4) Eine Änderung mit der Kategorie Performance ist im Hinblick auf die Art der Änderung zu betrachten. Zusätzliche Funktionalität kostet ggf. zusätzliche Performance. Wenn es Ziel war, das System performanter zu gestalten, ist einer Differenz dieser Kategorie ein anderer Stellenwert beizumessen.
Bei einer Betrachtung der Differenzen aus Projektsicht, gibt es nur 2 Differenzstati; entweder „Accept“ oder „NotAccept“. Der Einfluss der hier ausgeübt werden soll bezieht sich auf das Ändern des Differenzstatus. Hierzu sind folgende Ansätze denkbar:
Punkt 2) ist noch umzusetzen. Punkt 3) Die Bewertungsschritte können Teilbewertungen sein
Die Bewertung von Differenzen bei einer Benutzergruppe innerhalb eines Projektes hat hauptsächlich zum Ziel, zu ermitteln, ob die technische und fachliche Weiterentwicklung der Module bzw. Subsysteme die Differenzen verursacht, die zu erwarten waren.
Zu 1) Eine Änderung mit der Kategorie Qualität deutet mehr oder weniger auf Oopse hin. Wenn die Anzahl der Oopse sich erhöht hat, könnte das auf mögliche Probleme oder eine fehlerhafte bzw. instabile Implementierung des Moduls hinweisen. Es sollte angestrebt werden, eine oopsfreie Normalausführung des Moduls zu erhalten. Zu 2) Sind die Änderungen in den Objekten auch die Änderungen, die durch die neue Funktionalität zu erwarten waren.
Bei einer Betrachtung der Differenzen aus Sicht des Benutzers, ist die Änderung der Kategorie Content in Kategorien mit einer kleineren Granularität und die Zuordnung der Gewichtungen auf Basis der Zusammenhänge der richtige Ansatz.
Hierzu sind folgende Ansätze denkbar:
Punkte 2) und 3) sind noch umzusetzen. Die Umsetzung der beiden Punkte könnte in einem Schritt erfolgen.
Punkt 4) Die Bewertungsschritte können Teilbewertungen sein.
Die Bewertung von Differenzen für eine manuelle Abnahme hat hauptsächlich zum Ziel, jedem einen Einblick in die erzeugten Differenzen zu ermöglichen, wodurch der Entwickler bzw. der Fachverantwortliche entscheiden kann, ob die Softwarekomponente ihre Funktionalität korrekt und stabil ausführt.
Eigentlich sind alle Differenzen wichtig.
Bei einer Betrachtung der Differenzen für eine manuelle Abnahme, ist eine umfassende Kontrolle sehr wichtig. Das Programm welches der Benutzer bedient, soll:
Hierzu sind folgende Ansätze denkbar:
Punkt 2) ist noch umzusetzen.