1.1 什么是软件工程
1.1.1 定义
程序+文档（张效祥，计算机科学技术百科全书）
- 程序是计算任务的处理对象和处理规则的描述
- 文档是为了便于了解程序所需的阐明性资料
1. 定义、目的、方法
定义：理解问题的本质，并给出解决方案，即：用系统科学的方法解决问题
目的：设计和开发高质量的软件
方法：面向过程、面向对象
1.1.2 软件的特征
- 软件是逻辑实体
- 软件是设计开发的，而不是生产制造
- 涉及其他领域的专业知识，对软件工程师提出了很高的要求
- 软件开发花费多，容易被copy
1.1.3 软件危机
原因：硬件和软件开发的整体复杂性
- 项目超出预算
- 项目超时
- 软件效率低
- 软件质量低
- 软件不符合需求
- 软件无法管理，代码难以维护
- 软件无法交付
软件危机：落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
典型表现：
- 对软件开发成本和进度的估计常常很不准确。
- 用户对“已完成”软件系统不满意的现象经常发生。
- 软件产品的质量往往靠不住。
- 软件常常是不可维护的。
- 软件通常没有适当的文档资料。
- 软件成本在计算机系统总成本中所占的比例逐年上升。
- 软件开发生产率提高的速度，远跟不上计算机应用迅速普及深入的趋势。
出现的原因：一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。
- 软件缺乏“可见性”，管理和控制软件开发过程相当困难。
- 软件规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。
- 开发时期引入错误，导致软件维护通常意味着改正或修改原来的设计，客观上使得软件较难维护。
- 软件专业人员对软件开发和维护中或多或少地采用了错误的方法和技术。
1.1.4 软件工程（SE）
1968年，第一次提出软件工程（software engineering）这个概念
研究如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。
定义：nature (understand the problem clearly) + solution (implement by developing tools)
用系统科学的方法解决问题
目标：设计和开发高质量的软件
以计算机科学理论和计算机功能为基础，通过对要解决问题的本质的了解，采用相应的工具和技术，实现设计方案，推出高质量的软件产品
1.2. 软件工程取得了哪些进展
1.2.1 故障，错误和失效各自的含义（含举例）及它们之间的联系：
2. 错误、缺陷、失效
错误(error)：是在软件开发过程中人为产生的错误（需求说明中的错误，代码中的错误）。
故障(fault)：软件功能实现过程中产生的问题，是错误导致的结果，是软件中一个错误的表现（一个错误可能产生多个故障，静态存在）。
失效(failure)：系统违背了它应有的行为（在系统交付前或交付后被发现，动态存在）。
联系：人为原因导致程序错误；该错误编译到系统中导致系统故障；用户使用该系统时，因故障导致失效。故障是系统内部视图，从开发者的角度看待问题；失效是系统外部视图，从用户角度看到的问题。而且并不是所有的故障会导致失效，只要不执行故障代码，或者不进入某个特定状态，那么故障就不会使代码失效。
- error：理解的错误
- fault：理解的错误体现到了软件制品当中（不一定会触发failure）
- failure：系统的行为跟预期不符
例：直径是半径的3倍→写入文档是error，运行后结果错误：failure
会考如何区分↑
1.3 什么是好的软件
从三个方面考虑软件的质量：产品的质量、生产该产品的过程的质量以及在产品将使用的商业环境背景下的质量。
3. 软件质量
1.3.1 产品的质量
用户：从失效的数目和类型等外部特性进行评价，如果软件具有足够的功能，并且易于学习和使用；或者虽然难以学习和使用，但是由于功能值得这些付出，用户就断定软件是高质量的。
开发者：从故障的数目和类型等内部特征来作为产品质量的依据。
1.3.2 过程的质量
有很多过程都会影响到最终的产品质量，只要有活动出了差错，产品的质量就会受到影响；开发和维护过程的质量与产品的质量是同等重要的。
几个量化模型：CMM、ISO 9000、SPICE（了解）
1.3.3 商业环境背景下的质量
投资回报
(1) 技术价值与商业价值的联系与区别：
技术价值：技术指标（速度，正确的运行时间，维护成本等）。
商业价值：机构对软件是否与其战略利益相吻合的一种价值评估。误区：技术质量不会自动转化为商业价值。
(2) 目标
将技术价值和商业价值统一起来，改进过程所带来的商业价值。
1.4 软件工程涉及的人员
客户(customer)：为将要开发的软件系统支付费用的公司、组织或个人。
开发者(developer)：为客户构建软件系统的公司、组织或个人。
用户(user)：实际使用系统的人。
有时，他们可能是同一个人或同一组人。
1.5 系统开发方法
1.5.1 软件系统的系统要素
活动和对象
活动(activity)：活动是发生在系统中的某些事情，通常描述为由某个触发器引发的事件，活动通过改变某一特性把一个事物转变成另一个事物。
对象(object)或实体(entity)：活动中涉及的元素称为对象或实体（如记录数据的对象）。
关系和系统边界
关系(relationship)：对实体和活动间数据项及动作相互关系的描述。
系统边界(system boundary)：用于描述系统中包含什么，不包含什么。
1.6 软件工程方法
4. SE大致包含的阶段：
（1）需求分析与定义：包括问题定义、可行性研究、需求分析【《SRS》即《软件需求规格说明书》】与复审（所有人）。
（2）系统设计：包括用户界面的设计【《SAD》即《软件系统结构图》：如何制作软件】与复审（开发者与客户）。
（3）程序设计：包括模块功能算法与数据描述设计【相关文档】与复审（开发者）。
（4）程序实现：包括编程与 debug【源代码和注释】与复审（开发者、码农）。
（5）单元测试：模块功能测试与性能测试【测试报告】与复审（测试团队）
（6）集成测试：按照结构图进行测试【测试报告】与复审（测试团队）。
（7）系统测试：按《SRS》对系统总体功能进行测试与复审（开发者与客户）
（8）系统交付：交付产品【用户手册和操作手册】与复审。
（9）系统维护：修改软件的过程，为改错或满足新需求【维修报告】与复审（维修团队）。
注：圆括号中的为测试人员，方括号为生成的文档。
额外说明（了解）：以上阶段只是大致的划分，软件团队实际执行时比这要复杂，还有若干辅助性过程和阶段，而有些阶段实际是相互重叠、相互影响的。
1.7 开发团队的成员
需求分析人员、设计人员、程序员、测试人员、培训人员、维护人员、资料管理人员、配置管理人员。
软件工程各阶段各自的工作：（了解）
- 需求设计（分析员、客户）：将客户想要的分解为离散需求。
- 系统设计（分析员、设计员）：生成系统层描述（系统要做什么）。程序设计（设计员、程序员）：实现指定需求的代码。
- 程序实现（程序员）：编代码。
- 单元测试（程序员、测试员）：发现各种错误。集成测试（测试团队）：检查系统功能。
- 系统测试（测试员、客户、培训员）：根据《SRS》检查要求。系统交付（培训员）：培训用户。
- 系统维修（维修团队）：寻找故障，根据客户需求变化，对系统作出修改。
- 资料管理（资料管理员）：维持一个软件的不同版本之间各种文档的对应关系，包括需求规格说明、设计描述、程序文档、培训手册、测试数据进度等。
- 配置管理（配置管理员）：维护需求、设计、实现和测试之间的对应关系。
- 软件架构师：属于高级程序员，侧重开发过程和模式的选择和论证（在国内和分析员差不多,其工作重点与分析员有所不同，但就开发来说，其工作似乎更重要些，而分析员的工作更偏重于市场与用户需求）。
1.8 软件工程发生了多大的变化
1.8.1 七个关键因素(by Wasserman)
5. 现代SE 七个关键因素
（1）商用产品投入市场时间的紧迫性（时间紧迫）
（2）计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本（计算成本降低）
（3）桌面计算机功能增强
（4）广泛的局域网和广域网（网络技术的发展）
（5）面向对象技术的采用及其有效性（面向对象技术的发展）
（6）使用窗口、图标、菜单和指示器的图形用户界面（图形化界面实现的发展）
（7）软件开发瀑布模型的不可预测性（瀑布模型的问题）
1.8.2 软件工程的 Wasserman 规范（或基本概念）
6. Wasserman 规范
① 抽象(abstraction)：
基于某种层次归纳水平的问题描述。它使我们将注意力集中在问题的关键方面而非细节。
② 分析、设计方法和符号描述系统：
使用标准表示来对程序进行描述。利于交流，利于建模并检查其完整性和一致性，利于对需求和设计部件进行重用。
③ 用户界面原型化(prototyping)：
建立系统的小型版, 通常具有有限的关键功能,以利于用户评价和选择，证明设计或方法的可行性。
④ 软件体系结构：
定义一组体系结构单元及其相互关系集来描述软件系统。
单元分解的方法（以下了解）：
（1）基于功能的模块化分解: 基于指派到模块的功能。
（2）基于数据的分解: 基于外部数据结构。
（3）面向事件的分解：基于系统必须处理的事件。
（4）由外到内的分解：基于系统用户的输入。
（5）面向对象的设计：基于标识的对象的类以及它们之间的相互关系。
⑤软件过程：
软件开发活动中的各种组织及规范方法。（以下了解）
因应用类型和组织文化之间的巨大差异,故难以对软件过程本身进行预先指定,也就是说:使过程本身规范化是不可能的.软件过程不可能以抽象和模块化的方式作为软件工程的基础。
⑥ 重用或复用(reuse)：
重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去 (注: 这里的重用绝不仅仅是源代码的重用)。
⑦ 测度或度量(measurement)：
量化的指标
通用的评价方法和体系，有助于使过程和产品的特定特性更加可见，包括量化描述系统、量化审核系统。
⑧ 工具和集成环境：
通过框架比较软件工程环境提供的服务，以决定其好坏。工具：由于厂商很少针对整个开发生命周期，因此对于工具的比较集中于小的活动集，例如测试或设计。（以下了解）
工具集成中必须处理的五个问题：(by Wasserman)
平台集成、表示继承、过程集成、数据集成、控制集成。