个人作业——软件工程实践总结作业
| 这个作业属于哪个课程 | 软件工程1916|W |
|---|---|
| 这个作业要求在哪里 | 个人作业——软件工程实践总结作业 |
| 学号 | 131601207 |
| 这个作业的目标 | 软件工程实践总结 |
| 其他参考文献 | [1]邹欣.构建之法[M] |
作业正文
一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
开篇博客中，我对课程的目标和期待如下：
培养分析和解决实际问题的能力，提高编程能力，了解如何团队分工合作开发项目，培养团队合作的意识
对比目前的所学所练所得，我基本达到了自己的期待和目标，培养了自己分析和解决实际问题的能力，编程能力得到了提高，了解到了如何团队分工合作开发项目，培养了团队合作的意识，但在项目管理方面还是存在着一些不足，主要是因为自己在整个团队作业阶段主要还是担任一个“被管理者”的角色，服从团队队长的安排，较少直接参与团队的管理。
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
1. 统计一下，你在这门软件工程实践中，完成了多少行的代码
| 阶段 | 代码行 |
|---|---|
| 结对编程 | 537行 |
| 团队作业 | 2643行 |
2. 软工实践的各次作业分别花了多少时间？
| 作业名称 | 时间(h) |
|---|---|
| 第一次作业-准备篇 | 3 |
| 结对第一次—原型设计（文献摘要热词统计） | 15 |
| 结对第二次—文献摘要热词统计及进阶需求 | 10 |
| 团队作业第一次—团队展示 | 2 |
| 团队作业第二次—项目选题报告 | 12 |
| 团队第三次-项目原型设计 | 13 |
| 团队作业第四次-项目需求分析 | 11 |
| 团队作业第五次—项目系统设计与数据库设计 | 6 |
| 团队作业第六次—团队Github实战训练 | 15 |
| 项目Alpha冲刺（团队） | 28 |
| 事后诸葛亮（团队） | 3 |
| 项目Beta冲刺（团队） | 32 |
| Beta阶段团队项目互评 | 2 |
| 个人作业——软件工程实践总结作业 | 3 |
| 总计 | 155 |
3. 哪一次作业让你印象最深刻？为什么？
项目Beta冲刺（团队）作业让我印象深刻，因为在这个阶段开始前，我们团队中和我一起负责前端的同学被交换走了，因此在这个阶段我的任务量变大，花费的时间和精力也更多。但是在这个过程中，我也收获了许多，通过大量时间的投入，我对于前端框架Vue的掌握更加充分，编程能力在短时间内得到了较大的提升。
4. 累计花了多少个小时在软工实践上？平均每周花多少个小时？
累计花了超过170个小时在软工实践上，平均每周花超过13个小时
5. 学习和使用的新软件
墨刀、WebStorm
6. 学习和使用的新工具
Github、ProcessOn、StackEdit
7. 学习和掌握的新语言、新平台
Vue.js前端框架、jsoup
8. 学习和掌握的新方法
单元测试
9. 其他方面的提升。
学习能力的提高、团队合作能力的提高、项目开发能力的提高
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
- 在项目开发的过程中，团队之间的沟通非常重要，比如我们团队在Alpha阶段初期，由于团队成员之间的沟通不足，导致前后端开发人员在对于需求的理解上出现了一些偏差。
- 在项目开始前，对于任务的细化安排非常重要，比如我们团队在Beta阶段对于任务的安排比较细致，每位成员都知道自己每天需要完成的任务，使得整个开发过程都比较顺利。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
对下一届实践的建议：既然软工实践是一门必修课，与其抗拒这门课，不如学会接受，在实践的过程中提高自己的学习能力，加深自己对于软件项目开发的理解，尤其是对于缺乏项目经历的同学。
对于开学初的我：提高效率，把握时间
对于大一的你：好好学习，争取保研，不要以为上了大学就可以放松了。
对于后来人的期许：希望后来人可以以更大的热情投入到这门课中，并在这门课中有所收获，开发出高质量的软件产品。
下一届要不要中途换队员：要中途换队员，因为人员的变动确实是软件项目开发过程中会遇到的问题，但是希望换队员可以是团队之间交流后的结果，交换能力和开发方向相近的同学，而不是简单的随机抽签。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
《构建之法》上说团队的发展有四个阶段，分别是萌芽阶段、磨合阶段、规范阶段、创造阶段，我的团队经历了前三个阶段，可能还没有达到“创造”阶段
萌芽阶段：从团队展示到项目原型设计阶段，我认为我们团队是处在萌芽阶段，团队成员之间刚刚互相认识，依赖于团队领导的指导。
磨合阶段：从项目需求分析开始到Alpha阶段结束，我认为我们的团队是处在磨合阶段，大家都在积极的适应队友，一起克服遇到的困难。
规范阶段：在Beta冲刺阶段，我认为我们的团队就进入了规范阶段，团队的成员们对自身的角色，职责都非常了解。
五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
软件经过了同学们的试用，并且获得了较好的反馈。
部分用户展示：
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
团队在整个项目开发的整个过程中都有详细的规划和任务分工，确保项目能够在预计的时间内发布，并且保证每个人都参与到项目的开发中。
部分项目计划安排截图：
3）并且通过数据展现软件是可以维护和继续发展的。而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
项目Github地址：
接口文档地址：http://evaluation.huanglexing.com/swagger-ui.html#/
六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
阅读的论文文献：Code quality analysis in open source software development
本文中作者提出Eric Raymond在其论文'The Cathedral & the Bazaar'中提出的关于开源过程的两个基本原则，'release early and release often'（早发布，经常发布）和'given enough eyeballs all bugs are shallow'（给予足够多的眼球,所有的错误都是肤浅的），我觉得确实非常形象地表达出了开源的好处，这也让我意识到以后要多将自己的代码开源，与他人分享交流，这样才可以不断地提高自己的代码质量。
参考论文文献：
[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.
[2] Boehm B W, Brown J R, Lipow M. Quantitative evaluation of software quality[C]//Proceedings of the 2nd international conference on Software engineering. IEEE Computer Society Press, 1976: 592-605
[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
七、个性发挥，包括图文、照片和创意等
感谢我们整个团队的成员，感谢你们给予我的帮助，也感谢老师和助教们一整个学期的辛苦付出。
最后附上团队合照一张：