Was verbindet viele große Multinationale Konzerne mit Paketierern an verschiedenen Standorten, mit ebenso vielen Mittelständischen Unternehmen in denen die Paketierleistung durch ein kleines 2-Mann Team gestemmt wird? Es passieren Fehler. Es wird wenig bis gar nichts dokumentiert. Übergaben funktionieren oft nicht. Abteilungsübergreifendes Arbeiten an Paketen erinnert mehr an Krieg als an Zusammenarbeit, Testprozesse (nur der User weiß, wie die Anwendung funktionieren muss) ist eine Farce. Natürlich ist dies nicht die Regel, aber einige der genannten Punkte sind sicherlich in fast jedem Unternehmen wiederzufinden.

All diese Dinge lassen Sich selbstverständlich nicht mit einem Tool, einer Liste, einem neuen Projektleiter, anderen Software oder mehr Hardware aus der Welt schaffen, sondern die erfolgreiche, qualitativ hohe zur Verfügung-Stellung einer Anwendung hängt an vielen Faktoren. Nichtsdestotrotz, sind die richtigen Werkzeuge definitiv sehr hilfreich. Ein neues Werkzeug möchte ich nun in diesem und einigen folgenden Blogs vorstellen: Die „Packaging.Docs“, eine Sammlung von Dokumenten die den gesamten Paketierungsablauf begleiten und in einigen der ohne genannten Problemfällen versuchen, Abhilfe zu schaffen.

Bevor es mit der Paketierung wirklich richtig losgeht, sollte sich der geneigte Projektleiter allerdings Gedanken machen, was eigentlich zum Firmen-internen Prozess der Software-Inbetriebnahme gehört. Ich möchte mal einige Punkte auflisten:

1. Stellen der Anforderung

2. Auswahl der „richtigen“ Software

3. Beschaffung

4. Zusammenstellen aller notwendigen Informationen und Dokumentieren aller Schnittstellen

5. Paketierung

6. Test / Qualitätssicherung

7. Pilotierung

8. Inbetriebnahme / Rollout

9. Wartung

10. Außerbetriebnahme

Überrascht? 10 Punkte (und ich bin sicher, es gibt in manchen Unternehmen noch deutlich mehr) um eine Software einem User zur Verfügung zu stellen? Nun, wie schon eingangs erwähnt, egal ob ein 2 Mann Team alles macht, oder jeder einzelne Schritt durch eine eigene Abteilung durchgeführt wird, man kommt nicht drumherum, in der einen oder anderen Form über die meisten dieser Schritte zu gegebener Zeit nachzudenken.

Geht ein IT-Verantwortlicher alle dieses Schritte einmal durch, wird er feststellen, dass der Softwareintegrationsprozess eine ganze Menge Fehlerpotenzial enthält. Die „Packaging.Docs“ können natürlich nicht die gesamte Prozesskette beleuchten und wie der Name schon sagt: Die „Packaging.Docs“ betrachten natürlich ausschließlich die Rand-und Kernbereiche der Paketierung.

Starten möchte ich nun mittendrin, mit dem Schritt 5: Der Paketierung als solches. Vor allem aus dem Grund, weil ich in den letzten 2 Jahren am meisten Zeit damit verbracht habe, zu erläutern wie Pakete umgebaut werden müssen, damit Sie Qualitativ hochwertig unter Berücksichtigung aller sich auf tuenden Herausforderungen der Zukunft funktionieren werden.

Die „Packaging-Checkliste“ (als PDF Formular weiter unten zum Download verfügbar) ist ein reines Werkzeug für den Paketierer. Er hat die Möglichkeit diese Liste (online, oder in Papierversion) nach und nach zu vermerken, welche Punkte seines Paketes er schon erledigt hat und teilweise auch wie er diese Punkte umgesetzt hat. Eine solche Checkliste bietet folgende Vorteile:

• Die Ausfüllen dieser Liste erfordert max. 10 Minuten zusätzliche Zeit.

• Die Checkliste erspart häufig die Überarbeitung der Pakete um Fehler zu korrigieren (Was i.d.R. mehr als 10 Minuten Zeit beansprucht).

• Der Paketierer kann die Arbeit an einem Paket auch mal unterbrechen und findet relativ schnell wieder in seine Arbeit hinein.

• Die Checkliste dient als Dokumentation des Paketes.

• Übergabeprozesse zwischen verschiedenen Paketierern laufen deutlich besser.

Diese Liste kann natürlich nicht immer zu 100% für alle Umgebungen übernommen werden. Einige Punkte (wie z.B. das Befüllen zusätzlich angelegter Schemaerweiterungen) sind bewusst weich formuliert, eben weil natürlich jeder seine eigenen (oder gar keine) Schemaerweiterungen anlegt.

Bevor ich hier nun die detaillierten Inhalte der Checkliste beschreibe, schlage ich vor, laden Sie das PDF herunter, nutzen Sie es wie es ist, oder nutzen Sie es als Vorlage, um Ihre eigene Version zu erstellen. Als Viewer empfehle ich einen alternativen freien PDF Reader, da der Adobe Reader nicht in der Lage ist, ein PDF Formular inklusive seiner Formularinhalte zu speichern (Adobe setzt hier die Nutzung der kostenpflichtigen Vollversion voraus). Persönlich habe ich sehr gute Erfahrungen mit dem Foxit Reader gemacht.

Änderungswünsche, Positive Kritik aber auch Auswirkungen beim Einsatz dieser Liste sind mir immer als Anhang an diesem Blogeintrag oder als Mail sehr willkommen. Neuere Versionen werden ebenfalls in Rahmen dieses Blogeintrags veröffentlicht.

Die Liste als PDF kann im Donwload-Bereich unter PDF-Pool -> Services -> Paketierungsrichtlinien heruntergeladen werden. Eine Anmeldung ist notwendig.

Änderungshistorie:

2011-06-15

• Aktualisierung des Formulars auf die Version 0.8
• Ändern der Schriftart auf Arial für Kompatibilität mit Windows
• Erweitern der Rebootsteuerung um die Selektion des gewünschten Reboot-Verfahren
• Reparatur Option durch User wurde eingefügt
• Aus den Paketeigenschaft für Reboot wurden die Scriptinhalte entfernt

2011-10-14

• Auslagerung kritischer Werte.
• Auslagerung Zuweisungsabhängiger Werte.
• Ausführungsoptionen grafisch dargestellt.
• Weitere Checkboxen zur Dokumentation der Tätigkeiten wurden hinzugefügt.
• Logfile Konfiguration hinzugefügt.

2012-02-15

• Returncode Auswertung nur noch bei Fehler

• Ausführungsoptionen: RunAs ist ebenfalls eine Ausnahme

• Keine Ablage von Sourcen ausserhalb von Depots

• QS: Installation via Service nicht möglich (Desktop, Userinteraktion)

• Keine "harten Pfade" im Paket

• Sprache der Kommentare in den Kommentaren festlegen.

• Überarbeitung der Kategorien

• Betriebssystemfreigabe in den Paketeigenschaften hinzugefügt