|
Automatisierung und heterogene Systeme
|
Schnittstelle zwischen Open View Service Desk von Hewlett
and Packard (HPSD) und IBM Rational Change |
In großen oder wachsenden Umgebungen entstehen heterogene
System-Landschaften.
Der Aufwand für eine Vereinheitlichung oder Zusammenführung
derartiger Systeme kann einerseits hohe Aufwände generieren
und anderseits ist dieser Schritt aus der Prozesssicht des
Unternehmens nicht immer gewünscht. Hierbei ist die
Implementierung einer Schnittstelle zwischen den
unterschiedlichen Systemen zur Automatisierung und
Vereinheitlichung eine gute Lösung.
Beide Systeme sind in dem Unternehmen großflächig zum
Einsatz gekommen.
HPSD wird als das zentrale IT-Service Managementwerkzeug im
Produktionsbetrieb und IBM Rational Change im Bereich des
Managements der Änderungen (Changes) im Software LifeCycle
eingesetzt.
- Konzeption und Implementierung einer
Schnittstelle zwischen HPSD und IBM Rational
Change
- Der HPSD-Anwender soll die Möglichkeit
haben, im Incident in HPSD einen Change
Request (CR) in Change „near real-time“ zu
erzeugen
- Erhöhung des qualitativen Nutzens durch
Wegfall von manuellen Übertragungsaufwänden
der Incidents-Inhalte von HPSD nach IBM
Rational Change
- Unterbindung der unterschiedlichen
Eingabe-Variationen wegen der manuellen
Eingabe durch Benutzer
- Performante Auswertung und Analyse der
Anforderungen und Meldungen auf der
Zielsystem-Seite
- Vereinheitlichung der Prozessabläufe der
beiden Systeme
Funktionsweise:
Der HPSD Benutzer kann bei Bedarf durch „Knopfdruck“ nach
Erzeugung eines Incidents einen entsprechenden Change
Request (CR) in IBM Rational Change erzeugen. Die
Schnittstelle arbeitet projektspezifisch. Das bedeutet, dass
für unterschiedliche Change Instanzen eigene Vorgehensweisen
definiert werden können.
Bei der Erzeugung werden alle relevanten Daten, basierend auf
vordefinierten Mapping-Strukturen, übertragen. Hierbei sind
Vorbelegungen für bestimmte Attribute möglich. Die erzeugte
HPSD-Nummer wird in Change und die Change Request Nummer in
HPSD gespeichert. Somit entsteht eine Relation zwischen
Incidents und Change Requests. Anhand definierter Regeln
wird die Weiterverarbeitung des Ticktes bzw. Change Request
gesteuert. Wenn z.B. sich der Status des CR bei der
Bearbeitung ändert, muss der geänderte CR-Status in den
Incident übertragen werden.
Attribut- und Werte-Mappings und der Prozessablauf sowie die
Ansteuerung von Ziel-Installationen sind ohne
Code-Änderungen erweiterbar und konfigurierbar.
Die Anbindung wird seit Einführung von immer mehr
Entwicklungsprojekten in dem Unternehmen nachgefragt. Die
Lösung wurde ursprünglich für Telelogic Change Synergy
entwickelt und auf Telelogic Synergy Change bzw. IBM
Rational Change migriert.
|
|
Automatisierung von Build-Prozessen und Deployment in
J2EE-Plattformentwicklungen |
Durch gesetzliche Vorgaben und weitere Auflagen der
Innenrevision entstehen besondere Anforderungen bzgl. der
Nachvollziehbarkeit der Software-Projekte.
Software-Entwicklungsprozess sollen weitgehend automatisiert
sein, um eine durchgängige Nachvollziehbarkeit gewährleisten
zu können.
Alle modulgetesteten Änderungen werden automatisch in die
Integration übernommen. Nach erfolgreichem Build werden die
Erzeugnisse in die nächsten Stufen wie fachliche
Testumgebungen und Verbundtestumgebungen übertragen. Nach
erfolgreichem Test erfolgt der Rollout nach Produktion.
Projektziele:
- Steigerung der Effizienz von
Entwicklungsprozessen,
- Vermeidung von Fehlern, die durch
manuelle Schritte entstehen,
- Die Wiederherstellung eines Builds,
- Zu jeder Zeit muss die Frage beantwortet
werden können, welche Konfiguration der
Software zu welchem Zeitpunkt in Produktion
gewesen ist.
- Vereinheitlichung des
Deployment-Prozesses.
- Vereinheitlichung der Prozessabläufe der
beiden Systeme
|
|
