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

一、回望开学初对于软件工程课程的想象，回望博客开篇时对于这门课和这学期的期望，

1）对比现在的你和开学初博客开篇的课程目标和期待。

能力的预期
1.对于java的一些框架有了一定认识，不过学习的目标还有一部分没完成。
2.在做实践的过程中，和大家的沟通能力得到提高，可以很快的知道别人想要我做什么，并且可以很快地实现；也遇到了一些问题，比如如何做一个定时任务，每天定时刷新数据库;这些自己可以比较快的上网搜索解决。

项目课程的期望
栋哥的每个阶段都要求我们做好多事情，虽然有些事并没有感受到有多大好处，但是回想整个流程感觉这样才是正规的软件开发的流程。

2）总结这门课程的实践给你带来的提升：
Git
GitHub、markdown
2960 行
模拟测试
使用Spring框架完成定时任务

二、写下属于自己的人月神话

 我觉得比较重要的是每天要有计划，今天要完成哪些人任务，如果出现时间冲突，要如何重新调整计划。刚开始的时候并没有写issus这些东西，感觉麻烦，后来写了之后，比较好的一点是，虽然没用这个之前，每天自己也有计划，但是使用issues之后，每天的安排和目标会更明确，对于任务的完成度有了一个可以量化的标准。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。

  我认为首先作为一个程序员，自学的能力很重要，因为我们遇到的很多BUG基本上要靠自己解决，学会利用好搜索工具；然后团队合作比较重要的就是一个团队最重要的是态度，大家都认真的执行计划和安排团队才能运行下去。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？

  我所在的团队大家分工比较明确，我负责后台，两个写界面，一个负责前后端的对接，还有一个主要任务是写文档。我们刚开始的时候就划分好了每个人负责的部分，所以萌芽阶段很快就过去了；磨合阶段稍微长一点，主要是对于需求大家观点不同，有过争执；剩下的时间基本就是规范阶段了，需求基本确定了，而且经过一段时间合作大家走出了步调，我写完接口，就会更新接口文档，负责对接的就根据文档对接，并给出对应文档，前端使用接口发现问题就记录下来教给我们处理（虽然有些文档不是很规范，但是很好的促进了软件的完成），然后这个过程不断循环。创造，这个有点难。

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

参考论文文献：

[3] Samoladas I, Stamelos I, Angelis L, et al. Open source software development should strive for even greater code maintainability[J]. Communications of the ACM, 2004, 47(10): 83-87

摘要：

In our analysis we used a set of measurement programs available in the Debian GNU/Linux release, and a number of Perl scripts for managing measurement results. The metrics considered are among the most widely reported and used in the literature and are listed here:

  • Number of lines of code (LOC) measures the physical size of the program code, excluding blank lines and comments.
  • Percentage of lines of comments with respect to the number of lines of code (PerCM) describes the self-descriptiveness of the code.
  • Halstead Volume (V). Halstead [4] defined four metrics that can be measured from a program's source code: n1 (the number of distinct operators), n2 (the number of distinct operands), N1 (the total number of operators) and N2 (the total number of operands). Based on them, he defined program vocabulary n (given by n = n1 + n2) and program length N (given by N = N1 + N2). Finally, he defined Volume, a composite metric given by the formula V = N * (LOG2 n). Halstead Volume provides an alternative measure for the size of a program.
  • Cyclomatic Complexity V(g). Proposed by McCabe [7], this metric counts the number of independent paths in the control flow graph of a program component. Its value depends on the number of branches caused by conditional statements (if-then-else). It measures the structural complexity of the component.

It would be quite difficult to reach a consensus about the metric ranges that OSS code should respect in order to define an OSS-specific programming standard. In this study, rather than comparing with a predefined standard, we preferred to directly compare maintainability measures of open source with those obtained for closed source software, or simply to observe the trend of these measures and derive conjectures about improvement or deterioration of code quality. Because it may be difficult to obtain a single picture about maintainability from many measures derived from many different metrics, we preferred to use a different approach in our study based on the composite metric, Maintainability Index (MI), chosen by SEI [6] as the most suitable tool for measuring the maintainability of systems with high-quality requirements. We chose MI because we believe that OSS should conform to such standards in order to compete with CSS. Moreover, various OSS projects, including some we studied, are often part of large scale, critical applications. MI following this formula:

eq01.gif

where avgV stands for "average Halstead Volume per module" and avgV(g), avgLOC, and avgPerCM are defined in a similar way.

`取值并计算得：` n1=1; n2=45; N1=1; N2=49 module=4; LOC=2960 V(g)=2; PerCM=180 V=275; MI=50.94

六、怎样证明你学会了软件工程？

１ 研发出符合用户需求的软件
这个没正式发布，也没什么要讲的。

２ 通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
1.需求分析阶段有需求规格说明书
2.设计阶段用墨客进行原型设计，PowerDesign进行数据库设计
3.实现使用GitHub进行代码整合，PostMan测试接口；每天都有提交自己完成的任务以及次日计划。
4.部署在云服务器上，使用Tomcat部署。

３ 并且通过数据展现软件是可以维护和继续发展的。
后台有接口文档，前端有需求规格说明书、项目介绍、编译说明和安装说明，继续维护和拓展还是可以进行下去的。