天行健，君子以自强不息

221900221_沈建伟学生 2022-06-26 22:44:09

这个作业属于哪个课程	2022年福大-软件工程;软件工程实践-W班
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	课程回顾与总结&个人技术总结
其他参考资料	见博客末尾

1. 课程回顾与总结
1.1 回顾问题
Q1:商业价值与开源精神是否矛盾？
Q2:对于一名工程师而言，究竟应该是更”专“一点好，还是更”广“一点好呢？
Q3:项目/任务的大小应当由什么指标来决定？
Q4:顾客真的知道他们想要什么吗？
Q5:低层次的问题能依赖工具解决么?
Q6:作为”卑微“的乙方，开发团队该如何面对变化无常的需求？
2.各阶段的收获
1.需求阶段
2.设计阶段
3.实现阶段
4.测试阶段
5.发布阶段
3.理解和心得
1.个人项目
2.结对作业
3.团队项目
4.自我评分
5.个人技术总结
6. 参考文献

1. 课程回顾与总结

1.1 回顾问题

原问题的博客链接

Q1:商业价值与开源精神是否矛盾？

商业价值与开源精神是否矛盾不能一概而论，有些软件虽然开源，但每年仍然获利无数，而有些软件虽然闭源，却也站在行业的顶尖水平当中。开源并不意味着商业价值降低了，开源意味着可以让更多的人参与到项目的开发当中，集思广益，让商业价值进一步上涨；当然，也存在着守不住商业机密，盗版横行，导致商业价值降低。

新的看法：现在我对开源项目有了更深刻的认识，开源项目最重要的是社区，围绕着开源代码形成的社区。在社区当中要有配套的服务，通过服务来体现开源项目的商业价值。

提出新的问题：无

Q2:对于一名工程师而言，究竟应该是更”专“一点好，还是更”广“一点好呢？

我认为应该专一点好，随着一个研究方向的不断深入，会越来越多的出现与其他研究方向交叉的地方。而广一点，比如说我，看上去什么都懂一点，泛泛而谈，问到具体的问题的时候，却又哑口无言。

新的看法：我现在还是坚持专一点好，这次α β的项目对我来说都是以前未接触过的unity3D技术，但是在项目的研发过程中，我碰到了许多问题，有些问题可能会用到其他方面的知识，像是反射、协程技术等等。随着我对项目的不断研发，不断的“专”研下去，会碰到更多互相交融、相互交叉的问题，这时候能驱动我去学习其他方面的知识，以“专”会“广”。

提出新的问题：无

Q3:项目/任务的大小应当由什么指标来决定？

我觉得可以用实现的功能来决定，不管是自己手撸代码或者是调用框架，项目的大小都可以用实现的功能来决定。总不能说实现一个计算器功能，我从开发新的编程语言开始，这就是一个大项目了，本质上我只需要计算器功能，并不关心你具体如何实现。

新的看法：经过α β阶段的冲刺，我对这个问题有了更深刻的理解。每个人对自己的要求不一样，就算是实现同一个功能，有些人可以做到尽善尽美，有些人只是为了“完成”任务。都是做的同一个功能，但是能说他们的工作量一样吗？目前我的想法是这样子的，可以交由用户来评判，由用户的满意程度来评判工作量的大小。但是这样子也明显存在着许多问题，很多用户并不是我们行业的人员、有些任务的大小不好量化指标给用户等等，这些也给任务的大小判断造成了许多的问题。我们项目当中的评判标准是在给出任务点的时候就确定好，最后看大家的实现成果再来决定是否加分，这也不失为一种方法。

提出新的问题：有没有什么方法能够确定的量化每个人的工作量大小？这样子是不是也不太好？以后工作都不能摸鱼了...对摸鱼人提出了更高的挑战。

Q4:顾客真的知道他们想要什么吗？

我觉得顾客并不知道他们想要什么，比如一个顾客想要一台可以流畅运行网游的电脑，但是他们对电脑的了解并不多，他们只想打游戏，却听着周围鼓吹的声音，嚷嚷着上3090显卡，这并不是一个合适的方案，完全超出了顾客的需求。所以，实际的开发过程中，需要时时刻刻和顾客交流，并引导顾客，让他们明白什么才是最适合他们的。

新的看法：之前的看法有点儿太过片面了，有时候会碰到理性的顾客，对他们的需求确实很明白，我认为在需求分析阶段，顾客的参与力度应该要加大，同时我们也要不断给我们的专业意见，明确顾客的需求，不断讨论。

提出新的问题：能不能规范化顾客的需求，同时量化成指标，将顾客的主观因素转化为客观因素？这样子也更好的让顾客了解他们的需求。

Q5:低层次的问题能依赖工具解决么?

我认为低层次的问题有限度的依赖工具解决是没问题的。在学一门语言的早期，经常会出现一些破涕而笑的小问题导致出错，这时候依赖工具可以帮助我们更快的上手一门语言。在项目开发过程中，因为马虎大意而导致产生的低层次的问题，自己寻找起来可能要花费一点时间，但是通过快速解决，用工具查询，欸，就很快，很舒服。但是工具并不能自己创造，不能ctrl+alt+enter就写好一个项目，所以，只能是一个工具，帮助我们更好生产的一个工具。

新的看法：低层次的问题也分两种，一种是已经太过于熟悉以至于每次编写都觉得繁琐，这种情况用工具解决是没有问题的。另一种是类似编译器集成了git，太过于依赖编译器的功能，从而忽略了理解git的工作原理，当遇到相同原理的plastic时，因为unity只集成了plastic而没有继承git，所以导致有些同学不懂得如何使用plastic，不懂得如何举一反三。这种低层次问题我认为还是在掌握了git的相关知识之后才好用工具解决。

提出新的问题：无

Q6:作为”卑微“的乙方，开发团队该如何面对变化无常的需求？

和第四个问题有点类似，我认为甲方并不是很清楚他们的需求，需要开发团队多与甲方沟通，多多引导甲方，让他认清他的需求。

新的看法：我认为对于变化无常的需求，开发团队要做到以下几点，如果是功能的添加，开发团队要搭建好框架，维护程序的可拓展性；如果是类似UI的变化需求，我认为开发团队可以仔细和客户沟通，如果是太过于繁琐的工作我认为非必要的话可以不修改。
这次 β 过程中，策划对我们提出了更高的要求，但是由于 β 时间过于短暂，最后我们采取折衷的办法，采用添加小功能实现策划的要求。所以，面对变化无常的需求，我们要求自己的能力搭建好框架添加或者是有自己的理由说“不”！

提出新的问题：无

2.各阶段的收获

1.需求阶段

学会了使用NABCD分析法（Need、Approach、Benefit、Competitor 和 Delivery）模型分析需求，并了解到了需求分析的主要内容。在这个阶段中学会了需求规格说明书的涵括内容项和一些注意事项，例如用例图的设计和类图的设计。在这个阶段集思广益，确认好我们要做好一个什么样的项目！

2.设计阶段

在确定了需求之后就要进行整个项目的设计。这个阶段的主要任务是将项目的设计落地，继续完善设计类图，并在正式开始开发之前设计好系统和数据库、制定好计划和分工。除了数据库设计以外，还有原型设计，在这个阶段当中我学会使用Axure的一些基础功能，进行原型设计。在设计过程中，参考了Axure中文文档的内容，学习到了如何设计一个涵盖信息完整、界面简洁、吸引人的网站。还有接口设计，系统设计要设计好接口，这样有利于后续开发。在项目中，我参与数据库规格说明书的编写，类图的设计等。

3.实现阶段

学期初，我原本给自己的计划是后端方面的技术栈。在东奥项目当中，我学习了servlet的后端接口的编写，但是到了 α 和 β 阶段，我们的项目是游戏编写，所以我选择了游戏脚本的编写，虽然没有深入学习springboot等相关知识，但是在游戏脚本的编写当中，我学会了如何使用反射机制，如何使用协程，以及各种设计模式的设计，例如我们的工厂模式生成NPC等，收获巨大！

4.测试阶段

测试阶段，我们小组的开发代码都是自己进行单元测试，所以学会了unity里面自动化单元测试的使用。因为这学期还有门课程是有关于测试，所以让我对测试的看法不再是那么狭隘，我认识到了测试不仅仅只是代码，还要对各个文档进行测试，以及生成测试文档。因为开发人员有限，所以测试阶段我也学到了很多知识，把测试课程当中的知识学以致用！

5.发布阶段

项目发布之后总是会出现各种各样的问题，在这个阶段我学会了如何build一个游戏或者是导出测试版的游戏，在游戏运行时能更直观的看到游戏中各种信息。同时，在这个阶段我们也收到了很多用户给我们的意见，一直在修改各种bug，我认为用户不买账、用户不满意的地方都可以称之为bug。

3.理解和心得

1.个人项目

在这学期的个人项目当中，在实现冬奥会奖牌榜与日程的数据文件输出时，由于没有搞清楚助教测试的数量级，那时候都以为数量级都很大，我记得是10万行或者100行的测试，所以那时候为了大数据量的优化，牺牲了小数据量的时间，导致最后虽然都是正确的，但是耗时相对来说有点久，这件事情给我的教训就是一定要搞清楚数量级，往往目标错误的时候就不会得到好的结果。
同时，这个阶段当中我第一次接触到了PSP表格，学会了使用PSP表格统计预计耗时和实际耗时，以此对项目进行总结和分析，方便自身的提高。

2.结对作业

结对作业共有两次，一次是原型设计，一次是编码实现，我认为结对编程对于编码能力以及习惯的改变是巨大的。在结对过程当中，你总能从搭档身上学到闪光点，从而改变自己不好的编程习惯。我是比较倾向于在DDL快来来临之时赶工，但是搭档就会提早做好准备，这样子不管是面对需求的变更还是最后的成果都是比较好的。

3.团队项目

团队项目当中，我担任后端项目的开发。同时我也体会到了什么叫做一个团队。在这个团队当中，有不断进行统筹规划的组长，有不断给我们加工作量的策划，还有工作量巨大的前端成员，看着他们辛苦的工作开发建模，顿时感觉后端的工作量还算是比较轻松的，因为unity设计当中UI也是通过后端编码实现的，所以我在这个阶段当中还学会了如果进行过场动画等的设计。
感谢我的团队，让我在这次的团队项目当中收获巨大。感谢后端的小组成员，是他们一直给了我制导。感谢前端的小组成员，是他们的巨大工作量让我们的项目脱颖而出。感谢策划，是她在不断督促着我们进行项目的开发。

4.自我评分

目标名	内容
目标1	理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念
目标2	掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型
目标3	掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案
目标4	能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案
目标5	遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力
目标6	具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作
目标7	能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力

目标名	评分	解释
目标1	88	通过理论课对于软件工程师职业道德的讲述，能更好地理解软件工程师的社会职责，理解软件工程师的社会使命，并要求自己能遵循职业道德，不使用自己的专业知识做危害社会的事情
目标2	86	学会了使用NABCD分析法（Need、Approach、Benefit、Competitor 和 Delivery）模型分析需求，并了解到了需求分析的主要内容，同时在这个阶段我们小组也进行了充分的小组讨论交流，还有问卷调查等
目标3	80	项目开发过程，我充分参与了每个开发过程，参与对模块任务的划分，但是由于数据库的设计阶段缺少评审，所以导致问题的发生，数据库设计的不够规范
目标4	90	这学期的软件测评作业对3个代码托管平台进行了评测，对于软件评测有一定了解，同时能够运用这学期软件测试的相关知识，学以致用，这部分掌握的不错
目标5	80	参与各个文档的编写，了解大致的方法，但是文档的规范性有待提升
目标6	90	配合团队的工作内容，明确工作时限，同时作为一名开发者，能严格遵守开发时限，及时完成任务
目标7	82	作为后端脚本的编写人员，在teambition当中规划好了项目的工作量大小，以及每天完成一定的工作量之后都能通过燃尽图表现出来，同时也能和组长等搭配好，协调沟通项目的进程，确保项目如期完成