Erste Eingrenzung des „Release“-Begriffes

Es ist erstaunlich, dass man viele Bücher zu Frameworks, die „Release-Management“ als einen wichtigen Prozess beschreiben, lesen kann, ohne eine zufriedenstellende Definition des Release-Begriffes vorzufinden. Auch ich werde mich dem Release-Begriff in diesem Blog nur schrittweise nähern. Ein erste Mindmap für diesen Prozess ist nachfolgend dargestellt:

Um aber in kommenden Beiträgen nicht vollständig im luftleeren Raum zu argumentieren, werde ich mal eine erste Eingrenzung des Begriffs vornehmen. Dabei orientiere ich mich an folgenden Gedanken:

  • Ein Release ist nicht identisch mit einem konkreten Produkt – auch wenn im Jargon von SW-Entwicklern oft eine solche Gleichsetzung erfolgt.
  • Releases beziehen sich auf Ergebnisse konkreter Arbeits- und Entwicklungsprozesse.
  • Releases beziehen sich auf Produkte mit definierten und erwarteten Eigenschaften.
  • Es kann mehrere konkrete Produkte zu einem Release geben.

Warum betone ich den ersten Punkt? Nun, ich werde immer etwas allergisch, wenn mir Entwickler erzählen, sie hätten nun ein Release einer SW in den operativen Betrieb überführt. Haben sie nicht! Vielmehr haben sie meist ganz konkrete SW-Dateien auf definierten IT-Systemen installieren lassen (und einiges mehr).

Sie haben ein konkretes SW-Produkt implementiert. Dass ich ein Produkt mit den gleichen Eigenschaften zig-fach reproduzieren kann, liegt gerade bei SW auf der Hand. Niemand würde aber sagen, dass eine solche Kopie in irgendeiner Form ein anderes Release darstellen würde. Die Gleichsetzung von SW und Release hat daher – wenn überhaupt – nur eine abstrakte Bedeutung.

Als Kunde erwarten wir, dass ein vermarktetes SW-Produkt bestimmte versprochene Eigens­chaften erfüllt. Denken wir genauer nach, so erwarten wir sogar, dass alle Produkte zu einem „Release“ die gleichen Eigenschaften aufweisen. Kaufen wir ein SW-Produkt zweimal und installieren es auf zwei Endgeräten, so wollen wir keine Abweichungen in der Benutzeroberfläche und in der angebotenen Funktionalität sehen.

Nun möchte ich einen künftigen Release-Begriff von vornherein nicht auf SW eingrenzen. Lösen wir uns von SW, so erkennen wir, dass generelle Produkte mit bestimmten definierten Eigenschaften auch definierte Produktionsprozesse erfordern, die diese Eigenschaften erzeugen.

Releases beschreiben also eher eine bestimmte Klasse von Produkten, die ggf. über wohl definierte Produktionsprozesse und anhand von Schablonen erzeugt werden. Offenbar kann es sogar verschiedene, ggf. unterschiedlich effektive Prozesse geben, die ein release-konformes Produkt erzeugen. Ich komme zu folgender ersten Eingrenzung des Release-Begriffes:

Releases beschreiben Produktvarianten mit definierten Eigenschaften und ggf. mit einem daraus abgeleiteten definierten Funktionsumfang. Alle Produkte, die dieser Variante zugeordnet sind, weisen identische Eigenschaften auf. Diese Eigenschaften sind überprüfbar – u.a. anhand eines Anforderungskataloges.

Releases ziehen eine Klasseneinteilung konkreter Produkte nach sich: Ein einzelnes Produkt gehört entweder zu einer Klasse oder nicht.

Dieser Blog verwendet Cookies. Bei weiterer Nutzung gehen wir von Ihrem Einverständnis aus. Optionen/Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen