软件工程

问题描述 现在，在我国来看，无论大中小三种企业，均喜欢使用软件工程过程中的“敏捷模型”。 使用了“敏捷模型”的企业，大多的软件流程如下： 产品经理产出原型 架构师/主管开始拆分模块并分配至开发人员 产品经理开始补文档 这种方法虽然开发速度快，但是实际上，整个开发团队对于需求的理解是模糊的。 这种流程，在需求确认的时候，无法拿出一份符合软件行业规范的文档，仅仅以原型作为展示，来与客户、开发、测试等人员进行沟通。 实际上，纵观软件工程的发展史，我们就会发现，一切回到了最初的起点：软件危机。 仅使用原型来与客户进行需求确认，导致客户确认的需求比较模糊 架构/主管按照原型进行模块划分，导致软件整体架构是按照当前需求最优的，后期需求一旦变更，就会导致大面积的代码变更 模块虽不会对开发人员产生模糊，但是由于需求实际上并不是“确认”的，开发人员将可能产出错误的软件实现。 将对测试人员的工作产生巨大的影响，比如，测试人员认为有问题，但是开发人员认为没问题，产品经理也坚持没问题/下一版再说。 缺少文档、需求模糊、更改耗时耗力、一再拖拉，传说中的软件危机就这样再一次出现了。 如何避免和改善： 一日没有《需求分析说明书》，开发人员和测试人员就一日不应工作。

软件的定义 根据《软件工程》的规定， 软件 = 文档 + 数据 + 程序 我们能了解到，程序只是软件的一部分。 我们也可以获得软件的定义： 软件是采用了适当的算法与数据结构，并拥有完备的软件描述信息的一套指令的集合。 软件工程的关注点 我们都知道，（一套高质量的）程序是软件工程的最终目标，但是，程序并不是软件工程的关注点，文档与过程才是。 软件过程的开始 当项目立项后，可行性分析认为**“可行”**时，就正式的进入了软件工程过程。 （在这里，我不将可行性分析阶段算入软件工程过程，因为若可行性分析的结果是“不可行”，那么软件将不会存在） 软件过程的核心文档 《需求分析说明书》将成为了软件的第一个部分。它是软件工程过程中，最重要，也是最容易出现问题的部分。 当进入了需求分析阶段时，以最普遍的W模型来看，意味着测试工程师可以开始工作了，也即整个软件团队的成员都需要开始工作了。《需求分析说明书》就像一块凝结核，软件会在这个“凝结核”的基础上逐渐生长，慢慢成为坚固的“晶体结构”。 程序与软件的对比 我们再反观程序。程序就不一样了，在程序中，一定要有可运行的计算机代码，如果没有可运行的计算机代码，那么程序只能叫做算法，或是PDL。相比较于软件的“晶体结构”，程序就是一盘”散沙”，虽然掺点水可以做成沙堡，但是非常脆弱。 广义化的软件 那么站在软件工程过程上来说，我们就可以这样广义化描述： 当文档开始进入了软件工程过程时，即可被称之为软件。 在这种描述下，软件可以（在软件过程中）脱离程序而独立存在，也可以结合程序达到最终目标，但软件绝对不等价于程序。