标签：软件开发 变更 回归 bsp 告诉 天才 构建 工具 优化
第十四章中，作者告诉我们如何衡量软件的质量，以及如何保证软件的质量。
首先，软件=程序+软件工程，那么软件质量=程序质量+软件工程质量。
程序的质量体现在软件外在功能的质量。软件工程的质量则体现在以下方面：
软件开发过程的可见性、软件开发过程的风险控制、软件内部模块、中间阶段的交付质量，项目管理工具的因素、软件开发成本的控制和内部质量指标的完成情况。
软件工程的质量衡量方法则使用CMMI（能力成熟度模型集成）理论。CMMI分为五个等级，初始级、管理级、明确级、量化管理级和优化级。每个级别都是更高一级别的基石。
对于某些“无需独立测试人员”的极端言论，在绝大部分情况下并不适用。除非团队里都是天才或者项目非常小。
而有了独立测试人员之后，也要避免以下情况：
1、有专人负责之后其他人员对质量不负责；
2、盲目信任“专业人士”扮演的角色；
3、为了自己的角色而做绩效优化，导致局部最优但全局不是最优；
4、分工画地为牢，将一些不该分的工作分开；
5、分工责任不明确。
第十五章则介绍了软件的稳定和发布阶段。一开篇便把我打进了“O型血”的人群：不知道优秀的软件公司会发布有已知缺陷的软件，因此嘴巴惊讶成O型。
此外还有A型（知道优秀的软件公司会这么做）、B型（不信优秀的软件公司会这么做）、AB型（对别人是B，对自己是A）
作者告诉我们，对于复杂项目应成立会诊小组，决定如何处理每一个BUG，是修复，还是设计本该如此，还是不修复，还是推迟。
作者还提供了DCR（设计变更）、解决所有已知BUG（ZBB）、最后回归测试、砍掉功能、逐渐提高修复BUG的门槛、逐步冻结等招数供我们参考。
最后，在发布软件之后也要召开“事后诸葛亮会议”，层层推进，找到问题的根源，总结经验教训。
标签：软件开发 变更 回归 bsp 告诉 天才 构建 工具 优化
原文地址：http://www.cnblogs.com/sunmoonlake/p/6885360.html
