Belady和Lehmann的软件工程模型

Belay和Lehmann(1972)是最早尝试在预测模型中捕获维护工作的研究人员之一。该模型明确了这样一个概念，即如果使用了较差的软件开发方法，那么工作量和成本就会成倍增加，并且开发该软件的人员将不再有能力进行软件维护。贝拉迪(Belady)和莱曼(Lehmann)通过等式捕获了这些影响：

M = P + Ke ^(cd)

• M =扩展了系统的总维护工作量。
• P =它代表了富有成果的工作，例如分析，评估，设计，编码和测试。
• c =缺乏结构化设计和文档导致的复杂性。
• d =维护团队对软件的熟悉程度。
• K =通过将该模型与实际项目中的工作量关系进行比较而确定的常数；之所以称为经验常数，是因为其值取决于环境。

该公式在决定维护工作量的因素之间起着非常重要的关系。在给定的关系中，如果某种程度上不是通过使用软件工程过程来开发软件，那么“ c”的价值就会增加。当然，对于具有高度系统结构的大型软件产品，“ c”将比具有相同程度的小型软件产品更高。如果在不了解软件的结构，函数和用途的情况下维护软件，则“ d”的值pf将很低。这样，作为维护成本发现的结果成倍增加。因此，为了节省维护成本，最好的方法是使用良好的软件工程实践来构建系统，并让维护人员熟悉该软件。

示例：一个软件项目的开发工作量为300个人月。根据经验确定的常数(K)为0.3。代码的复杂度等于8(相当高的值)。计算总工作量(M)，如果

1. 维护团队对项目有很好的了解(d = 0.9)。
2. 维护团队对项目的了解不足d = 0.1)

解决方案：开发工作量(P)= 300 PM

K = 0.3
C = 8

1.维护团队具有良好的理解水平(d = 0.9)

M = P + ke(c-d)
  = 300 + 0.3e(8-0.9)
  = 300 + 363.59
  = 663.59 PM

2.维护团队的理解水平较差(d = 0.1)

M = P + Ke(c-d)
  = 300 + 0.3e(8-0.1)
  = 300 + 809.18
  = 1109.18 PM

因此，从上面的示例可以清楚地看出，如果使用不良的软件工程方法，则工作量将成倍增加，并且项目的可理解性也很差。