| 这个作业属于哪个课程 | 2020春丨w班 |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 结对学号 | 221701328 221701312 |
| 这个作业的目标 | 需求分析，原型模型的设计 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 邹欣《构建之法》 |
1、需求分析（NABCD模型）
这一次我们开发的软件--疫情统计可视化--是为了解决上一次作业中出现的问题，即大多数使用者对文字的感兴趣程度远不及一张图片，因此我们开发了这一软件。这一软件相对于上一次作业的命令行使用来说，不仅降低了用户的操作难度，用户不再局限于命令行的操作，而是通过更友好的点击操作进行互动查看；也增强了用户的使用欲望，使用图表或者图片的形式来展现数据，使得用户能够更直观、清楚地看到疫情的统计情况，而不再去看长篇大论的文字。基于NABCD模型的分析如下：
N(Need，需求)
自疫情产生以来，疫情的数据便牵动着所有人的心，“今天全国治愈了几个人啊？”，“我们省确诊的患者有多少啊？“......这些问题时常浮现于我们的脑海，因此开发出一个能够统计所有疫情数据的软件便成为了必要。这个软件会被很多人查看，上至老人，下至小孩，因此这个软件必须以图形界面的形式来实现，便于用户阅读与理解，用户在使用完后能对之前的问题作出解答，“哇，今天全国治愈了100个人，离胜利不远了！”，“我们省总确诊患者有50人”......
-
面向的对象
这次疫情波及的范围极广，全国各省或多或少都有出现，因此面向的对象是广大的群众。
-
用户的需求
将疫情的数据可视化，以图片或图表的形式呈现给用户，使得用户能直观、清楚地看出疫情情况，减轻用户阅读压力；用户能够通过点击的方式来查看某个省的具体数据，也可直接查看全国的数据；用户还可以通过查看折线图来查看数据的变化趋势如何；在最后用户还能查看国外的疫情情况，并提示用户抗击疫情的一些建议。
A(Approach,做法)
做这个软件的核心就是web数据的可视化，主要通过图形来表达信息，如高亮的数字，折线图，地图，表格等等对用户友好的方式。软件包括以下几个需实现的功能：
-
全国数据统计功能
在软件的初始界面显示，依次显示全国的患者情况：现有确诊人数，现有疑似人数，现有重症人数，累计确诊人数，累计治愈人数，累计死亡人数。在相应的数据下方显示较昨日的增长情况。在疫情地图的下方给出折线图，给出近一个月来患者数据的增长情况
-
疫情地图显示功能
展示出一幅全国地图，在每个省的相应位置写上名称，依患者的数量对各个省涂上不同深度的红色，在左下角显示颜色深浅代表的患者人数区间。用户可以点击单个省来查看该省的确诊患者人数，也可查看更详细的数据。用户可以在现有确诊和累计确诊两种情况中切换，来查看不同情况下的疫情地图。
-
省份数据显示功能
在用户查看省份详细数据后显示，依次显示该省份的现存确诊人数，累计确诊人数，累计死亡人数，累计治愈人数。在相应的数据下方显示较昨日的增长情况。给出折线图，显示近一个月来患者数据的增长情况。
-
全省份数据表格显示功能
在全国折线图后显示，以表格的方式依次列出每个省的情况，表格的表头从左往右分别为：现存确诊，累计确诊，死亡，治愈。表格从上到下按现存确诊的人数从大到小排序。表格每一栏都提供展开按钮，用户能看到各地级市的疫情数据。
-
全球数据表格显示功能
在全省份表格后显示，分别显示出全球7大洲的情况，表格的表头同全省份表格的表头一致，排序方式也一致。
-
辟谣与防护功能
全球数据后，显示谣言文章标题及内容。用户可查看文章内容或分享该文章。
B(Benefit，好处)
这个软件给客户/用户带来什么好处：
- 简单易操作。抛弃掉命令行的笨重方式，采用对用户更友好的点击和滑动方式来实现，使用起来是真正的“有手就行”。
- 显示直接，有效。通过图片、图表和地图的方式来显示，用户一眼就能看出数据的趋势和情况。
- 能进行交互。用户可以点击查看某一个具体省的情况。
- 数据全面而不冗余。用户能查看到的数据都是大部分人关心的有效数据，不会是无人关心的数据。
- 有世界疫情信息，用户能查看到世界疫情的现状。
- 获取辟谣信息。对于群众迷惑性较强的谣言进行辟谣，让群众安心。
C(Competitors，竞争)
- 这个软件属于后面进入市场的产品，具有后发优势（Second Mover Advantage,SMA）：
- 界面简洁、直观，用户一眼就能看到需要的信息。
- 图表、地图信息丰富而优美，能满足用户审美需求。
- 更新数据及时，能根据官方的数据进行实时更新。
- 增加了辟谣功能，对于用户关心的谣言进行辟谣，缓解群众情绪。
- 撇弃了一项目前不必要的功能：同乘查询。因为目前出行的人数少之又少，几乎用不到这个功能。
- 但这个软件也有自己的劣势
- 网络上关于疫情数据统计的可视化平台非常多，竞争压力大。
- 由于只是原型，所以并没有考虑到了所有方面，功能比较有限。
D(Delivery,推广)
- 可以借助校内的平台，如官方微博，微信公众号，QQ等常用的平台进行推广和宣传。
2、原型模型
-
原型链接
原型模型 (服务器太渣，加载较慢，请耐心等待)
-
原型设计工具
Axure Pr 9 Team Edition , echarts.js
-
主页预览图
3、结对过程
- 一开始我们不知道结对要怎么做，于是就单纯的吧作业分成两部分，一人做一部分。
- 然后我们看完《构建之法》结对相关的内容才知道结对两人之间应该怎么配合。
- 然后我们根据每个人的个人强项着重做相应的部分，一起讨论、查找资料。
- 最后我们各自撰写自己负责部分的博客，然后互相审查修改，完成了任务。
4、效能分析，PSP表格
-
效能分析
效能分析需要程序编码实现后才能进行，暂时无法提供效能分析数据
-
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 180 | 150 |
| Estimate | 估计这个任务需要多少时间 | 20 | 15 |
| Development | 开发 | 600 | 580 |
| Analysis | 需求分析 (包括学习新技术) | 150 | 120 |
| Design Spec | 生成设计文档 | 90 | 80 |
| Design Review | 设计复审 | 30 | 20 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 30 | 10 |
| Design | 具体设计 | 120 | 90 |
| Coding | 具体编码 | 120 | 100 |
| Code Review | 代码复审 | 10 | 10 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 20 |
| Reporting | 报告 | 10 | 10 |
| Test Report | 测试报告 | 10 | 10 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 1430 | 1255 |
5、困难与收获
-
遇到的困难：
- 一开始的困难是对用户的需求进行分析，如何分析？
- 由于我们是第一次接触到原型，对我们来说基本上一无所知。原型模型是什么？我们应该怎么去设计、制作？
- 地图要怎么制作，以及地图高亮、点击跳转的功能要怎么实现？
- 两人结对应该怎么互相协作？
-
解决方案
- 第一个困难很好解决，提示的很清楚。于是我去阅读了邹欣老师写的《构建之法》，阅读了第三章和第八章后，我们对NABCD模型有了大致的了解和认识，然后按照书上所写对这个软件进行了分析，得到了上面的分析结果。
- 我们花了大量的时间去查资料，看教程，终于弄懂了原型的概念，也学会了原型的设计。虽然制作的原型不是很好看，但总归有了成果。
- 我们查阅资料后发现用原型设计软件绘制地图以及实现地图相关功能十分复杂，于是我们决定使用js代码来完成这一需求。
- 我们阅读了《构建之法》中关于结对的部分，了解到了两人结对应该怎么去做，于是我们通过聊天软件互相协作，最终顺利的完成了任务。
-
收获
- 经过这次的作业，我们第一次接触到了结对任务，虽然成员间的配合还相当生疏，效率也没有太大的改善，但我们也获得了一次重要的经验，相信下次结对任务我们的配合能更进一步。其次我们也学习到了NABCD需求模型的建立，以及原型模型的设计。总的来说，经过这次作业，我们对软件工程、软件工程师的了解又更近了一步。
6、附件
博客pdf