团队成员简介和个人博客地址
| 头像 | 姓名 | 博客园名称 | 自我介绍 | PM | 测试 | 前端 | 后端 |
|---|---|---|---|---|---|---|---|
 |
dzx | 秃头院的大闸蟹 | 大闸蟹是1706菜市场里无菜可卖的底层水货。大闸蟹喜欢音乐（但可惜不会），喜欢lol（可惜上不去大师），喜欢pokemon（可惜买不起游戏机）。虽然大闸蟹能力不突出，但大闸蟹认真负责任劳任怨。希望在这门课中与大家成为朋友，一同努力奋斗，收获知识，并结下羁绊。 | √ | √ | ||
 |
cc | cc17373432 | 喜欢像素rpg。c,java,python,c++都用过，但是都不熟。希望在这学期的软工中和大家共同进步。(争取不拖后腿！) | √ | |||
 |
yjy | MagicJim | 1706底层群员，无名小卒，在1706菜市场买菜时于一水产摊子前相遇组员大闸蟹。没有特别的喜好，没有特别的专长。学过C和Java，还会一点点C++、Python和Ruby。之前没有接触过软工，也没有参加过团队项目。虽然经验不足能力有限，但是交付的任务不咕不鸽，保证认真完成。希望能向同组的大佬们好好学习，在这学期的软工课程有所收获。 | √ | √ | ||
 |
wjx | Kidogu | 目前可以披露的情报：熟悉C, C++, Python, Java, 有一定编程经验。刚刚接触软件工程，不够熟悉，希望和大家携手共进，斩获佳绩。 | √ | |||
 |
css | sugarorange | 1706底层群员，无名小卒。奶茶里喜欢加的配料是奥利奥和脆波波。希望和大家合作愉快，加油，奥利给！ | √ | |||
 |
dlf | blueshift | 星际玩家，最近因狂看CPP Reference视力进一步减退。目前掌握的编程语言有：C/C++(accumulating)、Java、Python(limited packages)。期待与各位敏捷侠开发出让用户满意的软件。 | √ | |||
 |
tq | starmiku | 干员星级：★★★★。招聘合同：大水群群员滕琦，将 |
√ |
团队项目的目标
设计和实现一个基于GitLab的软件工程教学实践平台，用于支持软件工程课上的实践项目，主要包括个人项目、结对项目和团队项目。
预期的典型用户
项目的典型用户主要分为三类人群：学生、助教和老师。我们针对每类典型用户的不同特点，分析了他们使用本项目的典型需求、场景、人群占比等因素。
学生A
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 学生A |
| 身份 | 普普通通的学生 |
| 情况 | 各项能力都处于平均水平。 |
| 动机 | 在软工课程平台上管理项目，接收课程通知，每次作业至少拿个基础分。 |
| 困难 | 在修改时粗心大意导致再次提交的作业存在问题。提交后发现了代码中的问题，本地Debug修改后，没有将应用程序改成在Release环境下生成就提交。 |
| 典型场景 | 提交代码后进行自动化测试，根据测试结果对代码风格以及bug修复后将高质量的版本提交。 |
| 典型描述 | 今后再也不用担心代码内的小问题！ |
| 比例 | 50％ |
| 重要性 | ★★★★★非常重要，占了一半的用户量，如果觉得这个平台好用，也会更愿意学这门课，学完之后也会更愿意向学弟学妹们推荐这门课。 |
助教B
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 助教B |
| 身份 | 软件工程课的助教 |
| 情况 | 监督进度，批改作业。 |
| 动机 | 去每一个人仓库里拉代码太麻烦，部分代码质量低。 |
| 困难 | 课余时间当助教，比较忙。 |
| 典型场景 | 登陆网站助教入口，在具体的作业项目中就能得到所有提交的代码，评测直接由平台进行，只需要提供测试数据就能得到结果排名。进入各项目进度窗口，查看各个组项目进度，对进度慢的组进行提醒。 |
| 典型描述 | 测试自动化，效率提高一千八！ |
| 比例 | 6％ |
| 重要性 | ★★★★★非常重要，自动化测试能极大程度减小助教工作量，助教就可以节省时间帮助更多的同学。 |
教师C
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 教师C |
| 身份 | 软件工程课的老师 |
| 情况 | 发布作业，答疑解惑。 |
| 动机 | 微信区里同学们问的问题大部分是重复的。 |
| 困难 | 比较忙。 |
| 典型场景 | 登陆网站论坛，查看同学们提出的问题，予以解答。 |
| 典型描述 | 答一疑，解千惑。 |
| 比例 | 2％ |
| 重要性 | ★★★★★非常重要，如果老师觉得这个平台好用，今后就会继续使用这个平台，也可能会向其他老师推广。 |
预期的功能描述
| 功能 | 描述 |
|---|---|
| 用户登录 | 输入账号密码登录 |
| 用户注册 | 用户注册新账号 |
| 用户注销 | 用户退出登录 |
| 广播功能 | 教师和助教可以向不同范围内的成员发送广播，所有成员可查看广播消息 |
| 评测功能 | 自动拉取学生仓库，实现个人和结对项目的自动评测 |
| 用户界面 | 用户登录成功后显示的总览界面 |
| 班级界面 | 展示、管理班级相关信息 |
| 项目界面 | 展示、管理项目相关信息 |
| 学生个人界面 | 展示、管理学生个人信息 |
| 教师&助教个人界面 | 展示、管理教学情况 |
| 创建班级界面 | 教师可在该界面创建班级 |
| 创建项目界面 | 教师和助教可在该界面创建项目 |
| 学生团队界面 | 展示、管理学生团队及学生项目相关信息，包括项目看板、冲刺、issue、博客的创建和管理 |
预期的用户数量
我们的项目的目标用户群体是本学期选软件工程课程的同学，预计用户数量为80人。如果我们的项目在本学期的课程结束后能够持续运营和管理，未来的用户预计为下一届选课的同学。
事先定义的软件用户量达到了么？
基本达到了。
团队的成员如何分工协作的？有什么经验教训？
在Alpha阶段的前期，我们分为了三个小组，分别是Debug组、完善组和增量组。每组两名同学，一名主要负责前端，一名主要负责后端，以三组并行的方式进行开发。
这样的分组方式持续了一周的时间，我们根据项目进展，将Debug组和完善组合并成了团队项目增量开发组，增量组成为个人和结对项目增量开发组，两组分别负责团队项目、个人和结对项目的增量开发。
在Alpha阶段的团队合作中，我们团队的分工明确，每个同学都有自己负责的模块和任务，团队氛围融洽。在每天的例会中，各个小组都会进行进度的汇报，相互督促，没有拖延的情况发生。
团队是如何进行项目管理的？
我们使用GitHub进行项目管理。新的任务通过issue的形式发布，每完成一项任务，就把对应的issue关闭。
为了防止两个人同时修改代码导致发生冲突，我们也采取了一些措施。一开始的计划是，每组在一天内的不同时间工作，分成上午下午晚上这三个时段，但发现大家的时间并不能完全固定，这样做不太现实。于是我们改变计划为，每次有同学修改代码前都会在群里说一下，给项目加锁，等修改完再释放锁，下一位同学再开始修改。大家轮流对项目进行修改，没有发生过冲突。
我们的GitHub中的issue：
团队如何平衡 时间/质量/资源 争取如期完成任务的？
由于时间比较紧张，我们决定Alpha阶段的主要目标是开发出平台的最小可用版本，修复项目中的Bug，完善基本功能，增量开发部分新功能。细节方面的优化和更多功能的进一步开发放在Beta阶段进行。
我们团队成员的积极性较高，大家都在尽量避免将项目拖到最后再完成，不想让自己成为影响团队进度的人。因此，我们在Alpha阶段的前两周节奏较快，项目进度始终处于稳步推进的状态，没有发生在项目后期疯狂赶ddl的情况。我们团队在时间安排上较为稳妥，充分利用了时间。
在产品之外，团队代码的软件工程质量如何？
测试用例和代码覆盖率
-
测试用例数目：112
-
运行测试用例得到代码覆盖率的视频录像
齐全的文档在哪里？
- 代码注释：在项目代码中给每个方法编写了注释，便于理解。
- 项目配置说明：基于项目原有的README，结合我们在配置环境过程中遇到的一些问题，我们编写了项目配置踩坑记，将在润色后与原有README合并，给今后继承我们项目的同学参考。
- 评测机API文档：我们仿照GitLab官方API文档，撰写了我们的评测机的API文档auto test runner API。
- 使用指南：
- 在线版本：请见博客园使用指南
- PDF版本：使用Latex编写
有些项目是在原来的基础上改进的，那么我们团队的软件工程项目质量有什么样的提高？
-
增强可用性：修复原来项目中存在的大量bug，完善了原有的功能，保证基本功能的正常使用。
-
功能更人性化：我们将一些操作进行了封装，例如编辑班级、返回功能。减少了在平台和GitLab之间的跳转，使用户体验更好。
-
增量开发：增加了一些新功能，例如评测功能、创建仓库、权限管理、广播功能等，使平台覆盖的功能更加全面。
-
编写文档、代码注释：使项目代码更加易读、易懂，便于以后继承我们项目的同学们更好地入手。
原来的项目有些代码混乱，没有注释，没有详细的文档，你们的项目是如何更好解决这个问题的？明年的同学继续开发这个项目，会不会出现类似的抱怨？如果一个新学生在一台新机器上想编译并运行你的项目， 请问能顺利完成么？有什么样的文档能指导新学生？
由于这个项目的环境配置比较复杂，我们在按照项目原有的配置说明进行配置时，仍然遇到了一些难题，花了不少时间。我们将这些问题的解决方法记录在了踩坑记里。这篇踩坑记经过了组内多名成员的迭代改进，已经较为完善和规范。对于明年继续继承我们项目的同学，我们有信心让他们能够比较顺利地配置好环境，不会再踩我们踩过的坑。
除了配置说明外，我们还编写了项目的使用指南，无论是使用者还是开发者，都能从指南中了解这个平台的功能和使用方法。
在代码方面，我们重新梳理了原项目的代码逻辑，并在原先有些混乱的地方做了一些改动。我们还编写了代码注释，方便今后继承项目的同学快速上手读懂代码。
对于项目的目标用户是一般学生的项目， 你们如何找到学生做需求分析？他们给你什么样的反馈？
我们采访了自己的室友，他们也是选了软件工程课的同学们，询问他们的需求。从他们那里得到的反馈和我们之前的计划设想基本相同。
团队项目的实际进展
发布的功能
详见我们团队项目的发布声明：发布声明
在哪里发布了软件
我们已经将项目部署在服务器上，用户可通过http://20.185.223.195直接访问。
用户反馈的截屏
说明在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？
我们每天都会将今天已完成的任务对应的issue关闭，有了新任务就会发布issue，不会为了燃尽图好看而关闭没有完成的issue，或是干脆不发布issue。并且每个issue的关闭，都会经过经办人的核查，确保每个issue的发布和关闭，都是我们项目进展的真实状态的体现。
团队成员在Alpha阶段的角色和具体贡献
| 名字 | 角色 | 团队贡献分 | 具体的, 可衡量的, 可验证的贡献 | 贡献总结 |
|---|---|---|---|---|
| css | PM | 51 | 写了20篇博客 组织了21次例会 |
撰写博客、组织例会、把握项目进度、项目发布 |
| yjy | 增量/个人和结对项目增量开发 | 59 | 写了3892行代码 发现了4个bug 修复了12个bug |
实现广播功能，自动仓库分配 调整gitlab权限分配结构，评测runner及api的封装和对接 |
| tq | 增量/个人和结对项目增量开发 | 49 | 写了404行代码 发现了2个bug 修复了3个bug 撰写项目介绍博客 技术学习花费25小时 |
实现广播功能、自动测试与仓库分配、构建runner 完成一些博客的撰写（团队介绍博客、功能规格博客等） |
| wjx | 完善/团队项目增量开发 | 47 | 写了288行代码 发现了4个bug 修复了5个bug 发布技术规格说明书 技术学习花费27小时 熟悉代码花费25小时 邀请了4位用户 |
代码部分： 添加用户注销、项目班级重名检查、 编辑班级详情、部分代码逻辑调整、 修复不能打开team events代码说明的bug、 创建团队项目的功能、创建冲刺时的班级说明、 冲刺详情的对应班级以及项目的说明、 撰写代码注释、修复冲刺页面的bug、 修复编辑了错误的班级的bug 其他部分： 学习前后端知识、 阅读前后端代码并发布后端代码的review、 测试项目、发现bug和功能问题、 邀请用户使用平台等 |
| dlf | 完善/团队项目增量开发 | 46 | 写了274行代码 修复了1个bug 邀请了3位用户 |
完善页面跳转逻辑 读了Application Record相关的代码 添加编辑班级的功能 |
| cc | Debug/团队项目增量开发 | 48 | 写了430行代码 发现了3个bug 修复了8个bug 发布功能规格说明书 技术学习花费20小时 熟悉代码花费30小时 邀请了2位用户 |
代码部分： 阅读了issue部分相关代码 修复了新建issue默认加入todo列的bug 修复了没有将gitlab中issue全部拉取拉取的bug 修复了项目看板计数、权重、优先度显示的bug 新增了为项目自定义label的功能 完善了issue部分的注释 其他部分： 采访往届团队 |
| dzx | Debug/团队项目增量开发 | 50 | 撰写项目使用指南 撰写团队介绍&采访 进行了3次对于项目的全面测评 撰写bug复现文档 发现了21个bug 修复了8个bug 邀请了30位用户 技术学习花费30小时 熟悉代码花费24小时 |
对项目进行细致的测评，并对bug进行定位，进行bug修复 撰写团队介绍、使用指南 大力推广项目 |
所做软件最有特色的功能是什么，请着重介绍一下。活的用户如何从你的软件中获益的，请现场展示。
评测功能
将创建评测点、提交评测任务、获取评测结果封装成按钮。实现自动拉取学生仓库，在评测机上进行自动评测，并返回评测结果。
增加此功能后，在平台上可以实现个人和结对项目的自动评测，而不需要助教去手动克隆每个学生的项目，再逐一进行评测，为助教评测作业提供了极大的便捷。
- 创建评测点
- 提交评测任务
- 获取评测结果
团队项目功能
我们实现了多种与团队项目管理有关的功能，可以在平台上很方便地进行团队项目的管理。
- 项目看板
- 冲刺
- 问题
团队从用户那里得到了什么反馈，有什么样的bug？
用户给予我们的反馈普遍较好，也收到了一些问题的反馈。
总结，整个团队在Alpha阶段学到了什么，对软件工程的教育，对这个具体的课程有什么批评建议？Beta阶段有什么大体计划？
在Alpha阶段学到的
-
软件工程流程方面
体验了软件工程中一个项目从前期的团队建立、整体规划、需求分析、任务拆解，到项目的开发、冲刺，再到项目的发布、总结、规划下一阶段，这样一个完整的流程。对软件的工程化开发有了更深入的体会和理解。
-
团队协作方面
我们的团队是一个七人团队，以往的课程往往是三四个人的小组，我们对团队合作有了更丰富的经验和感受，体会到了如何更好地发挥出自己在团队中的作用，也锻炼了自己的协作、沟通、表达能力。无论是基础较好的同学，还是基础一般的同学，都能够在团队中尽自己所能，做出自己的贡献，在团队合作中有所收获，实现1+1+1+1+1+1+1>7的成果。
-
技术方面
- GitLab
- Ruby on Rails
- Sqlite3/PostgreSQL
- Vue
- JavaScript
- Nginx反向代理
Beta阶段的计划
在Beta阶段，我们的主要任务是结合Alpha阶段发布后收到的用户反馈，提升用户体验，优化细节。
-
界面美化
-
批量添加成员
-
创建团队的合法性检测
-
登录时的身份验证
-
完善评测机，使用docker容器作为评测环境，防止评测对主机的影响
-
进一步开发评测机的API，实现更多功能，以及更多的评测指标
-
引入团队评分系统，用户提供一个评分规则，我们自动算分
-
引入评分系统，对博客分、个人、结对、团队分进行整合，整个平台成为一个更加凝聚的整体，一键评分
-
各项信息的导出（比如下载对应的.csv等）