软工总结

软工总结

一、链接到以前提问题的博客

第一次博客作业

二、请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。

1.在**“好看的GPA”**与**“完整的知识体系”**中，势必要有所侧重，但这个侧重的度究竟是怎样的？**GPA**与**知识体系**两者在未来对自身的影响究竟是怎样的？

对于这个问题，通过这个学期的软件工程课程以及其他课程的学习，笔者已经有了自己的认识：这两者其实并不是那么冲突——构建了完整的知识体系后，自然会对这一学科的学习有较为全面的认识，成绩自然也不会太差；而即使是通过刷题、突击的方式来争取一个不错的成绩，那么在这个过程中，其实也已经了解到了这一门课程的重点、难点究竟是什么，以及如何攻克它们。

2.对于一些初学者来说，他甚至不知道哪些问题是不可以绕过的，哪些问题是可以解决的，哪些问题是很难解决的。那么对于不同的人来说，究竟该如何走出或者从根本上避免陷入类似的误区呢？

在本学期的两次开发过程中，我对这一问题的认识尤为深刻。开发过程中用到的所有知识几乎都是要通过自学完成的，难免会遇到障碍。这一知识如何应用到这一问题上？切入的角度是否正确？甚至该不该用到这上面来？当然，可以通过咨询他人的方法来解决。但最主要的，我当初提出的这个问题本身其实就是一种能力，培养这种能力在未来的学习生活中是及其必要的。

3.虽然摆脱国外操作系统“垄断”，对于我们民族的伟大复兴来说，是很有意义的一步，但究竟应该如何做到呢？从更小的规模来说，如果创新者的研究方向恰好是已经几近于成熟的，那他的创新还有意义么？

经过一学期的学习，我对这个问题的看法已经有所改变。诚然，创新不可能一帆风顺，而其有很大的风险会面临着失败。然而与第二个问题类似的是，创新者如何评估创新的风险。综合考量创新的成果、失败的风险，来决定是否走上创新之路是每个you这想法的人必须要做的工作。即，不打无准备之仗，大胆的创新并不意味着大胆地决策，相反，倒需要决策者有一定的远见。

4.我们究竟该如何**在小的创新被整合之前**，发现这些小的创新的价值？如果不对这些小的创新给与相应的激励，最终会不会形成一种不愿有人当**创新者**，都想去当**“整合者”**的风气？

提出这个问题时，我可能对于软件开发相关的领域了解不是深入，其次，个人的侧重点也有所偏颇。其实这一领域还是相当开放的，并不存在那么多铜臭味的纠葛，相反，大多数人都是为了有所贡献而贡献，比如开源。

5.在一些学生遇到难题时，如何避免“高动力低能力”的学生，逐渐变为“低动力低能力”或者是“高能力低动力”的学生？谁来担当这个“领导者”的角色？有哪些有效的举措呢？

这个问题可能因人而异，毕竟每个人的经历都不一样。但就我自己而言，这个问题至今依旧没有一个明确的答案。

三、是否原来的问题还不明白？如果有，请分析。

• 见（二）5.

四、是否产生了新的问题？如果有，请提出。

• 无，倒是有很多收获。

五、请问你们在项目的 需求/设计/实现/测试/发布/维护阶段（一共6 个阶段）中都学到了什么“知识点”，每个阶段只要说明一个知识点即可。

阶段	收获
需求	需求本身对项目效果的影响真的很大，但由于我们组是指定命题，因此基本不涉及这一问题
设计	好的设计能够在实现阶段省去很多烦恼，也许需要设计者对实现的相关技术有一定的了解，而不是像一个甲方
实现	对于新手而言，学习的效率基本上决定了实现阶段的成果好坏
测试	测试本身应该是穿插在实现过程中的，而非线性的承接于实现过程
发布	发布不会影响产品本身的好坏，但会影响甚至决定大众对产品了解与认可程度，即销量
维护	我认为维护就是实现的对立面，实现的好，维护的工作就轻松；实现的差，维护的工作就困难

六、结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得

• 由于同组的老哥们都十分好说话，而且基本不存在拖拉的情况，都是尽力而为，因而很少会因为对别人的工作不满意。
• 对于每个人各自的工作，应该是六分靠学习，三分靠实践，一分靠沟通。虽然课程尽可能地模仿真实的开发流程，但毕竟还是有很大的区别。产品需求、发布时间等等无法自行把控，可能有些遗憾。
• 最后针对个人项目与结对编程，希望课程组能够对结果有一定的反馈，而不是仅仅回复一下博客、打个分数就结束了。否则我会认为这两个环节意义不大。