快速阅读教材之后存在的一些问题：
①：第五章中开始讲了团队和非团队的区别，之后讲的各种模型可以看出团队中分工的重要性（开发人员和测试人员以及各种其他人员相互协调才能做出好的软件）。软件开发过程中，开发人员和测试人员各司其职。但是，测试人员开始工作是在开发人员完成代码之后，这两者之间是不是应该在代码完成之前或者是在代码完成之后的测试工作中就应该有一些交流或者是合作？测试人员在开发人员写代码的时候是要干什么呢？开发人员在测试人员测试的时候是要做什么呢？
②：第八章 8.6 节讲到了如何对项目进行计划和估计，第九章中讲到了PM的各种职能，PM要带领整个团队进行开发，所以，理想情况下，项目经理应该是要对整个过程都有一个比较清楚的认识，比如说在什么时间点要完成什么样的效果（也就是估计），但是，在我们课堂上临时组建起来的队伍，好多同学第一次担任经理这样一个角色、开发人员的好多技能都要现学的情况下（按照书上所讲，这种情况下很难有一个较精准的估计），如何对一个团队的开发流程有一个比较详细的掌握呢？
③：第八章中 8.2 节讲到 “很多人和很多机构都是软件的利益相关者，软件团队在分析软件需求是要考虑这些利益相关者”，并且提到我们团队中的好多人都是软件的利益相关者。在对用户进行需求调查时，如果团队中对一种功能的喜好上出现了近似等比例的分歧，书中虽然提到了要给机会让工程师提出需求和一件，但是如果时间、精力有限的情况下，从何角度出发做一个合适的选择？
④：第八章中 8.5 节讲软件功能的定位，可以看到，软件的功能分好多种，如果在实现了必要功能之后，团队中出现了对性能的优化或继续扩展一些辅助需求分歧的情况下，应该如何进行抉择？
⑤：书中第七章中的第三节讲到MSF团队模型
在MSF团队模型中，任何技术项目都必须达到特定的关键质量目标，才能够被认为是成功的项目。
书中下面也提到了团队中每种角色都有自己特定的工作，就像是开发人员被认定的质量就是程序能够正常执行，功能正常实现.....书中也说每种角色之间的质量目标可能会有冲突，所以，每种角色的质量目标应该是如何形成的？
⑥：书中第二章 2.3节个人开发流程 中讲到了个人开发中有一些复审的流程（代码复查），根据 “百度百科”中 个人软件过程 对代码复审的流程来看，虽然是个人开发，但是自己复审自己的代码应该也是可行的，可如果是在有限的时间内，要完成一个相对完善的功能，个人软件开发中的某些耗时的过程是不是可以简化？
软件和软件工程词汇的出现：
有据可考的“软件”一词最早出现的地方是在1953年8月由Richard R. Carhart 发表出来的一篇电子工程文章中；
“软件工程”这个词汇最早出现是由 Margaret Hamilton 在参加“阿波罗计划”的时候提出的，提出这个词汇是因为当时软件在阿波罗计划中不被大多数人所重视，而 Margaret Hamilton 却认为这是一门艺术，并且有属于其自己的地位。所以，Margaret Hamilton 提出这样一个词汇来将软件和其他东西相区分开。
软件工程发展过程中有趣的冷知识或冷故事
1975年，艾伦和盖茨给Altair 8800计算机写了个BASIC解释器卖给MITS，他们很快完成了解释器，甚至包括自己的IO系统和编辑器，一共只需要4k内存。 不过最后他们发现还需要一个引导程序将这些东西从外存整进去。 Paul Allen在飞机航班上完成了这项工作。这是1975年，没有笔记本。他用的是纸笔。写的是8080机器码。
-----引自 <知乎>
目前流行的一些源程序版本管理和项目管理软件的优缺点：
| 优点 | 缺点 | 使用人数 | |
| MTFS | 能有效实现Scrum； 能够和vs无缝对接； 任务、项目进度可视性强； 集成了项目管理、版本控制、Bug跟踪； |
访问速度慢； 系统兼容性差，不支持xp； 有一些细节没考虑到用户体验。 |
Unknown |
| Git | 仓库中的版本控制信息不复杂； 版本库本地化，支持离线提交； 完整克隆版本库，比较合并性能好； 分布式版本库，无单点障碍，内容完整性好。 |
缺乏良好的封装； 版本之间命令不兼容； 命令复杂，命令名字有冗余； 命令行中信息输出用户体验差。 |
Unknown |
| Mercurial | 服务器部署容易； 内部封装好，扩展性好； 简洁优雅，命令相对易学易用。 |
功能弱一些； 支持社区略差； 分支管理不灵活。 |
Unknown |
| GitHub | 可用性好，十分方便； 用户多，项目多，利于交流学习； 有自己的十分强的功能（pull request,issue）。 |
学习曲线陡峭； 对中文支持太差； 对企业来说，价格过高； 免费套餐不支持私有项目。 |
15,000,000 （2016年） |
| Bitbucket | 支持私有免费项目； 提交大文件速度快。 |
不容易找到项目； 社区活跃度不是那么大。 |
6,000,000 (2017年) |
| Trac | 十分灵活，支持定制； Trac有良好的扩充性； Trac的权限体系是比较完备的设计。 |
核心功能很少； 不支持多项目； 对中文的支持差； 需求和缺陷没有分离。 |
Unknown |
| Bugzilla | 定制功能很强； 对语言的支持很强； 免费，响应速度较快。 |
UI设计差； 安装过程繁琐。 |
Unknown |
用户人数来自 wiki
上表中大部分软件的用户人数并未找到。 所以，找到这样两张图作为参考比较
图一中的变量是仓库数量，虽然不是人数，但从仓库数量也一定地反映了使用情况。可以看出，git在所有软件中份额是最大的，紧随其后的是Subversion.
图二比较了一些源代码管理工具，从三个方面（users,projects,ranking）对各个软件的情况进行了统计，从三个方面不难看出，github的使用是最多的，也是最受欢迎的。