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

@

目录

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

一、阅读目录

1.修改完善上周提交的需求规格说明书
2.团队的编码规范
3.使用Powerdesigner绘制ER图
4.进行项目的后端架构设计。
5.团队分工
6.本次分工及工作量比例
7.参考资料汇总

二、修改完善上周提交的需求规格说明书

链接：https://www.cnblogs.com/506506yyds/p/17795839.html

三、讨论制定团队的编码规范

1. 代码规范

  • 代码风格规范：

    • 使用一致的缩进风格，统一使用4个空格作为缩进。
    • 代码文件的字符编码应为UTF-8。
    • 使用Unix风格的换行符（\n）。

  • 代码设计规范：

    • 采用模块化的设计，每个模块或类应具有清晰的职责和界限。
    • 遵循SOLID原则，尤其是单一职责原则和开闭原则。

2. 代码风格规范

  • 代码风格的原则是：

    • 简明：代码应保持简短，每个函数和方法应不超过30行。
    • 易读：使用有意义的变量名和函数名，避免缩写。
    • 无二义性：使用括号来明确表示逻辑优先级。

  • 缩进：

    • 使用4个空格作为缩进，不使用制表符（Tab）。

  • 行宽：

    • 行宽限制为80字符，确保代码在绝大多数文本编辑器中可读。

  • 括号：

    • 在条件语句中，使用括号明确表示逻辑优先级。示例：if (condition) { ... }。

  • 分行：

    • 在超过行宽限制时，应进行适当分行，并使用缩进来提高可读性。

  • 命名：

    • 使用有意义的、描述性的变量和函数名，避免单字母变量名。
    • 遵循驼峰命名法，如myVariableName。

  • 大小写：

    • 类名使用帕斯卡命名法（PascalCase），首字母大写；例如：MyClass。
    • 变量和函数名使用驼峰命名法（camelCase），首字母小写；例如：myVariable。

  • 注释：

    • 在代码中添加注释，解释代码的目的、不明显的决策和算法。
    • 使用文档注释标准（如JSDoc或JavaDoc）来描述函数和类的参数、返回值和用途。

3. 代码设计规范

  • 函数：

    • 每个函数应只负责一个明确定义的任务，遵循单一职责原则。
    • 避免过度复杂的函数，确保可读性和可维护性。

  • goto：

    • 严格禁止使用goto语句，以提高代码的结构性和可维护性。

  • 运算符：

    • 仅使用标准运算符以执行常规操作，不要重载运算符来实现非标准行为。

4. 代码复审

  • 形式：

    • 自我复审：每个开发人员在提交代码前自行复审，确保代码符合规范。
    • 同伴复审：团队中的其他成员进行同伴复审，提供反馈和建议。
    • 团队复审：定期进行团队级别的复审，以确保一致性和共享最佳实践。

  • 目的：

    • 找出代码错误，包括潜在的逻辑错误和性能问题。
    • 传授经验，分享知识，提高整体编码质量。

  • 记录整理：

    • 明确规定复审后的记录方式，包括记录明显的错误、问题的责任人、无法立即解决的问题等。
    • 建立错误库，将所有错误记录下来，以供以后的自我复审和学习。

5. 结对编程

  • 角色：
    • 驾驶员：负责具体的编码工作，键盘输入。
    • 领航员：提供实时反馈、指导，确保规范

四、使用Powerdesigner绘制ER图

实体关系图的中文翻译：

  • 身份认证（AUTHENTICATION）验证用户（USER）身份和登录尝试，包括失败和管理员登录。
  • 用户（USER）请求文档发送和签收的权限（PERMISSIONS）。
  • 权限（PERMISSIONS）包括对公文发送模块（DOCUMENT_DISPATCH）的访问，该模块随后进行公文签收（DOCUMENT_SIGNING）并输入到公文库（DOCUMENT_LIBRARY）。
  • 管理员身份认证（ADMIN_AUTHENTICATION）请求管理员权限（ADMIN_PERMISSIONS）进行用户和日志管理。
  • 用户管理（USER_MANAGEMENT）包括用户注册和注销。
  • 日志管理（LOG_MANAGEMENT）监控登录、访问和文档处理记录。

实体和属性的中文翻译如下：

  • 身份认证（AUTHENTICATION）
    • 身份检查（identityCheck）
  • 用户（USER）
    • 用户ID（userID）
    • 姓名（name）
    • 所属部门（department）
    • 密码（password）
  • 权限（PERMISSIONS）
    • 公文模块（documentModule）
    • 发文日期（dispatchDate）
    • 公文分类（classification）
    • 公文密级（secrecyLevel）
    • 公文内容（content）
    • 收文单位（receivingUnit）
    • 保密期限（confidentialityPeriod）
    • 发文人（dispatcher）
  • 公文发送（DOCUMENT_DISPATCH）
    • 公文分类（category）
    • 发文日期（sendDate）
    • 公文密级（secrecyLevel）
    • 公文内容（content）
    • 收文单位（receivingUnit）
    • 保密期限（confidentialityPeriod）
    • 发文人（sender）
  • 公文签收（DOCUMENT_SIGNING）
    • 发文机关（dispatchAuthority）
    • 收文日期（receiveDate）
    • 收文人（receiver）
  • 公文库（DOCUMENT_LIBRARY）
    • 文档（documents）
  • 管理员身份认证（ADMIN_AUTHENTICATION）
    • 管理员身份检查（adminIdentityCheck）
  • 用户管理（USER_MANAGEMENT）
    • 用户账号（account）
    • 用户姓名（userName）
    • 用户所属部门（department）
    • 用户发布权限（publishPermission）
    • 用户接收权限（receivePermission）
    • 用户密码管理（passwordManagement）
  • 用户注册（USER_REGISTRATION）
    • 注册详情（registrationDetails）
  • 用户注销（USER_DEREGISTRATION）
    • 注销详情（deregistrationDetails）
  • 日志管理（LOG_MANAGEMENT）
    • 用户登录及访问权限（loginAndAccess）
    • 用户收文记录（receiveRecord）
    • 用户发文记录（dispatchRecord）

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

六、确定团队分工

  • 利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。

  • 在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。

  • 给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图。

  • TODOList

学号 姓名 工作
20211111 刘海涛 实现身份认证功能
20211117 祁昱霖 实现公文发送功能
20211105 李宜时 实现用户管理功能
20211121 杨博川 实现公文接收功能
20211126 李浩瑞 实现日志管理功能、实现公文发送功能
  • 燃尽图

七、组员在上述任务中的分工

学号 姓名 工作
20211111 刘海涛 项目的后端架构设计
20211117 祁昱霖 制作燃尽图、制作WBS图
20211105 李宜时 绘制ER图
20211121 杨博川 完善需求规格说明书
20211126 李浩瑞 完成项目的数据库设计
posted @ 2023-11-05 20:47  506ilou小组  阅读(33)  评论(0)  编辑  收藏  举报