如何确定Web应用程序的生命周期?

时间:2010-01-20 21:56:28

标签: java end-of-life

这个问题可能会带来很多意见,但我想得到的是一系列措施,可以帮助我和我的公司确定我们销售的产品的生命周期。

我们销售CMS系统,通过该系统我们创建了一些子产品

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

我们已准备好开始我们的道路规划(2010年和2011年),我们正在努力确定何时将是我们应用程序的生命周期。你们中的一些人可能认为一个架构很好的应用程序(我认为我们的应用程序没有很好的架构)不需要生命结束,但我们使用的这个应用程序可以追溯到至少6 - 7年,几乎没有文件(现实生活)。此时只有一个人知道如何改变核心功能(可怕)。

请建议,

地理


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

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

  • 有一位开发人员能够维护我们产品的核心功能。 (只有一个)
  • 有两个开发人员能够将功能增加到某一点。两个开发人员都受到核心产品限制的约束,他们都必须在这些限制范围内工作。
  • 非常重要的一点。我们正在考虑将其用于报废的产品大部分由承包商建造。承包商是唯一能够维护核心功能的开发人员。我们只在承包商框架之上发展。

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

8 个答案:

答案 0 :(得分:7)

由于应用程序设计得很好,您可能不想退休并放弃迄今为止所做的所有投资。

以下是我的建议:

  • 请一位初级开发者加入 现任开发商。
  • 将大部分未来的更新转储到初级 开发人员(在sr的帮助下) 显影剂)
  • 要求初级开发人员这样做 他的工作文件
  • 要求高级开发人员审核 文档

在一段时间内,您有另一个人可以支持此应用程序,它也将被记录。现在,您不需要亲自杀死自己设计良好的应用程序。

使用下面的Jefferey建议扩展此解决方案(“有时重写是一项很好的投资。”)

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

使用当前和建议系统的文档,您可能希望了解是否可以逐个模块升级(重写)组件。如果应用程序设计得很好,这是可能的。


根据您的(地理位置)评论

Geo的组织拥有定制的第三方(只有一个合同开发商)CMS应用程序,该应用程序实现了以下业务要求,并支持许可费用以支持和使用他的代码。

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

以下是我的建议

  • 按模块详细使用创建模块 该项目的案例文件。您的 开发人员可以这样做或将会这样做 非常适合独立经营 分析师也是如此。
  • 聘请高级开发人员评估是否 开源CMS可以处理所有或 您的大多数要求(例如 Joomla,Drupal等。)。
  • 这里最重要的是 能够迁移现有数据 到新系统。您可能需要帮助 你现有的合同开发者 这样做。
  • 您可能需要更新业务 使用新的流程或工作流程 系统。
  • 无法实施的模块 可能需要使用开源CMS 使用自定义实现 网站。

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

答案 1 :(得分:3)

这只是我的意见,但如果这是您销售的产品,那么这一切都归结为商业前景。如果产品没有销售,请将其丢弃。如果产品有未来,那么投资它,并通过重构,重写或任何你必须做的事情,使它成为最好的软件。如果您拥有忠诚的客户或强大的品牌,那么这值得保护。

如果当前的软件具有可以复制的成功设计,具有强大的品牌,并且可以正确完成,那么有时用另一种技术重写整个事物是一项很好的投资。

答案 2 :(得分:2)

应用程序在没有任何文档的情况下发布时已达到使用寿命。现在就开始开发,你可能想考虑更换了解原始系统的人。如果他们已经过去了6/7年而没有创建任何类型的文档,那么他们就不是你公司想要的人。

答案 3 :(得分:2)

唯一能延长系统寿命的文档是随着系统生命周期的变化而保持一致的事情,如测试套件,自诊断工具,代码注释,声明合同(如interfcaces)和自动生成的文档。< / p>

其他手动管理的文档工件(如手册,开发人员指南,体系结构文档,数据格式)往往与文档数量成比例地过时。我不认为这些是增加应用程序预期寿命的因素,除非你已经考虑了维护它们的成本。

如果您无法“负担”开发人员冗余以可靠地维护应用程序,那么您无法保证更新文档。缺乏文件实际上是你已经决定的技术债务,也许是无意识的。如果需要更长的生命周期,那么其成本必须考虑到满足该要求。

答案 4 :(得分:1)

长话短说:我的情况相似。

  • 只要这个应用程序像现金一样,但公司无法负担(或打算)开发新的应用程序,它将不会在客户决定购买更新的系统之前消亡。

  • 几乎不可能重写没有(记录)的要求。

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

  • 如果必须维护此应用程序,则应引入模块之间的接口, 降低整体复杂性。这些旧模块无论它们多么混乱,都不关心是否需要插入新功能。

答案 5 :(得分:0)

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

答案 6 :(得分:0)

在决定某个系统是否会“终结”时,我可能会考虑这些事情:

此系统提供的功能是以更便宜,更可靠或更易于使用的形式提供给最终用户吗?如果不是现在,那么这可能是什么时候?从长远来看,这种产品是否可行?

这是用客户可以避开的技术编写的,因为与他们的产品接口很尴尬,或者要求他们运行“过时的”平台?是否会给潜在客户留下一个印象,即您的公司显着落后于时代,例如即使在2010年,VB6可能仍然可以,但要求Win16兼容性可能不是。

您能以合理的成本聘请了解基础技术平台的优秀人才吗?在较老的技术上,可能有很多人都知道这个平台,但看到它是一个死胡同,并且如果他们的职业生涯在低迷期间萎靡不振,他们会要求高薪。

如果对您而言,开发平台是否仍受供应商支持?如果供应商不再更新它,您是否会受限于可以运行它的硬件或操作系统?同样,平台中是否存在可能需要更新的安全漏洞?即使是小众开源产品也会受此影响。一旦产品失宠并且核心开发人员转向新项目,社区就很难完成修复。

如果支持,供应商是否会向您收取支持较旧平台的溢价?如果不是现在,那么他们会做多久呢?

将新技术集成到其中以利用当前趋势,为最终用户提供丰富的功能以保持竞争力是多么困难?你关心这件事吗?如果您基本上运行一个封闭的系统可能无关紧要。

如果没有广泛的“霰弹枪”变化在整个系统中波动,那么发布功能变化有多难?这又回到了系统设计的模块化程度。如果你的竞争对手将功能推向市场并不差,那你就可以了。

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

答案 7 :(得分:0)

我经历了一个类似的过程。我们有一个运行了近8年的网络应用程序。在那段时间里,我们进行了大量的维护工作,并以我们没有想到的方式进行扩展。然而,核心很好,它仍然能够被拉伸。

推动我们的是维护成本。 8年前,找到具备合适技能的人很容易。今天,没有人想在这些环境中工作;甚至不是我们:)。

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

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

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

最后一个因素是我们的应用是模块化的。因此,我们能够将其缩小到足够小的尺寸,以便将交货时间表与每个可交付物之间的停机时间/分析周期相结合。这确保我们在每个阶段都走在正确的道路上。

相关问题