团队作业（三）：确定分工

团队任务电子公文传输系统

团队作业（三）：确定分工

项目名：电子公文传输系统
成员：20191331刘宇轩、20191303姜淳译、20191305李天琦、20191311陈之韬、20191318王泽文
撰写：刘宇轩
日期：2021.10.31

一、《需求规格说明书》修改：

• 分层形式描述不够具体清晰，没有做到逐层深入，缺少目录。

  目录：

  1.引言

    1.1使用说明
    
    1.2背景
  

  2.用户场景

  3.类图

  4.界面原型

  5.功能描述

    5.1用户功能
    
    5.2系统管理员功能
    
    5.3数据库管理员
  
    5.4安全审计员
    
    5.5系统功能补充
  

  6.验收验证标准

• 未描述成员具体分工和工作量比例。

• 上次制定的需求规格说明书中部分内容实现起来较为困难且冗余，我们删除了管理员字号管理功能。

更新后的《需求规格说明书》：https://gitee.com/vegetable-dogggg/docsys/blob/master/规格需求说明书v2.md

二、代码规范和编码

团队的编码规范：

1.代码风格规范

代码风格的原则是：简单，易读，无二义性。包括缩进、行宽、括号等。

• 缩进：将Tab键扩展定义为4个空格。不使用tab键的原因是它在不同的情况下会显示不同的长度。使用空格可读性高。

• 行宽：行宽限制为100字符。

• 括号：在复杂的条件表达式中，用括号清楚地表示逻辑优先级；左右小括号和字符之间不能出现空格。

• 断行与空白的{}行：每个｛和｝都单独占一行，互为一对的{和}要位于同一列，并且与引用它们的语句左对齐。

• 代码行：if、else、for、while、do 等语句自占一行。不论执行语句有多少行，就算只有一行也要加{}，并且遵循对齐的原则。

• 命名：

  • 代码中的命名只能由字母、数字、下划线组成；不能以下划线或美元符号开始，也不能以下划线或美元符号结束。

  • 命名不能直接使用中文。

  • 不可以是系统的关键词比如if、else等。

  • 常量命名全部大写，单词用下划线隔开。

• 注释：保证代码与注释的一致性，要简洁明了，注释的双斜线与注释内容之间有且仅有一个空格复杂的注释放在函数头，注释中应只使用ASCII字符。

2.代码设计规范

• 函数：

  • 一个函数最好仅完成一件功能，多调用为简单功能编写函数。

  • 函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出。

  • 避免设计多参数函数，不使用的参数从接口中去掉。

  • 检查函数所有参数输入的有效性与作用。

  • 函数名应准确描述函数的功能，便于查找和修改。

  • 明确函数功能。

• 变量：

  • 去掉没必要的公共变量。

  • 构造仅单一模块或函数可以修改、创建的公共变量，防止多个不同模块或函数都可以修改、创建同一公共变量的现象。

  • 定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改及创建等。

  • 当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界等现象发生。

  • 局部变量与公共变量不能同名。

  • 严禁使用未经初始化的变量。声明变量同时对变量进行初始化。

  • 注意数据类型的强制转换。

• 编写：

  • 注意随时保存与备份避免代码丢失。

  • 使用相同编辑器与选项设置。

  • 编写代码过程中互相帮助，随时找出代码中的错误并进行改进，相互学习。

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

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

五、确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容。

相应的WBS图：

象限法分析核心需求：

当前核心任务TODOList：

燃尽图：

六、描述组员在本次任务中的分工和工作量比例。

正在编篡。