软件=程序+数据+相关的文档

1. 能够提供客户所需功能与性能的计算机程序
什么是软件？软件包括：

2. 使程序能够适当的操作信息的数据结构
3. 用于设置程序的配置文件、用于描述程序结构及开发过程的系统文档及解释如何使
用系统的用户文档

优良软件的属性：
可维护性（Maintainability）：软件按需求变化不断进行的能力
可依赖性（Dependability）：包括软件可靠性、保密性、安全性
有效性（Efficiency）：软件对内存、CPU等系统资源的利用率
可用性（Usability）：软件是否易用，易被客户接受

工程：应用有关的科学知识与技术手段，通过有组织的群体协作活动，建造具有预期
使用价值的人造产品的过程。

软件危机：指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软
件开发与维护过程中出现一系列严重问题的现象，如开发效率低下、成本高、质量无
法保障、可维护性差等。
软件工程被认为是能够解决软件开发严重问题的有效途径。

什么是软件工程
软件工程是涉及软件生产各个方面的一门工程学科
软件工程涉及软件生命周期的各个方面，从软件需求的确定到软件退役。
软件工程还涉及软件开发中的人为因素，如团队组织；经济因素，如成本估算；法律
因素，如版权保护
软件工程：1.将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过
程，即将工程化应用于软件；2.研究1中的方法

软件过程与软件生命周期
软件过程是指开发或制作软件产品的一系列活动及其成果

1.描述（Specification）：系统应该提供的功能及其开发约束
所有的软件过程中都包括四个基本活动：

2.开发（Development）：软件产品的生产过程
3.有效性验证（Validation）：检验软件产品是否满足了客户的需要
4.进化（Evolution）：按照用户的变更要求不断的改进软件
软件生命周期是软件过程的另一种形象描述，通常包括需求定义、分析与描述、软件
设计、实现、测试、维护与退役等活动。

软件工程方法
软件工程方法是软件生命周期中使用的一整套技术方法的集合，包括系统模型描
述、约束规则、设计建议和过程指南等组成元素。
目前，软件方法的发展经历了四个阶段：
面向过程、面向对象、面向构件、面向服务，四个阶段软件复用程度逐渐提升，软件
开发效率越来越高

软件项目的成功要素
一个成功软件项目的三个要素包括：按时交付、不超预算、满足用户要求

软件工程行业规范
软件工程师应该遵循的行为准则：保密、工作能力、知识产权、计算机滥用

瀑布模型（顺序模型）

1.需求分析和定义 2.系统和软件设计 3.实现和单元测试 4.集成和系统测试 5.运行和维

护

瀑布模型的特点和适用情况
这种模型生硬地把一个软件过程划分成几个界限清晰的阶段，而且这些阶段前后有严
格的顺序，这导致它很难对用户的需求变更做出及时的调整；因此，瀑布模型只适合
需求非常清楚和需求变更被严格限制的情况下。

进化式开发模型
基本思想：通过开发系统原型和用户反复交互，以明确需求，使系统在不断调整与修
改中得以进化成熟。又叫做原型式开发方法。
两种基本类型：探索式开发、抛弃式原型法

1.降低了适应需求变更的成本，变更分析与修改文档的工作量比瀑布模型少很多；
较之瀑布模型有的三大优势：

2.用户的深度参与可以提供更及时有效的反馈，并能体现在不同版本的开发进度中；
3.相比于瀑布模型，能够更早的交付和部署有用的软件给客户
1.缺乏过程可见性
问题：

2.系统结构通常会很差
3.需要一些特定的技术，通常与主流技术不兼容

1.适合中小规模的交互系统
适用情况：

2.可用于大型系统的局部开发，可以和瀑布模型混合使用
3.生命周期较短的系统

增量式开发的特点
在这种开发方式中，系统不是作为一个整体交付，而是被分解成若干个可以单独交付
的模块-增量，每个增量交付系统的部分功能。
用户的需求按优先级排队，优先级最高的需求被放入最早交付的增量中。这样，优先
级最高的系统功能就得到最多的测试，系统的可靠性较高。

基于构件的软件工程
软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过
程。
软构件是标准的、可以互换的、经过装配可随时使用的软件模块。

软件复用的意义
软件复用的出发点是使软件系统的开发不在“一切从零开始”，能够充分利用已有的知识
和经验。
软件复用能够在软件开发中避免重复劳动，充分利用已有的开发结果，提高开发效
率，降低开发成本。
软件复用还可以避免全新开发可能引入的错误，从而提高软件的开发质量

需求描述->构件分析->需求修订->基于复用的系统设计->开发与集成->系统验证

敏捷开发方法的基本原则：
客户参与、增量式交付、人非过程、保持变更、保持简单性

敏捷开发方法的适用情况
中小规模的开发团队
每个团队成员都可以参与决策
需求变更频繁的项目
风险高的项目

软件过程改进
软件过程改进是提升软件产品质量以及软件过程效率和效果的重要手段。
软件过程改进重点在于改善软件过程与项目管理以及将优良的软件工程实践引进到机
构中，以达到提高软件质量、降低成本、减少开发时间的目的。
CMM（Capability Maturity Model for Software）软件能力成熟度模型
SEI（美国卡内基-梅隆大学软件工程研究所）给CMM下的定义是：
对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各个发展阶段的

SW-CMM为软件企业的过程能力提供了台阶式结构，共分五级，分别是初始级、可重
描述。

级、定义级、管理级和优化级。

需求的两个不同层次的描述：
用户需求、系统需求

功能需求与非功能需求
功能需求、非功能需求、领域需求
功能性需求与非功能性需求相比较，非功能需求往往更为关键，因为非功能需求表示
的是系统的整体特征，而功能性需求描述的则是局部功能。
功能性需求描述应该具备全面性和一致性。
非功能需求的常见问题是检验困难，描述时应该设定明确目标并设定可测试的度量标
准

需求工程过程
需求工程过程并不具有唯一的模型，在所有的过程中都会涉及一些共同的活动它们
是：
可行性研究；
需求导出和分析；
需求描述；
需求有效性验证；
需求管理

可行性研究
可行性研究要决定被提议的系统是否值得去做。
进行可行性研究包括信息评估、信息汇总和书写报告三部分工作。
信息的评估与汇总需要分析人员与信息持有者相沟通，通过提出问题汇总信息。

需求导出与分析
这个阶段在可行性研究之后进行，通常与需求描述交叉进行
需求导出的过程活动包括：需求发现、需求的分类与组织、优先排序和冲突解决、需
求文档化
需求的发现与识别是整个过程中最为关键的活动。
信息的来源包括已有的文件，系统的信息持有者以及相近系统的规约描述

需求要从多个视点进行分析
视点用来表述不同角度的需求来源。每一个视点代表系统需求的一个子集。
从多视点对系统进行分析是十分重要的，因为没有哪一种单一的途径能够诠释整个系
统需求。
视点一般可以分成直接视点、间接视点和领域视点

结构化分析建模
结构化分析方法是一种面向数据流的系统建模技术，它从数据加工的角度对系统进行
规格描述
结构化分析方法建立的分析模型结构如图

结构化分析模型的核心是数据词典，它描述了所有的在目标系统中使用的和生成的数
据对象。
围绕着这个核心的有三种图：实体关系图（ERD）描述数据对象及数据对象之间的关
系；数据流图（DFD）描述数据在系统重如何被传送或变换，以及描述如何对数据流
进行变换的功能（子功能）；状态-迁移图（STD）描述系统对外部事件如何相应，如
何动作。
因此，ERD用于数据建模，DFD用于功能建模，STD用于行为建模。
需求有效性验证
需求有效性验证的目的是检验需求描述是否正确地反映了客户的意愿。

需求检查
对需求文档中定义的需求要进行多种检查，包括：
有效性、一致性、完备性、现实性、可检查性

软件工程中的设计
设计是一个把问题转换成解决方案的创造性过程；
设计解决的是“如何实现系统”的问题；
从工程管理的角度，软件设计可以分成概要设计（总体设计、系统设计）与细节设计
（详细设计）

模块化
模块化的思想，即把软件划分为可独立命名和编址的构件，每个构件称为一个模块，
每个模块完成一个子功能，当把所有模块组装到一起成为一个整体时，便可以完成指
定的功能。
模块组成系统或子系统。
“一个复杂问题分割成若干个容易解决、容易管理的小问题后更易于求解”，模块化正是
以此为依据把系统划分成若干个模块，各个击破（分而治之）

信息隐藏与独立性
信息隐藏原理告诉我们，模块应该是功能独立的。

1.它支持模块的并行开发；
采用信息隐藏原理指导模块设计有很多好处：
2.减少测试和后期维护的工作量
3.整个系统扩充功能只需“插入”新模块，原有的多数模块无须改动

模块独立性
模块独立性可用两个定性准则来度量：耦合性（coupling）和内聚性（cohesion）
耦合是模块之间相对独立性的量度，而内聚则是模块功能相对强度的量度。
模块的内聚性越强，耦合性越弱，独立性越强

抽象
人类在认识复杂现象的过程中使用的最强有力的思维工具就是抽象

逐步求精（细化）
逐步求精是与抽象密切相关的一个概念，可视为早期的自顶向下的设计策略
层次结构的上一层是下一层的抽象，下一层是上一层的求精

体系结构设计
体系结构（又称架构）设计的任务是要识别出组成系统的子系统并建立子系统的控制
和通信框架。

几种常见的体系结构风格
三种应用广泛的组成模型：
数据中心体系结构（容器模型）
客户/服务器体系结构
抽象机或分层体系结构

数据中心体系结构的基本特点：
所有共享数据放到一个中心数据库中，所有子系统都能从中存取数据；
当系统中存在大量的数据共享时，数据中心模型是最为常用的体系结构风格。

客户/服务器体系结构
客户/服务器模型是一个分布式系统模型，数据和加工过程在多个处理器之间分配；
这种模型的主要组成：
一组为其他子系统提供服务的单机服务器
一组向服务器请求服务的客户机
连接客户机与服务器的网络

分层体系结构：
这种模型把系统组织成一系列的层次，每一层提供一组服务
这种模型支持增量式的开发，不同层次的服务可以单独交付
层与层之间以接口相联系，一个接口发生改变，只有毗邻的层会收到影响

体系结构视图
一个体系结构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中
涵盖了系统的某一特定方面，而省略了与此方面无关的实体
控制模型
对控制流建模有两种一般性方法：
集中式控制、基于事件的控制
集中式控制按子系统顺序执行还是并行执行分为两类：
调用-返回模型、管理者模型
基于事件的控制主要有两种：
广播模型、中断驱动模型

鲁棒性分析的输入：
一个用例
这个用例的用例场景
这个用例的活动图
域模型

鲁棒性分析的输出：
通过一个UML序列图和一些设计组件：边界、服务、实体、组件，得出用鲁棒图表示
的设计模型。

鲁棒性分析建立设计模型的过程

界面设计的一般原则：
用户熟悉
一致性
意外最小化
可恢复性
用户引导
用户差异性

错误消息
错误消息应该是礼貌的、简明的、一致的和建设性的

帮助系统设计
软件帮助系统不能是用户手册的简单复制，应该有一个合理的组织与结构，应该为用
户提供不同的入口

程序设计与调试
程序设计的任务是把设计转换成程序以及在程序中去除错误，包括编程与调试两个过
程。
通常，程序员要对自己开发的程序进行测试，这时程序中的一些明显错误会暴露出来
并被根除，这个过程叫调试。
验证和有效性确认
验证：检查软件是否符合它的规格描述（不符合描述的即为“软件缺陷”）
有效性确认：检查软件是否满足客户的期待（要检查系统是否符合客户的真是愿望）

用来实现V&V目标的测试类型
缺陷测试、有效性测试

V&V过程的两种基本方法
软件审查、软件测试
测试的目的是为了揭示程序中存在错误，而不是没有错误（判断）
按照测试的不同目标可以把测试分成有效性测试与缺陷测试。

的，是起决定性作用的V & V技术。

静态审查无法检验软件是否可用，也不能检验非功能需求，因此程序测试是必不可少

在V & V过程中，程序测试和静态审查通常是结合在一起使用的。

测试和调试
测试和调试是不同的过程，通常交叉进行。
缺陷测试的目的是确定系统中存在缺陷
调试考虑的是定位和修改缺陷

V&V规划
V&V过程的规划应该从开发过程的早期就开始

组件测试：
测试单个的程序组件；
通常由程序开发者完成；
这个阶段的测试大多依靠测试者的经验。
系统测试：
测试由组件整合成的子系统和系统；
有专门的测试团队进行测试
测试要依据需求规格说明进行
集成测试
集成测试分为自顶向下集成和自底向上集成

增量集成测试
为了简化测试中错误定位的问题，可以采用增量集成的方法

测试用例的设计
测试用例的基本构成可以包括：设计的输入、期望的输出、测试环境和测试对象的描
述。
设计测试用例是系统测试与组件测试的关键工作，主要是通过设计输入数据与预计的
输出来测试系统。
测试用例设计的目的是建立一组测试用例集合，用尽可能少的测试代价有效地发现系
统缺陷并证明系统能够满足需求。
设计测试用例的常用方法：
划分测试与边界值分析；
结构化测试（白盒测试）。

 黑盒测试又叫做功能测试，测试者只关心系统的功能而不关心软件的实现。也
黑盒测试与白盒测试

就是说测试者不必了解有关系统的任何细节，只把系统看成是一个能够处理输
入，产生输出的“黑盒子”，仅从功能的角度设计测试用例。
 白盒测试又叫做结构测试，是一种根据软件的结构知识导出测试用例的设计方
法。测试者把被测试组件看成是一个打开的“白盒子”，组件的内部结构对测试
者是透明的，通过对所用算法结构的分析设计测试用例。


等价划分测试
等价划分测试是测试用例设计的一种方法。设计测试用例时，可以按特征把
数据输入域划分成若干等价类，等价类中的每个数据应该以同样的方式得到处
理，因此对于揭露程序中的错误是等效的。这样，就可以选取少量有代表性的

 （看例题和练习题，要求会做类似习题）
输入数据作为测试数据，以期用较小的代价暴露较多的程序错误。

 按照不同的测试目标，逻辑覆盖又可分为：语句覆盖、判定覆盖、条件覆
逻辑覆盖法

盖、判定－条件覆盖、条件组合覆盖及路径覆盖。 其中语句覆盖覆盖度最
弱，路径覆盖最强！

 基本路径测试的原理：
基本路径测试

“在程序控制流图的基础上，分析控制结构的环路复杂度,并用这个复杂度为指南
定义执行路径的基本集合，从而导出基本可执行路径集合，设计出测试用例并保证每
个可执行语句至少执行一次，而且每个条件在执行时都将分别取真、假两种值。”
  （掌握本讲课后作业与课上练习）

 软件系统变更是不可避免的，软件系统开发的一个关键的问题就是如何实现和
系统变更与进化

 软件系统随变更要求不断更新改进的过程就是系统进化过程。
管理现存软件的变更；

 软件维护是指在软件交付使用之后，为了改正错误和满足新的需要而修改软件
软件维护

 维护通常包括四种类型：
的过程。

 纠正性维护——修补系统缺陷的维护，日常维护的主要工作。
 适应性维护——使软件适应不同的操作环境（软硬件环境）的维护
 完善性维护——增加或修改系统功能的维护
 预防性维护（再工程）——为预防系统后期可能的失效而做的维护。

 维护成本一般会高于开发成本；
维护成本

 影响维护成本的有技术因素也有非技术因素。
 开发阶段多些投入，有助于减少维护成本。
 软件年龄越大，维护成本越高。

 团队稳定性
影响维护成本的主要因素

 合同责任
 人员技术水平
 程序年龄与结构
预防性维护/软件再工程
预防性维护,或再工程，是由Miller提出来的，他的想法是“结构化翻新”。他把这种方法
定义为：“把今天的方法学应用到昨天的系统上，以支持明天的需求。

软件再工程过程模型
  软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，
软件项目管理

 软件项目管理主要考虑如何保证软件能够按时、按计划并满足用户需求规格的
而对成本、人员、进度、质量、风险等进行分析和管理的活动。

交付，即如何用科学的管理手段保障软件项目的成功。

软件项目管理中的4P’s
 人员（People）— “人的因素”是成功软件项目中最为重要的因素；
 产品（Product）— 产品的目标与范围，成本与开发约束是划分项目任务，制

 过程（Process）— 软件过程提供了完成特定软件项目所需的框架活动和开发
定项目进度的依据；

 项目（Project） — 把软件置于有计划的、可控的项目之中，是保证其成功的
任务的集合；

唯一途径。

1.确定项目范围
项目策划任务集

2.确定可行性
3.分析风险
4.确定所需的资源
5.估算成本和工作量
6.制定项目进度计划

 硬件和软件成本
软件项目的成本构成

 差旅费和培训费用
 工作成本
 经常性的管理费用

 活动网络图表示构成一个项目的不同活动之间的依赖关系以及由开始到结束的
活动网络图

关键活动路径。
  CMM 对质量的定义是：① 一个系统、组件或过程符合特定需求的程度；②
质量管理

 可以这样理解软件质量： 软件质量是许多质量属性的综合体现，各种质量属
一个系统、组件或过程符合客户或用户的要求或期望的程度。

性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高

 软件质量要素是指对软件整体质量影响最大的质量属性或者客户最关心的、能
软件的整体质量。

成为卖点的质量属性

 软件质量属性可分为两大类：
软件质量属性

 功能性质量属性：正确性，健壮性，可靠性。
 非功能性质量属性：性能，易用性，安全性，可扩展性，兼容性，可移
植性。

 可以用来评价软件质量的6个质量要素包括：
 功能性、可靠性、易用性、效率、可维护性、可移植性

配置管理
配置管理规程规定了如何记录和处理所提议的变更，如何使系统变更与系统组件相关
联，以及如何识别系统不同版本的方法。
配置管理的目的在于控制由变更带来的成本和人力消耗。