UltraSoft - DDL Killer - Alpha 项目展示

团队介绍

CookieLau fmh 王 FUJI LZH DZ Monster

PM & 后端前端前端前端后端后端

CookieLau	fmh	王 FUJI	LZH	DZ	Monster
PM & 后端	前端	前端	前端	后端	后端

软件介绍

项目简介

项目名称：DDLKiller
项目描述：“妈妈再也不用担心我忘交作业了！”
开发团队：软软软团队-“介绍一下自己吧”

项目预期

1. 典型用户

用户信息	用户情况
姓名	小A
用户身份	计算机学院大三学生
知识层次/能力	成绩普通，专业知识能力一般
生活/工作	学习热情不高，作业往往以DDL为动力
用户动机	希望可以方便及时地得到各项作业DDL的提醒
用户困难	各门课作业的DDL往往发布在课程中心上需要手动登录查看很不方便而且有时会忘记作业的截止时间
典型场景	在作业DDL的前一天发送邮件，提醒用户作业内容和截止时间 (类似于博客园的作业提醒)
用户偏好	及时快捷地得到通知而无需自己登录网站查询
用户比例	50%

用户信息	用户情况
姓名	小B
用户身份	计算机学院某项目小组主要负责人
知识层次/能力	规划管理水平与领导能力较强，专业知识扎实
生活/工作	对于小组项目认真负责，尽心尽力，积极热情
用户动机	希望可以更好地管理和组织组内的讨论或者会议保证相关成员得到及时提醒而不会忘记到场
用户困难	目前的普遍方法就是微信群等社交APP内的通知，但是不够科学高效，需要过多的人力投入
典型场景	向组内成员发布提醒事项，添加到各成员的DDL列表之中，实现自定义按时提醒功能
用户偏好	简单自动地发布日程信息
用户比例	20%

用户信息	用户情况
姓名	小C
用户身份	计算机学院大三学生
知识层次/能力	成绩较好，专业知识水平较高
生活/工作	学习积极热情，喜欢与同学分享交流
用户动机	希望在统一的平台上可以得到一门课程较为全面的课程资源而且可以分享补充
用户困难	各门课程的资源十分分散，有的在不同的网站上，有的在微信群里，很难统一管理而且很难补充完善
典型场景	期末考期期间下载并相互分享各门课程的复习资料以及往年试题等
用户偏好	各门课程来自各方面的资源得到充分整合且能够分享自己的资源进行补充
用户比例	30%

2. 功能描述与版本实现

功能描述	设计原型	Alpha实现
登陆界面
注册界面
首页
日历视图
事项详情页
新建事项
列表视图
课程视图 (ddl列表)
课程视图 (资源列表)
消息中心		鸽了，暂时没啥用
个人中心 (个人资料)
个人中心 (个性设置) 尚未实现

3. 预期用户数量

发布一周内注册用户量：100~150人

Alpha阶段项目实况

1. 项目效果展示

1.1 用户注册

1.2 使用北航邮箱激活

1.3 登陆并同步课程中心

1.4 日历视图和新建日程

1.5 修改任务提醒时间

1.6 查看课程的DDL和课程资源

2. 实际用户规模

发布一天后：77人
发布两天后（截至2020.5.7晚）：148人

团队管理

团队分工

团队中的成员分工大致如下：

成员	分工
CookieLau	PM、后端、测试、部署
刘zh	前端、测试
冯mh	前端、测试
王fuji	前端、美工
Dz	后端
杨jc	后端、文案、测试

项目进展情况（燃尽图）

团队贡献分

根据：

每个成员实现的任务的客观工作量大小
每个成员实际的贡献指标
团队贡献分博客中的奖惩规则
成员之间相互不记名互评

我们得到以下结果：

成员	CookieLau	Dz	Monster	kkkkk	FUJI Wang	LiuZH
最终得分	$\frac{326}{1842}*300=53$	$\frac{294}{1842}*300=48$	$\frac{304}{1842}*300=50$	$\frac{319}{1842}*300=52$	$\frac{296}{1842}*300=48$	$\frac{303}{1842}*300=49$

具体贡献：

成员	职位	代码	博客	调查	推广
CookieLau	PM、后端	800行Python，包括爬虫、邮件功能和后端数据库交互	Scrum Meeting + 技术规格功能规格+发布声明与事后分析的终稿	宿舍内部调查	微信朋友圈 3个qq群 6+个微信群
Monster	后端	约250行（有效代码）	测试报告、发布声明、项目展示和事后分析博客的初版	在发布后收集部分反馈意见	在微信朋友圈和自己的几个北航小群内推广
Dz	后端	数据库创建以及API编写维护，代码及注释行数在400行左右。	参与功能规格博客编写	对各类接口和最终的完成项目进行了测试	由于项目受限于北航学生，故推广对象和组内成员有很大的重复，有效的推广范围主要在于自己原高中的学弟学妹，大约十几人
LiuZH	前端	1500行代码，三四个文档	功能规格博客部分	宿舍内部调查	推广了三四个小群，发了朋友圈
王FUJI	前端	800行	无	宿舍内部调查	pyq文案被征作推广文案
kkkkk	前端	600行左右	技术博客	宿舍内部调查	pyq*1

项目管理

实话实说，Alpha阶段我们在项目管理这方面做的并不理想。我们的项目主要分为三个阶段：

第一阶段

一开始，我们是在GitHub的仓库上进行多人协作的，前端和后端分别位于不同的branch，分别进行开发。

第二阶段

这种做法在前后端分别进行开发的时候没有出现什么问题，但是到了前后端连接的时候就出现了问题：一方面我们的组员都没有前后端连接的经验，因此将前后端放在何种目录结构下是个大问题，需要不断地去尝试；另一方面，这个阶段的前后端api调用也需要经常改动，以确保后端的api能正确地被前端调用。基于这些原因，我们专门成立了一个三人小组（包括PM、前端1人和后端1人）进行前后端连接的调试，这一阶段的代码被放在了gitee上。

第三阶段

最后，在前后端成功连接起来后，就进入了前后端的bug修复阶段，这一阶段很多bug是要前后端协商解决的，因此就采用了腾讯会议+VSCode直接连接服务器修改代码的方式。

代码管理

代码测试

我们并没有对前端和后端分开进行很多的单独测试，相反，我们在前后端连接起来之后进行了相当多的功能测试，测试内容覆盖了所有已经实现的功能，并且在修复了一个bug之后还会进行其他功能的回归测试。此外，由于课程中心的多样性和个性化，在测试课程中心的爬虫时，我们还请每位组员都参与了测试，甚至请了一些其他同学来测试，确保爬虫能适应多种情况。

我们没有进行大规模的压力测试，原因有二：第一，我们网站的核心功能是通过邮件提醒来实现的，一直在线的用户并不会很多，服务器压力相对不会那么大；第二，我们的测试时间有限，在功能测试阶段花费了较多时间，相对的留给其他测试的时间就不够了。比较幸运的是，我们的服务器到现在为止还没有出现过因压力过大而崩溃的情况。

api文档&json文档

在我们的项目中api和json文档非常重要，前后端依靠这两个文档实现了分离，因此这两个文档需要经常维护和更新。这两个文档均放在了我们的GitHub仓库中，以下是部分文档内容的展示：

有了这些文档，即使是新加入的成员应该也能快速上手项目，因为他们只需按照这些api和json的格式进行编写即可。

特色功能

我们的主打功能是用户的DDL提醒功能，这个DDL可以是从课程中心同步的作业，也可以是用户自定义的事项。不同于简单的DDL整理和查询，我们采用了邮箱进行DDL提醒，以保证用户不需要登陆我们的网站也可以了解到即将到期的DDL。下面是一个提醒邮件的例子：

PC端：

手机端：

我们还提供了设置提醒邮箱的功能，例如将提醒邮箱设置为QQ邮箱，可以在微信中直接收到邮箱助手的相关提醒。

用户反馈

不多说了，直接上图！

Alpha阶段反思和总结

做的好的地方

团队气氛融洽，组员合作进行得较好
组员对项目都比较负责，没有特别划水的组员
计划阶段的功能基本完成
组员基本都是从零开始学习，最后项目跑起来的时候真的很有成就感
虽然发布很晚但是依然完成了课程的目标
找到了属于我们团队自己的开发方式（腾讯会议+VSCode的多人结对编程）

做的不够好的地方

没有工程经验，外加理解错了课程组的时间安排，导致前期进度比较缓慢
对团队的协作管理不够到位，出现了仓库体积过大导致被迫迁移到Gitee的情况
对未知的困难估计不到位，比如前后端连接，导致发布时间拖后

Alpha阶段我们项目的上线时间拖了一周左右，大部分时间都花在了前后端的连接上，不过这一点相信在Beta阶段会有很好的缓解，因为大家都有了经验。

对课程的建议

如果可能的话，希望课程组能提供更好的服务器，不要让硬件成为了限制我们项目开发和运行的门槛。

（阿里云的免费服务器在使用VSCode多人实时协作时经常卡死）

其他

我们要做软件工程，那就要有一点工程的样子：

团队项目的目标，预期的典型用户，预期的功能描述，预期的用户数量在哪里？
- 在上面
团队的产品如何满足了用户的需求？要看到目标用户使用产品的过程和评价。
- 在上面
事先定义的软件下载量达到了么？为什么没有达到？
- 达到了
团队的成员如何分工协作的？有什么经验教训？
- 分工协作：
  - 小团队分为前端和后端，不专门配备测试，自己写的代码自己测
  - 在项目开始阶段提出预期和需求并加入到Github issue上，细化到自己预期的使用经历，开发进度一目了然
  - 在开发过程中维护 锅&坑 文档，具体到负责人，遇到别人的/自己的问题直接加入锅中，大家随时能看到
  - 使用结对编程+实时讨论的方式营造氛围提高效率
- 经验教训：
  - 初始的项目预期一定要细化细化再细化，否则会对项目的进度产生错误的估计，本来开发到尾声的时候发现有功能一直忘了加，非常仓促
  - 要结对编程不要成为孤立的个体
  - 对Github的 gitignore 一定要考虑周到，否则仓库一旦膨胀只能删库重来
团队是如何进行项目管理的？
- 在上面
团队如何平衡时间/质量/资源争取如期完成任务的？
- 这是一个三角理论，为了更好的用户体验，我们不愿意发布粗糙的产品，所以舍弃了时间，我们的项目稍微延后发布但是获得了使用者很高的评价和赞誉
在产品之外，团队代码的软件工程质量如何？如何用数据来证明？
- 工程质量当然有待提升，出现过需要修改数据库的情况，主要是考虑不全导致的需要建表实现关系
测试用例数目，代码覆盖率数目。
- 没有具体的数目，只能说所有能够点击的地方我们都已经尝试过了。
运行测试用例得到代码覆盖率的视频录像，(需要现场看到。没有诸如 “我的电脑没有装测试环境”,“文件不全”等等借口)
- 可以直接删除账户从注册开始演示一遍。
代码规范在哪里？
- 在仓库的docs里面有数据库编写规范，其他的前端后端规范有待补充
齐全的文档在哪里？
- 在仓库里
有些项目是在原来的基础上改进的，那么我们团队的软件工程项目质量有什么样的提高？例如，代码覆盖率从原来的x增长到y？
- 并没有，是自己全新的idea，全新的项目
原来的项目有些代码混乱，没有注释，没有详细的文档，你们的项目是如何更好解决这个问题的？明年的同学继续开发这个项目，会不会出现类似的抱怨？如果一个新学生在一台新机器上想编译并运行你的项目，请问能顺利完成么？有什么样的文档能指导新学生？
- 自己的项目不存在这个问题
对于项目的目标用户是一般学生的项目，你们如何找到学生做需求分析？他们给你什么样的反馈？
- 我们自己就是学生，组内6人+每个人的宿舍舍友已经可以做需求分析了，这个项目的idea就是PM自己开学的时候的痛点，尝试过Tower等日程协作软件但是使用不是很舒服所以自己做了
- 反馈很不错，有的同学会想一直用下去，但是可能。。。看看后续的反馈吧，既然注册了域名我自己也是想一直用到至少毕业。
所有的项目都会收集到用户的数据，请问你们对这类数据做了什么样的分析，这些分析如何验证或推翻了原来的假设？这些数据如何帮助项目改进软件工程的质量？
- 用户注册量和同步课程中心的次数以及时间频率，还用用户主动添加的任务的数量