Beschreibung
REMOTE ggf Ludwigsburg: BMC Remedy ITSM Suite Entwickler w/m/d POS47531Einsatzort: REMOTE ggf Ludwigsburg
Remedy Developer
Leistungszeitraum
Starttermin: ASAP, bzw. Anfang 2020
Einsatzende: 30.06.2021
Ort: Remote, ggf. ab und zu Ludwigsburg
Leistungsbeschreibung:
1) Aufbau und Inbetriebnahme
Das E-/K-System wird aus Sicht der Infrastruktur bereitgestellt. Es ist die Software für den AR-Server
(Laufzeit und Entwicklung sowie notweniger weiterer Software) zu installieren und mit dem jeweiligen
Datenbanksystem zu integrieren. Die Integration umfasst hierbei ggfs. notwendige Anpassungen, da die Datenbank
eine Spiegelung des P-Systems ist. Es ist ebenfalls das MidTier (WAR-Archive) für das jeweilige System
bereitzustellen.
Zur Erprobung soll zunächst auf dem E-System auch das Reporting von Remedy installiert werden. Nach
erfolgreicher Erprobung ist diese Komponente auch auf dem K- und P-System ausgerollt werden.
2) Upgrade / Aktualisierung
Um die Systeme weiterhin supportfähig zu halten ist ein Upgrade von 9.1 in Richtung 18.x vorgesehen und unter
Beachtung der Lizenzbedingungen durchzuführen.
3) Analyse Berechtigungskonzept
Das bisher vorhandene Berechtigungskonzept der Anwendung trifft die heutigen Anforderungen nur noch teilweise.
Es ist eine Analyse der Rollen und Berechtigungen durchzuführen und mit den aktuellen Anforderungen
abzugleichen. Aus dieser dokumentierten Soll-Ist-Darstellung muss der Soll-Zustand umgesetzt werden. Aus der
Analyse kann es sich ebenfalls ergeben, dass die für technische Zweckeverwendeten Benutzer anzupassen sind.
In diesem Zuge muss auch eine Trennung zwischen technischer und fachlicher Administration vorgenommen werden.
Durch diese Trennung muss das neben dem SSO vorhandene manuelle Login entfernt werden. 4) Lizenzen
Durch die Hinzunahme weiterer Benutzer sind weitere Lizenzen notwendig. Um zu vermeiden, dass unnötige
Lizenzen gekauft werden, müssen die abgelehnten Lizenzen analysiert werden. Im Anschluss soll die Anzahl der
zu beschaffenden Lizenzen bestimmt werden.
Aufgrund des Berechtigungs - und Rollenkonzepts kann zurückgeschlossen werden, welcher Benutzer aus welcher
Organisationseinheit aktiv ist. Es ist zu prüfen, ob eine Lizenzbeschränkung (Anzahl der zur Nutzung
bereitgestellten Lizenzen je Organisationseinheit) umgesetzt werden kann und welche Rahmenbedingungen hierzu
notwendig sind.
5) Archivierung und Löschung
Aufgrund gesetzlicher Regularien müssen PRMS-Tickets archiviert und zu einem späteren Zeitpunkt gelöscht
werden. Es ist ein entsprechendes technisches Konzept unter Berücksichtigung der vorhandenen Infrastruktur
(Hard- und Software) nach fachlicher Vorgabe zu erarbeiten. Hierbei ist auch der Zugriff auf archivierte Daten
im Hinblick auf die Performance zu berücksichtigen.
Entwicklungstätigkeiten
6) Mailversand
Der Mailversand wird heute über POP3 realisiert. Es ist eine Umstellung auf IMAP vorzunehmen.
7) Attachments (Anhänge) zu Tickets
Die Attachments zu den Tickets werden derzeitig in der Datenbank gespeichert. Zum einen ist die Speicherung so
umzustellen, dass die Attachments auf dem Dateisystem des AR-Servers gespeichert werden und zum anderen müssen
die bisherigen Attachments auf das Dateisystem ausgelagert werden (Migration der Attachements).
8) Look & Feel
Die graphische Oberfläche wurde für den IE11 optimiert. Das entsprechende Look & Feel ist auf Google Chrome
und ggfs. Firefox zu übertragen. Zu berücksichtigen ist hierbei auch die Verwendung von IE11-Nachfolgern.
9) Ticket Druck
Die Funktionalität des Ticket Druck, insbesondere Laufzeit entspricht den Erwartungen. Diese Funktionalität
ist zu überarbeiten.
10) Performance
Die vorhandenen Workflows zeigen reproduzierbar Laufzeitschwächen auf. Es ist über AWR-Reports und
Netzwerkanalysen nachweisbar, dass Probleme in den Workflows liegen. Diese Performance-Löcher sind zu
analysieren und zu beseitigen.
11) PRMS-Navigation
Das aktuelle Design der PRMS-Navigation mit den mehrfachen Suchtabellen je Thema und der nicht
funktionierenden Größenänderung der Tabellen innerhalb der Verschachtelung der Reiter soll ersetzt werden.
Es wird EINE Tabelle (pro Zieltabelle) in einem neuen Reiter-Bereich erstellt (um hier den vertikalen Platz
mit/ohne Details-Bereich bis zum unteren Rand ausnützen zu können)
Über 10 sog. „Quick-Buttons“ werden die Standardsuchen (welche bis jetzt fix auf die Karteireiter verteilt
waren) für die User hinterlegt. Somit muss diesbezüglich die PRMS-Userkonfiguration erweitert werden.
Die User können sich ihre Quick-Buttons frei wählen und belegen. Aus einem Set von x vorgegebenen Suchen
(welche durch die Admins frei definierbar sind, und auch von Key-Usern erstellt werden könnten) kann sich der
User in seinen User-Einstellungen die passenden Suchen auf einen der 10 Quick-Buttons legen.
Hierzu wird die aktuelle Filter-Funktion am rechten Rand erweitert – um eine freie Qualifikation hinterlegen
zu können. Diese dort definierte Suche kann man weiter über das Drop-Down Menü auswählen, aber eben auch auf
die Quick-Buttons legen.
Initial werden für alle User die aktuellen Suchen (Unsere Tickets, Meine Tickets…) auf die ersten Buttons
gelegt.
Fixe Filterfelder, welche die Suche der Quick-Buttons weiter eingrenzen sollen in der ersten Phase noch nicht
erstellt werden. Dies soll über die Quick-Buttons Filter-Funktionen mitgenommen werden.
Initial wird ein fixer Chunk auf 30 Tickets pro Seite eingestellt. Somit werden pro Chunk („Seite“) jeweils 30
Tickets angezeigt – mittels « und » kann zwischen den Chunks gewechselt werden.
12) PRMS-Administration
Es ist ein fixes Chunking auf alle Tabellen aktivieren, kein automatische Refresh bei Reiterwechsel.
Reiter User: Suche nach Username, letztes Login Datum. (Hierzu ist die Usertabelle um das letzte Login-Datum
des Benutzers zu erweitern); des Weiteren eine Mehrfachauswahl aktivieren für Löschen-Befehl. Vor dem Löschen
werden aber die Offenen Tickets des Users ausgelesen – um diese vorher zu schließen oder weiterzuleiten. Diese
Funktion soll entweder über einen neuen Button „Offene Tickets“ ermöglicht werden – welche in einer Tabelle
die Usernamen und deren offene Tickets zur direkten Bearbeitung anzeigt – oder eine Anzeige der Anzahl der
offenen Tickets direkt in den Userdaten (entweder automatisch oder nach dem Drücken des Buttons)
Reiter Gruppe: Suche nach Gruppenname, OE, Area, Level, Division – sowie anzeige der neuen Spalten.
13) Bisherige Entwicklungen
Die bereits durchgeführten Entwicklungen, so Multi-Attachment und „Lösungsfeld/Kommentarfeld“ müssen auf dem E-
/K-P-System ausgebracht werden.
Staging-Verfahren
Die Entwicklung findet auf dem E-System statt. Ein fertiggestelltes Entwicklungspaket/-inkrement wird im
Repository bereitgestellt. Ein solches Inkrement umfasst:
- Notwendige Software
- Dokumentation des Pakets (Fachliches Beschreibung, technische Beschreibung der Umsetzung und bei MidTier-
Änderungen die Liste von veränderten Dateien)
- Installationsanleitung
Auf dieser Grundlage wird das Entwicklungspaket auf das K-System zur Prüfung überführt. Nach erfolgreichem
Test auf dem K-System wird das P-System mit dem Entwicklungspaket versorgt. Sollte die Prüfung nicht
erfolgreich sein, so muss ein neues Entwicklungspaket bereitgestellt werden. Sollten aus einen zu vorigen
Entwicklungspaket auf dem K-System ein Missstand entstanden sein, so muss ein entsprechendes Paket
bereitgestellt werden, dass dies bereinigt. Nicht mehr benötigte Dateien sind zu entfernen bzw. muss über die
Installationsanleitung beschrieben werden, wie die Dateien zu entfernen sind.
Skills:
BMC Remedy ITSM Suite: Fortgeschrittene K.