| 这个作业属于哪个课程 |
|
|---|---|
| 这个作业要求在哪里 |
|
| 结对学号 |
|
| 这个作业的目标 |
|
| 作业正文 |
|
| 其他参考文献 |
|
NABCD模型
N（Need，需求）：
目前新型冠状病毒肺炎疫情到了非常关键的时期，大家非常关注疫情，由此我们做了疫情统计程序，将各省的疫情收集然后集中显示，但是上次的疫情统计结果只是通过文字来显示，不够直观、具体，对用户不够友好，故新的可视化的疫情统计程序有很大的需求，值得一做。
A（Approach，做法）：
通过地图的形式来直观显示疫情的大致分布情况，还可以查看具体省份的疫情统计情况。
在地图上方显示全国数据，在各指标下方小字显示对比昨日新增人数。
在全国地图上使用不同的颜色代表大概确诊人数区间
* 颜色的深浅表示疫情的严重程度，可以直观了解高危区域；
* 提供现有确诊和累计确诊的两份地图；
* 鼠标移到每个省份会高亮显示；
* 点击鼠标会显示该省具体疫情情况。点击某个省份显示该省疫情的具体情况
* 显示该省份对应的感染患者人数、疑似患者人数、治愈人数、死亡人数,在各指标下面小字显示对比昨日新增的人数；
* 该省份到目前为止的新增确诊趋势、新增疑似趋势、治愈趋势和死亡趋势。
B(Benefit，好处)：
- 以地图的方式体现全国疫情，更加直观；
- 用颜色深浅的方式表示各省份的疫情严重程度，一眼就能对全国的疫情有个大概的了解；
- 用户一般比较关心所在省份的疫情，该程序可以选择想要的省份查看具体情况，符合用户需求；
- 提供对比昨日的数据，可以清楚的了解疫情的走向，也是用户关心的问题；
- 如果单看昨日数据还不够清晰，我们提供了具体省份的各指标人数的曲线图，非常直观；
C（Competitors，竞争）：
优势：后发优势的“免费搭乘”效应，可以站在前人的肩膀上看问题：
1.对现有的疫情程序的使用情况进行分析，吸取前人的优点，摒弃用户体验不好的部分，可以节约大量时间成本，这是我们的优势之一；
2.在位者惯性：由于沉没成本的存在，组织僵化，不愿引进新产品或改进产品，不愿改革，而后动者作为一个追赶者，时刻都想抓住机遇从而取代先动者的地位，因而可以进行大量的革新，从而在与先动者的竞争中占有优势。
劣势：
另一方面，同期也有很多涌入的竞争者（同学），由于两人少有团队合作的经验，在技术水平、两人组队的配合等方面我们可能不占优势。
D（Delivery，推广）：
身为大学生有天然的推广优势：可以推荐给身边的同学使用，如果好用让他们再推荐给其他人，做到免费宣传；如有必要，还可以当街推广的形式宣传我们的程序；当今是互联网时代，更可以通过QQ空间、微信朋友圈、微博等等形式推广，好友多则阅读量大，更容易产生用户，且该方法成本低、收益高。
采用的原型开发工具
原型工具：Axure RP
原型项目地址
(加载可能需要点时间...)
结队过程
首先我们阅读了《构建之法》的第三章和第八章，通过NABCD模型进行研究设计。
之后，我们选定了原型设计工具。
开始设计时我们有着许多的疑惑，在接下来的学习中慢慢解开，
经历了几版的原型设计，最终得出了结果。
设计过程
困难和解决
困难描述
看完题目我们就有了疑惑:
1.如何在原型中显示选定省份高亮？
2.如何让颜色深度对应感染的人数？
3.曲线图要如何实现？
4.原型要做到什么程度？
5.原型要如何在博客中展示？
解决尝试
1&2.找到了阿里云的接口获取全国各省份的svg，然后部署多个热区实现了全国省份高亮显示。
查看原图
3.最后是以外部做好然后导入axure的形式来完成折线图的设计，效果没有那么好但勉强能用。
查看原图
4.考虑到下次作业应该要实现这次的原型，鉴于我们的能力有限，所以把一些比较难实现的（对于我们的实力来说）功能都砍掉了，目标就是精简，快速实现原型。
由于时间限制，通过这几天里的学习仍然对Axure RP这软件的使用不够熟练，错误估计了做原型所需要的时间，导致有些虎头蛇尾。
基础需求基本在原型中体现出来了，趋势图由于使用的是外部的JSure，所以无法在原型中实现要求的鼠标移到对应日期上显示当天的确诊人数（这个在下次作业尽量实现），以及为图方便在原型的地图中的确诊数据都是以***来代替确切数据。上头的数据部分用的是写原型完成时当天的数据，如图：
查看原图
可能我俩的审美都不太行，所以可能有些不那么美观，请见谅。
5.思来想去，只能以发布到云端然后贴链接的方式来展示原型最为方便...
是否解决
-
1&2.解决
-
3.解决
-
4.解决
-
5.解决
有何收获
首先，是对原型模型设计工具（Axure RP，墨刀）的使用逐渐熟练，基础功能大致会用。刚开始用Axure的时候不太会，在与队友的不断讨论中做了又删，删了又做，后来通过同学的得知，用了一个模板，在它的基础上改，在这过程中不知不觉就学会了，组建也都熟悉了，在讨论中慢慢把原型做了出来。
其次，是对原型开发从无到有，有了一定的了解。
最后，是从这次原型设计过程中的体会，俗话说万事开头难，刚开始做这个作业的时候由于没有使用过相关的工具和参加过类似的项目，得边学边做，显得有些手足无措。
效能分析与PSP表格
效能分析：由于这次是原型设计，没有代码部分，所以效能分析暂无法估计......
PSP表格：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 30 |
| Estimate | 估计这个任务需要多少时间 | 30 | 45 |
| Development | 开发 | 540 | 600 |
| Analysis | 需求分析 (包括学习新技术) | 120 | 120 |
| Design Spec | 生成设计文档 | 120 | 150 |
| Design Review | 设计复审 | 20 | 30 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| Design | 具体设计 | 300 | 420 |
| Coding | 具体编码 | 0 | 0 |
| Code Review | 代码复审 | 0 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 60 | 60 |
| Test Report | 测试报告 | 30 | 20 |
| Size Measurement | 计算工作量 | 20 | 20 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 20 | 20 |
| 合计 | 1290 | 1515 |
心得体会
体会很深的一点是NABCD模型，学习了NABCD的分析原则，这是一个很成熟的商业软件分析模式，Need考虑到用户的需求，Approach从用户的需求出发提出我们的解决方案，Benefit也是从用户的角度出发看看到底解决了用户的什么痛点，Competitors分析了软件的竞争力所在，Delivery要求考虑后期的推广；NABCD模式即考虑到了用户的需求，又考虑到了软件本身的竞争力以及市场推广，把这五项进行透彻的分析后很容易看出我们所设计的软件优势在哪，劣势在哪，有助于我们进行完善软件的设计。
当然，最深刻的体会就是：这次作业虽然不涉及编码，但依旧很累，要是再多几天就好了...
附件：
PDF下载链接