1.总结：
经过了软工M1和M2阶段的历练，我提升了对软件工程的认知，在对一个工程的分层解耦，架构和接口设计上提升到了一个新的高度。另外在代码规范和团队合作上，我也有了更明确的认识。学习了这门课程, 还有老师们的多元化教课,不但让我从理论上掌握软件工程,还有从不同的实例,让理论和实践得到了很好的结合。整一个学期下来，总的来说还是学到了很多东西 的，有很多地方是值得肯定的，其实在我看来，软件工程与其说是一门课程，不如说是一门思想。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止 局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。
2.以前问题的博客：
http://www.cnblogs.com/hoerwing/p/4830486.html
3.解决的问题：
（1）软件开发时，比如web2.0的rest风格架构，前后端完全分离，然而其交接时，很可能出现问题，并且因为完全分离，所以有可能出现开发不同步的问题，前后端的交互耦合，开发同步的问题该如何解决。
这种大前端式的开发，非常重要的一点就是要在前期做好接口文档，并且在开发过程中严格按照接口文档进行编码，如果接口有修改，要及时让各个部分的开发人员同步最新的文档。这样在最后的对接阶段才能迅速对接，并减少bug。
（2）数据操作，和逻辑操作，实体操作等如何分离解耦。这和
（3）如果有效果的分层解耦，三层框架是什么。其实差不多是一个问题：
三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合”的思想。
a.表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。（负责展示而已）
b.业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。（关键在于由原始数据抽象出逻辑数据）能够提供interfaceAPI层次上所有的功能。，“中间业务层”的实际目的是将“数据访问层”的最基础的存储逻辑组合起来，形成一种业务规则
c.数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等。（关键在于粒度的把握）要保证“数据访问层”的中的函数功能的原子性！即最小性和不可再分。“数据访问层”只管负责存储或读取数据就可以了。
（4）过度解耦，或者大规模模块化开发时遇到的依赖冗余问题如何解决。
这就要把握一个度，模块化粒度的度。这是在初期架构时就决定的，我们要对各个功能的开发成本，复用频度，效率问题等做一下评测，之后再决定在架构中的模块如何划分，粒度是怎样的，这种划分造成的依赖冗余会造成多大成本和影响，综合考虑，将其影响降到最低。
（5）如何在开发成本和收益之间权衡需求，如何判断刚性需求，伪需求。
b. 需求转化阶段（用户需求-->产品功能），不能直接照着用户说的做，而要分析用户的目标，这得靠领域知识和对目标用户的理解。
c. 产品概念验证，自认为想清楚了新功能，在动手开发前，再找几个用户沟通一下吧，注意方式方法。
d. 新功能上线时，多用用灰度测试，可以先用较低的成本上线一个满足一点需求的功能，看看市场反馈。
人人都爱出主意，所以，伪需求的最常态就是“用户提出的解决方案”，而本例中“用户为了掩盖真实目的而欺骗”的反倒不是很多，作为产品经理，处理方法类似，都需要找个这个方案背后要解决的问题，然后给出自己的方案。
（6）如何在开发过程中设计框架和预留接口使得迭代更加高效，维护更加轻松。
这要考验项目之初对用户需求的分析程度和架构师对架构的理解和对未来功能的展望。对我自己来说，我通常是考虑到后来跟这个功能有关的扩展时才会考虑这个问题，我觉得这样还是不够的，我希望能找到一套工程化的通用规范或者方法来高效的解决这个问题。
5.产生了哪些新的问题，请提出:
（1）如何进行高效的测试，自动化测试，黑盒测试，产品的安全性应该如何保证。
6.同时我们还读了8篇软件工程相关的论文或博客，你回头再看看这些文章，有没有新的体会?
没有。。。。。满篇英文再读还是那么费劲【捂脸】
7.知识点：
（1）需求：要从用户出发，做好用户定位，用户需求调查，市场调查，并且分析用户究竟想要什么，而不是他说他想要什么。
（2）设计：框架搭建时要注意分层解耦，又要注意依赖冗余，一定要做好接口文档和代码规范。
（3）实现：源代码管理要做好各个版本的迭代，各个模块之间对接时尤其要注意代码管理。还要注意为以后的开发迭代预留好接口。
（4）测试：回归测试和单元测试都要进行。压力测试要和日志相结合，解决并发效能问题。
（5）发布：要做好宣传工作，要从用户得到反馈。
（6）维护：要做好日志监控和数据备份。服务器的性能信息也要做好监控。