一、请回望第一次作业，你对于高级软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
本次我们小组的项目主要用到的技术是，前端用到bootstrap框架和anjularjs，HTML，css，后台用Sqringmvc框架，java语言进行开发的。在本科阶段大都是自己一个人做项目，缺乏团队的意识。在本次的项目开发中，收获最大的是项目管理上的锻炼，增强了团队的意识，学会了如何与团队其他成员进行更有效的沟通，提高开发效率。其次，虽然经过本次的项目实践，代码能力相比之前有很大的提升，但是还是远远不够，在实际开发过程中也因为能力的不足使得项目不能按原计划完成，希望在日后继续努力，提升自己的代码能力，为团队做出更大的贡献。
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
- 统计一下，你在这门高级软件工程实践中，完成了多少行的代码
按模块统计，在这次高级软件工程实践中，完成的大约14000行代码。
- 高级软工实践的各次作业分别花了多少时间？（做一个列表）
| 作业 | 花费时间（博客+代码） | 作业 | 花费时间（博客+代码） |
| 高级软件工程第一次作业 | 2h | 项目Alpha冲刺Day11 | 0.8h |
| 高级软件工程第二次作业 | 7h | 项目Alpha冲刺Day12 | 0.7h |
| 第一次结对作业 | 8h | 设计模式第三次作业 | 7h |
| 高级软件工程第一次作业 | 1.5h | 测试随笔 | 2h+10h |
| 第二次结对作业 | 24h | 总结随笔 | 1.5h+10h |
| 团队选题报告 | 3h | 集合随笔 | 0.4h+10h |
| 设计模式第一次作业 | 4h | 城市安全风险管理项目Postmortem结果 | 1h |
| 团队项目-需求分析 | 3h | 项目Beta预备 | 1h |
| 设计模式第二次作业 | 8h | Beta冲刺第一天 | 0.5h+7h |
| 项目Alpha冲刺Day1 | 0.8h+7h | Beta冲刺第二天 | 0.5h+7h |
| 项目Alpha冲刺Day2 | 0.7h+7h | Beta冲刺第三天 | 0.5h+7h |
| 项目Alpha冲刺Day3 | 0.8h+7h | Beta冲刺第四天 | 0.5h+12h |
| 项目Alpha冲刺Day4 | 0.6h+11h | Beta冲刺第五天 | 0.5h+7h |
| 项目Alpha冲刺Day5 | 0.5h+7h | Beta冲刺第六天 | 0.5h+10h |
| 项目Alpha冲刺Day6 | 0.7h+11h | Beta冲刺第七天 | 0.5h+10h |
| 项目Alpha冲刺Day7 | 0.8h+11h | Beta冲刺总结 | 1.5h+10h |
| 项目Alpha冲刺Day8 | 0.8h+7h | 用户调查报告 | 3h |
| 项目Alpha冲刺Day9 | 0.7h+7h | Beta冲刺集合 | 0.5h |
| 项目Alpha冲刺Day10 | 0.7h+7h |
- 哪一次作业让你印象最深刻？为什么？
作业中包含个人作业和团队作业。团队作业让我比较印象深刻。其中最让我印象深刻的是团队作业中的最终项目总结。在做项目总结的作业时，脑子里浮现的是这几个月来与团队成员一起奋斗的画面，为能完成本次项目感到兴奋与自豪。
- 累计花了多少个小时在高级软工实践上？平均每周花多少个小时？
累计花在高级软件工程的软工实践上大约240小时。Alpha和Beta阶段大约花费3周时间。故平均每周花费80小时。
- 学习和使用的新软件；
开发软件IntelliJ IDEA、ProcessON（画图、Git(版本控制)、RP（原型设计）、svn（版本管理工具）
- 学习和使用的新工具；
Github（一个代码托管平台）、博客园
- 学习和掌握的新语言、新平台；
anjularjs，sqring mvc框架、bootstrap前端框架
- 其他方面的提升。
项目管理方面的提升，有效的沟通。
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
定义：
三个以上的个人实践根据某种规则密切联系成为一个统一的整体，我们称这样的总体为团队实践。
性质：
团队实践应具有以下性质：
- 团队中的个人都要遵守统一的团队规则
- 在形式上，个人之间是独立的，可以并发执行
- 在内容上，个人实践是紧密联系，缺一不可的
- 个人实践之间应该两两互不矛盾。这个包含两个层面：个人的代码不会影响其他人的结果，同时自己的代码不会受其他人的代码影响。
鉴于以上性质，加上自己的实践，总结出以下经验：
本次项目的开发过程中，每当遇到问题时的迷茫，以及解决难题时的快意，都让我们印象深刻。在项目的收尾阶段，将对我们遇到的问题进行一些总结，分享我们的项目经验与教训。
需求分析阶段。只有充分了解了用户的需求才能开发功能完整、性能良好的产品。所以前期的市场调研，各个功能模块的详细描述显得非常重要。
数据库的设计。一个项目的开发必然离不开数据的交互。在本次的项目过程中，因为底层封装的东西，设置数据库字段不能出现大写字母，调用一些底层的方法无法实现，折腾了很长时间才解决。所以数据库的设计显得格外的重要。
测试。测试环节也是项目开发过程中的一个重要环节。这次我们团队测试分为两个阶段：第一个阶段为组内成员之间进行交叉测试、第二阶段让学长学姐充当用户进行第二轮测试。这样测试的作用避免存在局限性，开发人员测试自己模块时，往往会下意识的不去输入一些非法数据。
分工与合作。由于团队成员之间存在能力上的不同，故任务的分配显得非常重要。分配得当，会带来很多好处，大大提高开发效率。
沟通。在实际生活中大家都在强调够沟通的重要性。经过本次项目的实践，深有体会。在分派任务时，没有和谐的沟通，就很可能把做正确的事和正确的做事混为一谈。准确地说，正确地做事必须要以做正确的事为前题，如果没有做正确的事，正确地做事就没有意义。
整体性能与用户需求。一个产品的开发最终是要提供给用户使用。故在开发过程中应该站在用户的角度思考问题。在本次项目的测试阶段就发现这个问题，开发人员往往被很多习惯限制了自己的思维，没有想到用户是不懂程序的，没有对一些非法的输入进行处理，导致最后程序的崩溃，数据的丢失等等。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？
理论必须与实践相结合才有意义。《构建执法》中强调learning By Codeing。根据个人的经验，作为一门实践课程，如果只是在课上学习一点理论知识，而不把理论运用在实践上，过不了多久就忘得一干二净，只有在实践中才会发现自己的不足，慢慢完善自己。对下一届学弟学妹的意见是，趁年轻多学点东西，这门课完全可以满足你在动手能力上的需求，加入软工实践，会收获很多你意想不到的东西。
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
√ 萌芽阶段√ 磨合阶段√ 规范阶段√ 创造阶段。
我们团队经历着这四个阶段。从大家一脸蒙蔽，个人角色和职责都不清楚，不知道自己该做什么，该往哪里去的萌芽阶段到大家对同伴和团队的疑惑和冲突，在组长的带领下，大家相互信任，解决冲突，能够有效的沟通，逐渐进入规范阶段。进入规范阶段，我们就角色，职责定义，人员分工，和开发流程都能取得比较一致的意见，作为一个整体，团队要做什么，不做什么，都相比前面两个阶段更加明确。团队的信心更足。经历了萌芽阶段、磨合阶段、规范阶段，现在团队终于可以创造一些有意义的东西。
五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
请在随笔中用数据证明上述内容或侧重选择之一。
在博客中可以看到我们项目经过选题、需求分析、原型设计、代码实现、用户测试、最终成果。选题报告：http://www.cnblogs.com/zlxbky/p/7774087.html。
需求分析：http://www.cnblogs.com/zlxbky/p/7834324.html。
原型设计、代码实现、用户测试：http://www.cnblogs.com/zlxbky/p/7986891.html
http://www.cnblogs.com/zlxbky/p/8124241.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
七、个性发挥，包括图文、照片和创意等
