第五周作业
软件过程日志（2016.3.21-2016.3.27）
我们小组本周的主要任务是确定小组项目的具体项目，包括立项与需求分析。以下是我们在本周的一些工作记录与成果以及我的体会。
小组工作记录
- 2016.3.21 小组第一次集合，就项目内容进行讨论，初步决定小组项目为一个五子棋平台，与老师交流后决定添加创新点，初步设想为在三维空间中下棋。
- 2016.3.23 就三维五子棋的快速原型进行讨论，初步否决了该想法，并决定提出其它方案于第二天开会讨论。
- 2016.3.24 小组第一次正式会议，决定团队项目内容为仿照手机游戏“球球大作战”做一款PC端的3D游戏。
- 2016.3.25 决定使用Unity游戏引擎。
- 2016.3.27 完成立项说明书与需求说明书的第一版。
个人心得
在本周的项目中，我有如下几点心得体会以及想说的地方：
关于需求调研
由于时间有限以及本项目的其它一些实际情况，我们小组主要使用了“焦点小组”以及“快速原型调研”两种调研方式。
-
焦点小组
焦点小组的调研方式是通过用户代表与开发者等涉众集体讨论的方式来获取需求。由于我们作品的用户可能就只有我们小组的这些开发人员了，故该焦点小组由我们项目小组的成员组成。在焦点小组中我们讨论了我们要制作什么样的项目，这个软件的功能有哪些等等。然而在实施过程中我们遇到了一些问题，那就是有时讨论的积极性不高，大家没有踊跃发表自己的观点，变成了等待我一个人布置任务一般，特别是在线讨论的时候。这与我的组织能力不足有一定的关系。当然这个方法也取得了成果，我们还是通过这种方式最终确定了最终的项目。 -
快速原型调研
快速原型调研是通过拿出模型给用户使用得到体会而获取需求的。与课本上用纸等做成的模型不同，我们这次使用的快速原型是可以运行的软件。我们小组有一段时间倾向于制作一个3D五子棋，让用于可以在立体三维空间落子，这样一个棋子可以在26个方向与其它棋子相连，看起来比较有趣，然而我们担心是否太过于复杂。于是我们花一天做了一个软件原型，实现了整个界面，落子，旋转等基本功能，给小组成员以及一些朋友使用。然而我们得到的反馈是落子很不方便，棋子一多便眼花起来，看不出棋子间的联系。我们也获得了许多改进方面的反馈，并进行了改进再次尝试，但是效果仍然不能让人满意。于是这个想法被放弃。
关于技术选型
最初决定写3D游戏的时候，我们选择的引擎是JMonkey，因为这款引擎是使用我们熟悉的Java语言来制作游戏的，上手比较容易，因此五子棋的快速原型以及后来确定的项目的前期规划与分工都是按照JMonkey来弄的。然而在班上其它小组的推荐下，我觉得用Unity可能会更好，于是总结了下它们的优缺点，跟小组成员进行了探讨：
| 游戏引擎 | 优势 | 劣势 |
|---|---|---|
| JMonkey | 使用熟悉的语言Java进行开发；接触之后觉得足够该项目的要求 | 非主流引擎，网上资料很少，中文资料几乎没有 |
| Unity | 强大，流行，网上资源多，学了之后没准以后还能用得上 | 小组里没人使用过，心里没底；C#语言团队里也没人会 |
最后还是决定把引擎换为Unity，因为它更加主流，资源丰富，C#跟Java也特别相似，上手难度不大，而且以我们组一些成员的基础，用Java 跟用C#其实差不多-_-||。
后记 现在写这篇文章的时候距离这个决定已经一个星期了，在此期间对Unity有了更深的了解，逐渐也发现了Unity的几个“坑”：
- 虽说资料多吧，但是能找到的大部分中文资料是Unity4甚至是之前的，而我们选择的最新版Unity5虽然已经发布一年，但资料还是主要靠官网的英文原版文档和视频，当时完全没预料到这点。
- Unity引擎很强大，完全不像JMonkey那样什么事都要用代码实现，Unity需要自己写代码的地方很少，这就导致我们团队项目的需要的代码量大幅度下降。有些功能花很多时间学习并制作出样品之后，发现根本没有写出代码就已经实现了。也就是说，对这项目的付出完全没法用代码量来衡量。本来按功能进行的分工，可能满足不了老师“每个人都要写代码”的要求。这现在成为一件令人头疼的事情。
关于文档
文档按照老师的要求是每个人都参与，然而在以前的项目经验中，每人一句拼出来的文档质量实在是难以令人不敢恭维。需求文档本来就很短，中间很多东西关联性很强，强行分给不同人来写，每个人就写那么几句话，个人认为实在是不适合。尽管如此，我们还是基本按照老师的要求把任务分下去，关键的部分由几个人进行类似于”结对编程“的方法结对编写文档，对于大家交上来的文档我也没像以前一样一字一句地修改到作者本人都不认识，而是只修改了一些非常显眼的问题，进行简单的排版后提交了上去，最终效果似乎也并不让老师满意。怎样写出符合”人人参与“和”保证质量“两个要求的文档，我们仍在探索之中。