1、ZLL,BeiHua,软件工程,主编 曹哲 高诚中国水利水电出版社,ZLL,BeiHua,经理管什么？,计 划,预算,组 织,标 准,什么是软件项目管理？,ZLL,BeiHua,第2章 软件项目管理,软件项目管理必须从项目的开头介入，并贯穿于整个软件生存周期的全过程。软件项目管理的范围主要集中于3个P上，即： People（人员）、Problem（问题）和Process（过程）。 软件项目管理的主要任务是：根据选定的软件开发过程框架（即软件开发模型）和对其估算的结果制定软件项目实施计划；再根据计划对人员进行组织、分工；按照计划的进度，以及成本管理、风险管理、质量管理的要求，控制并管理软件开发和
2、维护的活动，最终以最小的代价完成软件项目规定的全部任务。,ZLL,BeiHua,第2章 软件项目管理,软件项目的成本管理、软件质量管理和软件配置管理有一定的特殊性和独立性，可单独立项。任务分别是：,ZLL,BeiHua,第2章 软件项目管理,2.1 软件度量2.2 软件项目估算2.3 软件质量度量 2.4 软件复杂性度量2.5 软件开发过程的管理,ZLL,BeiHua,软件度量是软件产品、软件开发过程或自愿简单属性的定量描述。如程序规模、操作符个数、程序中错误的个数等。面向规模的度量 面向功能的度量,. 软件度量的基本概念,ZLL,BeiHua,1）测量（measure）：对产品或过程的某个属
3、性的范围、数量、维度、容量或大小提供一个定量的指示。 2）度量（metric）：对系统、部件或过程的某一特性所具有的程度进行的量化测量。如软件质量度量等。 3）估算（estimation）：对软件产品、过程、资源等使用历史资料或经验公式等进行预测。如工作量、成本、完成期限等。估算一般用于立项、签订合同、制定工作计划等。4）指标（guideline） 4）指标是一个度量或度量的组合，它可对软件产品、过程或资源提供更深入的理解。,.软件的度量,ZLL,BeiHua,2软件项目管理的对象及其属性对象,ZLL,BeiHua,内部属性是指对象本身的属性，如软件产品的代码长度、模块化的程度、复杂性等。对象
4、的外部属性体现了对象与环境的关系，如软件的可靠性、可维护性、可移植性、成本、人员的生产率等。对象的部分属性如表2-1所示。,2软件项目管理的对象及其属性对象的属性,ZLL,BeiHua,表2-1 软件工程的产品、过程、资源的属性,ZLL,BeiHua,直接度量 对不依赖于其他属性的简单属性的测量。如软件的模块数、程序的代码行数、操作符的个数，工作量、成本等。,度量 分类,间接度量 即对涉及若干个其他属性的软件要素、准则或属性的度量。如软件的功能性、复杂性、可靠性、可维护性等等。.,3软件度量的分类,ZLL,BeiHua,图2-1-1 两侧面间关系,面向规模的度量,面向功能的度量,面向人的度量,
5、生产率度量,质量度量,技术度量,ZLL,BeiHua,2.1.2 面向规模的度量,面向规模的度量是以软件的代码行（LOC，Line of Code）数为基础的直接度量。,L表示软件的代码行数，单位为KLOC（千行代码）或LOC；E表示开发软件所需工作量，单位为人月（PM）或人年（PY）；S表示软件成本，单位为美元或元；N表示错误个数；Pd表示软件文档页数；M表示开发所用的人数。,ZLL,BeiHua,1软件开发的生产率P： P = L / E 2开发每行代码的平均成本C： C = S / L 3代码出错率EQR： EQR = N / L 4软件的文档率D： D = Pd / L,2.1.2 面
6、向规模的度量,ZLL,BeiHua,优点：简单、直接。 缺点：代码行数的估算依赖于程序设计语言的功能和表 达能力。对设计精巧的软件项目产生不利影响。在开发初期估算代码行十分困难。只适用于过程式程序设计语言。,2.1.2 面向规模的度量,ZLL,BeiHua,【例2.1】 已知有一个国外典型的软件项目的记录，开发人员M=6人，其代码行数=20.2KLOC，工作量E=43PM，成本S=314000美元，错误数N=64，文档页数Pd=1050页。试计算开发该软件项目的生产率P、平均成本C、代码出错率EQR和文档率D。解：根据给出的已知数据，可得：P = L / E =20.2 KLOC /43 PM
7、 = 0.47 KLOC / PM= 470 LOC / PMC = S / L = 314000美元 / 20.2 KLOC = 15.54 美元 / LOCEQR = N / L = 64个 / 20.2KLOC = 3.17 个 / KLOCD = Pd / L = 1050 页 / 20.2 KLOC = 51.98 页 / KLOC,ZLL,BeiHua,2.1.3 面向功能的度量,1简单功能点度量1979年，Albrecht首先提出了功能点度量方法。这是一种面向功能的间接度量方法，即从软件定义的基本功能出发，来估算软件系统的规模。因此，该方法可以在软件开发项目的初期，在软件定义过程
8、中即可预测待开发软件的规模。,ZLL,BeiHua,1简单功能点度量,功能点FP的度量公式如下： FP = CTTCF = CT 0.65 + 0.01F i （2-5） 其中：CT基本功能点。CT值按表2-2来计算，它的值为5个参数加权值的总和。,14,i=1,ZLL,BeiHua,表2-2 简单功能点度量的基本功能点的计算,ZLL,BeiHua,表2-2中的5个参数的含义,1）用户输入数：用户为软件系统提供的输入参数的个数（不包括查询）； 2）用户输出数：软件为用户提供的输出参数（报告、屏幕帧、错误信息等）的个数； 3）用户查询数：一次联机输入导致软件以联机输出方式实时产生一个响应的个数；
9、 4）文件数： 逻辑主文件的个数； 5）外部接口数：机器可读的接口（如磁盘或磁带上的数据文件等）的个数。,ZLL,BeiHua,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。,ZLL,BeiHua,表2-3 F i 取值表,ZLL,BeiHua,2功能点度量,简单功能点度量方法没有直接考虑软件本身的算法的复杂
10、性问题。所以它仅适用于度量算法简单的事务处理等系统。 1986年Jones对简单功能点度量进行了推广，在计算软件系统的基本功能点CT时，引入了算法复杂性因素，即使用表2-4计算CT 。我们称这种推广的度量方法为功能点度量。 这两种方法对一般的事务处理系统等算法简单的软件系统计算出来的FP值基本相同，但对于较复杂的软件系统，功能点度量方法比简单功能点度量方法计算出来的FP值要高20%35%。,ZLL,BeiHua,表2-4 推广的功能点度量的基本功能点的计算,ZLL,BeiHua,用功能点计算软件项目的有关参考量：,1）生产率P（平均每人月开发的功能点数，以功能点 / PM为单位）：P = FP
11、 / E （2-6） 2）平均成本C（以美元/功能点或元/功能点为单位）：C = S / FP （2-7）,ZLL,BeiHua,用功能点计算软件项目的有关参考量：,3）代码出错率EQR（即每功能点的平均错误数，以个/功能点为单位）为：EQR = N / FP （2-8）4）软件的文档率D（即平均每功能点的文档页数，以页/功能点为单位）为：D = Pd / FP （2-9）,ZLL,BeiHua,3功能点度量方法的优缺点,优点：可用于软件项目开发的初期阶段的项目估算。因为在可行性研究和需求分析阶段已能基本确定输入、输出等各个参考量；与程序设计语言无关。适合于过程或非过程式语言。 缺点：某些参考
12、量的收集有一定困难；度量值的主观因素较多，如Fi取值；功能点FP本身没有直观的物理意义。,ZLL,BeiHua,4软件的代码行与功能点的关系,软件的功能点数和选用的程序设计语言无关，但对于同一个软件（功能点数已定），如用不同的程序设计语言来实现，所得到的软件的代码行数可能会有较大差别。Albrecht等人通过多个软件统计出了用不同程序设计语言实现每个功能点所需代码行数，即计算出各语言的LOC/FP的平均值，如表2-5所示。,ZLL,BeiHua,表2-5 部分程序设计语言LOC/FP平均值的比较,ZLL,BeiHua,2.2 软件项目估算,常用的软件项目的估算方法主要有以下4种 1自顶向下的估
13、算方法 2自底向上的估算方法 3差别估算法 4根据经验估算公式,2.2.1 软件项目的估算方法,ZLL,BeiHua,基本思想：首先根据已完成项目的总成本或总工作量来推算待开发软件的总成本或总工作量，然后再按比例将其分配到各开发任务中去。即从整体到局部。 优点：估算工作量小、速度快。 缺点：对项目中的特殊困难估计不足，有可能产生遗漏，估算出的值盲目性较大。,1自顶向下的估算方法,ZLL,BeiHua,2自底向上的估算方法,基本思想是：把待开发软件细分，直到每一个子任务或阶段都已经明确所需要的开发工作量或成本，然后再把它们累加起来，得到待开发软件的总工作量或总成本。 优点：计算各个部分的准确性较
14、高。 缺点：缺少各个子任务之间相互联系的工作量和系统工作量（如项目管理、配置管理、质量管理），估算值往往偏低，必须用其他方法进行校正。,ZLL,BeiHua,3差别估算法,基本思想：把待开发的软件项目与过去完成的软件项目进行比较，从各子任务中区分出类似的和不同的部分。类似的部分按已知的实际量计算，不同的部分则采用某种方法进行估算。差别估算法综合了以上两种方法的优点。 优点：估算的准确程度高。 缺点：不容易划分相似的界限。,ZLL,BeiHua,4根据经验估算公式,通过众多实际软件项目的经验，总结出一些有价值的软件成本和工作量估算的经验模型。这些模型对于软件项目管理具有一定的指导意义和验证效果。
15、,ZLL,BeiHua,估算方法举例,【例2.2】Boehm给出了“软件库存情况更新”项目采用自顶向下估算方法的一个参考例子，由过去已完成的项目的工作量，估算出该项目的总工作量为53。然后将其按比例分配到各个阶段，如表2-6所示。从中可以看出软件开发各阶段工作量的分配情况。,ZLL,BeiHua,表2-6 软件项目的自顶向下估算,ZLL,BeiHua,2.2.2 代码行和功能点的估算,采用2.2.1中介绍的估算方法可以估算出代码行或功能点的乐观值a、一般值m和悲观值b，并用如下的加权平均公式计算LOC或FP的期望值（expectation）：X =（ a +4 m +b）/ 6 （2-10）软
16、件的LOC或FP的期望值估算出来后，就可以根据已有的标准生产率对成本和工作量等进行估算了。,ZLL,BeiHua,【例2.3】对CAD软件项目进行估算,解：这里采用自底向上的估算方法。即首先，将CAD项目按功能分解为7个子项目，并估算出每个子项目LOC的乐观值a、一般值m和悲观值b，由此可估算出每个子项目的代码行的期望值X。在根据已知的开发类似子项目的生产率P和平均成本C即可估算出每一个子项目的成本和工作量，最后将7个子项目的成本和工作量分别累加，即可估算出软件项目的总成本S和总工作量E。估算的各种值如表2-7所示。,ZLL,BeiHua,表2-7 采用加权平均、自底向上方法估算代码行、成本和
17、工作量,ZLL,BeiHua,估算的组织实施,为了使估算更准确，可以组织几个专家采用无记名的方式分别填写表2-7，然后组织者计算出这几个表格的平均值；这一过程可反复几次，直到获得一个得到多数专家共识的软件规模。 另外，还可以将每个子项目再按生存周期划分，估算其各阶段的工作量，再累加求出每个子项目的工作量和整个项目的工作量。可将用几种方法估算的结果进行比较来验证估算的准确性。,ZLL,BeiHua,2.2.3 软件项目的经验估算模型,1IBM模型1977年，IBM公司对60个软件项目的数据利用最小二乘法拟合，得到的经验估算公式：E = 5.2 L0.91 （2-11）D=4.1L0.36 = 2
18、.136 E0. 3956 （2-12）S = 0.54 E0.6 （2-13）DOC = 49 L1.01 （2-14） 其中：E为工作量（PM）；L为源代码行数（ KLOC ）；D为项目持续的时间，以月为单位；S为人员需要量（人）；DOC为文档数量（页）。,ZLL,BeiHua,2Putnam模型,1978年，Putnam提出了大型软件项目的动态多变量估算模型。 该模型以工作量在30人年以上的大型软件项目的实测数据为依据，推导出了工作量分布曲线，如图2-2-1所示。 图中的工作量分布曲线的形状与著名的Rayleigh-Norden曲线相似。,ZLL,BeiHua,图2-2-1 软件项目的工
19、作量分布曲线,系统定义,功能设计 规格说明,设计编码,测试和确认,维护,管理,系统定义、需求分析,开 发,运行维护,0,开发占总工作量的40%,维护占总工作量的60%,总工作量,td,时间t（年）,工作量 （人年）,ZLL,BeiHua,2Putnam模型,Putnam估算模型如下：L = Ck E1/3 td 4/3,Ck为技术状态常数，与开发环境有关，如下： 2000 较差，没有方法学的支持，缺乏文档 和评审，采用批处理方式； Ck = 8000 一般，有方法学的支持，有适当的文档和评审，采用交互处理方式；11000 较好，有集成化的CASE工具和环境。,E = L3 / (Ck3 td4
20、),ZLL,BeiHua,R-N分布,线性分布,0 1 2 3 4 t（年）,td,人年数年,图2-2-2 概率密度,ZLL,BeiHua,图2-2-2 人力资源的分配,ZLL,BeiHua,Putnam模型的优缺点,优点：揭示了软件项目的源程序代码长度、 软件开发时间和工作量三者之间的关系，在理论上有重要意义。 缺点：准确程度不高。 没有反映软件产品、项目、参加人员、软硬件资源等属性。,ZLL,BeiHua,3CoCoMo模型（构造性成本模型）,CoCoMo模型按其详细程度分三个层次： 基本CoCoMo模型；中间CoCoMo模型；详细CoCoMo模型。,2.2.3 软件项目的经验估算模型,Z
21、LL,BeiHua,（1）基本CoCoMo模型,其工作量和开发时间的估算公式如下：E = a Lb D = c Ed 其中：L 软件代码行的估算值（以KLOC计）；E 工作量（以PM计）；D开发时间（以月计）；a、b、c、d经验常数。,ZLL,BeiHua,表2-8 a、b、c、d参数值的选取,ZLL,BeiHua,（2）中间CoCoMo模型,中间CoCoMo模型在估算工作量时，在基本CoCoMo模型的基础上再乘以由15个因素组成的工作量调节因子EAF，于是有：E = a Lb EAF = a Lb F i 其中：L 软件的代码行数（以KLOC计）；E 工作量（以PM计）；a、b 经验常数；,
22、i=1,15,ZLL,BeiHua,表2-9 a、b参数的取值,ZLL,BeiHua,（2）中间CoCoMo模型,工作量调节因子EAF与软件的产品的取值属性、计算机属性、人员属性、项目属性等因素有关。这15个因素Fi（i=115）的值可按等级取值，即可分为很低、低、正常、高、很高、极高，共6级。正常情况下Fi=1。Boehm推荐的Fi值的范围是.701.66，F i的值可根据实际情况按表2-10来选取。 工作量E求出之后，就可以用公式（2-18）即 D = c Ed计算出开发时间D。,ZLL,BeiHua,（3）详细CoCoMo模型,详细CoCoMo模型的基本工作量（指EAF=1时的工作量）公
23、式、开发时间公式与中间CoCoMo模型相同。 所不同的是详细CoCoMo模型在计算EAF时针对每个影响因素，分层次（系统层、子系统层、模块层）并按软件生存周期分阶段给出工作量因素的分级表。 详细CoCoMo模型可以更准确地估算软件项目的工作量。,ZLL,BeiHua,表2-11 子系统层软件可靠性工作量因素分级表,ZLL,BeiHua,通信工作量,由N个程序员组成的程序员小组的通信数量：C（N）=N（N-1）/2 设：每两个人之间通信的平均工作量为 则：N人的程序员小组增加的通信工作量为：EC = C（N）= N（N-1）/ 2 （2-20） 则该小组的总工作量ET为：ET = E + EC
24、（2-21）,ZLL,BeiHua,通信工作量,如图，由3人组成的程序员小组的通信数量：C（3）=3（3-1）/2=3 而由5人组成的程序员小组的通信数量：C（5） = 5（5-1）/2 = 10。 当程序员小组的人数较多时，通信工作量EC N2 /2与人数的平方成正比，从而使程序员小组的生产率随着人数的增加而迅速下降。 由此可见，当在开发的后期发现不能按时交货时，临时盲目增加程序员将会更加推迟交货的日期。,ZLL,BeiHua,通信数,图2-2-4 N=3 和N=5 时的通信数,ZLL,BeiHua,4COCOMO模型简介,COCOMO提供了3个层次的软件开发工作量-进度估算模型，其估算的详
25、细程度逐步增加。 应用组装模型 该层次的模型可用于“应用组装”类型的软件项目的开发工作量-进度的估算；也可用于“应用程序生成器”、“系统集成”、“基础结构”等类型的软件项目的最早阶段或螺旋周期的原型开发阶段，以便解决像软件/系统交互、用户界面、性能和技术等的风险问题，该模型也适用于后期阶段的原型开发。这类软件项目或原型的开发可充分利用现成的构件。 早期设计模型 该模型适用于“应用程序生成器”、“系统集成”、“基础结构”等类型的软件项目的早期设计阶段，以便确定软件或系统的体系结构或增量开发策略和操作概念、制定生命周期计划等。 后体系结构模型 早期设计阶段结束，即已开发了软件生命周期体系结构，确认
26、了系统任务、风险、操作概念、生命周期计划，建立了产品的框架后，即可采用该模型对软件产品的实际开发与维护进行有效的估算。,ZLL,BeiHua,COCOMO模型系列的估算公式,后体系结构模型公式软件开发工作量代码行的非线性函数： E = a Lb Fi （2-22） b = c + 0.01 （2-23） 在式2-22中，L为软件的代码行数；E为工作量（以PM计）；a为工作量系数；b为工作量指数；工作量调节因子Fi（i=117）可分为很低、低、正常、高、很高、极高，共6级。正常情况下Fi = 1。Fi的值可以根据实际情况按表2-12来选取。,ZLL,BeiHua,工作量调节因子Fi的取值,ZLL
27、,BeiHua,后体系结构模型比例因子Wj的取值,ZLL,BeiHua,早期设计模型公式,该模型也是把软件开发工作量表示成代码行的非线性函数： E = a Lb Fi （2-24） b = c + 0.01 （2-25） 式2-24与式2-22基本相同，所不同的是其工作量调节因子Fi（i=17）只有7个，是将后体系结构的17个调节因子分类组合而成。Fi的值可以根据实际情况按表2-14来选取。由表2-14可见，由于是多个调节因子组合成一个调节因子，因此，其等级分为极低、很低、低、正常、高、很高、极高，共7级。该阶段估算的细致程度与所获得的数据的细致程度相一致，与后体系结构模型相比较，是较粗粒度的
28、估算。,ZLL,BeiHua,早期设计工作量调节因子Fi的取值,ZLL,BeiHua,COCOMO进度估算模型,COCOMO提供了用于早期设计和后体系结构阶段的简单的进度估算公式。 D = （ d E标称f ） （2-26） f =（ e + 0.2 （b c ） （2-27） 其中，D为开发时间（即进度），以月（Mo）为单位，以瀑布模型为例，指的是从确认一个产品的需求直到验证产品已经满足需求为止的整个开发时间；d为进度系数；E标称为不考虑SCED工作量调节因子时所估算的工作量，称为标称工作量（以PM计）；g为要求的进度压缩或扩展的百分数；f为进度指数；e为进度基本指数；b为工作量指数；c为工
29、作量基本指数。,ZLL,BeiHua,【例2.5】,设有一个软件开发项目的体系结构和需求已经确认，项目规模（包括新开发的代码行和复用改编折算的代码行）为100KLOC，试估算该项目当要求进度压缩为标称进度的75%（即g = 75）时的开发时间和开发成本。假设估算时所有的工作量调节因子Fi和比例因子Wj都取正常值、承担该项目的开发组织的平均工资为W = 6000元/PM。 解：由于该项目的体系结构已经确立，所以应采用COCOMO的后体系结构模型来估算工作量： b = c + 0.01 = 0.91+0.01（3.72 + 3.04 + 4.24 + 3.29 + 4.68 ） 1.01 E标称
30、= a Lb Fi = 2.94 100 1.01 1.00 308 PM 该项目的进度（即开发时间，单位以月（Mo）计）为： f = e + 0.2 （b c ）= 0.28+0.2 （1.01 0.91 ）= 0.3 D = （ d E标称f ） = 3.67 308 0.3 75/100 15.4 Mo 进度压缩后的实际估算工作量为： E = a Lb Fi = 2.94 100 1.01 1.00 1.43 440 PM 软件开发成本为： S = E W = 440 6000 = 2640000元,ZLL,BeiHua,成功的标准：,2.3 软件质量度量,失败的根本原因：,用户在用 用
31、户可很容易做完要做的事,开发人员写出的东西达不到用户要求 (人的问题、技术问题),ZLL,BeiHua,2.3 软件质量度量,软件质量是软件的生命。它作为软件工程的一部分，贯穿于整个软件生存周期之中。 生产高质量的软件产品是软件工程的首要目标。 由于软件是逻辑产品，软件质量很难直接度量。因此，应当给出软件质量的科学的、实用的定义，并通过一定的度量模型进行度量，以便在整个软件生存周期中对其进行评价和控制。,ZLL,BeiHua,2.3.1 软件质量的定义,1983年，ANSI/IEEE std729标准给出了软件质量的定义如下：软件质量是软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，
32、包括：1软件产品满足用户要求的程度；2软件拥有所期望的各种属性的组合程度；3用户对软件产品的综合反映程度；4软件在使用过程中满足用户需求的程度。,ZLL,BeiHua,2.3.2 软件质量的度量模型,软件质量与软件的内部特性及其组合有关。要度量软件质量，就应根据这些内部特性（即软件属性）建立起软件度量模型，进而构建软件质量度量体系。 1976年，Boehm提出了定量度量软件质量的概念，他给出了软件质量的层次模型，并给出了60个软件质量度量公式； 1978年，Walters和McCall提出了三层次软件质量度量模型； 1985年，ISO提出了SQM（Software Quality Metric
33、，软件质量度量）工作报告等等。,ZLL,BeiHua,1McCall等人的软件质量度量模型,McCall等人提出了由软件质量要素、评价准则、定量度量三个层次组成的三层次度量模型。 其中: 第一层是将对软件质量的度量归结为对直接影响软件质量的若干个软件质量要素的度量； 第二层是用若干个可度量的评价准则来间接度量软件质量要素； 第三层是对相应评价准则的直接度量。,ZLL,BeiHua,图2-3-1 软件质量三层次度量模型,要素j,评价 准则1,评价 准则2,评价 准则L,度量1,度量2,度量L,ZLL,BeiHua,2软件质量要素,软件质量要素（factor）是指直接影响软件质量的软件质量特性。
34、随着对软件质量的认识的逐步提高，软件质量要素也可能有所变化。 当时McCall等人认为，软件质量由11个软件质量要素来衡量。这11个质量要素可划分为三类： 面向运行特征的软件质量要素有正确性、可靠性、有效性、完整性和可用性； 面向软件承受修改的质量要素有可维护性、灵活性、可测试性； 面向转移的软件质量要素有可移植性、可重用性、可互操作性。这三类要素构成了软件质量的三个侧面，如图2-3-2所示。,ZLL,BeiHua,图2-3-2 软件质量要素的构成,产品 修正,产品 转移,产品 运行,可维护性灵活性 可测试性,可移植性可重用性可互操作性,正确性 可靠性 有效性 完整性 可用性,ZLL,BeiH
35、ua,质量要素新概念,ZLL,BeiHua,质量要素新概念,ZLL,BeiHua,2软件质量要素,软件质量要素不是独立的，一个要素可能与其他几个要素有关系，如表2-12所示，其中:正相关以“”表示，负相关以“”表示。 对于具有负相关的质量要素，在开发时应根据具体情况加以取舍或进行折衷。例如，对于实时控制系统，必须确保系统的可靠性和有效性，而软件的可重用性、可移植性等质量要素就可以放宽要求。,ZLL,BeiHua,质量要素间的关系,ZLL,BeiHua,3软件质量要素的评价准则,软件质量要素一般很难直接测量。为了对11个要素进行度量，McCall等人通过确定影响软件质量要素的属性，定义了21个软
36、件质量要素的评价准则。这些评价准则既能够比较完整、准确地描述软件质量要素，又比较容易测量。 通过这组评价准则就可以间接测量软件质量要素，进而度量整个软件质量。,ZLL,BeiHua,评价准则新概念,1）可审查性（audit-ability）：检查软件需求、文档、过程、标准等是否一致的难易程度； 2）准确性（accuracy）：计算和控制的精确程度； 3）简明性（conciseness）：程序源代码的紧凑程度； 4）通信通用性（communication commonality）：使用标准接口、协议和带宽的程度； 5）数据通用性（data commonality）：在程序中使用标准数据结构和类型
37、的程度； 6）容错性（error-tolerance）：在各种异常情况下软件能继续提供操作的能力；,ZLL,BeiHua,评价准则新概念,7）执行效率（execution efficiency）：软件运行效率； 8）可扩充性（expandability）：结构、数据、过程等设计可以扩充的程度； 9）通用性（generality）：程序潜在应用领域的多少； 10）硬件独立性（hardware independence）：软件与其运行的硬件环境无关的程度； 11）检测性（instrumentation）：程序监视自身运行并标识错误的程度； 12）可操作性（operability）：操作该软件的难易
38、程度；,ZLL,BeiHua,评价准则新概念,13）安全性（security）：控制或保护程序和数据不被破坏、非法访问等机制的能力； 14）自文档化（self-documentation）：源代码提供自身说明文档的程度； 15）简单性（simplicity）：程序易于理解的程度； 16）软件独立性（software independence）：软件与非标准编程语言特征、操作系统特征等软件环境约束无关的程度； 17）易培训性（training）：软件对使用它的新用户的支持程度。,ZLL,BeiHua,质量要素与评价准则的关系,ZLL,BeiHua,4软件质量要素的度量,第j种软件质量要素Fj（j
39、=1,2,11）的计算公式为：Fj = Cj k M k （2-21） 其中：M k 是第j 种软件质量要素F j 对第k种评价准则的测量值。评价准则多数只能按主观想法定值。McCall将每个评价准则都划分为0 10级，并且M k 的值可以在0，0.1，0.2，1.0中取一个。加权系数Cjk满足Cjk = 1，Cjk 0。Cjk = 0表示质量要素与第k种评价准则无关。,ZLL,BeiHua,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
40、.8， 则可靠性的度量值为：F2 = C23M3+C24M4+C25M5+C26M6=0.10.7+0.30.6+0.40.5+0.20.8=0.61,ZLL,BeiHua,ISO三层次软件质量度量模型。,1985年，国际标准化组织也提出了三层次软件质量度量模型。其中： 高层称为软件质量需求评价准则（SQRC），并由正确性、可容性、有效性、安全性、可用性、可维护性、灵活性、可互操作性等8个要素组成； 中层称为软件质量设计评价准则（SQDC），并由可追踪性、完全性、等共23个评价准则组成； 低层称作软件质量度量评价准则（SQMC）。 ISO认为，应对高层和中层建立国际标准，而低层可由各使用单位自
41、行制定。,ZLL,BeiHua,2.4 软件复杂性度量,通过软件的复杂性度量值可以估算出软件中故障的数量； 也能估算出软件开发所需的工作量； 定量度量的结果还可以用于比较不同设计方案的优劣。 同时，软件的复杂性也能从某些方面影响软件的可维护性、可靠性等软件质量要素。因此，软件复杂性度量是软件度量的一个重要组成部分。,ZLL,BeiHua,2.4.1 软件复杂性的概念及度量原则 1软件复杂性的概念,K . Magel 从6个方面来描述软件复杂性：1）理解程序的难度；2）维护程序的难度；3）向其他人解释程序的难度；4）按指定方法修改程序的难度；5）根据设计文件编写程序的工作量；6）执行程序时需要资
42、源的多少。 软件复杂性反映了软件的可理解性、模块化、简单性等属性。,ZLL,BeiHua,2软件复杂性度量的原则,软件复杂性的度量，的一些基本原则：1）软件的复杂性与其规模的关系不是线性的；2）数据结构复杂的程序较复杂；3）控制结构复杂的程序较复杂；4）转向语句使用不当的程序较复杂；5）循环结构比选择结构复杂、选择结构比顺序结构复杂；6）语句、数据、子程序模块等出现的顺序对复杂性有影响；,ZLL,BeiHua,2软件复杂性度量的原则,7）非局部变量较多的程序较复杂； 8）参数按地址调用（Call by reference）比按值调用（Call by value）复杂； 9）函数副作用比显式参数
43、传递难理解； 10）作用不同的变量同名时较难理解； 11）模块、过程间联系密切的程序较复杂； 12）程序嵌套层数越多越复杂。 以上这些基本原则是指导我们进一步研究定量度 量软件复杂性的基础。,ZLL,BeiHua,2.4.2 McCabe度量模型,McCabe给出了程序控制结构图G的巡回秩数V（G）作为程序控制结构复杂性的度量，其度量模型为：V（G）= E N + 2 （2-22） 其中：E 程序图G中边的总数；N 程序图中结点的总数。V（G）又称为图G的环形复杂度。 可以证明，V（G）的值等于结构图中有界和无界的封闭区域的个数。,ZLL,BeiHua,三种基本结构的程序图,（a）顺序结构,V
44、（G）= E N + 2 = 1 2 + 2 = 1,（b）选择结构,V（G）= E N + 2 = 4 4 + 2 = 2,（c）while结构,V（G）= E N + 2 = 3 3 + 2 = 2,（d）until 结构,V（G）= E N + 2 = 3 3 + 2 = 2,ZLL,BeiHua,2.4.2 McCabe度量模型,程序结构的复杂性度量值V（G）取决于程序控制流的复杂程度。当程序内的分支数和循环数增加时，V（G）值将随之增加，即程序的复杂性增大。 McCabe研究大量程序后指出，V（G）可作为程序规模的定量指标，V（G）值越高的程序往往是越复杂、越容易出问题的程序。 Mc
45、Cabe建议模块规模应满足：V（G）10,ZLL,BeiHua,【例2.6】程序流程图如图2-4-2所示，试求出其巡回秩数V（G）,解：（1）画出程序流程图对应的程序图。,图2-4-3 程序图,图2-4-2 程序流程图,ZLL,BeiHua,（2）由程序图（或流图）可得：,（3）由程序图可以看出，其有界区域有R1、R2、R3共3个，还有1个无界区域R4，共4个封闭区域，所以：,V（G）= E N + 2 = 11 9 +2 = 4,V（G）= 4,【例2.5】程序流程图如图2-4-2所示，试求出其巡回秩数V（G）,ZLL,BeiHua,2.4.3 Halstead度量模型,20世纪70年代初，
46、Halstead给出了称为文本复杂性度量的模型。它是根据统计程序中的操作符和操作数的个数来度量程序的复杂程度。程序可以看成是由操作符和操作数组成的符号序列。操作符是指程序中出现的语法符号，如+、if-then-else、while等。操作数是操作对象，如程序中定义或使用的变量、常量、数组、指针等。 令：N1为程序中操作符出现的总个数，N2为程序中操作数出现的总个数。则程序的语言符号长度N定义为：N = N1 + N2。,ZLL,BeiHua,2.4.3 Halstead度量模型,如果已经测得程序中不同操作符的个数n1和不同操作数的个数n2，则程序的长度N可用下式来估算：N n1 log2 n1
47、+n2 log2 n2 （2-23） Halstead用下式来定义程序量（即程序在词汇上的复杂性）：V = N log 2（ n1 + n2 ） （2-24） Halstead还给出了预测错误数的公式如下：E = N log 2（ n1 +n2 ）/ 3000 （2-25）,ZLL,BeiHua,2.4.3 Halstead度量模型,可以对多个某种程序设计语言的程序进行统计分析，从而得出每千代码行（KLOC）或每个功能点（FP）所包含的操作符和操作数个数CL或CF，于是，可以将程序语言符号长度N折合成相应的代码行数或功能点数。,ZLL,BeiHua,2.5 软件开发过程的管理,在前几节中介绍了软件度量和估算，这些即是评价软件的重要依据，也是软件开发过程管理的组成部分和基础。在本节中将介绍软件项目管理的过程、风险分析，软件开发计划的进度安排，软件开发人员的组织与分工等等。 2.5.1 软件开发项目管理过程 为达到软件工程的目标，必须对软件开发项目的工作范围、所需的工作量和成本、必需的人力和软硬件资源、可能遇到风险、进度的安排、待实现的任务、经历的里程碑等进行管理。软件开发过程的管理应在所有技术工作开始之前启动，直至软件工程过程的结束。,
