《软件工程学习心得》由会员分享，可在线阅读，更多相关《软件工程学习心得（2页珍藏版）》请在金锄头文库上搜索。
1、学习心得学习心得学了一个学期的软件工程课，终于知道了个软件工程的大概。我们为什么需要软件工 程呢？软件工程最终是为了实现“软件制造业”的社会化,工业化大生产,提高其劳动生产效率。 只有如此,软件业才能实现社会化,工业化大生产,才能“做大做强”。没有管理的设计是失败 和混乱的设计，没有设计指导的编程是无序的忙碌的。根据开发的软件的规模，应该适当 程度的运用软件工程化的思想，需要灵活，但只要涉及人员间的交流和沟通，或多或少都 要需要软件工程才能更有效率，工作成果更稳定。 无论是在上个世纪还是在现在，软件开发所涉及的工作基本上都没有变化，它们都起 始于一个实际需要或某个灵感，然后就是分析，设计，编码
2、，调试，维护。这些任务以某 种方式动态地结合起来就构成了软件开发的整个过程，这就是所谓的“软件开发周期”。 但 对于这些工作，具体怎样做，什么时候做，每个人都有自己的一套方式，甚至有的人有几 套方式。这样，当几个人合在一起干活的时候，最终的结果就只能是一片混乱。所以就需 要一套规则，大家都按规则来办事，问题就会少得多。好的规则就叫做规范，规范都是由 一些 master 们根据经验总结的，又经过长时间的历练，不断地被补充修正，可以说都是精 华，按照规范来干活，对于提高软件质量和工作效率自然大有帮助。 而软件工程，说白了， 就是这样一套用于软件的团队开发，以提高软件质量和程序员工作效率为目的的规范
3、。其 核心就是，对于软件开发的 5 个重要组成部分：需求分析，设计，编码，调试，维护，如 何组织这 5 个部分的工作，以及如何完成每一个工作。简单来说，就是对于总体的组织和 对于局部的实现。 规范只是提供一个好的例子，以描述一种思想，具体到每一个环节怎样 实现，对于不同的公司或团体则是各有千秋，因为根本就不可能存在一套放之天下皆可行 的标准。就像 C+，也只是提供了一套标准，不同的编译器都有各自的实现，对标准的支 持程度也互不相同。所以，在不同的公司或团体中，尽管核心思想都是大同小异，但具体 到每一个步骤，往往都是不相同的。软件工程将有能力的人团结在一起，然后把他们变成 工人，因为工业化的生产
4、是效率最高的。这就是根本所在 具体到每一步的工作要怎样完成，我前面已提到过，是非常灵活的，只要把握住大 体的方向就行。在进行分析，设计，编码，调试，维护这几部分的工作的时候，最核心的 就是文档的编写。文档的作用在于以下 3 个方面：一是可以帮助整理思路。把要完成的目 标，系统的结构，每一个模块的功能等整理一下，然后分门别类地写下来，这样在开发的 过程中，就有据可依，在需要回过头来修改设计的时候，也有证可考。二是便于交流。想 象一下开会时的情形。一大帮子人争先恐后，激烈辩论，然后会终人散，思想灵感也就随 之散了，结果是开了半天会，什么也没讨论出来。这就是后来会议记录被发明出来的原因。 在脑子里的
5、东西一多，就会散而且乱，用语言表达的时候，很容易会丢三落四，别人也很 难把握住你的思想。但经过整理写在纸上以后，则会清晰得多，无论是别人还是自己，看 起来都可以一目了然。三是可以作为以后维护时的参考资料。有一句名言：“笔和纸永远都 比大脑可靠”，意思就是说，放在大脑里的东西说不准哪天就忘了，但写在纸上的东西，只 要不发生什么意外，一般是丢不了的。当过了一段时间，你需要再回过头来修改你的程序 的时候，你就会发现，你以前写下的文档实在太有价值了。别指望你的源代码，对于复杂 一点的程序来说，单纯的源代码几乎会扼杀掉你所有的时间。 至于文档怎样写，教科书上大多都是一条一条列得满满的，就像一些地方政府的
6、规章 制度一样，其实大可不必，只要能满足需要就行。如果是在公司，则每个公司大多都有一 套自己内部的文档模板，个人没有选择的余地。而对于像我这种业余的，写个程序除了练 练手艺，无非就是供自己和亲朋好友玩玩，则根本没必要搞得过于复杂。以下就是我自己 的一份文档模板的概要，麻雀虽小，但五脏俱全。 可行性分析 就是关于当前项目能不能干的分析结果。主要考虑的方面包括：是否能把 这个项目开发出来；假如可以的话，预计需要多少时间，能否满足客人的时间要求；需要 多少人力和资金的投入；最重要的是，这个项目能否赚钱，能赚多少。还要对可能存在的 风险进行评估，例如，万一项目主管被车撞了要怎么办。当然，这对于我来说毫
7、无意义， 我在这里写上只是为了保持完整而已。 需求分析是要决定“做什么，不做什么”。 需求分析为什么困难？有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2） 需求自身经常变动；（3）分析人员或客户理解有误。 客户说不清楚需求：有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。有些客 户心里非常清楚想要什么，但却说不明白。 事实上，用简单的话来说明需求过程，就是确定系统该做些什么以及该符合什么条件。 话虽然简单，实现起来可没有那么容易。所以科学的需求过程有一整套完整的理论、工具、 方法来实现。 明确：目前大多数的需求分析采用的仍然是自然语言（因为如果采用形式化 语言的话，和用户的沟
8、 通将成为一个大问题，这意味着客户在开发软件之前必须先进行形 式化语言培训，这是不现实的） 。 自然语言对需求分析最大的弊病就是它的二义性。所以 我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语动作的简单表达方 式。说白了，需求分析中的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采 用疑问句、修饰这些华丽的表达方式.需求分析最重要的是和用户沟通，可是用户多半不是 计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。举预测 例子。 完整：再也没有什么比软件开发接近完成时才发现遗漏了一项需求更糟的事情了。需求的 完整性是非常非常重要的，想象一下遗漏需求而不得
9、不返工，这简直就是恶梦。可是令人 遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题，更多的问题发生在用户 那里，他们不知道该做些什么。要做到需求的完整性是很艰难的一件事情，它涉及到需求 分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。 一致：一 致性也是一个比较大的概念，很难用几句话讲清楚。简单的来说，就是用户需求必须和业 务需求一致，功能需求必须和用户需求一致可测试：大家觉得一个项目的测试从什么时候 开始呢？有人说从编码完成后开始。更清楚一点的说是编码的时候同时进行单元测试，编 码完成后进行系统测试。这些都没有错。但是实际上测试是从需求分析过程就开始了。需 求分析是测试计划的输入和参照。这就要求需求分析是可测试的。
