一、个人阅读作业+总结
银弹：
我比较同意“没有银弹”。
“There is a Sliver Bullet”这篇文章中提出，依靠面向对象思想就能解决问题，不需要掌握所有情况下的具体实现方法。
但是在这学期的团队开发经历中，我觉得，很多时候明确需求和改变需求也是影响软件工程开发效率的重要因素。而改变需求又是无法避免的。面向对象虽然便于重构一部分代码，但无法完全应对可能变化的需求。
大泥球：
文章中提到，一个系统中有大量“THROWAWAY CODE”被称为“大泥球”。“THROWAWAY CODE”是开发过程中针对某个问题写的一段快速而又不可复用的代码。
我觉得我们的项目可能深受其害。在调试的时候因为这个花了不少时间。
想解决这个问题，首先从架构上就要十分清晰。我觉得普通的大学生可能比较难以解决这一问题。尤其是时间不那么充裕的情况下。
其次，一定要规定好各个模块的接口，数据结构等细节，否则是不可能复用的。
大教堂和集市：
- The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC were presented as examples.
- The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.
我们团队用的偏向于大教堂模式。虽然代码开发过程中一直是公开的，但实际上能修改的只有开发团队。
迷失：
我觉得没出现这种情况。
我们的游戏开发完全依赖于cocos creator，除此之外没用到别的工具或是插件。而cocos creator是一个整合好的平台，不需要什么依赖就可以运行。
Worse is Better:
我觉得可能要看软件需不需要长期的维护。
如果是发布之后就不管了的软件，或许可以放弃完整性。
或者是直接推出新版本。
但是实际上很多软件都要一直维护，这种情况下我觉得在完整性上所做的花费很可能要比事后维护来的少。
瀑布：
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。
这种开发方式十分模式化。但是模式化要付出巨大的代价。非常不灵活，需要大量文档，难以应对需求变化。
敏捷：
我们的开发流程可以说是极端化敏捷。
alpha版本只更新过一次文档，之后的改动全是开发人员自己决定的。UI部分连文档都没有。
beta阶段好了很多，但还是以敏捷为主。由于cocos creator限制了UI部分的并行开发，开发者之间需要经常交流，实时确定分工。
在此期间做的更改也都会先写进代码后更新文档。开发流程中也经常进行结对编程。
方法论：
软件工程是个应用性很强的学问，而且实际应用中要经常面对变化。
方法论只能保证一部分大体模式上的问题不会出现，但并不能解决一些细节问题。而且一种方法不太可能应对所有不同情况。
在项目规模不是很大，参与的人员没有很多经验的时候，系统的方法往往会难以执行。
我觉得只能起到理论指导作用，针对具体情况作出改变是必不可少的。
二、回顾自己一开始提出的问题
http://www.cnblogs.com/crvz6182/p/7588101.html
1.
我觉得是这样的。至少是对于新手来说。
我们alpha阶段失败在需求几乎不明确，beta阶段失败在没有测试，导致后期debug耗时巨大。（cocos creator对单元测试不支持）
2.
我觉得找出错误是优先的。
因为我觉得软件工程的最低目标是开发出一个可以正常工作的实现了功能的软件。
4.
我们没有团队内外的交流，但是PM一定是要管理流程的。
beta阶段得益于PM的管理，我们才能保持进度。
5.
从我们的开发流程来看，最好能细化到具体的接口规格和每一部分的功能，这样才能方便分工和对接
6.
更多的反馈，更多的改进机会
7.
我觉得是依赖的。我觉得在这次开发过程中很多新想法在实现的时候就发现cocos creator可能不支持这么做，就放弃了。
8.
相近的工作量非常难以确保，但分工是一定要明确的，不然会很乱，严重影响开发效率。
9.
我暂时觉得用不到。可能架构和一些设计模式对软件工程师更加重要。
软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。
- 请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点就可以。
需求：确保需求明确是很重要的，在时间不充裕的情况下不能在需求分析上花太多时间
设计：在动手实现一个模块的时候一定要有完善的设计
实现：最好不要由两个以上的人实现一个小模块
测试：这一环节很重要，不能不重视，有效的测试可以减轻维护的负担
发布：实际的发布可能很麻烦，要给这一阶段留一些时间
维护：维护要及时，但消耗也不小