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

Präsentation zum Thema: "Office@Huebsch.at http://AMW.huebsch.at SW Release Management Office@Huebsch.at http://AMW.huebsch.at © Ing. Arnold Hübsch 2006."—  Präsentation transkript:

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

2 © 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)  ©

3 © 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  ©

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

5 Produkt wird geliefert Projekt ausgearbeitet
MSF Projektzyklus Produkt wird geliefert  Release Ziel festgelegt Freeze Baseline Projekt ausgearbeitet ©

6 Magisches Projekt Dreieck
Abhängigkeit  Ressourcen Zeit Features Magisches Projekt Dreieck ©

7 © 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  ©

8 © 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  ©

9 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 ©

10 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  ©

11 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 ©

12 © 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  ©

13 Vorschlag Produkt Doku
Produktverzeichnis am Server Produkt Infos Prod 1 Daten  Prod 2 Doku Prod 3 Support Info ©

14 © 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  ©

15 Danke für Ihre Aufmerksamkeit
©

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

17 © 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  ©

18 © http://AMW.huebsch.at 2006
Reparaturen DB  ©