一、对前期提出的问题的回答
1.在先修课程基础薄弱的情况下，该如何学习软件工程？
在软件工程的学习中，代码和先修课程并不是最主要的。因为在开发软件的过程中，编写代码的工作量其实只占不到所有工程量的30%，而后期的管理和维护更是占了60%到80%之多。软件工程课学习的是软件开发的思想和过程，至于先修课程基础薄弱或是不擅长代码这个问题，我们可以学习中一点一滴的积累，慢慢弥补。代码只是开发软件这个浩大的工程的一个小小的过程。
2.这次我们课程的主要学习方式是“做中学”，强调实践的重要性，但是大家都知道在这门课程未改革前，我们所学习的软件工程课的最后的考核方式都是理论笔试，而有些考点是相对滞后的也是我们在实际操作中用不到的，那么这些理论在我们的学习中还需要掌握么？
理论可以指导实践，实践可以检验理论，理论与实践的相结合才是最好的学习方法。虽然这学期的软工课学习方式是“做中学”， 偏重实践。但是实践时也需要强大的理论支撑。
3.用户和开发人员看软件的角度不同，那么书中写到的“足够好”的软件更侧重于谁眼中的“足够好”？
我认为，“足够好”是在双方眼里的“足够好”。首先开发人员认为这个软件已经比较成熟、功能较完善、可维护性强……在开发人员眼中，它已经做到“足够好”了以后，发布推广。其次是用户使用后，认为它“足够好”。两者达成一致意见后，都认为是“足够好”，这个软件才真正做到了“足够好”。
4.在结对编程中，哪种结对模式更好？实力均等的组合还是一強一弱（一人带一人）的组合？
我认为，每种组合各有利弊关键还是看个人的学习态度。我们结对编程时遇到的最大的困难就是编码问题，如果学习态度不积极，编码能力一强一弱组合会有人懈怠，最终结果是组合只靠编码强人。实力均等组合很可能双方都消极怠工。所以，如果我们的主观想要学习，无论是哪种组合我们都会有收获。
5.对瀑布流程和敏捷流程不是十分理解。
瀑布模型是传统的软件周期模型严格遵循软件生命周期各阶段的固定顺序：计划、分析、设计、编程、测试和维护，上一阶段完成后才能进入到下一阶段，整个模型就像一个飞流直下的瀑布。
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
二、总结本学期这门课程的体会
这学期的软件工程课接近尾声，回顾这一学期的学习有许多收获。
对“做中学”的感触：上这门课之前就听说软工课是一门很枯燥乏味的理论课，而这学期的软件工程课进行了改革，遵从“做中学”的学习方式。我认为，这种学习方式比较适合我们学习的提高。之前我们理论课的学习都是糊弄过去的，考试前两周开始疯狂的“学霸”模式，这两个礼拜要掌握之前学习的所有理论知识以应对考试，这种方式学不到东西。现在的这种学习方式，每周更新博客作业，检查作业的方式公开透明，学习态度不得不端正起来，而且这种方式让每个人都动了起来，不能说有多好的效果，但我认为做了一定比不做强。
对“结对编程”的感触：之前的课程中，我们都是个人编程为主，基本没有接触过合作的项目，这次结对编程对我来说是一个新的体验。在结对编程的过程中，我认为两人合作是相互学习的过程，在遇到问题时，两个人讨论，提出自己的解决问题的方法，不光是自己个人能力的提升也为伙伴提供了解题思路相互促进相互学习，提高效率。
对“团队编程”的感触：团队编程是在结对编程之后，比起结对编程，团队编程的团队协作和沟通能力占主导地位。团队编程人数较多，如何公平合理的分配任务十分重要，这个时候就考验到我们的团队默契程度和沟通能力，团队协作的越好，完成软件的质量越高。
以上是我对这门课程其中感触最深的部分的体会。最后要感谢老师和同学在这学期对我的帮助！
三、对课程的建议
我觉得我们最后可以以班级为单位进行一次头脑风暴，在有余力的情况下，班级团队制作出一个“足够好”的软件。