实验十 团队作业7：团队项目用户验收与beta冲刺

项目	内容
课程班级博客链接	课程班级
这个作业要求链接	作业链接
团队名称	鲤鱼跃龙门
团队成员分工描述	任务一：王亚涛 任务二：Beta冲刺一刘兴瑞；Beta冲刺二张潇潇；Beta冲刺三王亚涛；Beta冲刺四王方 任务三：项目总结ppt刘兴瑞；测试报告王方，燃尽图王亚涛；博客撰写：刘兴瑞，张潇潇，王亚涛
团队的课程学习目标	（1）将学习的敏捷软件开发过程在实际的工程中实践； （2）掌握软件黑盒测试技术； （3）掌握软件项目确认测试内容，学会编制软件项目总结PPT。
这个作业在哪些方面帮助团队实现学习目标	1.通过基础测试方法学习和测试进行两个部分促使我们了解了软件测试的工程要求 2.通过4天冲刺督促了我们，帮助我们任务分解和规划 3.团队测试让我们学会了如何测试代码有很大的帮助
团队博客链接	团队博客
团队项目Github仓库地址链接	仓库链接

任务一

• 按团队项目互评名单，对互评方《实验七 项目需求分析建模与系统设计（1）》的项目成果进行评价，具体要求如下：
  （1）阅读互评团队项目博文作业并进行评论，评论要点包括：博文结构、博文内容、任务分工与时间耗费。将以上评论内容发布到互评团队博客评论区。
  （2）下载并阅读互评方团队项目资料。

结对方团队博客链接
结对方Github项目仓库链接

符合（1）要求的博客评论：

项目	点评
博文结构	博主的博文风格清新，结构清晰明了，观看者体验感不错，但是看起来排版美观不足，图片文字大小不太匹配。
博文内容	团队成员分工明确，各个任务需要的文档都准备的非常完善，博文内容完成，文档内容充分。
任务分工与时间耗费	各项任务都已完成且任务实际完成时间与理想时间相比有所延迟。完成任务时结合了老师上课时所讲的课堂知识，任务完成度较高，值得我们借鉴与学习

评价如图：

互评团队作业评分成绩：150分

任务2

• 团队作业Beta冲刺：团队项目经过Alpha阶段冲刺后，已基本完成项目编码工作。进入Beta阶段冲刺后，需要开发者对软件进行用户使用体验或典型用户应用场景测试并完善功能，此时常用黑盒测试技术完成测试工作。请根据团队项目中软件的需求分析文档、需求规格说明书和软件设计说明书，编写软件用户功能测试方案，并执行测试过程，在日期区间[6.25-6.30]内，任选连续4天进行Beta冲刺，冲刺当天晚23点前发布一篇团队Beta冲刺博客。

Beta 冲刺Scrum meeting导航如下：

日期	博客链接
6.27	【Beta】Scrum meeting 1链接
6.28	【Beta】Scrum meeting 2链接
6.29	【Beta】Scrum meeting 3链接
6.30	【Beta】Scrum meeting 4链接

软件的功能测试方案文档提交如图：

任务三

• 完善与整理团队项目资料、编制团队项目总结陈述PPT、录制视频演示软件需求规格说明书中要求功能，在团队项目Github仓库中上传以上两个文档。
  

任务4

1.完成《实验十 团队作业6：团队项目编码与Alpha冲刺》团队博文作业

• 已完成

2.提供任务2要求在团队项目仓库中上传测试文档/测试活动视频后的3个截图（3分）

• 见任务二

3.【软件验收测试Beta冲刺总结】结合燃尽图陈述任务1执行过程；（5分）

• 燃尽图在Beta冲刺阶段有具体体现，在任务一的执行过程中首先我们经过讨论商定由王方同学对博客内容进行查看和评价总结，我带领其他三位成员对github上提交内容进行测试检查，并与对方团队成员取得联系，解决了在评价过程中遇到的问题，最后，在团队讨论中由成员汇报检查情况，集体讨论商议最后的评价和得分。

4.提供任务3要求团队项目github仓库中上传项目总结陈述PPT、软件功能演示视频文档后的2个截图；（2分）

• 见任务三

5.记录完成《实验十 团队作业7：团队项目用户验收&Beta冲刺》各项任务实际花费的时间和分工（4分）；

| 任务 | 时间（天） |
| ---- | ---- | ---- |
|任务一 | 1 |
| 任务二 | 4 |
| 任务三 | 2 |

• 具体分工见表一

6.每位成员总结本次实验心得，最后由项目组长进行总结陈述。（合计10分，缺少1人扣3分）；

成员	实验心得
刘兴瑞	本次软件工程的团队项目的设计与实现基本完成。由于是第一次按照软件开发流程进行软件的设计与实现，在整个过程中也出现了很多的问题。这整个过程不仅仅是一个软件的开发，其中还有设计到很多的东西，比如团队之间的合作，沟通，磨合等，都需要每个成员之间的配合；另外团队组长对项目任务的合理分工也很重要，要根据每个成员的实际能力进行合理的分工，确保项目的顺利进行和完成。在这个项目中，从开始的项目确定、项目立项、开始计划项目、整体方向讨论、制定计划、项目开始制作实施到项目的完成，这其中涉及到了个人的思维能力、团队的协作能力和实践能力等。在这个过程中，我学到了很多。明白了团队的重要性，了解到团队项目的每一个步骤都需要团队中每一个人共同的参与配合。这种合作精神值得运用到学生的各个领域。
王亚涛	在这次Beta冲刺阶段中，主要是对项目进行黑盒测试，在理论课上学习的黑盒测试技术将在这次实验中进行，四天的时间，从一开始的只了解理论知识，到后面的熟悉整个测试过程，这是一个很充实的实验经历。每一天的任务都积极去完成对每个模块的测试，发现Bug之后一起想方设法去找到错误的地方，修复Bug，这个过程重复四天下来，不光是测试的具体过程，还有积累了修复常见Bug的经验。虽然每天的工作都很紧张，但是团队的每个人都在努力，完成起来也就轻松了许多。
王方	本次实验我的任务分工是进行系统测试，觉得对一个完成的系统进行测试这一步骤是非常有必要的，会及时的发现系统中存在的漏洞或不足，在交付给用户前可以加以改进，提高系统性能；还有就是要对每一次的测试过程做详细的记录，以便于总结经验；最后是测试用例的选择问题也是非常重要的，要全面，精准的发现更多的系统运行过程中逻辑问题。
张潇潇	通过本次实验，我们将学习的关于测试的相关内容运用在了实际的软件开发的过程中，执行了整个的敏捷开发流程。在本次实验中，我负责了各功能模块的测试，同时完成了测试文档。用过此次实验，我体会到了测试的重要性，仅仅进行编码阶段的程序依然存在很多的问题，要通过测试人员的不断测试发现程序的问题，及时与开发人员沟通，及时解决问题，带给用户好的体验感。小组的成员们也能根据自己每天的任务安排，按时地完成当天任务，当有问题时大家也能及时沟通、有效地解决问题。
总结	这次项目之后，我觉得一个人尤其大学生要养成总结与反思的习惯，并有意识地提炼日常工作成果。这次开发主要用的是Java，在一种语言上编程，但别为其束缚了思想。深入一门语言开发还远远不足，任何编程语言的存在都有其自身的理由，所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。

7.每位成员陈述课程学习总结，回顾《实验一软件工程准备》提出的3个问题，并总结答案。（合计15分，缺少1人扣5分）；

成员	学习总结	问题	答案
刘兴瑞	本次软件工程项目的设计与开发，学习到了很多技术和知识。首先是对工程项目思维的训练，从刚开始的项目推进中我发现盲目进行代码堆砌对项目的开发没有太大的帮助，反而会在后期造成很多困扰，所以要及时与团队成员进行沟通，完善设计框架和目标，尤其是与各模块的负责人，对接口提前约定，保持开发进度和开发功能点的统一，及时对接以发现问题，其次就是作为团队的一员，一定要按时完成任务，不拖团队后腿。从团队角度来看，合理的分工、合适的项目组织与流程规划都是成功项目的关键，一个项目的开发不是靠单纯的个人能力就能够驾驭的，根据不同的项目类型进行合理的开发过程规划是非常关键的，在开发的过程中，小组的团队配合要好，项目进度和质量也会比较好的。同时学到了很多软件工程开发的实质性知识，而且对于以前不敢面对的编程也慢慢入手去做，学到了很多相关领域的知识，提高了自己的整体水平。	问题一：软件行业赖以生存的“软件”, 程序员用来安生立命的“程序” 是什么?问题二：开发一个项目时，如何组建一个软件团队，怎么选择“合适” 的团队模式?问题三：我们要做实用并且创新的项目，那么我们怎么提出新的创意, 怎么说服别人我的创意是靠谱的?	问题一：程序，在这里指的是源程序，就是一行一行的代码。仔细看过去，它们的确是建立在数据结构上的一些算法。光有代码还是不行的，这些一行一行的代码不会自己运行，得有人编译成机器能懂的目标代码，而编译不仅仅是 cc 和 link 命令， 对于一个复杂的软件，我们要用各种文件来描述各个程序文件之间的依赖关系，编译参数，链接参数，等等。这些都是软件的构建。问题二：充分利用现有的知识积累；（2）建立一个产品平台,为后期的开发提供便利；（3）提高开发速度；（4）尽量降低成本；软件团队的模式有主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐模式、爵士乐模式、功能团队模式、官僚模式。我比较倾向于交响乐模式和功能团队模式。交响乐模式的主要特点是门类齐全，各司其职，有共同方向的。其优点是在开发过程中分工明确，大家可以术业有专攻，效率比较高。缺点是适用于某歌软件领域处于稳定成长的阶段，如果是在刚开始的时候可能会产生分歧。功能团队模式的主要特点是：人人平等，没有管理与被管理的关系。优点是小组间交流比较频繁，不同能力的人可以平等协作共同完成一个功能并且完成一个工作后可以再和别人完成另外的工作，效率较高。缺点是：要适应别人的编程规范。问题三：进行头脑风暴，在头脑风暴的时候需要记住几点:自由畅谈:关于主题，不受任何限制，让思维联想发散，尽可能的提出不同视角的想法。禁止评论:对别人提出的任何想法都不能称赞或批评，同时也不允许自我批判。这会影响团队的其他同伴。追求数量:头脑风暴会议的目标是获得尽可能多的设想，追求数量是它的首要任务。在一定基础的量上，去寻找优质想法。二次联想:在他人的想法上再次进行联想，来提出新的设想。
王亚涛	从之前的软件需求、软件设计、再到后来的软件测试，每一个环节都是在软件开发过程中必不可少的，也知道了每个环节的重要性，更知道了团队合作的重要性。在此次的测试过程中，明白了之前所做的所有工作对之后测试的重要性，之前所做的工作只为更好的为后面的工作做铺垫，测试的目的就是寻找新的bug，为软件质量再次给了保证。在这个过程中我们反反复复，一次又一次寻找新的漏洞，每当解决一个新的问题，满满的成就感，让我们每个人都有新的动力和信心，也许这就是努力。在这个过程中我们一起合作，让我真正体会到团队合作的力量，也让我明白了测试对于一个好的软件的重要性。	1、在通读了《现代软件工程——构建之法》这本书以后，我对软件工程的重要性有所了解，那么我们所学的专业计算机科学与技术与这门课程软件!工程之间有什么区别与联系？它们各自有什么优点或不足？二者未来会朝着怎样的方向发展？2、在《现代软件工程——构建之法》这本书中提到软件工程是消灭bug的过程，一个软件bug越少，它就越好，那么在开发过程中这个“足够好到可以发布”的程度应该怎么判断？3、在《现代软件工程——构建之法》这本书中第三章谈到了软件工程师与普通程序员的对比，如何才能成为一名合格的软件工程师？在这个过程中我们可以做什么怎么做？	问题一：软件工程专业是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言，数据库，软件开发工具，系统平台，标准，设计模式等方面，因此要求学生在学习过程中一定要学精学通，不能只了解皮毛。计算机科学与技术类专业毕业生的职业发展路线基本上有两条路线：一是纯技术路线，二是由技术转型为管理的路线。软件工程专业就为方向与前景本专业毕业生的就业市场前景广阔，主要毕业去向是计算机软件专业公司﹑信息咨询公司﹑以及金融等其它独资、合资企业等。计算机科学与技术专业就业方向与前景：短期内社会需求仍然很大，计算机专业毕业生的就业市场前景广阔。毕业生毕业后就业领域较多，如从事网络工程领域的设计、维护、教育培训等工作或者是到国内外众多软件企业、国家机关以及各个大、中型企、事业单位的信息技术部门、教育部门等单位从事软件工程领域的技术开发、教学、科研及管理等工作等等。问题二：一，良好的编程能力。编程能力直接决定了项目开发的效率。二，自觉的规范意识和团队精神。随着软件项目规模越来越大，仅仅依靠个人力量已经无法完成工作，因此，现代软件企业越来越重视团队精神。三，认识和运用数据库的能力。信息以数据为中心，因此与数据库的交互是必不可少的，了解数据库的操作和编程是软件工程师需要具备的基本素质之—。四，较强的英语阅读和写作能力。五，具有软件工程的概念。基础软件工程师从事的工作相对于系统分析师和高级程序员要单纯一些,但是他们仍然是整个软件工程中重要的一环，他们同样需要具有软件工程的概念:从项目需求分析开始到安装调试完毕，基础软件工程师都必须能清楚地理解和把握这些过程，并能胜任各种环节的具体工作。问题三：什么是好软件？其实就是软件没有缺陷。而软件工程，其实就是将软件中的Bug消灭掉的过程。Bug的多少可以直接衡量一个软件的开发效率、用户满意度、可靠性和可维护性。用户满意度：用户在使用时发现了软件的很多问题，影响了用户使用软件的效率。可靠性：某个软件经常会崩溃，某个操作系统会时不时的死机，某个网站往往在最需要的时候登录不上去。软件流程的质量：软件团队和开发流程的问题太多，导致团队成员无法互相协作，按时交付软件。这也可以说是软件团队的Bug可维护性：某个软件太难维护了，按下葫芦起了瓢，修复了一个问题，另一个问题又出来了。也没有足够的文档，维护人员表示需要更多的时间和资金来维护这个软甲，甚至建议推到重写。
王方	通过本次团队项目的设计实现，我对所学的知识有了进一步的理解与掌握，认识到了课本所学知识与实际应用的差异。只有通过具体项目的实践，才能更好的掌握所学知识，并针对具体的问题灵活的变通处理。此外，我深刻认识到一个项目的实现最重要的是需求分析而不是代码的实现。只有合理的分析设计，代码实现的过程中才不会遇到问题。这期间学习到了HTML网页的一些基本语法和编写方法，UML用例图的绘制，软件工程开发的一些基本工具的使用，软件开发文档编写的方法和实践，人机交互应用程序开发时人机界面的设计，人机对话的实现，人性化的界面设计等。本次项目设计也使认识到了团队协作的重要性，一个人的能力毕竟是有限的，而大家的力量无穷的。在这个期间，也体会到了大家同心协力去做一件事的快乐。通过本次项目设计，我深知道自己相关专业知识掌握的还很不够，也发现了学习和实践中的不足。软件工程中需求分析的不充分，软件开发方法的不恰当这些都是需要以后改进和学习的，软件开发中的各种文档编写能力还需要提升，在以后学习和实践中认真总结和完善，参考他人的软件工程项目，体会优秀软件工程的思想。在做任何事情的时候都要有觉得是站在巨人的肩上，而不是重复的生产车轮的思想来做事情，要对别人的经验教训加以总结，学习、参考和引用别人的先进研究成果，要有重视团队协作以及虚心学习的精神。	问题一：软件共享和开源的本质区别是什么，什么情况下软件可以共享或开源？问题二：什么是软件工程？问题三：软件工程经济和我们这节课之间的联系或者区别是什么?	问题一：共享软件是以“先使用后付费”的方式销售的享有版权的软件。根据共享软件作者的授权，用户可以从各种渠道免费得到它的拷贝，也可以自由传播它。用户总是可以先使用或试用共享软件，认为满意后再向作者付费；如果你认为它不值得你花钱买，可以停止使用。开源软件，英文表示是open source software，简称为OSS，直接的字面意思是公开源代码的软件。软件既然连源代码都公开，因此开源软件具备可以免费使用和公布源代码的主要特征。问题二：什么是软件工程？通过本学期的学习，使我更加了解了软件工程。软件工程是对一个项目从立项到结项的所有过程，主要包括需求调研与分析，项目概要设计，项目详细设计，项目实现，项目测试，项目维护等过程。本学期我们主要就是围绕这些步骤展开学习。问题三：软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。在现代社会中，软件应用于多个方面。典型的软件有电子邮件、嵌入式系统、人机界面、公套件、操作系统、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，也提高了工作效率和生活效率。软件工程(Software Engineering，简称为SE)是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言，数据库，软件开发工具，系统平台，标准，设计模式等方面。
张潇潇	通过软件工程这门课的学习，我认识到了自己的许多不足。在以前编写程序时总是一味的写，没有对整个程序系统的分析与设计或者说很少有对这些内容的分析设计，至于设计文档之类的内容更是没有编写过，这也使得以前在写软件程序时时常会想到一些比目前更好的方法或设计，又将许多写出来的内容推导重做，这增加了许多的工作量，也使得写出来的程序不够稳定。在这一门课程的学习中，我了解了事前的分析与设计工作的重要性，也了解了编写相关的分析、设计文档的必要性，这使得我在之后的软件项目中能够少走许多弯路。同时通过这一门课的学习，我对团队协作有了新的认识，也理解了团队协作的重要性，同时也学习到了正确的团队协作应该如何进行，这对我们之后的团队项目很有帮助。除了在理论课程中学习到了许多新的理念与技术以外，在这一门课程的项目实训中，我也积累了许多有用的经验与方法，这些都会为我以后的学习与软件开发提供帮助。总的来说，我在这一门课程的学习收获很大，希望通过这些收获，我在未来的学习与编程中能够越做越好。	;问题一：阅读了《现代软件工程—构建之法》第四章4.5节后，我看了这一段文字：“有效率的结对编程不是一天就能做到的。结对编程是一个相互学习、相互磨合的渐进过程。开发人员需要时间来适应这种新的开发模式。”我有这样一个问题：“如果两个实力都很强的人组队结对编程，当他们有分歧的时候，该如何解决？如果课堂上老师随机结对编程，一强一弱的两位同学被分到一组，这个水平较弱的同学会不会跟着划水，而失去结对编程的意义？”问题二：通过阅读本书第七章设计与开发后，我看了这一段文字：“ 不让用户犯简单的错误”，那么”我通过查阅资料发现就定义上来说有四个小的方法。但是我还是不太懂，我的困惑是：测试时具体应该怎么做呢？问题三：阅读了《现代软件工程—构建之法》第四章的软件过程/方法论之后，我看了这一段文字：“敏捷 (Agile) 是一股思潮, 它包括了好几种软件开发的方法论 (methodology); 这些方法论又是建立在许多业界证明行之有效的最佳实践方法 (best practices) 上面的。”我有这个问题：敏捷 (Agile)可以使用的范围是什么呢？我查了资料，有这些说法:“敏捷（Agile）是一套原则和价值观，而非具体的工作形式（Scrum、XP、kanban）”。 但是我还是不太懂，我的困惑是：敏捷 (Agile)既然是一种方法论，那么谁可以使用它，使用时有什么要求呢？	答：在结对编程的过程中，分歧是经常会有的。面对分歧时，双方都应该先仔细听取对方的观点，然后用平静和尊重对方的语气阐述自己的观点。这时侯，最忌讳 的就是盲目自信。你要试着从对方的角度看待问题，这会让你发现自己遗漏了的地方。不要把这变成一场谁对谁错的争斗，你也没必要在每次辩论时都成为获胜的那 一方。如果双方实在没有办法达成一致的观点，那就试着找别的同事帮忙做个选择。很自然的，有时一个人比另一个人对任务了解的更深入。这有可能造成两个人的节奏不同步，以至不愉快的经历。如果你了解的更多，你要及时意识到这一 点，控制你的节奏，让你的同伴跟上。必要时，停下你手头的工作，好好解释一下。同样，如果你是跟不上趟的那个人，要及时提出来。让你的同伴慢下来，好好跟 你解释他／她到底在做什么，以及为什么这么做。记住，沟通是必须的。 答：（1）给予用户适当的行为约束——为用户封闭掉不正确的道路；（2）给予用户必要的预判性错误提示——告诉用户，这样走可能会错；（3）告诉用户操作所处的状态和正确的操作方式——告诉用户，怎么走才对；答：敏捷方法论其实是一个技巧问题，也是特定学科的方法、过程和规则。但是敏捷的价值观和原则显然告诉我们，要避免规定任何特定的方法或程序。也就是说敏捷没有指定的方法，也不是一种方法论，这也许会令许多人出乎意料，但如果真的花时间去看，在敏捷价值及原则中，确实找不到任何方法论。相反，我们会找到关于如何选择，最适合团队协作的方法。而所有方法的底线是，测试人员，开发人员及其他人员都必须不断提高自己，以拥抱敏捷的工作方式。敏捷价值观和原则，并不会规定团队的工作方式，反而会协助团队，以可行的方式进行思考。敏捷是团队不断适应的能力，也是持续改进工作方式的能力。虽然敏捷不是方法论，但团队可以使用一些方法论来遵循敏捷的价值和原则。以Scrum为例，Scrum采用了高度迭代的方法，着重于在每次冲刺之前定义关键特性和目标。它旨在降低风险，同时快速提供价值。Scrum为团队的工作，指定了一些特定的仪式感，其中包括：举行每日站立会议、固定长度的Sprint周期、产品展示会以及回顾会议等。许多团队发现Scrum是遵循敏捷价值和原则的一种好方法，它提供了一个强大的方法论来协助大家遵循敏捷。还有人说Scrum是一个框架，因此会比方法论更加灵活，但是两者之间的界限相当模糊，只有细微的差别。极限编程是在软件开发中，会遇到的另一种方法论，它包括测试驱动开发以及结对编程等。极限编程方法论可以为团队，带来一些可用于遵循敏捷价值及原则的方法及过程。例如敏捷原则，团队应该利用变更来作为竞争优势，XP的做法提供了促成这项原则的软件撰写方法，那为什么人们仍然认为敏捷是一套方法论呢？这通常是因为他们混淆了敏捷的价值原则和大家用以遵循这些原则的方法及方法论。如果团队真的想要遵循敏捷价值及原则，方法论就要随着团队的成长不断调整，与时俱进。毕竟，这才是敏捷的真正意义。