团队作业（三）：确定分工
1、上次的《需求规格说明书》初稿的不足指出有：
- 用户场景不够细化，分了三类用户的大致使用功能，修改细分成了表格的形式，使其更加美观整齐。
- 不同级别标题字体大小一样，不美观，修改之后，可读性更强。
- 对项目整体分析以及用户需求分析不够全面，有些功能可以合并。
2、代码规范和编码
●代码规范
1. 严格采用阶梯层次组织程序代码：每层次缩进为4格，括号位于下一行。要求相匹配的大括号在同一列，对继行则要求再缩进4格
2.提示信息字符串的位置：在程序中需要给出的提示字符串，为了支持多种语言的开发，除了一些给调试用的临时信息外，其他所有的提示信息必须定义在资源中。
3.对变量的定义，尽量位于函数的开始位置。
● 代码风格原则：简明、易读、无二异性
●变量名的命名规则：
1.只能由字母、数字、下划线组成
2.第一个字符必须是英文字母
3.有效长度为255个字符
4.不可以包含标点符号和类型说明符%,&,!,#,@,$
5.不可以是系统的关键词比如else
●注释规范原则
1.注释要简单明了，便于理解和修改；
2.边写代码边注释，修改代码同时修改相应的注释，以保证注释与代码的一致性；
3.在必要的地方注释，注释量要适中，注释的内容要清楚明了，含义准确，防止注释二义性，保持注释与其描述的代码相邻，即注释的就近原则；
4.对代码的注释应放在其上方相邻位置，不可放在下面；
5.全局变量要有较详细的注释，包括对其功能、取值范围、哪些函数或过程存取它以及存取时注意事项等的说明；
6.在每个函数或过程的前面要有必要的注释信息，包括：函数或过程名称；功能描述；
7.输入，输出及返回值说明；调用关系及被调用关系说明等
● 函数编写
1.一个函数最好仅完成一件功能，多调用；
2.函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出；
3.避免设计多参数函数，不使用的参数从接口中去掉；
4.检查函数所有参数输入的有效性；
5.函数名应准确描述函数的功能，便于查找和修改；
6.明确函数功能，精确（而不是近似）地实现函数设计；
●变量编辑
1.去掉没必要的公共变量
2.构造仅有一个模块或函数可以修改、创建，而其余有关模块或函数只访问的公共变量，防止多个不同模块或函数都可以修改、创建同一公共变量的现象
3.仔细定义并明确公共变量的含义、作用、取值范围及公共变量间的关系
4.明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改及创建等
5.当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界等现象发生
6.防止局部变量与公共变量同名
7.仔细设计结构中元素的布局与排列顺序，使结构容易理解、节省占用空间，并减 少引起误用现象
8.结构的设计要尽量考虑 向前兼容和以后的版本升级，并为某些未来可能的应用保留余地（如预留一些空间等）
9.留心具体语言及编译器处理不同数据类型的原则及有关细节
10.严禁使用未经初始化的变量，声明变量的同时对变量进行初始化
11.编程时，要注意数据类型的强制转换
●细节之处
1.缩进：4个空格，而不是TAB；
2.行宽：限定为100字符；
3.括号、断行与空白的{}行；
4.分行；
5.命名：匈牙利命名法；
6.下划线：分隔变量名字中的作用域标注和变量语义；
7.大小写（Pascal形式和Camel形式）；
●代码复审
1.形式：自我复审、同伴复审、团队复审；
2.目的：找出代码错误、发现逻辑错误、发现算法错误、发现潜在的错误和回归性错误、发现可能需要改进的地方、传授经验；
3.代码复审后把记录整理出来：
（1）更正明显的错误；
（2）记录无法很快更正的错误；
（3）把所有的错误记在自己的一个“我常犯的错误”表中，作为以后自我复审的第一步；
●结对编程
1. 角色：
驾驶员：控制键盘输入；
领航员：起到领航、提醒的作用；
2.好处：
（1）在开发层次，可以提供更好的设计质量和代码质量，两人合作解决问题的能力更强。
（2）对开发人员，带来更多的信心，高质量的产出带来更高的满足感。
（3）企业管理层次上，有效地交流，相互学习和传递经验，分享知识，取得更高的投入产出比。
3、通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。(10')
4、进行项目的后端架构设计，要与需求规格说明书中的界面原型设计相对应。（15'）
5、确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：（15'）
利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能。
以下是相应的WBS图。
以下是各个核心需求的优先级。
在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。
给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList。
当前TODOList：
后续可以查看子功能、分工、正在进行、已完成功能等。
燃尽图如下：
6、描述组员在上述任务中的分工和工作量比例。
分工：
工作量比例：
7、以上内容发表成一篇随笔，Alpha 版本的发布时间安排在5月下旬，请各个团队注意时间结点，尽快开始开发。
