定义：软件工程即用系统科学的工程性方法解决软件开发时遇到的问题，也就是，将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护。

目的：生产出高质量的软件进而找到解决方案，并考虑那些对质量有影响的特性。

方法：

分析---分析问题，调查软件正反两方面

设计---给出解决方案

开发团队---描述在团队中的人员的角色和职责

开发---实现解决方案（实现对象、活动、封装等等）

项目管理---将系统分为小部分，逐步明确过程，控制进度，处理每个改变等

作用：付出较低的开发成本，达到要求的软件功能，取得较好的软件性能，开发的软件易于移植，需要较低的维护费用，能按时完成开发工作，及时交付使用。

它表示开发软件时特定的方法或哲学。是软件开发的全部过程，活动和任务的结构框架，它能直观的表达软件开发全过程，明确要完成的主要活动，任务和开发策略。

错误:是进行软件开发过程中人为出错造成的

例如，设计人员可能误解了某个需求，创建出与需求分析人员和用户的实际意图不相符的设计。这个设计故障是一种错误的编码，可能导致其他故障，如不正确的代码或用户手册中不正确的描述等。

故障/缺陷：方法实现时出现的问题。（静态存在）

失效:是指程序运行中出现的问题（由于故障产生）。（动态存在）

例如，需求文档可能会包含故障，所以即使系统按照需求规格来运行，如果它未进行应有的行为，也称为失效。

联系：单个错误可能产生多个故障。故障是系统的内部视图，这是从开发人员的角度看待系统；而失效是系统的外部视图，它是用户所看到的问题。并非每一个故障都对应于一个失效（不执行故障代码就不会是代码失效）。

产品的质量

用户考虑产品的功能要易于使用和学习

开发人员考虑产品的内部特性。

过程的质量

有很多活动会影响到最终的产品质量。只要活动出了差错，产品的质量就会受到影响。

商业环境背景下的质量

技术价值并不能直接转换为商业价值，软件开发还需要将技术价值和商业价值统一起来

系统 = 实体 + 活动 + 关系 + 边界

1. 需求分析和定义───《软件需求规格说明书》
2. 系统设计───《软件系统结构图》
3. 程序设计─┐
4. 程序实现─┴─程序文档（设计文档、源代码、注释）
5. 单元测试─┐
6. 集成测试─┼─《测试报告》
7. 系统测试─┘
8. 系统提交───《用户手册和操作手册》
9. 维护    ───《维修报告》

1. 商业软件的投放市场时间的紧迫性
2. 计算经济学的改变
3. 强力的桌面计算平台的可用性
4. 局域网和广域网的延伸
5. 面向对象技术的出现和采用
6. 使用窗口、图标、菜单和指针的图形用户界面
7. 瀑布模型用于软件开发的不可预测性

重用：重复采用以前开发的软件系统中具有共性的部件, 用到新的开发项目中去。

抽象：某种层次归纳水平的问题描述。它使我们将注意力集中在问题的关键方面而非细节。

软件过程：

将一组有序的任务称为过程，它涉及活动、约束和资源使用等一系列步骤，用于产生某种想要的需求。软件过程是软件开发活动中的各种组织及规范方法。

重要性：

1. 通用性（一致性/结构性）一致性和结构性可以使我们知道是否已经做好了工作，还能使别人以同样的方式做工作，因而具有相对通用性。

1. 自我指导性

软件生命周期：软件开发过程

瀑布模型：它将开发阶段描述为从一个阶段瀑布般得转换到另外一个阶段。

需求分析                                        《SRS》软件需求规格说明书

系统设计                                          系统设计文档《SAD》

程序设计                                          模块功能算法和数据描述文档

编码                                                 源程序和注释

单元测试和集成测试                        单元测试报告

系统测试                                          系统测试报告

验收测试                                          验收测试报告

运行与维护                                      维护报告

优点：

1. 每一过程活动有其相关联的里程碑和提交物（经理便于评价）
2. 简单性（容易对用户解释）
3. 其他复杂模型的基础（添加反馈循环和额外的活动）

缺点：

1. 不能反映实际的代码开发方式
2. 面临软件变动时, 该模型无法处理实际过程中的重复开发问题

----软件是一个创造的过程, 不是一个制造的过程。

1. 当时的文档转换有困难

原型：一种部分开发的产品，用来让用户和开发者共同研究，提出意见，为最终产品定型。

用途：减少开发中的风险和不确定性

含义：系统被设计成部分提交, 每次用户只能得到部分功能, 而其他部分处于开发过程中。

分类：增量式和迭代式 (对原型化模型的改进)

增量式开发：

1. 系统需求按照功能分成若干子系统，开始建造的版本是规模小的、部分功能的系统，后续版本添加包含新功能的子系统，最后版本是包含全部功能的子系统集。

迭代式开发：

1. 系统开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统的功能达到最强性能。

任务：计划      目标/可选方案     风险评估     开发和测试

含义：操作概念  软件需求          软件设计     系统实现与部署运行

1. 设计对于分析模型应该是可跟踪的：软件的模块可能被映射到多个需求上。
2. 设计结构应当尽可能的模拟实际问题。
3. 设计应当表现出一致性。
4. 不要把设计当成编写代码。
5. 在创建设计时就应该能够评估质量。
6. 评审设计以减少语义性的错误。

统一过程（UP）可以用三句话来表达：

它是用例驱动的、以基本架构为中心的、迭代式和增量性的软件开发过程框架，它使用对象管理组织（OMG）的UML 并与对象管理组织（OMG）的软件过程工程原模型（SPEM）等相兼容。

RUP是IBM提供支持和包装的UP系统。

进化式迭代开发：

1. 迭代开发是统一开发过程(RUP)的关键实践
2. 开发被组织成一系列固定的短期小项目
3. 每次迭代都产生经过测试、集成并可执行的局部系统
4. 每次迭代都具有各自的需求分析、设计、实现和测试
5. 随着时间和一次次迭代，系统增量式完善

项目进度是对特定项目的软件开发周期的刻画。包括对项目阶段、步骤、活动的分解，对各个离散活动的交互关系的描述，以及对各个活动完成时间及整个项目完成时间的初步估算。

活动：项目的一部分, 一般占用项目进度计划中的一段时间。

里程碑：指特定的时间点, 标志着活动的结束, 通常伴随着提交物。

关键路径法（CPM）

时差=可用时间-真实时间

时差=最晚开始时间-最早开始时间

完成工作的能力，对工作的兴趣，开发类似应用的经验，使用类似工具或语言、开发环境、技术的经验，培训，与其他人交流的能力，与其他人共同承担责任的能力，管理技能。

主程序员负责制组

忘我方法

专家估算：请几位专家做出3种预测，来形式化地表示类推过程：一个悲观的预测（x）、一个乐观的预测（y），和最可能的预测（z），通过公式（x+4y+z）/6计算这些数的beta概率分布的平均值。通过使用这种技术，产生的估算是对个人估算的“规范化”。

算式估算：使用表示工作量和影响工作量的因素之间关系的模型进行估算。这些模型通常用方程式描述。大部分模型认为项目规模是方程式中影响最大的因素，表示工作量的方程是：E = (a + bSc) m(X)。其中S是估算的系统规模，而a、b、c是常量。X是从x1到xn的一个成本因素的向量，m是基于这些因素的一个调整因子。

阶段一：项目通常构建原型以解决包含用户界面、软件和系统交互、性能和技术成熟性等方面在内的高风险问题。

阶段二：设计人员必须研究几种可选的体系结构和操作的概念。

阶段三：开发已经开始，可以根据功能点或代码行来进行规模估算。

软件风险：在软件生产过程中不希望看到的、有负面结果的事件。

对来自用户的关于软件系统的期望行为的综合描述, 涉及系统的对象、状态、约束，功能等。

原始需求->获取问题分析->规格说明草稿->需求核准->正式的 <SRS>

1. 绝对要满足的需求（必须的）
2. 非常值得要的但并非必须的需求（值得要的）
3. 可要可不要的需求（可选的）

例如：信用卡记账系统：

要求列出最近的费用（1）

要求加起来并要求在某日期前支付（2）

要求购买类型分析（3）

A:  针对需求确定一种量化的描述方法，避免模糊的表达方式

B:  将各种指代用词替换为实体的正式名称

C:  每个名词或款项应在需求文档中给出唯一定义。

需求定义和需求规格说明

功能性需求：描述系统内部功能或系统与外部环境的交互作用,涉及系统输入应对,实体状态变化,输出结果,设计约束与过程约束等。

非功能性需求/质量需求：描述软件方案必须具备的某些质量特征。

设计约束：已经作出的设计决策或限制问题解决方案集的设计决策，例如平台或构建接口的选择。

过程约束：对于构建系统的技术和资源的限制。例如，客户可能坚持使用敏捷方法，以便在继续增加新特征的时候能够使用早期版本。

正确性：我们和客户都应该评审需求文档，确保它们符合我们对需求的理解。

一致性：一般来讲，如果不可能同时满足两个需求，那么这两个需求就是不一致的。

无二义性：如果需求的多个读者能够一致、有效地解释需求，那么需求就是无二义性的。

完备性：如果需求指定了所有约束下的、所有状态下的、所有可能的输入的输出以及必需的行为，那么这组需求就是完备的。

可行性：当用户要求两个或更多的质量需求时，常常会出现可行性问题。

相关性：有时，某个需求会不必要地限制开发人员，或者会包含与客户需要没有直接关系的功能。

可测试性：如果需求能够提示验收测试（明确证明最终系统是否满足需求），需求就是可测试的。

可跟踪性：对需求进行精心组织并唯一标记，已达到易于引用的目的；求定义中的每一条都在需求规格说明中有对应，反之亦然。

数据流图，箭头表示数据流，数据存储是一个正式的库或信息库，表示为两个平行的条，数据源或者数据接收器表示为矩形，称为参与者。

抛弃型原型：为了对问题或者提议的解决方案有更多的了解而开发的软件。

在真正实现后就抛弃不用了。

演化型原型：用于了解问题，并作为将来准备提交的系统的一部分而开发的软件。

体系结构:一种软件解决方案，用于解释如何将系统分解为单元，以及单元如何相互关联，还包括这些单元的所有外部特性。

设计模式：编写了设计决策以及最好的实践，它们根据设计原则来解决一些特定的问题；它们不是拿来就可以使用的打包的解决方案，而是解决方案的模板，必须针对特定的状况进行修改和调整。

一种针对单个软件模块或少量模块而给出的一般性解决方案，它提供较低层次的设计决策。(此设计决策低于体系结构)  (注: 此处为说明,不是定义)

设计公约：一系列设计决策和建议的集合，用于提高系统某方面的设计质量。

概念设计：告诉客户系统要做什么，即软件架构和功能。

技术设计：相当于程序设计，告诉程序员软件系统将要做什么，即程序员的参考文档。

初始建模->分析->文档化->复审->输出:正式的 <SAD> ：软件体系结构文档

体系结构设计：由软件需求中的系统能力与系统部件关联起来而得到软件整体结构的过程

代码设计：各个部件（模块）的算法、数据结构的设计

运行设计：最底层设计—内存分配、数据格式、位模式等

关系：流程工作中，先是体系结构设计，然后是代码设计，最后是运行设计；随着设计人员对解决方案及其含义有更多的理解，他们就会往返于各层次之间。（程序设计由代码设计和运行设计组成）

体系结构：一种软件设计方案，说明如何将系统分解为单元以及这些单元的关联方式，以及所有单元的外部可见特性。

体系结构风格: 大规模系统结构模式, 包括规则、元素、技术。

模块化：也称作关注点分离，是一种把系统中各不相关的部分进行分离的原则，以便于各部分能够独立研究。

抽象：对细节的隐藏。

设计界面要注意解决的要素（寓意/比喻、思维模型、模型的导航规则、外观、感觉）；

文化差异问题；

用户爱好问题。

耦合：两个软件部件之间的相互关联程度。

耦合的六种层次：

非直接耦合：模块相互之间没有信息传递

数据耦合  ：模块间传递的是数据

特征耦合  ：模块间传递的是数据结构

控制耦合  ：模块间传递的是控制量

公共耦合  ：不同模块访问公共数据

内容耦合  ：一个模块直接修改另一个模块

(A模块直接调用B模块的私有数据, 或直接转移到B模块中去)

内聚：软件部件内部各组成成分的关联程度。

内聚的七种层次：

偶然性内聚：不相关的功能, 过程,数据等出现在同一个部件中

逻辑性内聚：逻辑上相关或相似的功能或数据放置在同一个部件内

时间性内聚：部件各部分要求在同一时间完成

通讯性内聚：各部分访问共享数据

过程性内聚：各部分有特定次序

顺序性内聚：各部分有输入输出关系

功能性内聚：各部分组成单一功能

复审： 检查文档是否满足所有功能及质量需求。

设计复审的重要性：

(1) 复审中批评和讨论是“忘我”的， 能将开发人员更好地团结在一起， 提倡并增强了成员之间的交流

(2) 在评审过程中故障的改正还比较容易， 成本还不高， 在这时候发现故障和问题会使每一个人受益。

面向对象是一种软件开发方法，它将问题及其解决方法组织成一系列独立的对象，数据结构和动作都被包括在内

基本特征：分类、抽象、封装、继承、多态、持久性、一致性

设计模式编写了设计决策以及最好的实践，它们根据设计原则来解决一些特定的问题；它们不是拿来就可以使用的打包的解决方案，而是解决方案的模板，必须针对特定的状况进行修改和调整。

抽象、接口、模块化、通用性、信息隐藏、增量式开发

语言具有一致性（采用相同的语义结构（类、对象、接口、属性、行为）描述问题和解决方案）

过程具有一致性（从需求到测试，所有的过程采用相同的语义构造）。

OO需求分析+OO高层设计+OO低层设计+OO编程+OO测试

用例：描述系统提供的特定功能， 用椭圆表示

执行者：和系统交互的实体（ 用户、 设备或其他） ， 用小人表示。

包含：对已定义用例的复用， 用以提取公共行为， 用带箭头的实线表示

扩展：对一个用例的扩展使用， 用以下图标表示

用例：描述了应该执行或展示的特定功能

用例图：通过建立用户、外部项、其他实体的对话模型，而对系统将要完成的功能进行描述或刻画。

这些表示法每种都显现了系统的某个方面，因此相应地，这种表达也提供了对于问题或解决方案的详细描述。

1. 设计人员可能没有处理平台和编程环境的所有特性， 易于用图表示的结构和关系并不是总能直截了当的编写代码。
2. 编写的代码要易于自己和他人理解
3. 编写的代码要易于重用

编程标准对自身的用处

编程标准对他人的用处

设计与编程实现相匹配

编写更快代码的代价。可能会使代码更加复杂，从而花费更多的时间编写代码。

测试代码的时间代价。代码的复杂度要求有更多的测试用例或测试数据。

用户理解代码的时间代价。

需要修改代码时，修改代码的时间代价。

其他程序注释，包括：

版本注释：随着时间进行修改的记录。

解释性注释：本段源代码是在做什么的注释。

分解性注释：通过注释将代码分解成多个段。

注意的问题：
1、分段注释。
2、注释和代码要一并更改。
3、注释要有意义。
4、一边写代码一边写注释，不要写完代码回过头来添加注释。

极限编程（XP）是一种轻量级的软件开发方法论，属于敏捷开发方法。XP是经过实践后对实践的总结，其主要特征是要适应环境变化和需求变化，充分发挥开发人员的主动精神。XP承诺降低软件项目风险，改善业务变化的反应能力，提高开发期间的生产力，为软件开发过程增加乐趣等等 。

派对编程属于主要的敏捷开发方法，其开发方式是两个程序员共同开发程序，且角色分工明确。一个负责编写程序，另一个负责复审与测试。两人定期交换角色。

规格说明可能是错误的，或者遗漏了某个需求。

对于指定的硬件和软件，规格说明中可能包含不可能实现的需求。

系统设计中可能包含故障。

程序设计中可能包含故障。

程序代码可能是错误的。

当不存在明显的故障时，我们就测试程序，通过创造一些条件，使代码不能像计划的那样做出反应，看一看能否发现更多的故障。因此，知道我们正在查找什么类型的故障是很重要的。

算法缺陷，计算和精度缺陷，文档缺陷，过载缺陷，能力缺陷

被分类的任何一项故障都只属于一个类别， 则分类方案是正交的。

如果一个故障属于不止一个类， 则失去了度量的意义。

模块测试、构件测试或单元测试： 将每个程序构件与系统中的其他构件隔离， 对其本身进行测试。

集成测试：测试系统构件是否符合系统和程序设计规格说明中描述的功能共同工作。

功能测试：测试系统的功能是否符合需求规格说明文档中描述的功能，其结果是一个可运转的系统。

性能测试：测试系统的软硬件性能是否符合需求规格说明文档中的描述。其结果是一个确认的系统。

验收测试：确定系统是按照用户的期望运转的。

安装测试：确保系统在实际环境中按照应有的方式运转。

系统测试：功能测试、性能测试、验收测试和安装测试统称为系统测试。

测试过程中难以排除个人感情，因此，通常使用独立的测试小组来测试系统，这样就避免了故障的个人责任与尽可能多地发现故障的需要之间的冲突。

黑盒：测试人员在完全不了解程序内部的逻辑结构和内部特性的情况下，只依据程序的需求规格及设计说明，检查程序的功能是否符合它的功能说明。

白盒：以测试对象的内部结构为基本依据，手工或自动的展开各种测试。

检查代码，与需求及设计比较->编译代码(编译和调试)->开发测试用例并进行测试

在走查中，程序员向评审小组提交代码及其相关文档，然后评审小组评论它们的正确性。

在审查中，评审小组按照一个事前准备好的关注问题清单来检查代码和文档（更正式）。

分类：

等价分类法  边界值分析法  错误猜测法  因果图法

逻辑覆盖法，包括：

语句覆盖：使被测程序的每条语句至少执行一次；

判定覆盖：使被测程序的每一分支至少执行一次，故又称分支覆盖；

条件覆盖：要求判定中的每个条件均按“真”、“假”两种结果至少执行一次。

如果判定中仅含一个条件，条件覆盖也就是判定覆盖；但若判定中包含两个或更多的条件，情况就不同了。

条件组合覆盖：要求让所有结果的所有可能都至少出现一次。

路径测试法，包括：

节点覆盖：程序的测试路径至少经过程序图中的每个节点一次

边覆盖：程序的测试路径至少经过程序图中的每条边一次

路径覆盖： 程序的测试路径至少经过程序图中的每条路径一次

完全覆盖：同时满足节点覆盖和边覆盖的覆盖称为完全覆盖

分类：

由底向上集成测试  自顶向下集成测试  莽撞测试  混合方式测试（三明治测试）

驱动模块：代替上级模块传递测试用例的程序)

桩模块：代替下级模块的仿真程序

面向对象系统的测试中更容易和更困难的部分：

(1)测试用例的充分性：对过程语言而言，当系统改变时，我们可以针对改变测试是否正确，并使用原有的测试用例来验证剩余的功能是否同原来一致。但是面向对象的测试中，我们可能需要编写不同的测试用例。

(2)面向对象趋向于小粒度，并且平常存在于构件内的复杂性常常转移到构件之间的接口上。 这意味着，其单元测试较为容易，但是集成测试涉及面变得更加广泛。

(3)传统测试和面向对象的测试主要集中在：需求分析和验证、测试用例生成、源码分析和覆盖分析。

（1）制定测试目标

（2）设计测试用例

（3）编写测试用例

（4）测试测试用例

（5）执行测试

（6）评估测试结果

功能测试：测试系统的功能是否符合需求规格说明文档中描述的功能，其结果是一个可运转的系统。

性能测试：测试系统的软硬件性能是否符合需求规格说明文档中的描述。其结果是一个确认的系统。

验收测试：确定系统是按照用户的期望运转的。

安装测试：确保系统在实际环境中按照应有的方式运转。

系统配置：交付给特定客户的一系列部件的集合

配置管理：对系统不同软件配置的管理及控制方法（既有开发，也有测试），通过控制系统差别以降低风险，减少错误

基线：是指软件文档和其他资料的集合，它们代表了产品在某一时间点的情况(以及其他参考点)

回归测试是用于新的版本的一种测试，以验证与旧版本相比，它是否以同样的方式执行相同的功能。

功能测试：基于系统功能性需求，属于闭盒测试。我们不必知道正在执行哪个构件，相反，必须知道系统应该做什么。

作用：将系统的实际表现与其需求进行比较。

A: 较高的查错概率

B: 独立的测试团队

C: 了解预期的输出结果

D: 对合法与非法的输入都予以测试（假设是弱健壮等价类）

E: 不能仅仅为了测试的方便而修改系统

F: 停止测试应该有前提条件

在我们确定系统能执行需求所要求的功能之后，就要考虑这些功能执行的方式。

因此，功能测试针对的是功能需求，而性能测试针对的是非功能需求。

A: 压力测试 / 强度测试(在短时间内加载极限负荷, 以验证系统能力)

B: 巨量数据测试 / 容量测试(验证系统处理巨量数据的能力)

C: 配置测 ---构建测试用例 对系统软硬件的各种配置(最小到最大)进行测试。

D: 兼容性测试---测试接口等

E: 回归测试

F: 安全测试

G: 计时测试

H: 环境测试

可用性：是指在给定的时间间隔，一个系统能够按照规格说明正确运作的概率。

可靠性：是指一个软件系统在给定的时间间隔和给定条件下运行成功的概率。

可维护性：是在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。

当功能测试和性能测试完成后，我们确信，系统满足在软件开发的初始阶段过程中指定的所有需求，下一步要询问客户和用户，他们是否持有同样的观点。

基准测试：客户准备一组代表在实际安装后系统运作的典型情况的测试用例。针对每一个测试用例，客户评估系统的执行情况。

并行测试：当一个新系统要替代现有系统，或者该新系统是分阶段开发的一部分，使用并行测试。在并行测试中，新系统与先前版本并行运转，用户逐渐地适应新系统，但是继续使用与新系统功能相同的老系统。

引导测试：在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化（分为α测试和β测试两种）

α测试：在客户进行实际的试验性测试之前先让来自自己组织机构或公司的用户来测试这个系统，这样的内部测试称为α测试。

β测试：客户的测试，属于试用性质的非正式的验收测试。

即在用户的场所安装系统。如果验收测试已经是在实地进行，就不一定需要安装测试了。