个人作业——软件工程实践总结

软工实践总结作业

作业地址

一、请回望暑假时的第一次作业,你对于软件工程课程的想象

1)对比开篇博客你对课程目标和期待,“希望通过实践锻炼,增强计算机专业的能力和就业竞争力”,对比目前的所学所练所得,在哪些方面达到了你的期待和目标,哪些方面还存在哪些不足,为什么?

对这门课的期待也是能通过学习,能丰富自己的知识。希望能够通过和队友的合作,做出一个好的项目。

  • 通过这门课的学习,项目开发能力得到了提升,在没上这门课之前,没有什么项目经历,但是通过这门课,从选题,到需求分析···经历了项目开发的基本过程
  • 通过这门课的学习,自己的代码能力得到了提升,在之前会一些语言,但是都比较粗浅,通过这次的课程,巩固了自己Java的基础
  • 通过这门课的学习,懂得了一点项目管理
  • 查找资料更快了
  • 但是自己的代码冗余度有点高,时间利用率太低,测试能力还比较低
  • 就业竞争力还是比较弱

2)总结这门课程的实践总结和给你带来的提升,包括以下内容:

  • 统计一下,你在这门软件工程实践中,完成了多少行的代码;
语言 代码行
java 6680
xml 720
html 840
css 500
  • 软工实践的各次作业分别花了多少时间?(做一个列表)
作业 花费时间(h)
第一次作业——准备篇 2
第二次作业——个人项目实战 18
原型设计(结对第一次) 14
结对第2次作业——WordCount进阶需求 16
团队展示 2
项目选题报告 15
项目需求分析 23
团队作业——校友录 6
项目Alpha冲刺 53
个人作业——软件产品案例分析 8
事后诸葛亮 2
项目beta冲刺 21
个人作业——软件工程实践总结 2
总结 182
  • 哪一次作业让你印象最深刻?为什么?
    第二次结对作业让我印象深刻,那是第一次和别人一起写一个东西,在第二次结对作业当中遇到最大的问题就是github的使用,两个人的代码签入后发生了冲突,还有就是两个人的代码风格不挑,在刚开始写代码的事后没有统一,导致写了差不多之后还要修改。
  • 累计花了多少个小时在软工实践上?平均每周花多少个小时?
    完成作业的时间和学习的时间合起来花费了近200个小时在软工实践上,按17周计算,平均每周花在软工实践上的时间有12个小时左右
  • 学习和使用的新软件和工具
    • 原型设计——Axure RP
    • 画活动图、用例图等——starUML
    • 思维导图——ProcessOn
    • 团队项目管理——GitHub
  • 学习和掌握的新语言、新平台
    语言没有新学习什么,但是更加深入的学习了Java,学习了servlet和service
  • 学习和掌握的新方法
    • 单元测试
    • 性能分析
  • 其他方面的提升
    • 和大家的团队协作能力
    • 抗压能力
    • 提高了查资料和自学的能力

二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析

在团队项目实践中,大家都基本属于0基础,有的可能只是知道Java的语法,没有真正的实践过。在大家合作开发网站的时候,大家分工发现都没有会后端,最后只能硬着头皮边学边做,我自己先学,然后大家统一按照一定的框架做,这样在后期的代码整合的时候会方便很多。因为是边学边做,我们在alpha的时候遇到很多问题,service和servlet那边都遇到很多问题,我们遇到问题主要先百度解决,但是百度的答案有的时候不一定正确,就需要一遍一遍的尝试。有的时候还是解决不了就去请教会的同学。

三、对下一届实践的建议,或者对于开学初的你,对于大一的你,对于开学初的我,你有什么想建议和告知的呢?对于后来人的期许。特别地,特别地,下一届要不要中途换队员?

  • 对下一届的建议:选实践一定要慎重(但是好像从下一届开始就要必修了),选题要量力而行,组队要综合考虑每个人会的东西,组队要是比较多都是什么都不会的就不太好。
  • 对于开学的自己:要好好安排时间,不要积累大量的工作量放在deadline之前
  • 对大一的我:大一时间充裕,好好学习知识,积极参加竞赛
  • 至于要不要中途换队员,这个要视情况而定,我觉得可以让团队成员自己选择要不要更换,如果真的不适合这个团队就需要更换。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段,你的团队都经历过么,最后到达了“创造”阶段了么?(参考《构建执法》第17章 人、绩效和职业道德)

  • 萌芽阶段
    团队刚成立的时候,大家热情都特别高,一起讨论选什么题目,要先学些什么技术
  • 磨合阶段
    在合作过程中会发现大家的习惯,代码风格都不一样,就需要磨合,在alpha阶段体现的最为明显
  • 规范阶段
    经过了alpha阶段,在bata阶段开始之前,大家就对自己代码的规范化,命名都采用驼峰命名,采用一个框架,都添加注释
  • 创造阶段
    可能还有一点距离,但是快了

五、怎样证明你学会了软件工程?请在随笔中用数据证明下面内容或侧重选择之一。

1)研发出符合用户需求的软件

必须公开发布,有实际的用户,一定的用户量和持续使用量 (3 天后能保持10 - 100个用户);而不是: 做没有用户使用的软件

在beta冲刺结束之后,我们进行了用户调查测试,大部分用户都认为我们的网站符合他们的需求

2)通过一系列工具,流程,团队合作,能够在预计的时间内发布 “足够好” 的软件

有项目规划/需求/设计/实现/发布/维护,有定时的进度发布 ; 而不是: 通过临时熬夜,胡乱拼凑,大牛一人代劳,延迟交付等方式糊弄

通过github管理代码,在软件开始前有选题、需求分析,原型设计,代码实现,部署到服务器等阶段,大家一起协作开发。每个人负责不同的模块,每天都有规划进度,第二天的安排。熬夜经常存在,但是不是临时,基本属于明天12节没课,大家就会熬夜争取多写一点东西

3)并且通过数据展现软件是可以维护和继续发展的。

而不是 找不到源代码,代码无文档,代码不能编译,没有task/bug 等项目的发展资料

  • 代码放在GitHub上(github地址
  • 代码有接口文档、有注释

六*(选做)、阅读软件工程中关于代码质量的经典论文,从下列文献中选择一篇或若干篇,结合自己的实际做一个阅读笔记(例如,自己写的代码质量如何,是不是一个大泥球,如何衡量自己代码的质量)?从以下参考论文中选择一篇或若干篇:

默认情况下,该工具使用测量值测量每个组件并根据四个基本标准(即可测试性,简单性,可读性和自描述性)对其进行评估。该标准取自关于软件质量子特性的国际标准(国际标准组织(ISO),1991)。该标准被软件行业的许多公司使用(Fenton 等,1995并且,尽管有批评,但它被认为是软件质量测量发展的一个重要里程碑。此外,上述标准充分反映了开源代码所需的质量特性,如引言中所述。开源代码应该是可测试的,以允许快速演进并且足够简单以允许频繁修改和扩展。显然,它应该是可读的和自我描述的,以促进这些活动。
——引用自《Code quality analysis in open source software development

通过阅读论文知道,可以通过可测试性,简单性,可读性和可描述性四个方面衡量自己代码的质量

目前我自己的代码做到了基本的可读性、可测试性。

  • 可读性:代码变量的命名采用驼峰式命名,使用看的懂的单词命名。添加适当的注释。
  • 可测试性:代码大多数采用接口形式调用

但是自己的代码冗余性太高了,很多重复的代码,不够精简

有三种不同的关键实践可能有助于实现高质量的代码:
1、可以要求程序员在干预代码时考虑结构代码质量。
2、项目协调员可以根据预定义的标准评估程序员返回的代码的质量。这意味着某些不符合标准的组件可能会被拒绝,即使它们提供了正确的错误修复或新功能。
3、当项目似乎遇到严重问题时,项目协调员可以采取适当的代码重新设计决策。——引用自《Code quality analysis in open source software development

通过规范代码,可以减少后期不必要的修改。可以学习一下怎么提高代码的质量。

参考论文文献:

[1] Stamelos I, Angelis L, Oikonomou A, et al. Code quality analysis in open source software development[J]. Information Systems Journal, 2002, 12(1): 43-60.

七、个性发挥,包括图文、照片和创意等

感慨一下,软工时间终于结束了,这学期的代码量可能和掉了的头发成正比,可以不用在熬夜了,接下来就是好多好多的考试。

posted @ 2019-01-08 20:30  BANG!  阅读(245)  评论(3编辑  收藏  举报