结对第一次—疫情统计可视化（原型设计）
| 这个作业属于哪个课程 | <2020春S班> |
|---|---|
| 这个作业要求在哪里 | <作业要求> |
| 结对学号 | 221701109、221701110 |
| 这个作业的目标 | <学习制作原型模型、NABCD模型、结对完成> |
| 作业正文 | https://www.cnblogs.com/blogofbao/p/12378557.html |
| 其他参考文献 | CSDN、构建之法 |
原型成果展示
- 本次原型使用墨刀制作
设计过程和困难
设计过程
- 设计初衷:一款基于手机浏览下的实时疫情地图，方便广大用户随时随地可以查看和了解疫情的最新动态。
- 设计思路:主页是当前疫情地图和具体确诊、疑似、治愈、死亡的人数，每个省根据疫情的严重程度分为不同颜色。
- 鼠标移入(单击)会有高亮显示，并显示确诊该省人数。
- 继续单击或鼠标移出将返回主页。双击将进入该省详细页面。
- 页面中可以查看详细的新增确诊趋势、新增疑似趋势、新增治愈/死亡趋势。通过底部按钮可以切换不同的趋势图，或者选择返回主页。
困难及解决
困难描述
1.地图深浅如何标识、高亮如何处理
2.点击后的页面如何实现
解决尝试
1.地图我们选择在网上查找图片，并用相应的图片编辑工具，修改颜色的深浅。高亮也是将对应的省份颜色做高亮处理，然后将页面添加不同状态，相应事件将跳转对应状态。
2.点击后的页面，首先是在墨刀里添加链接区域，设置好事件，指向设置好对应的页面或状态即可。
解决结果
1.地图颜色处理有些繁琐，但是可以解决基本问题。
2.满足了所有需求。
有何收获
在这一次的作业中，我学会了如何去解决一个开发问题，我们在做开发的时候首先就要连接客户需求，我们所做的都是建立在客户的需求之上的，
不能随便按个人心愿，任何的项目都是如此。同时解决问题难免会遇到困难，但我们应该要学会克服困难，利用自身的聪明才智解决它。
因为这一次的作业时结对完成，所以也收获了其他的东西。面对问题两个人要积极交流，寻求解决办法。
团队的两个人，要互相信任，相互依赖，明白团结，人有一个缺陷就是对自己
知道的往往熟视无睹，老是追求前卫的，但结果往往是适得其反。我们现在处的环境是大家都有一个组，倘若有人完不成作业，
那么同组的人就难辞其咎。所以也不要在意个人得失，团队的利益至上，互相帮助，互相督促进步才是我们应该做的。
整个组必须协调。切不可个人自扫门前雪，休管他人瓦上霜。
NABCD使用说明
N（需求）
有一家统计网站每天都会提供一个对应的日志文本，记录国内各省前一天的感染情况，上次的疫情统计结果只是通过文字来显示，不够
直观、具体，对用户不够友好，本次我们希望可以通过地图的形式来直观显示疫情的大致分布情况，还可以查看具体省份的疫情统计情况
A（做法）
我们学习了相应的数据分析，也懂得了不少数据处理操作。所以我们决定做的是一个美观简洁的手机应用，调用数据库内容，用相关图
行界面工具来实现这个应用的开发，向用户动态展示当前疫情状况。这样资源获取简单，也便于维护。
B（好处）
安装在手机上的桌面应用，界面简单，占用空间较小，便于获取，比较轻松地就能获取当前疫情状况，同时想获取哪个省的信息也只要点一下某一省即可。
C（竞争）
就目前来说要想获取疫情状况，大致地电子设备无非就是电脑，iPad，手机等。相对而言，手机是容易携带，基本人手一个，所以我们主
打的手机应用也就符合大众的普遍需求。而且，像比如浏览器而言，手机应用只要稍点一下就能获取信息，操作简单。当然，现在也会有
一些播放新闻的软件能停止用户疫情信息，但所推送的都是某一小部分的信息，信息不全。而就针对与很多手机应用而言，我们的这个也是
有自身优势的，界面简单，操作方便，而且占用空间也极小。
D（推广）
- 在博客园中我们会撰写博客推广我们的产品
- 在校园中推广产品
- 像各大应用平台推荐我们的产品，审核通过便会在各大平台上展示，用户便可获取。
- 在知名网站中我们也会适当的推广我们的产品，让更多的人了解我们的应用。
- 利用微信，微博，抖音等当下较热门的app宣传
讨论过程
- 1.初步定下使用墨刀
- 2.探索链接区域
- 3.进一步美化
- 4.高亮处理
- 5.细节优化
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 45 | 60 |
| Estimate | 估计这个任务需要多少时间 | 45 | 60 |
| Development | 开发 | 550 | 580 |
| Analysis | 需求分析 (包括学习新技术) | 30 | 40 |
| Design Spec | 生成设计文档 | 15 | 10 |
| Design Review | 设计复审 | 15 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 5 |
| Design | 具体设计 | 30 | 24 |
| Coding | 具体编码 | 400 | 376 |
| Code Review | 代码复审 | 30 | 70 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 45 |
| Reporting | 报告 | 105 | 130 |
| Test Repor | 测试报告 | 30 | 40 |
| Size Measurement | 计算工作量 | 30 | 30 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 45 | 60 |
| 合计 | 700 | 770 |
