大多都是自己的推论和想法。如有不恰当之处，还请指教！
第一版前言
这本书的目的是想让学生在一个学期内切实实践一些软件工程的方法论和工具，并且具体了解它们的优缺点。
树立 做中学（Learning By Doing） 的学习观。
给任课教师和助教的建议
理论课和实践课要在同一个学期。
教学模型
经典瀑布模型的教学会在不同阶段呈现不同的问题。学生自己没有完成理论知识到实践的转化。就算完成了一定程度的转化，也会因为全局观不足而破坏作业之间的连贯性。表现在学生前期的需求分析和设计不是为了后期的各个阶段做准备的，后期的各个阶段不是以前期的准备为基础的。
现实中的软件工程师职业发展与经典瀑布模型不同，两者顺序几乎相反。然而若要使用现实中的模型，需要有以前同学开发的程序，并且这个程序有一定的用户量。因此刚采用新的教学方法还是得从经典瀑布模型开始。如何减少这种模型的缺点所带来的影响？
以需求分析为例：
指定一个项目主题（仅用于需求分析）和几个特定的用户。让学生采访这些用户，制作原型并再次跟用户沟通。经过两次与用户的交流，在意识到自己辛辛苦苦做出来的软件很有可能是用户不想要的甚至可能推倒重来的时候，就能够稍微体会到需求分析是什么。
单纯地从理论上讲需求分析的重要性是没用的，学生怎么可能承认自己做出的东西会不符合用户预期？
师生关系
大学软件工程专业理想的师生关系是“健身教练/健身员”的关系
这点在福大会表现得比较明显。学生必须通过投分来选择任课教师，而张老师也在学生选课之前告诉学生选他之后会有什么样的得失。多数学生是主动来的，这也就表示他们是有准备的。
给授课老师和助教的建议
和学生沟通。在每次作业结束之后，问同学们软件工程给他们带来了哪些提高。
助教评分要能够将不同水平的同学明显地划分开来。同学们完成作业要求的某个点，并不意味着他至少可以得到“辛苦分”。助教在任意一个 check point 上有三个档次的分数：完成的很好（满分）、完成得一般（一半分数）、没有完成或者很粗略地完成（0分）。要敢于打0分，不然就是对优秀学生的极大不公。
另外一点就是作业各个步骤的权重。一个 ckeck point 本身的分数不高，但是如果没有这一步，会对全局造成比较大的影响。那么如果这一点得0分，也应该让与它相关的其他 check point 分数降低。
关于总得分的计算公式：
( X - min ) / ( max - min ) * ( B - A ) + A
- [A, B]为分数映射区间，例如[50, 100]表示学生最低得分为50，最高为100。不过如果有些学生得分太低，可以直接给0分。
- X 为学生作业总得分
- max 和 min 分别为所有学生作业总得分最高和最低的值。
鼓励学生向老师和助教提问。大部分学生会将问题憋在心里，懒得问或者不敢问。提问途径可以是：
- 博客中：每次提交作业，可能会有一两个点没有完成。把难点列在博客上，并说明自己做了哪些努力，这样助教才可以有针对地帮助同学们解决问题。
- 微信中：作业刚布置下去，可能有些要求比较模糊。学生可以主动提问，把要求清晰化。这也可以作为“需求分析”的过程。
助教和老师应能够听取学生的意见，并作调整。
没有老师第一次上课就能达到最好的效果，助教也不要期望自己能够一次做到最好。