[BUAA软工]Alpha阶段项目展示
[冰多多]Alpha项目展示
冰多多项目: 语音coding 助手, alpha阶段目标: 语音辅助输入
一. 团队成员的简介和个人博客地址
| 成员 | 角色 | 个人博客地址 |
|---|---|---|
| 卓培锦 | PM, 后端开发 | https://www.cnblogs.com/butub/ |
| 牛雅哲 | 后端 | http://www.cnblogs.com/swainz/ |
| 韩笑冰 | 前端+后端对接 | http://www.cnblogs.com/hanxiaobing/ |
| 李天宇 | 前端 编辑器 | http://www.cnblogs.com/SephyFine/ |
| 余凯 | 前端 | http://www.cnblogs.com/imageboom/ |
| 张圆宁 | 测试 部分文档 | https://www.cnblogs.com/melina/ |
二.我们要做软件工程，那就要有一点工程的样子
此处详细说明我们整个项目
2.1 团队项目的目标，预期的典型用户，预期的功能描述，预期的用户数量在哪里？
项目的终极目标是让语音能够代替我们的双手, 在适当的场景, 提供的语音编程的功能. 当然这很困难, 所以我们分阶段去完成.
- 在Alpha阶段需要完成的是一个demo, run通整条语音到所需动作,动作到指定输出(到shell)的pipeline.
- 在beta阶段将alpha阶段设计好的编辑器\ shell \ 语音接口 整合起来, 组成一个完整的IDE, 提供简单的IDE功能
- 在gamma阶段推出一个更加完整的IDE, 增加指令数, 优化UI, 考虑是否改成插件发布.
典型用户🅰️: 不同场景中, 只能使用手机临时Coding 的程序员
典型用户🅱️ : 由于手部残疾, 需要使用语音辅助coding 的人士
Alpha阶段预期用户数量: 100 , 活跃用户数量: 30
2.2 团队的产品如何满足了用户的需求？
产品通过在termux的基础上增加一个用于控制语音输入的按钮, 以及输入语音后对应的提示信息, 来帮助用户通过语音辅助输入. 注意, 这是一个demo级别的app, 仍然有着极大的改进空间.
上传视频于bilibili视频网站
https://www.bilibili.com/video/av50392247/
2.3 事先定义的软件下载量达到了么？为什么没有达到？
没有, 因为发布时间比较晚.
2.4 团队的成员如何分工协作的？有什么经验教训？
分工是协商分工, 并且按照项目进度动态分配任务的, 比如一些文档的工作, 开发忙碌时, 没空写文档, 可能会让测试或者前端写一些课程需要的文档.
成员的协作上, 发现面对面的协作开发,会让效率变得更快. 不过更多时候通过会议以及github代码交流, 以及微信等别的联络手段在协作中也占很大的比重.
比较深刻的教训是, 对于PM来说, 一定要经常地, check项目的进度, 和每一个组员进行跟踪, 以保证项目的进度.
2.５团队如何进行项目管理
我们通过github进行项目的管理．https://github.com/bingduoduo1
2.6 团队如何平衡 时间/质量/资源 争取如期完成任务的？
主要以来团队成员们的毅力，面对bug，不屈不挠，在本阶段开发中遇到了一些非常底层的bug，开发难度大．时间上，在完成功能的基础上，如果有紧急的情况，大家都会把时间投入进去一起解决问题．我们在alpha阶段主要完成一个demo级别的应用，因此也算是质量上基本不错的，资源上，我们组并没有什么非常稀缺的资源，更多是需要组员去为团队更多付出．
当然，因为我们从０开始打通一个项目，和继承上届项目的团队比起来，我们遇到的原生的,底层的bug非常多，我们团队已经尽最大努力去完成预定目标了．
2.7 在产品之外，团队代码的软件工程质量如何？如何用数据来证明？
工作分工质量尚可，参照github
团队组织水平上游，参照srcum博客．
2.8 测试用例数目，代码覆盖率数目。运行测试用例得到代码覆盖率的视频录像．
2.9 代码规范在哪里？
团队协商的结果是，统一使用小驼峰编码，成员变量以小写m开头
2.10 齐全的文档在哪里？
- 博客园团队博客：http://www.cnblogs.com/bingduoduo/
- github：public_doc仓库: https://github.com/bingduoduo1/public_doc
2.11 如果一个新学生在一台新机器上想编译并运行你的项目， 请问能顺利完成么？有什么样的文档能指导新学生？
我们的项目统一在AndroidStudio上构建，Gradle版本４.10.1, Gradle-plugin版本3.3.0，ndk版本19.2.5345600，最低android api为21, 只要这几个版本配置正确，基本上不会有问题，我们团队开发中的issue可以提供一定的参考，但要继承这个项目需要对于代码有比较深的理解，因此读懂已有的代码的基础上，有一些android开发经验的同学要run起来这个项目并不难，因为底层的bug已经被我们团队排查过一遍了．
2.12 所有的项目都会收集到用户的数据，请问你们对这类数据做了什么样的分析，这些分析如何验证或推翻了原来的假设？这些数据如何帮助项目改进软件工程的质量？
我们随app发送了一份问卷， https://www.wjx.cn/jq/38338600.aspx ，主要调查app的功能正确性，同时也搜集关于ＵＩ，以及传统建议类型的信息．
一共得到了18份用户反馈问卷，下面就问题一一分析
下载与安装
因为我们提供的是百度网盘下载，所以除了下载速度有点慢，所有人的下载都还是安装成功了。本来我们对于安装这一步心怀忐忑，因为软件初次下载会下载一些必须的包，而软件源是国外的地址。所以我们在安装信息进度中提示安装速度有点慢，最好在校园网环境之下。但是所有的用户都安装成功了
界面反馈
有一半的人在界面是否美观这一问题上选择了否😱，这也是我们下一步要完成的主要任务。前端编辑器已经基本完成了，beta阶段的主要任务就是把编辑器和shell连接起来。
功能体验与运行
我们随应用包的下载附了一份pdf版本的说明书，而且身边的朋友主要处在工科院系，大部分人都有操作shell的经历，所以大部分人都描述自己的体验为顺利的，在shell上的命令运行基本没有问题。
bug反馈和解决方法
得到的反馈中，真正意义上的bug大概有两个，一个是我们为了同步语音识别与输入，在松开按钮0.8秒之后才会识别并显示输入（在前期的scrum会议中有记录），有的用户对这个有点敏感，我们后期大概会尝试别的同步方式。第二个是长按按钮会和小米手机上的一个叫做传送门的内置应用（启动方式为长按）冲突，我们在开发的过程中关闭了那个功能，所以没有发现，后期会寻找屏蔽该应用的方法。
在后期填写问卷人中，反馈语音识别失灵的人越来越多，我们初步认定是因为使用的人比较多，发出去的次数太多，用光了讯飞sdk每天的500次免费额度。我们已经申请了学生的教育优惠，每天的免费识别次数会提高到20000条，不过还在人工审核中。
手机运行型号
小米6，小米8，小米8se，一加A3010，一加A600，三星A6，S8，S10，华为p30, nova 3
得到的后期建议
三．致命bug
有两个bug我们de了非常久，得到了惨痛的教训．
3.1 语音同步问题link
描述：科大讯飞的语音接口比较复杂，需要实例化一个RecognizerListener对象，并且重写里面的方法．
void onVolumeChanged(int var1, byte[] var2);
void onBeginOfSpeech();
void onEndOfSpeech();
void onResult(RecognizerResult var1, boolean var2);// <<<<<<<<<<<<<< onResult()
void onError(SpeechError var1);
void onEvent(int var1, int var2, int var3, Bundle var4);
但是我们并不知道科大讯飞混淆过的SDK是在什么时候调用onResult方法的，那么监听语音回调的结果就成为了一个问题，我们初始时很难de出这个bug, 因为不确定是识别错误还是各种别的原因导致没有返回结果，最终一级一级定位到是停止录音之后，需要大约0.8s返回结果，然后我们让两个过程对齐，才让功能正常，这在之后可以优化．
教训：像语音这种功能，要么第三方真的很靠谱，不然更应该把这种核心功能掌握在自己手上．开发过程中甚至有发现曾经讯飞的语法识别的在线识别功能下线的问题，导致项目需要更换接口．
3.2 改变applicationID link
这个bug我们组内称为史诗级bug
-
应用商店上架需要改变applicationID, termux已经使用com.termux上线，通常applicationＩＤ是和 app解耦合的，改变applicationID不会影响app的正常运行．所以我们改成了com.bingduoduo
-
但是发现termux-app中termux-service中的FILE_PATH字段硬编码成 "/data/data/com.termux/files"; 也就是应用的私有缓存目录，这个目录android中对于用户和开发者都是不可见的．termux做的一件事是把启动所需的包缓存到这个目录，然后使用系统函数链接到linux环境中去，就能够模拟出一个shell环境，于是我们把这个路径也改成＂/data/data/com.bingduoudo/files＂
-
但是发现bug, 编译正常，初始化时对话框一直installing...，表示正在安装bootstrap的包，logcat显示出下载成功，但是链接的时候出错．这时这个bug已经de了有两天，原因在于termux自己维护的源的包，在编译的时候有硬编码的字段$PREFIX,对应包名＂com.termux＂, 于是我们需要自己重新编译这些包，自己维护一个源，参考issuetermux/termux-app#1059 ,
-
按照issue中的方法，安装docker, 编译需要的包，生成Packages, 上传到服务器，用脚本生成boostraps-arm.zip,再传到github上，修改termux-app中的termuxInstaller中的url字段为github上对应的网址．下载运行
-
发现包可以下载，链接也正常，启动的shell和termux本身的也一样，但是运行时，手机显示CANNOT LINK EXECUTABLE, 发现在docker中重新编译所有需要的包的时候，有一个字段TERMUX_PKG_API_LEVEL设置成了最高的28, 所以在android api 28的手机上能够运行，而在androidapi22上的测试机就不能用.
所以我们需要编译TERMUX_PKG_API_LEVEL 21的包，这里还有一些包的依赖关系，我们最终编了个24的，在小米７上可以run,这个bug的出现导致我们正式版本的app发布延期，目前发布的是内部测试版．
教训：不到最后成功发布的一刻，永远也不知道还有什么巨大的bug在等着我们大家，就算发布成功后，用户环境下也可能出现各种各样的bug，我们应当随时准备好debug.另外就是，能解耦和的东西，工程上尽量解耦和，这会给后续开发和改动更大的便利．不过这种硬编码也不失为保护app的一种方式，毕竟如果使用远程仓库的app过多，也会导致拥塞等一系列问题．然后是termux的文档以及issue的维护非常到位，让我们可以参考，termux是一个真正的开源项目，２k+star名副其实．
四．团队项目的实际进展
4.1 燃尽图如下：
4.2 发布功能：发布说明
4.3 发布软件：shell内测版
链接：https://pan.baidu.com/s/1dFOURm8P3-vRcTIprwkQ-w
提取码：29l3
复制这段内容后打开百度网盘手机App，操作更方便哦
我们的项目管理中燃尽图还算客观地描绘了项目的进展，但对于一些很难de的bug，没有足够好的体现．一定程度上美化了状态．
五. 团队成员在Alpha阶段的角色和具体贡献：
| 名字 | 角色 | 具体的可衡量的可验证的贡献 |
|---|---|---|
| zpj | ＰＭ,后端开发 | 博客Ｘ3 |
| 65 commits | ||
| 主要的termux中文注释 | ||
| bug fixed: 2 | ||
| 推广：10 | ||
| 总分: 58 |
| 名字 | 角色 | 具体的可衡量的可验证的贡献 |
|---|---|---|
| nyz | 后端开发 | 博客X2 |
| 1３ commits，代码量大 | ||
| bug fixed: 2 | ||
| 文档:1 | ||
| 调研语音接口 | ||
| 总分: 56 | 推广:5 |
| 名字 | 角色 | 具体的可衡量的可验证的贡献 |
|---|---|---|
| hxb | 前端+后端对接 | 博客X13 |
| 21 commits | ||
| bug fixed: 1 关键思路提供 | ||
| 文档：３ | ||
| 推广：8 | ||
| 总分:56 |
| 名字 | 角色 | 具体的可衡量的可验证的贡献 |
|---|---|---|
| lty | 前端 ，编辑器 | 文档Ｘ3 |
| commit: ３ | ||
| 调研测试模块\编辑器模块 | ||
| 发现bug:1 | ||
| 推广:2 | ||
| 总分：45 |
| 名字 | 角色 | 具体的可衡量的可验证的贡献 |
|---|---|---|
| yk | 前端 | 文档：３ |
| commit: 3 | ||
| 推广：５ | ||
| 调研前端demo: 1 | ||
| 总分:45 |
| 名字 | 角色 | 具体的可衡量的可验证的贡献 |
|---|---|---|
| zyn | 测试，部分文档 | 文档Ｘ４ |
| ５ commit | ||
| 测试功能模块 | ||
| 调研语音接口 | ||
| 发现bug:1 | ||
| 总分:40 | 推广：３ |
