《需求分析与系统设计》阅读笔记（七）

　　这本书是上个学期读的，那个时候还没有系统学习软件体系架构和软件过程管理，仅仅是抱着“简单了解一下需求分析”的目的来读书，而这学期学过了课程之后，再读起来显然有不同的感悟。前面的章节若有了新的感悟会再起一篇，而今天这篇承接上次的内容，讲的是质量与变更管理。

　　近期软件过程与管理刚刚结课，正在为考试复习，所以看到管理二字总会想到记下的那些知识点。质量管理确实让我感到许些亲切。“质量管理与人员管理，风险管理及变更管理等活动都属于整个软件过程管理的一部分”，这是书中原话。软件的质量是甲乙两方的关注点，前者希望软件质量越高越好，后者希望软件质量可以让甲方满意。如今的软件开发团队有了更加细致的任务划分，作为架构师，或者说小组领导者就是软件过程管理的直接负责人，软件质量什么样子要由他（她）来把关。质量管理主要针对软件产品及开发产品时所采用的软件过程，显然不同的软件对质量要求不同，但对软件质量的评定标准大体是一致的。我学习到的有关这方面的知识被称为质量属性，即可用性，易用性，性能，可维护性，可测试性，安全性等等，而书中除了这些之外，还补充了正确性，鲁棒性，可复用性，协同工作能力等等。不管它怎样命名，对软件质量判断总归是从用户体验，开发情况两个方向去考虑的。用户希望软件能够方便易用，功能齐全，安全可靠，反应快捷，由此衍生出了性能评估等等；而开发者则需要想更多的东西：自己的软件是否具有良好的兼容性，可以在其他系统平台上运行？如果用户提出更改需求，能否快速做出更改，或者以可以接受的成本对软件进行重构？

　　对软件质量进行管理，就要有标准去界定是否合格，上文已经给了标准——质量属性。那么评定过程该如何去做呢？评审和测试。随着专业课的深度学习，我被安排写了很多文档，需求分析文档，测试文档等等。这些文档的内容就反应出软件的质量问题。评审过程藉由评审员根据检查表或者某某文档内容，按照自己的思路去测试软件，虽然评审与测试本质上都是为了找到软件缺陷，提高软件质量，但评审与测试还是有很大不同的。软件测试现在已经有了比较完整的体系，甚至已经可以单独设置一门课去学习，究其原因是软件测试终归要跟底层代码打交道，因为你不可能说自己做软件测试只做黑盒测试，测试过程中需要测试员理解开发者的思维，最起码你应该知道自己要测试的模块是什么逻辑思路。而评审对这一方面显然非常随意，要注意你是评审员，你是评委你说了算，你可以站在用户的角度提出“无理”的需求，这些都是你的自由，只要最后能把缺陷改正就是好的。

　　变更管理就更好理解了，它只负责用户提出需求变更的时候，对变更过程把关。变更管理还是离不开测试，不，是整个软件开发过程都离不开测试。变更管理的整个操作流程中，最常见的就是请求。从书中给的图示上看，变更管理就是：变更请求——提交请求——测试请求——质量管理的过程，是的，变更管理的最后，还是对软件质量进行管理。