Office@Huebsch.at http://AMW.huebsch.at SW Release Management Office@Huebsch.at http://AMW.huebsch.at © Ing. Arnold Hübsch 2006

© http://AMW.huebsch.at 2006 Themen Problemstellung Projekt Development Time Pushing Methode SW Release Management Nummernvergabe Bedeutung Dokumentation Versionsdokumentation Support Historie Reparaturliste (falls dazu Zeit bleibt)  2006 07 25 © http://AMW.huebsch.at 2006

© http://AMW.huebsch.at 2006 Probleme Produktversionen geraten durcheinander Kunden kennen sich nicht aus Nummernplan ist inkonsistent Release Datum von Produkten halten nie Nummerierung und Abhängigkeiten erzeugen zusätzliche Verzögerungen Service kann Versionen nicht zuordnen Funktionalität und Version unklar Mehrfach Vergabe von Versionsnummern Nummernplan lässt Ergänzungen nicht zu  2006 07 25 © http://AMW.huebsch.at 2006

© http://AMW.huebsch.at 2006 Projektzykluskreis Planung und Design  Realisierung Programmierung Nutzung Betrieb 2006 07 25 © http://AMW.huebsch.at 2006

Produkt wird geliefert Projekt ausgearbeitet MSF Projektzyklus Produkt wird geliefert  Release Ziel festgelegt Freeze Baseline Projekt ausgearbeitet 2006 07 25 © http://AMW.huebsch.at 2006

Magisches Projekt Dreieck Abhängigkeit  Ressourcen Zeit Features Magisches Projekt Dreieck 2006 07 25 © http://AMW.huebsch.at 2006

© http://AMW.huebsch.at 2006 Projektmethode Es gibt kein Ende eines Projektes Ein Projekt mündet in der nächsten Release … oder in einem ablösenden Produkt Bei Zeit und Ressourcenmangel werden Features in die nächste Release geschoben Kunde sieht laufenden Projektfortschritt Features laufen nicht ineinander, verhindert Versionsabhängigkeitsprobleme  2006 07 25 © http://AMW.huebsch.at 2006

© http://AMW.huebsch.at 2006 Time Pushing Time Pushing priorisiert das Release Datum Wenn Ressourcen fehlen werden Features in die nächste Version geschoben Releasedatum kann eingehalten werden Kundenerwartungen zumindest Terminlich erfüllt werden Verlässlichkeitseindruck steigt Abhängigkeiten zu anderen Projekten können besser koordiniert werden Keyfeatures werden priorisiert „Nice to have Features“ wandern im Krisenfall in die nächste release Beispiel: MX1 <-> Fahrpult  2006 07 25 © http://AMW.huebsch.at 2006

Planning the Solution Was der Anwender wollte Was der Analyst als Bedarf verstanden hat Das hätte dem Anwender auch gereicht Die Design Vorgaben Das wurde schließlich implementiert 2006 07 25 © http://AMW.huebsch.at 2006

SW Release # Managemenmt Die Releasenummern sollten Aussagekraft haben Nummernplan muss konsistent sein über alle Produkte Vorschlag: 1. Stelle für Hauptreleases große Featureänderungen 2. Stelle für laufende Ergänzungen die Feature Zuwachs bringen 3. Stelle um Maintenance Releases unterscheiden zu können 4. Stelle ausschließlich zur internen Verwendung Developper Releases diese soll kein Kunde zu Gesicht bekommen  2006 07 25 © http://AMW.huebsch.at 2006

SW Release Managemenmt Beispiel ZST Version 1.62 (5) Variante brachte MX31 Sprachsupport 1.5x brachte MX31 Download Support „unsichtbare“ Nummer um Entwicklungsversionen zu unterscheiden. Somit als interne Release leicht zu erkennen Hauptversion  Subrelease hat Fehler behoben Nur Kleinigkeiten an neuen Features 2006 07 25 © http://AMW.huebsch.at 2006

© http://AMW.huebsch.at 2006 Freigabe Der Entwickler gibt Produkte frei Erkennbar an Bezeichnung Dokumentation der Version kurzer Begleittext der aufgehoben wird Support dokumentiert Fehler Support und Entwickler dokumentieren Fehlerbehebung Alle Infos zu einer Release an EINEM definierten Platz Kristallisationspunkt für neue Features  2006 07 25 © http://AMW.huebsch.at 2006

Vorschlag Produkt Doku Produktverzeichnis am Server Produkt Infos Prod 1 Daten  Prod 2 Doku Prod 3 Support Info 2006 07 25 © http://AMW.huebsch.at 2006

© http://AMW.huebsch.at 2006 Knowledge Base Ausschließlich für interne Personen Externer Support über WEB Seite Telefon ZIMO Forum Zugriff über Chaossuche auf die Produktinformations Verzeichnisse Vermeidet Formpflichten die eeh nicht eingehalten werden Mechanismus WEB Suche Support Info allgemein zugänglich Developper werden von Support entlastet Support‘er weiß wo es Infos gibt Support für weniger übliche (alte) Produkte möglich Ende der Diskussionen über Info Fluss Weniger Arbeitsaufwand für den Einzelnen, Infos sollen möglichst einfach abzulegen sein Vorschlag Textfile Funzt nur wenn alle dazu beitragen … und Infos die als Mail kommen eingestellt werden  2006 07 25 © http://AMW.huebsch.at 2006

Danke für Ihre Aufmerksamkeit 2006 07 25 © http://AMW.huebsch.at 2006

© http://AMW.huebsch.at 2006 Reparaturen DB Infobasis EXCEL File Perl  2006 07 25 © http://AMW.huebsch.at 2006

© http://AMW.huebsch.at 2006 Reparaturen DB Dokumentiert den Zustand Nichts Neues Lebt von den Daten die eingegeben werden Zeilen lassen sich ausblenden heikle Zeilen in DB aber nicht am WEB Anfragen von Händlern und Kunden fallen weg Verzögerungen werden Sichtbar Begründung kann eingegeben werden Reparaturaufkommen wird von außen sichtbar Qualitätsvorteil für den Anwender ZIMO hat nichts zu verbergen Einträge altern und werden ausgeblendet  2006 07 25 © http://AMW.huebsch.at 2006

© http://AMW.huebsch.at 2006 Reparaturen DB  http://salm.huebsch.at/RepReport/Reparaturstatus.pl 2006 07 25 © http://AMW.huebsch.at 2006