六读《构建之法》——质量保障稳定和发布阶段

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了六读《构建之法》——质量保障稳定和发布阶段相关的知识,希望对你有一定的参考价值。

第十四章中,作者告诉我们如何衡量软件的质量,以及如何保证软件的质量。

首先,软件=程序+软件工程,那么软件质量=程序质量+软件工程质量。

程序的质量体现在软件外在功能的质量。软件工程的质量则体现在以下方面:

软件开发过程的可见性、软件开发过程的风险控制、软件内部模块、中间阶段的交付质量,项目管理工具的因素、软件开发成本的控制和内部质量指标的完成情况。

软件工程的质量衡量方法则使用CMMI(能力成熟度模型集成)理论。CMMI分为五个等级,初始级、管理级、明确级、量化管理级和优化级。每个级别都是更高一级别的基石。

对于某些“无需独立测试人员”的极端言论,在绝大部分情况下并不适用。除非团队里都是天才或者项目非常小。

而有了独立测试人员之后,也要避免以下情况:

1、有专人负责之后其他人员对质量不负责;

2、盲目信任“专业人士”扮演的角色;

3、为了自己的角色而做绩效优化,导致局部最优但全局不是最优;

4、分工画地为牢,将一些不该分的工作分开;

5、分工责任不明确。

 

第十五章则介绍了软件的稳定和发布阶段。一开篇便把我打进了“O型血”的人群:不知道优秀的软件公司会发布有已知缺陷的软件,因此嘴巴惊讶成O型。

此外还有A型(知道优秀的软件公司会这么做)、B型(不信优秀的软件公司会这么做)、AB型(对别人是B,对自己是A)

作者告诉我们,对于复杂项目应成立会诊小组,决定如何处理每一个BUG,是修复,还是设计本该如此,还是不修复,还是推迟。

作者还提供了DCR(设计变更)、解决所有已知BUG(ZBB)、最后回归测试、砍掉功能、逐渐提高修复BUG的门槛、逐步冻结等招数供我们参考。

最后,在发布软件之后也要召开“事后诸葛亮会议”,层层推进,找到问题的根源,总结经验教训。

 

以上是关于六读《构建之法》——质量保障稳定和发布阶段的主要内容,如果未能解决你的问题,请参考以下文章

构建之法阅读笔记05

构建之法06

《构建之法》读书笔记六

构建之法阅读笔记06

《构建之法》

构建之法阅读笔记04