1.修改完善上周提交的需求规格说明书，并在博客中描述：上次的《需求规格说明书》初稿有哪些不足？修改需同时体现在Github的MarkDown文件与PDF中。（提示：功能考虑不全或需求文档描述缺少的地方。）（5'）
修改后的链接：https://www.cnblogs.com/zja2019/p/15491514.html
2.讨论制定团队的编码规范，讨论之前和讨论之后，队员阅读《构建之法》第四章内容，并讨论总结。将代码规范和编码原则发布在随笔上，并说说你们这么选择的理由。（5'）
代码风格规范和代码设计规范，代码风格规范主要是文字上的规定，看似表面文章，实际上非常重要；代码设计规范牵涉到程序设计、模块之间的关系、设计模式、等方方面面的通行原则；
代码风格规范原则：简明、易读、无二异性；
-
缩进：将Tab键扩展定义为4个空格。不直接使用tab键的原因是它在不同的情况下会显示不同的长度。4个空格可读性高；
-
行宽：行宽必须限制，建议100字符；
-
括号：在复杂的条件表达式中，用括号清楚地表示逻辑优先级；
-
断行与空白的{}行：
分行：不要把多中不同的操作放在同一行（书中建议“不要把多个变量定义在一行”，可能会使代码不够简洁）； -
命名：“匈牙利命名法”；
-
下划线：分隔变量名字中的作用域标注的变量的语义；
-
大小写：全部大写、小写会导致不易读，所有的类型/类/函数名用 Pascal 形式（每个单词首字母大写），所有变量都用 Camel （第一个单词小写，后面用 Pascal ）；
-
注释：解释程序做什么，为什么这样做。复杂的注释放在函数头，解释参数，要不断更新（书中建议使用ASCII码以增强可移植性，但实际操作复杂，我们不做这方面的要求）
代码设计规范：
1.函数：只做一件事，做好一件事；
2.goto：可使用goto实现函数的单一出口（但也要尽量少使用），助于程序逻辑的清晰体现
3.错误处理：参数处理，断言；
4.运算符：一般情况下不需要自定义操作符，运算符不要做标准语义以外的任何动作。运算符的实现必须非常有效率，如有复杂的操作，应定义一个单独的函数；
5.处理C++中的类（类，class vs.struct，公共／保护／私有成员，数据成员，虚函数，构造函数，析构函数，new和delete，运算符Operators，异常，类型继承）；
代码复审：
形式：自我复审、同伴复审、团队复审
目的：找出代码错误、发现逻辑错误、发现算法错误、发现潜在的错误和回归性错误、发现可能需要改进的地方、传授经验
代码复审后把记录整理出来：
更正明显的错误
记录无法很快更正的错误
把所有的错误记在自己的一个“我常犯的错误”表中，作为以后自我复审的第一步
结对编程：最早有记录的结对编程、为什么要结对编程、不间断地复审、如何结对编程），两人合作的不同阶段和技巧（萌芽阶段，磨合阶段，规范阶段，创造阶段）：如何影响对方、如何正确的给予反馈；
3.通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。(10')
4.进行项目的后端架构设计，要与需求规格说明书中的界面原型设计相对应。（15'）
5.确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：（15'）
- 利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。
- 在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。
- 给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图。
燃尽图
6.描述组员在上述任务中的分工和工作量比例。
