结对第一次——疫情统计可视化（原型设计）
| 这个作业属于哪个课程 | 2020春W班（福州大学） |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 结对学号 | 221701418&221701435 |
| 这个作业的目标 | 某次疫情统计可视化 |
| 作业正文... | 此页 |
| 其他参考文献... | echarts |
设计原型
首页展示
NABCD模型
N（Need）
有一家统计网站每天都会提供一个对应的日志文本，记录国内各省前一天的感染情况，上次的疫情统计结果只是通过文字来显示，不够直观、具体，对用户不够友好，在本次作业里，我们希望可以通过地图的形式来直观显示疫情的大致分布情况，还可以查看具体省份的疫情统计情况。
- 在全国地图上使用不同的颜色代表大概确诊人数区间；
- 颜色的深浅表示疫情的严重程度，可以直观了解高危区域；
- 鼠标移到每个省份会高亮显示；
- 点击鼠标会显示该省具体疫情情况；
- 点击某个省份，显示该省份对应的感染患者人数、疑似患者人数、治愈人数、死亡人数；
- 显示该省份到目前为止的新增确诊趋势、新增疑似趋势、治愈趋势和死亡趋势
A（Approach）
查看全国具体疫情情况，并通过地图的形式来直观显示疫情的大致分布情况，并查看各省的疫情统计情况。
-
通过使用axure软件的内联框架实现地图的数据可视化，深浅表示疫情的严重程度；
-
提供各省份的高亮度显示，并提供福建省疫情具体统计情况以及疫情趋势；
B（Benefit）
-
以地图的方式体现全国疫情，更加直观；
-
以颜色深浅的方式表示各省份的疫情严重程度，对全国疫情可以快速的了解；
-
方便了解用户比较关心的省份的具体数据；
-
提供疫情趋势，方便用户了解疫情的走向；
C（Competitor）
优势
- 对现有疫情程序的使用情况分析，吸取前人的经验，抛弃用户体验不好的部分，可以节约大量时间成本；
- 内联框架的引入使地图的交互更加切合用户的需求；
劣势
- 疫情产品再多，竞争力大；
- 可扩展的功能还有很多，未很好的全部实现；
D（Deliver）
推荐给身边的同学使用，如果好用让他们再推荐给其他人，做到免费宣传；如有必要，还可以当街推广的形式宣传我们的程序；当今是互联网时代，更可以通过QQ空间、微信朋友圈、微博等等形式推广，好友多则阅读量大，更容易产生用户，且该方法成本低、收益高。
原型工具
Axure RP 9
Axure RP是一个专业的快速原型设计工具。是一个专业的快速原型设计工具，让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具，它能快速、高效的创建原型，同时支持多人协作设计和版本控制管理。
困难及解决方案
-
地图相关的亮度及严重区域的显示。
解决方案：使用Axure进行开发，同时对Axure的内联框架相关模型进行了熟悉，复习了Echarts的相关知识，成功解决问题。 -
全局信息和具体省份的切换，以及省份信息的图片化显示
将省份信息单独做成一个网页，用中继器实现图标交互
-
收获
-
221701418
通过此次编程实践，我收获了很多。首先是要注重团队合作。现在一个软件或者系统，其工程量不是一个人能够完成的，往往需要数十人甚至几百人来完成。因此在团队开发的项目中要养成良好的编程风格，注重沟通以及任务的分配。良好的编程风格有利于提升效率。沟通可以使得项目进展更快，减少误解。合理的分配任务可以使得每个成员从事自己擅长的工作，也能够提升开发效率。其次是善于利用互联网学习。即使一个人水平再高，也总会有知识盲区。就比如说这次作业中的博客原型制作就是我从未接触过的。但是通过互联网搜索教程使我了解了如何简单的制作博客原型。最后是要善于思考，寻找好的解题方法。
-
221701435
通过此次的结对协作，我更加懂得了如何去如何去与队友合作去解决问题，对团队合作有了更一步的理解，能更好地与队友进行沟通，学会了如何将自己的想法分享给队友一起讨论解决。通过此次得作业，我觉得一个人的自学能力很重要。要学会去如何解决问题，而不是去逃避。
-
同时，通过对构建之法第三章和第八章内容的学习，我们学会了一个软件工程师的思维应该是怎样的且如何去培养，且应该避免自己陷入一些误区。同时，知道了需求分析对一个软件的开发至关重要，我们学习了NABCD模型，通过这个模型，了解了软件开发的结构框架，收获颇丰。整个过程中走了不少弯路,对原型的理解还不是很到位,与伙伴之间的配合还有待提高,整个过程中原型设计,查找资料,echarts使用,服务器部署,都很有挑战同时很有意思
-
结对过程
-
拿到需求之后我们展开了对话，立马确定了分工，定下原型设计软件，开始熟悉原型设计软件；
-
肃南负责项目的主要开发，我负责项目功能的添加及修改，撰写文档；
-
两人第一次合作不是很有默契，不熟悉对方具有的开发技能，浪费了许多时间。
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 20 |
| Estimate | 估计这个任务需要多少时间 | 20 | 20 |
| Development | 开发 | 720 | 840 |
| Analysis | 需求分析 (包括学习新技术) | 60 | 90 |
| Design Spec | 生成设计文档 | 30 | 30 |
| Design Review | 设计复审 | 30 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 30 | 30 |
| Design | 具体设计 | 450 | 540 |
| Coding | 具体编码 | 60 | 60 |
| Code Review | 代码复审 | 30 | 30 |
| Test | 测试（自我测试，修改代码，提交修改） | 30 | 30 |
| Reporting | 报告 | 120 | 150 |
| Test Report | 测试报告 | 30 | 30 |
| Size Measurement | 计算工作量 | 30 | 30 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 60 | 90 |
| 合计 | 860 | 1010 |
