这段时间阅读了《构建之法》的剩余章节。
第14章承接前文软件测试，讲了软件质量保障需要做的工作。作者先介绍了软件质量的衡量可利用CMMI,又讲了保障质量所需付出的成本（预防、评审、内部故障、外部故障），软件测试与质量保障是不同的。软件质量保障包含测试。
第15章——稳定和发布阶段，作者把代码发布时可能遇到的问题列出，也讲诉了按时发布的招数DCR、ZBB，最后项目的总结与回顾。可见，软件工程不光是完成代码即可，作为一个项目，它的生命周期还没有结束。
第16章——IT行业的创新，创新是时下热门的词语，天天都能听到看到，抓住创新的时机很重要，而创新受到很多因素的制约。
第17章——人、效绩和职业道德。软件团队中存在3种人，猪、鸡和鹦鹉。猪全身心投入工作，而鸡只投入了一部分精力，鹦鹉则是动动嘴皮。其实在生活工作中大部分人都想做鹦鹉，但只想不劳而获是不对的，在学校时可以靠朋友，但未来工作时没有实力，工作可能就没有了。希望我们团队可以凭自己努力做好程序。软件团队的合作阶段有萌芽、磨合、规范、创造等。个个行业都有其职业道德，软件工程师也不例外。
读完《构建之法》对软件工程方面有了更深的了解，邹欣老师这本书，写的不像一般课本那样死板，举了和多课外的实例与软件工程的知识相结合。书的内容从介绍“软件=程序+软件工程”开始，先是个人编程再到两人合作及团队合作。也讲了软件工程的方方面面，如需求分析、设计实现、测试等。软件发展产生的过程离不开人，程序员及用户是这过程中重要的参与者。
最后，在阅读计划中我曾提出如下问题：http://www.cnblogs.com/a1397240667/p/5247236.html
1.怎样确定一个软件“足够好”，并且可以发布了？
很显然，软件发布受到方方面面制约，不是程序员觉得技术上很完美就可以称得上“足够好”，实际要考虑工期、预算以及客户的需求。在满足客户最重要的需求的同时，还要赶得上多变的市场。有舍必有得，我们只可以完成相对不错的软件。
2.个人软件开发流程PSP是依靠工程师自己收集数据分析，那么这个过程中确保数据的真实性？
就我自身而言，很难一直坚持下去。所以实施过程中自觉性很重要。
3.团队合作有多种模式，如何确定自己的团队所适合的模式?
需要团队的管理者对队员的特点有清晰的认识，在合作过程中摸索。
4.现代软件工程方法论大致可以分为重方法论和敏捷方法论两大阵营,如何选择适合的软件工程方法论？
重方法论更加强调前期设计，为未来设计；而敏捷方法论则更加强调只为现在设计，未来再重构它，而就是这个最为本质的区别才是根据项目实际特点进行正确选择的基础。需求分析员应该基于对业务领域的了解，正确地评判项目的特点，为开发团队选择适合的软件工程方法论提出建议。而邹欣老师的博客也给了确定方法的建议http://www.cnblogs.com/xinz/p/3852390.html
5.MSF适合大学里面的团队吗？
随着课程的学习，我认为MSF这一模型不错，但在团队中实现不容易。当下的学生对学习的态度多是“应付”为主，而到了编程时，多半还是一人编程，其他人看着。