1                     Themenübersicht

Semiramis unterstützt die Bearbeitung von Kundenanfragen und Erweiterungen, sowohl bei der Erfassung als auch bei der Umsetzung und Auslieferung. Korrekturen im Standard von Semiramis können vom Semiramis Supportsystem bis zum Kundensystem transportiert werden.

Semiramis bietet Anwendungen zur Verwaltung der Supportanfragen und der daraus resultierenden Entwicklungsaufträge. Nach Abschluss der Entwicklung können die entstandenen Softwareaktualisierungen mit einer Supportauslieferung ausgeliefert werden. Der Transport von Softwareaktualisierungen bis zum Produktivsystem kann ebenfalls automatisiert werden.

2                     Zielgruppe

Die Zielgruppe dieses Dokuments sind Administratoren und technische Berater.

3                     Begriffsbestimmung

Supportanfrage

Eine Supportanfrage ist alles, was als Anfrage, Fehlermeldung, Wunsch usw. eingeht. Supportanfragen können je nach Vorgang sowohl von Mitarbeitern der Partner als auch von Kunden erfasst werden.

Entwicklungsauftrag

Ein Entwicklungsauftrag ist ein Auftrag an ein Einwicklungsteam, um eine Korrektur oder Neu- bzw. Weiterentwicklung durchzuführen. Entwicklungsaufträge beschreiben das zu lösende Problem auf einer technischen Ebene. Bei der Bearbeitung einer Supportanfrage können Entwicklungsaufträge angelegt werden.

Supportauslieferung

Supportauslieferungen werden benutzt, um Informationen und Softwareaktualisierungen auszuliefern. Zu diesem Zweck kann einer Supportauslieferung optional ein beschreibender Text und optional eine Softwareaktualisierung zugeordnet werden.

Vom Semiramis-Support erstellte Supportauslieferungen enthalten einen redaktionell aufbereiteten, zur allgemeinen Einsicht freigebenden Text. Supportauslieferungen für den Kunden werden für genau einen Kunden erstellt.

Internes System

Jeder Partner kann optional ein internes System besitzen. In einem internen System werden Supportanfragen, Entwicklungsaufträge und Supportauslieferungen verwaltet. Das Releasestand des internen Systems ist unabhängig von dem Releasestand der verwalteten System.

4                     Beschreibung

4.1               Systemübersicht

Im Rahmen der Abarbeitung von Supportanfragen werden Verwaltungsinformationen und Softwareaktualisierungen erzeugt. Die Verwaltungsinformationen zur Bearbeitung einer Supportanfrage werden in einem internen System in der Supportdatenbank abgelegt. Sowohl der Semiramis-Support als auch optional die Semiramis-Partner besitzen solch ein internes System. In einer Supportdatenbank können Supportanfragen unterschiedlicher Systeme und Releases verwaltet werden. Das Releasestand des internen Systems ist unabhängig von dem Releasestand der verwalteten System.

Systemübersicht CISAG – Partner – Kunde

Jeder Partner besitzt für jedes von der CISAG herausgegebene Release, zu dem er Kunden hat, ein Qualitätssicherungssystem (QAS). Das QAS-System ist immer auf dem aktuellsten Stand, d.h. alle von der CISAG erstellten Supportauslieferungen werden zeitnah in Qualitätssicherungssystem übernommen. Das QAS-System hat die folgenden Aufgaben:

• Es versorgt alle anderen Systeme des gleichen Releases mit Softwareaktualisierungen, d.h. insbesondere die Kundenadaptierungssysteme, Demosysteme und das interne System.
• Auf dem QAS-System kann der Partner überprüfen, ob ein vom Kunden gemeldeter Fehler im Standard nachvollziehbar ist.

Im Kundenadaptierungssystem werden kundenspezifische Anpassungen entwickelt. Die Übernahme von Softwareaktualisierungen aus dem QAS- in das Kundenadaptierungssystem kann auf Grund von Konflikten mit Kundenadaptierungen zu weiteren Softwareaktualisierungen führen.

Systemlandschaft beim Partner und Kunden

Im Kundenadaptierungstestsystem werden alle aus dem Kundenadaptierungssystem stammenden Softwareaktualisierungen eingespielt. Je nach Größe des Kunden beziehungsweise Umfang der Adaptierungen kann für einen Kunden wieder ein Qualitätssicherungssystem QS unterhalten werden.

Insbesondere während der Entwicklungszeit, hat das Kundenadaptierungstestsystem einen anderen Stand als das Produktivsystem, so dass sich dort die Fehlermeldungen des Kunden nicht mehr verlässlich nachvollziehen lassen. In diesem Fall ist es sinnvoll, dass der Partner bei sich im Haus ein Duplikat (Qualitätssicherungssystem QS) des Codestandes des Kundenproduktivsystems hat. Auf dem QS-System kann der Partner Fehlermeldungen des Kunden nachvollziehen und ggf. leichter Debuggen als auf dem Kundensystem bzw. dem Kundentestsystem beim Kunden. In das QS-System werden genau die Softwareaktualisierungen eingespielt, die zum Kunden ausgeliefert werden.

Jeder Kunde muss ein Testsystem haben, auf dem dieser alle vom Partner stammenden Softwareaktualisierungen einspielen muss. Das Kundentestsystem muss nur dann gestartet sein, wenn Softwareaktualisierungen installiert oder getestet werden.

Auf diesem Kundentestsystem wird überprüft, ob die ausgelieferten Softwareaktualisierungen fehlerfrei sind. Es empfiehlt sich, dass das Kundentestsystem eine OLTP-Datenbank mit einem für den Kunden repräsentativen Datenbestand besitzt. Der Kunde kontrolliert im Kundentestsystem, ob die Softwareaktualisierungen bei diesem Datenbestand korrekt eingespielt werden können. Insbesondere bei Datenmodelländerungen sollte der Kunde testen, ob sein Datenbestand korrekt überführt wurde. Nach dem Einspielen der Softwareaktualisierungen testet der Kunde, ob die vom Partner ausgelieferte Funktionalität seinen Anforderungen genügt.

Wenn Softwareaktualisierungen im Kundentestsystem erfolgreich getestet wurden, so werden diese vom Kundentestsystem in das Produktivsystem übernommen.

Bei größeren Kunden kann zusätzlich zum Kundentestsystem ein zweites Testsystem (T2) erstellt werden. Wenn es ein T2-System gibt, so gibt es kein T-System, sondern ein T1-System. Alle vom Partner kommenden Supportauslieferungen werden sowohl in das T1-System als auch in das T2-System übernommen. Das T2-System wird vor dem Einspielen der Softwareaktualisierungen aus einer vollständigen Kopie des Produktivsystems erstellt. Damit wird getestet, ob das Einspielen der Softwareaktualisierungen auf dem Produktivsystem zu Problemen führen kann. Insbesondere die Auswirkungen von Datenaktualisierungen und Datenmodelländerungen auf die Produktivdaten können kontrolliert werden.

Falls ein Kunde keine Adaptierungen braucht, so benötigt dieser auch kein DV-System. In diesem Fall sollte jedoch trotzdem ein DT-System angelegt werden, um von der CISAG stammende Supportauslieferungen weiter zusammenzufassen und um vom Kunden gemeldete Fehler im DT-System nachvollziehen zu können.

Es gibt SYS- und APP-Softwareaktualisierungen. SYS-Softwareaktualisierungen enthalten Änderungen an System-Entwicklungsobjekten und ggf. alle für den Betrieb der Systems notwendigen Dateien. Insbesondere können SYS-Softwareaktualisierungen die System-Engine, den Varial-Client, den ODBC-Treiber usw. enthalten. SYS- und APP-Softwareaktualisierungen können nicht zusammengefasst werden.

Branchenlösungen werden in diesem Dokument nicht behandelt.

4.2               Supportvorgänge

Die folgenden Ursachen können einen Supportvorgang für einen Kunden einleiten:

• Der Kunde hat ein Problem, das gelöst werden muss.

Dies trifft beispielsweise zu, wenn der Kunde einen Fehler in der Adaptierung oder im Standard gefunden hat.

• Der Kunde wünscht eine Erweiterung.

Beispielsweise wünscht der Kunde zusätzliche Funktionalität vom Partner.

• Der Partner will präventiv das Kundensystem aktualisieren.

Beispielsweise möchte der Partner eine wichtige Fehlerkorrektur zu einem Fehler ausliefern, der dem Kunden noch nicht aufgefallen ist.

In dem internen System werden alle Daten verwaltet, um die obigen Vorgänge zu unterstützen. Um die obigen Supportfälle zu bearbeiten werden Supportanfragen, Entwicklungsaufträge und Supportauslieferungen benötigt. Zwischen Supportanfragen, Entwicklungsaufträgen und Supportauslieferungen können Beziehungen angelegt werden. Diese Beziehungen haben einen Typ, der unterschiedliche Bedeutungen ausdrückt, wie beispielsweise „abhängig von“, „zu testen mit“, „Ursprungssupportanfrage“, „Folgeentwicklungsauftrage“ usw.. Die Beziehungen selbst sind unidirektional, es wird jedoch für jede Beziehung auch die Gegenrichtung angelegt.

Zusammenhänge zwischen Supportanfragen und Softwareaktualisierungen

Zu der Bearbeitung einer Supportanfrage können mehrere Entwicklungsaufträge angelegt werden. Diese Entwicklungsaufträge werden in mehreren Entwicklungsaufgaben, aus denen dann Softwareaktualisierungen entstehen, bearbeitet. Es ist möglich, dass ein Entwicklungsauftrag mehr als eine Supportanfrage löst. Ebenso ist es auch möglich, dass eine (ggf. zusammengefasste) Softwareaktualisierung zu mehr als einen Entwicklungsauftrag gehört.

Über die Entwicklungsaufträge besteht eine n zu m Beziehung zwischen der Supportanfrage und der Supportauslieferung. Meist wird es jedoch zu einer Supportanfrage auch nur eine Supportauslieferung geben. Der Fall, dass zu einer Supportanfrage mehr als eine Supportauslieferung existiert, ist möglich, aber eher selten. Zu einer Supportauslieferung wird häufig mehr als eine Supportanfrage eine Beziehung haben.

Die CISAG liefert zu jeder Softwareaktualisierung eine Supportauslieferung der Art RFR (Refresh) aus. Zu jeder Supportauslieferung gehört ein Text, der die mit der Softwareaktualisierung ausgelieferten Änderungen beschreibt.

INF-Supportauslieferungen enthalten Hinweise und Vorgehensweisen zu der Lösung allgemeiner Probleme. INF-Supportauslieferungen können aufgrund einer Supportanfrage entstehen oder aber präventiv vom Semiramis-Support oder der CISAG erfasst werden. Zu einer INF-Supportauslieferung gibt es keine zugehörige Softwareaktualisierung.

Der Partner kann für seine Kunden ebenfalls Supportauslieferungen erstellen, diesen ist immer eine Softwareaktualisierung zugeordnet.

Partnern wird empfohlen, ein internes System zu nutzen. Dieses interne System kann die an den Semiramis-Support gestellten Supportanfragen, die vom Kunden erfassten Supportanfragen sowie die daraus entstehenden  Entwicklungsaufträge und Supportauslieferungen enthalten.

Der Partner erstellt Supportauslieferungen immer für genau einen Kunden. Supportauslieferungen von der CISAG werden für beliebig viele Partner erstellt, d.h. Supportauslieferungen für einen Kunden haben genau diesen Kunden als Empfänger, während INF- und RFR-Supportauslieferungen keinen speziellen Empfänger haben.

Eine Supportauslieferung für einen Kunden enthält meist mehr als einen Entwicklungsauftrag, und zu den meisten Entwicklungsaufträgen gibt es mindestens eine Softwareaktualisierung. Einer Supportauslieferung kann jedoch nur eine Softwareaktualisierung zugeordnet sein. Deshalb werden beim Erstellen der Supportauslieferung alle zugehörigen Softwareaktualisierungen zu einer Softwareaktualisierung zusammengefasst. Diese zusammengefasste Softwareaktualisierung bildet eine nicht mehr auftrennbare Einheit.

Die Granularität der Supportauslieferungen ist sowohl durch die Abhängigkeiten zwischen den Entwicklungsaufträgen bzw. Softwareaktualisierungen bestimmt als auch davon, was für den Verwendungszweck angemessen ist. Für Supportauslieferungen für den Kunden ist es nützlich, die Softwareaktualisierungen soweit wie möglich zusammenzufassen, damit der Kunde nur eine große Softwareaktualisierung installieren muss. Die CISAG teilt die Supportauslieferungen in thematische Gruppen, die z.B. durch das Framework oder die Anwendung untergliedert sind. Dadurch können Supportauslieferungen selektiv eingespielt werden, um spezielle Probleme zu lösen.

4.2.1          Supportanfragen vom Kunden

Wenn der Kunde ein Problem hat, stellt er eine Supportanfrage. Die Behandlung der Supportanfrage ist im Wesentlichen unabhängig davon, ob es sich um einen Fehler, einen Erweiterungswunsch oder ein Verständnisproblem des Kunden handelt. Die Behandlung von Supportanfragen durch den Partner lässt sich grob in die folgenden Vorgänge unterteilen:

• Die Supportanfrage ist einfacher Natur und kann direkt beantwortet werden. (Grafik: Fall A)
• Wenn die Supportanfrage nicht ohne Entwicklungsaufwand bearbeitet werden kann, so muss überprüft werden, wo das Problem liegt und wie es behoben werden kann. (Grafik: Fall B)
• Das in der Supportanfrage beschriebene Problem ist bereits bekannt und in Bearbeitung. In diesem Fall wird die Supportanfrage mit dem entsprechenden Entwicklungsauftrag oder der Supportanfrage verbunden. (Grafik: Fall A oder B)

Die oben beschriebenen Varianten lassen sich in das folgende vereinfachte Schema abbilden:

Ablauf einer Supportanfrage

Beim Kategorisieren der Supportanfrage wird dieser unter anderem ein Bearbeiter und eine Priorität zugeordnet. Von dem zugeordneten Bearbeiter wird die Supportanfrage analysiert. Bei der Analyse einer Supportanfrage werden die Ursachen für das vom Kunden beschriebene Problem gesucht. Als ein Ergebnis der Analyse können Entwicklungsaufträge erzeugt werden. Falls Entwicklungsaufträge angelegt wurden, werden diese bearbeitet und erzeugen Softwareaktualisierungen. Um die zu einer Supportanfrage erarbeitete Lösung an den Kunden auszuliefern, wird eine Supportauslieferung erstellt. Wenn im Rahmen der bearbeiteten Supportanfrage auch Softwareaktualisierungen der CISAG übernommen worden sind, so können diese mit den von dem Partner erstellten Softwareaktualisierungen zu einer Softwareaktualisierung zusammengefasst werden. Diese zusammengefasste Softwareaktualisierung wird mit der Supportauslieferung verknüpft.

In dem vereinfachten Schema sind nicht alle möglichen Vorgänge und alle beteiligten Personen zur Bearbeitung einer Supportanfrage abgebildet. Aus diesem Grund werden einige Abläufe im Folgenden genauer beschrieben.

4.2.2          Analyse einer Supportanfrage

Das Ziel der Analyse einer Supportanfrage ist es, die technischen Ursachen für ein Problem das der Kunde hat zu finden. Die Analyse einer Supportanfrage kann zu den folgenden Ergebnissen führen:

• Das Problem ist bereits bekannt.
• Das Problem ist lösbar:
• Es ist ein Konfigurations- oder Verständnisproblem des Kunden.
• Es ist ein Fehler in einer Kundenadaptierung
• Das Problem betrifft den Standard
• Das Problem ist bereits gelöst.
• Der Partner stellt eine Supportanfrage an den Semiramis-Support.

Die folgende Graphik deutlicht den Ablauf der Analyse einer Supportanfrage:

Ablauf der Analyse einer Supportanfrage

Ist das Problem bereits bekannt, kann eine Beziehung zu dem Entwicklungsauftrag oder der Supportanfrage erfasst werden, die das Problem beschreibt.

Wenn das Problem noch nicht bekannt ist, so sollte das Problem als Erstes auf dem Kundenadaptierungstestsystem bzw. falls vorhanden auf dem QS-System nachvollzogen werden. Ist das Problem im Kundenadaptierungstestsystem bzw. QS-System reproduzierbar, so muss entschieden werden, ob das Problem den Standard oder nur eine Kundenadaptierung betrifft. Wenn das Problem nicht reproduzierbar ist, so handelt es sich entweder doch um ein bekanntes Problem, das bereits gelöst wurde, oder aber das Problem ist abhängig von der Konfiguration oder den Daten des Kunden. In diesem Fall sind weitere Rückfragen bzw. die Anpassung der Testumgebung notwendig. Der Partner kann sich zu diesem Zweck auch beim Kunden einwählen und den Fehler direkt dort nachvollziehen, um seine Testumgebung zu verbessern.

In besonderen Fällen kann es sein, dass die Analyse nicht ohne Hilfe des Semiramis-Supports durchgeführt werden kann. In diesem Fall benötigt der Semiramis-Support einen Zugang auf das Produktivsystem des Kunden.

Betrifft die Supportanfrage die Kundenadaptierung, so können Entwicklungsaufträge zur Fehlerbehebung der Kundenadaptierung erfasst werden. Diese Entwicklungsaufträge besitzen eine Beziehung zu der Supportanfrage aufgrund derer diese erstellt worden sind.

Wenn das Problem den Standard betrifft, muss dieses auf dem Qualitätssicherungssystem verifiziert werden. Das Qualitätssicherungssystem muss dazu den aktuellsten von der CISAG ausgelieferten Stand haben.

Wenn das Problem im Qualitätssicherungssystem nicht reproduzierbar ist, dann muss der Partner die entsprechenden Softwareaktualisierungen im QAS-System auswählen und diese im DV-System installieren.

Wenn das Problem im Qualitätssicherungssystem reproduzierbar ist, so betrifft es die Standardauslieferung der CISAG. In diesem Fall muss eine neue Supportanfrage an das Semiramis Support Center gestellt werden. Die Durchlaufzeit einer Supportanfrage beim Semiramis-Support ist jedoch mindestens die Zeit bis zu einer Zwischenauslieferung, die im Allgemeinen nur alle 2 Wochen erstellt wird. Wenn der Kunde nicht so lange auf eine Lösung warten kann, so muss ein Entwicklungsauftrag für einen „Hotfix“ erfasst werden. In diesem Entwicklungsauftrag wird eine Lösung für das Problem des Kunden implementiert, ggf. mit Hilfe des Semiramis-Supports. Wenn das Problem nicht so dringend ist, so muss der Partner darauf warten, dass die CISAG die Supportanfrage bearbeitet und mit einer Supportauslieferung ausliefert.

4.2.3          Bearbeitung einer Supportanfrage

Im Standardfall folgt die Bearbeitung einer Supportanfrage dem folgenden Schema:

Bearbeitung einer Supportanfrage

Bevor mit der Bearbeitung der Entwicklungsaufträge begonnen wird, muss entschieden werden, ob die Übernahme von Softwareaktualisierungen aus dem QAS-System notwendig oder gewünscht ist. Wenn Softwareaktualisierungen übernommen werden, dann hat der Partner die Wahl entweder alle Softwareaktualisierungen vom QAS-System oder selektiv nur bestimmte Softwareaktualisierungen im DV-System zu installieren. Die Supportdatenbank mit den Beschreibungen der Supportauslieferungen ist bei Auswahl der zu installierenden Softwareaktualisierungen hilfreich.

Beim Einspielen der Softwareaktualisierungen in das DV-System kann eine Entwicklungsaufgabe zur Konfliktbearbeitung notwendig sein. Diese Aufgabe muss entweder einem bestehenden Entwicklungsauftrag zugeordnet werden oder aber es muss ein weiterer Entwicklungsauftrag angelegt werden.

Nach der Übernahme der Softwareaktualisierungen aus dem QAS-System werden die zu der Supportanfrage gehörigen Entwicklungsaufträge bearbeitet. Das Ergebnis der Bearbeitung der Entwicklungsaufträge sind eine oder mehrere Softwareaktualisierungen.

Während der Bearbeitung der Entwicklungsaufträge können Beziehungen zwischen unterschiedlichen Entwicklungsaufträgen erfasst werden. Mit diesen Beziehungen können Abhängigkeiten und Verweise ausgedrückt werden.

Wenn die Bearbeitung eines Entwicklungsauftrags abgeschlossen ist, so kann und sollte ein Softwareauslieferungstext für den Kunden erfasst werden. Der Softwareauslieferungstext wird später in die Supportauslieferung übernommen werden. Im Softwareauslieferungstext erfährt der Kunde, welche Inhalte die Softwareaktualisierung hat bzw. welche Besonderheiten bei oder nach der Installation der Softwareaktualisierung zu beachten sind. Der Softwareauslieferungstext der Entwicklungsaufträge kann beim Erstellen der Supportauslieferung als Vorlage für den beschreibenden Text der Supportauslieferung dienen.

4.2.4          Supportauslieferung an den Kunden

Bei einer Supportauslieferung mit Softwareaktualisierung werden die Softwareaktualisierungen ausgewählt, die der Supportauslieferung zugeordnet werden sollen. Im Allgemeinen sollten nur Softwareaktualisierungen aus erledigten Entwicklungsaufträgen ausgeliefert werden. Alle auszuliefernden Softwareaktualisierungen werden dabei untrennbar zu einer einzigen Softwareaktualisierung zusammengefasst. Diese zusammengefasste Softwareaktualisierung wird zu der Supportauslieferung abgelegt.

Wenn ein erledigter Entwicklungsauftrag einer Supportauslieferung zugeordnet wird, so wechselt der Entwicklungsauftrag in den Zustand abgeschlossen.

Zusammenhänge Softwareaktualisierungen und Supportauslieferung

Jede noch nicht zusammengefasste Softwareaktualisierung ist im Rahmen der Bearbeitung eines Entwicklungsauftrags entstanden. Auf diesem Weg können Beziehungen zwischen den ausgelieferten Entwicklungsaufträgen und der Softwareauslieferung hergestellt werden. Die Entwicklungsaufträge haben Beziehungen zu den Ursprungssupportanfragen. Somit ist bekannt, mit welcher Supportauslieferung eine Supportanfrage bearbeitet worden ist.

Beispiel für die Beziehungen zwischen Supportanfragen, Entwicklungsaufträgen und Supportauslieferungen

Wenn eine Supportanfrage vollständig bearbeitet worden ist, so ist diese im Status „Folgeaufträge bearbeitet“. Sobald alle zur Supportanfrage gehörenden Entwicklungsaufträge in eine Supportauslieferung aufgenommen worden sind, wechselt die Supportanfrage in den Zustand „erledigt“. Der Kunde wird von dem Statuswechsel der Supportanfrage informiert und kann die daraus entstandene Supportauslieferung herunterladen und installieren. Der Kunde überführt nach dem Test der Softwareaktualisierungen die zugehörige Supportanfrage in den Zustand „abgeschlossen“. Wenn der Anfragesteller mit der Lösung nicht zufrieden ist, so überführt der Kunde die Supportanfrage in den Zustand „Korrektur notwendig“. In diesem Fall muss die Supportanfrage erneut bearbeitet werden.

4.3               Verteilung von Softwareaktualisierungen

Jede Softwareaktualisierung durchläuft von ihrem Entstehungsort bis zu ihrem Ziel einen genau festgelegten Transportweg. Auf dem Transportweg kann die Softwareaktualisierung mit anderen Softwareaktualisierungen zusammengefasst werden.

Vor jedem Einspielen von Softwareaktualisierungen in ein beliebiges System muss eine vollständige Sicherung des Systems vorliegen. Falls es beim Einspielen der Softwareaktualisierungen zu einem Fehler kommt, muss diese Sicherung zurückgespielt werden.

Transportwege von Softwareaktualisierungen

QS- oder T2-Systeme sind in der Grafik nicht berücksichtigt. Diese bilden zusätzliche Wegpunkte auf dem Transportweg einer Softwareaktualisierung, ändern aber nichts an dem prinzipiellen Ablauf.

Es wird aber dringend empfohlen, die in diesem Dokument vorgestellten Transportwege einzuhalten, da diese ein für Kunden angemessenes Qualitätsmanagement ermöglichen. Fehlkonfigurationen durch Abweichungen von den empfohlenen Transportwegen können zu irreparablen Inkonsistenzen in den beteiligten Systemen führen, die eine vollständige Neuinstallation dieser Systeme erfordern.

4.3.1          Download Supportauslieferungen

Über die Anwendung „Supportauslieferungen abfragen“ kann der Benutzer die Supportauslieferungen abfragen, die er noch nicht downgeloaded hat:

• Ein Benutzer kann abfragen, welche Softwareaktualisierungen bzw. INF-Supportauslieferungen er persönlich noch nicht abgefragt hat.
• Ein Benutzer kann abfragen, welche Softwareaktualisierungen bzw. INF-Supportauslieferungen noch niemand aus der Organisation, in der er Mitarbeiter ist, abgefragt hat.

An der Supportauslieferung wird zu diesem Zweck gespeichert, von wem und wann die dazugehörige Softwareaktualisierungen downgeloadet wurde. Zusätzlich zu dem Eintrag des Benutzers wird beim ersten Download auch ein Eintrag für die Organisation, in der er Mitarbeiter ist, gespeichert.

4.3.2          Zielsystem aktualisieren

Die Funktion „Zielsystem aktualisieren“ des Softwareaktualisierungscockpits setzt voraus, dass die Kommunikation zwischen dem QAS-Systems  den Kundenadaptierungssystemen funktioniert. Um dies sicherzustellen sollten beteiligten Systeme mit der gleichen Konfigurationsdatenbank laufen.

Bei der Funktion „Zielsystem aktualisieren“ startet das Quellsystem das Einspielen der ausgewählten Softwareaktualisierungen im Zielsystem. Wenn der Message-Server des Zielsystems läuft und in der Konfigurationsdatenbank des Quellsystems korrekt eingetragen ist, so transferiert das Quellsystem die ausgewählten Softwareaktualisierungen in das Import-Verzeichnis des Message-Servers des Zielsystems. Danach werden die Softwareaktualisierungen im Zielsystem installiert. Für jeden Installationsvorgang wird ein Protokoll geschrieben, welches für das Zielsystem im Systemcockpit abgefragt werden kann. Dieses Protokoll enthält Informationen über den Erfolg bzw. Misserfolg des Installationsvorgangs.

Falls die Kommunikation zwischen den Message-Servern nicht gewünscht ist, so sollte das Kundenadaptierungssystem so eingerichtet werden, dass dieses die Liste mit den importierten Coderefreshes im QAS-System des Partners ablegen kann. Die Softwareaktualisierungen müssen in diesem Fall jedoch manuell in das Kundenadaptierungssystem übernommen und eingespielt werden.

Vor jeder Installation von Softwareaktualisierungen in einem System sollte eine vollständige Sicherung des Systems vorliegen, die im Fehlerfall erlaubt, das System kurzfristig wieder in den ursprünglichen Zustand zurückzuversetzen.

4.3.3          Supportauslieferungen vom Semiramis-Support

Vom Semiramis-Support werden in regelmäßigen Abständen RFR-Support­auslieferungen für jedes ausgelieferte Release bereitgestellt. Die RFR-Support­auslieferungen umfassen mehrere Supportanfragen und können thematisch gegliedert sein. Zu jeder RFR-Supportauslieferung erstellt die CISAG genau eine zusammengefasste Softwareaktualisierung. Von der CISAG werden keine Softwareaktualisierung ohne Supportauslieferung ausgeliefert.

Der Semiramis-Support stellt die Softwareaktualisierungen mit den Softwareauslieferungen allen Partnern auf dem Support-System zum Download bereit.

INF- und RFR-Supportauslieferungen haben keine speziellen Empfänger und sind deshalb für alle Partner gleichermaßen sichtbar.

4.3.4          Verteilung auf Kundenadaptierungssysteme

Bei der Verteilung auf Kundenadaptionssysteme wird die Funktion „Zielsystem aktualisieren“ des Softwareaktualisierungscockpits verwendet. Wenn der Message-Server eines Kundenadaptierungssystems erreichbar ist, d.h. wenn dieser läuft und in der Konfigurationdatenbank korrekt erfasst ist, dann kann vom QAS-System das Kundenadaptierungssystem aktualisiert werden. Diese Vorgehensweise wird für alle Partner empfohlen.

4.3.5          Transport zum Kundenadaptierungstestsystem

Die Softwareaktualisierungen werden durch die Funktion „Zielsystem aktualisieren“ vom DV- in das DT-System übernommen.

4.3.6          Supportauslieferungen für den Kunden

Softwareaktualisierungen können mit oder ohne die Nutzung eines internen Systems an den Kunden ausliefert werden. Die Verwendung eines internen Systems wird von der CISAG empfohlen, ist aber nicht notwendig.

Wenn der Partner ein internes System nutzt, so muss er eine Supportauslieferung erstellen, wenn er Softwareaktualisierungen zum Kunden transportieren will. Beim Erstellen der Supportauslieferung werden Softwareaktualisierungen zusammenfasst und an das interne System übertragen. Die zusammengefasste Softwareaktualisierung wird auf dem internen System nicht installiert, sondern nur als Datei ableget. Der Kunde kann dort über die Anwendung „Supportauslieferungen abfragen“ alle Supportauslieferungen abfragen, die er noch nicht downgeloadet hat.

Wenn kein internes System eingesetzt wird, müssen die entsprechenden Dateien beispielsweise auf einem FTP-Server zum Download angeboten werden.

Transportwege von Softwareaktualisierungen ohne Verwendung eines internen Systems

Wenn die Softwareaktualisierungen im Kundentestsystem erfolgreich getestet wurden, können diese in das Produktivsystem übernommen werden. Dieser Vorgang kann der Funktion „Zielsystem aktualisieren“ erfolgen.

4.3.7          Auslieferungen an externe Standardsysteme

Der Partner kann externe Systeme einrichten, die keine Adaptionen benötigen. Wenn dieses Systeme ein Kundensystem ist, so empfiehlt es sich dennoch, ein DT-System beim Partner für den Kunden anzulegen, damit Fehlermeldungen des Kunden beim Partner leichter auf dem Kundenstand nachvollzogen werden können.

Wenn das externe System kein Kundensystem sondern ein Demosystem ist, so ist das Einrichten eines DT-Systems unnötig. In diesem Fall werden, wenn das Demosystem aktualisiert werden soll, im QAS-System die Softwareauslieferungen auf Basis der der im Demosystem importierten Softwareaktualisierungen ausgewählt.

Ein Demosystem, das das QAS-System nicht über das Messaging erreichen kann, kann nicht automatisch mit der Funktion „Zielsystem aktualisieren“ aktualisiert werden. Die Softwareaktualisierungen müssen per Dateitransfer zum Demosystem übertragen und in das Import-Verzeichnis abgelegt werden.