前言：
对非软件领域的其他领域[比如化工、船舶等等]的工程项目有了解的人，应该都知道：工程规模扩大，其他相应的人力成本，过程计算，工程周期等等并不是线形关系。更经常地，您会发现，有时候小工程和大工程适用的科学理论体系都是不同的。
依据小工程的经验判断大工程问题是单纯的幻想，那么，软件领域又有哪些值得注意或者有趣的规律呢？
软件规模和沟通交流的关系
多人项目潜在的交流途径为 N(N-1)/2 个。比如N=10，潜在交流途径则为45个。
交流的途径越多，消耗的时间也就越多，交流出错的可能性就越大。
改善途径：
在可能的情况下，分解项目团队的规模。
阅读和撰写文档是减少交流次数的有效方法之一。
软件规模和BUG的关系
软件规模既影响BUG的数量，也影响BUG的类型。
小的软件项目中，对质量影响最大的是开发者的技能。
越大的软件项目中，需求和架构的错误对质量的影响逐步加大。但无论多么大型的项目，开发者带来的问题依然超过问题总数的50%以上。
在其他条件都相等的时候，大的软件项目生产率低于小的软件项目
| 项目大小[代码行] | 每人年的代码行数[括号里是cocomo II均值] |
| 1K | 2500 - 25000 [4000] |
| 10K | 2000 - 25000 [3200] |
| 100K | 1000 - 20000 [2600] |
| 1000K | 700 - 10000 [2000] |
| 10000K | 300 - 5000 [1600] |
在其他条件都相等的时候，大的软件项目BUG率高于小的软件项目
| 项目大小[代码行] | 典型的BUG密度[千行BUG数] |
| < 2000 | 0-25 |
| 2000 - 16000 | 0-40 |
| 16000 - 64000 | 0.5 - 50 |
| 64000 - 512000 | 2 - 70 |
| > 512000 | 4 - 100 |
放大轻量级的方法论要好过缩小重量级的方法论
随着项目规模的增加，工作量超过线形增长的活动有：
交流
计划
管理
需求分析
系统功能设计
接口设计和规格说明
架构
集成
消除缺陷
系统测试
文档生成
此外，其它活动基本还是线形的。
