一、回顾上课之初的五个问题:
问题1:第二章个人技术和流程提到效能分析，我发现提高速度的方法都是通过用软件本身的代码来实现或者减少调用函数的次数，我想当一个程序过分的追求它的效能的时候，他的稳定性有保证吗？
答：这个问题现在没有困惑了，当在做个人项目作业的时候有过效能分析，提高效能的前提当然是程序能够按照要求正常的运行，所以稳定性是肯定的。可以理解为先确保程序是可运行的，在此基础上再进行效能的测试和提高。
问题2:第一章和第三章都提到一个职业的软件工程师的职业程度需要用一些数据来测量的，就像nba用一些数据来测量一些球员的水平一样，可是以我目前对nba的了解，有些能力是在数据上体现不出来的，比如策应能力和间接助攻能力，所以我想这些数据可以扩充一些，更全面一些或者按照不同人的侧重于性格来评价各种方向侧重的软件工程师。
答：这个问题现在没有困惑了，软件工程是一个工程类的技术，既然是工程类的技术就要有一个量化的衡量标准，如我们所做的psp，我们所有的工作都会摆在台面上来评价与价值衡量，而为止付出的不为人知的努力并不是客户所需要的。而关于性格来评价一个软件工程师本来就是错误的，软件工程师本来就是不掺杂着任何感情因素的，评价一个软件工程师只能凭借逻辑和理性的分析来评价，不能该带有情感的倾向。
问题3:第三章初级软件工程师的几种成长中一共列出了5种成长方向，一个是技术技能的掌握的提高，一个是积累问题领域的知识和经验，一个是对通用的软件设计思想和软件工程思想的理解，一个是提升职业技能，最后一个是实际成果。按照我目前个人浅显的理解，我认为这5个方面是成梯度呈现的，因为一个初级的软件工程师也是一个精力有限的人，当他把自己认为最难的部分处理好，才会发现一些之前觉得更简单的问题往往最难处理，就像考试一样，最后的难题往往是一些定理的证明。
答：根据这个学期的学习，我想这5种成长方向是同时展开的，只是在实际的运用过程中你的任务会更侧重于哪个方向的发展，像技术技能掌握的提高和积累问题领域的知识和经验以及对通用的软件设计思想和软件工程思想的理解是相辅相成的，进而在不知不觉中我们的职业技能自然而然的就提升了，也有了一些实际成果。
问题4:第六章提到了敏捷流程，看了很多的方法有点蒙，粗略的以为有一些明确的任务目标分块的用敏捷开发比较适合，而一些只有大致方向的用传统的瀑布式的比较好，但我我想知道当一个项目的开发从开始用传统的瀑布式的开发后有了明确的目标分块，这时还可以转换为敏捷开发吗？
答：我个人理解瀑布式开发和敏捷开发从根本上就是两个事情，瀑布式开发的核心是文档，只有在开发的后期才能见到软件的模样，而且并不能进行迭代和用户的反馈。而敏捷开发是一个与之截然不同的过程，首先他要快，快才能跟上时代的步伐，其次是以人为本，要客户参与进来，实时的进行反馈和更改需求，还有就是要实现小版本，快速的功能展现。所以这两个东西是不能转换的，可以从新开始。
问题5:读了第8章的需求分析，我终于了解了nabcd的含义，分别代表需求，做法，好处，竞争和推广。又了解了功能的定位了优先级，一个正常的需求功能包括了杀手功能和外围功能，我想这个杀手功能是以一个纵向的发展更好还是以横向的发展更好。
答：我个人认为是纵向的发展更好因为杀手功能是一个项目的王牌功能，是你吸引客户的功能，即是一个痛点也是一个亮点，而从实际的问题出发，解决一个或者优化一个问题，把它做到的足够好，需要花费大量的人力资源和时间的，所以杀手功能很少甚至不可能是一个横向的发展，就像汽车行业，奥迪的灯做得很突出，宝马的操控和奔驰的舒适以及马自达前卫的外观这都是有目共睹和有倾向性的，他们都在外围功能过得去的情况下，尽一切努力来纵向发展杀手功能。
二、新提出的五个问题:
问题1：我有一个很笼统的疑问，一个项目我们在做工程控制，比如事先制定好计划，绘制燃尽图，要对工程有个预期的时间的把控，还要绘制一些uml图之类的等等，但在这个信息发展飞速的时代抢占市场的先机不主要吗？当我们做完这些的时候，假如市场已经被别人占领，岂不是徒劳了吗？
问题2：在我看书的过程中，了解MSF这一套大型的开发指南。其中介绍了MSF的9个基本原则，最重要的也是最基本的就是推动信息共享与沟通，当中提到会把项目过程中的每人的错误记录下来，我们似乎还没有实行这个提议吧？
问题3：在384页之后是给任课老师和助教的建议，我想这里应该加一个（选读）的字眼，毕竟这本书并不是仅仅针对教师来编写的，加上选读之后可以在主观上看上去这本书是写给广大的对软件工程感兴趣的人们，或者改一个标题，具体是什么没想好。还有这本书只有大概每章的页码，并没有每一小节的具体页码啊，我还是希望能够加上的，这样找的时候方便一些
问题4：在114页和115页敏捷流程的经验教训中，第6点Scrum估计不是一个“合同”，领导们不要把它当成一个合同，而第七点钟又说不要和管理层谈“流程”，他们只关心结果。那我们在Scrum谈论的不就是流程吗，既然领导是不关心的完全不用出席啊，但我想这也失去了意义，还有这个估计可能不够准确，当你把自己每天订的都过高的时候，但实际没有完成，领导是否会觉得你对自己估计不够准确、不够专业。而每天都订的过低的时候，领导又觉得你是在消极的态度或者能力不够。4
问题5：在122页练习与讨论中，瀑布式开发和敏捷开发这两种模式该选择哪一个，我也很困惑，下面也列出了几个选项供人们参考，从这些选项中我可以理解当我们环境相对比较恶劣的时候就用瀑布式开发吗，但我认为软件开发的初期都是环境比较恶劣的啊。
三、对学弟学妹说的话：
刚上软件工程这个课的时候，你可能会对杨老师会有一个比较深的印象，他会颠覆你在大学中对课程的概念（上过《构建之法》这门课的除外），你可能会想杨老师又是一个形式主义者，他说的什么分数啊、测评啊都是扯淡的。当你这样想的时候，你就会觉得接下来很痛苦、很惊讶，因为他的作业完全是按照他对你们的计划执行的。这个时候你们不要去抵抗（因为抵抗并没有用），选择接受，而且尽你最大的努力去完成，记得是按时完成（以后就明白了），你就这样在一天天的抱怨中上着杨老师的课，也在一天天的成长，当你一个学期之后下来你会发现你懂的收获挺大的，不管是语言的表述还是对工程的控制，不能做得那么准确，但最起码你用过，下次会做的更好。不要觉得杨老师不近人情（确实不近人情），因为在他的字典里工程是没有人情可言的，他也是对事不对人的。最后，祝愿你们能够在一学期的风雨中能挺过来，当乌云散去的时候，你翻翻你的博客记录写着你对下一届的寄语，发现这是一件挺有趣的事情。
四、如果重新来过
1、我会在一开始就在交作业的前几天就开始准备，不能该等到快交作业的前两天开始着急，弄到半夜。
2、我会在一开始就学一门面向对象的语言，而不是在学期中才开始学习c#。
3、我会在团队项目开始之前对准备好的项目进行大量的学习，这样就不会在项目开发中显得手忙脚乱。
4、我会在事后诸葛亮会议中更加踊跃的提出自己的见解，虽然有时候觉得很蠢。
五、对老师说的话：
感谢的话就不说了，感觉老师你也不太兴这套。
1、老师应该先交我们一些实际的东西，因为有些东西你第一次提出来我们真的很难理解，然后上网去查也是觉得云里雾里，所以有些人就选择放弃了，我觉得可以你讲一点然后让我们自学一点，这样效果会更好。
2、老师可以将开始作业留的再少一点，因为都是一些生疏的知识，我们也很难消化，有些底子的同学可能就勉强完成，没有底子的同学真的很难完成，这样就会增加抵触情绪。
3、虽然感谢的话打算不说的，但是还是觉得您是一位受人尊重的老师，还是要感谢您一下，老师注意一点身体，虽然你和我们在课上总是用金钱来衡量一些东西，但我感觉的出来你也是一个不光只谈钱有梦想的人，我们可能拖累你的梦想了，这里感到抱歉了。。。