软件工程演示文稿

软件工程演示文稿目前一页\总数一百四十一页\编于十四点软件工程第章目前二页\总数一百四十一页\编于十四点经理管什么？计划预算组织进度标准什么是软件项目管理？目前三页\总数一百四十一页\编于十四点

管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。什么是软件项目管理？目前四页\总数一百四十一页\编于十四点什么是软件项目管理？成本管理：估算软件项目的成本，作为签订合同或项目立项的依据；在软件开发过程中按计划管理经费的使用。质量管理：制定软件质量保证计划；按照软件质量评价体系控制软件质量要素；对阶段性的软件产品进行评审；对最终产品进行验证和确认，确保软件产品的质量。软件配置管理：制定配置管理计划；对程序、文档和数据的各种版本进行管理，确保软件的完整性和一致性。目前五页\总数一百四十一页\编于十四点第2章 软件项目管理2.1软件度量2.2软件项目估算2.3软件质量度量2.4软件复杂性度量2.5软件可靠性度量2.6软件开发过程的管理目前六页\总数一百四十一页\编于十四点

软件度量是软件产品、软件开发过程或自愿简单属性的定量描述。如程序规模、操作符个数、程序中错误的个数等。面向规模的度量面向功能的度量2.1软件度量目前七页\总数一百四十一页\编于十四点2.1软件度量２.１.１软件度量的基本概念1．测量、度量、估算和指标

软件工程项目的定量描述涉及测量、度量、估算和指标等一些基本概念。目前八页\总数一百四十一页\编于十四点1）测量（measure）：对产品或过程的某个属性的范围、数量、维度、容量或大小提供一个定量的指示。2.1软件度量4）指标（guideline）：是一个度量或度量的组合，它可对软件产品、过程或资源提供更深入的理解。2）度量（metric）：对系统、部件或过程的某一特性所具有的程度进行的量化测量。如软件质量度量等。3）估算（estimation）：对软件产品、过程、资源等使用历史资料或经验公式等进行预测。如工作量、成本、完成期限等。估算一般用于立项、签订合同、制定工作计划等。目前九页\总数一百四十一页\编于十四点2．软件项目管理的对象及其属性

软件项目管理的对象主要包括产品、过程和资源等。产品（product）是指软件开发过程得到的文档和程序。过程（process）是指与软件项目有关的活动。资源（resource）是指进行软件项目所需要的各种支持。要对软件项目管理的对象进行有效的管理与控制，就必须对这些对象的属性进行测量、度量与估算。一般来说，产品、过程、资源等对象都具有内部属性和外部属性。2.1软件度量目前十页\总数一百四十一页\编于十四点对象的属性对象的内部属性是指对象本身的属性，如软件产品的代码长度、模块化的程度、复杂性等。对象的外部属性体现了对象与环境的关系，如软件的可靠性、可维护性、可移植性、成本、人员的生产率等。目前十一页\总数一百四十一页\编于十四点表2-1软件工程的产品、过程、资源的属性

产品过程资源内部属性程序代码行长度；程序功能；模块化；控制流结构；重用性；模块耦合度与内聚度。工作量；计划及进度；事件。人员；方法；工具；环境；经验。外部属性软件的可靠性；软件的可理解性；软件的有效性；软件的可用性；软件的可维护性；软件的可移植性。成本；可控制性；可观察性；稳定性。成本；生产率；时间。目前十二页\总数一百四十一页\编于十四点3．软件度量的分类可分为直接度量和间接度量两类：1）直接度量。即对不依赖于其他属性的简单属性的测量。如软件的模块数、程序的代码行数、操作符的个数，工作量、成本等。2）间接度量。即对涉及若干个其他属性的软件要素、准则或属性的度量。因为它们必须通过建立一定的度量方法或模型才能间接推断而获得。如软件的功能性、复杂性、可靠性、可维护性等等。2.1软件度量目前十三页\总数一百四十一页\编于十四点2.1.2面向规模的度量

面向规模的度量是以软件的代码行（LOC，LineofCode）数为基础的直接度量。

L表示软件的代码行数，单位为KLOC（千行代码）或LOC；

E表示开发软件所需工作量，单位为人月（PM）或人年（PY）；

S表示软件成本，单位为美元或元；

N表示错误个数；

Pd表示软件文档页数；

M表示开发所用的人数。目前十四页\总数一百四十一页\编于十四点1．软件开发的生产率P：P=L/E2．开发每行代码的平均成本C：C=S/L3．代码出错率EQR：EQR=N/L4．软件的文档率D：D=Pd/L面向规模的度量目前十五页\总数一百四十一页\编于十四点

面向规模的度量目前十六页\总数一百四十一页\编于十四点优点：简单、直接。缺点：①代码行数的估算依赖于程序设计语言的功能和表达能力。②对设计精巧的软件项目产生不利影响。③在开发初期估算代码行十分困难。④只适用于过程式程序设计语言。

面向规模的度量目前十七页\总数一百四十一页\编于十四点2.1.3面向功能的度量1．简单功能点度量1979年，Albrecht首先提出了功能点度量方法。这是一种面向功能的间接度量方法，即从软件定义的基本功能出发，来估算软件系统的规模。因此，该方法可以在软件开发项目的初期，在软件定义过程中即可预测待开发软件的规模。目前十八页\总数一百四十一页\编于十四点1．简单功能点度量功能点FP的度量公式如下：FP=CT×TCF=CT[0.65+0.01∑Fi]其中：CT——基本功能点。CT值按表2-2来计算，它的值为5个参数加权值的总和。14i=1目前十九页\总数一百四十一页\编于十四点表2-2简单功能点度量的基本功能点的计算测量参数值加权因子加权值简单一般复杂用户输入数×3×4×6=用户输出数×4×5×7=用户查询数×3×4×6=文件数×7×10×15=外部接口数×5×7×10=

基本功能点CT目前二十页\总数一百四十一页\编于十四点表2-2中的5个参数的含义1）用户输入数：用户为软件系统提供的输入参数的个数（不包括查询）；2）用户输出数：软件为用户提供的输出参数（报告、屏幕帧、错误信息等）的个数；3）用户查询数：一次联机输入导致软件以联机输出方式实时产生一个响应的个数；4）文件数：逻辑主文件的个数；5）外部接口数：机器可读的接口（如磁盘或磁带上的数据文件等）的个数。目前二十一页\总数一百四十一页\编于十四点1．简单功能点度量在FP度量公式中：TCF——技术复杂性调节因子。0.65和0.01——经验数据。Fi（i=1，2，…，14）——复杂性调节值。Fi所代表的因素如表2-3所示，每个Fi可根据实际情况取0、1、2、3、4、5中的一个值。其中：0—没有影响、1—偶然的、2—适中、3—普通、4—重要、5—极重要的影响。TCF取值范围：0.65~1.35。目前二十二页\总数一百四十一页\编于十四点表2-3Fi

取值表i因素Fii因素Fi1234567需要可靠的备份和恢复吗？需要数据通信吗？有分布式处理的功能吗？性能是关键吗？在现存实用的操作环境下运行吗？需要联机数据入口吗？联机数据入口需要用输入信息构造复杂的界面或操作吗？891011121314

需要联机更新主文件吗？输入、输出、文件、查询复杂吗？内部处理过程复杂吗？要求代码设计可重用吗？设计中包含转换和安装吗？系统设计支持不同组织的多次安装吗？系统设计有利于用户的修改、使用吗？目前二十三页\总数一百四十一页\编于十四点2．功能点度量简单功能点度量方法没有直接考虑软件本身的算法的复杂性问题。所以它仅适用于度量算法简单的事务处理等系统。1986年Jones对简单功能点度量进行了推广，在计算软件系统的基本功能点CT时，引入了算法复杂性因素，即使用表2-4计算CT。我们称这种推广的度量方法为功能点度量。这两种方法对一般的事务处理系统等算法简单的软件系统计算出来的FP值基本相同，但对于较复杂的软件系统，功能点度量方法比简单功能点度量方法计算出来的FP值要高20%~35%。目前二十四页\总数一百四十一页\编于十四点表2-4推广的功能点度量的基本功能点的计算测量参数值权值加权值用户输入数×4=用户输出数×5=用户查询数×4=文件数×7=外部接口数×7=复杂算法数×3=基本功能点CT目前二十五页\总数一百四十一页\编于十四点用功能点计算软件项目的有关参考量：1）生产率P：P=FP/E2）平均成本C：C=S/FP3）代码出错率EQR：EQR=N/FP4）软件的文档率D：D=Pd/FP

目前二十六页\总数一百四十一页\编于十四点3．功能点度量方法的优缺点优点：①可用于软件项目开发的初期阶段的项目估算。②与程序设计语言无关。缺点：①某些参考量的收集有一定困难；②度量值的主观因素较多，如Fi取值；③功能点FP本身没有直观的物理意义。目前二十七页\总数一百四十一页\编于十四点2.2软件项目估算常用的软件项目的估算方法主要有以下4种1．自顶向下的估算方法2．自底向上的估算方法3．差别估算法4．根据经验估算公式2.2.1软件项目的估算方法目前二十八页\总数一百四十一页\编于十四点1．自顶向下的估算方法基本思想：首先根据已完成项目的总成本或总工作量来推算待开发软件的总成本或总工作量，然后再按比例将其分配到各开发任务中去。即从整体到局部。优点：估算工作量小、速度快。缺点：对项目中的特殊困难估计不足，有可能产生遗漏，估算出的值盲目性较大。目前二十九页\总数一百四十一页\编于十四点2．自底向上的估算方法基本思想是：把待开发软件细分，直到每一个子任务或阶段都已经明确所需要的开发工作量或成本，然后再把它们累加起来，得到待开发软件的总工作量或总成本。优点：计算各个部分的准确性较高。缺点：缺少各个子任务之间相互联系的工作量和系统工作量（如项目管理、配置管理、质量管理），估算值往往偏低，必须用其他方法进行校正。目前三十页\总数一百四十一页\编于十四点3．差别估算法基本思想：把待开发的软件项目与过去完成的软件项目进行比较，从各子任务中区分出类似的和不同的部分。类似的部分按已知的实际量计算，不同的部分则采用某种方法进行估算。差别估算法综合了以上两种方法的优点。优点：估算的准确程度高。缺点：不容易划分相似的界限。目前三十一页\总数一百四十一页\编于十四点4．根据经验估算公式通过众多实际软件项目的经验，总结出一些有价值的软件成本和工作量估算的经验模型。这些模型对于软件项目管理具有一定的指导意义和验证效果。目前三十二页\总数一百四十一页\编于十四点2.2.2代码行和功能点的估算采用中介绍的估算方法可以估算出代码行或功能点的乐观值a、一般值m和悲观值b，并用如下的加权平均公式计算LOC或FP的期望值（expectation）：X=（a+4m+b）/6软件的LOC或FP的期望值估算出来后，就可以根据已有的标准生产率对成本和工作量等进行估算了。目前三十三页\总数一百四十一页\编于十四点2.2.3软件项目的经验估算模型1．IBM模型（静态单变量模型）数据利用最小二乘法拟合，得到的经验估算公式：E=5.2×L0.91D=4.1×L0.36=2.136×E0.3956S=0.54×E0.6DOC=49×L1.01目前三十四页\总数一百四十一页\编于十四点2．Putnam模型（动态多变量模型）该模型以工作量在30人年以上的大型软件项目的实测数据为依据，推导出了工作量分布曲线，如图2-2-1所示。2.2.3软件项目的经验估算模型目前三十五页\总数一百四十一页\编于十四点图2-2-1软件项目的工作量分布曲线系统定义功能设计规格说明设计编码测试和确认维护管理系统定义、需求分析开发运行维护0开发占总工作量的40%维护占总工作量的60%总工作量td时间t（年）工作量（人年）图2-2-1软件项目的工作量分布曲线目前三十六页\总数一百四十一页\编于十四点2．Putnam模型Putnam估算模型如下：L=CkE1/3td4/3Ck为技术状态常数，与开发环境有关，如下：2000较差，没有方法学的支持，缺乏文档和评审，采用批处理方式；Ck

=8000一般，有方法学的支持，有适当的文档和评审，采用交互处理方式；11000较好，有集成化的CASE工具和环境。E=L3/(Ck3td4)目前三十七页\总数一百四十一页\编于十四点图2-2-2人力资源的分配初级技术人员高级技术人员管理人员验收测试组装测试单元测试编码详细设计概要设计需求分析系统定义人数目前三十八页\总数一百四十一页\编于十四点Putnam模型的优缺点优点：揭示了软件项目的源程序代码长度、软件开发时间和工作量三者之间的关系，在理论上有重要意义。缺点：准确程度不高。没有反映软件产品、项目、参加人员、软硬件资源等属性。目前三十九页\总数一百四十一页\编于十四点3．CoCoMo模型（构造性成本模型）CoCoMo模型按其详细程度分三个层次：

基本CoCoMo模型；

中间CoCoMo模型；

详细CoCoMo模型。2.2.3软件项目的经验估算模型目前四十页\总数一百四十一页\编于十四点（1）基本CoCoMo模型其工作量和开发时间的估算公式如下：E=aLb

D=cEd

其中：L——软件代码行的估算值（以KLOC计）；E——工作量（以PM计）；D——开发时间（以月计）；a、b、c、d——经验常数。目前四十一页\总数一百四十一页\编于十四点表2-8a、b、c、d参数值的选取软件类型abcd适应领域组织型2.41.052.50.38一般应用程序半独立型3.01.122.50.35实用程序、编译程序等嵌入型3.61.202.50.32实时控制程序、操作系统目前四十二页\总数一百四十一页\编于十四点（2）中间CoCoMo模型中间CoCoMo模型在估算工作量时，在基本CoCoMo模型的基础上再乘以由15个因素组成的工作量调节因子EAF，于是有：E=aLbEAF=aLb∏Fi

其中：L——软件的代码行数（以KLOC计）；E——工作量（以PM计）；a、b——经验常数；i=115目前四十三页\总数一百四十一页\编于十四点表2-9a、b参数的取值软件类型ab组织型3.21.05半独立型3.01.12嵌入型2.81.20目前四十四页\总数一百四十一页\编于十四点（2）中间CoCoMo模型工作量调节因子EAF与软件的产品的取值属性、计算机属性、人员属性、项目属性等因素有关。这15个因素Fi（i=1~15）的值可按等级取值，即可分为很低、低、正常、高、很高、极高，共6级。正常情况下Fi=1。Boehm推荐的Fi值的范围是.70~1.66，F

i的值可根据实际情况按表2-10来选取。工作量E求出之后，就可以用公式（2-18）即D=cEd计算出开发时间D。目前四十五页\总数一百四十一页\编于十四点（3）详细CoCoMo模型详细CoCoMo模型的基本工作量（指EAF=1时的工作量）公式、开发时间公式与中间CoCoMo模型相同。所不同的是详细CoCoMo模型在计算EAF时针对每个影响因素，分层次（系统层、子系统层、模块层）并按软件生存周期分阶段给出工作量因素的分级表。详细CoCoMo模型可以更准确地估算软件项目的工作量。目前四十六页\总数一百四十一页\编于十四点表2-11子系统层软件可靠性工作量因素分级表

阶段可靠性级别需求分析和概要设计详细设计编码及单元测试集成及测试综合很低0.800.800.800.600.75低0.900.900.900.800.88正常1.001.001.001.001.00高1.101.101.101.301.15很高1.301.301.301.701.40目前四十七页\总数一百四十一页\编于十四点通信数图2-2-4N=3和N=5时的通信数目前四十八页\总数一百四十一页\编于十四点成功的标准：2.3软件质量度量失败的根本原因：

用户在用用户可很容易做完要做的事开发人员写出的东西达不到用户要求(人的问题、技术问题)目前四十九页\总数一百四十一页\编于十四点不贪污的官就是好官吗“运行正确”的程序就是高质量的程序吗？也许运行速度很低并且浪费内存；也许代码写得一塌糊涂

目前五十页\总数一百四十一页\编于十四点2.3.1软件质量的定义软件质量是软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，包括：1．软件产品满足用户要求的程度；2．软件拥有所期望的各种属性的组合程度；3．用户对软件产品的综合反映程度；4．软件在使用过程中满足用户需求的程度。目前五十一页\总数一百四十一页\编于十四点2.3.2软件质量的度量模型1976年，Boehm提出了定量度量软件质量的概念，他给出了软件质量的层次模型，并给出了60个软件质量度量公式；1978年，Walters和McCall提出了三层次软件质量度量模型；1985年，ISO提出了SQM（SoftwareQualityMetric，软件质量度量）工作报告等等。目前五十二页\总数一百四十一页\编于十四点1．McCall等人的软件质量度量模型McCall等人提出了由软件质量要素、评价准则、定量度量三个层次组成的三层次度量模型。其中:第一层是将对软件质量的度量归结为对直接影响软件质量的若干个软件质量要素的度量；第二层是用若干个可度量的评价准则来间接度量软件质量要素；第三层是对相应评价准则的直接度量。目前五十三页\总数一百四十一页\编于十四点图2-3-1软件质量三层次度量模型要素j评价准则1评价准则2评价准则L度量1度量2度量L……目前五十四页\总数一百四十一页\编于十四点2．软件质量要素当时McCall等人认为，软件质量由11个软件质量要素来衡量。这11个质量要素可划分为三类：面向运行特征的软件质量要素有正确性、可靠性、有效性、完整性和可用性；面向软件承受修改的质量要素有可维护性、灵活性、可测试性；面向转移的软件质量要素有可移植性、可重用性、可互操作性。这三类要素构成了软件质量的三个侧面，如图2-3-2所示。目前五十五页\总数一百四十一页\编于十四点图2-3-2软件质量要素的构成产品修正产品转移产品运行可维护性灵活性可测试性可移植性可重用性可互操作性正确性可靠性有效性完整性可用性目前五十六页\总数一百四十一页\编于十四点质量要素概念1）正确性（correctness）：指程序满足需求规格说明及用户目标的程度；2）可靠性（reliability）：指在给定的时间间隔内，程序成功运行的概率。可靠性是衡量软件质量的一个重要目标。3）有效性（efficiency）：指软件系统的时间和空间效率。这是一个应当努力追求的重要目标。4）完整性（integrity）：指对未授权人员访问程序或数据加以控制的程度；5）可用性（usability）：指学习使用软件（即操作软件、准备输入数据、解释输出结果等）的难易程度；目前五十七页\总数一百四十一页\编于十四点质量要素概念1）灵活性（flexibility）：指改变一个操作的顺序所需工作量的多少；2）可测试性（testability）：指测试软件以便使其具有预定功能所需工作量的多少；3）可维护性（maintainability）：指软件产品交付使用后，在实现改正潜伏的错误、改进性能等属性、适应环境变化等方面工作的难易程度。目前五十八页\总数一百四十一页\编于十四点1）可互操作性（interoperability）：指程序与其他系统相互交换并使用信息的能力。2）可重用性（reusability）：指软部件可以在多种场合使用的程度。3）可移植性（portability）：指软件从一个计算机系统或环境移植到另一个上去的难易程度。质量要素概念目前五十九页\总数一百四十一页\编于十四点2．软件质量要素软件质量要素不是独立的，一个要素可能与其他几个要素有关系，如表2-12所示，其中:正相关以“√”表示，负相关以“×”表示。对于具有负相关的质量要素，在开发时应根据具体情况加以取舍或进行折衷。例如，对于实时控制系统，必须确保系统的可靠性和有效性，而软件的可重用性、可移植性等质量要素就可以放宽要求。目前六十页\总数一百四十一页\编于十四点表2-12质量要素间的关系关系要素要素正确性可靠性有效性完整性可用性可维护性灵活性可测试性可移植性可重用性可互操作性正确性

可靠性√有效性完整性×

可用性√√×

√可维护性√√×

√灵活性√√×

×

√√可测试性√√×

√√√可移植性×

√√可重用性×

×

×

√√√√可互操作性×

×

√目前六十一页\总数一百四十一页\编于十四点3．软件质量要素的评价准则

软件质量要素一般很难直接测量。为了对11个要素进行度量，McCall等人通过确定影响软件质量要素的属性，定义了21个软件质量要素的评价准则。这些评价准则既能够比较完整、准确地描述软件质量要素，又比较容易测量。通过这组评价准则就可以间接测量软件质量要素，进而度量整个软件质量。目前六十二页\总数一百四十一页\编于十四点评价准则新概念1）可审查性（audit-ability）：检查软件需求、文档、过程、标准等是否一致的难易程度；2）准确性（accuracy）：计算和控制的精确程度；3）简明性（conciseness）：程序源代码的紧凑程度；4）通信通用性（communicationcommonality）：使用标准接口、协议和带宽的程度；5）数据通用性（datacommonality）：在程序中使用标准数据结构和类型的程度；6）容错性（error-tolerance）：在各种异常情况下软件能继续提供操作的能力；目前六十三页\总数一百四十一页\编于十四点评价准则新概念7）执行效率（executionefficiency）：软件运行效率；8）可扩充性（expandability）：结构、数据、过程等设计可以扩充的程度；9）通用性（generality）：程序潜在应用领域的多少；10）硬件独立性（hardwareindependence）：软件与其运行的硬件环境无关的程度；11）检测性（instrumentation）：程序监视自身运行并标识错误的程度；12）可操作性（operability）：操作该软件的难易程度；目前六十四页\总数一百四十一页\编于十四点评价准则新概念13）安全性（security）：控制或保护程序和数据不被破坏、非法访问等机制的能力；14）自文档化（self-documentation）：源代码提供自身说明文档的程度；15）简单性（simplicity）：程序易于理解的程度；16）软件独立性（softwareindependence）：软件与非标准编程语言特征、操作系统特征等软件环境约束无关的程度；17）易培训性（training）：软件对使用它的新用户的支持程度。目前六十五页\总数一百四十一页\编于十四点18）可追踪性（traceability）：是指根据软件需求对软件设计、程序进行正向追踪，或根据程序、软件设计对软件需求进行逆向追踪的能力。19）模块化（modularity）：把一个程序划分成若干个模块，每个模块完成一个子功能，将这些模块组装成一个整体，即可完成该程序指定的功能。20）一致性（consistency）：整个软件系统（包括程序、数据和文档）的各个模块应使用一致的概念、符号和术语；程序内部接口应保持一致；软件与环境的接口应保持一致；系统规格说明应与系统行为保持一致；用于形式化规格说明的公理系统应保持一致。21）完全性（completeness）：软件系统不丢失任何重要成分，完全实现所需的系统功能的程度。评价准则新概念目前六十六页\总数一百四十一页\编于十四点表2-13质量要素与评价准则的关系评价准则关系质量要素可追踪性完全性一致性容错性准确性简单性可操作性执行效率可审查性检测性安全性数据通用性可扩充性通用性硬件独立性简明性通信通用性自文档化软件独立性易培训性模块化正确性√√√可靠性√√√√有效性√√√完整性√√√可用性√√可维护性√√√√√√灵活性√√√√√√√可测试性√√√√√可移植性√√√√√可重用性√√√√√可互操作性√√√√目前六十七页\总数一百四十一页\编于十四点4．软件质量要素的度量第j种软件质量要素Fj（j=1,2,…,11）的计算公式为：Fj=∑CjkMk其中：Mk是第j种软件质量要素Fj对第k种评价准则的测量值。评价准则多数只能按主观想法定值。McCall将每个评价准则都划分为0~10级，并且Mk的值可以在0，0.1，0.2，…，1.0中取一个。加权系数Cjk满足∑Cjk=1，Cjk≥0。Cjk=0表示质量要素与第k种评价准则无关。目前六十八页\总数一百四十一页\编于十四点4．软件质量要素的度量例如，要度量某软件的F2（可靠性）假设C23=0.1，C24=0.3，C25=0.4，C26=0.2，其余的C2k=0，而M3=0.7、M4=0.6、M5=0.5，M6=0.8，则可靠性的度量值为：F2=C23M3+C24M4+C25M5+C26M6=0.1×0.7+0.3×0.6+0.4×0.5+0.2×0.8=0.61目前六十九页\总数一百四十一页\编于十四点ISO三层次软件质量度量模型。1985年，国际标准化组织也提出了三层次软件质量度量模型。其中：高层称为软件质量需求评价准则（SQRC），并由正确性、可容性、有效性、安全性、可用性、可维护性、灵活性、可互操作性等8个要素组成；中层称为软件质量设计评价准则（SQDC），并由可追踪性、完全性…、等共23个评价准则组成；低层称作软件质量度量评价准则（SQMC）。目前七十页\总数一百四十一页\编于十四点2.4软件复杂性度量通过软件的复杂性度量值可以估算出软件中故障的数量；也能估算出软件开发所需的工作量；定量度量的结果还可以用于比较不同设计方案的优劣。同时，软件的复杂性也能从某些方面影响软件的可维护性、可靠性等软件质量要素。因此，软件复杂性度量是软件度量的一个重要组成部分。目前七十一页\总数一百四十一页\编于十四点2.4.1软件复杂性的概念及度量原则

1．软件复杂性的概念K.Magel从6个方面来描述软件复杂性：1）理解程序的难度；2）维护程序的难度；3）向其他人解释程序的难度；4）按指定方法修改程序的难度；5）根据设计文件编写程序的工作量；6）执行程序时需要资源的多少。软件复杂性反映了软件的可理解性、模块化、简单性等属性。目前七十二页\总数一百四十一页\编于十四点2．软件复杂性度量的原则软件复杂性的度量，的一些基本原则：1）软件的复杂性与其规模的关系不是线性的；2）数据结构复杂的程序较复杂；3）控制结构复杂的程序较复杂；4）转向语句使用不当的程序较复杂；5）循环结构比选择结构复杂、选择结构比顺序结构复杂；6）语句、数据、子程序模块等出现的顺序对复杂性有影响；目前七十三页\总数一百四十一页\编于十四点2．软件复杂性度量的原则7）非局部变量较多的程序较复杂；8）参数按地址调用（Callbyreference）比按值调用（Callbyvalue）复杂；9）函数副作用比显式参数传递难理解；10）作用不同的变量同名时较难理解；11）模块、过程间联系密切的程序较复杂；12）程序嵌套层数越多越复杂。以上这些基本原则是指导我们进一步研究定量度量软件复杂性的基础。目前七十四页\总数一百四十一页\编于十四点2.4.2McCabe度量模型该方法是把程序流程图转化为程序图：即把程序看成是有一个入口结点和一个出口结点的有向图，图中每个结点对应一个语句、一个简单判断或一个顺序流程的代码块，原来程序流程图中的箭头变成连接各结点的有向弧（或称为边）。一般地，可以假设从程序图中的开始结点可以到达图中的任一结点，而从图中的任一结点都可以到达出口结点。程序图又称为程序控制结构图或程序流图。目前七十五页\总数一百四十一页\编于十四点2.4.2McCabe度量模型McCabe给出了程序控制结构图G的巡回秩数V（G）作为程序控制结构复杂性的度量，其度量模型为：V（G）=E–N+2其中：E——程序图G中边的总数；N——程序图中结点的总数。V（G）又称为图G的环形复杂度。可以证明，V（G）的值等于结构图中有界和无界的封闭区域的个数。目前七十六页\总数一百四十一页\编于十四点R1图2-4-1三种基本结构的程序图R1R2R1R2（a）顺序结构V（G）=E–N+2=1–2+2=1

（b）选择结构V（G）=E–N+2=4–4+2=2（c）while结构R1R2V（G）=E–N+2=3–3+2=2（d）until结构V（G）=E–N+2=3–3+2=2目前七十七页\总数一百四十一页\编于十四点2.4.2McCabe度量模型程序结构的复杂性度量值V（G）取决于程序控制流的复杂程度。当程序内的分支数和循环数增加时，V（G）值将随之增加，即程序的复杂性增大。McCabe研究大量程序后指出，V（G）可作为程序规模的定量指标，V（G）值越高的程序往往是越复杂、越容易出问题的程序。McCabe建议模块规模应满足：V（G）≤10目前七十八页\总数一百四十一页\编于十四点【例2.5】程序流程图如图2-4-2所示，试求出其巡回秩数V（G）解：（1）画出程序流程图对应的程序图。开始abchgfdei结束图2-4-3程序图abcfghdeiR1R2R3R41234567891011图2-4-2程序流程图目前七十九页\总数一百四十一页\编于十四点【例2.5】程序流程图如图2-4-2所示，试求出其巡回秩数V（G）（2）由程序图（或流图）可得：abcfghdeiR1R2R3R41234567891011（3）由程序图可以看出，其有界区域有R1、R2、R3共3个，还有1个无界区域R4，共4个封闭区域，所以：V（G）=E–N+2=11–9+2=4

V（G）=4目前八十页\总数一百四十一页\编于十四点2.4.3Halstead度量模型20世纪70年代初，Halstead给出了称为文本复杂性度量的模型。它是根据统计程序中的操作符和操作数的个数来度量程序的复杂程度。程序可以看成是由操作符和操作数组成的符号序列。操作符是指程序中出现的语法符号，如+、–、if-then-else、while等。操作数是操作对象，如程序中定义或使用的变量、常量、数组、指针等。令：N1为程序中操作符出现的总个数，N2为程序中操作数出现的总个数。则程序的语言符号长度N定义为：N=N1+N2。目前八十一页\总数一百四十一页\编于十四点2.4.3Halstead度量模型如果已经测得程序中不同操作符的个数n1和不同操作数的个数n2，则程序的长度N可用下式来估算：N≈n1log2n1+n2log2n2Halstead用下式来定义程序量（即程序在词汇上的复杂性）：V=Nlog2（n1+n2）Halstead还给出了预测错误数的公式如下：E=Nlog2（n1+n2）/3000目前八十二页\总数一百四十一页\编于十四点2.4.3Halstead度量模型可以对多个某种程序设计语言的程序进行统计分析，从而得出每千代码行（KLOC）或每个功能点（FP）所包含的操作符和操作数个数CL或CF，于是，可以将程序语言符号长度N折合成相应的代码行数或功能点数。目前八十三页\总数一百四十一页\编于十四点2.5软件可靠性度量

软件可靠性定义为在某个给定时间间隔内，程序按照规格说明成功运行的概率。目前八十四页\总数一百四十一页\编于十四点1．软件可靠性令：随机变量t表示发生故障的时刻，t∈[0，∞]；函数f（t）为随机变量t的概率密度函数，F（t）表示分布函数；P（0≤t≤t1）表示从初始时刻到t1时刻程序发生故障的概率。设：初始时刻程序运行正常，即F（0）=0。于是有：F（t）=∫f（x）dxf（t）=dF（t）dt0t目前八十五页\总数一百四十一页\编于十四点令：Pf（t1）表示从0到t1时刻程序发生故障的概率，有：Pf（t1）=P（0≤t≤t1）=F（t1）–F（0）=F（t1）如果在[0，t]区间程序成功运行的概率为Ps（t）、发生故障的概率为Pf（t），则有：Ps（t）+Pf（t）=1Ps（t）就是可靠性，一般标记为R（t）。由以上几个式子可导出：R（t）=1–Pf（t）=1–F（t）=1–∫f（x）dx上式说明，当软件残留的错误数一定时，程序运行的时间越长，发生故障的次数越多，软件的可靠性越小。0t目前八十六页\总数一百四十一页\编于十四点下面引入故障率函数Z（t），以比较一个程序在不同时期、或不同程序在同一时期的可靠性。设系统一直成功运行至时刻t，t∈[t1，t1+△t]，P（t1≤t≤t1+△t，t＞t1）是系统在[t1，t1+△t]时间间隔且t＞t1时发生故障的概率。故障率函数Z（t1）的值定义为：Z（t1）=limP（t1≤t≤t1+△t，t＞t1）/△t可以证明：Z（t）=·对前式的两端对时间t求导得：dF（t）/dt=–dR（t）/dt，代入上式，得：

=–Z（t）dt

1R（t）dF（t）d（t）dR（t）R（t）目前八十七页\总数一百四十一页\编于十四点对上式两端积分，利用初始条件R（0）=1，可得：R（t）=exp[–∫Z（x）dx]

上式即为可靠性和故障率的基本方程式。据此可以导出几个常用的故障模型：Z（t）=λ，其中λ是常数。将λ代入式前式，可得：R（t）=e–λt上式称为故障率为常数的可靠性模型。由于故障率是常数，可靠性将随着时间t的增加呈指数衰减。t0目前八十八页\总数一百四十一页\编于十四点Z（t）=kt，这里k为常数，t≥0。将kt代入前式可得：

R（t）=e–kt2/2

上式称为故障率是时间的线性函数时的可靠性模型。即当存在损耗和退化时，故障率将随着时间的增加而线性增加。该模型一般不适合于软件产品。需要指出，软件中的错误一般都是人为的设计错误，其中多数是逻辑错误。随着对软件的测试及修复，软件系统中的错误会越来越少。因此，实际软件系统的故障率函数曲线应如图2-5-1所示，即软件故障率不是常数、也不是线性函数，而是按指数规律下降。实际的统计结果也说明了这一点。目前八十九页\总数一百四十一页\编于十四点图2-5-1软件系统故障率Z（t）Ot目前九十页\总数一百四十一页\编于十四点2．软件的有效性及其度量软件的有效性函数A（t）定义为软件系统在时刻t按照规格说明成功运行的概率。可靠性与有效性之间的差别是，可靠性强调软件系统在0～t这段时间间隔内都有效，而有效性强调软件系统在时刻t这一时间点有效。A（200）=0.93表示假设有100个相同的系统同时启动运行，运行到200小时这一时刻，其中有93个处于正常运行状态，7个出现故障，等待修复。R（200）=0.93表示假设有100个相同的系统有93个无故障运行了200小时，有7个在此期间发生故障。目前九十一页\总数一百四十一页\编于十四点2．软件的有效性及其度量一般来说，对R（200）=0.93的要求比对A（200）=0.93的要求要严格得多。对于不可修复系统（即不允许程序停止运行的系统）或没有修复能力的情况：A（t）=R（t）对于可修复系统并能及时修复的情况：A（t）≥R（t）。目前九十二页\总数一百四十一页\编于十四点软件稳态有效性的两种度量方法1）软件系统投入运行后，在一段时间内，可统计软件系统的故障停机时间tdi和正常运行时间tuj，则软件系统的稳态有效性为：A（t）=Tu/（Tu+Td）其中：t=Tu+Td，Td=∑tdi，Tu=∑tuj目前九十三页\总数一百四十一页\编于十四点软件稳态有效性的两种度量方法2）软件系统在稳态运行时，可统计其平均故障间隔时间MTBF（meantimebetweenfailurs，即程序正常运行时间的平均值）和平均修复时间MTTR（meantimetorepair，即平均停机时间），则软件系统的稳态有效性为：A=MTBF/（MTBF+MTTR）采用上述方法，在开发阶段和投入运行后都可以定量地度量软件系统的有效性和可靠性。软件系统投入运行的一段时间内，可以用各种输入和操作来引发程序中残留的错误，经过多次修复后错误将逐渐减少，有效性和可靠性将不断提高。目前九十四页\总数一百四十一页\编于十四点2.5.2软件可靠性的估算软件可靠性估算模型大致分为宏观和微观模型两类。宏观模型是从程序中残留错误数的角度建立模型，并用统计方法确定模型参数。而微观模型则以程序的控制结构和语句分析为基础。下面仅介绍几个典型的宏观模型。1．残留错误总数的估算模型对残留错误总数的估算是可靠性估算的基础。典型的估算模型：错误植入模型；分别测试模型。目前九十五页\总数一百四十一页\编于十四点1）错误植入模型Mills首先提出了估算程序中残留错误总数的错误植入模型。即在进行测试之前，由专人（比如统计人员）在程序中随机地植入一些错误（称为带有标记的错误），测试人员测试之后，通过统计测试人员发现的原有错误和植入错误的比例来估算程序中原有错误总数。设：Nt—植入的错误数，n—测试发现原有的错误数，nt—发现植入的错误数，ET—原有的错误总数。则有：ET/Nt≈n/nt于是ET的估算模型为：ET=Nt·n/nt

目前九十六页\总数一百四十一页\编于十四点2）分别测试模型1973年，Hyman对错误植入模型做了改进，即用甲、乙两个程序测试员同时对一个程序的两个副本进行独立测试。设：ET——程序中原有的残留错误总数，E1——甲在[0，τ]时间内发现的错误数，E2——乙在[0，τ]时间内发现的错误数，E0——两人在[0，τ]时间内发现的相同的错误的个数，则有：ET=E1·E2/E0

Hyman提出的分别测试模型无论在技术上还是在经济上都比错误植入模型优越。目前九十七页\总数一百四十一页\编于十四点2．软件平均故障间隔时间的估算软件的平均故障间隔时间MTBF是可靠性度量的一个重要参数，往往作为一个重要的质量指标由用户提出来。下面介绍MTBF的估算方法。1）软件故障率为常数当软件故障率λ为常数时，假设程序运行H小时，共发生r次故障，则λ的估算值为：λ≈r/H于是有：MTBF=1/λ=H/r目前九十八页\总数一百四十一页\编于十四点2）软件故障率与程序残留错误数成正比设：IT—程序代码长度；ET—测试之前程序中残留错误总数；Ec（τ）—[0，τ]区间内改正的错误数；Er（τ）—在τ时刻程序中剩余的错误数；其中τ为调试和排错时间。于是，剩余的错误数为：Er（τ）=ET–Ec（τ）目前九十九页\总数一百四十一页\编于十四点2）软件故障率与程序残留错误数成正比Er（τ）=ET–Ec（τ）用IT去除上式的两边，有：Er（τ）/IT=ET/IT–Ec（τ）/IT令：εr（τ）=Er（τ）/IT，εT=ET/IT，εc（τ）=Ec（τ）/IT，于是有：εr（τ）=εT–εc（τ）目前一百页\总数一百四十一页\编于十四点2）软件故障率与程序残留错误数成正比由于软件故障率λ=λ（τ）与程序残留错误数成正比，所以有：λ=kεr（τ）=k（εT–εc（τ））其中的比例因子k可通过实验测试和统计的方法来估算。设进行n次软件排错实验，时间区间为[0，τj]，到τj时刻为止，共排除了Ec（τj）个错误，而在时间区间[0，τj]内，程序运行了Hj小时，出现了rj个错误，j=1，2，…，n。此时k的估计值为：

k

=∑rj/∑Hj[εT–εc（τj）]nj=1nj=1目前一百零一页\总数一百四十一页\编于十四点2）软件故障率与程序残留错误数成正比k

=∑rj/∑Hj[εT–εc（τj）]当n=1时，

k=r/H[εT–εc（τ）]当n=2时，k=（r1+r2）/{H1[εT–εc（τ1）]++H2[εT–εc（τ2）]}k的值估算出来之后，即可利用公式估算MTBF，它是τ的函数。目前一百零二页\总数一百四十一页\编于十四点2）软件故障率与程序残留错误数成正比对于确定的τ值，λ=kεr（τ）为常数，于是，经过[0，τ]区间的排错后，软件可靠性估算为：R（t）=exp[–kεr（τ）t]=exp（–t/MTBF）上式中时间参数τ以月计，表示对程序调试和维护的时间，t∈[0，τ]，以小时计，表示程序运行的时间。上式可理解为经过τ个月的调试后所达到的软件可靠性。目前一百零三页\总数一百四十一页\编于十四点2.6软件开发过程的管理为达到软件工程的目标，必须对软件开发项目的工作范围、所需的工作量和成本、必需的人力和软硬件资源、可能遇到风险、进度的安排、待实现的任务、经历的里程碑等进行管理。软件开发过程的管理应在所有技术工作开始之前启动，直至软件工程过程的结束。目前一百零四页\总数一百四十一页\编于十四点软件开发项目管理过程主要包括以下几个方面：1．启动一个软件项目

2．成本估算3．风险分析4．进度安排5．追踪和控制目前一百零五页\总数一百四十一页\编于十四点风险分析风险的特点：①不确定性，某项风险可能发生也可能不发生；②损失，一旦某项风险变成了现实，就必然会给项目带来不良的影响和损失，甚至灾难性后果。（1）按照风险的影响范围分类

①项目风险

②技术风险

③商业风险2.风险分类：

（2）按照风险的可预测性分类

①已知风险

②可预测的风险

③不可预测的风险目前一百零六页\总数一百四十一页\编于十四点风险分析3.风险分析的三个主要活动：

风险标识；风险估算；处理风险的策略。

Ifyoudon’tactivelyattacktherisks,theywillactivelyattackyou.——TomGilb(1988)目前一百零七页\总数一百四十一页\编于十四点1．风险标识Boehm建议使用各类风险检测表来标识风险。在风险检测表中列出所有可能的与每一个风险因素有关的问题。包括产品规模风险检测表、商业风险检测表、客户风险检测表、过程风险检测表、开发环境风险检测表、技术风险检测表、人员风险检测表等等。例如，“人员风险检测表”可如表2-14所示。

在表2-14中，可以根据实际情况选用0、1、2、3、4、5来回答每一个问题，某个问题取值越大表示该项风险也越大。人员风险检测表反映了人的因素可能对软件项目的影响。目前一百零八页\总数一百四十一页\编于十四点表2-14人员风险检测表序号问题回答（0、1、2、3、4、5}1开发人员的水平如何？22开发人员在技术上是否配套？13是否有足够的人员可用？04开发人员是否能自始至终参加软件项目的工作？25开发人员是否能把全部精力投入到软件开发工作中？26开发人员对自己的工作是否有正确的期望？17开发人员是否已接受了必要的培训？08开发人员的流动是否还能保证工作的连续性？3目前一百零九页\总数一百四十一页\编于十四点2．风险估算——风险预测风险预测(也称为风险估算)试图从两个方面来评估每个风险：风险变成现实的可能性或概率，以及当风险变成现实时所造成的后果。（1）评估风险后果美国空军建议从性能、支持、成本和进度等四个方面评估风险的后果，他们把上述四个方面称为四个风险因素。下面给出这四个风险因素的定义。·性能风险·成本风险·支持风险·进度风险目前一百一十页\总数一百四十一页\编于十四点2．风险估算根据风险发生时对上述四个风险因素影响的严重程度，可以把风险后果划分成四个等级：可忽略的、轻微的、严重的和灾难性的。（2）建立风险表目前一百一十一页\总数一百四十一页\编于十四点评估风险后果目前一百一十二页\总数一百四十一页\编于十四点3．处理风险的策略

对于绝大多数软件项目来说，上述的4个风险因素(性能、成本、支持和进度)都有一个临界值，超过临界值就会导致项目被迫终止。也就是说，如果性能下降、成本超支、支持困难或进度延迟(或这4种因素的组合)超过了预先定义的限度，则因风险过大项目将被迫终止。如果风险还没有严重到迫使项目终止的程度，则项目组应该制定一个处理风险的策略。一个有效的策略应该包括下述三方面的内容：风险避免(或缓解)；风险监控；风险管理和意外事件计划。目前一百一十三页\总数一百四十一页\编于十四点

（1）风险缓解如果软件项目组采用主动的策略来处理风险，则避免风险总是最好的策略。这可以通过建立风险缓解计划来达到。（2）风险监控随着项目的进展，风险监控活动也就开始了。项目管理者监控某些能指出风险概率正在变高还是变低的因素。（3）风险管理和意外事件计划风险管理和意外事件计划假设缓解风险的努力失败了，风险变成了现实。3．处理风险的策略目前一百一十四页\总数一百四十一页\编于十四点

项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为了做到这一点，管理者必须制定一个足够详细的进度表，以便监督项目进度，并控制整个项目。软件项目的进度安排是一项活动，它通过把工作量分配给特定的软件工程任务，并规定完成各项任务的起、止日期，从而将估算的工作量分布于计划好的项目持续期内。进度安排目前一百一十五页\总数一百四十一页\编于十四点基本原则下述的基本原则能够指导软件项目的进度安排。1.划分2.相互依赖性3.时间分配4.工作量确认5.定义责任6.定义结果7.定义里程碑进度安排目前一百一十六页\总数一百四十一页\编于十四点1、GanttChart（甘特图）tw12345678ABCD当前进度优点：简单，能动态地反映开发进展。缺点：难以反映多个任务间的逻辑关系。进度安排目前一百一十七页\总数一百四十一页\编于十四点012345678

codingA

testingA

debuggingABcoding

understandingC

modifyingC

testingB

testingC

debuggingB

debuggingC

testingABC012356789

codingA

testingA

debuggingA

understandingC

modifyingC

testingB

testingC

debuggingB

debuggingC

testingABC4

debuggingABcoding2、PERT(ProgramEvaluation&ReviewTechnique)和CPM(CriticalPathMethod)例：开发三个模块A、B、C。

A为公用模块，B、C的测试须等A的调试完成后进行。A的编码需6天，测试8天，调试6天。B的编码需7天，测试8天，调试6天。C利用已有的模块，须先理解原模块8天，再修改8天，测试9天，调试7天。最后三模块集成测试需5天完成。目前一百一十八页\总数一百四十一页\编于十四点持续时间LastingTime机动时间SlackTime编号EarliestStartTimeLatestStartTime012345678941363029222014126006142082028293641(0)(0)(15)(4)(2)(4)(0)(2)(0)(2)(0)(0)686678886975(1)标出LastingTime(2)标出EST:=从起点始，所有进入事件的EST+LT中最大的(3)标出LST:=从终点(EST=LST)始，所有离开事件的LSTLT中最小的(4)标出ST:=终点LST起点EST

LT(5)标出CriticalPath:即EST=LST的所有事件组成的路径目前一百一十九页\总数一百四十一页\编于十四点软件质量保证1）在需求分析阶段提出对软件质量的需求，并将其自顶向下逐步分解为可以度量和控制的质量要素，为软件开发、维护各阶段软件质量的定性分析和定量度量打下基础；2）研究并选用软件开发方法和工具；3）对软件生存周期各阶段进行正式的技术评审（FTR）；4）制定并实施软件测试策略和测试计划；5）及时生成软件文档并进行其版本控制；6）保证软件开发过程与选用的软件开发标准相一致；7）建立软件质量要素的度量机制；8）记录SQA的各项活动，并生成各种SQA报告。1．软件质量保证（SQA，SoftwareQualityAssurance）活动的内容目前一百二十页\总数一百四十一页\编于十四点2.技术复审的必要性正式技术复审的明显优点是，能够较早地发现错误，防止错误被传播到软件过程的后续阶段。正式技术复审实际上是一类复审方法，包括走查(Walkthrough)和审查(Inspection)等具体方法。走查的步骤比审查少，而且没有审查那样正规。软件质量保证目前一百二十一页\总数一百四十一页\编于十四点(1)参与者驱动法参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须对每个质疑做出回答，要么承认确实有错误，要么对质疑做出解释。走查(2)文档驱动法文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更彻底，往往能检测出更多错误。经验表明，采用文档驱动法时许多错误是由文档讲解者自己发现的。目前一百二十二页\总数一百四十一页\编于十四点

审查的范围要比走查广泛得多，它的步骤也比较多。一般来说，审查有5个基本步骤。·综述·准备·审查·返工·跟踪审查目前一百二十三页\总数一百四十一页\编于十四点

正