Wie kann ich das Lebensende der Webanwendung bestimmen? [abgeschlossen

Question

Diese Frage könnte viele Meinungen auf den Tisch bringen, aber was ich gerne bekommen werde, ist eine Reihe von Maßnahmen, die mir und meinem Unternehmen helfen, das Ende eines Produkts zu bestimmen, das wir verkaufen.

Wir verkaufen ein CMS-System, mit diesem System erstellen wir einige Unterprodukte

• Websites
• Vorschlagschöpfer
• Marketing -Kampagnen -Tracker

Wir sind bereit, unsere Straßenplanung (für 2010 und 2011) zu beginnen, und versuchen zu finden, wann das Ende der Lebensdauer unserer Bewerbung sein wird. Einige von Ihnen denken vielleicht, dass eine sehr gut architektierte Anwendung (Ich glaube nicht, dass unsere Bewerbung gut architektiert ist) Muss kein Lebensende haben, aber diese App, die wir verwenden, reicht von mindestens 6-7 Jahren zurück und hat fast keine Dokumentation (wirkliches Leben). In diesem Moment weiß nur eine Person, wie man die Kernfunktionalität (beängstigend) verändert.

Bitte Ratschläge,

Geo

---

Dank an alle! Ich schätze Ihre Kommentare, Meinungen und Gedanken zu diesem Thema sehr.

Ich werde einige der Post -Back -Fragen in der folgenden Liste besprechen

• Es gibt einen Entwickler, der die Kernfunktionalität unseres Produkts aufrechterhalten kann. (nur und nur eins)
• Es gibt zwei Entwickler, die die Funktionalität auf einen bestimmten Punkt erhöhen können. Beide Entwickler sind durch die Grenzen des Kernprodukts eingeschränkt, und beide müssen innerhalb dieser Grenzen arbeiten.
• Eine sehr wichtige Anmerkung. Das Produkt, das wir in Betracht ziehen, wird größtenteils von einem Auftragnehmer gebaut. Der Auftragnehmer ist der einzige Entwickler, der die Kernfunktionalität aufrechterhalten kann. Wir entwickeln uns nur noch im Rahmen des Auftragnehmers.

Ich werde weiterhin Antworten hinzufügen, während ich Ihnen alle Antworten lese.

Answer 1

Da die Anwendung sehr gut architektiert ist, möchten Sie sie möglicherweise nicht in den Ruhestand treten und alle Investitionen verlieren, die Sie bisher getätigt haben.

Hier sind meine Vorschläge:

• Lassen Sie einen Junior -Entwickler diesem aktuellen Entwickler beibringen.
• Füllen Sie die meisten zukünftigen Updates zum Junior Developer (mit Unterstützung des SR. Entwickler)
• Bitten Sie Junior Developer, die Dokumentation seiner Arbeit zu erstellen
• Bitten Sie Sr. Developer, die Dokumentation zu überprüfen

Im Laufe der Zeit haben Sie eine andere Person, die diese Anwendung unterstützen kann und sie wird ebenfalls dokumentiert. Jetzt müssen Sie Ihre eigene, sehr gut architektierte Anwendung mit Ihren eigenen Händen nicht töten.

.

Die Erweiterung dieser Lösung mit Jefferey -Vorschlag unten ("Manchmal ist das Umschreiben eine gute Investition.")

Wenn Sie weiterhin die aktuelle Anwendung fallen lassen und sie neu schreiben möchten, müssen Sie weiterhin vorhandenes System dokumentieren und Anforderungen für ein neues System erstellen, das darauf basiert.

Mithilfe der Dokumentation des aktuellen und vorgeschlagenen Systems möchten Sie möglicherweise feststellen, ob Sie inkrementell nach Modul-Upgrade (Re-Write) -Komponenten (Modul Upgrade) können. Dies ist möglich, wenn die Anwendung sehr gut architektiert ist.

---

Gemäß Ihren (Geo-) Kommentaren

Die Organisation von GEO verfügt über eine CMS-Anwendung von Drittanbietern (mit nur einem Vertragsentwickler), das unter den Geschäftsanforderungen implementiert wird und die Lizenzgebühr für die Unterstützung und Verwendung seines Kodex zahlt.

• Geschäftsanforderungen für CMS
• Websites
• Vorschlagschöpfer
• Marketing -Kampagnen -Tracker

Hier sind meine Vorschläge

• Erstellen Sie das Modul nach Modul Detaillierter Anwendungsfalldokument für dieses Projekt. Ihr Entwickler kann dies tun oder ist ideal, um einen separaten Geschäftsanalysten für denselben zu haben.
• Mieten Sie einen Sr. -Entwickler, um zu bewerten, ob Open -Source -CMS alle oder die meisten Ihrer Anforderungen (z. B. Joomla, Drupal usw.) behandeln kann.
• Das Wichtigste ist hier, um Ihre vorhandenen Daten in ein neues System zu migrieren. Sie benötigen möglicherweise Hilfe von Ihrem vorhandenen Vertragsentwickler, um dies zu tun.
• Möglicherweise müssen Sie den Geschäftsprozess oder Workflow aktualisieren, um ein neues System zu verwenden.
• Module, die mit Open Source CMS nicht implementiert werden können, müssen möglicherweise über benutzerdefinierte Website implementiert werden.

Ein Großteil davon hängt auch von Ihrem Geschäftsbeziehung mit dem bestehenden Vertragsentwickler und der Lizenzvereinbarung ab. Was Sie ausgesetzt sind, ist ein Verkäuferschloss im Szenario. Möglicherweise möchten Sie Lösungen weiter recherchieren, um diese Anbietersperrung in der Situation zu beseitigen.

Answer 2

Dies ist nur meine Meinung, aber wenn dies ein Produkt ist, das Sie verkaufen, dann läuft alles auf Geschäftsaussichten hinaus. Wenn das Produkt nicht verkauft wird, lassen Sie es fallen. Wenn das Produkt eine Zukunft hat, investieren Sie in es und machen Sie es zur besten Software, die Sie durch Wiederieren, Umschreiben oder was auch immer Sie tun müssen. Wenn Sie loyale Kunden oder eine starke Marke haben, ist es wert, geschützt zu werden.

Manchmal ist es eine gute Investition, das Ganze in einer anderen Technologie neu zu schreiben, wenn die aktuelle Software ein erfolgreiches Design hat, das kopiert werden kann, eine starke Marke hat und wenn sie richtig gemacht werden kann.

Answer 3

Die Anwendung erreichte das Ende des Lebens, sobald sie ohne jegliche Art von Dokumentation versandt wurde. Beginnen Sie jetzt mit der Entwicklung, und Sie möchten möglicherweise in Betracht ziehen, die Person zu ersetzen, die das ursprüngliche System kennt. Wenn sie 6/7 Jahre gegangen sind, ohne irgendeine Art von Dokumentation zu erstellen, sind sie nicht jemand, den Sie in Ihrem Unternehmen haben möchten.

Answer 4

Die einzige Art von Dokumentation, die das Leben Ihres Systems erweitert, sind Dinge, die konsistent bleiben, wenn sich das System in seiner Lebensdauer ändert, wie Testsuiten, selbstdiagnostische Tools, Code-Kommentare, deklarative Verträge wie Schnittstellen und automatisch generierte Dokumentation.

Andere manuell verwaltete Dokumentationsartefakte wie Handbücher, Entwicklerleitfäden, Architekturdokumente und Datenformate werden tendenziell im Verhältnis zur Menge der Dokumentation veraltet. Ich würde diese nicht als Faktoren zählen, die die Lebenserwartung Ihrer Anwendung erhöhen, es sei denn, Sie haben bereits die Kosten für die Wartung berücksichtigt.

Wenn Sie sich Entwicklerreduktion nicht leisten können, um den Antrag zuverlässig zu halten, können Sie es sich nicht leisten, die Dokumentation auf dem neuesten Stand zu halten. Mangelnde Dokumentation ist wirklich eine technische Schuld, die Sie vielleicht unbewusst entschieden haben. Wenn ein längerer Lebenszyklus eine Voraussetzung ist, müssen die Kosten dazu berücksichtigen, diese Anforderung zu erfüllen.

Answer 5

Um eine lange Geschichte kurz zu machen: Ich bin in einer vergleichbaren Situation.

• Solange dieser Antrag so etwas wie ein Cashcow ist, aber das Unternehmen kann es sich nicht leisten (oder beabsichtigen), eine neue Anwendung zu entwickeln. Es wird nicht sterben, bevor die Kunden ein frischeres System kaufen.

• Das Umschreiben ohne (dokumentierte) Anforderungen ist fast unmöglich.

• Zumindest sollte die Erfahrung spezialisierter Abteilungen auf eine Weise dokumentiert werden, die für weitere Entwicklungen nützlich ist.

• Wenn Sie diese Anwendung beibehalten müssen, sollten Sie Schnittstellen zwischen Modulen einführen, um die Gesamtkomplexität zu verringern. Also alte Module, egal wie Messie sie sind, ist es egal, ob Sie neue Funktionen platzieren müssen.

Answer 6

Auch wenn es sehr gut gestaltet und funktionsfähig ist, bedeutet die Tatsache, dass es keine Dokumentation hat und von einer Person für sein Leben abhängt, das Produkt in einen nicht wachsamen Zustand eingetreten. Dies ist kein gutes Zeichen. Ich würde zustimmen, dass das Produkt über das "Ende des Lebens" hinaus läuft ist

Answer 7

Dies sind die Art von Dingen, die ich bei der Entscheidung berücksichtigen könnte, ob ein System möglicherweise "Ende des Lebens" geht:

Ist die Funktionalität, die dieses System Endbenutzern in einem billigeren, zuverlässigeren oder einfacheren Gebrauchsformular zur Verfügung stellt? Wenn nicht jetzt, wann ist das wahrscheinlich? Ist dieses Produkt längerfristig lebensfähig?

Ist dies in einer Technologie geschrieben, von der die Kunden weggehen würden, da es unangenehm wäre, in ihre Produkte zu versetzen, oder sie verlangen, dass sie "veraltete" Plattformen ausführen? Würde es einem potenziellen Kunden den Eindruck geben, dass Ihr Unternehmen ist bedeutend Hinter der Zeit, z. B. VB6 ist wahrscheinlich noch in Ordnung, selbst im Jahr 2010, aber die Gewinn16 -Kompatibilität ist es wahrscheinlich wahrscheinlich nicht.

Können Sie gute Leute einstellen, die die zugrunde liegende technische Plattform zu angemessenen Kosten kennen? Bei älteren Technologie gibt es vielleicht, dass es viele Menschen gibt, die die Plattform kennen, sie aber als Sackgasse ansehen und ein Prämiengehalt bitten werden, wenn ihre Karriere in der Flaute schmachten wird, während sie daran arbeiten.

Wenn es Ihnen wichtig ist, wird die Entwicklungsplattform immer noch vom Anbieter unterstützt? Werden Sie eingeschränkt werden, auf welcher Hardware oder des Betriebssystems Sie es ausführen können, wenn der Anbieter sie nicht mehr aktualisiert? Gibt es in der Plattform, die möglicherweise aktualisiert werden müssen? Selbst Nischen -Open -Source -Produkte können darunter leiden. Sobald ein Produkt in Anspruch genommen wird und die Kernentwickler zu neuen Projekten wechseln, kann es schwierig sein, Korrekturen durch die Community abzuhalten.

Wenn es unterstützt wird, berechnen Sie dann die Anbieter eine Prämie für die Unterstützung einer älteren Plattform? Wenn nicht jetzt, wie lange dauert es, bis sie es tun?

Wie schwierig ist es, neue Technologien in sie zu integrieren, um den Endbenutzern aktuelle Trends zu nutzen, die angereicherte Funktionen bieten, um Sie wettbewerbsfähig zu halten? Kümmerst du dich darum? Es ist möglicherweise keine Rolle, ob Sie im Wesentlichen ein geschlossenes System ausführen.

Wie schwierig ist es, funktionale Veränderungen ohne umfangreiche "Schrotflinte" -Dänderungen zu veröffentlichen, die sich über das gesamte System rücken? Dies kommt darauf zurück, wie modular das System in erster Linie ausgelegt war. Wenn Sie nicht schlechter sind, als Ihre Konkurrenten auf dem Markt zu Funktionen zu kommen, sind Sie wahrscheinlich in Ordnung.

Was wäre die Kosten für das Wiederumschreiben des Systems? Wie ist dies im Vergleich zu wie viel billiger, um Einnahmen zu erhalten oder zu steigern? Es ist möglicherweise nicht wirtschaftlich machbar, eine ganze Umschreiberin durchzuführen. Wenn die Entwicklungsplattform solide ist, können Sie einfach mehr einen Refactoring -Ansatz ausprobieren. Hier hilft eine gute Test-Suite und eine gute Dokumentation.

Answer 8

Ich habe einen ähnlichen Prozess durchlaufen. Wir hatten eine Web -App, die fast 8 Jahre lang ausgeführt wurde. In dieser Zeit wurde viel Wartung erledigt und sie auf eine Weise erweitert, die wir uns nicht vorgestellt hatten. Der Kern war jedoch gut und es konnte immer noch gedehnt werden.

Was uns überschritten hat, waren die Wartungskosten. Menschen mit den richtigen Fähigkeiten zu finden, war vor 8 Jahren einfach. Heute möchte niemand in diesen Umgebungen arbeiten. nicht einmal wir :)

Nach der Analyse wussten wir, dass wir es innerhalb von 12 Monaten durch identische Funktionalität ersetzen konnten und dass sich diese Zeit schnell auszahlen würde.

Wir haben also Screenshots als funktionale Anforderungen verwendet, das Erscheinungsbild überarbeitet und konnten sogar erhöhte Funktionen liefern. Wir haben uns auch Verwendungsdaten angesehen, um Teile zu identifizieren, die entweder selten oder nie verwendet wurden, und diese beschnitten und mehr Aufmerksamkeit auf die verwendeten Teile richteten.

Letztendlich waren wir erfolgreich. Zum Teil, weil alle im Team mit der neuen Technologie gut vertraut waren, so dass es wenig Lernen benötigte. Weitere Faktoren waren ein gut durchdachtes Design. Ich denke, wir haben 3 Monate im Design verbracht, bevor wir etwas geschrieben haben.

Der letzte Faktor war, dass unsere App modular ist. Daher konnten wir es in Größen, die klein genug sind, um eine Kombination aus kurzen Lieferplänen mit einer Ausfallzeit / Analysezeit zwischen den einzelnen Lieferungen zu haben. Dies stellte sicher, dass wir in jeder Phase auf dem richtigen Weg waren.