一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
达到的期待和目标
- 更加深刻理解了软件工程的整个过程和体系。
- 团队一起推进完成一个可上线项目。
- 增强了自己的实践能力。
- 时间管理/计划意识。
- 文档撰写。
不足
- 很多时候还是想着划水。
- 没有很好地调动团队的积极性。
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
-
1、统计一下，你在这门软件工程实践中，完成了多少行的代码；
作业 代码量 个人作业 300 结对作业 500 团队项目 2100 总计 2900 -
2、软工实践的各次作业分别花了多少时间？（做一个列表）
作业 时间（h） 第一次作业-准备 4 第二次作业 - 个人项目 22 第三次作业 - 原型设计 10 第四次作业 - 团队展示 2 第五次作业 - 结对作业二 30 第六次作业 - 团队选题报告 10 第七次作业 - 需求分析报告 12 第八次作业 - 现场UML设计 7 Alpha冲刺阶段 35 团队现场编程实战（抽奖系统） 8 福大软工 · 第十次作业 - 项目测评 7 Beta 冲刺阶段 20 最终作业 - 软件工程实践总结 2 总计 169 -
3、哪一次作业让你印象最深刻？为什么？
个人项目，感受到了软工实践满满的恶意，也发现了自己是多么菜。 -
4、累计花了多少个小时在软工实践上？平均每周花多少个小时？同时贴出开篇博客“你打算平均每周拿出多少个小时用在这门课上”的回答
169小时。算16周的话，每周超过10个小时，实际上，其他零零碎碎的时间加进去远不止如此。(虽说当时说视情况而定，但是内心想的肯定不超过十小时。
-
5、学习和使用的新软件；
Processon,Visual Studio，也更加熟悉了eclipse的使用。 -
6、学习和使用的新工具；
leangoo，真的是个好东西。
github，之前用过，但是不熟悉，这次也算更加熟悉这一神器了。 -
7、学习和掌握的新语言、新平台；
增强了一点点Java，增强了一点点C，增强了一点点Python。Get到了Processon、leangoo等平台。 -
8、学习和掌握的新方法；
敏捷开发流程，团队管理知识等。 -
9、其他方面的提升。
提升的太多了，执行力、学习能力、开发能力、表述能力等。
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
- 在团队开发中，团队意识比其他都要来得重要，只有团队意识好了整个团队的状态才更加健康。比如，在团队项目初期，团队处于迷茫状态，彼此也没能很好接触沟通，导致一系列后续的事情都得不到团队的统一，更别说是执行了。
- 在结对项目中，好的队友非常重要，我和当时的队友就相处良好，分工迅速，推进也比较一致，结对项目自然也比较顺利。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，对于同期的TA们，对于后来的学弟学妹：
- 1）你有什么想建议、告知和期许想要告诉他们呢？
三分钟热度的就算了，需要花比较多的时间，想划分的人在后期都抱怨=划水>执行。（另队长抗压能力要强QAQ，一度怀疑人生 - 2）特别地，特别地，下一届要不要中途换队员（强制的、彻底的从一队换到另一队）？
假设依旧是一个90+人数的大班。不建议更换队员，甚至是团队解散。中途换队员，沟通成本增加，原本的计划会被略微打乱吧。 - 3）身在一个格外大的班级，竞争强劲，你认为一个组的人数应当在多少比较合适？
9-10人的团队人数在这里面真的是太多了，分工不好分，沟通成本也在增加，队员又会松懈，建议5-6人。 - 4）个人/结对/团队作业应该控制在怎样的规模？
个人作业认为还行吧，虽然第一次作业花了很多时间。团队作业周期太短了，迭代次数不足，按照最后要求应该是一个比较完整的产品，但是其实大部分团队项目还都只是处在demo而已。 - 5）这学期下来，你最感谢的人是谁？有什么话想要对TA说呢？
感谢我的队员，没有怨言，虽然不是很积极，但是都会去执行任务，结果不差，可是我们本不该这样，也是我没有很尽到做队长的职责，如果再来一次，我们是不是该辉煌一次？
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
我任务我们团队已经经历萌芽和磨合阶段进入规范阶段。遗憾的是没有进入创造阶段。
五、怎样证明你学会了软件工程？
- 1）研发出符合用户需求的软件
草履记-一款记录、分享你旅游足迹、故事的产品。目前拥有73用户量（实际上并未正式进行推广），每天都有用户持续打开（特别少）。
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件 - 2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
通过leangoo每两天记录进度，例会，燃尽图等，让团队成员不仅了解自己的任务是什么，还了解自己项目应有的进度，以及和队友的任务进度对比。团队分工较均衡。
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄 - 3）并且通过数据展现软件是可以维护和继续发展的。
团队建设有功能优先图，UI规范文档，Bugs清单以及优化清单，通过github展示维护代码。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料 - 4）对着这个检查表：http://xinz.cnblogs.com/p/3852177.html 检查一下，自己如果去企业面试，这些常见的问题是否都能回答，并在此总结。
很多问题无法回答，主要原因是平时不注重细节，没有时常总结。在接下去的经历中，会吸取教训。
请在随笔中用数据证明上述内容或侧重选择之一。
六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：
参考论文文献：
[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
七、个性发挥，包括图文、照片和创意等
-
来个总结吧。
-
团队项目：草履记。
-
最后是我们的团队照啦，多些各位指教，希望你们在这次团队项目都有所收获，在接下去去的生活中都能活出自己的样子，加油少年！
