确定分工

确定分工

1. 上次的《需求规格说明书》初稿的不足之处。

• 加密技术不够细化，应该包括：身份验证、数字签名、明文加密；

• 公文系统使用者权限不够细化，应包括：

用户层面

用户可对公文文件进行发送、接收，对自己权限以内的文件浏览、查询、下载等。
公文传输：在安全登录情况下，从电脑中将需处理的公文上传至电子公文系统。
公文加密：将公文使用密码算法加密进行加密发送。
公文接收：对相应接收到的公文进行判断并解密，浏览下载公文。

管理员层面

公文管理：使用者根据自己所发布或所接收的文件，按照密级、紧急程度等进行分类归档。
管理员可以查询浏览所有文件，普通用户只能阅读自己对应权限下的文件。
管理员可根据系统设置的安全规则、安全策略对不同级别的用户分配不同的权限。
管理员可增加、删除和修改系统角色信息。
管理员可进入后台选择文件列表，查看用户发布及签收文件的情况，可查询所有发布和接收的公文。

• 文件发送前，服务器端加密模块进行密钥协商，生成密钥，终端用户利用对称密钥进行公文加密传输。
  服务器端按照相关权限修改，将公文放在接受目录的用户下，接收方通过服务器身份认证，进行相应公文的浏览下载。
  修改后的Git链接：https://gitee.com/rookie-hacker_1/myproject

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

《构建之法》第四章讲的是两个人的合作、结对编程。结对编程往往只需花费大约一半的时间就能编写出质量更高的代码。以下是分别对这三个方面的分析与理解：

• 编程规范
  《构建之法》中的编程规范主要包括代码规范、代码风格规范和代码设计规范。此处规范的标准是简明易懂、能让其他程序员更好地理解和维护。对于编程规范的重要性，相信很多人都深有体会，平时上网找参考代码或者是跟别人合作做一些编程作业，最怕就是对方的代码不规范，看起来费时又揪心。其实别说是其他人，如果我们没有一个规范的编程习惯，我们自己回头看自己以前写的代码，恐怕也是很难看懂的。因此在给函数或者类取名的时候要严谨，不能写一些没意义的名称；在一些代码后面可以加些注释来说明此行代码的作用。

• 代码审核
  为什么要注重代码审核？是因为不相信程序员的能力吗？明显不是的，再有能力有经验的程序员也会有出错的时候，这时候若没有严格的代码审核流程，错误往往就会被忽略，直到产品交到用户手上使用错误才逐渐暴露出来，从而造成不可挽回的损失。而代码审核又有自我审核、同伴审核和团队审核几种形式，其作用都是不一样的，自我审核一般能检查一些由于疏忽而产生的错误，同伴审核能以与程序员本人不一样的思维来看代码，从而能发现一些程序员本人考虑不到的问题，而团队审核则往往是站在项目总体的角度分析该代码，从而检查改代码是否能实现了本来要求的功能需求。

• 结对编程
  无论是乔布斯与乔纳森，还是比尔盖茨与保罗艾伦，我们看到了太多的结对模范，他们的成功都离不开彼此。一个人的能力是有限的，在奋斗的路上我们往往需要一个志同道合的人和你一起努力；一个人的思想也是局限的，我们很多时候还需要一面镜子，在镜子中的人对比，发现自身的优点与不足，镜子中的人有时候可以是自己，但更多的时候会是你的搭档。无论是作为一名志同道合的合作伙伴，还是忠实无条件的支持者，还是在我们犯错时及时指正的引路者，你的搭档都是难得而珍贵的。所以我觉得，重视结对编程，有百利而无一害。

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

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

我们设计的公文传输系统的后端架构由用户模块、服务器模块和数据库三部分组成。用户模块实现的功能有登录、注册、上传公文、接收并下载公文和加密模块，其中加密模块包括密钥协商、文件加密和解密。服务器模块由身份认证、用户注册、密钥管理子系统和文件管理子系统构成，其中密钥管理子系统的功能有密钥协商、密钥销毁和文件传输加密；文件管理子系统的功能有修改文件权限、归档文件至接收用户目录和将传输信息在数据库中记录。数据库部分的内容包括普通用户权限表、管理员权限表、用户及公文存储目录和公文下载传输信息记录表。

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

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

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

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

6. 描述组员在上述任务中的分工和工作量比例。

7. 附录

• 燃尽图