个人作业——软件工程实践总结作业
| 这个作业属于哪个课程 | 软件工程1916|W（福州大学） |
|---|---|
| 这个作业要求在哪里 | 个人作业——软件工程实践总结作业 |
| 学号 | 221600307 |
| 这个作业的目标 | 总结本学期软件工程实践课程内容。 |
一、请回望暑假时的第一次作业，你对于软件工程课程的想象
1）对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？
我在这个课程的目标是：通过实际项目将理论与现实相结合，在实践中掌握更多知识，培养更多能力。 期待这门课能够让我对软件工程有更清晰的认知，希望能交出一份不错的答卷。
这是学期初我对这门课的期待，期末回顾，我觉得已经基本实现了我的期待，一个项目从策划、分析到实现、测试，如何在一个小组中最大化地发挥自己的作用，如何和别人合作共同尽可能完美地达成一个目标等等，都是在实践中学到的内容。当然这也多亏我的队友们都是很好的人，互相帮助才能学到更多。
2）总结这门课程的实践总结和给你带来的提升，包括以下内容：
-
统计一下，你在这门软件工程实践中，完成了多少行的代码；
- 在各次作业完成过程中其实我的代码量并不算多，因为小组作业时我主要在做UI设计、测试以及各种文档撰写。结对编程300行左右，GitHub实训约500行，校招平台1000多行。
-
软工实践的各次作业分别花了多少时间？（做一个列表）
作业名称 花费时间(h) 第一次作业——准备篇 3 结对第一次——原型设计（文献摘要热词统计） 12 结对第二次—文献摘要热词统计及进阶需求 10 团队作业第一次—团队展示 2 团队作业第二次—项目选题报告 10 团队第三次-项目原型设计 16 团队作业第四次-项目需求分析 20 团队作业第五次—项目系统设计与数据库设计 5 团队作业第六次—团队Github实战训练 20 项目Alpha冲刺（团队） 50 事后诸葛亮（团队） 3 项目Beta冲刺（团队） 40 Beta阶段团队项目互评 6 个人作业——软件工程实践总结作业 3 总计 200 -
哪一次作业让你印象最深刻？为什么？
- 印象最深刻的是α冲刺，因为时间紧，任务重，所以每一天大家都在争分夺秒地赶工，而且由于前期任务完成的欠缺，导致大范围返工。经此一役大家都得到了教训，每一阶段都需要尽心尽力，千万不能抱有这次没做好下次弥补的侥幸心理。
-
累计花了多少个小时在软工实践上？平均每周花多少个小时？
- 由上表可看出，各次作业累计完成的时间已经有约200h，还有一些课外学习的时间，零零总总算下来大概有240h左右，平均每周花费20h，已经大大超出我当初对这门课的预期。
-
学习和使用的新软件&新工具
- 原型：墨刀
- 测试：Emmagee、iTest
- 代码管理：GitHub
- markdown：Typora
-
学习和掌握的新语言、新平台
- 不算新语言吧，是旧语言但新技术，安卓开发。开发平台是AndroidStudio和IDEA。
-
学习和掌握的新方法
- 各种测试方法。
-
其他方面的提升
- 在与人合作方面有很大提升，还有如何同时进行多种任务，各种文档的撰写以及对一个项目流程的把控。
二、写下属于自己的人月神话
团队开发最重要的就是协作和配合，在完成项目的过程中文档是非常重要的，小组成员在开发时不能只一根筋地埋头苦干自己被分配到的任务，需要时时跟进其他人的进度，检查自己的完成部分和其他成员是否契合。我们小组前期就是因为成员之间没有协调好，在代码完成过程中没有检查先前阶段的文档，导致最终的客户端界面和原型有很大出入，前后端接口之间也总是有出入，常常要改。后期我们对这个问题进行了改进就大大减少了问题出现的次数。
三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。 特别地，特别地，下一届要不要中途换队员？
- 对于大一的我：课外学习是非常重要的，不要局限于课堂和课堂作业，尽量多积累项目经验，多看多学多写。
- 对刚开学的我：在此为你点播一首歌——建议是看开点。把握时间，创造奇迹。
- 对下一届的建议：学期初就要对自己整个学期进行大概的规划，结对编程和小组项目选择组员都是非常重要的。和组员的熟悉程度、大家的技术掌握程度都是需要考量的点。不要因为怕错就不做，迈出一步之后的９９步就会更容易走。而且希望下一届学生在选课前能够清楚课程的上课形式，不然容易在后期产生抵触心理。
- 对于中期换人：作为被选中替换的人，在紧张的β阶段难以快速上手一个已经趋于完整的项目，小组其他成员已经一起完成过８次作业，我作为空降人员初期总觉得格格不入。不幸中的幸运是交换后的小组我需要做的工作此前已经有一定的知识积累，否则只能作为团队边缘人物完成一些无关紧要的任务，新组旧组项目成功的喜悦全都与你无关。对于小组来说，如果一开始就抱着迟早会有一个人被换走所以不能让任何一个人成为组里的绝对核心的想法，那么开始就注定了项目的失败。当然不排除有一些组前期组队时由于成员之间相互的不了解所以后期磨合出现问题产生换人的想法，我的建议是谁想换谁换，不想换就不换，毕竟在实际的工作场景中硬逼一个后端开发去做界面设计的情况也是绝不可能发生的。这门课并不教授技术，只是依靠学生此前的技术积累，旧组在选题时已经考虑过所有人的技术侧重，而后期贸然做出随机替换的决定不仅草率而且丝毫没有顾及到实际情况。大三下学期课程非常多，光是各科的作业已经让人感到疲惫，我想学生是否有自己选择的权力呢？
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章 人、绩效和职业道德）
-
萌芽阶段
组内成员提出选题建议，讨论、击碎、重构并采纳的过程。
-
磨合阶段
初期文档不规范或者文档没有考虑归纳到的情况，代码、接口等等在α阶段常常出现差错，所以需要改正、磨合。
-
规范阶段
后期重新制定了各种规范，代码与接口规范在之后阶段大有帮助。
-
创造阶段
暂未达到。
五、怎样证明你学会了软件工程？
1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量 （3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件
在内测及小组互评阶段我们的应用都得到了较好的评价，用户满意度较高，对于现有功能较为满意，我们在开发时也非常尽心尽力，并不只是为了完成这门课的作业敷衍了事。由于现阶段ａｐｐ功能已较为完善，我们后续还会再进行完善维护，如果有机会希望能投入使用。
用户使用手册
2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布 ； 而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄
在持续两个月的小组作业里可以通过一系列博客的发布看出我们项目的流程规划和实现过程，每个阶段的任务都按时甚至提前交付，基本在计划之内。
3）并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料
所有的代码都有GitHub存档，迭代过程可在ｔｅａｍｂｉｔｉｏｎ查看，编写过程就已经考虑到后续的拓展、维护过程，代码具有良好的可扩展性，并且有完整的相关文档可供查阅。
六、个性发挥
此时无声胜有声。
