14软二杨近星（2014551622）
项目开发的开始， 到现在已经很久了， 软件工程的课也上了很久了， 不过， 我们的游戏现在依然还没有影子， 只能说。。。还是啥也不会。。。
从一开始， 兴致勃勃地需求访谈， 到现在， 各种报告， 各种说明书， 各种图， 忙的好乱。
不过， 对于游戏开发来说， 还是有起色的， 比方说：
我们发现了我们使用的开发软件很容易崩。。。
然后只能重装。
我们还预习了如何画状态图， DFD， 类图等等
不过，画图也有很多问题， 比方说工具选择， 用viso画图的时候， 连接线只能向同一方向指， 导致DFD只能画得像流程图一样， 状态图也很是问题， 我们事先用纸把图画下来， 然后商讨， 接着画到word上的， 然而。。。状态图一个套一个。。。到最后只能画个局部放大图来添加细节。。。还有， 我们把图画完了， 才发现看错了样例（反工的过程TT）。
作为项目组长， 调节团队成员之间微妙关系的责任就在我身上， 毕竟我不能让这个项目夭折（平时分啊！！！）然而， 时不时的会有各种神奇的问题， 比方书这个烦了， 那个嫌没时间， 或者这个催稿， 那个不着急。。。总之， 我也是有脾气的， 虽然有时候是我发的无名火是我不对， 但是。。。（跑题了， 回来）， 因为团队中每个人都偏向于技术， 所以在设计和需求的这方面（直言）还是比较薄弱的， 所以， 三个人在立项， 需求的时候， 不是很能同意的到一起。
在一个问题， 就是markdown了。。。完全没接触过的语言， 虽然有大神说不难学， 可是突然就用这个是在手足无措啊。
再就是开发环境了， 说真的， 引擎我真的想换了， creater有的时候崩掉的蔫坏蔫坏的， 看不出来， 也不报错， 就是运行不了， 所以， 有时候完全不知道是代码有问题， 还是程序没ready， unity好歹也是维护了很久的软件， 应该不会出这么大的问题， 毕竟我们都是新手， 每个函数， 每个方案都要去试， 这样子很浪费我们的时间。
最后再提一下立项说明书吧， 立项说明书的书写方法我不是很赞同其实， 因为一个说明书要有连贯性， 一堆人， 一人一段会失去一篇文章的连贯性， 我的建议是一个人或者两个人写， 一个或两个人修订， 这样子， 修订的人会通读全文， 找出驴唇不对马嘴的地方， 然后做更改， 而不是直接加了一段神奇的自然段在上面。