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

软工实践总结作业

作业地址

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

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.

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

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