软件工程的过程改进 就要推进最佳实践的应用
组织进行软件工程的过程改进，就是要不断地优化组织的软件工程的实践，采取适合组织情况的最佳实践。那么什么才是软件工程的最佳实践呢？
最佳实践不是空口无凭仅是专家金口玉言而来的。软件工程的最佳实践必须要通过量化的数据来证明，这些量化数据包括对项目进度、工作量、成本、质量、客户满意度的改进效果评估或者以上这些因素的组合评估值。比如下表中的最佳实践的评价标准就是基于生产力的改进和质量的改进两种数据来评判软件工程实践的水平。
| 分数 | 生产力的改进 | 质量的改进 |
|---|---|---|
| 10 | 25% | 35% |
| 9 | 20% | 30% |
| 8 | 17% | 25% |
| 7 | 15% | 20% |
| 6 | 12% | 17% |
| 5 | 10% | 15% |
| 4 | 7% | 10% |
| 3 | 3% | 5% |
| 2 | 1% | 2% |
| 1 | 0% | 0% |
| 0 | 0% | 0% |
| -1 | 0% | 0% |
| -2 | -1% | -2% |
| -3 | -3% | -5% |
| -4 | -7% | -10% |
| -5 | -10% | -15% |
| -6 | -12% | -17% |
| -7 | -15% | -20% |
| -8 | -17% | -25% |
| -9 | -20% | -30% |
| -10 | -25% | -35% |
毫无疑问，评价软件工程实践的水平要依据足够的数据样本进行。除此之外，使用这种评价方法来确认最佳实践还要注意以下3点：
- 对于规模大小不同的软件，最佳实践也不尽相同。对于小型项目可能称为最佳实践；但是对于大型系统，这些实践可能就是不是同样有效了。
- 不同类型的软件，最佳实践也不尽相同。软件工程不是一个“一刀切”的行业。对于信息技术项目可能称为最佳实践，但对于嵌入式软件就不是那么有效了。
- 软件工程活动的复杂性，使得同一个实践不可能对于所有的活动.工具、语言和方法都是同样的有效或重要。
以上3个问题表明，为软件工程选择一组最佳实践将是一个相当艰巨的任务。我们需要根据软件的规模、类型以及活动来评估每种方法、工具或者语言的有限性。
- 小规模和大规模软件的最佳实践
对于小型项目，敏捷开发、极限编程以及高级语言都是关键的实践，因为对小型应用程序来说，编码是主要活动。但是．当我们分析大型应用时，我们会发现质量控制才是重中之重。下表给出了针对两种不同规模的软件工程最佳实践的建议：
| 小型应用程序 | 大型应用程序 |
|---|---|
| 1 敏捷开发 | 1 可重用性（>85%零缺陷材料) |
| 2 高级语言（当前） | 2 潜在缺陷<3.00/功能点 |
| 3 极限编程（XP） | 3 正规的成本跟踪报告 |
| 4 个体软件过程（PSP） | 4 审查（需求） |
| 5 可重用性（>85%零缺陷材料) | 5 正规的安全分析 |
| 6 自动静态分析 | 6 缺陷去除效率度量 |
| 7 时间盒短迭代 | 7 团队软件过程（TSP） |
| 8 可重用的源代码（零缺陷） | 功能点分析（高速） |
| 9 可重用的功能担保 | 9 能力成熟度模型集成（CMMI5级） |
| 10 可重用的功能认证 | 10 自动化安全测试 |
| 11 潜在缺陷<3.00/功能点 | 11 审查（设计） |
| 12 可重用的功能变更控制 | 12 缺陷去除效率>95% |
| 13 可重用的功能召回方法 | 13 审查（代码） |
| 14 面向对象开发 | 14 自动规模估算工具 |
| 15 审查（代码） | 15 混合型（CMM+TSP/PSP+其他） |
| 16 缺陷去除效率>95% | 16 自动静态分析 |
| 17 混合型（CMM+TSP/PSP+其他） | 17 个体软件过程（PSP） |
| 18 Scrum会议（每日） | 18 自动化的成本估算工具 |
| 19 缺陷去除效率度量 | 19 需求变更测量 |
| 20 功能点分析 | 20 面向服务架构（SOA） |
| 21 自动维护工作台 | 21 自动化质量与风险预测 |
| 22 提前评估潜在缺陷 | 22 行业数据基准 |
| 23 团队软件过程（TSP） | 23 质量功能展开 |
| 24 用户参与团队工作 | 24 大型应用的正规架构 |
| 25 行业数据基准 | 25 自动化缺陷跟踪工具 |
| 26 度量缺陷的严重级别 | 26 可重用架构 |
| 27 用例 | 27 正规的风险管理 |
| 28 可重用的测试用例 | 28 项目活动级生产力度量 |
| 29 自动化安全测试 | 29 正规的进度报告 |
| 30 不良修复的注入度量 | 30 功能点分析（模式匹配） |
- 不同类型软件的最佳实践
下表罗列了信息技术（IT）项目和系统/嵌入式软件项目的前30个最佳实践。
| 信息技术IT项目 | 系统/嵌入式项目 |
|---|---|
| 1 可重用性（>85%零缺陷材料） | 1 可重用性（>85%零缺陷材料） |
| 2 正确的治理 | 2 潜在缺陷<3.00/功能点 |
| 3 团队软件过程（TSP） | 3 缺陷去除效率>95% |
| 4 个体软件过程（PSP） | 4 团队软件过程（TSP） |
| 5 敏捷开发 | 5 度量缺陷的严重级别 |
| 6 缺陷去除效率>95% | 6 审查（代码） |
| 7 正规的安全分析 | 7 精益六西格玛 |
| 8 正规的成本跟踪报告 | 8 软件六西格玛 |
| 9 潜在缺陷<3.00/功能点 | 9 自动静态分析 |
| 10 自动静态分析 | 10 缺陷去除效率度量 |
| 11 缺陷去除效率度量 | 11 混合型（CMM+TSP/PSP+其他） |
| 12 功能点分析 | 12 个体软件过程（PSP） |
| 13 面向服务架构（SOA） | 13 正规的安全分析 |
| 14 联合应用设计 | 14 正规的成本跟踪报告 |
| 15 功能点分析（高速） | 15 功能点分析（高速） |
| 16 自动规模估算工具 | 16 审查（设计） |
| 17 通过数据挖掘来提取业务规则 | 17 自动化的项目管理工具 |
| 18 行业数据的基准 | 18 正规的测试计划 |
| 19 混合型（CMM+TSP/PSP+其他） | 19 质量功能展开（QFD） |
| 20 可重用的功能认证 | 20 自动化成本估算工具 |
| 21 可重用的功能变更控制 | 21 自动安全测试 |
| 22 可重用的功能召回方法 | 22 面向对象开发 |
| 23 可重用的功能担保 | 23 审查（测试材料） |
| 24 可重用的源代码（零缺陷） | 24 敏捷开发 |
| 25 提前评估潜在缺陷 | 25 自动规模估算工具 |
| 26 不良修复的注入度量 | 26 可重用的功能认证 |
| 27 可重用的测试用例 | 27 可重用的功能变更控制 |
| 28 检查（要求） | 28 可重用的功能召回方法 |
| 29 基于项目活动的生产力度量 | 29可重用的功能担保 |
| 30 可重用的设计 | 30 可重用的源代码（零缺陷） |
在表中可以看出，对于IT项目和系统/嵌入式项目来说.高质量可重用组件都是排名第一的最佳实践，但是两个表中剩余的最佳实践就截然不同了。对于信息技术项目，治理是排在第二位的最佳实践。而对于系统/嵌入式软件，多种形式的质量控制度量是排名最靠前的最佳实践。
对于很多军用软件来说，需要从上面两种最佳实践方法中综合考虑来选取，比如综合考虑小规模和嵌入式软件的最佳实践。可是，实际上很多软件项目并没有应用到最佳实践。据统计，在美国也只有14%的软件项目尝试使用9分以上的最佳实践。
软件工程的最佳实践会有效地改进生产力和质量，我们应当在推进软件工程的过程改进时，大力推进最佳实践的应用。
参考书目：《软件工程最佳实践》
