§1

软件工程是一门学科，目的是生产出没有错误的软件，按时并且在预算内交付，满足用户的需求。
软件工程范畴非常广，可以归入数学或计算机科学，其他方面可以落入经济学、管理学或心理学的范畴。
软件危机指软件产品的质量低得通常不能接受，并且不能满足交付日期和预算限制。考虑到软件危机的周期长且难预测，可能将软件危机重新命名为软件萧条。
生命周期模型是对在构建一个软件产品时应当完成的步骤的描述。
将整个生命周期模型划分为一系列较小的步骤，称为阶段。
对某个具体的软件产品所做的一系列实际步骤，从概念开发到最终退役，称为该产品的生命周期。
瀑布模型（传统生命周期模型的6个阶段）：
1.需求阶段：提取客户需求
2.分析（规格说明）阶段：软件项目管理计划
3.设计阶段：结构设计（模块+详细设计）、两份设计文档
4.实现阶段：代码编写+单元测试、集成后验收测试
5.交付后维护：纠错性和增强性维护
6.退役
传统软件开发方法可以描述为开发——维护模型
回归错误是指对软件某处进行修改时，不小心在与该处明显没有关联的另一处造成了新错误。
面向对象设计也叫职责驱动设计或按合同设计。
客户是想建造某一产品的个体。开发者是小组的成员，负责建造该产品。用户是客户委托商品所代表利益的人。
客户和开发者可能是同一组织的部分。——内部软件开发
客户和开发者是完全独立的组织中的成员。——合同软件
商用现货软件：可以卖的软件、开源软件

§2

进化树生命周期模型：显示了事件的顺序。而瀑布模型不可以。
特性的蔓延：连续地向需求中加入小的甚至是琐碎的特性。
联动引起的退化性差错。
迭代-递增生命周期模型，有五个核心工作流：需求工作流、分析工作流、设计工作流、实现工作流、测试工作流
迭代-递增模型的特点：
1.为检查软件产品是否正确提供多个机会
2.在生命周期的相对早期可以确定其蕴涵结构的健壮性（具有可以连续扩展以包含下一次递增的属性）
3.较早地减轻风险
4.总是有该软件的一个工作版
5.经验数据表明它很有用
其他模型：
1.编码-修补生命周期模型
2.瀑布生命周期模型
3.快速原型开发生命周期模型
4.开源生命周期模型（纠正性、完善性、适应性维护）
5.敏捷过程
6.同步-稳定生命周期模型（微软）
7.螺旋生命周期模型
各种生命周期模型的比较：

生命周期模型	长处	短处
进化树模型	与现实世界软件开发最接近的模型，与迭代-递增模型等价
迭代-递增生命周期模型	与现实世界软件开发最接近的模型，蕴涵统一过程方法
编码-修补生命周期模型	适用于不需要任何维护的小程序	总的来说不适合重要的程序
瀑布生命周期模型	纪律性强制的方法，文档驱动	交付的产品可能不符合客户的要求
快速原型开发生命周期模型	确保交付的产品符合客户的要求	还没有证明无懈可击
开源生命周期模型	少量实例中工作得相当好	实用性有限，通常不太起作用
敏捷过程	客户的需求模糊时能很好地工作	似乎只适合小规模项目
同步-稳定生命周期模型	能满足未来用户的要求，确保各组件能够成功集成	除了在Microsoft公司，还没有广泛地应用
螺旋生命周期模型	风险驱动	只能用于大型的内部软件产品，开发者必须精通风险分析和风险排除

§3

今天最主要的面向对象的方法是统一过程，统一建模语言UML。
需求流：让开发组织确定客户的要求。（目标）
步骤：理解问题域并建造业务模型。
业务模型是说明目标产品代价合理性的文档。
限制条件：最终期限（主要）、可靠性、成本（重要）
最初对客户需求的调研有时称为概念探究。
分析流（提取类）：分析和提取需求，以获得正确开发软件产品和易于维护它所必需的需求。（目标）
模糊是自然语言固有的特性。规格说明文档可能是矛盾的。
软件项目管理计划：可交付的东西（客户将要得到的）、里程碑（时间）以及预算
设计流（类的设计）：详细设计，细化分析流的制品，直至材料处于程序员可实现的形式。（目标）
实现流：用选择的实现语言实现目标软件产品。（目标）
测试流：在统一过程中，测试从始至终与其他工作流并行进行。
测试流的性质随着被测试的制品的不同而不同。对所有制品都至关重要的是可追踪性。
单元测试：对组件进行系统测试 -> 集成测试：检查组件是否正确组合在一起 -> 产品测试：对产品功能进行整体测试 -> 验收测试：客户用真实数据 -> 交付后维护：1.检查要求的改变已经正确实现了 2.确保在对产品要求的改变时，不做其他无意识的改变 =>回归测试
统一过程的各阶段：开始、细化、构建、转换
开始阶段目标（需求流）：决定是否值得开发目标软件产品，主要目标是明确提出的软件产品是否经济上可行
步骤：1.经济效益、按时交付、风险 2.明确风险
细化阶段目标（分析和设计流）：细化最初的要求，细化体系结构，监控风险，细化它们的属性，细化商业案例以及生成软件项目管理计划。
构建阶段目标（实现、测试流）：产生软件产品的第一个可工作版本（β版）。
转换阶段目标（完成后维护）：确保客户的需求切实得到满足。
能力成熟度模型（CMM）是一组用于改进软件过程的相关策略，不考虑生命周期模型。
成熟度是过程本身良好程度的度量。
成熟度级别：
1.初始级：临时过程
2.可重复级：基本项目管理（根据经验对产品进行计划和管理）
3.定义级：过程定义（管理和技术有明确定义）
4.管理级：过程测量（有质量目标和生产目标）
5.最优级：过程控制（统计质量和过程控制技术对软件组织进行指引）
关键过程区是一个组织在迈向下一级别时要努力实现的目标。
统一过程是迄今为止将大型问题作为一些较小，较独立的子问题解决的最好办法。
它提供了递增和迭代的一个框架，这个机制用于解决大型软件产品的复杂性。

§4

布鲁克斯法则：向一个已经延期的软件项目增加人员会使项目完成得更晚。
民主小组：基本概念（无我编程）
优点：对查找错误的积极态度
传统的主程序员小组方法：关键特性（专业化和等级性）
主程序员和备程序员
编程秘书-文档
不实用性：主/备程序员都很难找到，秘书也是
现代编程小组：主程序员由两人替代（小组领导、小组经理）
小组领导：负责技术，小组经理：负责所有非技术型的管理事务
适当分散决策过程
同步-稳定小组（微软）
敏捷过程小组：结对编程，具备无我编程的特点
开源编程小组
人员能力成熟度模型，描述管理和开发一个组织的人力资源的最佳实践。
各小组组织方法的比较：

小组组织	优点	缺点
民主小组	由于积极地寻找错误，因而代码质量高，特别适用于解决难的问题	有经验的人反感新手的评价不能从外部强加
传统的主程序员小组	《纽约时报》项目的主要成功之处	不实用
修改的主程序员小组	有许多成功的案例	没有与《纽约时报》项目可比拟的成功范例
现代分级编程小组	小组经理/小组领导结构避免对主程序员需求，可扩展，必要时支持分散决策	除非明确小组经理和小组领导间的负责范围，否则容易产生问题
同步-稳定小组	鼓励创造性，确保大量开发者为共同目标工作	在Microsoft公司之外还没有该方法应用的实例
敏捷过程小组	程序员不测试自己的代码，如果一个程序员离开不会有损失，经验欠缺的程序员可以向其他人学习，代码具有小组所有权	还没有更多的实例证实它的功效
开源小组	少数项目非常成功	应用面窄，需由出色的有号召力的人领导，需顶尖高手参与

§5

分析工具：
1.逐步求精法：尽可能将细节的定义推延到最后（迭代+递增），以便集中精力在重要的事项上。
米勒法则：一次一个人最多只能集中精力于7桩事情。
2.成本-效益分析法：对比估计的未来收益和预测的未来成本。
3.分治：最古老的分析工具。
4.关注分离
5.软件质量：
产品度量：测量产品本身的某个特性。
过程度量：开发者使用这些度量推断软件开发过程的信息。
软件工具（CASE）：在开发过程的较早工作流（需求、分析、设计）帮助开发者的CASE工具称为高端CASE或前端工具，帮助实现流和交付后维护的CASE工具称为低端CASE或后端工具。
数据字典：在产品中定义的所有数据的计算机化列表。
另一个用处是为报表生成器和屏幕生成器提供数据。报表生成器产生生成报表所需的代码。屏幕生成器帮助软件开发者产生用于数据捕获屏幕的代码。
编程工具：指诸如文本编辑器这样的CASE工具。
小编程：单模块，大编程：模块级进行的，多编程：由小组进行的软件开发
多编程结合了小编程和大编程两方面
结构编辑器：可以随时检测程序员键入的语法错误，需要支持在线接口检查。
软件版本：修订版、变种版
构建大型产品时，版本控制，配置控制，建造工具是最基本的。
CASE技术——提高生产力

§10

我们人类处理信息量的限制的一个办法是使用逐步求精方法。
迭代和递增都是软件工程的固有特性。
核心工作流：需求、分析、设计、实现、测试
主要的面向对象方法是统一过程，统一过程是使用图形化语言——统一建模语言UML来表示要开发的软件。
模型是一套图表，表示软件产品的一个或多个方面。
需求工作流的目标是明确客户需要什么。
分析工作流的目标是分析和提炼需求。
实现工作流的目标是用选择的实现语言实现目标软件产品。
测试工作流从始至终与其他工作流并行进行。
成本-效益分析法是对比估计的未来收益和预测的未来成本。
度量（5种主要的基本度量）(1)规模 (2)成本 (3)持续时间 (4)工作量 (5)质量
CASE代表计算机辅助软件工程。最简形式是软件工具，例如画UML图的工具。
数据字典、报表生成器和屏幕生成器
每个制品的特定版本集是这个产品版本的配置。
基线是产品中所有制品的配置。
重用指使用一个产品中的组件来简化另一个功能不同的产品的开发。#

§11

需求流的整体目标是让开发组织确定客户的需要。
应用域是目标产品应用的特定环境。
发现客户需求的过程称为需求启发（或需求捕获）。
推敲和补充的过程称为需求分析。
术语表：在该领域应用的技术词汇列表和对应的解释。
业务模型是对公司的商业过程进行的描述。
访谈：程式化的访谈和非程式化的访谈
模型是代表要开发的软件产品的一个或多个方面的UML图。
用例为软件产品本身和软件产品的使用者之间的交互建立模型。
系统的使用者可以扮演不止一个角色。参与者不一定是人。
面向对象范型是迭代。功能性需求指定目标产品必须能够执行的行为。
非功能性需求指定目标产品本身的属性：例如平台限制、响应时间、可靠性
快速原型是仓促建立的软件，展示目标软件产品的主要功能。
用户友好一词指人类与软件产品沟通的容易性。
窗口、图标和下拉式菜单是图形用户界面的要素。

§12

规格说明文档是客户和开发者之间的一种合同。
结构化系统分析（半形式化技术）共有9个步骤。
步骤1，画DFD：确定逻辑数据流。
步骤2，决定哪部分计算机化以及如何计算机化（批处理或联机）
对于处理量大和要求严格控制的情况，经常选择批处理；对于小容量计算机，用联机处理。
步骤3，确定数据流的细节：数据字典
步骤4，定义处理的逻辑
步骤5，定义数据存储：数据实时访问图
步骤6，定义物理资源
步骤7，确定输入-输出规格说明
步骤8，确定大小
步骤9，确定硬件要求
有穷状态机，在需求分析时做，是形式化技术。
一个有穷状态机包括：状态集J 输入集K 转换函数T 初始状态S 最终状态集F
当前状态与事件与谓词 => 下一个状态
Petri网：形式化技术。
禁止弧：没有令牌也能转换。
Z：形式化技术。
一个规格说明文档必须既是非形式化的，足以让客户理解，又是形式化的，足以让开发小组将其作为要建造的产品的唯一描述。

§13

面向对象分析（OOA）是面向对象范型的半形式化分析技术。
分析流的两个目标：
1.得到对需求更深的理解
2.按设计和实现易于维护的思路描述需求。
统一过程有三种类：
实体类为长期存在的信息建模。
边界类为软件产品和它的参与者之间的交互行为建模。
控制类为复杂的计算和算法建模。
抽取实体类：功能建模，实体类建模，动态建模
实体类建模：名词抽取法：阶段1，用一个段落描述软件产品；阶段2，分辨名词
分析流的基本目标是生成规格说明文档。

§14

面向操作设计，强调操作，目标是设计具有高内聚性的模块。
面向数据设计，首先考虑的是数据。首先确定数据结构，然后设计符合数据结构的过程。
数据流分析（DFA）是一项得到具有高内聚模块的传统设计技术。
程序描述语言（PDL）——“伪码”
事务是从产品用户的观点来看的一个操作。
统一过程的前提是知道面向对象设计。

§15

二进制机器码是第一代语言。
第二代语言是汇编语言。
C、C++、Pascal或Java是第二代语言。
第四代语言：4GL。
实现流的目标是用所选的实现语言实现目标软件产品。
单元测试的测试数据可以用两个基本的方法系统地构建。
第一个是规格说明测试，这个技术也称为黑盒测试、行为测试、数据驱动测试、功能测试以及输入/输出驱动测试。
另一个是代码测试，白盒测试。
黑盒测试：
涉及测试用例、等价类划分、边界值分析
等价类成员+边界值+临近边界值
白盒测试：语句、分支和路径覆盖。
每个新的代码制品加入到已集成的模块中时都必须进行测试，这称为集成测试。
当集成过程结束时，软件产品作为一个整体进行测试，称为产品测试。
交给客户进行验收测试。

§17

UML是统一建模语言。
空菱形表示聚合，聚合是UML中表示局部-整体关系的术语。
线的端点处旁边的数字表示多重性。
组合是聚合的一个更强形式，部分-整体的关系。用一个空心菱形表示。
继承是泛化的一个特例，用空心三角形表示。
关联的方向需由一个实心三角形式的箭头来明确。
用例是软件产品的外部用户（参与者）和软件产品自身的交互模型。
包含关系在UML中当作构造型对待。
扩展关系：用例是标准用例的变体。
交互图显示软件产品中的对象与另一个对象交互的方式。
交互图：顺序图和通信图（协作图）
对象可以向本身发送消息——自调用
状态图
活动图：显示各种事件是如何协调的.
组件图：显示软件组件之间的依存度，包括源代码、编译代码以及可执行载入映像。
部署图：显示每个软件组件安装（或部署）在哪个硬件组件上。