Produktlebenszyklen verlängern

Wenn Umsatzbringern plötzlich die Luft ausgeht

Seite: 2/3

Anbieter zum Thema

Lifecycle Extension Strategy

Man hat nun drei Möglichkeiten: Man läßt das Produkt auslaufen, verzichtet damit aber auf Umsätze und Marktanteile oder man bringt schnell einen Nachfolger auf den Markt, geht damit aber ein unkalkulierbares Risiko ein wenn die Entwicklung übereilt abgeschlossen wird. Die dritte Möglichkeit ist, durch eine geeignete Strategie den Lebenszyklus des Produktes zu verlängern und sich so die notwendige Zeit zu verschaffen, einen Nachfolger marktreif zu entwickeln.

Bildergalerie

Hardwareentwicklung oft besser dokumentiert

Meist geht mit der Aktualisierung des Produktes eine Revision der Hardware einher. Dies ist erfahrungsgemäß entweder notwendig, um End-of-Life-Komponenten zu ersetzen, oder um modernere, leistungsfähigere Bauteile einzusetzen, die mehr Speicherkapazität oder höhere Rechenleistung bieten, und so die Implementierung neuer bzw. verbesserter Produktfeatures ermöglichen.

Was jedoch immer notwendig wird, ist ein gründliches Redesign der Software. So muss die Firmware auf neue Komponenten und meist eine neue Hardwarerevision angepasst werden, was oftmals einen erheblichen und unterschätzten Aufwand bedeutet. Denn anders als bei Hardwareentwicklungen ist im Softwarebereich die vorhandene Dokumentation erfahrungsgemäß eher dürftig und der Code ist nur schwer zu entschlüsseln.

Je nachdem, wie lange ein Produkt bereits auf dem Markt ist, kommt hinzu, dass vielfach die Mitarbeiterinnen und Mitarbeiter, die die Software seinerzeit entwickelt haben, nicht mehr im Unternehmen sind. Dadurch ist in der Zwischenzeit viel Wissen über die Architektur verloren gegangen.

Phase 1: Reverse Engineering

Oft funktioniert eine Gerätegeneration über lange Zeit problemlos, allerdings weiß niemand im Unternehmen mehr wirklich, wie genau die Software eigentlich funktioniert. Um die Software aber an eine neue Hardware anzupassen oder ein neues User Interface zu installieren, muss die Funktionsweise bekannt sein.

Hier wird man um Reverse Engineering nicht umhinkommen, denn das ‚neue‘ Gerät soll sich ja genauso verhalten wie das bisherige (siehe Bildergalerie, Bild 1).

Phase 2: Das Redesign

Die Ergebnisse dieses Reengineering wiederum sind der Input für die zweite Phase, das Software-Redesign. Dieser Input bestimmt die technischen Anforderungen. Dabei ist es sehr wichtig, auch die nicht-funktionalen Anforderungen im Blick zu behalten: Testbarkeit, Wartbarkeit, Bedienbarkeit, Dokumentation, etc.

Diese Anforderungen bestimmen dann die Architektur und das Design der neuen Software. Dies ist auch der Moment, an dem eventuell neue Anforderungen hinzugefügt werden können, die dann in die neue Software einfließen.

(ID:43645772)