垂死软件的迹象

Question

什么迹象表明软件正在消亡？

---

开发人员如何发现早期警告以保存一个软件不会死亡？

从用户的角度来看,我认为很清楚 - 他们无法有效使用,他们会垃圾.

除此之外,软件可能因其代码而死 - 架构,编码风格,代码库大小,代码库组织和程序员的质量.

我想知道如何听取软件死亡的迹象并采取纠正措施.任何着名的例子软件都没有,因为没有开发人员听过这些标志？是否保存了死亡软件的任何示例？

Answer 1

以下任何一项都清楚地表明您的系统属于濒危物种清单:

• 允许存在单点故障(只有一个人理解)
• 管理层未分配资源来修复缺陷
• 六个月没有积极的发展
• 一年内没有发布周期
• 基础供应商产品/库不再受支持
• 资源从一个项目中取出,而不是在一个季度内更换两次以上
• 环境变化(例如,更高的用户数量)没有得到补救
• 未测量性能并且不会定期进行调整(性能下降)
• 基础设施变化迫在眉睫(OS,DB,HARDWARE)
• 由于系统中存在缺陷,挫折或错误,用户已创建了解决方法
• 用户群正在下降

保持项目至关重要的方法:

• 公开直接地与您的管理层接洽
• 准确报告缺陷率并根据管理成本对其进行量化
• 尽可能多地自动构建,测试,打包和部署周期
• 尽可能模块化系统
• 制定明确的指标并在必要时调整应用程序
• 了解用户最关键的内容并满足这些需求

在从死里复活的软件库中,我必须将第一个功能区放到Objective-C上.

Answer 2

在这里插入一个胡思乱想的Windows笑话.

有几个迹象:

• 增加缺陷到达率
• 修复每个缺陷的成本更高
• 每个新功能的成本更高

所有这些都表明代码中的熵更高,即低信噪比.

有很多方法可以解决这个问题; 可能最有效的方法是识别具有高缺陷率的模块 - 缺陷往往具有帕累托分布,即20%的模块占80%的缺陷.您为这些模块构建测试框架工作,并从干净的页面重新实现它们,构建良好的测试(使用适当的单元测试框架等),然后将它们装回整个系统.

Answer 3

我认为,你似乎想到的软件因内部"技术原因"而死亡的情况相对较少.我真的不能想到任何例子; 也许是德尔福(虽然那不是死的,只是非常生病).

软件似乎更常见,因为

• 底层硬件或操作系统已过时,软件无法进行转换(WordPerfect,Lotus 1-2-3)
• 竞争产品提供卓越的功能,而市场领导者因自满而停滞不前(Amiga)
• 该软件通过"范例更改"(Encarta)变得过时

虽然前两点可能通常部分是质量问题的错误(这使得它对市场变化的反应太慢而且成本太高),后者则不然.