Beta冲刺答辩

这个作业属于哪个课程	班级的链接
这个作业要求在哪里	作业要求的链接
团队名称	OneDay
这个作业的目标	Beta冲刺
作业正文	Beta冲刺答辩
其他参考文献

一、设想和目标

项目简介

背景意义
项目功能是一款主打轻松记录日常的 app，希望通过与虚拟宠物互动，同时通过标签与数字这种更“具象”的符号保留身边的日常。
解决问题
生活中一些闪光的事物，或是太小太细用纸笔记录繁琐。或是属于自己的小确幸而难以通过空间微博与人分享。

beta 冲刺目标与完成情况

需完善的功能	具体完成程度	新增的功能	具体的完成程度
日记详细内容编写的页面布局将进行优化，设计更为人性化和丰富的编辑页面	基本完成	增加宠物亲密度算法	基本完成
软件的美工整体还比较粗糙，将对各种icon大小位置进行更加细致的美化	基本完成	日期查询，标签查询，按时间排列日记功能	基本完成
后端与前端的数据验证方面，将优化成更加稳定安全的设计	基本完成	日记按时间顺序排序,增加展示所有日记的界面	基本完成
用户信息类的接口逻辑需要优化	基本完成

完成情况评价

日期	计划	具体进度
2020.5.28	讨论功能的具体实现过程以及分工负责上一阶段宠物建模的同学继续进行优化	基本完成
2020.5.29	进行宠物算法的优化测试人员学习使用新的测试工具负责上一阶段宠物建模的同学继续进行优化美工人员优化icon	基本完成
2020.5.30	优化日记编写页的原型设计增加周统计页面的原型设计负责上一阶段宠物建模的同学继续进行优化测试人员对之前的代码进行新一轮的测试	基本完成
2020.5.31	开发新的日记编写页增加自定义标签的功能的原型设计负责上一阶段宠物建模的同学继续进行优化测试人员对之前的代码进行新一轮的测试	基本完成
2020.6.1	开发周统计页面导入3D模型测试人员对之前的代码进行新一轮的测试	基本完成
2020.6.2	开发自定义标签功能测试人员对之前的代码进行新一轮的测试	基本完成
2020.6.3	整体优化，修复bug，准备答辩	基本完成

二、设计和实现

测试工具

团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

单元测试:Junit
JUnit是一个Java语言的单元测试框架。它由Kent Beck和Erich Gamma建立，逐渐成为源于Kent Beck的sUnit的xUnit家族中为最成功的一个。 JUnit有它自己的JUnit扩展生态圈。
多数Java的开发环境都已经集成了JUnit作为单元测试的工具。
有效！
后端接口测试:Apipost
ApiPost是一个支持团队协作，并可直接生成文档的API调试、管理工具。
支持模拟POST、GET、PUT等常见请求，是后台接口开发者或前端、接口测试人员不可多得的工具。
有效！
UML发生改变
- 原因：增加了宠物改变颜色的功能
- 具体变化：新增了宠物类的颜色属性
- 需要更新UML文档！

BUG

什么功能产生的 Bug 最多，为什么？在发布之后发现了什么重要的 bug? 为什么我们在设计/开发的时候没有想到这些情况?

功能：修改日记的时候
原因：要传递任意的属性都能进行修改

代码复审

代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

在项目开发之初，我们制定一个代码编写的规范，并在项目开发的过程中严格按照代码编写的规范。
在开发人员编写完自己的代码后，由开发人员自己进行代码复审，通过代码复审，提高代码管理的质量。
复审过程中，严格按照代码规范的要求进行检查。

代码复审方面

代码风格。如变量和常量的命名、接口与实现类的注释、何时回车、怎样缩进等等。我们通过代码复查，一方面督促开发人员按照规范编写代码，另一方面也使开发人员自身形成良好的编程习惯。代码风格的审查，由于内容比较单一，我们常常可以通过一些代码复查的工具来自动完成，提高复查的效率。
重大缺陷。在一些关于代码复查的文章中，列出了一个长长的单子，描述了代码复查应当着重注意的重大缺陷，它们包括：存在SQL注入、易受跨站点脚本攻击、缓存区溢出、托管代码等等。
设计逻辑与思路的审查。我认为，这部分的审查是代码复查中最核心、最有价值的部分。代码风格与重大缺陷的审查，虽然重要但简单而机械，可以通过软件自动检查；而设计逻辑与思路的审查，却是复杂而有深度的审查，需要有一定理论深度和编码经验的人才能完成。

三、与 alpha 阶段相比的提升

计划安排方面的提升

在alpha冲刺中，我们是根据每个人现有的能力来进行计划安排的，保证每个人都得到合适自己的那一份工作。但是我们没人安排让技术差的同学去花时间学习我们小组在项目开发中用到的技术，没有安排他们学习以快速提高水平，导致部分技术差的同学参与度比较低，到了冲刺后期就没什么事可以做，而负责代码开发的少数几个人到后期还一直在忙。所以在beta冲刺中，我们小组对这一方面进行改进，安排一些参与度比较低的同学去学习项目中要用的技术和工具。
燃尽图中各项任务的量化标准：

任务量的计算采用敏捷开发工作量评估模型：
单个任务工作量(o)=SC单个任务工作量(o)=SC
项目的总工作量(E)=∑i=1n(SC)i项目的总工作量(E)=∑i=1n(SC)i
以上描述的仅仅是属于开发任务任务量，其余文档编辑、问卷调查等任务另算（按时间与任务数大小计算），并且已加入个人任务量

团队分工合作方面的提升

团队分工的规则
组长分配
需要改进的团队分工：
1.上一阶段的代码分工不够明确，这一阶段将更加均匀的分配工作，是每个人的贡献度争取100%
2.上一阶段的测试人员比较单一，这次将增加测试人员数，扩大测试的广度以及深度
3.开会的效率较低，这次将在会前确定好讨论的目标

工具流程方面的提升

需要改进的工具流程（如版本控制、测试工具等）：
1.暂时先完善iphone8plus的版本，后续会开发iphone11等版本
2.java后端将继续沿用JUnit进行单元测试，增大测试覆盖率
3.同时使用Apipost进行接口测试

测试与发布

（1）alpha 阶段在测试方面存在什么问题？beta 阶段是否解决这个问题？
- alpha 阶段的测试人员比较单一，这次将增加测试人员数，扩大测试的广度以及深度
- alpha 阶段没有一个具体的测试计划
（2）团队是否有一个测试计划？为什么没有？
有
（3）团队是否有测试工具来帮助测试？自动化程度如何？
java后端用JUnit进行单元测试，同时使用Apipost进行接口测试。没有使用Web应用程序自动化测试工具。
（4）是否进行了正式的验收测试？
我们团队中有专门的测试小分队，由分队小组长统一制定测试计划，让团队中的测试人员进行最后的验收测试，保证接口正确，功能和性能没有问题。
（5）团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
压力测试的执行是通过自动化工具执行脚本语言。通过多进程运行相同或不同的测试脚本，来模拟多个用户执行相同或不同的任务，实现压力测试。一个测试脚本包含多个事务，设置并发点，先运行到并发点的进程将等待，当所有进程都运行到并发点时，进行释放，使所有的进程同时运行同一个事务，这样就可以测定与实际比较接近的响应时间。
（6）在发布的过程中发现了哪些意外问题？
无