引言
- 软件错误：如果该问题确实是由软件引起，可能会给我们的文明社会带来不愉快和灾难性的结局。
- 软件工程：一门学科，目的是生产出没有错误的软件，按时并且在预算内交付，满足用户的需求。更进一步，当用户的需求改变时，软件必须易于修改。
1.历史方面
- 软件的开发应当同其他工程任务的开发相类似，软件工程应当使用已建立的工程学科的基本原理和范型来解决所谓的软件危机。
- 软件危机：软件产品的质量低得通常不能接受，并且不能满足交付日期和预算限制。
- 软件工程师需要获得广泛的技巧，既有技术的也有管理的。
- 软件生产过程虽然在许多方面与传统工程是相似的，但仍然有自己的属性和问题
- 软件萧条：软件危机的周期长且难预测
2.经济方面
将经济性原理应用于软件工程要求客户选择能够减少长期成本的技术。
3.维护性方面
- 生命周期模型：在构建一个软件产品时应当完成的步骤的描述
- 阶段：将整个生命周期模型划分为一系列较小的步骤
- 生命周期：对某个具体的软件产品所做的一系列实际步骤，从概念开发到最终退役
- 瀑布模型在20世纪70年代非常流行，主要分为6个阶段：需求阶段、分析（规格说明）阶段、设计阶段、实现阶段、交付后维护、退役。
- 传统软件开发方法可以描述为：开发——维护模型。这是一个时间上的定义。由于错误的难以避免以及功能的频繁添加，开发与维护没有本质上的区别。
- 除了这种不一致以外，还有两个原因导致开发——维护模型在今天是不现实的：一方面，如今的软件开发周期时间很长，用户的需求很可能改变，这会导致很早就进入所谓的维护阶段；另一方面，软件开发者在将要开发的软件中尽量重用已经存在的软件的各个部分，这种模型已经不适用了~
- 操作性定义：当改正错误或者需求变化时，维护已经发生了
- 交付后维护的重要性：有时人们认为只有坏的软件产品才需要维护，实际上恰恰相反：人们通常会将坏的软件扔掉，而对于好的软件在10年、15年甚至更长的时间范围内进行改进和提高。进一步说，软件产品是现实世界的模型，而现实世界在不断变化着，从而必须不断对软件进行维护以保证它能准备地反映现实世界。交付后维护非常重要，因而是软件工程的一个重要方面。它由可降低软件交付后维护成本的技术工具和实践组成
附：阶段解释
- 需求阶段：对概念进行研究和细化，提取客户的需求
- 分析阶段：分析客户需求，并以规格说明文档的形式给出。在阶段结束的时候，制定出计划，称为软件项目管理计划，详细描述期望的软件开发。
- 设计阶段：先是结构设计，将产品分解为各个部分——称为模块，然后设计每个模块，这个过程称为详细设计——得到的两个设计文档描述产品时如何做的
- 实现阶段：对各个部分独立地进行代码编写和测试
- 交付后维护：包括在产品交付并安装到客户计算机中并通过验收测试后对产品所做的全部改动。
- 退役：发生在产品当产品推出服务的时候，当产品功能不再对客户组织有用的时候，就不再使用该产品。
4.需求分析和设计方面
- 软件专业人员也是人，在开发产品时可能会犯一些错误，如果这个错误在需求阶段出现，那么这个错误会延续到规格说明阶段甚至更远。不难发现，越早纠正错误越好~
- 在软件生命周期的早期产生如此多的错误，说明软件工程的另外一个重要方面：技术能够产生更好的需求、规格说明和设计。
5.小组编程方面
- 诸多软件产品太大了无法由一个人在规定时间内编写完成，然而小组编程导致了代码模块间的接口问题和小组成员间的沟通问题。
- 如果不能对开发小组进行恰当的组织和安排，那么将有大量的时间浪费在小组成员之间的协调上。因为现在的软件绝大多数由小组开发和维护，所以软件工程的范畴必须包括确保小组恰当管理和组织方面的技术~
6.为什么没有计划阶段
在每个项目的一开始有一个计划阶段显然是最基本的，传统的软件开发范型常常要进行三类几乎活动：
- 在项目的开始，对管理需求和分析阶段进行初步计划
- 一旦明确知道了将要开发什么，就制定出软件项目管理计划SPMP
- 在整个项目过程中管理者需要监督SPMP的执行情况，并且注意是否有偏离计划的情况发生
概括地说，不存在独立的计划阶段。反之，计划活动贯穿于软件生命周期的始终。然而在有的时候计划活动占主导地位。这包括在项目的开始以及客户刚签署了规格说明文档之后。
7.为什么没有测试阶段
- 在软件产品开发出来后，非常仔细地检查它是非常重要的，但当该产品准备好交付给客户时才检查它实在是太晚了。
- 尽管测试常常占有过重的分量，但永远不要不进行测试。如果将测试看作一个独立的测试阶段，那么会有不将测试连续贯穿于产品开发和维护的每个阶段的实际危险。
- 仔细检查应当自动伴随着每个软件开发和维护活动。与此相反，一个独立的测试阶段与确保一个软件产品尽可能在所有时候都无差错的目标是不一致的。
- SQA：软件指令保证组，，主要职责是确保交付的产品是客户要求的，并且该产品在各方面都一直正确地建造。
8.为什么没有文档阶段
就像不应该有独立的计划阶段或者测试阶段一样，也不应当由独立的文档阶段。与此相反，在任何时候，软件产品的文档必须是完整、正确和最新的。诸如计划、测试和文档活动应当伴随着建造软件产品的所有其他活动进行。
9.面向对象范型
- 1975-1985年间，所谓传统或结构化范型的发展很快
- 随着时间的推移，结构化范型被证明存在两个方面的缺陷：这些技术有时不能解决软件产品的规模越变越大的问题，另一方面则是交付后维护不能满足人们的最初期望。
- 传统范型不成功的原因在于，要么面向操作，要么面向属性，但没有同时面向这两者。软件产品的基本组成是产品的行为和这些行为对其进行操作的属性。与传统范型正相反，面向对象范型将数学和操作看作是同等重要的。
实现细节局限于对象内部带来了面向对象范型的众多优势：
- 极大地减少了回归错误
- 使软件开发变得更加容易
- 设计良好的对象是独立的单元
- 提高了重用度
- 降低产品复杂度
结构化和面向对象范型的对比，两张图：
10.正确看待面向对象范型
传统的结构化范型存在许多缺点，然而面向对象范型也并非完美无缺：
- 像所有软件生产的方法一样，必须正确使用面向对戏那个范型，像其他范型一样，很容易错误地使用面向对象范型。
- 当正确使用的时候，面向对象范型可以解决一些传统范型遇到的问题。
- 面向对象范型有自己的问题
- 面向对象范型是目前可用的最好方法，然而像所有技术一样，将来它一定会被更先进的技术所取代。
11.术语
- 客户：想建造某一产品的个体
- 开发者：小组的成员，负责建造该产品
- 内部软件开发：客户和开发者可能是同一组织的一部分
- 合同软件：客户和开发者是完全独立组织中的成员
- 用户：涉及软件生产的第三方，是客户委托产品所代表利益利益的人
- 商用现货软件：昂贵定制软件的多个低价副本，早期称为用收缩薄膜包装的软件
- 开源软件：一个开源软件产品由一组自愿者开发和维护，任何人都可以下载并免费使用
- Linus法则：如果足够多人给与关注，所有的软件错误都将一目了然。相关的法则是：尽早发布，经常发布。
- 软件：不仅由机器可识别的代码组成，而且包括为每个项目固有组成部分的所有文档
- 程序和系统：程序是一个自治的代码段，通常以一堆打孔卡片的形式出现，它能够被执行；系统由许多这样的相关程序组成
- 系统分析：前两个阶段，即需求和分析阶段
- 系统设计：即第三个阶段，设计阶段
- 产品：表示一段重要的软件
- 方法：用于表示“一种开发软件产品的方法”
- 范型：用于表示“一种软件开发风格”
- 技术：方法和范型都用于整个软件过程，技术则适用于软件过程的某个部分。
- 当一个程序员犯了过错，该过错的结果造成代码中的差错，执行软件产品产生故障，即可观察到的产品的不正确行为是代码中的差错造成的。错误是差错的积累，造成结果的不正确。
- 缺陷：一个通用词汇，可以指差错、故障和错误。
- 臭虫：差错这个概念的委婉说法。
- 属性：表示一个对象的数据成员。
- 状态变量：也即“属性”。
- 实例变量：也即“属性”。
- 成员函数：也即“方法”。
12.道德问题
软件产品时由人开发和维护的，如果这些人勤劳、聪明、明智和现代，而且最重要的是要有道德，那么软件开发和维护的方式会是令人满意的。
软件工程道德和从业规范(5.2版)
在我们的专业道路上严格遵守道德准则是至关重要的~
