垂死软件的迹象

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

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

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

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

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

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

允许存在单点故障(只有一个人理解)

管理层未分配资源来修复缺陷

六个月没有积极的发展

一年内没有发布周期

基础供应商产品/库不再受支持

资源从一个项目中取出,而不是在一个季度内更换两次以上

环境变化(例如,更高的用户数量)没有得到补救

未测量性能并且不会定期进行调整(性能下降)

基础设施变化迫在眉睫(OS,DB,HARDWARE)

由于系统中存在缺陷,挫折或错误,用户已创建了解决方法

用户群正在下降

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

公开直接地与您的管理层接洽

准确报告缺陷率并根据管理成本对其进行量化

尽可能多地自动构建,测试,打包和部署周期

尽可能模块化系统

制定明确的指标并在必要时调整应用程序

了解用户最关键的内容并满足这些需求

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

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

有几个迹象:

增加缺陷到达率

修复每个缺陷的成本更高

每个新功能的成本更高

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

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

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

软件似乎更常见,因为

底层硬件或操作系统已过时,软件无法进行转换(WordPerfect,Lotus 1-2-3)

竞争产品提供卓越的功能,而市场领导者因自满而停滞不前(Amiga)

该软件通过"范例更改"(Encarta)变得过时

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