第十一章，软件设计与实现：
典型的开发流程；开发阶段的一些管理方法：每日构建，小强地狱，构建大师。
从Spec到实现，拿到文档后要做的基本流程，就像是做某道题的过程一样。
从功能需求到提交签入大部分步骤都有Bug，如果Bug可修复还要再从详细设计这一步往下走，最后的自动测试和功能全面测试发现Bug了还得从开始一步步做，开发人员的标准工作流程步骤多，较繁琐重复，
但按这个来做出来的软件确实完美。开发阶段的日常管理中闭门造车算是基础，给员工时间，让其“沉浸”在自己领域的世界里，安心开发；每日构建，每天或至少每周完成构建，来提升团队积极性；构建大师，
看名字以为是构建强者，原来是导致构建失败的成员，授予“构建大师”称号；小强地狱，让Bug过多的小强“入狱”，解决到一定程度后再出狱。
第十二章，用户体验：
考虑用户体验的各种角度，认知阻力，用户体验的衡量标准
短期刺激和长期影响对用户算是直观上的体验，短时间不断让客户感到新鲜感，长时间也可以让客户不厌倦。某银行反假币电子邮件的超长电子邮件的例子，一方面算是考验投诉人的耐心，另一方面算是做的较
差，没有从用户的角度出发。
在用户使用一段时间后可以让用户填写相应的问卷，询问其中做的不太使人满意的地方和做的较为出色的方面，从用户本身给出评价标准。
第十三章，软件测试：
各种测试方法
所谓的黑箱/白象，是指软件测试设计的方法，不是软件测试的方法！注意“设计”二字。
无论哪种方法，都是找出软件中的错误地方，这一般是开发人员自己的工作，以前对测试投入较少，基本是代码写完之后。随着科技的发展，现在的软件更多功能，更加复杂，更加大型，不仅要测试错误的地
方，还要保证质量好，安全性高等。将整个过程结构化，程序结构化，测试结构化，可以一步步进行检测，先单元式测试，再集中起来测试，再系统测试，最后对测试做评估，对软件的各方面可以以打分等的方
式给出，再进行二次检测，直到大家都满意。这个过程需要各个部门一起做，多讨论，多沟通，达到都满意的效果。
第十四章，质量保证：
软件的质量包括哪些方面，如何衡量软件工程质量。
和第一章给出的定义一样：软件质量=程序质量+软件工程质量。“软件的开发过程有三个主要的特性：“好”、“快”、“便宜”。通俗的理解是“软件在功能、成本、时间三方面满足利益相关者的需求”，各个方面都需要
好好斟酌，绝不是敲敲代码的事，还得注意客户，时间等方面的问题。不单是软件，其他别的任何东西，质量上不去，没什么客户敢用，团队花心血做的软件无质量保证，那心血有很多算是白费了。
明确CMMI的等级，在每一级上严格实行，在过程中把质量保证上去。
第十五章，稳定和发布阶段：
软件项目的会诊，软件按时发布的招数，项目的总结和回顾：
看完开头，我已经属于“O型”了，“他们不知道这一点，因此嘴巴惊讶成O型”，对于复杂项目应成立会诊小组，决定如何处理每一个BUG，是修复，还是就是这样设计，还是不修复，还是推迟。
给了众多招数，设计变更，ZBB，最后回归测试，砍掉功能，逐渐提高修复BUG的门槛，逐步冻结。发布之后，开“事后诸葛亮会议”，通过这次项目，我们学到了什么，我们有什么经验教训。
第十六章，IT行业的创新：
创新的迷思打破普遍的错误印象，新商业的诞生，最关键的是灵感，但灵感不会在每个人脑海里随之产生，好的灵感不一定来源于某个领域的专家大佬，但是灵感来源于善于捕捉需求的人，敏锐地察觉需求，走
在较前列，明白人们的需要。创新者也不总是一马当先，很多领域的领导者可能不是这一领域的开拓者。
创新的时机给了很多，给了黄金点游戏的12次记录，在一定程度上反映了不适时的新方法往往收不到预期效果，创新基本涵盖三点：了解团队能力、产品方向和大环境的趋势。后面给出的象限分类解决了不同的
处理方式。