Team informationhtml
Division of labor前端
| 模块序号 |
模块名 |
模块具体内容 |
| 1 |
现场签到 |
1）实现基本的签到功能数据库 2）改进签到功能实现优化小程序 |
| 2 |
发布通知 |
1）实现基本的通知功能后端 2）实现通知栏提醒功能服务器 |
| 3 |
投票 |
1）实现基本投票功能markdown 2）结果数据的分析与返回工具 |
| 4 |
想法收集 |
实现基本的问答功能 |
| 5 |
文章共享 |
1）实现基础的文本编辑功能post 2）完成简单的文本选择注释功能学习 |
-
- 燃尽图
UML Design
Part1：（部署图）
• 这里描述的是系统哪部分？
这里主要说明的是部署问题
• 这部分要面临什么样的问题？
服务器及数据库的搭建，先后端交互等。
• 如下设计解决了哪些问题？
解决的问题：
前端客户操做返回给后台服务器，后端服务器依照前端操做给出相应返回值，从数据库中调用相应的数据。
Part2：（类图）
• 这里描述的是系统哪部分？
使用WeEdit小程序的功能方面内容。
• 这部分要面临什么样的问题？
1）项目模块定义不够清晰；
2）代码未有统一格式；
• 如下设计解决了哪些问题？
解决的问题：
经过统一参数，方便后续先后端工做的配合。
Part 3：（状态图）
• 这里描述的是系统哪部分？
这部分UML描述了发布签到、发布共享文档、发布投票功能可能的状态以及其中状态的具体活动
• 这部分要面临什么样的问题？
每一个具体状态转化细化得不够彻底、在实现中还需更近一步改进
• 如下设计解决了哪些问题？
解决的问题：
体现了软件须要的功能以及解决了软件内部各功能实现的逻辑问题
Part 4：（用例图）
• 这里描述的是系统哪部分？
这里是用户在**WeEdit**系统上可以进行各项操做的部分，以及对操做内容的具体化。
• 这部分要面临什么样的问题？
须要面临功能如何按照用户习惯排布的问题
• 如下设计解决了哪些问题？
解决的问题：
各个功能模块之间直观的逻辑联系
Part 5：（活动图）
• 这里描述的是系统哪部分？
描述了用户具体选择发布通知，现场签到，投票，想法收集和文章分享这几大模块。以及每一个模块相对应的后续操做和结果。如进入现场签到模块后，能够选择签到会议。
• 这部分要面临什么样的问题？
不能防止同窗带翘课的同窗的手机来签到。
• 如下设计解决了哪些问题？
解决的问题：
解决了用户权限的问题。不一样权限的用户进入不一样的界面，进行不一样的操做，不会发生权限混乱形成文件出现错误。
Part 6：（时序图）
• 这里描述的是系统哪部分？
展现对象之间交互的顺序。它经过描述对象之间发送消息的时间顺序显示多个对象之间的动态协做。
• 这部分要面临什么样的问题？
须要理清项目各模块内的逻辑，按时间顺序显示各模块内的动态协做。
• 如下设计解决了哪些问题？
解决的问题：
更加清晰地展现了各模块内的交互逻辑、交互顺序。
Part 7：（实体关系图 ）（本人完成的部分~~~(*^_^*)~~~）
• 这里描述的是系统哪部分？
主要描述的是系统的概念结构设计的部分。
• 这部分要面临什么样的问题？
实体的决定、实体属性的决定、实体之间的关系（包括了一对一，一对多，多对一，多对多）
• 如下设计解决了哪些问题？
解决的问题：
1） 分配了七个实体：参与者、发起者、投票、现场签到、文章分享、想法收集、发布通知
2） 各实体属性的决定。具体属性可参照“实体关系图”。
3） 各实体之间的关系。具体实体之间的关系可参照“实体关系图”
（发起者）
（参与者）
Selected tool
1）ProcessOn属于线上的编辑软件，无需额外下载，随需随用！
2）ProcessOn操做界面整洁明了，极易上手，对新用户的操做而言十分友好！
3）ProcessOn功能丰富，可以解决许多图形的绘制问题，额外功能十分丰富！
4）ProcessOn集成了许多图形的绘制，集成性强！
5）同窗的推荐啦~~
Evaluation of the tool
1）无需下载， very convenient！
2）功能丰富，very convenient plus one！
3）极易上手，very convenient plus two！
PSP表格
| Planning |
计划 |
15 |
10 |
| · Estimate |
· 估计这个任务须要多少时间 |
5 |
8 |
| Development |
开发 |
|
|
| · Analysis |
· 需求分析 (包括学习新技术) |
50 |
20 |
| · Design Spec |
· 生成设计文档 |
20 |
10 |
| · Design Review |
· 设计复审 (和同事审核设计文档) |
10 |
15 |
| · Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
0 |
0 |
| · Design |
· 具体设计 |
30 |
90 |
| · Coding |
· 具体编码 |
0 |
0 |
| · Code Review |
· 代码复审 |
0 |
0 |
| · Test |
· 测试（自我测试，修改代码，提交修改） |
5 |
15 |
| Reporting |
报告 |
|
|
| · Test Report |
· 测试报告 |
0 |
0 |
| · Size Measurement |
· 计算工做量 |
10 |
5 |
| · Postmortem & Process Improvement Plan |
· 过后总结, 并提出过程改进计划 |
20 |
10 |
| 合计 |
|
160 |
183 |
评估成员的贡献分配
| 黄毓明(临时队长) |
15+2=17 |
| 杨礼亮 |
14+2=16 |
| 礼亮 |
11+2=13 |
| 蒋熊 |
6+2=8 |
| 黄志铭 |
6+2=8 |
| 苏路明 |
13+2=15 |
| 陈瀚霖 |
7+2=9 |
| 胡展瑞 |
12+2=14 |
| 031602219 |
柯奇豪(队长) |
12.5% |
分配到的任务不难，算是正常操做，做为标准拿个基础分 |
| 041602209 |
黄毓明 |
14.5% |
做为临时队长分配管理很好，各项任务也能尽职尽责 |
| 041602204 |
丁水源 |
13.5% |
任务完成基本符合预期，可是用词上还须要改进，例如ER图中实体、属性应该是名词，“核实”以及某些实体的叫法都偏动做了些 |
| 061600236 |
黄礼亮 |
13.5% |
任务完成基本符合预期，可是菱形分支上缺少条件说明，部分箭头指示缺失，还望及时修改 |
| 031602603 |
陈超星 |
6.5% |
参照交换组的评定，彷佛贡献度不够，需注意 |
| 181600215 |
林翔宇 |
12.5% |
参照交换组的评定，任务完成基本符合预期 |
| 031601123 |
黄志铭 |
10.5% |
两人作的话彷佛分摊的工做量略小，同时类图的规范标准彷佛没有明确，"+"(public)、"-"(private)和"#"(protected)的区别 |
| 031601124 |
蒋熊 |
10.5% |
两人作的话彷佛分摊的工做量略小，同时类图的规范标准彷佛没有明确，"+"(public)、"-"(private)和"#"(protected)的区别 |
给出本次换队环节的感觉
- 这种换队环节我以为颇有趣啊，原来团队成员对于分工之类的都是比较明确的，若是此次没有换队这个环节，那你们就是按照本身的作，可是正由于此次换队环节，原来的计划一会儿被打乱了，也不能说乱，就是发生了一些变化。甚至换队的一些人咱们还不认识，以及换队成员可能对本组项目不熟悉，所以此次换队咱们面临着从新规划、认识新队员以及熟悉工做方式、和造成新的配合关系和模式等等。这样的“忽然”的事件让人颇有新鲜感和兴趣。并且因为队长换走，原本可能会引发一点点乱，但实际也没有，小组的人仍是很积极的，很快站出来临时队长，这就使事情顺利多了。所以我以为仍是很不错的。哈哈哈！