高级软件工程2017第7次作业--团队项目:Beta阶段综合报告
Deadline:2017-11-06(周一) 21:00pm
0、评分规则:##
按时交 - 有分,内容包括以下5个方面:
- Beta阶段敏捷冲刺每日报告 - 30分
- Beta版本测试报告 - 30分
- Beta版本发布说明 - 10分
- Beta展示博客 - 20分
- Beta阶段总结报告 - 20分
- Beta阶段项目复审 - 20分
注意事项:
- 晚交 - 0分
- 迟交两周以上 - 倒扣本次作业分数
- 抄袭 - 倒扣本次作业分数
1、Beta阶段敏捷冲刺每日报告 (30分)##
经过紧张的Alpha阶段,很多组已经从完全不熟悉语言和环境,到现在能够实现初步的功能。下一阶段即将加快编码进度,完成系统功能、强化软件工程的体会。
-
凡事预则立,在Beta开始前,以小组为单位,在敏捷冲刺前(11月1日 周三)发布一篇博客,描述 (5分):
- 下一阶段需要改进完善的功能,如果要大规模改变设计,请看DCR 的内容
- 下一阶段新增的功能
- 需要改进的团队分工(针对之前的不足,需要加强和改进团队协作和分工的地方)
- 需要改进的工具流程(如版本控制、测试工具等),alpha 阶段用纸和笔做燃尽图的,必须升级到使用软件工具管理燃尽图。
- 冲刺的时间计划安排(冲刺时间为期5天,安排在2017.11.2——2017.11.6之间)
参考
- 设计变更(DCR):参考课本第15章有关内容
- http://www.cnblogs.com/yc-chen/p/6129224.html
-
Beta阶段的冲刺时间为期5天,安排在2017.11.2——2017.11.6之间。
安排连续5天的敏捷冲刺。每天举行站立式会议,讨论项目每个成员的昨天进展、存在问题、今天安排。团队在冲刺的5天内,每天发布一篇随笔( 每篇5分):-
每个人的工作:
(1) 昨天已完成的工作
(2) 今天计划完成的工作
(3) 工作中遇到的困难
(4) 每个人的贡献比
-
选用合适的工具制作并发布项目燃尽图
-
每人的代码/文档签入记录
(1) 不能每天都在 “研讨”, 但是没有代码签入。
(2) 签入记录对应的Issue内容与链接,代码必须每天可执行。
(3) 必要的code review,编码规范不是摆设,文档要随时更新。
-
适当的项目程序/模块的最新(运行)截图。
-
参考
- Scrum/sprint http://www.cnblogs.com/xinz/archive/2012/10/05/2712602.html
- 每日例会(scrum meeting)报告。(例子)
- 敏捷项目协作工具 https://www.leangoo.com/
- 如何使用Leangoo自动生成燃尽图 http://www.scrumcn.com/agile/scrum/8569.html
2、Beta版本测试报告 (30分)##
请根据团队项目中软件的需求文档、功能说明、系统设计和Beta阶段的计划安排,写出软件的测试过程和测试结果,并回答下述问题。
-
在测试过程中总共发现了多少bug?每个类别的bug分别为多少个?
bug的分类:- 修复的bug;
- 不能重现的bug
- 这个产品就是这样设计的,不是bug;
- 没有能力修复,将来也不打算修复;
- 这个bug的确应该修复,但是没有时间在这个版本修复,延迟到下一个版本修复。
-
场景测试(scenario testing),包括以下内容:
- 你预期不同的用户会怎样使用你的软件?
- 他们有什么需求和目标?
- 你的软件提供的功能怎么组合起来满足他们的需要?
-
根据不同项目的特点,进行必要的性能测试、压力测试等,并给出测试的过程和结果
-
你们在什么样的平台、硬件配置、浏览器类型等条件上对你们的软件进行测试?——测试矩阵(test matrix)
-
你认为你们团队的软件在什么条件下,就可以认定其已经足够好,可以发布Beta版本?——出口条件(exit criteria)
参考:
- 测试的计划及执行: http://www.cnblogs.com/xinz/archive/2011/11/19/2255542.html
- 测试报告实例:http://www.cnblogs.com/buaase/p/5094119.html
3、版本发布说明 (10分)##
软件发布的同时,在团队博客上写一个发布说明
- 列出这一版本相对于Alpha版本的新功能
- 列出这一版本对Alpha版本修复的缺陷
- 对运行环境的要求
- 安装方法
- 描述系统已知的问题和限制
- 说明软件的发布方式以及发布地址
对于功能的描述除了文字以外,可以通过图片、视频等进行辅助说明。
参考
- Beta版本发布说明的实例:http://www.cnblogs.com/buaase/p/5094106.html
3、Beta版本展示博客 (20分)##
-
团队成员的简介和个人博客地址,团队的源码仓库地址。
-
我们要做软件工程,那就要有一点工程的样子:
-
团队项目的目标,预期的典型用户,预期的功能描述,预期的用户数量在哪里?
-
beta 发布之后一定会比alpha 阶段更能满足用户的需求, 请录一段视频, 展现目标用户使用 beta 产品的情况。
-
团队的成员如何分工协作的?有什么经验教训?
-
团队是如何进行项目管理的?
-
团队如何平衡 时间/质量/资源 争取如期完成任务的?
-
beta 阶段每个团队在软件工程方面有哪些具体改进?(例如 代码测试覆盖率从 x 提高到 y),也要列出来。
-
-
团队项目的实际进展(拷贝那些 scrum 过程中的燃尽图即可),发布的功能(拷贝发布文档)。说明在项目管理中,scrum的燃尽图是如何真实反映项目的状态的?或者燃尽图美化了状态?
- 展示建议:把beta阶段每天的会议图片, 燃尽图分别做出一个 GIF 动画, 放在最后的报告中,显示工作的进展。
- 也可以采取其他方式
-
到了beta, 代码的情况也请列出来, 到底有多少行, 多少文件, 文档在哪里,如果一个新团队要接手这个项目,他们应该怎么做? 这有说明么?
-
团队可以用视频显示, 如何在一个全新的电脑上,下载所有代码,构建,发布,并运行你们的程序。
5、Beta阶段总结分析报告 (20分)##
请各小组在Deadline之前,召开事后诸葛亮会议,发布一篇事后分析报告。
总结的提纲内容,请参照课本15章内容或邹欣老师的博客:
-
项目管理之事后诸葛亮会议:http://www.cnblogs.com/xinz/archive/2011/11/20/2256310.html
-
博客要附上全组讨论的照片。
团队成员在Beta阶段的角色和具体贡献:
名字 | 角色 | 团队贡献分 | 可验证的贡献 |
---|---|---|---|
马小哥 | PM | 推广活动 | |
Phone | Dev | 多少注释 | |
Pipe | Test | 被修复了 |
6、Beta阶段项目复审 (20分) ( 该部分截止时间:11月13日 21:00 pm )##
每个复审人看本班级其余团队的总结展示博客,以及代码质量,实际测试结果, 决定名次(没有并列),说明项目的优点和缺点分析(不少于 140 字)
(注: 因为需要等其他团队发布Beta阶段完整信息,该部分内容可以等到11月13日和个人作业一起提交)
- 谁来做复审人:可以每个团队选一个本团队的代表,或者团队成员一起开评审会讨论决定
- 团队博客列出团队的排名(没有并列),和对这些团队的点评(不包括本团队)
- 复审看什么:
- 软件的质量:解决原计划解决的问题了么,软件运行质量如何?用户有多少,用户反馈如何?
- 软件工程的质量:代码在哪里? 代码能在新的机器上构建成功么? 代码可维护性如何?每日构建有么?
- 项目如何管理的?燃尽图反映真实状态么?老师和助教的点评有回答或改进么?
- 复审怎么做:
- 通过看博客和代码,博客评论交流的方式平均并排名次。 大家都是学过软件工程,做过项目的人了,评论要有点专业性,不能光谈感性认识 (这个小组做的App 看起来还可以...), 而是要点评这个产品和软件工程相关的地方,书上提到下面的公式:
- 软件 = 程序 + 软件工程
- 软件(的质量) = 程序(的质量)+ 软件工程(的质量)
- 我们要好好测试一下程序的质量,给出明确的,定量的评定。同时我们要观察这个小组软件工程的质量(通过他们的每日例会,燃尽图,以及其它博客)点评他们项目的目标实现了么?项目的风险是如何应对的?找到用户的痛点并解决了么? 对主要和次要的需求是如何取舍的?如果换成我来领导这个小组,我会做什么不一样的事情?
- 通过看博客和代码,博客评论交流的方式平均并排名次。 大家都是学过软件工程,做过项目的人了,评论要有点专业性,不能光谈感性认识 (这个小组做的App 看起来还可以...), 而是要点评这个产品和软件工程相关的地方,书上提到下面的公式:
小组的名字和链接 | 优点 | 缺点,bug报告(至少140字) | 最终名次(无并列) |
---|---|---|---|
team1 | ...... | 程序有什么具体的bug? 项目的目标实现了么? 项目的风险是如何应对的? 找到用户的痛点并解决了么? 对主要和次要的需求是如何取舍的? 源代码管理如何? 如果换成我来领导这个小组,我会做什么不一样的事情? ...... |
|
team2 | ...... | ...... |