一，总结收获
团队合作开发项目已经好几周了，我们小组六个人也在这段时间一起磨合，一起合作，一起进步。
首先因为团队项目选择了北航MOOC手机客户端的开发，所以在课题明确的时候我们一开始就是开会分析工作量以及安排分工，虽然只是最初的安排也随着程序的进行偶尔更改一些人的任务安排，但是每个人也都在尽心完成自己的部分。我觉得团队合作有很多有优势的地方：
- 互相监督，明确分工，完成效率高。我们小组的分工为一人主攻UI，一人主攻博客，四人分散负责代码模块。所以并没有造成必须要等某一个人完成才能继续做其他人的工作的时间拖欠。
- 互相帮助，指导学习。第一次接触Android开发，虽然是java平台，但是比java要复杂很多，所以我在最开始学习的时候很有困难，基本上属于完全看不懂的状态，然后团队另两个同学因为之前有过Android开发经验，所以抽出自己的时间，从基本的控件到xml绘制，再到Android—java代码的攥写，他们都给我必须的指导，帮助我节省了很多时间。
- 任务流动，不会耽搁。在工程进行的期间，负责博客攥写的同学因为身体不舒服请假不能正常完成工作量了，所以我们协商之后将他的任务分散给了每个人，在闲暇的时候更新每天的scrum meeting.
- ……
当然团队合作也存在一些问题，因为我对Android studio并不是很熟悉，所以在第一阶段集成的时候因为我负责的个人信息部分没有完全完善造成拖延，结果整个项目因为我的问题导致时间浪费，我觉得很抱歉。接下来还有需要完成的任务，我也希望我们团队的每个人都可以打起精神继续努力！
二，阅读作业
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed. This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.
These patterns explore the forces that encourage the emergence of a BIG BALL OF MUD, and the undeniable effectiveness of this approach to software architecture. What are the people who build them doing right? If more high-minded architectural approaches are to compete, we must understand what the forces that lead to a BIG BALL OF MUD are, and examine alternative ways to resolve them.
（虽然大部分注意力都集中在高级软件架构模式是什么,实际上,很少讨论软件体系结构的实际标准。本文探讨这种最常见的部署的软件架构:大泥球。大泥球是一个简单,甚至随意,结构化的系统。它的组织,如果一个人可以称之为比设计基于私利的。然而,其持久的人气不能仅仅是罔顾建筑的象征。
这些模式探索的力量鼓励大泥球的出现,和不可否认这种软件架构方法的有效性。建立他们的人在干什么?如果竞争更高尚的建筑方法,我们必须了解的力量,导致大泥球,并检查替代方式解决它们。）
- You need to deliver quality software on time, and under budget.
- Therefore, focus first on features and functionality, then focus on architecture and performance.
我们团队的项目分工我负责个人信息以及软件设置方面，所以在我的时候因为Android studio页面的陌生都让我忘了java怎么写，所以导致最开始的函数都写在了OnCreate里，着实看的太难受，最后重新更新一下。
2/CatB – Cathedral and the Bazaar
大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。
市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。
我们团队选择在github平台上管理代码，Android Studio平台开发，每天通过commit,pull,push获取其他队员更改的代码，以及提交自己负责完善的部分。
所谓质量，只有在某人对它负责时才有意义，而这个“某人”只能是一个人，不能是几个人——二重奏除外。
我很赞同这个观点，想要确保的质量，必须每个人都认真负责好自己的部分。一个人或者两个人负责一个模块，人员能力+默契配合，至少要在思想上明确观点这一部分的质量取决于我，所以做不好的原因也很明显归咎于我，所以在这个压力下才能避免侥幸心理以及懒惰想法。
4/ Managing the development of large software systems: concepts and techniques
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
瀑布模型是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段。
瀑布模型的优点
（1）为项目提供了按阶段划分的检查点。
（2）当前一阶段完成后，您只需要去关注后续阶段。
（3）可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
（4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
5/Agile Method – by Martin Fowler
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
我们团队在开发的时候商量分配任务，每个人分别负责一部分模块。比如唐彬（主页面：热门课程，全部可能，我的课程），我的（个人信息：账户信息，软件信息，我的下载，我的课程）等等，每一部分都是自己负责xml绘制以及java功能补充，在调试过程中可以自己一边修改一遍测试。
第一轮发布实现的主要功能有在线视频播放，全部课程，热门课程浏览，个人信息显示等部分，第二轮迭代需要完成的是下载部分。
第一部分成果完成之后，我们团队抽出两个人专门负责试用阶段，给他们的要求是随便玩，想尽一切办法玩坏这个app，这样才能发现更多的错误。