天行健,君子以自强不息

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能够辨别具体软件项目管理中涉及的构成要素,掌握软件规模和工作量的估算方法,能够选择合适的工具规划软件进度并对项目管理过程进行配置,具备初步的管理复杂软件工程项目的能力
目标名评分解释
目标188通过理论课对于软件工程师职业道德的讲述,能更好地理解软件工程师的社会职责,理解软件工程师的社会使命,并要求自己能遵循职业道德,不使用自己的专业知识做危害社会的事情
目标286学会了使用NABCD分析法(Need、Approach、Benefit、Competitor 和 Delivery)模型分析需求,并了解到了需求分析的主要内容,同时在这个阶段我们小组也进行了充分的小组讨论交流,还有问卷调查等
目标380项目开发过程,我充分参与了每个开发过程,参与对模块任务的划分,但是由于数据库的设计阶段缺少评审,所以导致问题的发生,数据库设计的不够规范
目标490这学期的软件测评作业对3个代码托管平台进行了评测,对于软件评测有一定了解,同时能够运用这学期软件测试的相关知识,学以致用,这部分掌握的不错
目标580参与各个文档的编写,了解大致的方法,但是文档的规范性有待提升
目标690配合团队的工作内容,明确工作时限,同时作为一名开发者,能严格遵守开发时限,及时完成任务
目标782作为后端脚本的编写人员,在teambition当中规划好了项目的工作量大小,以及每天完成一定的工作量之后都能通过燃尽图表现出来,同时也能和组长等搭配好,协调沟通项目的进程,确保项目如期完成

5.个人技术总结

unity当中协程的使用

6. 参考文献

...全文
6910 3 打赏 收藏 转发到动态 举报
写回复
用AI写文章
3 条回复
切换为时间正序
请发表友善的回复…
发表回复
SoftwareTeacher 教师 2022-07-13
  • 打赏
  • 举报
回复

会碰到更多互相交融、相互交叉的问题,这时候能驱动我去学习其他方面的知识,以“专”会“广”。


赞, 行到水穷处,就会发现新的 ‘广’

Jingbin-Wang 教师 2022-07-12
  • 打赏
  • 举报
回复

这次 β 过程中,策划对我们提出了更高的要求,但是由于 β 时间过于短暂,最后我们采取折衷的办法,采用添加小功能实现策划的要求。所以,面对变化无常的需求,我们要求自己的能力搭建好框架添加或者是有自己的理由说“不”!

β过程中的策划毕竟还是同学,现实中的客户可能会很坚持他提出的修改意见,此时折衷和谈判就很重要。
很赞的总结!继续加油!

221900137李凌佳 学生 2022-06-29
  • 打赏
  • 举报
回复 1

img

139

社区成员

发帖
与我相关
我的任务
社区描述
2022年福大-软件工程;软件工程实践-W班
软件工程 高校
社区管理员
  • FZU_SE_teacherW
  • 丝雨_xrc
  • Lyu-
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧