汇总
团队作业第一次——种子队伍选拔和团队展示
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第一次——种子队伍选拔和团队展示 |
| 这个作业的目标 | 组建 6-8 人团队，定一个学期选题并做出 PPT |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
1 团队名
- 沙雕网友2020
2 团队项目
- 爱宠云--爱护宠物人的云集地
3 团队队员风采
- 3.1
- 学号：221701413
- 成员姓名：龙
- 成员博客园地址：博客园地址
- 成员性格：比较内向
- 擅长的技术：无
- 兴趣爱好：小说，漫画
- 希望的软角色：都行
- 一句slogan：
- 3.2
- 学号：221701408
- 成员姓名：221701408陈怡
- 成员博客园地址：博客园地址
- 成员性格：温婉细腻，谋定后动
- 擅长的技术：JAVA
- 兴趣爱好：历史，小说，古风歌曲，单机游戏
- 希望的软角色：皆可
- 一句slogan：虽然我很菜，可是我会努力学习
- 3.3
- 学号：221600233
- 成员姓名：吴江旭
- 成员博客园地址：博客园地址
- 成员性格：较为内向，性格偏懒
- 擅长的技术：无
- 兴趣爱好：足球，动漫
- 希望的软角色：无
- 一句slogan：
- 3.4
- 学号：041701124
- 成员姓名：12we123asd
- 成员博客园地址：博客园地址
- 成员性格：温和友好
- 擅长的技术：c
- 兴趣爱好：打游戏，闲逛
- 希望的软角色：除了做报告的角色
- 一句slogan：周末神圣不可侵犯！
- 3.5
- 学号：221701428
- 成员姓名：木头人超自信
- 成员博客园地址：博客园地址
- 成员性格：活泼开朗
- 擅长的技术：无
- 兴趣爱好：游戏，篮球
- 希望的软角色：PM
- 一句slogan：每天进步一点点
- 3.6
- 学号：221701205
- 成员姓名：nd12345
- 成员博客园地址：博客园地址
- 成员性格：特别内向
- 擅长的技术：无
- 兴趣爱好：健身
- 希望的软角色：皆可
- 一句slogan：菜 无敌踩 但也还是慢慢努力吧
- 3.6
- 学号：<221701441>
- 昵称：AIMAN
- 博客园地址
- 性格：较为内向，
- 擅长的技术：无
- 爱好：足球
- 希望的角色：无
4 团队首次合照
- 就将就先用头像替代啦
5 团队愿景
- 愿景对我们组来说可能比较灰暗，不奢求啥种子队伍了，毕竟大佬们都组团抱在一起了，没人带我们，我们组基本都是菜鸡没人要报团在一起，代码能力不强其他方面可能也是勉勉强强，所以就希望我们接下来的团队作业可以做的过来，不奢求其他，希望我们组能平稳度过这门课吧
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第二次—团队Github实战训练 |
| 这个作业的目标 | 开发一个向社会限量供应的口罩应用 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》、CSDN论坛 |
一、仓库地址
https://github.com/xlaq/live-project
二、组员职责分工
| 学号 | 姓名 | 分工 |
|---|---|---|
| 221701413 | 龙 | 博客，部分数据库 |
| 221701408 | 陈怡 | gui的构建 |
| 221701428 | 木头人超自信 | 中签相关函数 |
| 041701124 | 12we123asd | 部分数据库，和判断预约相关的函数 |
| 221600233 | 吴江旭 | 身份证验证函数 |
| 221701205 | nd12345 | 用户手册 |
| 221701441 | AIMAN |
三、github 的提交日志截图，各组员的commit次数
1、提交日志截图
2、各组员的commit次数
由于我的失误，多人提交很容易冲突，最后我们就修改的代码集中起来一起交了，次数和实际有所区别
| 学号 | 姓名 | 次数 |
|---|---|---|
| 221701413 | 龙 | 0 |
| 221701408 | 陈怡 | 6 |
| 221701428 | 木头人超自信 | 1 |
| 041701124 | 12we123asd | 5 |
| 221600233 | 吴江旭 | 0 |
| 221701205 | nd12345 | 3 |
| 221701441 | AIMAN | 0 |
四、程序运行截图
五、程序运行环境
MySQL VS
六、GUI界面
七、基础功能实现
八、遇到的困难及解决方法
221701413：创建仓库的时候没注意ignore，等注意到的时候已经来不及改了，给组员造成困扰非常抱歉。
221701408：commit的时候出现了一些错误，最后解决了，学习到了。
221701428：和队友交流有些错位，学到教训了。
041701124：没学c#真是太亏了。
221600233：找资料用的时间太长了。
221701205：代码不熟练真的很难受。
221701441：
九、评估每位组员的贡献比例
| 学号 | 贡献度 |
|---|---|
| 221701413 | 12 |
| 221701408 | 25 |
| 221701428 | 25 |
| 041701124 | 25 |
| 221600233 | 8 |
| 221701205 | 5 |
| 221701441 | 0 |
十：PSP表格
221701413：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| Estimate | 估计这个任务需要多少时间 | 30 | 40 |
| Development | 开发 | 60 | 120 |
| Analysis | 需求分析 (包括学习新技术) | 120 | 150 |
| Design Spec | 生成设计文档 | 20 | 30 |
| Design Review | 设计复审 | 30 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| Design | 具体设计 | 40 | 60 |
| Coding | 具体编码 | 60 | 60 |
| Code Review | 代码复审 | 20 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 10 |
| Reporting | 报告 | 30 | 20 |
| Test Report | 测试报告 | 20 | 10 |
| Size Measurement | 计算工作量 | 40 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 40 | 20 |
| 合计 | 560 | 580 |
221701408：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| Estimate | 估计这个任务需要多少时间 | 30 | 40 |
| Development | 开发 | 60 | 140 |
| Analysis | 需求分析 (包括学习新技术) | 120 | 150 |
| Design Spec | 生成设计文档 | 20 | 30 |
| Design Review | 设计复审 | 30 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| Design | 具体设计 | 40 | 60 |
| Coding | 具体编码 | 60 | 80 |
| Code Review | 代码复审 | 20 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 10 |
| Reporting | 报告 | 30 | 20 |
| Test Report | 测试报告 | 20 | 10 |
| Size Measurement | 计算工作量 | 40 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 40 | 20 |
| 合计 | 560 | 620 |
221701428：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| Estimate | 估计这个任务需要多少时间 | 30 | 40 |
| Development | 开发 | 60 | 120 |
| Analysis | 需求分析 (包括学习新技术) | 100 | 150 |
| Design Spec | 生成设计文档 | 20 | 30 |
| Design Review | 设计复审 | 30 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| Design | 具体设计 | 40 | 60 |
| Coding | 具体编码 | 60 | 60 |
| Code Review | 代码复审 | 20 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 10 |
| Reporting | 报告 | 30 | 20 |
| Test Report | 测试报告 | 20 | 10 |
| Size Measurement | 计算工作量 | 40 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 40 | 20 |
| 合计 | 540 | 580 |
041701124：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| Estimate | 估计这个任务需要多少时间 | 30 | 40 |
| Development | 开发 | 60 | 120 |
| Analysis | 需求分析 (包括学习新技术) | 120 | 150 |
| Design Spec | 生成设计文档 | 20 | 30 |
| Design Review | 设计复审 | 30 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| Design | 具体设计 | 40 | 60 |
| Coding | 具体编码 | 60 | 60 |
| Code Review | 代码复审 | 20 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 10 |
| Reporting | 报告 | 30 | 20 |
| Test Report | 测试报告 | 20 | 10 |
| Size Measurement | 计算工作量 | 40 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 40 | 20 |
| 合计 | 560 | 580 |
221600233：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| Estimate | 估计这个任务需要多少时间 | 30 | 40 |
| Development | 开发 | 60 | 120 |
| Analysis | 需求分析 (包括学习新技术) | 100 | 120 |
| Design Spec | 生成设计文档 | 20 | 30 |
| Design Review | 设计复审 | 30 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| Design | 具体设计 | 40 | 60 |
| Coding | 具体编码 | 60 | 60 |
| Code Review | 代码复审 | 20 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 10 |
| Reporting | 报告 | 30 | 20 |
| Test Report | 测试报告 | 20 | 10 |
| Size Measurement | 计算工作量 | 40 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 40 | 20 |
| 合计 | 540 | 550 |
221701205：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| Estimate | 估计这个任务需要多少时间 | 30 | 40 |
| Development | 开发 | 60 | 120 |
| Analysis | 需求分析 (包括学习新技术) | 120 | 110 |
| Design Spec | 生成设计文档 | 20 | 30 |
| Design Review | 设计复审 | 30 | 10 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 20 | 10 |
| Design | 具体设计 | 40 | 60 |
| Coding | 具体编码 | 60 | 60 |
| Code Review | 代码复审 | 20 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 20 | 10 |
| Reporting | 报告 | 30 | 20 |
| Test Report | 测试报告 | 20 | 10 |
| Size Measurement | 计算工作量 | 40 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 40 | 20 |
| 合计 | 560 | 540 |
十一、选题答疑
1、1.如何防止被恶意领养，然后被售卖？
需要严格的实名认证，并且需要签署具有法律效力的协议。
团队作业第三次—项目需求分析
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第三次—项目需求分析 |
| 这个作业的目标 | 完成项目分析，制作项目原型和项目需求规格说明书及其演讲ppt |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》、《软件需求规格说明书》国标规范文本 |
一、 团队项目的整体计划安排
1、提出项目（组内讨论确认开发项目）：2月26日-3月6日
2、项目需求分析（完成需求规格说明书）：3月17日-3月27日
3、设计阶段（进行原型设计和数据库设计）：3月23日-4月7日
4、编码阶段（对项目进行具体的程序编写）：4月8日-6月8日
5、测试阶段（对项目进行测试）：6月9日-6月30日
6、上线和维护（将项目上线并进行维护）：7月1日起
二、 组员分工及贡献度
| 学号 | 工作内容 | 贡献度 |
|---|---|---|
| 221701428 | 界面原型设计，部分需求规格说明书，部分博客撰写 | 35% |
| 221701408 | 部分需求规格说明书，需求分析ppt | 15% |
| 041701124 | 部分需求规格说明书 | 10% |
| 221701413 | 部分博客撰写，部分评审表 | 10% |
| 221701205 | 汇报演讲 | 10% |
| 221600233 | 界面原型ppt | 10% |
| 221701441 | 评审表 | 10% |
三、需求规格说明书
1、需求规格说明书
2、 需求规格说明书ppt
四、界面原型设计
1、 界面原型设计
2、 界面原型设计ppt
团队作业第四次—项目系统设计与数据库设计
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第四次—项目系统设计与数据库设计 |
| 这个作业的目标 | 将项目的设计落地，继续完善设计类图，并在正式开始开发之前设计好系统和数据库、制定好计划和分工 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》、作业要求下的参考教程 |
一、 团队项目的整体计划安排
| 日期 | 工作内容 |
|---|---|
| 第一周 | 根据分工学习有关知识，完成数据库的连接与访问和学习搭建基本的前端框架 |
| 第二周 | 搭建基本的前端框架，完成登录和注册相关类和接口 |
| 第三周 | 完善UI，完成消息通知和宠物领养的部分接口 |
| 第四周 | 继续完善UI，完成宠物领养部分的接口 |
| 第五周 | 进行前后的连接和简单的测试 |
| 第六周 | 检测各种情况的输入及运行 |
二、开发计划分工安排
学号 | 工作内容
:---😐:---😐:---:
|221701428 |主导完成后端的架构，连接前后端|
|221701408 |UI设计，后端设计，测试 |
|041701124 |数据库设计，算法设计|
|221701413|UI设计，测试|
|221701205|后端设计 |
|221600233 | 算法设计|
|221701441 |测试 |
三、设计相关
1、体系结构设计
本系统使用MVP和AOP对App进行纵向和横向的切割之后，能够使得App整体的结构更清晰合理，避免局部的代码臃肿，方便开发、测试以及后续的维护。
2、功能模块层次图
本项目的主要功能有账号管理、消息管理、问题提问、领养管理以及帖子管理等多个模块，其中又包含多个子模块，
3、设计类图
4、ER分析
5、表结构设计
- 管理员 （Administrator）
描述 字段名 数据类型 长度
管理员ID AdministratorID int 32
管理员姓名 AdministratorName Char 32
管理员密码 AdministratorPassword Char 32
管理员账号 AdministratorAccount Char 32
管理员邮箱 AdministratorEmail char 32 - 用户 （User_Info）
描述 字段名 数据类型 长度
用户ID UserID int 32
用户姓名 UserName Char 32
用户密码 UserPassword Char 32
用户账号 UserAccount Char 32
用户邮箱 UserEmail char 32
关注人数 UserConcern int 32
3）帖子 （Post）
描述 字段名 数据类型 长度
帖子ID PostID int 32
内容 Content text 1000
用户ID UserID int 32
点赞数 Like int 32
收藏数 Collect int 32
4）评论 （Comment）
描述 字段名 数据类型 长度
评论ID CommentID int 32
内容 Content text 100
帖子ID PostID int 32
点赞数 Like int 32
5）用户收藏 User_collect
描述 字段名 数据类型 长度
收藏ID CollectID int 32
用户ID UserID int 32
帖子ID PostID int 32
6）用户关注 User_concern
关注ID ConcernID int 32
用户ID UserID int 32
帖子ID PostID int 32
6、系统安全
为了满足系统系统对安全管理方面的要求，系统的设计主要满足以下几个安全性设计
·用户信息包括用户登陆信息和密码等数据在传输时加密，保证用户信息安全。
·每个用户都用户自己不同的账号密码，保证账号对应系统内所有信息归个人所有，不存在串号情况。
·不同的身份进入到的社团页面是不同的，例如社员身份进入到的社团页面如下。
7、 权限设计说明
为了满足系统系统对权限方面的要求，系统的设计主要满足以下几个权限设计
·系统中的领养功能需用户拥有一定条件才能领养和购买。
·对于问题提问需明确好内容，不可随意发布问题，否者可能会予以删帖，不对其进行发布。
·对于用户自身发帖也需要满足一定条件才可发布共享帖子，避免帖子杂乱，质量过于低下。
四、回答问题
1、关注的帖子等是类吗？
是的，之后会把这些做成类。
2、如何在海量帖子中找到我关注的帖子？
制作一个用户收藏夹，收藏帖子。
3、一个帖子被多人关注该如何表示？
数据库收藏表一个用户ID，一个帖子id,一个收藏id记录每个用户收藏的第几个帖子
五、 本次作业组员分工及贡献度
| 学号 | 工作内容 | 贡献度 |
|---|---|---|
| 221701428 | 系统设计说明书 | 20 |
| 221701408 | E-R图和数据库ppt | 18 |
| 041701124 | 数据库设计说明书 | 18 |
| 221701413 | 部分系统设计说明书，博客撰写，部分评审表 | 17 |
| 221701205 | 汇报演讲 | 15 |
| 221600233 | 系统设计说明书ppt | 10 |
| 221701441 | 评审表 | 2 |
六、作业文档
1、github仓库
2、系统设计说明书
3、 系统设计说明书ppt
3、 数据库设计说明书
3、 数据库设计说明书ppt
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一、代码规范和冲刺计划
二、十天冲刺
day1
day2
day3
day4
day5
day6
day7
day8
day9
day10
三、测试
四、总结
总结
一、代码规范
(一) 命名规约
1.代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
反例： _name / _name / $Object / name / name$ / Object$
2.代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。 注意，即使纯拼音命名方式也要避免采用。
反例： DaZhePromotion [打折] / getPingfenByName() [评分] / int某变量 = 3
正例： alibaba / taobao / youku / hangzhou等国际通用的名称，可视同英文。
3.类名使用UpperCamelCase风格，必须遵从驼峰形式，但以下情形例外：（领域模型的相关命名）DO / BO / DTO / VO等。
正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
4.方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式。
正例： localValue / getHttpMessage() / inputUserId
5.常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
正例： MAX_STOCK_COUNT
反例： MAX_COUNT
6.抽象类命名使用Abstract或Base开头；异常类命名使用Exception结尾；测试类命名以它要测试的类的名称开始，以Test结尾。
7.中括号是数组类型的一部分，数组定义如下：String[] args;
反例：请勿使用String args[]的方式来定义。
8.POJO类中布尔类型的变量，都不要加is，否则部分框架解析会引起序列化错误。
反例：定义为基本数据类型boolean isSuccess；的属性，
它的方法也是isSuccess()，RPC框架在反向解析的时候，“以为”对应的属性名称是success，导致属性获取不到，进而抛出异
常。
9.包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
正例：应用工具类包名为com.alibaba.open.util、类名为MessageUtils（此规则参考spring的框架结构）
10.杜绝完全不规范的缩写，避免望文不知义。
反例： AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成 condi，此类随意缩写严重降低了代码的可阅读性。
(二) 常量定义
1.不允许出现任何魔法值（即未经定义的常量）直接出现在代码中。
反例： String key="Id#taobao_"+tradeId；
cache.put(key, value);
2.long或者Long初始赋值时，必须使用大写的L，不能是小写的l，小写容易跟数字1混淆，造成误解。
说明：Long a = 2l;写的是数字的21，还是Long型的2?
3.不要使用一个常量类维护所有常量，应该按常量功能进行归类，分开维护。如：缓存相关的常量放在类：CacheConsts下；系统配置相关的常量放在类：ConfigConsts下。
说明：大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。
(三) 格式规约
1.大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果是非空代码块则：
左大括号前不换行。
左大括号后换行。
右大括号前换行。
右大括号后还有else等代码则不换行；表示终止右大括号后必须换行。
2.左括号和后一个字符之间不出现空格；同样，右括号和前一个字符之间也不出现空格。详见第5条下方正例提示。
3.if/for/while/switch/do等保留字与左右括号之间都必须加空格。
4.任何运算符左右必须加一个空格。
说明：运算符包括赋值运算符=、逻辑运算符&&、加减乘除符号、三目运行符等。
5.缩进采用4个空格，禁止使用tab字符。
说明：如果使用tab缩进，必须设置1个tab为4个空格。IDEA设置tab为4个空格时，请勿勾选Use tab character；而在eclipse中，必须勾选insert spaces for tabs。
正例：（涉及1-5点）
public static void main(String args[]) {
//缩进4个空格
String say = "hello";
//运算符的左右必须有一个空格
int flag = 0;
//关键词if与括号之间必须有一个空格，括号内的f与左括号，0与右括号不需要空格
if (flag == 0) {
System.out.println(say);
}
//左大括号前加空格且不换行；左大括号后换行
if (flag == 1) {
System.out.println("world");
//右大括号前换行，右大括号后有else，不用换行
} else {
System.out.println("ok");
//在右大括号后直接结束，则必须换行
}
}
6.单行字符数限制不超过 120个，超出需要换行，换行时遵循如下原则：
第二行相对第一行缩进 4个空格，从第三行开始，不再继续缩进，参考示例。
运算符与下文一起换行。
方法调用的点符号与下文一起换行。
在多个参数超长，逗号后进行换行。
在括号前不要换行，见反例。
正例：
StringBuffer sb = new StringBuffer();
//超过120个字符的情况下，换行缩进4个空格，并且方法前的点符号一起换行
sb.append("zi").append("xin")...
.append("huang")...
.append("huang")...
.append("huang");
反例：
StringBuffer sb = new StringBuffer();
//超过120个字符的情况下，不要在括号前换行
sb.append("zi").append("xin")...append
("huang");
//参数很多的方法调用可能超过120个字符，不要在逗号前换行
method(args1, args2, args3, ...
, argsX);
7.方法参数在定义和传入时，多个参数逗号后边必须加空格。
正例：下例中实参的"a",后边必须要有一个空格。
method("a", "b", "c");
8.IDE的text file encoding设置为UTF-8; IDE中文件的换行符使用Unix格式，不要使用windows格式。 9.【推荐】没有必要增加若干空格来使某一行的字符与上一行的相应字符对齐。
正例：
int a = 3;
long b = 4L;
float c = 5F;
StringBuffer sb = new StringBuffer();
说明：增加sb这个变量，如果需要对齐，则给a、b、c都要增加几个空格，在变量比较多的
二、冲刺任务
| 日期 | 完成任务 |
|---|---|
| 4.27 | 首页开发、动态列表页开发、关注列表页开发、文章详情页开发 |
| 4.28 | 首页开发、话题专题页开发、文章详情页开发 |
| 4.29 | 首页开发、话题分类页开发、个人中心页面开发、设置页面开发 |
| 4.30 | 首页开发、话题详情页开发、修改密码页面开发 |
| 5.1 | 首页开发、话题详情页开发、修改邮箱页面开发 |
| 5.2 | 首页开发、消息列表页面开发、编辑资料页面开发 |
| 5.3 | 搜索页开发、我的好友列表页开发、帮助反馈页面开发 |
| 5.4 | 发布表单页面开发、聊天界面开发、页面UI界面 |
| 5.5 | 发布表单页面开发、聊天界面开发、登录页开发 |
| 5.6 | 发布表单页面开发、搜索列表页开发、个人空间开发 |
| 5.7 | 总结、完善和测试 |
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
| :---: | :---: |
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一.每日汇报
| 学号 | 昨日进展 | 存在问题 | 今日安排 |
|---|---|---|---|
| 221701428 | 了解学习接口测试 | 无 | 继续学习postman |
| 221701408 | 环境搭建和创建项目 | 无 | 配置page.json和做图文列表样式 |
| 041701124 | 调试环境配置 | 无 | 导航栏tab导航开发和滑动滚动区域计算.导航列表联动实现以及顶踩操作和上拉加载功能 |
| 221701413 | 调试环境配置 | 无 | 做页面通讯并强化公共列表组件功能 |
| 221701205 | 环境搭建和创建项目 | 无 | 完善详情页关注顶踩功能 |
| 221600233 | 代码规范 | 无 | 了解学习Vue |
| 221701441 | 无 | 无 | 学习 |
二.会议截图
三.燃尽图
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一.每日汇报
| 学号 | 昨日进展 | 存在问题 | 今日安排 |
|---|---|---|---|
| 221701428 | 继续学习postman | 无 | 在本地配置好团队测试环境，继续学习postman测试 |
| 221701408 | 配置page.json和做图文列表样式 | 无 | 封装列表样式组件并制作全局分割线开发 |
| 041701124 | 导航栏tab导航开发和滑动滚动区域计算.导航列表联动实现以及顶踩操作和上拉加载功能 | 无 | 热门分类组件开发并封装热门分类组件 |
| 221701413 | 做页面通讯并强化公共列表组件功能 | 无 | 评论输入框组件封装和评论列表组件开发 |
| 221701205 | 完善详情页关注顶踩功能 | 无 | 分享功能组件开发 |
| 221600233 | 了解学习Vue | 无 | 学习uni-app和vuejs |
| 221701441 | 学习 | 无 | 学习 |
二.会议截图
三.燃尽图
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一.每日汇报
| 学号 | 昨日进展 | 存在问题 | 今日安排 |
|---|---|---|---|
| 221701428 | 在本地配置好团队测试环境，继续学习postman测试 | 无 | 根据已写功能，开始编写 测试程序 |
| 221701408 | 封装列表样式组件并制作全局分割线开发 | 无 | 优化列表组件-动画特效、关注功能和顶踩功能 |
| 041701124 | 热门分类组件开发并封装热门分类组件 | list数组没有修改导致数据调不出来 | 轮播图和搜索框开发、话题列表组件开发并封装话题列表组件 |
| 221701413 | 评论输入框组件封装和评论列表组件开发 | 无 | 个人中心UI构建 |
| 221701205 | 分享功能组件开发 | 无 | 继续分享功能组件开发 |
| 221600233 | 学习uni-app和vuejs | 无 | 编辑博客 |
| 221701441 | 学习 | 无 | 学习 |
二.会议截图
三.燃尽图
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一.每日汇报
| 学号 | 昨日进展 | 存在问题 | 今日安排 |
|---|---|---|---|
| 221701428 | 根据已写功能，开始编写测试程序 | 无 | 继续编写测试程序 |
| 221701408 | 优化列表组件-动画特效、关注功能和顶踩功能 | 无 | 滚动tab导航开发 |
| 041701124 | 轮播图和搜索框开发、话题列表组件开发并封装话题列表组件 | 无 | 话题分类页开发和话题详情页开发 |
| 221701413 | 个人中心UI构建 | 无 | 设置页面开发和修改邮箱页面开发 |
| 221701205 | 分享功能组件开发 | 无 | 修改密码页面开发 |
| 221600233 | 编辑博客 | 无 | 编辑博客并给出参考意见 |
| 221701441 | 学习 | 无 | 学习 |
二.会议截图
三.燃尽图
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一.每日汇报
| 学号 | 昨日进展 | 存在问题 | 今日安排 |
|---|---|---|---|
| 221701428 | 继续编写测试程序 | 无 | 继续编写测试程序 |
| 221701408 | 滚动tab导航开发 | 在涉及到app中的图标时，我们选择的是阿里巴巴矢量图标库，可是我忽然想起来我们并没统一项目的图标，这样在前端开发完成后我们必须重新统一整合各自的图标，同时每个人要修改各自图标代码和icon.css文件 | 上拉加载组件开发和封装，搜索页开发 |
| 041701124 | 话题分类页开发和话题详情页开发 | 无 | 话题详情上拉加载实现和tab选项卡组件开发 |
| 221701413 | 设置页面开发和修改邮箱页面开发 | 无 | showActionSheet接口使用和修改生日功能实现以及三级联动城市选择器使用 |
| 221701205 | 修改密码页面开发 | 无 | 编辑资料UI界面实现和修改头像功能实现 |
| 221600233 | 编辑博客 | 无 | 编辑博客并给出参考意见 |
| 221701441 | 学习 | 无 | 学习 |
二.会议截图
三.燃尽图
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一.每日汇报
| 学号 | 昨日进展 | 存在问题 | 今日安排 |
|---|---|---|---|
| 221701428 | 编写测试程序 | 无 | 学习并编写测试程序 |
| 221701408 | 上拉加载组件开发和封装，搜索页开发 |  |
继续搜索页开发并进行自定义导航栏开发 |
| 041701124 | 话题详情上拉加载实现和tab选项卡组件开发 | 无 | 消息列表组件开发和封装下拉刷新功能实现，下拉弹出层组件使用以及下拉弹出选项完善 |
| 221701413 | showActionSheet接口使用和修改生日功能实现以及三级联动城市选择器使用 | 无 | 登录页UI界面构建 |
| 221701205 | 编辑资料UI界面实现和修改头像功能实现 | 无 | 帮助反馈UI界面实现和关于页面UI界面开发 |
| 221600233 | 编辑博客 | 无 | 编辑博客并给出参考意见 |
| 221701441 | 学习 | 无 | 学习 |
二.会议截图
三.燃尽图
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一.每日汇报
| 学号 | 昨日进展 | 存在问题 | 今日安排 |
|---|---|---|---|
| 221701428 | 编写测试程序 | 无 | 学习并编写测试程序 |
| 221701408 | 搜索页开发并进行自定义导航栏开发 | 无 | 底部操作条组件开发，上传多图功能开发和删除选中图片功能实现 |
| 041701124 | 消息列表组件开发和封装下拉刷新功能实现，下拉弹出层组件使用以及下拉弹出选项完善 | 无 | 好友列表组件开发及封装 |
| 221701413 | 登录页UI界面构建 | 无 | 表单基础功能实现 |
| 221701205 | 帮助反馈UI界面实现和关于页面UI界面开发 | 无 | 登录类型切换效果实现 |
| 221600233 | 编辑博客 | 无 | 编辑博客并给出参考意见 |
| 221701441 | 学习 | 无 | 学习 |
二.会议截图
三.燃尽图
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一.每日汇报
| 学号 | 昨日进展 | 存在问题 | 今日安排 |
|---|---|---|---|
| 221701428 | 编写测试程序 | 无 | 学习并编写测试程序 |
| 221701408 | 底部操作条组件开发，上传多图功能开发和删除选中图片功能实现 | 无 | 保存草稿功能开发 |
| 041701124 | 好友列表组件开发及封装 | 图标库不知道为什么一旦修改，之前的就会全部不能用，导致不能新增图标 | 聊天输入框组件开发 |
| 221701413 | 表单基础功能实现 | 无 | 继续完成表单基础功能实现 |
| 221701205 | 登录类型切换效果实现 | 无 | 第三方登录组件功能实现 |
| 221600233 | 编辑博客 | 无 | 编辑博客并给出参考意见 |
| 221701441 | 学习 | 无 | 学习 |
二.会议截图
三.燃尽图
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一.每日汇报
| 学号 | 昨日进展 | 存在问题 | 今日安排 |
|---|---|---|---|
| 221701428 | 编写测试程序 | 无 | 学习并编写测试程序 |
| 221701408 | 保存草稿功能开发 | 无 | 完善搜索列表功能 |
| 041701124 | 聊天输入框组件开发 | 无 | 聊天列表组件开发及封装 |
| 221701413 | 表单基础功能实现 | 无 | 个人空间头部组件开发 |
| 221701205 | 第三方登录组件功能实现 | 无 | 个人空间UI界面实现 |
| 221600233 | 编辑博客 | 无 | 编辑博客并给出参考意见 |
| 221701441 | 学习 | 无 | 学习 |
二.会议截图
三.燃尽图
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第五次——站立式会议+alpha冲刺 |
| 这个作业的目标 | Alpha冲刺 |
| 作业正文 | 作业正文 |
| 其他参考文献 | 《构建之法》 |
一.每日汇报
| 学号 | 昨日进展 | 存在问题 | 今日安排 |
|---|---|---|---|
| 221701428 | 编写测试程序 | 无 | 学习并编写测试程序 |
| 221701408 | 完善搜索列表功能 | 无 | 检查并完善之前开发的功能 |
| 041701124 | 聊天列表组件开发及封装 | 无 | 完善聊天页功能并检查并完善之前开发的功能 |
| 221701413 | 个人空间头部组件开发 | 无 | 检查并完善之前开发的功能 |
| 221701205 | 个人空间UI界面实现 | 无 | 个人空间操作菜单实现并检查并完善之前开发的功能 |
| 221600233 | 编辑博客 | 无 | 编辑博客并给出参考意见 |
| 221701441 | 学习 | 无 | 学习 |
二.会议截图
三.燃尽图
编码是一个很累的过程，但也是个收获很大的过程。我们组选了两位代表发表对这次冲刺的感言。
余：这次任务我负责一部分的代码，在写打代码的过程中遇到了许多难以理解的错误，比如当我在图标库中增加了图标，并且用新的图标库去替换旧的图标库时，会导致找不到之前的图表使程序无法运行。让我感到我的编程能力还是不足，有许多需要学习的东西。
陈：我的个人总结:我在alpha阶段主要负责的是首页开发，搜索页面的开发，发贴页的开发，并且留下接口以待下一回后端API开发。一连坐了好几天，每天10小时总算按计划完成自己部分的代码，这个项目主要用uni-app这个适合多端开发的技术，以便在微信小程序端，安卓端和ios端推广。第一次接触这个不太熟练，之前也没有vue.js的基础，中途遇到了不少问题也没有人可以询问，不过在付出足够的时间和耐心后依然解决了大多数bug。其实我很担心我们的项目可能无法完成，这次虽然有5位同学参与编码工作，但是编码的任务只平分成了三份，也就是相当于整个项目只有3人在开发，对于一个前端就有十几个页面的大项目而已人真的太少了，而在下一阶段beta冲刺剩下的工作是这个阶段的双倍，(因为我们alpha前期没找到任何开发项目的办法和思路，并且在找到教学视频后分配任务很不顺利，耽搁了很多天才开始)，前后端加起来只有3个人开发怎么做得到呢？所有的api还都需要自己开发的，任务太重了......而且还有两个编程的同学虽然这次分配的任务很少，但是编程过程并不顺利，我们组的代码能力真的太弱了，这阶段现在还不知道其他2位同学的编程工作完成的怎么样了，下阶段我觉得更够呛了。
这一次，我们勉强完成了我们既定的任务，也从中认识到自己的能力与不足。这一次我们收获巨大，在下一次冲刺前我们会成长的，比这一次更进步。
| 组员 | 工作占百分比 |
|---|---|
| 221701428 | 10 |
| 221701408 | 30 |
| 041701124 | 30 |
| 221701413 | 17.5 |
| 221701205 | 2.5 |
| 221600233 | 10 |
| 221701441 | 0 |
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
| :---: | :---: |
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
一、Beta阶段问题总结
二、凡事预则立博客与换组博客
三、Beta冲刺博客
day1
day2
day3
day4
day5
day6
day7
四、用户使用调查报告
五、冲刺总结
六、代码规范和冲刺任务
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
一、设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决问题
该平台面向所有热爱宠物的爱宠人士以及正在初步接触宠物人士提供交流平台，并可为那些可爱无助的流浪宠物寻得他们的新主人
定义
较为清楚
典型用户和典型场景
用户：新手铲屎官
用户需求：第一次养宠物，问遍身边所有人怎么饲养的，但是还是觉得不保险。假设背景：在网上询问有什么app可以有基本的饲养手册，最好有大量相关人士，养宠人士时，网上推荐爱宠云app
用户场景：下载，注册/登录，点击宠物饲养手册，看完又逛了一遍推荐后，回到个人中心，发帖“我有了一只狗(_)，第一次养狗求指导！“
用户：白领
用户需求：家中有猫，今日突然胃口不佳，想询问其他铲屎官有没有类似情况发生假设背景：经询问有闺蜜给她推荐了一个有大量铲屎官聚集的app：爱宠云，里面交流氛围友好。
用户场景：下载app,注册/登录,先进入搜索界面，可能得到结果，若没有进入个人界面创作者中心发帖提问
2、我们达到目标了吗？（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
原计划的功能大概做了一半多，勉强按原计划时间交付，用户数量无。
3、和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
提高了.确定了参与情况，任务分配更加合理，还加入了高质量的伙伴。
4、 用户量,用户对重要功能的接受程度和我们事先的预想一致么?我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
没有用户。
二、计划
1、是否有充足时间来做计划？
是
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
没有什么不同意见
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有，队长管理能力不足，组员能力有限
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有
5. 是否每一项任务都有清楚定义和衡量的交付件?
没有，在beta冲刺中有改进
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
不是，进度没有按预期达成，没有预估到组员的参与度
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
有，但是没有起到太大作用
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
按参与度和能力分配任务，按劳分配。
9、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了团队内部是否有统一的目标和好的指挥是很重要的。再来一边的话从一开始的时候就调节组内氛围，做好奖惩制度，可能会有所改变吧。
三、资源
1. 我们有足够的资源来完成各项任务么?
没有，技术人员严重不足，并且学习热情不是很高。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
根据个人所表现的个人能力和参与度估计的，基本上准确
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
不是很够，有低估。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
可能换个组长会好一些吧
四、设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在项目开发开始之前所有人一起完成的。时间稍晚了一些，由陈怡和余轩鸿完成的需求分析报告，许光清完成的原型设计。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，商讨解决。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
整合前后端的时候，因为代码能力不足，勉强凑齐来之后出现了数据出错，模块运行不起来的情况。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由编写该部分的组员自己复审，要求严格执行。
五、测试/发布
1. 团队是否有一个测试计划？为什么没有？
有，但是完成的不是很理想
2. 是否进行了正式的验收测试？
没有
3. 团队是否有测试工具来帮助测试？
有使用vs帮助测试
- 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
没有进行 - 在发布的过程中发现了哪些意外问题？
数据出错，部分功能无法使用
我们学到了什么? 如果重来一遍, 我们会做什么改进?
学到了测试的重要性
六、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
主动报名，剩余分配，部分是。
2. 团队成员之间有互相帮助么？
有
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
组内商讨投票
七、新组员工作交接
因为新组员的能力很高，并没有让新组员没有交接原组员的工作，而是让他负责了后端部分，在将本组的资料交给他之后，组长和其他组员还积极地发言填补漏缺。
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
一、组长是否重选
组内讨论决定保持不变，不重新选。
二、下一阶段需要改进完善的功能
前端
功能完善
测试bug
三、下一阶段需要新增的功能
前端
完成前后端的接口连接
ui美化
后端
完成各功能和接口
连接前后端
四、需要改进的分工
由于组员能力和参与度的问题，这次任务主要由陈怡，龙颖鑫，余轩鸿，王肃南四人完成，所以我们只能按能分配，王肃南同学负责了大部分的后端，余轩鸿负责剩余部分和部分前端，陈怡负责大部分前端，龙颖鑫负责前端的剩余部分和博客。
四、工作流程的改进
无
五、冲刺计划时间安排
| 计划 | [时间 |
|---|---|
| 技术储备 | 5月15号~5月25号 |
| 组内任务分配和beta冲刺准备 | 5月26号~6月2号 |
| beta编码冲刺阶段 | 6月3号~6月9号 |
| 冲刺收尾查错阶段 | 6月9号~10号 |
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
| :---: | :---: |
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
SCRUM部分:
学号 |今日进度|遇到的困难|明日计划
:---😐:---😐:---😐:---😐:---:
|221701408 |重新整理了首页部分的alpha冲刺代码|出现了scroll-view 组件中不能滚动的问题，在css中加 white-space: nowrap;后解决|着手修改图文列表样式
|041701124 |数据库的搭建|受其他部分的影响数据库搭建不确定，姑且全部建了|着手帮助418完成后端部分
|221701413 |重新整理了搜索页面和发布表单部分的alpha冲刺代码|选择一张图片 返回的时候选择保存草稿 再点进来 删除这个图片 再返回 进来之后图片还在 没有同步缓存 ，可以再子组件中删除照片的时候删除对应的缓存|导航栏tab导航开发
|221701418 |搭建了后台api的环境，并研究了如何搭建适配项目的登录模块|对项目还不够熟悉|搭建登录模块
SCRUM 会议的照片
本日无
PM 报告：
学号 |预计任务量|目前已花费时间|剩余时间
:---😐:---😐:---😐:---😐:---:
|221701408 |40|6|34
|041701124 |45|4|41
|221701413 |55|5|50
|221701418 |60|6|54
燃尽图
每名成员的贡献比
| 学号 | 贡献比 |
|---|---|
| 221701408 | 20 |
| 041701124 | 20 |
| 221701413 | 30 |
| 221701418 | 30 |
| 221701441 | 0 |
| 221701205 | 0 |
| 221600233 | 0 |
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
| :---: | :---: |
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
SCRUM部分:
学号 |今日进度|遇到的困难|明日计划
:---😐:---😐:---😐:---😐:---:
|221701408 |修改了首页的图文列表样式和顶踩功能|let命令使用的不是很熟练|滚动导航
|041701124 |获取手机验证码开发|没有权限，设置成本地的|推出登录api
|221701413 |图片上传功能|传的图裂会开|话题页
|221701418 |账号密码api|进度太慢|测试登录模块，文章分类api
SCRUM 会议的照片
本日无
PM 报告：
学号 |预计任务量|目前已花费时间|剩余时间
:---😐:---😐:---😐:---😐:---:
|221701408 |40|11|29
|041701124 |45|10|35
|221701413 |55|15|40
|221701418 |60|12|48
燃尽图
每名成员的贡献比
| 学号 | 贡献比 |
|---|---|
| 221701408 | 20 |
| 041701124 | 20 |
| 221701413 | 30 |
| 221701418 | 30 |
| 221701441 | 0 |
| 221701205 | 0 |
| 221600233 | 0 |
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
| :---: | :---: |
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
SCRUM部分:
学号 |今日进度|遇到的困难|明日计划
:---😐:---😐:---😐:---😐:---:
|221701408 |滚动导航，关注列表页||消息列表页面
|041701124 |退出登录api|数据表不完善，进行了修改|话题分类api
|221701413 |话题专题页||话题详情页
|221701418 |测试登录模块，文章分类api|注册没处理好|指定分类下的话题列表api
SCRUM 会议的照片
本日无
PM 报告：
学号 |预计任务量|目前已花费时间|剩余时间
:---😐:---😐:---😐:---😐:---:
|221701408 |40|16|24
|041701124 |45|18|27
|221701413 |55|20|35
|221701418 |60|22|38
燃尽图
每名成员的贡献比
| 学号 | 贡献比 |
|---|---|
| 221701408 | 20 |
| 041701124 | 20 |
| 221701413 | 30 |
| 221701418 | 30 |
| 221701441 | 0 |
| 221701205 | 0 |
| 221600233 | 0 |
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
| :---: | :---: |
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
SCRUM部分:
学号 |今日进度|遇到的困难|明日计划
:---😐:---😐:---😐:---😐:---:
|221701408 |消息列表页面，修改密码页面||聊天界面
|041701124 |热门话题api话题分类api||发布文章api
|221701413 |话题专题页，设置页面||我的好友列表页面
|221701418 |指定分类下的话题列表api||指定用户的文章api
SCRUM 会议的照片
本日无
PM 报告：
学号 |预计任务量|目前已花费时间|剩余时间
:---😐:---😐:---😐:---😐:---:
|221701408 |40|25|15
|041701124 |45|27|18
|221701413 |55|35|20
|221701418 |60|36|24
燃尽图
每名成员的贡献比
| 学号 | 贡献比 |
|---|---|
| 221701408 | 20 |
| 041701124 | 20 |
| 221701413 | 30 |
| 221701418 | 30 |
| 221701441 | 0 |
| 221701205 | 0 |
| 221600233 | 0 |
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
| :---: | :---: |
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
SCRUM部分:
学号 |今日进度|遇到的困难|明日计划
:---😐:---😐:---😐:---😐:---:
|221701408 |聊天界面，个人中心页面||文章详情页
|041701124 |发布文章api|发布的时候必须选好标签才能发布|文章详情api
|221701413 |我的好友列表页面||搜索列表页
|221701418 |指定用户的文章api||搜索模块
SCRUM 会议的照片
PM 报告：
学号 |预计任务量|目前已花费时间|剩余时间
:---😐:---😐:---😐:---😐:---:
|221701408 |40|30|10
|041701124 |45|33|12
|221701413 |55|41|14
|221701418 |60|44|16
燃尽图
每名成员的贡献比
| 学号 | 贡献比 |
|---|---|
| 221701408 | 20 |
| 041701124 | 20 |
| 221701413 | 30 |
| 221701418 | 30 |
| 221701441 | 0 |
| 221701205 | 0 |
| 221600233 | 0 |
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
| :---: | :---: |
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
SCRUM部分:
学号 |今日进度|遇到的困难|明日计划
:---😐:---😐:---😐:---😐:---:
|221701408 |文章详情页，编辑资料页面||登录页
|041701124 |文章详情api||用户点赞模块
|221701413 |修改邮箱页面，搜索列表页||个人空间
|221701418 |指定用户的文章api||文章评论模块
SCRUM 会议的照片
PM 报告：
学号 |预计任务量|目前已花费时间|剩余时间
:---😐:---😐:---😐:---😐:---:
|221701408 |40|34|6
|041701124 |45|40|5
|221701413 |55|45|8
|221701418 |60|62|8
燃尽图
每名成员的贡献比
| 学号 | 贡献比 |
|---|---|
| 221701408 | 20 |
| 041701124 | 20 |
| 221701413 | 30 |
| 221701418 | 30 |
| 221701441 | 0 |
| 221701205 | 0 |
| 221600233 | 0 |
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
| :---: | :---: |
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
SCRUM部分:
学号 |今日进度|遇到的困难|明日计划
:---😐:---😐:---😐:---😐:---:
|221701408 |登录页||bug修复
|041701124 |用户点赞模块||聊天模块
|221701413 |个人空间||修改资料模块
|221701418 |文章评论模块||关注粉丝模块
SCRUM 会议的照片
PM 报告：
学号 |预计任务量|目前已花费时间|剩余时间
:---😐:---😐:---😐:---😐:---:
|221701408 |40|40|0
|041701124 |45|45|0
|221701413 |55|55|0
|221701418 |60|60|0
燃尽图
每名成员的贡献比
学号 |贡献比|
:---😐:---😐:---:
|221701408 |20|
|041701124 |20|
|221701413 |30|
|221701418 |30|
| 这个作业属于哪个课程 | 2020 春福大软工实践 W 班 |
|---|---|
| 这个作业要求在哪里 | 团队作业第六次——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | Beta冲刺 |
| 集合随笔 | 集合随笔 |
| 其他参考文献 | 《构建之法》 |
心得体会
| 学号 | 心得体会 |
|---|---|
| 221701408 | 在最后的beta冲刺中虽然只有4个人参与，还好在有能的新大佬加入和较为充裕的时间下，勉强完成了。 |
| 041701124 | 在beta测试中我参与了很多后端的开发，学习了很多新的技术，得到了很多的锻炼。 |
| 221701413 | 在这次任务中我深刻体会到了自己组织能力和编程能力方面的不足，之后会努力锻炼自己的能力。 |
| 221701418 | 这次冲刺是一次很大的挑战，各方面能力都得到了提高。 |
成员贡献比
| 学号 | 贡献比 |
|---|---|
| 221701408 | 20 |
| 041701124 | 20 |
| 221701413 | 30 |
| 221701418 | 30 |
| 221701441 | 0 |
| 221701205 | 0 |
| 221600233 | 0 |
一、设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决问题
该平台面向所有热爱宠物的爱宠人士以及正在初步接触宠物人士提供交流平台，并可为那些可爱无助的流浪宠物寻得他们的新主人
典型用户和典型场景
用户：新手铲屎官
用户需求：第一次养宠物，问遍身边所有人怎么饲养的，但是还是觉得不保险。假设背景：在网上询问有什么app可以有基本的饲养手册，最好有大量相关人士，养宠人士时，网上推荐爱宠云app
用户场景：下载，注册/登录，点击宠物饲养手册，看完又逛了一遍推荐后，回到个人中心，发帖“我有了一只狗(_)，第一次养狗求指导！“
用户：白领
用户需求：家中有猫，今日突然胃口不佳，想询问其他铲屎官有没有类似情况发生假设背景：经询问有闺蜜给她推荐了一个有大量铲屎官聚集的app：爱宠云，里面交流氛围友好。
用户场景：下载app,注册/登录,先进入搜索界面，可能得到结果，若没有进入个人界面创作者中心发帖提问
2、我们达到目标了吗？（原计划的功能做到了几个？ 按照原计划交付时间交付了么？）
原计划的功能做了大半，但还是部分重要功能没有做好，做好的部分也存在一些bug，虽然做了很多但是没有按原计划时间交付，现在仍然有部分功能没有完成，比如登录模块只做了登录部分。勉强按时交付，虽然部分功能没有实现，但是已经能正常使用了。
3、和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
和上个阶段比，软件工程的质量是提高了。在alpha结束后组员有认真得去学习项目有关知识，编程能力有所提高，组员之间的合作也更加默契，让我们在有限的时间里完成了远比alpha阶段多的任务。
4、 用户量,用户对重要功能的接受程度和我们事先的预想一致么？
因为时间不够充裕，没有来得及做这一方面。
5、我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
确实更近了，学习能力、编程能力、合作能力都得到了提升。教训：团队合作中不能只关注个人，团队管理的能力非常重要。改进：在项目最初就做好整个学期的大致的任务计划，定好奖惩制度，并积极思考激励和督促组员完成自己任务的方法，比如线上学习会并实行。，
二、计划
1、和alpha阶段相比，每天是否时间规划的更好?
虽然有了一些提升，但是beta冲刺的任务基本是每天溢出的的工作时间堆出来的，所以很难说更好。
2. 团队在beta阶段是如何解决队友们对于计划的不同意见的？
基本上按照组长的计划实行，有意见的部分进行讨论投票。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的勉强完成，还存在一些功能没有实现，一些bug没有修改。没有做完的部分一部分是技术原因，一部分是时间安排不合理的原因。
4. 是否每一项任务都有清楚定义和衡量的交付件?
有，分配的任务都有清楚定义，交付件都经过了组员的讨论。
5. 项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
组内氛围低落，组员参与度低甚至不参与。这是真的难以预料的，甚至组长都有些自暴自弃，重整之后时间不足人手不足的状况也非常头痛。主要原因应该还是在交流不够上，导致团队凝聚力不足。
6. 在计划中有没有留下缓冲区，缓冲区有作用么?
学习相关知识和项目冲刺阶段都有留下缓冲区，起了很大作用，虽然出现了意外导致项目停摆和人员流失，但是还是完成了大部分的任务。
7、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了合理的计划以及团队内部的交流是非常重要的。如果重来，会想办法增强组内交流，尽力合作。
三、资源
1. 我们有足够的资源来完成各项任务么?
没有，技术人员严重不足，时间也被浪费了很多，导致只能压榨劳动力。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
主要根据功能模块和负责该模块的成员能力综合考虑的，但是仍然存在很大的误差
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
因为alpha只做了前端，所以前端的时间充裕一些，但是也有些紧张，后端的时间就很紧，仍然存在bug。
美工和文案有存在低估，寻找合适的素材和设计需要时间和灵感，完成的不是很满意，编写文案时间很紧张，导致写的非常敷衍。
4. 变更的组员工作如何？如果未变更是否项目完成效率会更高？对于可能的变更是否能制定应急计划?
变更的组员工作非常非常靠谱，主动承担其他人难以完成的任务，积极参与组内讨论，让组内工作进行的比想象的顺利许多。如果未变更的话可能beta冲刺很难达到现在的完成度，甚至可能完成不了。应急计划的话，大概是根据变更组员情况修改beta冲刺的目标。
5、有没有感到某个成员做的事情可以让别人来做（更有效率）?有什么经验教训? 如果历史重来一遍, 你们会做什么改进?
按目前的情况来看，没有。教训老生常谈，交流和行之有效的激励赏罚机制在团队合作中是非常有必要的。重来的话视情况，根据人员提早安排任务。
四、设计/实现
1、项目是否经历重构？为什么需要重构？
前端进行了重构，alpha冲刺做的过于简陋。
2. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
有使用编译程序自带的工具进行了一些测试，在解决一些bug上节省了很多时间。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
整合前后端的时候接口问题比较多，因为和线上发布的时候web存在跨域问题，基本上是编程能力的原因。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
先由编写该部分的组员自己复审，在整合的的时候由整合的组员再次审核，代码规范要求严格执行。
五、测试/发布
1、和alpha阶段相比，测试工作有提高吗？在哪些地方提高了？
有，有进行过大概的测试，修复了很多简单的bug
2. 团队是否有一个测试计划？为什么没有？
有，每个组员先测试自己的模块，然后整合之后再整体的测试。
3. 团队是否有测试工具来帮助测试？
有使用编译程序自带的测试工具
5. 在发布的过程中发现了哪些意外问题？
跨域问题，图片不显示等等。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
测试是非常重要的，再来一遍的话会给测试留够充足的时间。
六、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
根据之前任务的表现和个人意愿决定的吗，部分是。
2. 团队成员之间有互相帮助么？
有，遇到困难的时候主动提出，组员之间相互帮忙寻找问题的解决办法
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
组内商讨投票
七、总结
1、组员们自我总结
见总结博客。
2、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?、
仍然处于一档，只求完成，做的不精。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
仍然处于磨合阶段，虽然有在合作完成项目，但是配合不好。
八、提高软件工程的质量
1、代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
统一规范，多检查。
2、整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
简化一些多余的功能
3、其它软件工具的应用，应该如何提高？
多看教程，多操作，积极交流。
4、项目管理有哪些具体的提高？
任务分配更加合理
5、项目文档的质量如何提高？
统一格式，定时更新
6、对于人的领导和管理， 有什么具体可以改进的地方？
加强组员之间的交流
九、项目展示
见答辩演示
一、代码规范
===========
(一) 命名规约
1.代码中的命名均不能以下划线或美元符号开始，也不能以下划线或美元符号结束。
反例： _name / _name / $Object / name / name$ / Object$
2.代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。
说明：正确的英文拼写和语法可以让阅读者易于理解，避免歧义。 注意，即使纯拼音命名方式也要避免采用。
反例： DaZhePromotion [打折] / getPingfenByName() [评分] / int某变量 = 3
正例： alibaba / taobao / youku / hangzhou等国际通用的名称，可视同英文。
3.类名使用UpperCamelCase风格，必须遵从驼峰形式，但以下情形例外：（领域模型的相关命名）DO / BO / DTO / VO等。
正例：MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例：macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
4.方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式。
正例： localValue / getHttpMessage() / inputUserId
5.常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
正例： MAX_STOCK_COUNT
反例： MAX_COUNT
6.抽象类命名使用Abstract或Base开头；异常类命名使用Exception结尾；测试类命名以它要测试的类的名称开始，以Test结尾。
7.中括号是数组类型的一部分，数组定义如下：String[] args;
反例：请勿使用String args[]的方式来定义。
8.POJO类中布尔类型的变量，都不要加is，否则部分框架解析会引起序列化错误。
反例：定义为基本数据类型boolean isSuccess；的属性，
它的方法也是isSuccess()，RPC框架在反向解析的时候，“以为”对应的属性名称是success，导致属性获取不到，进而抛出异
常。
9.包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
正例：应用工具类包名为com.alibaba.open.util、类名为MessageUtils（此规则参考spring的框架结构）
10.杜绝完全不规范的缩写，避免望文不知义。
反例： AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成 condi，此类随意缩写严重降低了代码的可阅读性。
(二) 常量定义
1.不允许出现任何魔法值（即未经定义的常量）直接出现在代码中。
反例： String key="Id#taobao_"+tradeId；
cache.put(key, value);
2.long或者Long初始赋值时，必须使用大写的L，不能是小写的l，小写容易跟数字1混淆，造成误解。
说明：Long a = 2l;写的是数字的21，还是Long型的2?
3.不要使用一个常量类维护所有常量，应该按常量功能进行归类，分开维护。如：缓存相关的常量放在类：CacheConsts下；系统配置相关的常量放在类：ConfigConsts下。
说明：大而全的常量类，非得使用查找功能才能定位到修改的常量，不利于理解和维护。
(三) 格式规约
1.大括号的使用约定。如果是大括号内为空，则简洁地写成{}即可，不需要换行；如果是非空代码块则：
左大括号前不换行。
左大括号后换行。
右大括号前换行。
右大括号后还有else等代码则不换行；表示终止右大括号后必须换行。
2.左括号和后一个字符之间不出现空格；同样，右括号和前一个字符之间也不出现空格。详见第5条下方正例提示。
3.if/for/while/switch/do等保留字与左右括号之间都必须加空格。
4.任何运算符左右必须加一个空格。
说明：运算符包括赋值运算符=、逻辑运算符&&、加减乘除符号、三目运行符等。
5.缩进采用4个空格，禁止使用tab字符。
说明：如果使用tab缩进，必须设置1个tab为4个空格。IDEA设置tab为4个空格时，请勿勾选Use tab character；而在eclipse中，必须勾选insert spaces for tabs。
正例：（涉及1-5点）
public static void main(String args[]) {
//缩进4个空格
String say = "hello";
//运算符的左右必须有一个空格
int flag = 0;
//关键词if与括号之间必须有一个空格，括号内的f与左括号，0与右括号不需要空格
if (flag == 0) {
System.out.println(say);
}
//左大括号前加空格且不换行；左大括号后换行
if (flag == 1) {
System.out.println("world");
//右大括号前换行，右大括号后有else，不用换行
} else {
System.out.println("ok");
//在右大括号后直接结束，则必须换行
}
}
6.单行字符数限制不超过 120个，超出需要换行，换行时遵循如下原则：
第二行相对第一行缩进 4个空格，从第三行开始，不再继续缩进，参考示例。
运算符与下文一起换行。
方法调用的点符号与下文一起换行。
在多个参数超长，逗号后进行换行。
在括号前不要换行，见反例。
正例：
StringBuffer sb = new StringBuffer();
//超过120个字符的情况下，换行缩进4个空格，并且方法前的点符号一起换行
sb.append("zi").append("xin")...
.append("huang")...
.append("huang")...
.append("huang");
反例：
StringBuffer sb = new StringBuffer();
//超过120个字符的情况下，不要在括号前换行
sb.append("zi").append("xin")...append
("huang");
//参数很多的方法调用可能超过120个字符，不要在逗号前换行
method(args1, args2, args3, ...
, argsX);
7.方法参数在定义和传入时，多个参数逗号后边必须加空格。
正例：下例中实参的"a",后边必须要有一个空格。
method("a", "b", "c");
8.IDE的text file encoding设置为UTF-8; IDE中文件的换行符使用Unix格式，不要使用windows格式。 9.【推荐】没有必要增加若干空格来使某一行的字符与上一行的相应字符对齐。
正例：
int a = 3;
long b = 4L;
float c = 5F;
StringBuffer sb = new StringBuffer();
说明：增加sb这个变量，如果需要对齐，则给a、b、c都要增加几个空格，在变量比较多的
二、冲刺任务
前两天整理alpha代码，熟悉后端建立环境和数据库
3-5完善前端，完成基础后端功能
5-7连接前后端，修正bug，完善剩余功能
新组员本来的工作
负责原组的前端部分
交接之后的安排
因为本组代码基础不太好，虽然新组员在原组负责前端，但是我们安排了他进行后端的工作。
新组员适应情况
因为承接的模块不同，也是新的项目，不过在新组成员的帮助下很好的了解了新项目的需求，能够参与工作。
换组的收获
王肃南（新组员）：在新的组里的任务接受了很大的挑战，但是应该也会有不错的收获。
龙颖鑫（组长）：新来了一名得力的干将，很多迫切的问题都得到了他很大的帮助。
一、前言
爱宠云是一个面向所有热爱宠物的爱宠人士以及正在初步接触宠物人士提供交流平台，并可为那些可爱无助的流浪宠物寻得他们的新主人的平台。
二、调研
因为时间不足没有线上调研，只进行了组内测试，主要问题在于很多部分仍存在bug，但总体功能完成的还算可以。
