福大软工 · 第十二次作业 - Beta答辩总结
404 Note Found
所有成员
| 学号 | 姓名 |
|---|---|
| 031602114 | 胡绪佩（组长） |
| 031602543 | 周政演 |
| 031602444 | 庄卉 |
| 081600410 | 胡青元 |
| 031602627 | 刘恺琳 |
| 031602525 | 刘一好 |
| 031602511 | 何家伟 |
| 031602513 | 黄鸿杰 |
| 031602510 | 葛家灿 |
| 031602539 | 翟丹丹 |
| 031602113 | 何宇恒 |
项目宣传视频链接
项目宣传视频链接：https://www.bilibili.com/video/av38829275
贡献比例
工作流程
- 本次作业由于在alpha版本阶段我们已经将大部分功能基本实现，所以Beta版本我们只是对于各个队员
负责的部分进行独立模块的优化和改进。 - 并且对团队协作进行了一定程度的规范化，采用github平台的方式进行团队协作。
- 在Beta冲刺阶段不断对bug进行修复并且在deadline之前好几天完成apk打包
- 并做了产品的专业机型测试,以及内测产品的推广及用户调查，针对调查结果对我们的产品进行bug修复和用户友好性改进，在几天时间内从1.0.0
版本更新至1.1.1版本。
组员分工
绪佩： 对备忘录的状态之间改变跳转进行修复改进、对删除备忘录的功能bug修复、现场展示PPT答辩、项目的推进、任务的分工
卉卉： 云服务器云端数据的部署，接口的测试和改进，产品的界面优化建议师，产品界面图标图片制作
家灿： 云服务器云备份，云同步部署，接口测试和改进
青元： 登录注册界面的完善，和云端数据库的对接，协作完成云同步和云备份，引导页的制作
鸿杰： 完成智能提醒天气分析和用户行为分析的功能合并，协作完成备忘录即将到期的通知显示，答辩环节提问回答算分汇总处理。
家伟： 改进和优化短信提醒的时间，内容，对后台运行程序的尝试
一好： 完成语音输入的浮标尝试，PPT制作
宇恒： 完成备忘录详情处添加图片路径处理，添加可以拍照的功能
政演： 针对两个智能进行深度优化,设计实现了基于 LD-Sketch 的云端数据处理框架,并制作ppt上台答辩，博客分工以及撰写
丹丹： 新颖视频的制作
恺琳： 优化生成壁纸的功能，美化壁纸展示的界面，修复生成壁纸的小bug
团队贡献比例：
| 姓名 | 贡献度 |
|---|---|
| 绪佩 | 11% |
| 卉卉 | 9.5% |
| 家灿 | 11% |
| 青元 | 13% |
| 鸿杰 | 11% |
| 家伟 | 6.5% |
| 一好 | 6% |
| 宇恒 | 6% |
| 政演 | 11% |
| 丹丹 | 9% |
| 恺琳 | 6% |
GitHub 项目链接
https://github.com/heihuifei/Canmory-of-404-Note-Found
本组 Beta 冲刺站立会议博客链接汇总
燃尽图
燃尽图：
原计划、达成情况及原因分析
组员：胡绪佩
原计划将什么功能做到什么程度
- 原计划将功能做到可以正常的添加和删除备忘录并且可以
友好的堆备忘录的完成状态进行跳转
实际做得怎样了
- 实际达到原计划的完成度，产品可以正常的进行备忘录
的添加和删除，并且可以友好的对备忘录的完成状态实现
勾中跳转。
如果没有达成，反思是哪些因素影响的
- 已经达成，后续还会对于其中一些操作性的细节做出优
化，提高用户友好性。
组员：周政演
原计划将什么功能做到什么程度
- 原计划的智能分析，仅仅是获取用户的数据。
实际做得怎样了
- 最后的智能分析是一个基于 LD-Sketch 的云端数据处理框架，用于在云服务器后台上处理从用户传来的数据。将用户的数据项看做流的形式，传到云服务器的sketch上，而不是将数据项存储在数据库中。后端人员只需要设计好用户端的数据采集，存于字符串中，通过thrift将数据从用户端传输到云端，并控制多用户向云端的并发数据传递。在后端将字符串解析成所需的数据，设置到LD-sketch的阈值大小，通过管道存入LD-sketch中,LD-sketch将自动报出超过阈值的数据项。
如果没有达成，反思是哪些因素影响的
- 已达成
组员：庄卉
原计划将什么功能做到什么程度
- 实现本地和云端数据的传送
实际做得怎样了
- 完成
如果没有达成，反思是哪些因素影响的
- 无
组员：何家伟
原计划将什么功能做到什么程度
- 原计划实现短信的分析功能，在收到快递或出行短信时自动提取关键字使前端能显示相应备忘录
实际做得怎样了
- 达到预计要求，但短信模板还能够进一步优化
如果没有达成，反思是哪些因素影响的
- 已达成
组员：黄鸿杰
原计划将什么功能做到什么程度
- 原计划实现桌面控件、天气提醒功能、锁屏壁纸设置、智能提醒功能
实际做得怎样了
- 达到预计要求，但是在打包apk过程中智能提醒功能出现了些许bug，在后续将完善这些bug
如果没有达成，反思是哪些因素影响的
- 已达成
组员：葛家灿
原计划将什么功能做到什么程度
- 用户登入注册：用户可以使用手机号（11位）和密码（6-16位）注册自己的账户，登入软件，用户数据保存在服务器中。
- 云备份和云同步：用户登入成功之后，打开侧边栏，点击云备份，可以将用户本地的个人数据，备份至服务器中，；点击云同步，可以将用户先前备份在云端的数据，还原至本地。避免由于手机丢失或者操作不当带来的不便。
实际做得怎样了
- 实际上满足先前构想
如果没有达成，反思是哪些因素影响的
- 已达成
组员：胡青元
原计划将什么功能做到什么程度
- 功能实用，界面美观。
实际做得怎样了
- 功能使用，但界面不够美观，以及功能还存在bug。
如果没有达成，反思是哪些因素影响的
- 已完成。
组员：刘恺琳
原计划将什么功能做到什么程度
-将备忘录显示在页面上，并可以选择自己想要的壁纸。
实际做得怎样了
- 可以做到从图片库中选取壁纸并显示，显示前五条壁纸
如果没有达成，反思是哪些因素影响的
- 任务完成
组员：翟丹丹
原计划将什么功能做到什么程度
- 满足组员要求，进行情景式视频剪辑
实际做得怎样了
- 已完成
如果没有达成，反思是哪些因素影响的
- 任务已完成
组员：刘一好
原计划将什么功能做到什么程度
- 原计划实现语音转文字功能和语音转文字悬浮窗
实际做得怎样了
- 语音转文字功能实现成功，悬浮窗口实现成功但是无法进行语音转文字
如果没有达成，反思是哪些因素影响的
- Android 的Service 功能中不能调用有关UI部分的内容。所以即使我实现了悬浮窗，但是不能进行语音输入的它对于我们整个团队来说就略显鸡肋了。
组员：何宇恒
原计划将什么功能做到什么程度
-原计划将备忘录编辑界面增加拍照和上传视频功能
实际做得怎样了
-实际上只做了拍照功能，并没有实现上传视频功能
如果没有达成，反思是哪些因素影响的
- android的edittext不支持多媒体插入，我在事先没有做好调查
Beta 版本展示
直接发布可用 Beta 版本，并提供使用说明。
记忆罐头APK网盘地址：https://pan.baidu.com/s/1AsbRgRbkdrx6Qz_dnpv_Sw
功能：登陆注册
使用说明
- 输入11位手机号作为账号，输入4到10个字母或者数字作为密码
- 输入注册过的手机号和密码即可登陆
功能：语音输入
使用说明
- 点击语音输入
- 说出要形成备忘的内容
- 语音输入生成备忘
功能：新建或修改备忘录
使用说明
- 根据提示输入标题，更改到期时间，调整优先级，添加详细内容，以及在更多设置中按照提示选择即可。
功能：智能分析
使用说明
-
我们的智能分析是一个基于 LD-Sketch 的云端数据处理框架，用于在云服务器后台上处理从用户传来的数据。将用户的数据项看做流的形式，传到云服务器的sketch上，而不是将数据项存储在数据库中。后端人员只需要设计好用户端的数据采集，存于字符串中，通过thrift将数据从用户端传输到云端，并控制多用户向云端的并发数据传递。并在后端将字符串解析成所需的数据，设置到LD-sketch的阈值大小，通过管道存入LD-sketch中,LD-sketch将自动报出超过阈值的数据项。
-
智能分析主要用于后台的数据处理，不向用户开放。
智能分析的部分特点
线速处理数据
能够高速处理从边缘到云端的数据，LD-sketch原是用于数据中心的高速流量测量，本产品用户端到云端的数据量远远小于数据中心，可以轻松完成线速数据处理。
占用极少空间
尽量减少空间的开销，不使智能分析成为负担。sketch的基本思想是将数据压缩到较小的空间内，在可接受的误差估计下完成数据采集，利用LD-sketch可以大大减少数据存储占用的空间。
通用处理框架
使边缘到云端的数据处理框架具备良好的通用性。我们设计的框架无需针对每一种数据都设计专门的处理方法。每一条数据都以字符串的形式传输，只要在后端设计好字符串的格式处理即可。
简化对接操作
省去数据库处理过程，简化处理流程。我们的数据处理框架中，绕过了数据库，避免数据在数据库中大量的 IO 操作，降低计算开销，同时不需要数据库管理员对数据处理，简化了对接操作。
功能：智能提醒
使用说明
- 打开智能提醒功能开关，根据引导设置权限，回到主界面再次打开智能提醒开关
功能：天气提醒
使用说明
- 打开天气预报功能开关
功能： 云备份 云同步
使用说明
- 未联网情况下只要不退出登录可正常使用该账号的本地备忘功能。
- 云备份：在联网情况下，点击云备份，可以将用户本地的个人数据，备份至服务器中，避免由于手机丢失或者操作失误带来的不便。
- 云同步：在联网情况下，点击云同步，可以将用户先前备份在云端的数据，还原至本地。
功能：桌面控件
使用说明
- 添加桌面控件
功能：壁纸预览
使用说明：选择图片库的一张图片，用户可以自由选择字体颜色和字体大小，点击预览可以预览锁屏效果，点击生成壁纸
便可以生成锁屏壁纸进行展示
得分
收集其他组对本组提出的问题，并回答
第一组回答：（爸爸饿了队）
1. 在早上的答辩中没有听懂基于LD-Sketch的用户行为统计算法可否详细解释一下？
答：感谢提问！我们的智能分析是一个基于 LD-Sketch 的云端数据处理框架，用于在云服务器后台上处理从用户传来的数据。将用户的数据项看做流的形式，传到云服务器的sketch上，而不是将数据项存储在数据库中。后端人员只需要设计好用户端的数据采集，存于字符串中，通过thrift将数据从用户端传输到云端，并控制多用户向云端的并发数据传递。并在后端将字符串解析成所需的数据，设置到LD-sketch的阈值大小，通过管道存入LD-sketch中,LD-sketch将自动报出超过阈值的数据项。
如有兴趣，欢迎讨论 ：）
附：
对于sketch的有关算法，可以查看这篇介绍：https://www.sdnlab.com/22685.html
关于LD-sketch的算法细节，可以查看这篇论文：https://ieeexplore.ieee.org/document/6848076/
2. 是否考虑精简界面的元素数量，给用户更简洁的观感？
答：感谢提问！我们在备忘展示的主界面的未完成、到期未完成、已完成三个列表均可点击使其隐藏。我们认为已经尽可能的精简了界面的元素数量，使其在满足用户需求的情况下尽量简洁。如果有什么好的建议欢迎与我们交流。
3. 应用的功能较多是否考虑做一个用户引导方便新用户了解功能？
答：感谢提问！我们的app在用户第一次安装时会提供一个引导页来介绍特色功能。
第二组回答：（拖鞋旅游队）
1. 对于本项目，在后续的bug修改以及推广方面有哪些想法
答：感谢提问!我们项目组负责开发部分的成员会继续修改bug，bug修改完善后，会投入市场运营，线上线下会同时宣传，争取吸引更多用户的使用。
2. 在以前的课上有提过你们不用语音输入的,现在怎么也支持语音输入了
答：感谢提问!因为我们有多余的时间和足够的能力，多多益善嘛，后续就添加了这个功能。
3. 有没有考虑本项目的某些地方其实产生了重叠从而对项目进行部分的增加或删除
答：感谢提问!目前还没有发现功能严重重叠的现象，但后续在推广过程中会根据用户反馈现象，对功能进行增删改。
第三组回答：（彳艮彳亍队）
1. 你们有没有做过关于界面美观或是逻辑设计的调查或测试？
答：感谢提问！在问卷中我们有这样的选项。
2. 语音输入的结果精度高吗？语音输入功能是调用什么实现的吗？
答：感谢提问！语音输入是调用百度的接口，精度在我们的能力范围确保语音输入的准确度。
3. 如果每一项提示需要填写这么多项的话,会不会太麻烦？让用户体验降低,是否考虑简化(目前个人用来觉得挺好,需要提醒事项多的时候没有测试过,所以不太清楚)
答：感谢提问！我们的备忘录并不是对每个选项都要设置，最简便的方法是语音输入，直接转成备忘录的标题。
第四组回答：（火箭少男100队）
1. 为什么没有展示智能分析？仅从口头描述来说，是否仅是上传各app的使用时长给服务器而已呢？
答：感谢提问！
- 第一，智能分析是一个运行在后台的功能，不对用户开放。
- 第二，app未推广，缺少实际的用户数据。
- 第三，智能分析的演示过程时间较长，十五分钟的展示时间无法完成。
- 第四，希望提问小组可以更认真一点聆听演示报告，有疑问，至少提问前看一下ppt上的内容。若是仅上传app使用时长给服务器，又何足道哉？我们的智能分析是一个基于 LD-Sketch 的云端数据处理框架，用于在云服务器后台上处理从用户传来的数据。将用户的数据项看做流的形式，传到云服务器的sketch上，而不是将数据项存储在数据库中。后端人员只需要设计好用户端的数据采集，存于字符串中，通过thrift将数据从用户端传输到云端，并控制多用户向云端的并发数据传递。在后端将字符串解析成所需的数据，设置到LD-sketch的阈值大小，通过管道存入LD-sketch中,LD-sketch将自动报出超过阈值的数据项。
- 第五，我们已在群里上传程序源码，框架的可行性也早已验证过，欢迎测试。
- 第六，以下是测试效果。我们从服务器端收到input，每条字符是一个数据项，设置阈值为100，在修改接口之后，同时将数据流用管道传入LD-Sketch，下图是后台中sketch的数据存储使用情况(为了方便显示，将行设为20，实际中并非如此)，并且可以看到，LD-sketch迅速并正确地报出超过阈值的key。
2. 在之前的展示中，你们反复提到软工课没必要做太高大上的技术，为什么这次展示又加了两个“智能”模块呢？
答：感谢提问！这个问题分两点回答。
- 我们从始至终都是有四个核心其中包括两个智能，希望提问小组可以更认真一点听每一次的演示，至少在提问之前也应该看一看被提问组提交的材料，这是对被提问方最基本的尊重。
- 我们所说的没有必要做过于高大上的功能是在没完成基础软件工程的前提下，当然如果完成了加上是完全OK的，相比于那个我们是针对于alpha版本某些组甚至没有完成他们的软件就一直呐喊着那些听起来高大上的算法却只有PPT产品提出来的观点，在beta版本已经完成基础软件添加高大上的功能有何不可呢？
3. 你们认为最核心的功能是什么呢？为什么？
答：感谢提问！我们认为最核心的功能是锁屏壁纸展示；壁纸展示能够最直观的让用户看到自己定下的备忘录，改变传统的备忘录形式，做到真正的“备忘”。
第五组回答：（精雕细课梦之队）
1. 语音输入的功能很好,请问语音识别的准确率如何?
答：感谢提问！其实之前就有回答过类似的问题，我们使用的是百度语音接口，准确率和使用者的口音和使用环境也有关系，正常使用的时候准确率是很可靠的。
2. 请问有没有打算beta版本之后从哪些方面来进一步完善？
答：感谢提问！优化各个页面的逻辑，使得页面更加人性化。还有就是对用户的APP使用情况进行分析，以提供更好的服务。
3. 请问你们会用什么来吸引用户、留住用户？
答：感谢提问！我们会提供个性化的设置，优美的界面，各种方便实用的功能其实就已经很吸引人了。
第七组回答：（第三视角队）
1. 仍存在一些bug未解决，演示时，智能读取短信加入待办事项的功能似乎出了问题，找到原因了吗？
答：感谢提问！找到原因了，智能读取短信时数据库读写出了问题。我们已经进行了解决。
2. 待办事项，进行中事项与已完成事项的ui交互逻辑不够友好，事项的相互转移操作不是很明晰，可以再进行优化吗？
答：感谢提问！我们会在后续更新中进行优秀，感谢您的建议。
3. 智能分析功能可以做一些展示吗？
答：感谢提问！我们会再对这方面进行优化，按照计划会在最终演示的时候进行展示。
第八组回答：（小白吃队）
1. 你们组的人数相对其他组比较多，能否简述一下你们的分工和工作时间？
答：感谢提问！分工已经在ppt很明确的指出了，希望该组组员再看一下；工作时间为每周2、5、6晚上9点至11点，值得一提的是，在本周三前，本组已经大致完成了所有核心功能，并发布了app1.0.0版本，并做了许多改进，如今已经到了1.0.9版本！
2. 为什么会出现现场演示中的错误，之后有无寻找原因并进行修改？
答:感谢提问！会在现场演示中出现错误，一方面是因为前期确实是没有准备好，另一方面是因为没有真正彩排过，没有到实地演练一遍！
3. 你们项目的功能已经十分完善了,能否简述一下后续的制作计划呢？
答：感谢提问！我们项目功能虽然比较完善了，但是还有一些细节处理的不够友好，还有待改进，另外会针对于我们的智能性方面做出更进一步的优化。再者我们将会对我们的产品做一个市场推广并根据用户反馈迭代产品，推广迭代过程还很漫长。后续计划将由pm制定！
个人PSP
| PSP2.1 | header 2 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 50 | 30 |
| · Estimate | ·估计这个任务需要多少时间 | 20 | 30 |
| Development | 开发 | 150 | 120 |
| · Analysis | 需求分析（包括学习新技术） | 60 | 60 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 80 | 50 |
| · Coding | · 具体编码 | 10 | 20 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | ·测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 10 | 10 |
| · Test Repor | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 0 | 0 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 20 |
|合计||660|790
个人学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 5 | 5 | 阅读《构建之法》，重点了解了 NABCD 模型 |
| 2 | 0 | 0 | 10 | 15 | 找到了适合团队的原型工具，以及如何并行操作 |
| 3 | 68 | 68 | 6 | 6 | python字符处理复习、爬虫学习 |
| 4 | 78 | 146 | 7 | 13 | java爬虫学习 |
| 5 | 194 | 340 | 6 | 19 | 单元测试设计 |
| 6 | 0 | 340 | 10 | 29 | 需求报告撰写 |
| 7 | 0 | 340 | 5 | 34 | Alpha博客撰写 |
| 7 | 0 | 340 | 3 | 37 | Alpha2博客审查 |
| 7 | 0 | 340 | 3 | 40 | Alpha3博客审查 |
| 7 | 0 | 340 | 2 | 42 | Alpha4博客撰写 |
| 7 | 50 | 390 | 10 | 52 | 构思了随机算法、附加功能算法和具体思路，完成撰写叙述 |
| 7 | 0 | 340 | 2 | 54 | Alpha5博客撰写 |
| 8 | 0 | 340 | 2 | 56 | Alpha6博客撰写 |
| 8 | 0 | 340 | 2 | 58 | Alpha7博客撰写 |
| 8 | 0 | 340 | 2 | 60 | Alpha8博客撰写 |
| 8 | 0 | 340 | 2 | 62 | Alpha9博客撰写 |
| 8 | 0 | 340 | 2 | 64 | Alpha10博客撰写 |
| 9 | 0 | 700 | 4 | 68 | 测试文档撰写 |
| 9 | 0 | 700 | 2 | 70 | Beta1博客撰写 |
| 10 | 300 | 1000 | 2 | 72 | Beta2博客撰写 |
| 10 | 200 | 1200 | 2 | 74 | Beta3博客撰写 |
| 10 | 300 | 1500 | 2 | 76 | Beta4博客撰写 |
| 11 | 300 | 1500 | 2 | 78 | Beta5博客撰写 |
| 12 | 0 | 1500 | 2 | 80 | Beta6博客撰写 |
| 13 | 200 | 1700 | 5 | 85 | 设计实现new idea |
| 14 | 0 | 1700 | 2 | 87 | Beta7博客撰写 |
| 14 | 0 | 1700 | 2 | 89 | Beta总结博客撰写 |
| 14 | 400 | 2100 | 6 | 95 | 完成智能分析 |
