团队作业——总结
- 团队成员列表：
| 学号 | 姓名 |
|
201731041215 |
王阳 |
|
201731062302 |
鲜雨珂 |
|
201731062128 |
邓捷 |
|
201731062305 |
周蓉 |
|
201731062131 |
龙继平 |
|
201731062304 |
杨梦欣 |
|
201731035120 |
张欣 |
|
201731062301 |
梅晨 |
王阳 201731041215：
阅读作业博客链接: 博客链接
博客要求内容:
1.Goto语句在大量使用时会使程序结构化设计被破坏甚至极大的影响程序的可读性，可理解性，为何这里又提倡使用呢，为何不能专门写一个异常出口函数来进行呢？
答：并非每种情况都适合goto语句，但是当有多种选择时，若有goto，那么goto是最好的选择，因为他很简便，同时在某种程度上少去了if—else跳转的程序多层嵌套情况，而只需要几个goto，那么可以大大提高程序易读性。
2.那如果对于动态语言/脚本语言（例如 Python等），又该如何呢，编译是自动完成同时采用动态步进，像这种语言编写的模块是直接嵌入然后进行测试还是只进行单步调试过程呢？
答：对于大型的项目，每个模块都必须有相应的单元测试，同时每个模块都必须进行调试以及单元测试，才会进行集成测试。
3.这个基准线到底该如何确定，对于一个大型软件包含上百模块时，采用回归测试，这个基准线该如何去评定呢，而回归测试大多采用自动化方式，不可避免这个测试模块本身也会出现问题，这时候又该如何去处理呢？
答：每个项目的基准线并不是一开始就固定的，而是对于整个项目进程进行动态变化的，而对于测试模块本身的问题，一般项目开发测试与开发是由不同的人进行的，根据采取的测试方法不同，而采用不同标准，并且测试并不是仅仅进行一次，它是会贯穿整个项目，所以尽管测试代码也会有问题，但是对项目测试并不会有太大影响。
4.在需求不断变化的同时如何准确地对客户需求进行分析呢？保持简明的同时如何让整个软件开发流程条理清晰呢？简明的同时应对不断变化的需求，对于文档的改动是否过大呢？采用敏捷流程开发又该如何去适配开发流程呢？
答：敏捷开发就是专门针对与需求不断变化的开发方式，敏捷流程采取每日任务的方式，与需求方一起工作，对于不断更改的需求每日都会有解决方案，敏捷流程并不是一种固定的开发方式，正如其名，它也是不断变化的。
经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的：
经过一学期的学习，学习到了很多软件工程的理论知识，同时对一些理论进行了实践、验证。在这过程中学习了许多工具的使用，如：原型开发工具Axzure，专业画图工具Visio，对源代码管理工具GitHub加深了了解。
有什么深刻的体会，对自己一学期学习过程的总结：
最大的收获是明白了软件工程不仅仅是写代码，甚至可以说写代码只是其中一个很小的环节，重要的是对于整个系统的需求分析，设计，以及小组合作。
鲜雨珂 201731062302
博客要求内容
1.（2.1）对于回归测试的具体内容还不是特别清楚明了，书上说对于“回归测试”中的“回归”，我们可以将其理解为“回归到以前不正常的状态”，这句话应该怎样理解？
答：经过查阅资料，回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试是验证新的代码的确把缺陷改正了，同时验证新的代码没有把模块的现有功能破坏，没有Regression，所以对于“回归测试”中的“回归”，我们可以理解为“回归到以前不正常的状态”。
2.（4.5）对于结对编程，既有好处也有坏处，我们应该在什么情况下采用结对编程的形式来使效率和正确性达到最大化？
答：结对编程最主要的因素是技术与挑战相匹配。如果技能和挑战能互相匹配，最高产的模式就是流模式以及一个更有效的模式指导模式。流模式指的是两个程序员共同从事一个有趣又有挑战性的问题。他们会有不同的技术、遇到不同的挑战，但是它们都善于找到好的解决方法。他们能够结合彼此的脑力、知识及经验来共同处理复杂的任务， 从而创造出最好的解决方案。指导模式则是老练的程序员在解决问题方面有经验和知识，可以与其他不能有效地独自解决问题的程序员分享。后来加入的程序员有足够的理论基础来理解这些解决方法和程序的实现。他会在学习中慢慢进步，成为更优秀的程序员。这两种模式都能提高全队当前与未来任务的生产率。
3.（5.3）TSP的原则第二点为团队的各个成员对团队的目标、角色、产品都有统一的理解，我认为一个团队的成员每个人在开发过程中可能有自己不同的想法，那我们如何做到对这些的统一？
答：每个人都是不同的个体，具有不一样的思想是正常的，对于软件开发过程中每个人的不同想法，我觉得最有效的办法是面对面的交流，很多时候不同的人会有不同的创意和想法，都会给彼此带来很多启发，通过不同人提出自己的意见和建议，队长综合所有人的想法进行考虑来使理解尽可能达到统一。
4.（6.1）敏捷流程的第三步冲刺阶段是时间驱动的，一到时间就结束，那如果在具体的项目实践中，冲刺阶段的任务并没有完成，这个时候应该怎样处理？
答：在这种情况下，冲刺任务不能如期完成已成定局，冲刺阶段的任务没有按时完成的原因可能是计划不够准确，队内成员某些技术方面的问题等等，我认为这时项目经理应该进行组内人员的调整和协作，尽可能弥补。
5.（3.2）软件工程师可能产生如分析麻痹、过早优化等思维误区，那么我们在实际的软件开发中，怎样去避免或者解决这些问题？
答：在这种情况下，软件工程师应该广泛听取团队组员的意见，以及用户的建议，当然最主要的是软件工程师要会意识到这些问题，不要一无所知，有的时候没有意识到自己的问题才是最大的问题。
经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的：
经过一学期的学习，掌握到了很多结构化分析和设计工具的使用，如visio，学习到了github源代码管理工具的具体用法，了解到了用github克隆项目以及提交代码的全过程。同时也学习到单元测试等软件测试方面的技能。
有什么深刻的体会，对自己一学期学习过程的总结：
这学期在软件工程这门课中，我学到了很多，不仅仅是技术方面的接触和学习，更多的是学习到了关于软件开发项目过程的很多方法和技能，让我明白了开发软件并不是简单的写程序，更多的是要做好整个项目的计划、需求分析、设计等，让我能将这些方法运用到以后的项目实践中。
杨梦欣 201731062304
阅读作业博客链接：博客链接
博客要求内容:
- 问题一：
代码复审 4.4
文中提到代码复审有三种形式：自我复审、同伴复审和团队复审。
我的疑问：最好是有经验、熟悉代码的人来复审，而代码作者一定是最熟悉自己代码的，但他自己复审，会有思维的局限性；如果同伴复审，就不存在思维的局限性，那么是选择一个同伴复审，还是两个同伴复审，甚至更多呢？如果是团队复审，最大的局限是效率不高。那么三种方式该如何抉择？
答：经过个人项目、结对编程和团队项目的实践，本人认为主要根据项目的大小来选择代码复审的形式。像个人项目就是自我复审；结对编程就是同伴复审；而团队项目，一般来说，同伴复审就足够了，若是项目比较大，又是特别核心的部分建议团队复审。
- 问题二：
结对编程 4.52
书中举有例子：越野赛车和驾驶飞机，两者共同特点是在高速度中完成任务，任务有较高的技术要求，任务失败的代价很高。
我的疑问是，开发程序时，什么样的情况是类似于文中举的例子，需要进行结对编程？是否有公司实行过结对编程？效果如何？对于合作的两人，是两人水平相当，还是一高一低？有什么特别的具体的要求吗？合作两人的适应期一般是多长时间呢？
答：看了书本，我想应该是时间紧张的情况下需要结对编程。确实有公司进行过结对编程，如Microsoft(Bill Gates, Paul Allen),Apple(Steve Jobs, Steve Wozniak),Yahoo(Jerry Yang, David Filo),Google(Sergei Brin, Lawrence Page)，效果都不错。对于两人的水平没有什么要求。他们的适应期需要经历四个阶段：萌芽——磨合——规范——创造。最重要的是如何磨合：向同伴提供容易接受的反馈意见时，采用三明治法。
- 问题三：
与顾客合作 7.2.9
文中提到MSF强调产品团队与顾客的交流合作，因为“我觉得”和“用户觉得”是两码事。
我的疑问：那么遇到哪种类型的问题需要与顾客交流？大概多久进行一次呢？若是交流时遇到“对牛弹琴”的情况该如何处理、如何交流？
答：本人认为遇到业务领域的问题，需要与顾客多次且深度交流。交流频率主要视实际情况而定。若交流有障碍，可以进行一些调查方法：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写等，再设计出原型图与顾客沟通交流。
- 问题四：
目标、估计和决心 8.6.1
文中提到如果我们混淆了目标估计和决心，那就会犯错。其中软件时间的估计是多个估计值的乘除法(估计的需求、估计的复杂度等等)。
我的疑问：那么，究竟每一项估计该怎么估计才比较准确呢？
答：上课时老师有提到项目做多了，自然而然就估计误差就越小。每一项的估计还是得看经验吧。
参考文章：https://blog.csdn.net/qiansg123/article/details/80130444
- 问题五：
PM做开发测试外的所有事情 9.3
文中提到微软公司有好几类PM，以及一名优秀的PM应有的能力。
我的疑问：无论是哪一类PM，是都必须要拥有文中所列举的那些能力吗？还是说负责内容不同，有不一样的要求？
答：书本中提到三类PM，分别是：Product Manager（产品经理），Project Manager（项目经理），Program Manager（微软的职位名称）。成为 一个合格的PM必须要拥有以下能力观察、理解和快速学习能力；分析管理能力；一定的专业能力。因此对于负责内容不同的PM，他们需必备的专业能力是不同的。
总结:
经过本次课程的学习及项目实践，了解了软件工程的原理，确确实实体验了一次软件开发。最大的收获不是在课堂上学习的，也不是最终答辩所展现的，而在于整个软件开发过程所经历的，学习到的知识。
邓捷 201731062128
阅读作业博客链接: 博客链接
博客要求内容:
1、第七章第二节：其中提到的MSF基本原则中有一条是“充分授权和信任”，但我们如何保证在给予了充分授权和信任的情况下，团队成员能够按时按质的完成自己的任务，不敷衍了事？
团队项目是团队成员的共同责任，不仅需要队员的自觉性，队友在项目完成过程中也应该相互监督相互提醒。
2、第十四章第二节：讲到测试人员，假如开发人员每个人都对自己的代码进行了初步的测试，并且有些公司的人后期也会使用本公司的产品，使用过程中也会逐步发现一些BUG，那么在这些情况下测试人员的作用会不会逐步的降低甚至变得可有可无？
不会，测试是软件编码过程中的重要一环，也是软件质量的重要保障，测试人员系统的测试更能发现一些开发人员自身没有发现的问题，对软件的完善有很大的推动作用
3、第八章第三节：说到对用户需求的获取，提到了调查问卷的方法，但现实是大部分的调查问卷都并没有得到用户足够的重视，或者有些用户即使认真回答了也不一定能够得到调查人员的正确理解，或是提出的意见并没有足够的价值，在这种情况下怎样保证了解到的需求是有意义的？
除了最开始对用户调研，开发人员在软件开发过程中也应该经常与用户沟通，在软件每完成一部分的时候
4、第八章第六节：提到软件工程师对实际花费时间的预估公式，但如何保证自己对事件的估计时间在合理范围内，如果低估了时间又该怎样弥补？
这个主要应该靠开发人员自己的经验积累，低估了时间就只能想办法拉快进度
5、第十三章：怎样识别软件的故障是内部问题还是外部问题？
一般是先软后硬的原则。重新分区，低格所有分区后用标准系统安装盘重装系统，如果故障依旧，那基本是硬件问题了。
个人收获：
认识到在项目完成中文档与类图，用例图，时序图的重要性，软件项目不是一个人的事情，更多的是团队的交流协作。
周蓉 201731062305
阅读作业博客链接: 博客链接
博客要求内容:
对于问题一：当初以为程序正确，如果加上正确后面的程序，是不会出错的。在团队合作中，本人体会到队长在合成我们的各个模块的时候，后面新建的模块如果出了问题同样会影响前面的功能，逻辑，物理结构，特别是传参数的时候，一但新构建的模块出了问题，它的输出，中止都会影响后续的模块，以前模块功能的正常使用。回归测试可以找出退化的软件（有了新模块，可能功能崩了）的错误，改进软件。这也是
软件测试的目的是为了发现错误而执行程序的过程；测试是为了证明程序有错，而不是证明程序无错（发现错误不是唯一的目的）
对于问题二：这个问题，本人想结合下在面向对象课程中一些体会，线下调查已有软件满足了用户什么需求，用户体验或者说别人想让软件工程师实现什么。而在需求分析中，我们构建的任何想法，其实都是建立在人类需要，既有需求的目的去开展的。
作为制作软件的成员，在最初就用该对使用用户有个定位，事实上我们对它应该完成了可行性分析，那么在调查问卷问题设置上就是有方向的，通过定位人群去找到有效反馈。
需求获取主要方法：文档“考古”法，用户代表访谈法，问卷调查法，运营数据分析法，同类方案研究法，虚拟用户构想法
对于问题三：得知，产品经理就是通过了解用户需求去设计原型给软件工程师实现，那么正确的获取需求，我想在以后工作中才能得到解答（如果有机会的话，考虑的前进方向中了）。
对于问题四：创新，本人对于它的理解有了新的体会，用户体验其实也是“新”的东西，同类型的软件，胜出的地方就在它给用户带来的感觉，just like QQ and TIM，后者就更为简洁，这也是创新呀。技术的创新，在原有的技术上实现算法，或者结构上的改变，使得更为简单。
对于问题五：在团队项目中，本人是贡献最少的吧，队长分配“网络编程”模块给我，但是我最终也没完成，回首过来，我才是“抱大腿的人”。我想团队合作中，团队意识最重要吧，有荣与焉，大家都在学新东西，菜鸡也是要有团队荣誉感的，当然也有关队长的分配了。
总结：
解答完自己的问题，回到“无力”，“愧疚”，“羡慕”这三个词语，是我在本课程的体会。在结对编程中，我是参与其中，本人十分感谢队友在他的博客中给我留足了面子，在我在为某个版块费劲头脑的时候，队友已经完成功能，而最终我完成的模块，却成为败笔，多余的，我是很受打击的。在项目中，我忘不掉，我跑去图书馆一层，打着手机灯在书库里面找网络编程书的过程，当时我心里的愧疚已经战胜我惧怕黑的感受了。连续几周都在看网络编程，连做梦都是。哭过，因为“无力”。在项目展示中，我"羡慕"那些优秀的同学，因为我一无是处。
很可惜的是，临了了，我仍旧没有找到自己的专业方向，可我真的很想在互联网专业从事一些工作啊。本人逻辑思维真的很差，编程对于我来说，或许准确的来说算法，平常人一两遍就能弄好，我可能要十遍，写上很多页纸才能弄懂。
掌握的技能：自学，专注，需求分析能力。新的问题：如何在团队中起到作用？
最后很感谢在团队合作中队友们对我的帮助和鼓励。
龙继平 201731062131
阅读作业博客链接: 博客链接
博客要求内容:
问题一：在瀑布模型中十分强调文档的作用，那么在其他开发的过程中是否也需要严格编写文档？还有文档的作用是否过于夸大，我也听说过，过于详细的文档不如没有，那么文档要多仔细为好？怎么样把握度量？
我的理解：我在这门课程的过程中开始理解文档的重要性。老师不断给我们强调文档的重要性。一个好的项目80%的时间是在设计文档。20%的时间用于把文档实现为代码。在大型项目时，文档是必须的，文档也是越详细越有条理符合规范为好。在个人小项目时，可以省略部分文档，只写重要的设计部分文档。
问题二：在这一节提到“我们要在竞争性的环境中实践软件工程，那就要做实用求创新的项目”，那么在需求分析的时候，是以创新为主还是稳定为主？如何处理需求与创新之间的矛盾？如何能够使需求合理化，符合软件设计要求？
我的理解：需求分析时以稳定为主，我们的目标是设计符合客户要求的软件，所以第一要素是满足客户需求，其次再是创新。需求设计要实事求是，不要天马行空。
问题三：在开发过程中不同程序员的进度不一，如果程序员更新错了代码会不会导致程序崩溃?那么在管理源代码过程中会不会出现版本冲突呐？在版本冲突的时候如何回退前一个版本？回退过后开发进度会不会跟不上任务要求？
我的理解：源代码的管理一般是由svn的版本管理工具管理的。使用十分方便可以实现代码的对比，然后在上传，也能够实现版本回退。
问题四:在进行效能测试时，往往都会测试不过全面，有时候也不能够达到测试的条件，在这种情况下如何测试？怎样才能使效能测试更加全面，高效？
我的理解：效能测试要涉及测试代码的每一个方面，尽量的做到测试全面，测试也应该覆盖每一个条件的分支，并得到想要的结果，才能测试全面。
问题五：这里介绍了软件的各个版本，beta也就是我们常说的尝鲜版，通常尝鲜版会有各种bug这个版本的发布会不会影响用户体验？其次各个版本之间如何有效的辨别？
我的理解：beta版本基本可以正常使用，beta版本测试是为了提高测试的效果，能够有更多的额人员参与软件的使用，从而发现问题修改问题。其次beta版本也是经过了一定的测试阶段，基本不影响正常使用，有的只是微小的bug，也可能是为了软件开发的新功能，来获取用户的反馈，从而更好的开发软件。
总结：
我学会了UML绘制类图，用例图，时序图。在团队项目的开发过程中，我开始认识到文档和沟通的重要性，我在这门课最大的收获就是开始正视文档，明白了软件工程这个专业不仅仅是技术，而我们更多的是学会去写文档，然后实现为相应的软件。
张欣 201731035120
阅读作业博客链接: 博客链接
博客要求内容:
问题一：
在教材中第二章个人技术和流程中，所讲到的单元测试，是对软件项目中的每一个小的模块进行test，是对后面工作的正确性的保证，同时也是之后的单元测试的基础，其中提到的代码的“覆盖率”，当时学C语言时有头文件，当写一个函数时，需要到头文件的那个文件夹中区寻找相同的功能代码，覆盖并运行，不知道我这种理解是不是正确。
答:所谓实践出真知，真正的去实践过后，才能更加深入的去理解自己的疑问，经过课程的各次实践，自己明白了覆盖率到底是怎么回事情，但是就像我知道了1+1=2一样，但是依然不知道为哦什么1+1为什么就是等于2一样，不知道在到底是怎么样编译器可以知道已经对代码路径实行了覆盖。
问题二：
在学软件工程的课程的同时，我们也在学数学建模的课程，在数学建模的课程上，老师讲了一个寻找临界点的问题，当时大多数同学都回答，找几个临界点的值，进行带入计算测试，而老师说，这个就是我们在接受软件工程教育是固有的思维模式，我在想这种思维模式是经过多年的思维习惯之后形成，会不会被困于这种思维模式跳不出了。
答:每个人都有自己在经过多年的事和物的磨练之后所形成的固有的思维模式，在一般情况下，却是是无法跳出自己的这种思维模式，但是在以后能经历更多的事之后，每个人的能力以及想法也都会发生变化，能否跳出来，也算是自己的一种能力。
问题三：
1.在压力测试中，沿着时间轴延长，一般模拟48小时的高负载才能认为系统通过测试，在如何模拟，是对其中的数据进行调用模拟还是，寻找真正的用户进行模拟；如若没有通过测试，系统崩溃之后，我们应该采取什么样的措施来补救？
答:在这个问题中。由于在项目的开发中自己并没有负责这一部分，所以也没有更深入的去针对这个问题进行求证，自己将在以后的学习生活当中，对这个问题进行实践并且求证。
2.同样也是test的问题，是在教材中第十三章软件测试中所讲的A/BTest，其中用了奥巴马竞选的例子来说明，A/BTest是同时为用户提供多种服务，还是随机测试，或者在给用户提供服务之前，让用户进行选择，自己想要的服务。尽量在测试的时候讲损失降到最低。
答:不论是做事还是做人都要敢于去做出尝试,才能有更好的发展,而做软件应该也不会例外.
问题四：
在课上讲的是在可以在开发代码完成之前，先写好测试代码，而在教材中的第十三章中讲到，开发时有开发说明书，测试同时也是有测试设计说明书的，其中要是有些功能还没有做好，不知道功能的具体情况，而时间有很紧急，这时候要如何去做开发代码的测试？
答:这个问题由于学姐的解答，以及自己在之后作业中的自己的理解摸索，代码测试的情况主要还是是项目的情况来确定，并不是一定要按照先代码后测试的顺序，而在现阶段，我只经历过先代码，后写代码测试的模式，希望以后能尝试进行先写测试代码的开发模式。
问题五：
在第三章软件工程师的成长中，在对项目完成估计的时间上，有些可能是比较常写的代码，但总是会用到不常用，或者是要去新学的知识，如何能更准确的去估计自己完成时间？
答:一般来说边学边做项目相对来说是不是很理想的，但是由于个人自身的限制只能用这种方式，会大大的拖慢团队的开发速度，所以一定你要在平时多积累知识，必要时候一定会用得上的。
问题六：
如何确保自己已经完成的代码在签入时和别人的代码能够很好的对接起来，由于对团队开发流程的不了解，在这一部分上，还是有很多的不明白。
答:这个问题依旧没有明白.
总结：
- 是否产生了新的问题？请提出。
有出现一些问题,但是在项目过程中,经过同学朋友的指点,已经解决.
- 经过这学期的学习，你掌握到了哪些以前没有的技能，你是如何掌握的。
经过这学期的学习,个人能力有了一定的提高,但是很不满意,没有很努力的去学习接纳更多更好的知识;上学期只是简单的运用VS编写简单的程序,这学期对VS有了更加深入的了解;接触并了解了代码的测试方面的知识;高尔基说书籍是人类进步的阶梯是很对的,从书籍中,我获得了许多以前不知道的知识.
- 有什么深刻的体会，对自己一学期学习过程的总结。
相对于上一学期,我对这学期的表现更加满意,但是仍然有很大的进步空间,希望自己能更加努力,越努力的人真的会更加美丽.
梅晨 201731062301
阅读作业博客链接: 博客链接
博客要求内容:
1、过早优化的问题在于：过早关注不重要的部分，而忽略行动和目标本身。让正确的程序更快比让快速的程序正确要容易很多，所以，首先应该把注意力放在使代码尽可能性的清楚和可读上，何时进行优化应该根据软件开发过程中的实际情况来决定。
2、结对编程是两个程序员用一台电脑，一起工作。两个人一个人是驾驶员的身份，另一个人是领航员的身份，对两个人并没有什么特别的要求，但是在结对的过程中还是需要相互磨合达到比较理想的效果，我觉得结对编程需要思考是如何将领航员的职能发挥到最大。两人合作是一种合作关系，相互帮助。
3、软件团队的模式选择我觉得跟软件项目本身和软件团队能力有着不可分的关系，可以结合项目本身和团队本身情况来选择一种合适的团队模式，合适的团队模式在整个软件开发的活动过程中会比较容易解决问题，按时完成项目。
4、思维局限我觉得是可能会出现的吧，肯定需要有专门的测试人员对整个软件进行测试，这时候其实也包含了对代码的检测，使得软件的出错率更少。
5、https://blog.csdn.net/wang_lichun/article/details/7267948
总结：
经过一学期的学习以及相关书籍的阅读，对于开始不懂的问题有了一些解答，在课程作业的完成过程中，体会到了结对编程的好处，在编写代码有错误出现时，会有人及时提醒，在设计代码的时候，可以一起讨论，融合两人不同的见解和观点，得出更加好的设计思路，会避免一个人深陷BUG之中。在整个的团队项目当中，也学习到了一些新的知识，同时深深感觉到自己编程能力的欠缺，但是也有不少收获，更加了解了软件开发过程，学会了一些软件开发过程中必要的技能。
团队项目Github地址：<链接>
