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