团队成员简介和个人博客地址
| 头像 | 姓名 | 博客园名称 | 自我介绍 | 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 | 干员星级：★★★★。招聘合同：大水群群员滕琦，将 |
√ | ||||
| my | mollygarden | 1706底层群员，无名小卒。因为晕画面没打过游戏，喜欢上（听）说唱和（看）街舞的一只程序媛。在接触计算机的第三年第一次开发应用软件，半道转会到宝可梦家族，希望得到大佬们提携，收获愉快的合作经历。 | √ |
团队项目的目标
设计和实现一个基于GitLab的软件工程教学实践平台，用于支持软件工程课上的实践项目，主要包括个人项目、结对项目和团队项目。
预期的典型用户
项目的典型用户主要分为三类人群：学生、助教和老师。我们针对每类典型用户的不同特点，分析了他们使用本项目的典型需求、场景、人群占比等因素。
学生A
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 学生A |
| 身份 | 普普通通的学生 |
| 情况 | 各项能力都处于平均水平。 |
| 动机 | 在软工课程平台上管理项目，接收课程通知，每次作业至少拿个基础分。 |
| 困难 | 在修改时粗心大意导致再次提交的作业存在问题。提交后发现了代码中的问题，本地Debug修改后，没有将应用程序改成在Release环境下生成就提交。 |
| 典型场景 | 提交代码后进行自动化测试，根据测试结果对代码风格以及bug修复后将高质量的版本提交。 |
| 典型描述 | 今后再也不用担心代码内的小问题！ |
| 比例 | 50％ |
| 重要性 | ★★★★★非常重要，占了一半的用户量，如果觉得这个平台好用，也会更愿意学这门课，学完之后也会更愿意向学弟学妹们推荐这门课。 |
助教B
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 助教B |
| 身份 | 软件工程课的助教 |
| 情况 | 监督进度，批改作业。 |
| 动机 | 去每一个人仓库里拉代码太麻烦，部分代码质量低。 |
| 困难 | 课余时间当助教，比较忙。 |
| 典型场景 | 登陆网站助教入口，在具体的作业项目中就能得到所有提交的代码，评测直接由平台进行，只需要提供测试数据就能得到结果排名。进入各项目进度窗口，查看各个组项目进度，对进度慢的组进行提醒，以及在平台上为同学们的博客作业评分。 |
| 典型描述 | 测试自动化，效率提高一千八！ |
| 比例 | 6％ |
| 重要性 | ★★★★★非常重要，自动化测试能极大程度减小助教工作量，助教就可以节省时间帮助更多的同学。 |
教师C
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 教师C |
| 身份 | 软件工程课的老师 |
| 情况 | 发布作业，答疑解惑。 |
| 动机 | 微信区里同学们问的问题大部分是重复的。 |
| 困难 | 比较忙。 |
| 典型场景 | 登陆网站论坛，查看同学们提出的问题，予以解答。 |
| 典型描述 | 答一疑，解千惑。 |
| 比例 | 2％ |
| 重要性 | ★★★★★非常重要，如果老师觉得这个平台好用，今后就会继续使用这个平台，也可能会向其他老师推广。 |
预期的功能描述
| 功能 | 描述 |
|---|---|
| 用户登录 | 输入账号密码登录 |
| 用户注册 | 用户注册新账号 |
| 用户注销 | 用户退出登录 |
| 广播功能 | 教师和助教可以向不同范围内的成员发送广播，所有成员可查看广播消息 |
| 评测功能 | 自动拉取学生仓库，实现个人和结对项目的自动评测 |
| 用户界面 | 用户登录成功后显示的总览界面 |
| 班级界面 | 展示、管理班级相关信息 |
| 项目界面 | 展示、管理项目相关信息 |
| 学生个人界面 | 展示、管理学生个人信息 |
| 教师&助教个人界面 | 展示、管理教学情况 |
| 创建班级界面 | 教师可在该界面创建班级 |
| 创建项目界面 | 教师和助教可在该界面创建项目 |
| 学生团队界面 | 展示、管理学生团队及学生项目相关信息 |
| 教学进度界面 | 展示教学进度 |
| 组织管理界面 | 展示、管理组织相关信息 |
| 博客界面 | 展示、管理博客 |
预期的用户数量
我们的项目的目标用户群体是本学期选软件工程课程的同学，预计用户数量为80人。如果我们的项目在本学期的课程结束后能够持续运营和管理，未来的用户预计为下一届选课的同学。
事先定义的软件用户量达到了么？
基本达到了。
由于用户数目在Alpha阶段已经基本确定下来了，我们在Beta阶段发布的目标是增加20个issue和20篇博客，这个目标也已经达成。
团队的成员如何分工协作的？有什么经验教训？
在Beta阶段，我们改变了Alpha阶段分组协作的方式，改为每个人负责一项或几项新功能的开发。基于Ruby开发的特点，团队的每个成员在Alpha阶段都学习了前端和后端的相关技术，每个人都能够独立负责一个功能的前、后端整体开发，我们认为这样的分工方式效率更高。
我们将分工也体现在了GitHub的issue中，我们的每一项新功能对应的issue都分配了assignee，标志着功能与负责人的对应。
团队是如何进行项目管理的？
我们使用GitHub进行项目管理。新的任务通过issue的形式发布，每完成一项任务，就把对应的issue关闭。
为了防止两个人同时修改代码导致发生冲突，我们也采取了一些措施。每次有同学修改代码前都会在群里说一下，给项目加锁，等修改完再释放锁，下一位同学再开始修改。大家轮流对项目进行修改，没有发生过冲突。
Beta阶段的改进
在Alpha阶段的评审中，老师和助教给我们提出的建议是将issue和commit对应起来，我们在Beta阶段做到了这一点：
E.g：改进广播系统
并且我们也规范了commit的格式，例如refinement、bugfix、new feature等类型，加上具体的内容，使commit信息更明确清晰。
我们的GitHub中的issue：
在产品之外，团队代码的软件工程质量如何？
测试部分
在测试方面，我们保留了Alpha阶段的全部测试用例，以确保回归测试的正确性。
每名成员负责测试自己所开发的新功能，修复出现的bug，确保能够正常使用后再提交。
齐全的文档在哪里？
- 代码注释：在项目代码中给每个方法编写了注释，便于理解。
- 项目配置说明：基于项目原有的README，结合我们在配置环境过程中遇到的一些问题，我们编写了项目配置踩坑记，将在润色后与原有README合并，给今后继承我们项目的同学参考。
- 评测机API文档：我们仿照GitLab官方API文档，撰写了我们的评测机的API文档auto test runner API。
- 使用指南：
由于在Beta阶段新增了不少功能，界面也有较大的调整，我们撰写了使用指南的Beta版本。
有些项目是在原来的基础上改进的，那么我们团队的软件工程项目质量有什么样的提高？
-
增强可用性：修复原来项目中存在的大量bug，完善了原有的功能，保证基本功能的正常使用。
-
功能更人性化：我们将一些操作进行了封装，例如编辑班级、返回功能。减少了在平台和GitLab之间的跳转，使用户体验更好。
-
增量开发：增加了一些新功能，例如评测功能、创建仓库、权限管理、广播功能等，使平台覆盖的功能更加全面。
-
编写文档、代码注释：使项目代码更加易读、易懂，便于以后继承我们项目的同学们更好地入手。
原来的项目有些代码混乱，没有注释，没有详细的文档，你们的项目是如何更好解决这个问题的？明年的同学继续开发这个项目，会不会出现类似的抱怨？如果一个新学生在一台新机器上想编译并运行你的项目， 请问能顺利完成么？有什么样的文档能指导新学生？
由于这个项目的环境配置比较复杂，我们在按照项目原有的配置说明进行配置时，仍然遇到了一些难题，花了不少时间。我们将这些问题的解决方法记录在了踩坑记里。这篇踩坑记经过了组内多名成员的迭代改进，已经较为完善和规范。对于明年继续继承我们项目的同学，我们有信心让他们能够比较顺利地配置好环境，不会再踩我们踩过的坑。
除了配置说明外，我们还编写了项目的使用指南，无论是使用者还是开发者，都能从指南中了解这个平台的功能和使用方法。
在代码方面，我们重新梳理了原项目的代码逻辑，并在原先有些混乱的地方做了一些改动。我们还编写了代码注释，方便今后继承项目的同学快速上手读懂代码。
对于项目的目标用户是一般学生的项目， 你们如何找到学生做需求分析？他们给你什么样的反馈？
我们采访了自己的室友，他们也是选了软件工程课的同学们，询问他们的需求。从他们那里得到的反馈和我们之前的计划设想基本相同。
团队项目的实际进展
发布的功能
详见我们团队项目的Beta阶段发布声明：Beta阶段发布声明
在哪里发布了软件
我们已经将项目部署在服务器上，用户可通过http://20.185.223.195直接访问。
用户反馈的截屏
说明在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？
我们每天都会将今天已完成的任务对应的issue关闭，有了新任务就会发布issue，不会为了燃尽图好看而关闭没有完成的issue，或是干脆不发布issue。并且每个issue的关闭，都会经过经办人的核查，确保每个issue的发布和关闭，都是我们项目进展的真实状态的体现。
团队成员在Beta阶段的角色和具体贡献
| 名字 | 角色 | 团队贡献分 | 具体的, 可衡量的, 可验证的贡献 | 贡献总结 |
|---|---|---|---|---|
| css | PM | 49 | 写了17篇博客 组织了12次例会 |
撰写博客、组织例会、把握项目进度、项目发布 |
| yjy | 开发 | 41 | 写了1595行代码 撰写1篇技术博客 |
1. 调整了前端的界面 2. 增加了教学计划功能 3. 增加了登录的权限管理以及组织的创建 |
| tq | 开发 | 51 | 写了1030行代码 撰写1篇技术博客 |
1. 多评测机功能 2. 评测点管理功能 3. 班级管理UI调整 |
| wjx | 开发 | 53 | 写了530行代码 撰写1篇技术博客 |
1. 批量创建结对项目 2. 批量创建团队项目 3. 创建博客选择作业 4. 学习vue组件 5. 学习element UI 6. 检查代码、发现和报告bug |
| dlf | 开发 | 54 | 写了227行代码 | 1. 增加表单合法性检查 2. 广播消息及新教学任务的实时通知 |
| my | 开发 | 52 | 写了426行代码 技术学习、熟悉代码花费20小时 |
组织的显示，修改，删除 |
| dzx | 开发、测试 | 50 | 写了818行代码 撰写1篇技术博客 撰写使用指南 |
1. 调整了前端的界面，增加了博客入口 2. 新增了批量创建学生用户的功能 3. 增加了博客作业的新建和展示功能 4. 增加新建博客选择博客作业 5. 调整博客显示界面 6. 增加博客评分功能 7. 调整所有博客的显示功能 8. 书写使用指南 9. 测试bug |
所做软件最有特色的功能是什么，请着重介绍一下。活的用户如何从你的软件中获益的，请现场展示。
-
批量添加学生
-
批量创建团队和结对项目
-
博客作业和评分
-
教学进度管理
-
新广播通知
-
表单合法性检查
-
评测系统
-
组织管理
图文版详见发布声明：发布声明，我们也录制了视频进行播放展示。
团队从用户那里得到了什么反馈，有什么样的bug？
用户给予我们的反馈集中表示为界面变化较大，更加美观了，也表示平台访问速度较慢，比较卡。
总结，整个团队在Beta阶段学到了什么，对软件工程的教育，对这个具体的课程有什么批评建议？
在Beta阶段学到的
-
更加重视项目管理
-
时间和质量的平衡与取舍