作业格式
| 这个作业属于那个课程 | 2020春 S班 |
|---|---|
| 这个作业要求在哪里作业要求 | 结对第一次—某次疫情统计可视化（原型设计) |
| 结对队伍 | 221701228 王嘉泓 221600137 郑廷健 |
| 作业正文 | |
| 这个作业的目标 | 阅读《构建之法》，了解NABCD模型，学习分析用户需求，利用相关软件设计原型 |
作业正文
NABCD模型
N（Need，需求）
从今年 1 月下旬开始，疫情开始全面爆发，全国人民与疫情的对抗正式拉开了的帷幕。疫情开始后，全国人民开始了禁足模式，大家的信息来源大部分来自互联网，并通过互联网来了解疫情实时情况。在上一次的寒假作业中已经通过文字来显示疫情统计结果，但是对用户来说，还需要更加直观、具体以及友好的界面，用户希望可以通过地图的形式来直观显示疫情的大致分布情况，还可以查看具体省份的疫情统计情况。有如下几点要求：
- 在全国地图上使用不同的颜色代表大概确诊人数区间
- 颜色的深浅表示疫情的严重程度，可以直观了解高危区域；
- 鼠标移到每个省份会高亮显示；
- 点击鼠标会显示该省具体疫情情况；
- 点击某个省份显示该省疫情的具体情况
- 显示该省份对应的感染患者人数、疑似患者人数、治愈人数、死亡人数；
- 该省份到目前为止的新增确诊趋势、新增疑似趋势、治愈趋势和死亡趋势
A （ Approach，方法 ）
于是我们利用Axure RP原型制作工具开发一款统计应用，实现了疫情统计实时数据的可视化。本次原型设计满足用户的需求——可以通过地图的形式来直观查看疫情的分布情况，进一步还可以点击查看某省份具体的疫情统计情况。
- 设计一个以Web页面为基础的界面来满足用户需求
- 全国数据可视化地图
1.在每个省份上表示出省份的名称，鼠标移至省份上方时显示相应的确诊患者人数。
2.依照每个省份确诊患者的数量，按照颜色变化 的标准，划分出地区疫情的严重程度，以颜色深浅标识出来（即深色区域为疫情严重区）。
3.点击某个省份，将跳转至对应省份的详细数据页面
- 全国数据可视化地图
- 各省份各类感染患者总数统计图
- 点击对应省份，跳转到该省份疫情统计的表格
- 主题界面：确定比例数，疑似比例数，死亡数，治愈数。
- 地图颜色深浅表示
- 截至时间
B （ Benefits，好处）
- 直观，各省份颜色的深浅表示疫情的严重程度，可以让用户一眼看出哪里是当前"最危险的地方"，从而提高警惕，避免不必要的麻烦。
- 具体，点击就能显示该省份对应的感染患者人数、疑似患者人数、治愈人数、死亡人数，通过具体的数字，让用户了解到当前形势。
- 从整体到局部，通过折线图来表现全国各种患者总数的变化趋势，与之相对应的还有XX省份各种患者人数的变化趋势。
C （ Compettors，竞争 ）
- 优势：相较于app客户端，该系统更加便捷，无需安装和卸载，操作简单，只要会上网就行。
- 劣势：存在如同数据分析方面不够全面，当前已经发布了很多类似的疫情可视化平台，从时间上来说我方还在开发阶段，相对落后。
D -- Delivery，推广
- 通过qq空间动态转发推广。
- 通过微信公众号来推送相关消息。
遇到的困难及解决方法
遇到的困难
- 使用哪种原型设计
- 如何在地图中直观显示疫情分布情况
- 不熟悉原型设计工具
- 如何在地图上点击跳转详细页面
解决困难
- 在经过各种比较后决定选择AxureRp作为我们的原型设计工具。虽然有考虑过墨刀，轻量，便捷，简单，但是相较之下，前者更加成熟，且功能丰富。
- 通过各种视频，以及上网查找资料，慢慢地学会简单地使用Axure，相比之前界面都不熟悉有了些许的进步。
- 通过网上查找资料，找到了第三方的Axhub组件，可以生成各类图表。
结对过程
与同班级同学一起结对
原型设计
建立模型使用工具：Axure rp
原型截图
主界面包含可视化地图
图表展示
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 120 | 148 |
| • Estimate | • 估计这个任务需要多少时间 | 360 | 540 |
| Development | 开发 | ||
| • Analysis | • 需求分析（包括学习新技术） | 60 | 60 |
| • Design Spec | • 生成设计文档 | 50 | 60 |
| • Coding Review | • 设计复审 | 30 | 20 |
| • Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| • Design | • 具体设计 | 0 | 0 |
| • Coding | • 具体编码 | 0 | 0 |
| • Code Review | • 代码复审 | 0 | 0 |
| • Test | • 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | ||
| • Test Report | • 测试报告 | 70 | 70 |
| • Size Measurement | • 计算工作量 | 30 | 20 |
| • Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 60 | 45 |
| 合计 | 540 | 573 |
总结
- 通过这次的结对原型设计，从刚开始的无从下手，到后面每一步设计完成的喜悦，收益颇多。按照发布的作业内容，从陌生的NABCD模型入手，让整个设计有了基本的方案，本以为按照这个模型在制作个差不多的草图，就可以从软件直接入手，但是在正式实施时就遇到了几个硬核的难题。比如软件的操作使用，制作过程时缺乏的相关数据以及队友之间不同的意见。并且在设计过程中发现软件的需求与自己的想法不匹配，与队友相互的讨论，反复的思考，然后在对大体的设计分工做出良好的分配。
- 经过这次看似有说明书的原型设计，我觉的一个有计划的、有协作能理的团队是非常重要的，当然也需要技术的支撑！