2017-2018-1 Java演绎法 第六七周 作业

团队任务：修改完善《需求规格说明书》等

• 团队组长：袁逸灏
  本次编辑：刘伟康

修改完善上周提交的需求规格说明书

• 【markdown 链接】
  【pdf 链接】

• 不足之处：仅就现在的问题来看，结构完整，用户需求内容有些不足，后期随着项目的完成度会继续修改。修订历史记录如下：

日期	版本	说明	作者
2017.11.5	V1.0	第一个版本，根据项目形成基本构架	Java演绎法
2017.11.12	V1.1	添加选车和选音乐界面，完善开始界面， 加入数据结构相关内容	Java演绎法
2017.11.19	V1.2	添加WBS功能介绍图和需求优先级象限图， 改善选车界面	Java演绎法

团队的编码规范

在大部分组员阅读了《构建之法》第四章内容之后，我们团队的组长袁逸灏制定了一份大致的编码规范，是关于开发过程中的规范要求（以后会有补充）：

• 1.总体上要干净整洁；

• 2.不同的方法间要分得开些；

• 3.每个方法要有对应注释说明，包括方法的作用以及输入参数的类型和意义；

• 4.方法中的变量也要进行功能说明；

• 5.变量名字要有功能性：如果要表示数组A的下标指针，该变量起名应为AIndex；

• 6.变量的名字要限制好，最好不要超过20个字；

• 7.类的起名也要明确，严禁出现 A.java,B.java 这些情况；

• 8.关于大括号的使用，不要这种情况：

  if(boolean){Code};
  

  即使只有一条代码语句，也不要出现这样的情况：

  if(boolean) Code;
  

  或是这样：

  if(boolean)
  Code;
  

  最好的情况做到这样

  if(boolean){
  	Code;
  }
  

使用Powerdesigner绘制ER图

• 由于我们的团队项目没有设计数据库的内容，所以只针对其他方面制定了ER图：（单击即可放大）
  

项目的后端架构设计

• 我们小组使用Xmind实现如下：
  

  点击查看大图：【主界面】

  文件链接：【主界面】

团队分工

• 团队分工：（参考第一周博客）

学号	姓名	负责工作
20162315	马军	日常统计，项目部分代码
20162316	刘诚昊	项目部分代码，代码质量测试
20162317	袁逸灏	组长，项目 主要 代码
20162319	莫礼钟	市场推广，广告策划
20162320	刘先润	项目部分代码
20162330	刘伟康	项目总结博客，日常管理，代码质量测试

【注】个别成员在没有具体工作时会进行动态分配。

• 利用象限法确定各个核心需求的优先级：
  

• 功能介绍图（WBS）：
  

• 对应版本需求：

  • Alpha版本
    • 1.开始，退出，暂停按钮...
    • 2.游戏界面各种元素：车，障碍，公路，路旁...
    • 3.障碍移动，车辆移动等功能...
    • 4.通关，游戏失败或自行结束后的积分功能...
  • β版
    • 1.图形选车，查找选车等功能...
    • 2.音乐功能...
  • 发布版本
    • 1.添加用户反馈渠道，实现与用户交流的功能

TODOList及燃尽图

• TODOList：
  

• 码云上的Issue：
  

• github上的Issue：
  

• 燃尽图：（仅本周任务）
  

• github上的燃尽图：（测试）
  

小组会议及交互总结

• 本周小组会议较短，在会议上，我们主要讨论了本次任务分工及修改需求规格说明书的问题，内容较少，没有前几周准备地那么充分，下次在小组会议的讨论提纲上要像前几周一样做一个可行的讨论计划。

• 关于交互，本周还是由 莫礼钟 完成此项任务，虽然主动性没有上一次那么强，但还算完成了任务，以下是他的交互总结：

团队任务已经进行到第六第七周，从开始的规格说明书如何编写，到现在根据《构建之法》第四章内容讨论编码规范，各个小组已经进入到了开始代码构架的阶段。
为此，我继续进行着我的交互任务，对各个小组做了一些简单的问答。
bug终结者小组说：他们的需求规格说明书还没有做到他们满意的效果，所以他们关于团队任务的安排是：让小组成员们对需求规格说明书的任意一章（自选）进行修改，并且在此任务的基础上让小组成员们寻找关于APP的素材，并开始对APP的构架。
JaWorld小组说：他们遇到的困难是，会遇到有不懂的代码，而且担心赶不上开发进度。
剩下的两个小组我得到的信息大概与上面两个小组相同，对于遇到的问题都是一些开发上面的问题。

• 交互反思：

觉得这次和上次的交互比起来太草率而且太不严谨了，许多小组都对于我（莫礼钟）的来意表示疑惑，并且我对他们的提问总是一成不变的：遇到什么问题？打算怎么解决？怎么分工？这些能在团队博客里呈现的内容。

• 交互改进（下一次团队作业时）：

我会准备一个问题模版并针对当前我们小组遇到的开发问题与其他小组进行探讨，让交互不再是简单的你问我答环节，而是对于各个小组遇到的问题能互相沟通提出建议或改进，学习其他小组的先进内容。

本次分工及工作量比例

成员	个人贡献及完成度	用时	比例
袁逸灏	制定开发开发过程中代码规范、项目的后端架构设计【100%】	2.0	16%
刘伟康	确定任务、分配任务、检查汇总整理（markdown 及 pdf）、编辑博客、项目github燃尽图【100%】	8.0	22%
刘先润	使用Powerdesigner绘制ER图、界面设计【100%】	6.0	20%
马军	使用象限法设计优先级图、功能介绍图（WBS）【100%】	2.0	16%
刘诚昊	列出TODOList、项目燃尽图【100%】	4.0	16%
莫礼钟	交互、对接其他小组【100%】	1.0	10%

小编感想

　　本周的任务比较散，具体来说就是使用各种软件预估分析团队即将完成的任务，为此有些组员费尽心思，别看最后的图挺普通，其实有的组员花费了大量时间学习软件。学习新软件的过程我也深有体会，我在其中负责生成燃尽图，但是这个燃尽图真的是奇特，根据给出的参考资料：使用Github生成燃尽图，我原本以为在码云上可以和 github 一样的方式生成燃尽图，没想到做到最后一步的自动生成燃尽图的网站只针对github，我只好选择第二种方式，将项目克隆下来，在虚拟机上安装各种插件，但是依然出现错误，没有成功。最后我在 github 上建了一个账号，重新建了一个项目的说明书，之后对应地写了一个测试的 Issues 和 milestone，才算大致完成了任务。的确，想要在一周内学会一个软件或者实现某种功能有时还是一件相当麻烦的事。
　　各位组员辛苦了，为了团队的明天继续做好各自的任务吧。（编辑：刘伟康）

参考资料汇总

• todoList

• ToDoList的使用

• 使用Github生成燃尽图

• 分而治之（Work Breakdown Structure, WBS）