个人作业——软件工程实践总结作业

最新推荐文章于 2024-11-16 08:09:50 发布

weixin_33775572

最新推荐文章于 2024-11-16 08:09:50 发布

阅读量192

点赞数

文章标签：移动开发 java git

原文链接：http://www.cnblogs.com/emperor-fa/p/8120328.html

版权

作业链接： https://edu.cnblogs.com/campus/fzu/SoftwareEngineering2015/homework/1545

个人作业——软件工程实践总结作业

四个月时间，软工实践匆匆结束了，一如承诺在临近期末复习前收尾。不知道你们的软工实践是很慢的煎熬，还是很快的逝去；是平淡如水的无聊，还是留下一点以后会想起的回忆。Anyway，总算结束啦。当然，我也会起一篇，写下我这学期的软工总结，以及希望寄语你们的话。

软件工程实践即将结束，布置结束前最后一次作业，每个同学都要写一篇博客

作业要求

一、请回望暑假时的第一次作业，你对于软件工程课程的想象

1.对比开篇博客你对课程目标和期待，“希望通过实践锻炼，增强计算机专业的能力和就业竞争力”，对比目前的所学所练所得，在哪些方面达到了你的期待和目标，哪些方面还存在哪些不足，为什么？

对比目前的所学所练所得，在编码方面有了一定的进步，一方面对java有了进一步的了解和掌握，这有利于后面的学习，另一方面对Android开发有了初步的涉及和实践，虽然不是特别懂，但还算有所了解；在写文档方面有了飞越的进步，刚开始我对此还不屑一顾，以为作为一名软件工程师，写文档并没有什么帮助，然而后来我才意识到写文档的重要性，通过写文档，对编码的总结和学习有非常大的帮助，而且可以锻炼自己的逻辑思维能力和代码大局观的掌握，另外对我个人还有自己对五笔输入法的练习；在软件工程方面，学会了开发一款软件的过程阶段、原理、结构、方法等等，还有对结对编程有了一定人实战和经历，对软件开发有了一定的了解和实践，对自己以后的就业和工作奠定了一定的基础。
不足：在编码方面，由于对java和Android之前未有了解，java也就是只学习了基础，所以在软件开发阶段，只能在网上找开源代码，修改开源代码时也感觉很吃力，都得靠百度，所以在编码方面需要提高，在写文档方面，只会根据题目来一点一点回答，不会自己做相应的扩展。在软件开发方面，由于是第一次进行团队编程，所以感觉我还是蛮分离的，只是完成自己的功能实现和整合，其他时间没有太多的交流和交涉。

2.总结这门课程的实践总结和给你带来的提升，包括以下内容：

1）统计一下，你在这门软件工程实践中，完成了多少行的代码
4500+
2）软工实践的各次作业分别花了多少时间？（做一个列表）

作业	时长
软件工程实践2017第一次作业	3
软件工程实践2017第二次作业	10
结队项目——第一次作业	7
团队第一次作业——团队展示	0.05
结对项目——第二次作业	24
团队作业—选题报告	3
个人技术博客（α）	4
团队作业—需求规格说明书	3
团队作业—预则立&&他山之石	1
团队作业——系统设计	4.5
团队作业——UML设计	3
团队作业——随堂小测（同学录）	8
个人作业——软件产品案例分析	7
团队项目课堂展示	0.5
团队项目测试报告与用户反馈	1
团队Alpha博客链接目录	0.05
团队事后诸葛亮博客	1
Beta冲刺博客集合贴	3
个人作业——软件工程实践总结作业	4
Alpha和beta阶段敲代码	100

3）哪一次作业让你印象最深刻？为什么？
alpha阶段冲刺，因为那是我第一次接触到Android开发，有一定的期待和兴趣。
4）累计花了多少个小时在软工实践上？平均每周花多少个小时？
300小时，平均每周花20个小时。
5）学习和使用的新软件
Android Studio、MindMaster
6）学习和使用的新工具
墨刀、markdown
7）学习和掌握的新语言、新平台
java ，git，博客园，GitHub、Android平台
8）学习和掌握的新方法
原型设计、团队协作、单元测试、查看错误、代码调试、测试数据、uml设计，需求规格说明书，系统设计，软件测试、commit和git
9）其他方面的提升
对百度更熟练了，学会了怎么查找开源代码和修改别人的代码；还有写文档能力，画流程图和数据流图，思维导图。

二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析

因为我是对android是一张白纸，从未接触过或接触不多，开始时妄想先学习再实践，然而android不是短时间内能学会的，不仅耽误了作业，而且浪费了不少时间。我在开始时想学一点基础，发现短时间内根本来不及，就算浏览一遍记住一些也是拔苗助长毫无作用，所以当初应该只需了解一下开发工具就直接上手找开源代码，如老师所说的learning by doing。还有一个就是要使用团队项目的代码，你若是独立于团队项目的代码开发分配给自己的功能或界面，在整合时可能会出现一些自己意想不到的错误或者代码冲突，比如我写分享功能后整合时导致闪退的问题。

三、对下一届实践的建议，或者对于开学初的你，对于大一的你，对于开学初的我，你有什么想建议和告知的呢？对于后来人的期许。特别地，特别地，下一届要不要中途换队员？

如果不是必修，请一定要慎重选择，如果你选择的原因是为了掌握一门语言或者是为了学会使用一个工具，那你就别选了，因为这门课并不会教你语言和使用软件，这门课的目的是体验软件的开发过程，一切得靠自己学习和摸索，还有就是如果你觉得写文档很烦，那也别上了，因为这门课的作业都是通过写博客来提交和展示，如果文采不好，写得也不会很好。
如果是必修或者你本身有很大兴趣或锻炼自己等其他原因你上了这门课，软工实践是一门很累的课程，甚至有时候会觉得累死累活，毫无收获。但是其实软工实践是一个很好的机会云尝试和经历，从中可以学到很多，比如现实社会公司中的软件开发流程，会让你劳累，让你无奈，让你无助，但亦会让你成长，让你进步，让你飞越。但是我并不同意不报软工实践，理论课就毫无意义，因为毕竟目前对我们来说开发一款好的软件还是太嫩。我觉得，下一届需要中途换队员，其一，不仅可以模仿真实职场的不测风云，而且可以考验团队的应变能力和团队凝聚力。试想一下，在真实场景遇到这种情况该怎么办呢，提前经历到时也有个心理准备，而且这种情况的确是有可能经常发生的，所以我觉得还是很有必要。

四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段，你的团队都经历过么，最后到达了“创造”阶段了么？（参考《构建执法》第17章人、绩效和职业道德）

萌芽阶段：这个阶段当然是选题了，当时大家侃侃而谈，犹如一群壮志未酬的才子一般，满怀创意和期待。
磨合阶段：这个阶段应该是写alpha阶段前期，这个阶段，大家的代码风格有了一定的
接触和磨合，交流也越来越多，甚至还会有矛盾，后来阶段小测同学录对磨合起了巨大的作用，因为当时时间紧，任务重，所以大家同仇敌忾，加快了磨合的脚步。
规范阶段：alpha阶段后期，讨论较为融洽，进程有条不紊，分工明确，大家的默契度较高，但是在规范阶段，要改变自己的代码风格和习惯有一定的困难和不适应。
创造阶段：这个时候是beta阶段，我认为我们并没有达到创造阶段，我觉得可能是因为之前付出太多，太辛苦，因为我们都没学过，只靠自己学习和摸索，一个小问题都要搞好久，所以导致大家对beta阶段没有什么激情，因为精力和激情都用光了。

五、怎样证明你学会了软件工程？

1）研发出符合用户需求的软件
必须公开发布，有实际的用户，一定的用户量和持续使用量（3 天后能保持10 - 100个用户）；而不是: 做没有用户使用的软件

我们并没有公开发布，只是找同学和朋友来试用和使用，以获得建议和功能性bug。

2）通过一系列工具，流程，团队合作，能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护，有定时的进度发布；而不是: 通过临时熬夜，胡乱拼凑，大牛一人代劳，延迟交付等方式糊弄

3）并且通过数据展现软件是可以维护和继续发展的。
而不是找不到源代码，代码无文档，代码不能编译，没有task/bug 等项目的发展资料

软件的源码和文档都在GitHub上，并且都是可编译运行的。我们采取的是自认为彻底完成所分配的任务时再上传，而不是完成一小部分就commit，所以可能源码或文档的commit数较少，更新速度慢，但是是完全可以维护和继续发展的。

六*（选做）、阅读软件工程中关于代码质量的的经典论文，从下列文献中选择一篇或若干篇，结合自己的实际做一个阅读笔记（例如，自己写的代码质量如何，是不是一个大泥球，如何衡量自己代码的质量）？从以下参考论文中选择一篇或若干篇：

参考论文文献：

[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