23、软件开发方法评估与构建案例解析

软件开发方法评估与构建案例解析

1. 方法评估的现状与挑战

正式的方法评估往往成本高昂，只有那些项目预算能够承担严格评估高额费用的大型软件开发人员才能负担得起。而在实际情况中，非正式评估随时都在进行。人们在实践中学习并调整自己的行为，例如Scrum实践在每个冲刺阶段结束时会进行回顾，大多数方法也都有某种形式的事后分析或审计，持续改进的需求也被纳入了ISO 9001标准中。然而，这些普遍的改进要求并没有为我们提供具体应该关注什么以及如何识别改进需求的指导。

在方法执行过程中，我们可以获取关于该方法是否达到预期目的的信息。为了确定是否需要对方法进行更改（例如，正确执行了错误的流程）或者是否需要改变方法的执行方式（正确的流程执行有误），我们需要将实际绩效与预期绩效进行比较。

大多数方法执行的属性、方法片段和构建方法的质量都是实时评估的。反馈可能会建议动态替换或添加新的方法片段，以确保项目能够成功完成。特别值得关注的是那些没有直接衡量标准的复合属性，而且似乎也没有关于有效性、效率、协调或治理的普遍认可的模型。就像项目成功一样，很难说清楚实现它需要什么，但相对容易判断是否没有实现。我们可以通过错误或其他失败症状来检测这些属性的缺失，而不是试图证明它们的存在和实现。

方法执行评估会促使对项目约束和意外情况进行审查。反之，项目意外情况或约束的变化也可能促使进行方法执行评估。此外，方法执行评估还提供了一种额外的手段，用于检测和证明对方法或方法执行方式的更改是合理的。需要明确的是，这里提出的方法执行评估并不等同于或应该取代其他更严格的过程评估，它旨在直接、客观地评估方法的适用性，而不是通过过程评估人员的主观知识和经验来暗示其适用性。

2. 质量评估的关键挑