Wie kann das Ende der Lebensdauer einer Webanwendung festgestellt werden?

Question

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

Wir verkaufen ein CMS-System, mit diesem System, das wir

• Websites
• Vorschlag Schöpfer
• Marketing-Kampagne Tracker

Wir sind bereit, zu beginnen unsere einige Nebenprodukte erstellen Straßenplanung (für 2010 und 2011) und wir versuchen herauszufinden, wann das Ende unserer Bewerbung enden wird. Einige von euch denken vielleicht, dass eine sehr gut geplante Anwendung (ich glaube nicht, dass unsere Anwendung gut geplant ist) muss kein Ende des Lebens haben, aber diese App, die wir verwenden, geht mindestens 6-7 Jahre zurück und hat fast keine Dokumentation (echtes Leben). In diesem Moment weiß nur EINE Person, wie man die Kernfunktionalität ändert (gruselig).

Bitte Beratung,

Geo

---

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

I unter

• Es ist ein Entwickler, der fähig ist, die Kernfunktionalität unserer Produkte zu halten einige der Post zurück Fragen in der Liste Adresse. (nur und nur einer)
• Es gibt zwei Entwickler, die in der Lage sind, die Funktionalität bis zu einem bestimmten Punkt zu erhöhen. Beide Entwickler sind durch die Beschränkungen des Kernprodukts eingeschränkt, und beide müssen innerhalb dieser Grenzen arbeiten.
• Eine sehr wichtige Anmerkung. Das Produkt, das wir in Erwägung ziehen, wird zum größten Teil von einem Auftragnehmer gebaut. Der Auftragnehmer ist der einzige Entwickler, der die Kernfunktionalität aufrechterhalten kann. Wir entwickeln uns nur im Rahmen des Auftragnehmers.

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

Answer 1

Da die Anwendung sehr gut entwickelt ist, möchten Sie vielleicht nicht in Rente gehen und verlieren Sie alle Investitionen, die Sie bis heute gemacht haben.

Hier sind meine Vorschläge:

• Haben Sie einen Junior-Entwickler dieses aktuellen Entwickler beitreten.
• Dump die meisten zukünftigen Updates auf junior Entwickler (mit Hilfe von sr. Entwickler)
• Stellen Sie Junior-Entwickler die Dokumentation seiner Arbeit
• Stellen Sie Sr. Entwickler tun Dokumentation

Meinung

Im Laufe der Zeit haben Sie eine andere Person, die diese Anwendung unterstützen kann und es wird auch dokumentiert. Jetzt müssen Sie Ihre eigene, sehr gut geplante Anwendung nicht mehr mit eigenen Händen erledigen.

.

Erweiterung dieser Lösung mit Jefferey Vorschlag unten („Manchmal ist Umschreiben eine gute Investition.“)

Wenn Sie noch aktuelle Anwendung wollen und neu schreiben es fallen zu lassen, müssen Sie noch dokumentieren System vorhandenen und Anforderungen erstellen für neues System basierend darauf.

Unter Verwendung der Dokumentation des aktuellen und des vorgeschlagenen Systems möchten Sie möglicherweise sehen, ob Sie Modul für Modul schrittweise aktualisieren (neu schreiben) können. Dies ist möglich, wenn die Anwendung sehr gut entwickelt ist.

---

Wie pro Ihre (Geo) comments

Geo Organisation hat individuelle Drittanbietern (mit einem und nur einem Auftragsentwickler) CMS-Anwendung, die unter Geschäftsanforderungen implementiert und für die Unterstützung Lizenzgebühr zahlt und Verwendung seines Codes.

• Geschäftsanforderungen für CMS
• Websites
• Vorschlag Schöpfer
• Marketing-Kampagne Tracker

Hier sind Anregungen meiner

• Modul Erstellen von Modul detaillierter Verwendung Fall Dokument für diese p Projekt. Ihr Entwickler kann dies tun oder wäre Ideal, um ein separates Geschäft Analyst für das gleiche zu haben.
• Hire einen Sr. Entwickler zu bewerten, ob Open-Source-CMS alle oder meisten Ihrer Anforderungen (z. B. Joomla, Drupal, etc.) verarbeiten kann.
• Wichtigste Sache hier wäre Fähigkeit, Ihre vorhandenen Daten auf neues System zu migrieren. Sie benötigen möglicherweise Hilfe von Ihrem bestehenden Vertragsentwickler zu dies tun.
• Möglicherweise müssen Sie das Geschäft Geschäft oder Workflow aktualisieren, um das neue System zu verwenden.
• Module, die nicht implementiert werden können mit Open-Source-CMS möglicherweise erforderlich mit benutzerdefinierten Website implementiert werden.

Vieles davon hängt auch von Ihrer Geschäftsbeziehung mit bestehenden Vertragsentwickler und Lizenzvereinbarung ab. Was Sie vor sich haben, ist eine Verkäufersperre im Szenario. Möglicherweise möchten Sie weiter nach Lösungen suchen, um diese Lieferantensperre in Situationen zu beseitigen.

Answer 2

Die Anwendung erreichte das Ende des Lebens, sobald sie ohne jegliche Dokumentation ausgeliefert wurde. Beginnen Sie jetzt mit der Entwicklung, und Sie sollten 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 Ihrer Firma wollen.

Answer 3

Selbst wenn es sehr gut entworfen und funktioniert, bedeutet die Tatsache, dass es keine Dokumentation hat und für sein Leben auf eine Person angewiesen ist, bedeutet, dass das Produkt sehr gut in einen nicht wartbaren Zustand eingetreten ist. Das ist kein gutes Zeichen. Ich würde zustimmen, dass das Produkt längst vorbei ist "End of life"

Answer 4

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, dann investieren Sie in es und machen Sie es zur besten Software, die Sie durch Refactoring, Neuschreiben oder was immer Sie tun müssen. Wenn Sie treue Kunden oder eine starke Marke haben, dann lohnt es sich, sie zu schützen.

Manchmal ist das Umschreiben der ganzen Sache in eine andere Technologie eine gute Investition, wenn die aktuelle Software ein erfolgreiches Design hat, das kopiert werden kann, eine starke Marke hat und wenn es richtig gemacht werden kann.

Answer 5

Um es kurz zu machen: Ich bin in einer vergleichbaren Situation.

• Solange diese Anwendung ist so etwas wie ein cashcow, aber das Unternehmen nicht leisten kann (oder beabsichtigt) eine neue Anwendung zu entwickeln, wird es nicht sterben, bevor die Kunden entscheiden, ein frischeres System zu kaufen.

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

• Zumindest die Erfahrung von spezialisierten Abteilungen sollte in einer Weise dokumentiert werden, die für weitere Entwicklungen nützlich ist.

• Wenn Sie diese Anwendung pflegen müssen, sollten Sie Schnittstellen zwischen den Modulen einführen, um die Gesamtkomplexität zu reduzieren. So alt Module, egal wie messie sie sind, ist es egal, wenn Sie neue Funktionalität hinzufügen müssen.

Answer 6

Die einzige Art von Dokumentation, die das Systems des Leben sind Dinge erweitern werden, die als die Systemänderungen in seiner Lebenszeit, wie Testsuiten, Selbstdiagnose-Tools, Code-Kommentare, deklarative Verträge wie interfcaces und automatisch konsistent bleiben generierte Dokumentation.

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

Wenn Sie sich keine Entwicklerredundanz "leisten" können, um die Anwendung zuverlässig zu verwalten, können Sie es sich auf keinen Fall leisten, die Dokumentation auf dem neuesten Stand zu halten. Der Mangel an Dokumentation ist wirklich eine technische Schuld, die Sie vielleicht unbewußt übernommen haben. Wenn ein längerer Lebenszyklus eine Voraussetzung ist, müssen die Kosten für die Erfüllung dieser Anforderung berücksichtigt werden.Ist

die Funktionalität, die dieses System in einem billigeren, die Endnutzern zur Verfügung stellt:

Answer 7

Dies sind die Art von Dingen, die ich prüfen könnte bei der Entscheidung, ob ein System gehen könnte „end-of-life“ zuverlässige oder einfach zu bedienende Form? Wenn nicht jetzt, wann ist das wahrscheinlich? Ist dieses Produkt längerfristig durchführbar?

Ist dies in einer Technologie geschrieben, von der die Kunden ablenken würden, weil es schwierig wäre, sie in ihre Produkte zu integrieren, oder wenn sie "veraltete" Plattformen ausführen müssten? Würde es einem potentiellen Kunden den Eindruck vermitteln, dass Ihr Unternehmen wesentlich hinter den Zeiten ist, z.B. VB6 ist wahrscheinlich nur noch in Ordnung, auch im Jahr 2010, aber wahrscheinlich nicht Win16 Kompatibilität.

Können Sie gute Leute einstellen, die die zugrunde liegende technische Plattform zu vernünftigen Kosten kennen? Auf der älteren Technologie könnte es sein, dass es viele Leute gibt, die die Plattform kennen, aber sie sehen es als eine Sackgasse und werden um ein Prämiengehalt bitten, 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? Sind Sie eingeschränkt auf welche Hardware oder Betriebssystem können Sie es ausführen, wenn der Anbieter es nicht mehr aktualisiert? Gibt es Sicherheitslücken in der Plattform, die möglicherweise aktualisiert werden müssen? Sogar Nischen-Open-Source-Produkte können darunter leiden. Sobald ein Produkt in Ungnade fällt und Core-Entwickler in neue Projekte wechseln, kann es schwierig sein, von der Community Korrekturen zu erhalten.

Wenn es unterstützt wird, berechnen die Anbieter Ihnen eine Prämie für die Unterstützung einer älteren Plattform? Wenn nicht jetzt, wie lange noch?

Wie schwierig ist es, neue Technologien zu integrieren, um die aktuellen Trends zu nutzen, die den Endnutzern erweiterte Funktionen bieten, damit Sie wettbewerbsfähig bleiben? Interessiert dich das? Es spielt keine Rolle, ob Sie im Wesentlichen ein geschlossenes System betreiben.

Wie schwierig ist es, funktionale Änderungen zu veröffentlichen, ohne umfangreiche "Shotgun" Änderungen, die sich über das ganze System verteilen? Dies ist darauf zurückzuführen, wie modular das System ursprünglich aufgebaut war. Wenn Sie nicht schlechter als Ihre Konkurrenten sind, um Funktionen auf den Markt zu bringen, dann sind Sie wahrscheinlich in Ordnung.

Was kostet das Umschreiben des Systems? Wie ist das im Vergleich dazu, wie viel billiger es wäre, den Verkaufserlös zu halten oder zu erhöhen? Es könnte wirtschaftlich nicht machbar sein, ein vollständiges Neuschreiben durchzuführen. Wenn die Entwicklungsplattform solide ist, können Sie einfach einen Refactoring-Ansatz ausprobieren. Hier hilft eine gute Testsuite und Dokumentation.

Answer 8

Ich ging durch einen ähnlichen Prozess. Wir hatten eine Web-App, die fast 8 Jahre lang lief. In dieser Zeit wurde viel gewartet, und es wurde so erweitert, wie wir es uns nicht vorgestellt hatten. Der Kern war jedoch gut und es konnte immer noch gedehnt werden.

Was uns antrieb, 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 mit identischer Funktionalität ersetzen könnten und dass diese Zeit sich schnell auszahlen würde.

Also, wir haben Screenshots als unsere funktionalen Anforderungen, überarbeitet das Aussehen und Gefühl, und waren sogar in der Lage, erhöhte Funktionalität zu liefern.Wir haben uns auch Nutzungsdaten angesehen, um Teile zu identifizieren, die entweder selten oder nie verwendet wurden, und diese getrimmt, und konzentrierten mehr Aufmerksamkeit auf die Teile, die verwendet wurden.

Letztendlich waren wir erfolgreich. Zum Teil, weil alle Teammitglieder mit der neuen Technologie vertraut waren und daher wenig Lernbedarf bestand. Weitere beitragende Faktoren waren ein durchdachtes Design. Ich denke, wir haben 3 Monate nur im Design verbracht, bevor wir etwas geschrieben haben.

Der letzte Faktor war, dass unsere App modular ist. So konnten wir es in Größen unterteilen, die klein genug waren, um eine Kombination aus kurzen Lieferterminen mit einer Ausfallzeit/Analyseperiode zwischen den einzelnen Lieferungen zu ermöglichen. So waren wir in jeder Phase auf dem richtigen Weg.