电子公文系统三--确定分工

一、规格需求说明书的修改

在引言方面，我们增加了电子公文系统的使用说明；在功能方面，我们在表达方面有所欠缺，本次采用分层叙述，更加的条理清楚，在功能实现有所欠缺，部分功能没有考虑到。
更改之后的规格需求说明书网址：规格需求说明书

二、代码规范和编码

1.代码规范

代码风格规范，主要是文字上的规定。
代码设计规范，牵涉到程序设计、模块之间的关系、设计模式等方方面面的通用原则。

2.代码风格规范

代码风格的原则是：简明、易读、无二义性。
缩进：将Tab键扩展定义为4个空格。不直接使用tab键的原因是它在不同的情况下会显示不同的长度。4个空格可读性高。
行宽：行宽必须限制，建议100字符。
括号：在复杂的条件表达式中，用括号清楚地表示逻辑优先级；左右小括号和字符之间不能出现空格。
断行与空白的{}行：每个｛和｝都单独占一行，互为一对的{和}要位于同一列，并且与引用它们的语句左对齐。

if(condition) DoSomthing();
else DoSomethingElse();

这样调试起来很不方便，而且在多层嵌套时不容易理清结构和对应关系，建议如下：

if(condition) 
{
    DoSomthing();
}
else 
{
    DoSomethingElse();
}

代码行：if、else、for、while、do 等语句自占一行。不论执行语句有多少行，就算只有一行也要加{}，并且遵循对齐的原则。
命名： 代码中的命名只能由字母、数字、下划线组成；不能以下划线或美元符号开始，也不能以下划线或美元符号结束，且下划线不允许出现在命名的首位或末位；命名不能直接使用中文；不可以是系统的关键词比如if、else等；常量命名全部大写，单词用下划线隔开。
下划线：分隔变量名字中的作用域标注和变量语义。
注释：保证代码与注释的一致性，要简洁明了，注释的双斜线与注释内容之间有且仅有一个空格复杂的注释放在函数头，注释中应只使用ASCII字符。

3.代码设计规范

函数：

一个函数最好仅完成一件功能。
函数的功能应该是可以预测的。
检查函数所有参数输入的有效性与作用。
函数名应准确描述函数的功能，便于查找和修改。
明确函数功能。
不论函数是否定义在main函数前，均需要进行声明，声明位于全局变量定义之后。
可使用goto实现函数的单一出口（但也要尽量少使用）。
一般情况下不需要自定义操作符，运算符不要做标准语义以外的任何动作。运算符的实现必须非常有效率，如有复杂的操作，应定义一个单独的函数。

常量定义：

任何常量需要在宏里定义再使用，如果是一些头文件里包含的常量，可以直接使用但是要在首次出现的地方进行注释，告诉我们是出自那个头文件，具体数值是多少。

变量：

去掉没必要的公共变量。
制造仅单一模块或函数可以修改、创建的公共变量，防止多个不同模块或函数都可以修改、创建同一公共变量的现象。
定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改及创建等。
当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界等现象发生。
局部变量与公共变量不能同名。
严禁使用未经初始化的变量。声明变量同时对变量进行初始化。
注意数据类型的强制转换。
全局变量需要定义在头文件与宏定义的下方，函数声明语句上方，如果能不使用全局变量尽量不使用，之后函数或是main函数里使用全局变量后尽量在结尾加以注释，方便查看全局变量的使用过程。

编写：

在Debug版本中，所有参数都要验证其正确性，在正式版本中，对外部转递就俩的参数要验证其正确性。
注意随时保存与备份避免代码丢失。
使用相同编辑器与选项设置。
编写代码过程中互相帮助，随时找出代码中的错误并进行改进，相互学习。

4.代码复审

形式：自我复审、同伴复审、团队复审。
目的：找出代码错误、发现逻辑错误、发现算法错误、发现潜在的错误和回归性错误、发现可能需要改进的地方、传授经验，防止错误的再发生。
代码复审后把记录整理出来：
- （1）更正明显的错误
- （2）记录无法很快更正的错误
- （3）把所有的错误记在自己的一个“我常犯的错误”表中，作为以后自我复审的第一步
- （4）定期查阅错误记录并进行学习总结

三、 通过Powerdesigner完成团队项目的数据库设计，并提供相应ER图。

四、 进行项目的后端架构设计，要与需求规格说明书中的界面原型设计相对应。

五、确定团队分工

象限法表示优先级

WBS图

燃尽图

六、描述组员在本次任务中的分工