大佬教程收集整理的这篇文章主要介绍了承前启后 继往开来 -- 软件工程实践总结，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
| 这个作业属于哪个课程 | 2021春软件工程实践|W班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 1.回顾自己列出的5到10个问题：尝试解答、继续分析、提出新问题 2.5个阶段中，每个阶段收获最大的知识或能力是什么？ 3.结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解 4.个人技术博客 |
寒假作业二
关于如何有效的结对编程，才能在兼顾效率的同时，避免进入匆忙编程的误区的问题。 再次回看了现代软件工程讲义3结对编程和两人合作这篇文章,我对结对编程有了更深的体会，优秀的结对编程需要双方前期做好深入的专研，形成自己的理解，避免牵制于繁琐的、耗时的操作上结对编程；同时，双方需要在专研后进行一个较长的交流，交换一下两个人的想法，并对即将完成的任务有一个大致的规划；在结对编程的过程中，最好能按期相互讨论，这样既不会影响双方的开发进度，也能让双方保持高度联系，对项目的整体进展有一个清晰地认识，而不会没有计划，截止前匆忙编程。 结合自己与结对队友的结合经历，我认为结对编程是一个可取的、高效的方法。如讲义中提到的，结对编程中的团队角色有如领航员和驾驶员。领航员（Navigator）起到领航、提醒的作用。驾驶员（Driver）是控制键盘输入的人。在结对编程中，结对双方会不断地复审对方的代码，交流开发过程中遇到的问题，具有更强的工作能力，是一种高效的互相督促，相互学习，相互磨合编程方式。
无人认领，难度较高的任务应该如何分配 结合自己的alpha/beta阶段和小组成员的冲刺经历。我的理解是，首先，任务需要被细致的分配，分配至比较小的量级，我们小组在冲刺的过程中主要是以功能点进行划分；后端的同学根据实现接口的数量和难易度进行划分，前端同学根据设计页面的复杂性和页面数量进行分配，最好的分配方式当然是，一位后端同学能够和一名前端同学进行对接，这样的好处是有点类似组内小型的结对编程，双方可以进行更深的交流；但我当然也不否认一名同学应对多名同学的方式，这种方式比较复杂，但是能够有效的避免人事变动，但因为我们本次项目比较小，所以采取的分配方式比较简单。 随后再谈谈无人认领的问题，本次我们小组没有出现这种情况，不过我想简单的分析一下。(1)需要保证每个小的任务任务量相差不大，同时要确定每个组员要认领的任务数量。（2）对于无法细分的且难度较高的任务可以设置任务难度等级。（3）可以将任务与贡献度进行挂钩，这样也能更好地评价组员的贡献。（4）对于实在有难度的任务，无人认领的情况下，小组长可以分配给组内能力较强的成员，但应该充分考虑每个成员的任务量，控制好项目的进度，对于能力较弱却领了较难任务的组员，组长应该更 紧密的关注，确保项目的进度，并对突发情况进行任务调整。
对于用户调研，我当时截取了邹欣老师关于中学生学习英语软件的用户调研的问题。我现在的想法是，中学生，家长，老师，这三个用户在我看来都没有问题。需求分析的时候需对这三种用户按照一定权重来接受他们的需求，就我自己的理解而言，学生作为这款软件的最终用户，软件需要满足学生的基本使用需求，在我看来这是必须实现的。在此基础上，开发团队发现了家长和老师这两个影响因素，应该在基础上继续分析他们的需求，选择他们的主要需求，尽可能的满足，对软件进行改进，这样在我看来才是比较完善的调研用户选择。确定主要用户，发现潜在的影响的用户。
简单的问卷收集不到全面的结果，复杂的问卷可能连问卷都收集不到，或是草草敷衍。 结合自己的alpha/beta阶段和小组成员的冲刺经历。我们小组普遍采取的方式是
团队合作中源代码的管理方式不易控制，特别是在处理文件的锁定问题上。 结合自己的alpha/beta阶段和小组成员的冲刺经历。我们小组管理代码的方式使用github对整个项目代码进行管理，在总的项目工程文件下方创建前端和后端两个代码文件夹。github在代码版本的管理上我认为是非常到位的，完全不会存在我想象的冲突无法解决的问题。我对它的理解是，在开始一日工作计划前先将昨日上传的代码进行更新(pull),如果存在冲突后，可以在编辑工具中选择合并或者进行选择。在上传文件(commit）阶段如果有组员更新需要先pull下最新的代码并进行合并。我认为除非操作失误，否则比较不可能出现覆盖他人代码的情况，就算覆盖了也可以根据提交记录进行回退。
负责工作：需求讨论、原型讨论、原型设计评审表制作、原型设计答辩、需求分析答辩。 在本阶段，我参与了小组关于"Fidle"小程序项目的需求分析讨论，我们将目标用户定位为福州大学在校学生，确定了在校大学生关于二手物品，任务委托，活动信息发布的需求，并且参考用户调查问卷相关文章设计了适用于我们小程序的用户调查问卷，用以明细用户更为具体的需求和未被我们小组成员发现的潜在需求。并最终对结果进行汇总，形成我们小程序功能点分析的参考。 本阶段我掌握了如何进行需求分析的技能，参与小组讨论，特别加强了在原型设计，类图，用例图的设计能力；学会了如何分析一个项目的可用性，发展前景；以及如何面对我们的目标用户，如何倾听目标用户的需求。
负责工作：参与小组讨论、PPT宣讲及答辩、学习新技术 在本阶段，我参与了小组关于"Fidle"小程序项目的数据库设计和系统设计的讨论，参与了功能模块层次图，ER分析图、拓扑图、设计用例图、设计类图、数据流图，向后端同学学习了解系统安全和权限设计，其中包括注入问题、权限问题、会话被窃取问题、数据库问题、密码加密问题，这些都是我之前只有简单了解的。 通过结合一个项目，将以前学习的知识点进行整合并运用，在准备答辩的过程中，我发现不理解可能存在错误的设计就会与相关设计的同学进行"讨论"，他们可能一觉睡起发现收到了我一堆消息攻击，但是彼此学习，互帮互助让我们在设计阶段的答辩收获了满意的成绩。
负责工作： alpha阶段：发布页、二手修改页、任务修改页、活动修改页界面结构和样式，发布页逻辑；二手修改页、任务修改页、活动修改页部分逻辑 beta阶段：后台首页和相关逻辑、完善α不足 本次开发阶段，我收获最大的就是实战经验了，实现了从几乎0到质的飞跃。和小组成员一起从基础，一个个看视频，模仿开始，在alpha阶段学习了微信开发者工具的使用，和交互逻辑函数，在beta阶段学习了vue框架和axios实现后台首页页面和逻辑，内心非常满足。我也认识到了万事开头难，随着不断地练习，不断地尝试，我渐渐收获了信心，自己制作的东西得到了认可，可以和组员一起完成制作，而不是划划水，不负责任，过程虽艰辛，但是都是成功的见证。
负责工作：对自己负责的界面按照需求说明书进行测试，验证无误。 测试阶段给我最大的体会就是，没有一件事情是一蹴而就，我们需要回顾，重新检查，对自己开发的软件进行测试，发现其中潜在的问题，或者是设计不合理的地方。同时，测试也不单单只有自己验证，可以请其他组员或者甚至是用户对自己的验证过的功能进行再次的黑盒测试，一切都是为了更加完善我们的软件，发现自己学习上的漏洞。
因为权限未被审核通过的原因，我们小组的项目未被成功发布，但是我们通过体验版收集了用户调查反馈，我们对于用户的反馈进行分析，收获了他们对于我们软件的认可和宝贵的意见，就比如我们之前没有意识到初次进入小程序时应该提示输入手机号等联系方式，否则在真正发布任务时接收者获取不到联系人信息。我渐渐理解到一个软件为何需要不断的维护，为了更加明确用户的需求，为了给用户更好地体验，才能笼络客户，将软件成功的经营下去。
在个人项目中，我阅读了《构建之法》，在上软件工程这门课之前对软件工程有了初步的了解，也提出了自己的问题，在随后的作业中，我学会了使用了PSP表格对自己待完成的事情制定计划，并且完成了wordCount程序，这个程序我的答案并不是正确的，但是我也认识到了自己的测试工作并没有做到位，需要在开发工作完成后针对预期结果设计有效的合理的、较为全面的测试用例，从中发现自己程序的漏洞，才不会吃扣分的亏。
在结对编程过程中，我第一次感受到了两个人协同开发，相互合作的过程。我们会互相讨论作业的要求，如何完成作业，并且共同解决开发过程中遇到的问题，做到较为合理的分工。这次体验让我从软件工程课本上对于结对编程的理解应用到了实际生活中，感受到了1+1>2的工作能力，也为后续在团队项目的合作过程中打下基础。
在本次团队项目中，我常常自嘲一句话，叫做“答辩大满贯”，"厚颜无耻"的和大家讨要"三连"，因为我担当了小组项目的所有答辩工作，当然我也有每次提前做好准备，检查ppt内小组成员汇报工作的正确性，及时与相关同学联系修正，希望能够将组内完成的情况，真实地，完美的展现在老师同学们的眼前，不辜负小组成员辛勤的付出，同时，我也希望我们小组的问题能够被暴露出来，得到老师和同学们的指正，因为这是我们上升的台阶。除了答辩工作，我在小组的项目开发过程中收获了从学到做，将微信小程序的开发技术和vue框架以及element-ui和vant组件库都简单应用了一遍，在完成任务后感受到了自己的价值！
微信开发者工具的使用总结
以上是大佬教程为你收集整理的承前启后 继往开来 -- 软件工程实践总结全部内容，希望文章能够帮你解决承前启后 继往开来 -- 软件工程实践总结所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。