结对第一次——疫情统计可视化
| 这个作业属于哪个课程 | 2020春W班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 结对第一次—某次疫情统计可视化（原型设计） |
| 结对学号 | 221701330、221701332 |
| 这个作业的目标 | 开发一个疫情统计程序 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 百度 |
1. 设计过程
| 困难描述 |
|---|
- 怎样将中国地图各省分开，即将地图按各个省份分块
- 如何去制作地图高亮效果，即鼠标移入某省份高亮显示
- 对于这些原型工具之前毫无了解，只能自己摸索
| 解决尝试 |
|---|
- 百度了解到使用Axure Rp可以将svg类型的图片按形状分离，也就解决了如何去将各省分开的问题
- 通过对墨刀的摸索发现可以通过交互改变组件状态来实现高亮效果
- 百度+看教程+自己上手慢慢摸索原型工具的使用
| 是否解决 |
|---|
- 是
- 是
- 大致上手了墨刀
| 有何收获 |
|---|
- 首先当然是对墨刀等原型工具有了一定的了解，不再是一无所知的小白
- 其次，感觉设计阶段也是不简单，需要我们去重视，去好好思考
- 再有就是边看边学边去亲身尝试墨刀的使用，果然更容易让人上手
2. NABCD模型描述
N(need,需求)
目前新型冠状病毒肺炎疫情到了非常关键的时期，学校仍然是严阵以待。继续沿用我们在寒假作业（2/2）——疫情统计的问题，
有一家统计网站每天都会提供一个对应的日志文本，记录国内各省前一天的感染情况，上次的疫情统计结果只是通过文字来显
示，不够直观、具体，对用户不够友好，在本次作业里，我们希望可以通过地图的形式来直观显示疫情的大致分布情况，还可
以查看具体省份的疫情统计情况。经过分析和讨论有如下几点需求：
-
在全国地图上使用不同的颜色代表大概确诊人数区间
-
颜色的深浅表示了疫情的严重程度，直观的展示了疫情的总体分布
-
鼠标移动到省份会高亮显示
-
点击省份会显示该省份的详细信息
-
点击某个省份显示该省疫情的详细信息
-
显示该省份对应的感染患者人数、疑似患者人数、治愈人数、死亡人数
-
该省份最近疫情变化趋势
-
拓展需求
-
显示一些防疫小知识
-
关于疫情的新闻
A(approach,做法)
-
解决方案的构成
通过Web实现疫情数据的可视化，通过地图图表等方式可以更直观的体现疫情的情况，让用户能够更好的获得疫情信息。 -
全国状况
根据各地确诊人数，以不同深度的红色为色调（无确诊为白色），颜色由浅到深，表示所在省份疫情越严重。
捕捉鼠标，鼠标移动到任意省上时，该省高亮显示为青蓝色同时显示简略的该省份的疫情信息。
鼠标点击省份，跳转到另一个网页，显示该省的具体详情。
同时拓展的疫情知识和实时最新文章网友关心的问题和官方发布的的最新动态一目了然，文章选自人民日报等权威机构，保证严谨性。 -
省内情况
包括“疫情状况”：显示该省份对应的新增感染患者人数、新增疑似患者人数、确诊人数，累计治愈人数、累计死亡人数；
这些趋势图根据往日数据产生，有明显的增减趋势，更加直观。
B(benefit,好处)
-
各省份颜色的深浅表示疫情的严重程度，可以让用户一眼看出哪里是当前"最危险的地方"，从而提高警惕，避免不必要的麻烦。
-
具体，点击就能显示该省份对应的感染患者人数、疑似患者人数、治愈人数、死亡人数，通过具体的数字，让用户了解到当前形势。
-
从整体到局部，通过折线图来表现全国各种患者总数的变化趋势，与之相对应的还有XX省份各种患者人数的变化趋势。
-
包含疫情小知识和最新新闻模块使得功能更丰富。
C(competior,竞争)
-
优势
-
操作简单，大部分人可轻松使用。
-
实时更新，符合当下时事。
-
界面简单明了，数据体验直观。
-
劣势
-
同款产品层出不穷，且技术成熟，市场被更早的占领。
-
不具有复用性，等疫情过去了，该功能也没用了。
D(delivery,推广)
可以将该网页链接附在我们平时使用的社交网页上，也可以发布到各个网络平台，感兴趣的人都会点进来看
3. 原型
- 工具：墨刀
- 原型地址
4. 结对过程
- 看到这次作业需求，我们便开始了讨论，并确立分工，分头行动
- 当然，对分工合作还是有些陌生的，也浪费了挺多时间
- 也就这么磕磕绊绊的完成了
| 讨论截图 |
|---|
 |
 |
 |
5. PSP表格
| psp2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| Estimate | 估计这个任务需要多少时间 | 20 | 25 |
| Development | 开发 | 800 | 960 |
| Analysis | 需求分析 (包括学习新技术) | 60 | 120 |
| Design Spec | 生成设计文档 | 60 | 90 |
| Design Review | 设计复审 | 20 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 30 | 30 |
| Design | 具体设计 | 240 | 180 |
| Coding | 具体编码 | 300 | 600 |
| Code Review | 代码复审 | 60 | 60 |
| Test | 测试（自我测试，修改代码，提交修改） | 120 | 180 |
| Reporting | 报告 | 60 | 120 |
| Test Repor | 测试报告 | 60 | 60 |
| Size Measurement | 计算工作量 | 40 | 30 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 40 | 60 |
| 合计 | 1200 | 1390 |
6. 心得体会
| 最大的体会当然是原来设计也这么累人。为了达到用户满意，便于与人交互的效果，仅仅是一个小功能就要考虑良多。虽然题目给的需求看起来挺简单的，但自己实际去上手就发现到处都得考虑，实在是有点花精力。 |
|---|
7. 博客PDF
| 在这 |
|---|
