个人作业——软件工程实践总结
班级:软件工程1916|W
作业:个人作业——软件工程实践总结作业
学号:221600418
作业目标:总结软工实践
一、请回望暑假时的第一次作业,你对于软件工程课程的想象
1)对比开篇博客你对课程目标和期待,“希望通过实践锻炼,增强计算机专业的能力和就业竞争力”,对比目前的所学所练所得,在哪些方面达到了你的期待和目标,哪些方面还存在哪些不足,为什么?
在开篇博客中提到:希望这门课能让我确定一个深入学习的方向。如果课程符合预期,可能会花较多的时间学习,否则可能自己找一个合适的方向进行学习
在项目开发方面达到了个人期望,了解和参与了项目开发的整个流程
不足方面应该是在团队开发的协同进行方面,在进行过程中出现了矛盾
2)总结这门课程的实践总结和给你带来的提升,包括以下内容:
1. 统计一下,你在这门软件工程实践中,完成了多少行的代码;
团队作业:总共34个文件(34个java文件,1个xml文件,一个yaml文件),总行数1181行(1038行java代码,76行maven代码,46行xml代码,21行yaml代码)
2. 软工实践的各次作业分别花了多少时间?(做一个列表)
序号 | 作业 | 时间 |
---|---|---|
1 | 个人作业第一次—准备篇 | 2 |
2 | 结对作业第一次—原型设计(文献摘要热词统计) | 12 |
3 | 结对作业第二次—文献摘要热词统计及进阶需求 | 20 |
4 | 团队作业第一次—团队展示 | 1 |
5 | 团队作业第二次—项目选题报告 | 9 |
6 | 团队作业第三次—项目原型设计 | 13 |
7 | 团队作业第四次—项目需求分析 | 9 |
8 | 团队作业第五次—项目系统设计与数据库设计 | 9 |
9 | 团队作业第六次—团队Github实战训练 | 8 |
10 | 团队作业第七次—项目Alpha冲刺 | 28 |
11 | 团队作业第八次—事后诸葛亮 | 2 |
12 | 团队作业第九次—项目Beta冲刺 | 20 |
13 | 团队作业第十次—Beta阶段团队项目互评 | 6 |
14 | 个人作业第二次—软件工程实践总结作业 | 3 |
总计 | 142 |
3. 哪一次作业让你印象最深刻?为什么?
【项目Alpha冲刺(团队) 】的印象最深。
从选题开始,到原型设计,项目需求分析等等,终于从理论的阶段到正式的编码阶段,经历一次完整的项目开发流程,与他人协作开发软件。到最后对接过程中不断的debug,收获很多。
4. 累计花了多少个小时在软工实践上?平均每周花多少个小时?
总的大致应该有140小时左右的时间,远远超过了在其他课程上的时间,平均下来每周花费的时间也有12个小时
5. 学习和使用的新软件&新工具;
idea、墨刀和GitHub
6. 学习和掌握的新语言、新平台;
Spring Boot
7. 学习和掌握的新方法;
Spring Boot的单元测试,maven的使用
8. 其他方面的提升。
对项目开发流程的了解,及debug能力的提升
二、写下属于自己的人月神话——个人或结对或团队项目实践中的经验总结+实例/例证结合的分析
团队协作开发不同于个人开发,开发文档对于团队的开发十分重要。还有就是对项目功能的把控上面,还是需要有特色或者是亮点吧。
1.在alpha结束到beta冲刺之前,由于那段时间我没有还对项目进行后续功能的开发,而另一个后端已经开始完成一些beta功能的开发,没有对拓展功能进行深入的讨论,当beta冲刺时间,我觉得他已完成的功能没能达到beta冲刺的目标,就按照beta冲刺对功能的要求重新设计了新的表,修改了一些原有的表,导致我们俩发生了激烈的冲突。也体会到了协作开发与个人开发之间的区别。不能只站在自己的角度看待问题,还是需要在开发前做好协商
2.我们参考了已有的一些类似的软件,在alpha冲刺中完成了大部分的要求,导致我们指定beta冲刺计划时有些迷茫,又经历的换人,最终beta阶段的成果不大能令自己满意。
三、对下一届实践的建议,或者对于开学初的你,对于大一的你,对于开学初的我,你有什么想建议和告知的呢?对于后来人的期许。 特别地,特别地,下一届要不要中途换队员?
告知: 这样的实践模式非常有利于学习软件开发过程的具体流程,体验理论课上讲述的各个阶段,不过确实是十分辛苦,尤其是在作业截至日期前的debug。总体上占用的时间远超预期,收获也是非常多
关于是否要换队员:对于换人,确实对团队的影响还是非常大,由于我们团队换进来的队员对前端框架不熟,能在短时间能接手任务并完成任务,已经很不错了,但是我们也由于换人,一些想做的任务没办法完成,最后的beta成果只能说是alpha阶段的查缺补漏。所以我对换人的态度,支持换人,但是希望是民主的换人,比如可以由个小组自己决定,可以提前了解其他小组的各成员的工作内容,然后由能力和工作内容相近的同学进行互换,减少由于换人而导致的作业质量的下降
四、分析一下自己所处的团队。软件工程实践是大学里少有的认真的团队协作经验。《构建之法》上说团队的发展有几个阶段,你的团队都经历过么,最后到达了“创造”阶段了么?(参考《构建之法》第17章 人、绩效和职业道德)
- 萌芽阶段
由小组成员各自去寻找需求,提出对选题的描述,经过讨论和投票筛选定下选题,并按照大家的兴趣进行分工,和对任务的分割 - 磨合阶段
由于在项目进行之前,我们就修订了详细的文档和接口,所以在进行和对接过程中的问题比较少,主要是发现bug和修改bug - 规范阶段
通过制定代码规范与接口文档,在开发过程中都遵循着代码规范与接口文档,使得代码的可读性和开发的效率有很好的提高 - 创造阶段
还没有达到这个高度
五、怎样证明你学会了软件工程?
1)研发出符合用户需求的软件
必须公开发布,有实际的用户,一定的用户量和持续使用量 (3 天后能保持10 - 100个用户);而不是: 做没有用户使用的软件
所在的团队通过beta冲刺后,项目的累计用户量及访问人数如下:
(数据来源:微信官方小程序 - 小程序数据助手)
2)通过一系列工具,流程,团队合作,能够在预计的时间内发布 “足够好” 的软件
有项目规划/需求/设计/实现/发布/维护,有定时的进度发布 ; 而不是: 通过临时熬夜,胡乱拼凑,大牛一人代劳,延迟交付等方式糊弄
在开发之前,在人员上我们就对每人的角色进行了划分,我们也对项目根据各个模块进行了分割,所有在开发与联调上出现的冲突和问题不是很好,保持着良好的开发效率
3)并且通过数据展现软件是可以维护和继续发展的。
而不是 找不到源代码,代码无文档,代码不能编译,没有task/bug 等项目的发展资料
由于在项目开发之前,经历了选题,原型设计,需求分析,系统设计与数据库设计,有良好的开发文档,在开发过程中,我们也做了自己团队的代码规范文档和前后端接口文档,项目的源码也可以在github上查看