个人学期总结

Posted 2020-12-04 jyxing

一、学期初，实验一中的任务4，大家拟定了5个准备从课程学习中找到答案的问题，通过一个学期的学习，相信大家已经有了答案，请根据自己的学习实践回答自己当初提的问题，并提出一个新的问题。

1、单元测试，是在所有模块整合完了，再测试？还是在还没有整合前，单个模块单个模块的测试？如果整合完了，那代码的量不就多吗？如果没整合，但是在整合完还是要测试，那当时的测试不就没意义了吗？

单元测试是在没整合之前测试，整合之后再整体测试。

2、若用户需求和优化后的软件起冲突时，要按照用户的需求继续做还是优化的软件？

若发生这种情况则取决于多种因素，阅读课本理解，功能是核心功能、外围功能还是辅助功能，理解用户对产品的误解需要做用户调研，也要对用户做画像，分析此用户是核心用户还是酱油用户，他的需求对产品市场的影响因子是怎样的等等，然后做优先级排序。

3、如何选择合适的团队模式与开发模式？

软件团队的模式有主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐模式、爵士乐模式、功能团队模式、官僚模式。

（1）主治医师模式：一人为主，其他人为此人服务。但容易退化成“一人干活，其人打酱油”的现象。

（2）明星模式：主治医师模式到达极致，一人的光芒掩盖所有人。

（3）社区模式：每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。但如果同一个任务同时几个人都对其感兴趣，就会出现争端。

（4）业余剧团模式：在不同项目中每个人扮演着不同的角色，可能随着项目的改变，自己的角色也会发生变化。

（5）秘密团队模式：一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。

（6）特工团队模式：有一些有特殊技能的专业人士组成的团队。

（7）交响乐团模式：人员工具齐全，准备充足的团队。

（8）爵士乐模式：相对自由，有风险，人少且不靠谱。

（9）功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能；同时也要适应别人的编程规范。

（10）官僚模式：层层领导的团队模式。

我个人比较倾向于功能团队模式和社区模式；我选择这两个团队模式的主要原因在于这两者的共同点—所有人都参与其中，在已选择的这两个模式中，我又更倾向于功能团队模式。功能团队模式中组合—完成—再组合，我觉得这样很棒，有利于团队成员对彼此的熟悉度，也可以让某方面好的同学带着这方面不足的同学，这样还可以提高团队整体能力；

团队的开发模式包括有、写了再改模式、瀑布模型及其各种变形、RUP统一流程、老板驱动的流程、渐进交付的流程、TSP的原则。

渐进交付的流程是我比较倾向的一个开发模式（开发—发布—听取反馈—根据反馈做改进）。在我们发布一款软件之前，哪怕已经做了很充分的市场调研和软件需求分析，也没有人感打包票说我们这款软件一定能火。那这时应该怎么办？放弃项目？自己不甘心，这时我们就可以先完成软件的第一版，把主要功能加以实现，快速的投入到市场中。失败了，损失的也只是个没有过多投入精力的软件。成功了，我们则可以根据用户的需求去完善软件。

4、团队怎样才能成为一流的工程化团队，并且保持旺盛创造力？

就这个学期团队项目来看我个人认为团队中（1）明确制定一个大的战略方向。（2）明确制定一个大的战略方向。（3）确保每周，团队都有可以做的一些事情。这一周我们要完成的工作。（4）好好规划各部门的工作任务，太难了团队完不成，就无所谓了。太简单了，没有成就感觉得水。难度中等偏上，保证工作的挑战性和可实现性。给一个规范的量身定做的工作量。（5）给团队的成员以自由与空间，充分尊重团队成员的个人习惯。（6）允许团队中有小团体的存在，有人的地方就有江湖，就有聚集。这是稳定团队的必要因素。但也要与每个人处理好关系。（7）及时关注团队进展以及听取团队成员意见。（8）让每个员工在他合适的位置上工作。（9）把团队取得的成绩和大家分享。

5、软件质量=程序的质量+软件工程的质量；那么程序的质量怎么理解呢？只是没有bug的程序就是一个好质量程序吗？

程序的质量就是代码的质量，没有语言上的错误，代码量少而精。

新的问题：即使我们经过了足够的测试，还是不能保证在实际运行中不会出错，尤其是当开发面向对象的网站或者软件时候，因为使用对象的多样性会遇到很多问题 。那么在维护阶段出现bug有没有比打补丁更规范适用的方法？

二、课程的实践总结和自身的提升：

1、统计你在软工课程实践中，完成了多少行的代码；

      完成了大约四千多行代码。

2、软工实践的各次作业分别花了多少时间？累计花了多少个小时在软工实践上？平均每周花多少个小时？（做一个列表）

软工作业	花费时间	平均每周花费时间
实验一 软件工程准备	5	7.25
实验二 软件工程个人项目	5	7.25
实验三 软件工程结对项目	8	7.25
实验四 基于原型的软件需求获取	7	7.25
实验五 软件研发团队组建	6	7.25
实验六 团队项目评审与团队项目选题报告	7	7.25
实验七 团队作业3—团队项目的原型设计与开发	8	7.25
实验八 团队作业4—基于原型的团队项目需求调研与分析	9	7.25
实验九 团队作业5—团队项目需求改进与系统设计	8	7.25
实验十 团队作业6—团队项目系统设计改进与详细设计	9	7.25
实验十一  团队作业7—团队项目设计完善&编码测试	8	7.25
实验十二  实验十二 团队作业8—团队项目用户验收评审	7	7.25

3、哪一次作业让你印象最深刻？为什么？

       印象最深的就是实验二结对项目，这是第一次和关系较好的同学一起做项目，因为太过于了解对方的性格和特点，交流起来很是舒服，花费在讨论上的时间大大减少，效率提高了很多。

4、学习和使用的新软件；

       visio

5、学习和使用的新工具；

       process on、墨刀、石墨文档、mockplus

6、学习和掌握的新语言、新平台；

       GitHub、博客园、中国大学MOOC

7、学习和掌握的新方法；

       快速原型方法、白盒测试与黑盒测试、面向对象设计方法

8、其他方面的提升。

      编程能力、文档撰写能力、解决问题的能力、团队协作的能力都有了很大的提升。

三、你认为目前的课程有哪些问题，你有什么更好的建议：

1、你认为本门课程需要在哪里进行改进，具体措施有哪些，包括：时间进度安排，项目难度等均可；

       这门课采用翻转课堂形式是比较新颖的，也学到了很多知识。但由于很多同学要考研复习加之课程较多，可能导致每次布置实验同学们会较仓促，如果时间充分我觉得作业质量会提升很多。

2、你认为助教／老师哪里做的不足，哪里限制太多等；

       助教/老师这一学期虽然工作任务都比较重但对我们都很负责任，给我们的学习提供了很多帮助。

3、你认为每次项目的评分标准存在哪些问题，你认为的合理评分准则是怎样的（个人／结对／团队算三个）

       评分标准合理。

4、在结对项目中你是否真正体会到了结对的好处，是否真正严格进行了结对编程，双方的工作量是否相同；

       结对编程可以多双眼睛，少点bug。在面对问题的时候，会有人一起分担，共同尝试新的策略。通过合理的分工能减少完成项目的时间，提高效率。双方的工作量是不一样的。

5、你的团队项目是否成功，如果重来一次你是否还会选择这个团队，为什么成功／失败；

　　我的团队项目是成功的，如果重来一次我还会选择这个团队，项目的成功是离不开每个成员的努力的。分工明确，积极进取，气氛融洽，没有理由不选择这个团队。

6、总结一下你们团队在做项目时大家的时间安排情况。

　　根据任务的难度和要求进行明确的分工，每个人都有自己的任务，自己根据自己的任务和时间自行安排，遇到问题会在讨论组里讨论。

7、对下一届软工课实践教学的建议，或者对于开学初的你，对于大一的你，对于开学初的老师，你有什么想建议和告知的呢？对于后来人的期许。

      业精于勤荒于嬉，或许你不喜欢这门课程，但这门课程开设是既定的事实，所以请踏踏实实的学习，不要糊弄。该有的思路总得有，该记住的东西总得记住，不是为了别的，就是为了不要让你成为脑残。

四、你还有什么想说得话。

     真诚的感谢代老师以及助教老师的辛苦付出。