将程序员的生产效率量化到指令/年,是一个过时的好方法吗?

系统编程的时间和工作量估计是一项复杂且精细的任务。简单地根据编码部分进行估计,然后应用固定比率,往往会导致不准确的结果。实际上,编码仅占整个项目工作量的六分之一左右,而其他诸如规划、文档编写、测试、系统集成和培训等任务同样占据大量时间。

以下是几种估计方法和实际经验数据的总结:

Aron 的数据

基于 IBM 在马里兰州盖兹堡的九个大型项目,Aron 发现程序员的生产率取决于系统中各部分之间的交互程度:

  • 非常少的交互:10,000 指令/人年

  • 少量的交互:5,000 指令/人年

  • 较多的交互:1,500 指令/人年

Harr 的数据

在 Bell 实验室,Harr 发现控制程序的生产率为 600 指令/人年,而语言翻译程序的生产率为 2200 指令/人年。


图 8.3 和 8.4 显示了一些有趣的数据,将实际的编程速度、调试速度与预期做了对比。

图片

图片

OS/360 经验

控制程序组的生产率大约为 600 到 800 指令/人年,语言翻译程序组则为 2000 到 3000 指令/人年。

Aron、Harr 和 OS/360 的数据都证实,生产率会根据任务本身复杂度和困难程度表现出显著差异。在复杂程度这片“沼泽”上的指导原则是:编译器的复杂度是批处理程序的三倍,操作系统复杂度是编译器的三倍。


综合来看,系统编程的工作量和时间消耗高度依赖于项目的复杂性、团队规模以及使用的编程语言等因素。使用高级语言可以显著提高生产力,但无论使用何种语言,系统编程的生产率都相对较低,尤其是在涉及大量交互和复杂控制逻辑的情况下。因此,在进行项目估计时,需要全面考虑各个阶段的工作量,并留有足够的缓冲时间以应对不可预见的问题。

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部