Comment déterminer la fin de l'application Web de la vie? [fermé]

Question

Cette question pourrait apporter beaucoup d'opinions sur la table, mais ce que j'aimerai obtenir est un ensemble de mesures qui me aider et mon entreprise à déterminer la fin de vie d'un produit que nous vendons.

Nous vendons un système CMS, avec ce système, nous créons quelques sous-produits

• Sites web
• Proposition Creator
• Marketing Tracker campagne

Nous sommes prêts à commencer notre planification routière (pour 2010 et 2011) et nous essayons de comprendre quand sera la fin de la vie de notre application. Certains d'entre vous pourraient penser qu'une très bien architecturé l'application (je ne pense pas que notre application est bien architecturé) n'a pas besoin d'avoir une fin de vie, mais cette application que nous utilisons remonte à moins 6-7 ans et n'a presque pas de documentation (vie réelle). En ce moment, une seule personne sait comment changer la fonctionnalité de base (effrayant).

S'il vous plaît des conseils,

Geo

---

Merci à tous! J'apprécie vraiment vos commentaires, opinions et réflexions sur ce sujet.

Je vais aborder quelques-unes des questions après retour de la liste ci-dessous

• Il y a un développeur qui est capable de maintenir la fonctionnalité de base de notre produit. (Seulement et une seule)
• Il y a deux développeurs capables d'augmenter la fonctionnalité à un certain point. Les deux développeurs sont contraints par les limites du produit de base, et ils ont tous deux à travailler dans ces limites.
• Une note très importante. Le produit que nous envisageons de mettre à fin de vie est pour la plupart en cours de construction par un entrepreneur. L'entrepreneur est le seul développeur capable de maintenir la fonctionnalité de base. Nous ne développons que sur le dessus du cadre de l'entrepreneur.

Je vais continuer à ajouter des réponses pendant que je vous ai lu toutes les réponses.

Answer 1

Depuis l'application est très bien architecturé, vous voudrez peut-être pas de se retirer et perdre tout investissement que vous avez fait à ce jour.

Voici mes suggestions:

• Avoir un développeur junior se joindre à cette développeur actuelle.
• Dump la plupart des futures mises à jour sur junior développeur (avec l'aide de sr. développeur)
• Demandez développeur junior de faire la la documentation de son travail
• Demandez développeur Sr. à revoir documentation

Au cours de la période de temps, vous avez une autre personne qui peut prendre en charge cette demande et il doit être documenté. Maintenant, vous ne aurez pas besoin de tuer votre propre application très bien architecturé avec vos mains.

.

L'extension de cette solution avec la suggestion Jefferey ci-dessous ( "réécriture est parfois un bon investissement.")

Si vous voulez toujours laisser tomber l'application en cours et récrire, vous avez encore besoin de documenter le système existant et de créer des exigences pour le nouveau système basé en dehors.

Utilisation de la documentation du système actuel et proposé, vous pouvez voir si vous pouvez le module progressivement par des composants de mise à niveau du module (re-écriture). Ceci est possible si l'application est très bien architecturé.

---

(Selon votre Geo) commentaires

L'organisation de Geo a des tiers sur mesure (avec un et un seul développeur de contrat) Application CMS qui met en œuvre en deçà des exigences d'affaires et paie des frais de licence pour le soutien et l'utilisation du son code.

• Les exigences opérationnelles pour CMS
• Sites web
• Proposition Creator
• Marketing Tracker campagne

Voici mes suggestions

• Créer par module utilisation détaillée document de cas pour ce projet. Votre développeur peut faire ceci ou serait idéal pour une entreprise séparée analyste même.
• Embaucher un développeur senior pour évaluer si CMS open source peut gérer tout ou la plupart de vos besoins (par exemple Joomla, Drupal, etc.).
• La chose la plus importante ici serait capacité de migrer vos données existantes au nouveau système. Vous devrez peut-être l'aide de votre développeur de contrat existant faire.
• Vous pouvez mettre à jour des affaires processus ou flux de travail à utiliser les nouvelles système.
• Les modules qui ne peuvent pas être mises en œuvre en utilisant CMS open source peut être nécessaire à mettre en œuvre à l'aide personnalisée le site web.

Une grande partie de celui-ci dépend aussi de votre relation d'affaires avec le développeur de contrat existant et contrat de licence. Ce que vous faites face est un verrou de fournisseur dans le scénario. Vous pouvez poursuivre la recherche de solutions pour éliminer ce blocage du fournisseur dans la situation.

Answer 2

Ceci est juste mon avis, mais si cela est un produit que vous vendez, alors tout se résume à des perspectives d'affaires. Si le produit ne se vend pas, puis déposez-le. Si le produit a un avenir, investir dans, et en faire le meilleur logiciel, vous pouvez par refactoring, réécriture, ou tout ce que vous avez à faire. Si vous avez des clients fidèles ou une marque forte, alors que la protection vaut le coup.

réécriture Parfois la chose dans une autre technologie est un bon investissement, si le logiciel actuel a un design réussi qui peut être copié, a une marque forte, et si elle peut être fait.

Answer 3

L'application en fin de vie du moment où il livré sans aucune sorte de documentation. Commencez maintenant le développement, et vous voudrez peut-être envisager de remplacer la personne qui connaît le système d'origine. Si elles ont disparu 6/7 ans sans créer toute sorte de documentation que ce soit, ils ne sont pas que quelqu'un vous voulez dans votre entreprise.

Answer 4

Le seul type de documentation qui prolongera la vie de votre système sont des choses qui restent cohérentes que les modifications apportées au système dans sa durée de vie, comme des suites de test, des outils d'auto-diagnostic, commentaires de code, les contrats déclaratives comme interfcaces et documentation générée automatiquement.

D'autres objets de documentation gérés manuellement, comme des manuels, des guides de développement, documents d'architecture, les formats de données ont tendance à se périmer en proportion de la quantité de documents. Je ne compte pas ces facteurs qui augmentent votre espérance de vie de l'application, sauf si vous avez déjà pris en compte le coût de les maintenir.

Si vous ne pouvez pas « permettre » la redondance des développeurs pour maintenir de manière fiable l'application, il n'y a aucun moyen que vous pouvez vous permettre de maintenir la mise à jour de la documentation. Le manque de documentation est vraiment une dette technique que vous avez décidé, peut-être inconsciemment, à prendre. Si un cycle de vie plus longue est une exigence, le coût de ce facteur doit en répondre à cette exigence.

Answer 5

Pour faire une histoire courte: Je suis dans une situation comparable

.

• Tant cette application est quelque chose comme un cashcow, mais la société ne peut se permettre (ou l'intention) de développer une nouvelle application, il ne mourra pas avant que les clients décident d'acheter un système plus frais.

• Réécrire sans exigences (documentées) est presque impossible.

• Au moins l'expérience des départements spécialisés, devraient être documentées d'une manière qui est utile pour de nouveaux développements.

• Si vous devez maintenir cette application, vous devez introduire des interfaces entre les modules, de réduire la complexité globale. modules si vieux, peu importe la façon dont ils sont messie, ne se soucient pas si vous devez plug-in de nouvelles fonctionnalités.

Answer 6

Même si elle est très bien conçu et le fonctionnement, le fait qu'il n'a pas de documentation et dépend d'une seule personne pour sa vie, signifie que le produit est très bien entré dans un état difficile à maintenir. Ce n'est pas un bon signe. Je suis d'accord que le produit est passé depuis longtemps « Fin de vie »

Answer 7

Ce sont le genre de choses que je pourrais considérer au moment de décider si un système pourrait aller « fin de vie »:

La fonctionnalité que ce système offre disponible pour les utilisateurs finaux dans un moins cher, plus fiable ou plus facile à utiliser le formulaire? Sinon maintenant, quand il est probable? Ce produit est donc viable à long terme?

Est-ce écrit dans une technologie que les clients se détourner de car il serait difficile à l'interface dans leurs produits, ou les obliger à exécuter des plates-formes « obsolètes »? Ne serait-il donner à un client potentiel l'impression que votre entreprise est en retard par exemple de manière significative VB6 est probablement encore OK, même en 2010, mais nécessitant une compatibilité Win16 est probablement pas.

Pouvez-vous embaucher les bonnes personnes qui connaissent la plate-forme technique sous-jacente à un coût raisonnable? Le plus technique, il est peut-être qu'il ya beaucoup de gens qui connaissent la plate-forme, mais voient comme une impasse et demandera un salaire de prime si leur carrière va languir dans le pot au noir pendant qu'ils travaillent là-dessus.

Si cela vous concerne, est la plate-forme de développement encore pris en charge par le vendeur? Est-ce que vous allez être contraint sur ce matériel ou système d'exploitation, vous pouvez l'exécuter sur si le vendeur n'est mise à jour plus il? , Sont également là des trous de sécurité dans la plate-forme qui peut être mis à jour? Même niche produits Open Source peuvent en souffrir. Une fois qu'un produit est hors de faveur et les développeurs principaux Occuper de nouveaux projets, il peut être difficile d'obtenir des corrections faites par la communauté.

Si elle est prise en charge, sont les fournisseurs qui vous chargeront une prime pour supporter une ancienne plate-forme? Sinon maintenant, combien de temps avant de le faire?

Quelle est la difficulté à intégrer les nouvelles technologies en elle pour tirer parti des tendances actuelles qui offrent des fonctionnalités enrichies pour les utilisateurs finaux pour vous garder compétitifs? ça peut vous faire à ce sujet? Il ne peut pas d'importance si vous êtes essentiellement l'exécution d'un système fermé.

Comment est-il difficile de libérer des changements fonctionnels à sans changements importants « fusil de chasse » qui se propagent à l'ensemble du système? Cela revient à la façon modulaire, le système a été conçu pour être en premier lieu. Si vous n'êtes pas pire que vos concurrents en obtenant des caractéristiques de commercialiser alors vous êtes probablement OK.

Quel serait le coût de ré-écriture du système? Comment cela se compare à la façon beaucoup moins cher que ce serait de maintenir ou d'augmenter des revenus des ventes? Il pourrait ne pas être économiquement possible de le faire une réécriture entière. Si la plate-forme de développement est solide, vous pouvez alors juste essayer plus d'une approche de refactoring. C'est là d'avoir un bon test de suite et la documentation aide.

Answer 8

Je suis passé par un processus similaire. Nous avions une application web qui avait couru depuis près de 8 ans. En ce moment-là beaucoup d'entretien a été fait, en l'étendant de manière que nous n'avions pas prévu. Cependant, le noyau était bon et il était encore capable d'être étiré.

Ce qui nous a poussé plus était le coût de l'entretien. Trouver des personnes avec l'ensemble des compétences droite était facile il y a 8 ans. Aujourd'hui, personne ne veut travailler dans ces environnements; même pas nous:)

Après analyse, nous savions que nous pourrions le remplacer dans les 12 mois avec des fonctionnalités identiques et que ce temps passé payerait rapidement.

Alors, nous avons utilisé des captures d'écran que nos exigences fonctionnelles, revitalisée l'apparence, et ont même été en mesure d'offrir une fonctionnalité accrue. Nous avons également examiné les données d'utilisation pour identifier les pièces qui étaient soit rarement ou jamais utilisés et préparèrent ceux-ci, et se concentrèrent davantage l'attention sur les parties qui ont été utilisés.

En fin de compte, nous avons réussi. En partie parce que tout le monde dans l'équipe a été très versé dans la nouvelle technologie il n'y avait guère besoin d'apprendre. D'autres facteurs comprenaient un design bien pensé. Je pense que nous avons passé 3 mois seulement dans la conception avant d'écrire quoi que ce soit.

Le dernier facteur est que notre application est modulaire. Donc, nous avons pu diviser en segments en tailles suffisamment petites pour avoir une combinaison des horaires de livraison courts avec une période temps d'arrêt / analyse entre chaque produit à livrer. Cela a permis que nous étions sur la bonne voie à chaque étape.