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.
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)