提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰 任健）
这个作业的要求在哪里	案例分析作业
我在这个课程的目标是	认真完成课程要求并提高相应能力
这个作业在哪个具体方面帮助我实现目标	回顾、总结本学期的软工课程
以前提问的博客	构建之法——个人阅读作业2

问题解答

1.第1章中提到了Cocomo模型，认为某种项目的时间花费遵守公式

​ \(Person*Month=2.4*KLoC^{1.05}\)

其中的\(KLoC\)表示一千行代码。查阅资料可以发现实际上的Cocomo模型远比此公式复杂，但是作者给出这样的简化公式应该是基于一定的考虑。如果仅从作者给出的公式出发，根据软工课程要求，平均每人大概2000行代码，如果一个团队用5个人计算，按照此公式可以得出完成任务大概需要27人月，即需要5个月左右才能完成。实际上课程所给时间远比此时间短，但是往年的同学仍然很好地完成了课程任务。那么这是因为作者给出的这个公式有问题，还是说由于我们的课程远比实际中的软工要简单，因此可以将时间大幅缩短呢？

上完这个学期的软工课程以后我体会到我们的课程要求确实没有实际要求那么高。相比于实际的软件工程，我们课程开发的软件体量小、功能相对简单，而且很多地方都进行了简化。因此虽然这个公式可能比较适用于一般的软件开发，但作为一门课程来说，这个公式事实上是不太适用的。

该问题的答案来源于实践。

2.第6章中提到了敏捷流程，作者提出了一些同时也是我想问的问题(并且没有解答)，即任务是靠成员认领的，就免不了会出现任务没人认领、任务和能力不匹配等情况(应该说这种现象在我们之中很常见，将来的开发过程中多半也会碰到这种情况)。这时候应该怎么办？

在本学期的软工课程中我体会到，如果大家都是认真负责的人，那么这个问题一般不会出现。例如我们组开发unity游戏，大家其实事先都没有使用过，但大家都尽自己最大的努力尽快学会了unity并投入到开发中。

另外，选题的时候大家也有一定的考量，不会选那种大家认为没办法完成的题目。再加上大家的学习能力都不差，因此大家基本都能按时完成任务。虽然一开始可能因为不熟悉或是其他原因导致质量没有那么高，但随着开发时间的增加，大家完成的质量也在逐渐提高。

但要是团队里有不负责的人，那么我觉得这个问就没办法解决了。无论是push、开例会或是怎样，不负责就是不负责，实际上的软件工程团队可能会开除这种人，但作为课程来说由于人都是事先分好的，显然没办法这么做。这时候这个人就会拖累整个团队(希望课程组以后可以考虑一下对于存在这种人的团队应该怎么办)。

该问题的答案来源于实践。

3.在第4章里作者提到当有助于程序逻辑的清晰体现时可以使用goto语句。但是现在许多人都支持“goto有害论”，认为goto完全可以被替代，任何时候都不应该使用它。我认为如果goto语句确实可以让逻辑更清晰，用goto也无妨，但“逻辑清晰”并不好定义，因为我们在写代码时有很大可能是因为用goto更简单所以就使用goto，这样未必能保证逻辑更清晰(甚至可能会使结构混乱)。在我看来，goto一旦使用不当，会对代码结构造成很大的影响。因此是否对goto的使用进行严格限制(或干脆不使用)会更好一些？

这个问题我并没有在开发过程中遇到。但我很赞同之前的提问作业里有一位助教的回答：

“对于第三个问题我觉得确实可以严格约束一下，因为在团队项目中，一个同学使用goto对于其他同学是“灾难”的，特别是在beta阶段转入新的组员，他在读到这种goto时，来回的上下翻找，往往是头大的，因此如果不能像超级大佬那样简化逻辑，干脆就规范一下。”

该问题的答案来源于助教。

4.在第6章和第8章等地方作者都有谈到对任务完成时间的估计，这样的估计是基于团队内部状况而进行的估计。本学期我选修的一门课程《信号处理与信息推断》指出这种估计称为“内部视角”，其往往是很不准确的。例如格力手机，董明珠估计一年销量为一亿台(被问及原因时，董明珠列举出了类似“我们掌握核心科技、质量有保证”等原因，这是一种典型的内部视角)，然而实际销量却惨不忍睹。同理，我们在软件开发时用这样一种纯内部视角来估计时间，会不会造成严重失误呢？

这样的估计确实是内部视角没错，但我们其实可以人为地加进一些外部视角来进行估计。另外，本学期的《信号处理与信息推断》也指出，如果有多个观测来修正我们的后验概率，那么我们的估计也会越来越准确。而事实上也是这样，我们的估计时间是在不断调整的，每一步估计都是基于我们之前的实践。因此随着开发时间的延长，我们的估计时间也会越来越准。

另外，退一步说，估计出错的概率确实很高，实际开发时间与估计不符的情况也很常见。但这个估计时间的唯一作用就是为自己定一个日程表，起到push的作用。因此就算其有一些偏差，影响也不是非常大。

该问题的答案来源于实践，以及《信号处理与信息推断》课程。

5.第9章中提到了项目经理，项目经理的责任很大，能力要求也比较高。那么对于几乎都没有什么经验的我们来说，在软工课中谁来担任这个角色呢？或者说，如果大家都认为无法担当项目经理的角色应该怎么办？或者说，我们的软工课程由于有一定的简化，是否可以不需要项目经理？

PM必须有！

首先，感谢自己组有一位好的PM。我们的PM为我们的项目付出了很多心血，项目的成功离不开他。展示时有一些组采用了轮值PM的模式，也讲了这么做的弊端。由此说明PM是很重要的。

关于这个问题，还是得说要勇于尝试。我们需要面对的新事物很多，不能因为自己从来没做过就畏手畏脚。有些事情看起来很难，但自己真正做起来的时候其实也没有那么困难。

该问题的答案来源于实践。

学到的知识点

需求：

用NABCD模型来进行需求分析。需求分析是相当重要的一个阶段，对后面的部分有很大影响。开发的软件要实现什么功能、有没有前途等，都取决于需求。

设计：

采用表达控制流(Flow Chart)来进行设计。我们的功能规格说明书即是采用了状态转移的方法来表达设计理念的。

实现：

学会了团队中与人交流的一些技巧。

测试：

对单元测试有了一定的了解。同时也了解到对于前端这种偏向图形化的部分，虽然采用单元测试比较困难，但其实可以按照一定的测试逻辑，采用传统方法来提升测试的覆盖率。

发布：

需要合理选择宣传方式。最初的发布阶段，应该集中精力有针对性地进行宣传，以便快速吸引用户并获得反馈。此后再进行大规模的宣传。

维护：

把握好版本更新的时机。版本更新太急，频繁地发布可能会使用户不厌其烦；版本更新太慢，则一些bug很晚才能得到修复，可能导致用户流失。

理解与心得

软件工程和我们平时的编程有很大区别，实际中的软件工程是比较复杂的，其在开发、管理等方面都有专门的方法，而不是像我们编程的时候写一段代码完成相应的功能就可以。

需求分析是相当重要的部分，在开发前，需求分析一定要做好。频繁地更改需求(参考结对编程第二次作业)导致的后果是灾难性的，一定要避免这种情况的发生。

团队项目中，个人的能力不仅体现在代码中，还体现在代码外。一个人的代码风格、交流能力、理解能力等，都对团队的开发进度有着很大的影响。团队项目是每个人各司其职、各展所长、共同努力的结果，而不是某个人逞英雄、单打独斗的产物。作为一个团队的成员，就要有责任心，至少要做到不拖累整个团队。

最后为辛苦了一学期的自己以及自己的团队点个赞。