如何确定 Web 应用程序的生命周期结束？[关闭]

StackOverflow https://stackoverflow.com/questions/2105304

  •  21-09-2019
  •  | 
  •  

题

这个问题可能会带来很多意见，但我希望得到的是一套措施，帮助我和我的公司确定我们销售的产品的使用寿命。

我们销售一个CMS系统，通过这个系统我们创建了一些子产品

  • 网站
  • 提案创建者
  • 营销活动跟踪器

我们已准备好开始道路规划（2010 年和 2011 年），并且正在尝试计算应用程序的生命周期何时结束。你们中的一些人可能认为一个架构非常好的应用程序 （我认为我们的应用程序架构不佳） 不需要有生命周期，但我们使用的这个应用程序至少可以追溯到 6-7 年前，并且几乎没有文档（现实生活）。目前只有一个人知道如何更改核心功能（可怕）。

请指教，

地理

谢谢大家！我非常感谢您对此主题的评论、意见和想法。

我将解决下面列表中的一些回发问题

  • 有一位开发人员能够维护我们产品的核心功能。（只有且只有一个）
  • 有两个开发人员能够将功能增加到一定程度。两位开发人员都受到核心产品的限制，并且他们都必须在这些限制内工作。
  • 一个非常重要的说明。我们正在考虑报废的产品大部分是由承包商制造的。承包商是唯一能够维护核心功能的开发商。我们仅在承包商框架之上进行开发。

在阅读您的所有回复时，我将继续添加答案。

有帮助吗？

解决方案

由于应用程序的架构非常好，您可能不想放弃它并失去迄今为止所做的所有投资。

以下是我的建议：

  • 让初级开发人员加入这个 当前开发人员。
  • 将大部分未来更新转储到初级 开发人员（在 Sr.开发商）
  • 请初级开发人员做 他的工作记录
  • 询问先生。开发人员审查文档

经过一段时间后，您将有另一个人可以支持此申请，并且该申请也将被记录下来。现在，您不需要亲手杀死自己架构良好的应用程序。

.

根据下面的 Jefferey 建议扩展此解决方案（“有时重写是一项很好的投资。”）

如果您仍然想删除当前应用程序并重新编写它，您仍然需要记录现有系统并根据它创建新系统的需求。

使用当前和建议系统的文档，您可能想看看是否可以逐个模块地增量升级（重写）组件。如果应用程序的架构非常好，这是可能的。

根据您的（地理）评论

Geo 的组织拥有定制的第三方（只有一名合同开发人员）CMS 应用程序，该应用程序实现以下业务要求，并为支持和使用其代码支付许可费。

  • CMS 的业务需求
  • 网站
  • 提案创建者
  • 营销活动跟踪器

这是我的建议

  • 逐个模块创建模块详细用途 该项目的案例文件。你 开发人员可以这样做，或者会这样做 拥有独立业务的理想选择 分析师。
  • 聘请一位先生。开发人员评估是否 开源 CMS 可以处理所有或 您的大多数要求（例如Joomla、Drupal 等）。
  • 这里最重要的是 迁移现有数据的能力 到新系统。您可能需要以下方面的帮助 您现有的合同开发人员 执行此操作。
  • 您可能需要更新业务 使用新流程或工作流的流程或工作流 系统。
  • 无法实现的模块 可能需要使用开源 CMS 使用自定义实现 网站。

其中很大程度上还取决于您与现有合同开发商和许可协议的业务关系。您面临的是场景中的供应商锁定。您可能需要进一步研究解决方案，以消除这种供应商锁定的情况。

其他提示

这只是我的意见，但是如果这是您要出售的产品，那么这一切都归结为业务前景。如果产品不出售，请放下它。如果产品有未来，请投资于它，并通过重构，重写或您必须做的任何事情来使其成为最佳的软件。如果您有忠实的客户或一个强大的品牌，那么这是值得保护的。

有时，如果当前的软件具有可以复制的，具有强大的品牌，并且可以做对的话，则有时将整个事情重写是一项不错的投资，如果当前软件具有成功的设计。

申请在没有任何形式的文档的情况下，申请就达到了生命的尽头。现在开始开发，您可能需要考虑更换了解原始系统的人。如果他们在没有创建任何任何文档的情况下已经走了6/7年，那么他们就不是您想要的人。

唯一可以延长系统寿命的文档是随着系统的一生而变化，例如测试套件，自我诊断工具，代码注释，宣言合同（例如Interfcaces）以及自动生成的文档。

其他手动管理的文档工件，例如手册，开发人员指南，架构文档，数据格式往往会与文档数量成比例过时。除非您已经考虑维护它们的成本，否则我不会将这些因素算作增加预期寿命的因素。

如果您无法“负担得起”开发人员的冗余来可靠地维护应用程序，那么您将无法负担最新文档的最新情况。缺乏文档确实是您决定要承担的技术债务。如果需要更长的生命周期，则必须考虑满足该要求的成本。

长话短说：我处于可比的情况。

  • 只要此应用程序就像CashCow一样，但是该公司负担不起（或打算）开发新应用程序的应用程序，它就不会在客户决定购买新鲜系统之前死亡。

  • 没有（记录）要求的重写几乎是不可能的。

  • 至少应该以一种对进一步发展有用的方式记录专业部门的经验。

  • 如果您必须维护此应用程序，则应在模块之间引入接口，以降低整体复杂性。因此，无论他们多么乱，旧模块都不在乎您是否必须插入新功能。

即使它的设计良好且运转良好，它没有文档，并且依赖一个人的生命，这意味着该产品已经非常不可测量地进入了一个无与伦比的状态。这不是一个好兆头。我同意该产品已经过去了“生命的终结”

这些是决定系统是否可能“寿命终止”时可能会考虑的事情：

该系统为最终用户提供的功能是否更便宜，更可靠或易于使用？如果不是现在，那么这可能是什么时候？因此，从长远来看，该产品是否可行？

这是用一项技术编写的，客户会脱离该技术，因为它会尴尬地接口到他们的产品，或者要求他们运行“过时”平台？它会给潜在客户留下您的公司的印象 显著地 即使在2010年，Times EG VB6也可能仍然还不错，但要求Win16兼容性可能不是。

您能否雇用以合理成本了解基础技术平台的好人？在较旧的技术上，可能有很多人知道平台，但将其视为死胡同，并且会要求高级薪水，如果他们的职业生涯会在低迷中陷入困境。

如果对您很重要，开发平台是否仍然得到供应商的支持？如果供应商不再对其进行更新，您是否会受到限制在什么硬件或操作系统上可以运行的？同样，平台中可能需要更新的安全孔？即使是利基开源产品也可能会遭受这一影响。一旦产品不受欢迎，核心开发人员进入新的项目，就很难由社区完成修复。

如果得到支持，供应商是否向您收取支持旧平台的溢价？如果不是现在，那么他们要花多长时间？

将新技术集成到IT中有多么困难，以利用当前的趋势，这些趋势为最终用户提供丰富的功能以使您保持竞争力？你在乎这个吗？是否基本运行封闭的系统可能无关紧要。

在整个系统中闪烁的大规模“ shot弹枪”变化而没有广泛的“ shot弹枪”变化，释放功能性更改有多困难？这回到了系统设计的模块化。如果您的竞争对手可以将功能推向市场，那么您可能还可以。

重新编写系统的成本是多少？这与维持或增加销售收入的便宜数量相比如何？进行整个重写可能在经济上是不可行的。如果开发平台是合理的，那么您可以尝试更多的重构方法。在这里，拥有良好的测试套件和文档有所帮助。

我经历了一个类似的过程。我们有一个运行近8年的网络应用程序。在那个时候，进行了很多维护，以我们没有设想的方式扩展了它。但是，核心是好的，它仍然可以伸展。

促使我们推翻的是维护成本。在8年前找到具有正确技能的人很容易。今天，没有人愿意在这些环境中工作。甚至不是我们:)

经过分析后，我们知道我们可以在12个月内将其替换为相同的功能，并且这段时间将很快获得回报。

因此，我们使用屏幕截图作为我们的功能需求，对外观和感觉进行了修改，甚至能够提供更多的功能。我们还查看了用法数据，以识别很少或从未使用过并修剪这些零件的零件，并将更加关注所使用的零件。

最终，我们取得了成功。部分原因是团队中的每个人都精通新技术，因此学习很少。其他贡献因素包括经过深思熟虑的设计。我认为我们在编写任何内容之前花了3个月的设计。

最终因素是我们的应用是模块化的。因此，我们能够以足够小的尺寸将其切成薄片，以结合每个可交付的短交付时间表以及停机时间 /分析期的组合。这确保我们在每个阶段都走上了正确的道路。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top