| 这个作业属于哪个课程 | 班级的链接 |
|---|---|
| 这个作业要求在哪里 | 结对第一次—疫情统计可视化（原型设计） |
| 结对学号 | 221701228 & 221600137 |
| 这个作业的目标 | 学习《构建之法》第三章、第八章，完成结对合作任务，做出疫情统计可视化的原型 |
| 作业正文 | https://www.cnblogs.com/tmblb/p/12374698.html |
| 其他参考文献 | AxhubCharts教程，百度Axure实现中国地图，《构建之法》，... |
一、原型模型地址
二、NABCD模型
1.N（Need 需求）
需求描述：
有一家统计网站每天都会提供一个对应的日志文本，记录国内各省前一天的感染情况，上次的疫情统计结果只是通过文字来显示，不够直观、具体，对用户不够友好，在本次作业里，我们希望可以通过地图的形式来直观显示疫情的大致分布情况，还可以查看具体省份的疫情统计情况。
1.在全国地图上使用不同的颜色代表大概确诊人数区间
颜色的深浅表示疫情的严重程度，可以直观了解高危区域；
鼠标移到每个省份会高亮显示；
点击鼠标会显示该省具体疫情情况。
2.点击某个省份显示该省疫情的具体情况
显示该省份对应的感染患者人数、疑似患者人数、治愈人数、死亡人数；
该省份到目前为止的新增确诊趋势、新增疑似趋势、治愈趋势和死亡趋势。
2.A（Approach 方法）
对于本次需求，我们选择使用中国地图svg文件导入Axure建立可视化模型，进而实现基础的交互功能，最后将其包装成Web前端，达到简洁，直观的效果。
3.B（Benefit 好处）
1.使用可视化模型，对于数据的展示更加直观，交互更加简便，明了。
2.使用Web技术，方便访问与分享。
3.使用图表，使数据的变化与统计更加直观。
4.C（Competitors 竞争）
优势
1.Web技术使访问更加方便。
2.采用图表，让数据显示更加直观。
3.界面简介，没有冗余信息。
劣势
1.有许多类似产品陆续诞生。
2.Web技术虽然使其精简方便，但对后续开发有一定限制，若后续有较多的功能增加反而使其变得笨重。
5.D（Delivery 推广）
1.使用QQ推广。QQ作为一款用户量大且活跃的社交媒体，在QQ上推广能够快速辐射大量用户。
2.使用微信推广。微信与QQ类似但略有差别，微信的用户较为稳定，呢个够收获稳定客户。
3.使用微博推广。微博在拥有大量用户的同时，不需要添加好友便可看到对方的博文。
4.使用抖音推广。抖音作为短视频媒体的龙头之一，必然是重要的推广平台。
三、遇到的困难
困难
1.Axure的使用
Axuer对我们来说是一款完全陌生的软件，对其上手也有一些难度。
2.制作地图模型
制作地图模型的方法有许多种，我们刚开始直接用echart导入内联框架的方法来实现，在预览的时候效果非常好，但是在发布之后发现了问题，内联框架绑定的本地文件并不能在线显示出来。而且考虑到后期后端数据的绑定，echart直接导入是非常不明智的一种行为，于是我们决定推翻重做。
3.中继器与图表
在操作过程中，中继器的属性窗口找不到了，导致无法正确使用中继器，以至于图表数据暂时无法修改，只能保持默认值。
尝试解决
1.在知乎、简书等平台搜索了一些教程，加上自己的摸索，基本掌握了一些简单的元件的使用方法。
2.在搜索引擎与其他同学的帮助下，我们找到的方法。从找教程，找svg图片，到设计界面，实现交互等等，在一个相对不慢的速度重新用另一种方式实现了可视化模型，虚惊一场，但相对于某些大佬而言我们的模型还略为粗糙。
3.在知乎，百度，简书，Axure官方教程，甚至贴吧寻找过资料，了解了中继器的使用方法和功能，但还是找不到中继器的属性界面，以至于无法修改中继器中的数据。
是否解决
大部分我们目前遇到的问题已经解决，但中继器这个问题暂时还遗留着，我们目前会继续学习，会实时跟进进度。
收获与心得
学会了使用原型设计工具Axure，虽然说还是个半吊子。其次，慢慢地对项目开发有了一定的了解，一个项目从建立到实现并不是想到了，立马动手代码、改Bug、发布，就能把一个项目做好了。程序化地去推进一个项目能节省很多的时间、资源和成本，特别是在这个信息爆炸快速更新的时代。
四、使用的工具
Axure RP是美国Axure Software Solution公司旗舰产品，是一个专业的快速原型设计工具，让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具，它能快速、高效的创建原型，同时支持多人协作设计和版本控制管理。
五、结对过程
六、原型展示
原型的主界面
可现实当前确诊人数、疑似人数等信息。
可视化地图
直观地看到全国各省市感染情况。
鼠标与地图的交互
通过鼠标的移动，可以展示各省市的具体确诊人数，选中地区高亮表示。
图表展示
图表暂用默认数据。
七、PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| Estimate | 估计这个任务需要多少时间 | 30 | 30 |
| Development | 开发 | 510 | 670 |
| Analysis | 需求分析 (包括学习新技术) | 90 | 150 |
| Design Spec | 生成设计文档 | 30 | 30 |
| Design Review | 设计复审 | 15 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | - | - |
| Design | 具体设计 | 45 | 40 |
| Coding | 具体编码 | 300 | 360 |
| Code Review | 代码复审 | 30 | 60 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 40 |
| Reporting | 报告 | 55 | 60 |
| Test Repor | 测试报告 | 15 | 15 |
| Size Measurement | 计算工作量 | 10 | 15 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| Total | 合计 | 595 | 760 |