【2020高等软工课程总结】
【2020高等软工课程总结】
前言
1月14日，高等软工课程终于结束了，说是终于，因为这门课与其他课程相比，确实是需要耗费更多的时间精力，也遇到了不少挑战。每个人对此课程都有不同的看法，我本人还是比较喜欢这门课程的，有多次的课程展示，每个小组都展现出了自身的特点，也很容易看到自己团队与其他团队的差距，也很容易知道自己与他人在“工作能力”上的差距，知道了自己“几斤几两”。
关于自身能力提升的探讨
在第一次博客中，我对自身提出了以下的期望
-
对规范化的软件开发流程有一个基本的认知。
这一点确实做到了，这门课较为系统的教授了软件开发的全过程，从从领域分析，到需求分析，到初步设计，详细设计，到测试（测试在课程中似乎没有拎出来细讲，也可能是我没仔细听课的缘故）。其中领域分析是我之前没有接触过的全新内容。
-
掌握撰写各种软件开发文档和作图的能力。
这一点效果较为满意，我自身写文档的能力，经过这门课的锤炼，有了较大的提高，虽然写的还是不够好，写起来还是不够快。全新掌握了领域分析文档的写法，需求分析中的大部分内容都在本科阶段有所接触，但是要求没有这门课严格，算是规范了需求分析的写法，并全新接触到了RCUM。设计阶段接触到了OCL，这也是之前没有接触过的内容。作图能力与之前相比也有了较大的提高，至少敢画了。
-
与同组的同学按照规范的流程，完成软件的开发，文档的撰写等，希望这是一次真正的小组合作，大家可以热情交流，感受真正的软件开发氛围，而不是某个大佬carry 全场。
这一点完成度中等，虽然大家都全程完成了各种任务，但是每个任务都没有明确的分工，而是类似于队长出题，其他人做题这样的模式。出现这个问题的原因是多样的，我作为队长，在此稍作分析：１.队长（我）喜欢掌控全局，没有完全放权给某人负责某件任务，对于大型开发，这是极为不利的；２.队长没有摸清每个人的能力，导致任务难以分配，客观而言，每个人能力不同，态度不同，团队中也有人不擅长团队合作，导致如果我确实放权给负任，有能力的同学完成，会导致他们很累，这也是我不愿意见到的情况，既然如此，那就作业化平分任务，显的公平；３.很重要的一点是，即使留下了文档，对于同一个任务，不同人最后写出来还是有较大的区别，难以统一，这个问题在需求分析阶段尤为明显，即使在会议中说清，写草稿说明，最后发现，文档和图有出入，甚至有较大的差异，归根结底还是沟通不够导致，在后期，有组员就此问题与我探索解决方法，这一现象有了很大的改善。没有让大家感受到较好的氛围，是我的遗憾。这是作业，不够软工。
-
从同学的反馈中知道自身的缺点，同时学习同学的优点。
较为满意，从改变沟通方式上，解决了沟通分歧问题，也为之后遇到类似问题积累了经验。也看到其他组较好的团队合作，尤其是做家庭工厂系统的一组，每个人在讲台上都能说出自己的成果和见解。
-
extra:本学期课程可能有点赶，希望治好我写文档作图纠结的毛病。
课程文档多，图多，我已经不敢拖延了。但是这份博客我又拖到最后一天，所以拖延的情况还在，但是写文档和作图速度已经比之前快多了。或许这就是摸鱼的快乐吧。
对项目成功关键因素的探讨
从项目成功的关键因素来看，下面对我在最开始提出的项目成功因素作出探讨。
-
项目的目标合理。项目需求要是可行的，合理的，需要充分考虑到小组成员的实际情况，选择一个可以让团队都可以在可接受的压力下完成的合理需求。
经过这一课程的考验，合理的项目目标的确是一关键因素，在需求分析阶段，我们为项目确立了大量的目标，到课程后期发现，如果要在课程时间段内全部完成，这几乎是不可行的，因此对系统进行了简化，才可以在课程结束前大致完成项目。
-
时间规划合理。软件的开发分为众多的阶段，需要合理制定时间节点，每个任务的时间节点不可过松或者过紧，需要根据实际情况合理调整时间规划。
如１所言，目标合理极为重要，确立工作量和所允许的项目时间的关系，把握关键的时间节点，是顺利完成开发的重要因素，在课程中，时间节点主要由老师的任务驱动，也较为合理。
-
团队成员基础扎实。在技术选型，难点攻关时离不开有较强技术力的成员，团队成员总体水平高、眼界广可以大大减少在此类问题上花费的时间。
这一点在整个项目的中表现尤为明显，客观而言，是存在成员能力不足而导致的问题的，在课程中，需要其他人补救。也存在成员技术偏向性较为明显的情况，如果成员之间有类似或是相同的技术栈，也会提高效率，具体表现在，这种小型项目，等你学完技术，如果学得慢一点，基本另一个人就开发完毕了，这是类似课程大作业类的项目中，切实存在的问题。
-
团队成员的高效沟通。团队成员需要在各个阶段沟通自己的想法和遇到的问题，探讨问题的解决思路，在必要时可能需要交换任务。
我的队伍成员来自各个实验室，很难凑到共同时间交流，因此我们线下会议较少，也采用过在线会议的形式，但是效果较差，全程我在一个人讲话，没有得到什么反馈，结果对于同一个功能，大家的理解都不同的情况，后续通过文档交流解决了这一问题，也侧面印证了文档的重要性。
-
责任心和积极性。团队成员都需要在项目上付出大量的时间，需要完成的，可能不仅仅是分配给自己的任务，还可能需要在其他团队成员需要的时候伸出援手，也需要在团队交流的时候针对项目中的问题发表自己的意见。
责任心无疑是重要的的，但是客观上存在（不只是课程中），有人偷懒，别人就要多干活的问题，决策者怎样解决这个问题才是关键，因为偷懒是不可避免的，能者多劳，是个好听但不光彩的词，不能因为有人偷懒就把任务加在其他人身上，企业内有劳动法约束，也不能随意开除偷懒的员工，采用绩效的考核方式么？这应该也是大多数公司采取的方式，是否是个好的解决方案，有待商榷，做的好就是鞭策，做不好，导致负责的人，积极的人越来越累，或许就是内卷。课程中采取的是贡献分的方式，但是大多数组应该都是平均分吧，只看到一组有较大的差异。不知到往年的分数分配，可能我不适合做领导者，我拉不下面子，但这的确是一个值得商讨的问题。
总结
收获与投入是成正比的，这门课投入相对较多，收获也较多。在研究生阶段应该很少有这样讨论和展示的机会了，既可以学到关于软工的知识，领域分析，RUCM，OCL是我之前从未接触过的，又可以锻炼自己课堂展示的能力， 还能看出自己与他人的差距，无数人说这个课浪费时间，我也说过，因为作为一个没能力但负责的队长，我的确花了特别多的时间和精力，但是平心而论，这门课的收获也比其他三分课的收获大多了，性价比还是超高的。
