| 这个作业属于哪个课程 | 软件工程实践 |
|---|---|
| 这个作业要求在哪里 | 疫情统计可视化（原型设计） |
| 结对学号 | 221701309，221701403 |
| 这个作业的目标 | 需求分析、可行性优化，原型设计 |
| 作业正文 | 正文如下 |
| 其他参考文献 | .... |
一、阅读《构建之法》第3章和第8章的内容
1.NABCD模型使用的详细说明
构建之法中有一句话令我印象深刻：软件开发的过程，就是“用户最需要的东西”在下面这一链条中传送、转换、实现、扭曲或丢失的过程：用户最需要的＞用户表达出来的＞软件团队能理解的+团队商业目标＞软件团队成员具体表达出来的＞在各种约束条件下，具体执行表达出来的＞验证通过的＞通过各种渠道告诉目标用户（发布/推广）＞用户终于用上了。那么我们这一次的任务其实也是这句话的一个具体反映，我们尽量不使用户最需要的东西在这一过程中扭曲或丢失，并将它完善。
NABCD模型在这次任务中的具体意义：
- N（需求）
需求就是上文“用户最需要的东西”。单纯用日志文本的形式来展示疫情情况很明显不够友好直观，为了用户更好的体验，我们需要将疫情数据和感染情况可视化，以便用户更好的把握疫情情况。当然，根据构建之法中提到的，有些需求是可以明面上直接看出来或表达出来的，而有些需求是用户没有表达出来，需要我们去捕捉的。那么像最基本的界面简洁美观，操作简单，使用代价小等等因素，而是我们需要达成的。
- A（做法）
通过web平台实现疫情数据和感染情况的可视化，结合图形图像等手段将传统的文本转换成更易于理解的视觉表现。
①将感染数据分门别类，以现有确诊，现有疑似，现有重症，累计确诊，累计治愈，累计死亡划分，并在数值下显示昨日变化人数
②全国整体以地图形式可视化，每个省份以边界划分，省份颜色深浅与左下角感染人数区间对应
③鼠标移至省份显示高亮，点击可进入省份具体信息，该省份中的市同样以边界划分，与全国整体地图类似
④该省份目前为止的新增确诊趋势，新增疑似趋势，治愈趋势和死亡趋势以曲线显示
⑤省份具体信息中包含各市定点医院，方便就医
- B（好处）
在原本只将全国整体情况和各省份具体数据和变化趋势的基础上，新增各市份感染情况以及各省份定点医院的显示，同时界面简洁，操作简单，用户使用代价小
- C（竞争）
目前为止，市面上已经有几个同类型平台，因此想要更加出众吸引用户目光较为困难。虽然时间紧迫导致功能不完善，但是我们也拥有界面简洁，操作方便的优点，并且还可以查看省份定点医院，便于及时就医，这些都可以作为我们竞争的支柱
- D（推广）
虽然目前暂时不需要推广，但若有必要，根据web平台这种表现形式，可以把入口作为一个外部链接安置在导航页面的热点栏或推荐栏，或者是手机APP的启动广告
二、关于疫情统计可视化
1.原型设计
- 疫情统计结果的可视化原型
https://sec1jg.axshare.com
（首页截图）
- 原型开发工具————Axure RP9
Axure RP是一个专业的快速原型设计工具，让负责定义需求和规格、设计功能和界面的专家能够快速创建应用软件或Web网站的线框图、流程图、原型和规格说明文档。作为专业的原型设计工具，它能快速、高效的创建原型，同时支持多人协作设计和版本控制管理 。
2.效能分析 & PSP
(由于目前项目开发只进行到原型设计，后续步骤暂时无法计算实际消耗)
| PSP2.1 | Personal Software Process Stages | 预估耗时（小时） | 实际耗时（小时） |
|---|---|---|---|
| Planning | 计划 | 1+ | 1 |
| Estimate | 估计这个任务需要多少时间 | 1+ | 1 |
| Development | 开发 | 150+ | |
| Analysis | 需求分析 (包括学习新技术) | 30+ | 40 |
| Design Spec | 生成设计文档 | 10+ | 10 |
| Design Review | 设计复审 | 2 | 1 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 2 | 1 |
| Design | 具体设计 | 30+ | 20 |
| Coding | 具体编码 | 150+ | |
| Code Review | 代码复审 | 20+ | |
| Test | 测试（自我测试，修改代码，提交修改） | 10+ | |
| Reporting | 报告 | 3+ | |
| Test Report | 测试报告 | 3+ | |
| Size Measurement | 计算工作量 | 1+ | |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 3+ | |
| 合计 | 416+ |
三、总结
1.结对过程
- 困难
A.由于未开学，组员之间无法面对面沟通讨论，交换意见，增加了相互间交换信息的难度
B.以前从未涉及过原型设计这方面的知识，无论是理论知识的运用还是设计工具的使用都很生疏
- 解决方法
A.利用各种社交软件进行交流
B.利用网络查找各类教程或建议自学
- 结对过程
2.设计过程
- 困难
A.由于从未接触过原型设计的工具，因此需要花费一定的时间学习
B.疫情地图高亮显示以及跳转至详细省份很难在原型设计上展现出来
C.功能的优化与实现的复杂性之间的冲突
- 解决方法
A.作业发布后的前两天通过观看视频安装原型设计工具Axure并掌握如何使用 Axure。
B.思考很久以后，我认为原型设计的主要目的是展现所开发项目的功能，页面与页面间转换的关系，而不是去实现具体的功能，因此，原型设计只要让开发人员看得懂即可。在请教了一些大佬之后，我也大概知道如何让图片显示高亮，有的人用抠图软件将中国地图的每个省份抠下来；有的使用echarts制作地图，还需要编写html文件。不得不说，最后的成果很nice，但是真的有必要为了一个原型设计花费如此多的时间吗？我认为没有必要。（像我这样动作迟缓的生物，抠个图就要一天）因此，我的原型设计无法显示高亮，但在对应的位置我都有做相应的备注，我认为这样的原型设计能够让开发人员以及客户看懂就足够了，也许制作有些粗糙，但却节约了很多时间。
C.在原型设计过程中，总是有很多创意和想法蹦到脑袋里，但是我却不知道如何去实现。权衡许久之后，我决定把所有的想法都设计出来，而对于功能的实现是后面具体开发时需要进一步去考虑的
- 设计过程
3.收获
这次的作业我收获颇丰。从前期的自主学习，掌握对原型设计工具的使用，再到头脑风暴设计疫情统计平台的功能，最后去把想法展示出来，在这一过程中，我不断思考，不断攻克自身弱点，不断探索未知的事物，最终做出自己较为满意的作品，我认为是有收获的。但在收获的同时，我认为我是需要反思的，不言而喻，这次作业应该算是很简单的（与具体编程相比），但是在原型设计的过程中我依旧还是出现了许多问题。这也暴露了我自身能力不足的缺陷。第一，自学能力差，对于网上信息的检索能力以及学习效率都是相当低下的；第二，动手实践能力差，在看完学习资料后不能灵活地学以致用，无法做到理论与实践相结合这是致命的；第三，缺乏创造力，对于项目功能的优化没有足够的创意。
在不断的学习以及deadline的压力下我暴露了许多的问题，但这些问题也是我的收获，有问题才会有成长。（虽然头脑呆滞，行动迟缓，但在deadline之下，也只能硬着头皮往前走了。）