结对作业（1/2）
| 这个作业属于哪个课程 | 点击前往 |
|---|---|
| 这个作业的要求在哪里 | 点击前往 |
| 结对学号 | 221701133,021700511 |
| 这个作业的目标 | 设计方案，描述方案，制作原型，提供解决方案 |
| 作业正文 | .... |
| 其他参考文献 |
1.疫情原型模型
2.基于NABCD模型的解决方案
我们的产品“疫情情况可视化平台”，旨在帮助用户从繁杂的各类资讯中整理汇总出疫情数据与情况，并简洁明了地进行显示，以满足用户最重要的需求。
2.1 N（Need，需求）
通过调查，我们发现用户主要是有这些方面的需求：
①. 在全国地图上使用不同的颜色代表大概确诊人数区间。
②. 地图上各个省份颜色的深浅表示疫情的严重程度。
③. 鼠标移到每个省份会高亮显示。
④. 鼠标点击地图上的省份会显示该省具体疫情情况。
⑤. 省份具体情况有：对应的感染、疑似、治愈、死亡人数。该省到目前为止的新增确诊、疑似、治愈、死亡趋势。
⑥. 用户想知道疫情相关的资讯与传言真假。
2.2 A（Approach，方法）
针对上述用户所提需求，我们将逐一进行解决用户痛点：
①. 数据以现确诊、累计确诊、疑似、累计治愈、累计死亡的人数来展现，并会以小字显示最新数据变化量。
②. 通过折线图来反映各个方面人数趋势的变化，鼠标置于折线点时将显示对应时间点的疫情某方面情况人数。
③. 地图上各个省份的颜色从白到深红显示，逐级对应从正常到十分严重，以此来向用户反馈疫情的严重程度。
④. 用专门的页面提供疫情最新情报，内容包括大众热搜与谣言粉碎。
2.3 B（Benefit，好处）
我们这个产品能给用户带来这些好处：
①. 可以通过图像直观获取疫情数据情况。
②. 操作简单，用户只需要点击地图上具体省份即可查看该省的详情，学习代价极小。
③. 可以到手实时更新的疫情最新动态，快速查看相关信息。
2.4 C（Competitors，竞争）
①劣势：目前市场上同类产品较多，功能涵盖面也较于成熟，并且各自都有依托于自身的大平台进行推广。我们产品受限于时间等因素无法做到功能庞大，也难以与这些先发产品依托的人们所熟知的大平台进行宣发上的竞争。
②优势：虽然市场上同类产品趋于饱和，但是我们产品依旧可以在这样的环境中独树一帜。首先，我们的产品简洁美观，不掺杂无用于用户需求的元素，用户可以轻易获取到自己所需要的信息。此外，提供的“最新动态”功能同时提供了当前热搜与谣言粉碎的信息，用户介以很方便地获取这两方面的信息。另外，在疫情信息更迭迅速的当下，我们产品更新讯息的速度即时准确，可以更好地满足用户的需求。
2.5 D（Delivery，推广）
我们产品本身轻量小型，操作简单方便，无论是年轻一辈或是对应用功能操作不熟练的老人也可以轻松学会。所以我们打算广泛宣传，在各类公众号和社交软件上都尝试投放广告。
3.采用的原型开发工具
墨刀。墨刀是一款在线原型设计与协同工具，借助墨刀，产品经理、设计师、开发、销售、运营及创业者等用户群体，能够搭建为产品原型，演示项目效果。
4.遇到的困难与解决方法
4.1 困难：原型设计工具墨刀的使用
解决尝试：通过百度等一边获取资料一边学习摸索，先建立实验性的一个原型进行实践熟悉使用墨刀。然后再开展本次作业的疫情可视化原型设计。
是否解决：是
收获：对原型开发工具墨刀具有一定的操作了解
4.2 困难：省份的高亮显示
解决尝试：最早使用echarts来实现地图这一部分的，但是写完发现墨刀并不能导入js，只能挂在一网页上，然后通过网页组件导入，但是导入后地图里的跳转又不好实现。后来想了想，原型图并不需要去实现所有功能，于是简单处理，只对一个省份进行高亮处理，这样只需要几个简单的事件就能完成效果。
是否解决：是
收获：原型图不是实际产品，不需要完整的功能，只需要简单的实现即可。
4.3 困难：UI应该怎么设计
解决尝试：与队友相互沟通探讨，并参考已有的类似软件的设计。
是否解决：是
收获：一个人的审美远远不足以设计一款面向大众的UI讨喜的软件，不仅需要与其他人（特别是队友）、受众进行交流探讨，并充分利用前人设计的已经证明没有问题的设计方式，以避免设计出影响用户体验的界面。
5.结对过程
6.本次作业的效能分析与PSP表格
6.1 效能分析
6.2 PSP表格
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 20 |
| Estimate | 估计这个任务需要多少时间 | 30 | 20 |
| Development | 开发 | 630 | 820 |
| Analysis | 需求分析 (包括学习新技术) | 180 | 215 |
| Design Spec | 生成设计文档 | 30 | 40 |
| Design Review | 设计复审 | 30 | 20 |
| Design | 具体设计 | 300 | 540 |
| Code Review | 代码复审 | 30 | 25 |
| Test | 测试（自我测试，修改代码，提交修改） | 60 | 40 |
| Reporting | 报告 | 120 | 100 |
| Test Repor | 测试报告 | 60 | 45 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 60 | 55 |
| 合计 | 780 | 940 |