5

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

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

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

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

请指教，

地理

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

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

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

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

4

8 回答 8

7

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

以下是我的建议：

  • 让初级开发人员加入当前的开发人员。
  • 将大部分未来更新转储给初级开发人员（在高级开发人员的帮助下）
  • 要求初级开发人员为他的工作做文档
  • 要求高级开发人员查看文档

随着时间的推移，你有另一个人可以支持这个应用程序，它也会被记录在案。现在，您无需亲手杀死自己架构良好的应用程序。

.

使用下面的 Jefferey 建议扩展此解决方案（“有时重写是一项不错的投资。”）

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

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

根据您的（地理）评论

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

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

以下是我的建议

  • 为这个项目创建一个模块一个模块的详细用例文档。您的开发人员可以这样做，或者最好有一个单独的业务分析师。
  • 聘请高级开发人员评估开源 CMS 是否可以处理您的全部或大部分需求（例如 Joomla、Drupal 等）。
  • 这里最重要的是将现有数据迁移到新系统的能力。您可能需要现有合同开发人员的帮助才能执行此操作。
  • 您可能必须更新业务流程或工作流程才能使用新系统。
  • 无法使用开源 CMS 实现的模块可能需要使用自定义网站来实现。

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

于 2010-01-20T22:19:09.167 回答
3

这只是我的观点，但如果这是您销售的产品，那么这一切都归结为业务前景。如果产品不卖，那就放弃它。如果产品有未来，那就投资它，通过重构、重写或任何你必须做的事情，让它成为你能做到的最好的软件。如果您有忠实的客户或强大的品牌，那么这是值得保护的。

有时用另一种技术重写整个东西是一项很好的投资，如果当前的软件有一个可以复制的成功设计，有一个强大的品牌，如果它可以做对。

于 2010-01-20T22:26:06.887 回答
2

该应用程序在没有任何文档的情况下交付时即已终止。现在开始开发，您可能要考虑更换了解原始系统的人。如果他们已经 6/7 年没有创建任何类型的文档，那么他们不是您公司想要的人。

于 2010-01-20T22:03:10.280 回答
2

唯一能延长系统寿命的文档是随着系统在其生命周期内发生变化而保持一致的东西，例如测试套件、自我诊断工具、代码注释、接口等声明性合同以及自动生成的文档。

其他手动管理的文档工件，如手册、开发人员指南、架构文档、数据格式，随着文档数量的增加，往往会变得过时。除非您已经将维护它们的成本考虑在内，否则我不会将这些视为增加您的应用程序预期寿命的因素。

如果您无法“负担”开发人员冗余来可靠地维护应用程序，那么您就无法负担使文档保持最新的费用。缺乏文档实际上是您决定承担的技术债务，也许是无意识的。如果需要更长的生命周期，则必须将其成本纳入满足该要求的因素。

于 2010-01-20T22:54:09.643 回答
1

长话短说：我处于类似的情况。

  • 只要这个应用程序有点像摇钱树，但公司负担不起（或打算）开发新的应用程序，它就不会在客户决定购买更新的系统之前死掉。

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

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

  • 如果你必须维护这个应用程序，你应该在模块之间引入接口，以降低整体复杂性。所以旧的模块，无论它们多么混乱，都不要在意是否必须插入新功能。

于 2010-01-20T22:43:47.327 回答
0

即使它的设计和功能都非常好，但它没有文档并且依赖于一个人的生命这一事实，也意味着该产品已经很好地进入了不可维护的状态。这不是一个好兆头。我同意该产品早已过“生命终结”

于 2010-01-20T22:10:03.473 回答
0

在决定一个系统是否可能“报废”时，我可能会考虑这些事情：

该系统提供的功能是否以更便宜、更可靠或更易于使用的形式提供给最终用户？如果不是现在，那么这可能是什么时候？因此，该产品在长期内是否可行？

这是用客户会避开的技术编写的，因为与他们的产品交互会很尴尬，还是要求他们运行“过时的”平台？它是否会给潜在客户一种印象，即您的公司明显落后于时代，例如 VB6 可能仍然可以，即使在 2010 年也是如此，但要求 Win16 兼容性可能不是。

您能否以合理的成本聘请了解底层技术平台的优秀人才？在较老的技术上，可能有很多人知道该平台，但将其视为死胡同，如果他们的职业在工作期间陷入低迷，他们会要求高薪。

如果对您很重要，供应商是否仍支持开发平台？如果供应商不再更新它，您是否会受限于可以在哪些硬件或操作系统上运行它？同样，平台中是否存在可能需要更新的安全漏洞？即使是利基开源产品也可能因此受到影响。一旦产品失宠，核心开发人员转向新项目，社区就很难修复。

如果支持，供应商是否会因支持旧平台而向您收取额外费用？如果不是现在，那么他们还要多久才能做到？

将新技术集成到其中以利用当前趋势为最终用户提供丰富的功能以保持竞争力有多困难？你关心这个吗？如果您本质上是在运行一个封闭的系统，这可能并不重要。

如果没有在整个系统中引起广泛的“散弹枪”更改，那么发布功能更改有多困难？这又回到了系统最初设计的模块化程度。如果您在将功能推向市场方面并不比您的竞争对手差，那么您可能没问题。

重写系统的成本是多少？这与维持或增加销售收入的成本相比如何？完全重写可能在经济上不可行。如果开发平台是健全的，那么你可以尝试更多的重构方法。这就是拥有一个好的测试套件和文档有帮助的地方。

于 2010-01-20T23:43:54.493 回答
0

我经历了一个类似的过程。我们有一个运行了将近 8 年的网络应用程序。在那段时间里，我们完成了大量的维护工作，并以我们没有想到的方式对其进行了扩展。不过，核心不错，还是可以拉伸的。

推动我们的是维护成本。8 年前，找到具有合适技能的人很容易。今天，没有人愿意在这些环境中工作。甚至我们也不行：）

经过分析，我们知道我们可以在 12 个月内用相同的功能替换它，而且所花费的时间会很快得到回报。

因此，我们使用屏幕截图作为我们的功能需求，改进了外观和感觉，甚至能够提供更多的功能。我们还查看了使用数据，以识别很少或从未使用过的部件并对其进行修整，并将更多注意力集中在使用过的部件上。

最终，我们成功了。部分原因是团队中的每个人都精通新技术，因此几乎不需要学习。其他促成因素包括经过深思熟虑的设计。我想我们在写任何东西之前就花了 3 个月的时间进行设计。

最后一个因素是我们的应用程序是模块化的。因此，我们能够将其拆分为足够小的尺寸，从而将较短的交付计划与每个可交付成果之间的停机时间/分析期相结合。这确保了我们在每个阶段都走在正确的道路上。

于 2010-01-21T00:42:03.317 回答