团队作业（三）：确定分工
成员：20211106隋吉达、20211108俞振阳、20211112周子凯、20211120刘钟徽、20211125苗靖章
时间：2023.11.4
项目名：电子公文系统项目团队作业三：确定分工
博客撰写：20211125苗靖章（08修改）
一、第一项任务（20211106）
修改完善上周提交的需求规格说明书，并在博客中描述：上次的《需求规格说明书》初稿有哪些不足？修改需同时体现在Github的MarkDown文件与PDF中。（提示：功能考虑不全或需求文档描述缺少的地方。）（5'）
（一）不足之处：1.分层形式描述不够具体清晰，没有做到逐层深入，缺少目录。2.上次制定的需求规格说明书中部分内容实现起来较为困难且冗余，我们删除了管理员字号管理功能。
（二）修改体现：
# 电子公文系统规格需求说明书 # 目录： ## 1.引言 ### 1.1使用说明 ### 1.2背景 ## 2.用户场景 ## 3.类图 ## 4.界面原型 ## 5.功能描述 ### 5.1用户功能 ### 5.2系统管理员功能 ### 5.3数据库管理员 ### 5.4安全审计员 ### 5.5系统功能补充 ## 6.验收验证标准 ## 1. 引言 ### 1.1 使用说明 本系统按照《GB/T33482-2016党政机关电子公文系统建设规范》和国家标准开发，实现纸质公文全流程电子化，确保安全、高效的公文流转。本文档面向用户、项目经理、开发人员、系统管理员及其他相关人员。 ### 1.2 背景 电子政务是信息化建设的关键，通过电子信息技术，实现政府机关机要文件流转全面信息化管理。传统纸质公文管理存在效率低、安全性差等问题，需要全面推进数字化技术为基础的全生命周期管理。 ## 2. 用户场景 - **用户**：拥有对公文的起草、修改、发布、接收、管理权限。 - **系统管理员**：维护系统稳定性和用户权限管理。 - **数据库管理员**：管理数据库资源和安全。 - **安全审计员**：监控系统安全并进行审计。 ## 3. 类图  ## 4. 界面原型      ## 5. 功能描述 ### 5.1 用户功能 - **公文格式**：根据密级、紧急程度制作红头模板。 - **公文上传**：安全登录后上传需要处理的公文。 - **公文发送/接收**：按对象、密级分类，加密传送/解密接收。 - **公文管理/查询/浏览**：分类归档、按权限查询和浏览公文。 - **用户权限**：注册时管理员赋予相应权限。 ### 5.2 系统管理员功能 - **权限管理**：设置用户权限。 - **查询文件**：查看发布和接收的公文列表，但无权阅读内容。 ### 5.3 数据库管理员 - **数据库资源管理**：监控数据库资源和可用性。 - **数据库安全**：对数据库进行加密和故障响应。 ### 5.4 安全审计员 - **系统监控**：监控用户行为，进行审计。 - **信息溯源**：追溯泄露信息。 - **日志管理**：记录和查看系统日志。 ### 5.5 系统功能补充 - **文件归档查询**：按多种方式进行归档管理，按权限查询。 - **公文权限控制**：附加权限属性，限定操作权限。 - **安全传输**：对公网传输的公文加密保护。 - **公文管理监控**：每份公文附有发、收、查阅日志。 ## 6. 验收验证标准 | 角色 | 功能 | 功能实现 | 预期结果 | | ------ | ------- | ------------------------------------------- | ------------------------------------------- | | 系统 | 注册 | 姓名、电话号码、传真、邮箱、密码、单位、所属部门等基本信息，符合一定要求或验证完成注册 | 对不同部门的工作人员基本信息录入系统，进行注册并且验证 | | | 登录 | 验证账号和密码进行登录 | 验证账户和密码进入页面，实现用户功能 | | | 文件归档查询 | 公文可直接归档到文件管理系统中供以后查询，归档的公文按权限进行查阅 | 用户可通过标题、文号、责任者等内容进行组合查询，也可通过全文检索等工具进行更精确的查询 | | | 公文权限控制 | 公文附有权限属性 | 仅相应权限人员可进行编辑，查阅等操作 | | | 安全传输 | 通过公网传输的公文进行加密保护 | 确保公文在公网中的安全传输 | | | 公文管理监控 | 每份公文附有发、收，查阅日志 | 实现每份公文收、发、查阅均可追溯 | | 用户 | 公文格式 | 根据不同公文的密级、紧急程度不同制作不同的红头模板 | 自动化生成匹配模版文件 | | | 公文上传 | 成功登陆的人员可将需要处理的公文上传至电子公文系统。 | 验证登陆并实现上传 | | | 公文发送 | 根据所要发送的对象、密级、紧急程度等对文件进行分类，再加密传送。 | 发送前对发送请求进行验证并加密发送 | | | 公文接收 | 根据文件的密级，发送单位将文件分类，判断安全后进行解密。 | 对接收到的公文二次验证并保存 | | | 公文管理 | 根据用户的需求对公文进行分类归档 | 根据系统或者用户自定义关键词进行分类保存并上锁 | | | 公文查询 | 相关权限用户根据签发部门，密级，紧急程度等查询公文 | 根据系统或者用户自定义关键词精准查询 | | | 用户权限 | 注册时管理员根据相关信息赋予用户相应权限。 | 管理员对注册用户进行审核，赋予相应权限 | | 系统管理员 | 权限管理 | 可管理各个用户权限 | 根据规定，对不同用户的权限 进行设置 | | | 查询文件 | 可查询所有发布和接收的公文，但无法阅读无授权的公文内容 | 实现公文管理并确保内容安全 | | | 文件列表 | 可进入后台选择文件列表，查看用户发布及签收文件的情况 | 实现用户行为管理和操作查看 | | 数据库管理员 | 数据库资源管理 | 数据库管理员管理数据库资源，动态监控数据库内存空间，保障电子公文系统的可用性 | 动态监控管理数据库内存空间，实现可用性保障 | | | 数据库安全 | 对数据库进行加密保护，对数据库故障进行响应 | 确保数据库安全，实现故障的及时响应 | | 安全审计员 | 系统监控 | 对用户和其他管理员行为进行监控，对其行为进行审计 | 对系统成员进行监控，实现异常行为溯源 | | | 信息溯源 | 对泄露的信息进行溯源 | 实现泄密事件可追溯追责 | | | 日志管理 | 包含系统的日志记录和查看模块，可在系统中查看日志记录 | 对系统日志进行管理和查看 |
二、第二项任务（20211106）
讨论制定团队的编码规范，讨论之前和讨论之后，队员阅读《构建之法》第四章内容，并讨论总结。将代码规范和编码原则发布在随笔上，并说说你们这么选择的理由。（5'）
团队的编码规范：
1.代码风格规范
代码风格的原则是：简单，易读，无二义性。包括缩进、行宽、括号等。
-
缩进：将Tab键扩展定义为4个空格。不使用tab键的原因是它在不同的情况下会显示不同的长度。使用空格可读性高。
-
行宽：行宽限制为100字符。
-
括号：在复杂的条件表达式中，用括号清楚地表示逻辑优先级；左右小括号和字符之间不能出现空格。
-
断行与空白的{}行：每个｛和｝都单独占一行，互为一对的{和}要位于同一列，并且与引用它们的语句左对齐。
-
代码行：if、else、for、while、do 等语句自占一行。不论执行语句有多少行，就算只有一行也要加{}，并且遵循对齐的原则。
-
命名：
-
代码中的命名只能由字母、数字、下划线组成；不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
-
命名不能直接使用中文。
-
不可以是系统的关键词比如if、else等。
-
常量命名全部大写，单词用下划线隔开。
-
-
注释：保证代码与注释的一致性，要简洁明了，注释的双斜线与注释内容之间有且仅有一个空格复杂的注释放在函数头，注释中应只使用ASCII字符。
2.代码设计规范
-
函数：
-
一个函数最好仅完成一件功能，多调用为简单功能编写函数。
-
函数的功能应该是可以预测的，也就是只要输入数据相同就应产生同样的输出。
-
避免设计多参数函数，不使用的参数从接口中去掉。
-
检查函数所有参数输入的有效性与作用。
-
函数名应准确描述函数的功能，便于查找和修改。
-
明确函数功能。
-
-
变量：
-
去掉没必要的公共变量。
-
构造仅单一模块或函数可以修改、创建的公共变量，防止多个不同模块或函数都可以修改、创建同一公共变量的现象。
-
定义并明确公共变量的含义、作用、取值范围及公共变量间的关系。明确公共变量与操作此公共变量的函数或过程的关系，如访问、修改及创建等。
-
当向公共变量传递数据时，要十分小心，防止赋与不合理的值或越界等现象发生。
-
局部变量与公共变量不能同名。
-
严禁使用未经初始化的变量。声明变量同时对变量进行初始化。
-
注意数据类型的强制转换。
-
-
编写：
-
注意随时保存与备份避免代码丢失。
-
使用相同编辑器与选项设置。
-
编写代码过程中互相帮助，随时找出代码中的错误并进行改进，相互学习。
-
三、第三项任务（20211112）
通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。(10')
四、第四项任务（20211120）
进行项目的后端架构设计，要与需求规格说明书中的界面原型设计相对应。（15'）
五、第五项任务（20211108）
确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：（15'）
1、利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。
WBS图：
2、在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。
部分图片已在上一小部分中包含
3、给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图。
20211108的TODOList：
20211112的TODOList：
20211106的TODOList：
20211125的TODOList：
20211120的TODOList：
六、第六项任务（20211125）
描述组员在上述任务中的分工和工作量比例。
| 成员 | 分工 | 工作量比例 |
|---|---|---|
| 20211106 | 修改完善需求说明书、编码规范 | 1/5 |
| 20211108 | 确定团队分工：WBS、子节点、ToDoList | 1/5 |
| 20211112 | 数据库设计、ER图 | 1/5 |
| 20211120 | 后端架构设计 | 1/5 |
| 20211125 | 文字内容、随笔、描述工作 | 1/5 |
七、第七项任务（20211125）
以上内容发表成一篇随笔，Alpha 版本的发布时间安排在5月下旬，请各个团队注意时间结点，尽快开始开发。
如题，已上传至博客园
八、第八项任务（20211125）
附录
Github： https://github.com/20211125/tdzy3
Gitee（总有一天要抛弃使用Gitee！！）
https://gitee.com/diana_sugar/electronic-document-system.git
浙公网安备 33010602011771号