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

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

一、任务详情

  1. 修改完善上周提交的需求规格说明书，并在博客中描述：上次的《需求规格说明书》初稿有哪些不足？修改需同时体现在Github的MarkDown文件与PDF中。
  2. 讨论制定团队的编码规范，讨论之前和讨论之后，队员阅读《构建之法》第四章内容，并讨论总结。将代码规范和编码原则发布在随笔上，并说说你们这么选择的理由。
  3. 通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。
  4. 进行项目的后端架构设计，要与需求规格说明书中的界面原型设计相对应。
  5. 确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：
    • 利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。
    • 在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。
    • 给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图。

二、任务实践

1.修改完善上周提交的需求规格说明书，并在博客中描述：上次的《需求规格说明书》初稿有哪些不足？修改需同时体现在Github的MarkDown文件与PDF中。
原文缺漏及改进
  • 排版错乱
原文：

改后：

原文：

改后：

  • 表意不当

    • 原文中用户场景部分说到管理员有公文修改权限，但其是对公文增删改查，并不对公文内容进行修改，所以应换成公文管理
    • 原文功能描述中管理员的公文集中管理表意不当，应改为公文备份

  • 功能非实用
    公文传输应以每个工作单位为单位，每个单位只能注册一个账号，但原文中写的则是注册只需要邮箱、用户名、密码即可，这完全不符合使用要求，应添加一项所在单位.

2.讨论制定团队的编码规范，讨论之前和讨论之后，队员阅读《构建之法》第四章内容，并讨论总结。将代码规范和编码原则发布在随笔上，并说说你们这么选择的理由。

编码风格规范

编码风格总原则：简明、易读、无二异性

  1. 库引用规范
  • 引用的库需要在程序最顶部声明,如C语言中#include<XXX.h>和’include<XXX.h>’需要在程序的最顶部，同时如果某些库只在各个系统上特有或需要下载的要添加注释。
  1. 变量定义规范
  • 所有的类型/类/函数名采用Pascal命名法：单字之间不以空格断开或连接号（-）、底线（_）连结，第一个单词首字母采用大写字母；后续单词的首字母亦用大写字母，例如：FirstName、LastName。美观方便，便于阅读。
  • 不把多个变量定义在一行上，一般不在变量定义的时候为其赋值。避免变量定义错误混乱，赋值不清晰。
  • 一个类型的成员变量用m_name来命名。统一方便，便于阅读。
  • 所有固定常数尽量用宏定义，在程序顶部规范。避免在程序中出现上下文不相关的未知数字。
  1. 代码设计规范
  • 函数只做一件事，一般使用单一出口，函数名一般代表函数功能。避免程序执行顺序混乱，便于阅读和理解程序。
  • 不在构造函数中做复杂的操作，简单初始化所有的数据成员即可。避免在函数中对另一个函数中的全局变量修改的操作等复杂操作，便于阅读。
  • 尽量少用goto。避免程序执行顺序混乱，便于阅读和理解程序。
  • C语言中，先定义所有的函数类型，再写main函数，再写各函数详细算法。使程序结构清晰可读，便于理解。
  1. 代码编写规范：
  • 使用{}时候单独成行，使用[]和()的时候不和其他变量间加入空格。如(i=0;i<1;i++),不用添加空格，视觉紧凑美观，便于阅读。
  • 只用ASCII字符，不要用中文。在代码中尽量不用中文字符，注释中可以适当添加。
  • 缩进时使用tab,不使用空格。
  • 在除了变量定义或函数名的地方尽量少使用下划线_。避免程序混乱，在使用_的地方一般可以理解为变量或函数，便于阅读
  1. 注释规范：
  • 使用//注释(C语言)解释程序做什么（What），为什么这么做（Why），以及要特别注意的地方。
  • 在该行写完后2个tab之后添加//注释(C语言)。
  • 注释的时候注意语言简洁规范，不要口语化。
3.通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图。

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

通过Spring Boot，可以轻松地创建独立的，基于生产级别的基于Spring的应用程序，您可以“运行”它们。
我们对Spring平台和第三方库持固执己见的观点，这样您就可以以最小的麻烦开始使用。大多数Spring Boot应用程序需要最少的Spring配置。
创建独立的Spring应用程序
直接嵌入Tomcat，Jetty或Undertow（无需部署WAR文件）
提供自以为是的“入门”依赖项，以简化您的构建配置
尽可能自动配置Spring和3rd Party库
提供可用于生产的功能，例如指标，运行状况检查和外部化配置
完全没有代码生成，也不需要XML配置
基于以上的优质特点，我们选择了Spring Boot作为主要后端设计框架进行搭建：

拟定项目结构：
启动类MyApplication.java
数据实体类

  • jpa项目
  • mybatis项目
    数据接口访问层
  • jpa项目
  • mybatis项目

数据服务接口层Service
数据服务接口实现层Service Implements
前端控制器层Controller
工具类库utils
配置类config
数据传输对象dto

5.确定团队分工。请参考"分而治之(WBS - Work Breakdown Structure)"，提供下述内容：
  • 利用象限法确定各个核心需求的优先级，依据需求优先级确定团队Alpha 版本需要实现的功能，在博客中叙述并给出相应的WBS图。
  • 在团队管理软件中（比如Github的Issue，Leangoo等）将各个叶子结点的功能加入，并确定每个子功能的工作量，在博客中给出分配后的截图。值得注意的是，与学习技术相关的任务也需要考虑在工作量中，开发需要检验产出，学习同样要有结果。PM可以用小Demo演示或学习心得博客作为学习任务的检验。
  • 给出团队各个成员（用学号代替姓名）认领的工作，列出当前团队的TODOList，并在最后给出燃尽图。


任务 完成人
撰写博客、使用leangoo确定团队分工与燃尽图 20201307梁辰鱼（组长）
编写讨论后的编码规范 20201323谭顺心
进行项目的详细后端架构设计 20201317鲁永欣
修改并完善《需求规格说明》 20201325夏俊睿
通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供相应ER图 20201310何忠鑫
列出当前团队的TODOList 20201222龚杰
posted @ 2022-11-06 19:59  ICEDREAM_X  阅读(179)  评论(1)  编辑  收藏  举报