软件工程实践总结———浮出水面

081900317_李楷鸿 学生 2022-06-26 20:39:44
这个作业属于哪个课程2022年福大-软件工程、实践-W班
这个作业要求在哪里软件工程实践总结&个人技术博客
这个作业的目标课程回顾与总结
其他参考文献CSDN博文,构建之法(邹欣 第三版)

目录

  • 《构建之法》问题回顾
  • 新问题
  • 五个阶段的实践收获
  • 需求
  • 设计
  • 实现
  • 测试
  • 发布
  • 软工实践的理解和心得
  • 个人项目
  • 结对编程
  • 团队项目
  • 课程目标掌握程度
  • 个人技术总结

《构建之法》问题回顾

问题博客链接————软件工程实践寒假作业

  • Q:1.2.2 大陆高校中的计算机专业与软件专业是否并不像书中说的那样雷同?

    Last Answer:在我看来在计算机专业与软件专业确实有雷同之处,也有不同之处。其实在本科计算机专业与软件专业的学习课程基本相同,计算机专业涉及面可能更广,但是深度我觉得与软件专业是相同的,计算机专业并不意味着涉及更多的理论,而是与软件工程专业一样。计算机专业的毕业生大部分是投身于解决工程问题,虽然计算机偏理论,但是毕业生由于就业前景好,对科研没有兴趣,也不会投身解决理论问题,而更多投身解决工程问题。
    Current Answer:经过一个学期软件工程课程学习,这应该是三年学习中与软件工程专业比较有关联的课程,但是也仅限于软件工程实践,从结对项目到团队项目,软件的需求分析,概要和系统设计,开发,运营以及维护,真正意义上涉及更多与人的交流。其他课程而言,更多的也是偏向理论的课程。当然计算机专业并不意味着涉及更多的理论,他们也有很多偏向实践的课程。其实计算机科学和软件工程有很多交汇的领域,因此计算机专业与软件工程还是有许多雷同之处。但是正如《构建之法》所说“不再纠结"科学"与"工程"的问题,而是在不同的学习与工作阶段,投入到最适合的项目类型中去。”
    原问题链接

  • Q:1.2.4 软件的行为和用户的期望值不一样,就一定是 Bug 吗?

    Last Answer:是否是bug取决于用户、开发者的不同角度。但是软件的行为就是为了满足用户需求,如果软件只是开发人员在预计的时间内发布的“足够好”的软件,不能满足用户期望值,就是存在Bug。因此,软件的行为和用户的期望值不一样,就是存在Bug。
    Current Answer:在团队项目需求分析阶段,根据用户需求,指明具体功能以及验收标准,在alpha阶段和beta阶段结束后分别进行了测试,包括单元测试,接口测试,以及功能测试。而功能测试,正是根据需求规格说明书中的具体功能和验收标准进行测试。如果不满足功能性需求,意味着存在Bug。因此,软件的行为和用户的期望值不一样,就一定是Bug。需求是来源于实际的,所以应研发出满足用户需求的软件。类似于在后端接口开发过程中,由于系统设计没有充分指明前端需要的返回值,而在实际开发中,后端接口不满足前端的要求,即存在bug,就要修改。
    原问题链接

  • Q:2.1 单元测试由最熟悉代码的人来写是否足够呢?

    Last Answer:足够,最熟悉代码的人了解代码的目的、特点和实现的局限性,让熟悉代码的人来写单元测试是足够的,这样单元测试就能体现API的语义,如果让不熟悉代码的人来代劳,语义的准确性不能得到保障,会产生歧义。
    Current Answer:在团队项目开发中,负责后端接口开发,而对代码进行单元测试,主要由自己进行。在我看来,单元测试应该由最熟悉代码的人来写。在实际单元测试中,设计测试用例要满足相应的条件覆盖、判定覆盖等,而这些要建立在对代码逻辑熟悉的基础上。如果由其他人对代码进行单元测试,没法保障单元测试的效率以及正确率。而黑盒测试,不需要了解代码逻辑,可以有专人进行测试。
    原问题链接

  • Q:2.1 如何提高单元测试的覆盖率(尤其是对于经验不足的新人)?

    Last Answer:对于经验不足的新手,提高单元测试的覆盖率,应该从以下几个层次入手,函数的覆盖,语句的覆盖,分支的覆盖,条件的覆盖,分支覆盖是强有力的测试依据,必须测试公开的和私有的函数/方法,提高覆盖率。
    Current Answer:刚开始进行单元测试是在个人实战过程中,一开始对于单元测试无从下手,但是了解一些单元测试后,设计测试用例满足判定覆盖、条件覆盖,提高了测试的覆盖率。而单元测试也占用了个人实战的一大部分时间,提高覆盖率并没有那么容易。当然对于新手而言,单元测试要测试API的每一个方法及每一个参数,同时要从多个层次入手,这样才能提高单元测试覆盖率。一味的追求代码覆盖率,并不能保证正确性。
    原问题链接

  • Q:2.1 单元测试中作者自己测试最好吗,单元测试使用随机数真的没有意义吗?

    Last Answer:单元测试由作者自己测试最好,代码的作者最了解代码的目的、特点和实现的局限性。单元测试应该产生可重复、一致的结果,如果某个随机数导致程序出错,但是下一次运行又不能重复这一个错误,则于事无补,所以单元测试使用随机数没有意义。
    Current Answer:单元测试由作者来完成,肯定是最好的,作者理解代码的逻辑,能够在保证覆盖率的同时保证正确性,此外效率也得到保证。团队实战过程中进行单元测试,使用随机数进行单元测试的话,程序报错,测试点无法通过,但是也仅限于此,根本无法准确定位错误,意味着要重新进行测试用例构造。单元测试过程中,设计测试的过程中,使用确定的值,一旦测试用例无法通过,就能够重复这个错误。不然下次运行又不能重复这个错误,所以单元测试使用随机数是没有意义的。
    原问题链接

新问题

  • Q:6.2 怎样在一开始制定一个较为合理和较弹性的计划?对任务优先级和依赖关系的权衡有什么标准吗?

    A:因为团队开发过程中,一开始指定地计划,到后期都很难按时完成,都需要加班加点。考虑到可能我们软件的功能较多,但是人员数量是不足的。但这不是唯一的理由。其实在一开始,就应该考虑到工作量和任务数,而不是按照模块进行划分,应该充分考虑各种因素,进行任务划分,这样的话,就较为合理。同时要设置缓冲时间,前紧后松这样就会更有弹性。此外要考虑到任务的优先级和依赖关系,对于有前后关系的任务,尚未完成,就会影响后面任务完成的,就应该有较高的优先级,这样不会使得进度延迟。当然也需要全盘考虑各种情况权衡优先级。
    问题链接

  • Q:13.2 单元测试应该在什么时候开始做?

    A: 在团队开发过程中,单元测试都是在代码完成后开始做的,根据代码设计的逻辑,去设计单元测试的测试用例。但是《构建之法》中提出,"单元测试应该在功能完成之前就已经完成了设计,即事先定义好接口和规范的输入输出,而不应该根据写完的代码写单元测试。应该测试的预期的功能和数据处理,如果预期功能发生变化,单元测试也应该发生变化,代码是应该与设计一致"。单元测试在开发之前设计会比开发完成后设计有更多好处,能够指导开发,定义规范,会起到较好的效果。
    问题链接

五个阶段的实践收获

需求

  • 在结对项目,以及团队实践过程中,需求分析阶段,都使用到了NABCD模型进行竞争性需求分析,可以很有条理地进行需求分析。从N(Need,需求)、A(Approach,做法),B(Benefit,好处),C(Competitors)到D(Delivery,推广),通过该模型可以很好地描述当前打算开发软件的优点,以及实现的必要性,同时又能很好的进行需求分析。
  • 此外在团队实践过程中,负责将用户需求转换成用况图以及类图。很好地锻炼了面向对象分析的能力,同时巩固了UML软件使用,以及类图的设计。

设计

  • 数据库设计,通过将需求分析阶段的类图,从数据库的逻辑设计到物理设计,通过ER图,体现了实体之间的关系,转换成数据拓扑图,到数据库的字典设计,最终设计出完整的数据库。通过数据库的设计的实践,让我对数据库设计有了更深的理解。当然,数据库设计阶段一定要满足需求分析,不然在后续的开发过程中,会导致事半功倍。数据库的设计一定要在开发之前就要统一,不然在开发过程中再去修改数据库,会导致开发人员有抗拒情绪,修改数据库意味着要修改代码。
  • 系统设计阶段,对后端接口文档进行定义,明确接口实现的功能,以及请求与响应的参数。这也是十分重要的,不然前后端无法统一进行开发,最终只会让前后端对接变得十分困难。

实现

  • 团队实践主要负责后端接口开发,正好与自己开学初顶下的学习路线一致,正好可以对自己学习过的技术进行实践,技术栈是SpringBoot、MyBatis-plus以及Redis。在开发过程中,也很好地对执行了代码规范,不再是先写代码再执行规范。同时也学会了SpringBoot图片上传接口的实现,自定义异常处理机制,以及jar部署Liunx服务器对图片上传进行测试。此外,还了解了一些SpringBoot开发规范,可以很好地进行开发。除了基本的层次以外,可以添加DTO层,用于封装sql语句返回的复杂内容,以及VO层,对前端请求参数进行封装。使用springboot自带的@validated注解,对前端参数进行校验,会更方便。
  • 在开发过程中,要不断地与前端进行对接,锻炼了沟通能力,以及如何与前端沟通技术上的问题,让对方更容易理解。同时也发现了,前后端主要问题都出现在,需求不一致上,因此在设计阶段,数据库设计和系统设计就要做到统一,这样能起到事倍功半的效果。

测试

  • 后端接口开发过程中,主要进行了单元测试、接口测试、以及性能测试。通过Junit5对后端代码进行单元测试,也理解了之前提出的问题。使用了ApiPost进行接口测试,发现了接口存在的一些问题。同时也使用PerfTest,基于Junit5进行性能测试,相比于Jmeter测试工具而言,PerfTest使用起来会更方便一些。

发布

  • 发布阶段,主要负责,将后端代码打包成jar,并部署到服务器上。由于服务器是第一次部署,所以要在Liunx系统上搭建环境。
  • 因为部署jar包,所以要安装JDK,因为是SpringBoot项目,jar中自带tomcat,所以不需要安装。然后要安装mysql,将数据库导入。此外项目还使用了redis数据库,对token进行缓存,因此要安装。考虑要将redis运行在服务器的守护线程上,因此要修改配置文件。这样部署jar包的前提环境都配置好了,要通过服务器管理平台安全组将端口对外访问的权限打开,这样将jar启动,配置在后台运行,就正式完成了。当然在多次换服务器之后,以及进一步让我对,liunx服务器常用命令,以及常用环境搭建非常熟悉。当然这都是建立在不断失败的基础上走过来的。

软工实践的理解和心得

个人项目

  • 个人项目完成北京冬奥会奖牌榜及每日赛程输出的控制台程序,在开发过程中使用IDEA开发工具,项目管理工具gitCode,此外还接触了单元测试Junit,使用PSP表格进行耗时记录,从项目接口的封装到不断地进行性能优化,再到单元测试,最终达成jar包,初步了解了一个软件开发的全过程。此外,需求的不断变更,也让我们深刻理解了,在客户需求不断变更的同时,我们应当保持理性,有更多的沟通。

结对编程

  • 结对编程使用Axure进行原型开发,此外使用Vue脚手架搭建单页应用程序。在原型开发过程中,初次使用Axure,在学习过程中遇到了不少困难,但是也在和队友的讨论中不断解决问题,包括奖牌榜如何设计更加方便,美观。当然,也在使用RP9的团队项目进行团队协作。通过实现需求,也是第一次接触了前端的框架开发,学习了vue,bootstrap等等。因为没有开发后端,于是便持久化存储在localstorage中。在结对项目中,更多要学会如何与队友进行沟通与协作,互帮互助,才能有所提高。在这里还是要感谢我的队友,给我提供了很多技术上的帮助。

团队项目

  • 团队项目应该是大学以来,组队合作完成的最大的项目,从一开始的需求分析、数据库设计和系统设计、git实战、alpha冲刺,再到beta冲刺,一路走来,不光是技术上有许多进步,同时也与队友有着很好的沟通。git实战,一天之内要完成前后端的开发,虽然说起来很简单,但是当真正多人合作起来,并没有那么容易。虽然最后忙活到截止时间以前,我们都没有完成前后端的对接。这也给了我们后面两次冲刺有了很多帮助,一开始就要确定好分工,指定好各模块的截止时间,在保证前后端的进度的前提下,要先做好前后端对接,这样才不会拖到最后完不成。alpha,beta冲刺主要负责后端开发,其实遇到最艰难的问题不是接口开发,也不是前后端的对接,而是我们在需求分析,数据库设计和系统设计阶段没有设计好,而导致的开发难题。这也意味着,下次开发要做好这一点。当然,在与队友一起合作开发的时间是美好的,也感谢队友的理解。

课程目标掌握程度

序号课程目标掌握程度(百分制)理由
目标1理解软件工程师的职业道德规范和实践要求,了解国情社情民情,理解软件产品对社会、健康文化等影响,树立积极向上的软件开发理念。95即将成为一名软件工程师,很好地理解了职业道德规范和实践道德,有着积极向上的软件开发理念,在团队开发过程中,很好地完成接口开发,并进行测试,不会随意地进行开发,满足用户地需求。对软件满足用户需求,社会需要有较深刻地理解。
目标2掌握需求分析的全过程,能辨别客户表述的多样化要求,熟练使用需求表达工具,能够规范、准确地表达客户的需求,构建需求分析模型。90在结对项目与团队项目的需求分析过程中,很好掌握了需求分析的全过程,能够将用户的需求很好地转化成用况图和类图,以便后期的设计与实现。同样也能用原型设计工具,将用户的需求很好的表现出来,但是原型设计,和构建需求分析模型方面还有待提高。
目标3掌握软件开发的全过程,遵循体系结构设计方法和基本设计原则,通过正式的技术评审,完成从体系结构设计模型、数据设计模型和构件级设计模型,形成面向高效可靠的服务组件设计方案或软件系统设计方案。90在团队项目开发过程中,很好地掌握了软件开发的全过程,完成了从体系结构设计模型、数据设计模型,形成了高效可靠的软件系统设计方案。但是没有很好地遵循体系结构设计方法和基本设计原则。
目标4能够执行从组件到软件系统的技术评测,具备设计模型的评判能力,具有创新设计意识,能够优选设计方案。80初步具备了设计模型的评判能力,能够择优选择设计方案,但是还没有创新的设计意识,还需进一步提高。
目标5遵循软件开发各阶段文档标准,采用规范的表达,掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法,具备与业界同行交流能力。95在团队项目文档编写过程中,负责了需求规格说明书、系统设计说明书、系统测试报告等文档撰写,当然文档也都是由我负责整合的,对于软件开发各阶段文档标准有了很好的理解。初步具备了与业界同行交流的能力。
目标6具有良好的团队意识和合作技能,能够与其他成员开展有效的沟通和协作;能够组织、协调或指挥团队开展工作。85在结对项目与团队合作中,锻炼了如何与队友如何更好地沟通,培养了良好的团队意识和合作技能。在后端接口开发中使用了源代码管理工具git,有效的进行协作。同时在前后端接口的对接上,很好地通过技术进行沟通。当然在组织、协调或指挥团队开展工作方面还有所欠缺。
目标7能够辨别具体软件项目管理中涉及的构成要素,掌握软件规模和工作量的估算方法,能够选择合适的工具规划软件进度并对项目管理过程进行配置,具备初步的管理复杂软件工程项目的能力。80在结对项目中,很好地掌握了软件规模和工作量的估计,因此在分工方面十分合理,在进度要求的前提下,保质保量的完成任务。团队项目中,使用了teambition规划软件进度,当然主要负责后端开发,完成了后端的接口开发进度安排,也提前完成了任务。对于整个软件项目的管理还是需要进一步提升。

个人技术总结

个人技术总结博客————SpringBoot图片上传及jar包部署测试
概述:实现图片上传接口,用户可以上传单张或者多张图片,对图片的大小,类型进行限制,指定存储服务器的位置,同时对图片上传异常进行自定义异常处理。同时搭建在liunx服务器上的jar包环境,部署jar包进行测试。

...全文
170 回复 打赏 收藏 举报
写回复
回复
切换为时间正序
请发表友善的回复…
发表回复
发帖
2022年福大-软件工程、实践-W班

136

社区成员

2022年福大-软件工程;软件工程实践-W班
软件工程 高校
社区管理员
  • FZU_SE_teacherW
  • 丝雨_xrc
  • Lyu-
加入社区
帖子事件
创建了帖子
2022-06-26 20:39
社区公告
暂无公告