软件工程第2章.ppt

软件工程,经理管什么？,计 划,预算,组 织,进 度,标 准,什么是软件项目管理？,管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。,什么是软件项目管理？,什么是软件项目管理？,成本管理：估算软件项目的成本，作为签订合同或项目立项的依据；在软件开发过程中按计划管理经费的使用。质量管理：制定软件质量保证计划；按照软件质量评价体系控制软件质量要素；对阶段性的软件产品进行评审；对最终产品进行验证和确认，确保软件产品的质量。软件配置管理：制定配置管理计划；对程序、文档和数据的各种版本进行管理，确保软件的完整性和一致性。,第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，Line of Code）数为基础的直接度量。,L表示软件的代码行数，单位为KLOC（千行代码）或LOC；E表示开发软件所需工作量，单位为人月（PM）或人年（PY）；S表示软件成本，单位为美元或元；N表示错误个数；Pd表示软件文档页数；M表示开发所用的人数。,1软件开发的生产率P：P=L/E 2开发每行代码的平均成本C：C=S/L3代码出错率EQR：EQR=N/L 4软件的文档率D：D=Pd/L,面向规模的度量,面向规模的度量,优点：简单、直接。缺点：代码行数的估算依赖于程序设计语言的功能和表 达能力。对设计精巧的软件项目产生不利影响。在开发初期估算代码行十分困难。只适用于过程式程序设计语言。,面向规模的度量,2.1.3 面向功能的度量,1简单功能点度量 1979年，Albrecht首先提出了功能点度量方法。这是一种面向功能的间接度量方法，即从软件定义的基本功能出发，来估算软件系统的规模。因此，该方法可以在软件开发项目的初期，在软件定义过程中即可预测待开发软件的规模。,1简单功能点度量,功能点FP的度量公式如下：FP=CTTCF=CT 0.65+0.01F i 其中：CT基本功能点。CT值按表2-2来计算，它的值为5个参数加权值的总和。,14,i=1,表2-2 简单功能点度量的基本功能点的计算,表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-3 F i 取值表,2功能点度量,简单功能点度量方法没有直接考虑软件本身的算法的复杂性问题。所以它仅适用于度量算法简单的事务处理等系统。1986年Jones对简单功能点度量进行了推广，在计算软件系统的基本功能点CT时，引入了算法复杂性因素，即使用表2-4计算CT。我们称这种推广的度量方法为功能点度量。这两种方法对一般的事务处理系统等算法简单的软件系统计算出来的FP值基本相同，但对于较复杂的软件系统，功能点度量方法比简单功能点度量方法计算出来的FP值要高20%35%。,表2-4 推广的功能点度量的基本功能点的计算,用功能点计算软件项目的有关参考量：,1）生产率P：P=FP/E 2）平均成本C：C=S/FP 3）代码出错率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+4 m+b）/6 软件的LOC或FP的期望值估算出来后，就可以根据已有的标准生产率对成本和工作量等进行估算了。,2.2.3 软件项目的经验估算模型,1IBM模型（静态单变量模型）数据利用最小二乘法拟合，得到的经验估算公式：E=5.2 L0.91 D=4.1L0.36=2.136 E0.3956 S=0.54 E0.6 DOC=49 L1.01,2Putnam模型（动态多变量模型）,该模型以工作量在30人年以上的大型软件项目的实测数据为依据，推导出了工作量分布曲线，如图2-2-1所示。,2.2.3 软件项目的经验估算模型,图2-2-1 软件项目的工作量分布曲线,图2-2-1 软件项目的工作量分布曲线,2Putnam模型,Putnam估算模型如下：L=Ck E1/3 td 4/3,Ck为技术状态常数，与开发环境有关，如下：2000 较差，没有方法学的支持，缺乏文档 和评审，采用批处理方式；Ck=8000 一般，有方法学的支持，有适当的文 档和评审，采用交互处理方式；11000 较好，有集成化的CASE工具和环境。,E=L3/(Ck3 td4),图2-2-2 人力资源的分配,Putnam模型的优缺点,优点：揭示了软件项目的源程序代码长度、软件开发时间和工作量三者之间的关系，在理论上有重要意义。缺点：准确程度不高。没有反映软件产品、项目、参加人员、软硬件资源等属性。,3CoCoMo模型（构造性成本模型）,CoCoMo模型按其详细程度分三个层次：基本CoCoMo模型；中间CoCoMo模型；详细CoCoMo模型。,2.2.3 软件项目的经验估算模型,（1）基本CoCoMo模型,其工作量和开发时间的估算公式如下：E=a Lb D=c Ed 其中：L 软件代码行的估算值（以KLOC计）；E 工作量（以PM计）；D开发时间（以月计）；a、b、c、d经验常数。,表2-8 a、b、c、d参数值的选取,（2）中间CoCoMo模型,中间CoCoMo模型在估算工作量时，在基本CoCoMo模型的基础上再乘以由15个因素组成的工作量调节因子EAF，于是有：E=a Lb EAF=a Lb F i 其中：L 软件的代码行数（以KLOC计）；E 工作量（以PM计）；a、b 经验常数；,i=1,15,表2-9 a、b参数的取值,（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。,（3）详细CoCoMo模型,详细CoCoMo模型的基本工作量（指EAF=1时的工作量）公式、开发时间公式与中间CoCoMo模型相同。所不同的是详细CoCoMo模型在计算EAF时针对每个影响因素，分层次（系统层、子系统层、模块层）并按软件生存周期分阶段给出工作量因素的分级表。详细CoCoMo模型可以更准确地估算软件项目的工作量。,表2-11 子系统层软件可靠性工作量因素分级表,通信数,图2-2-4 N=3 和N=5 时的通信数,成功的标准：,2.3 软件质量度量,失败的根本原因：,用户在用用户可很容易做完要做的事,开发人员写出的东西达不到用户要求(人的问题、技术问题),不贪污的官就是好官吗,“运行正确”的程序就是高质量的程序吗？,也许运行速度很低并且浪费内存；也许代码写得一塌糊涂,2.3.1 软件质量的定义,软件质量是软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，包括：,1软件产品满足用户要求的程度；,2软件拥有所期望的各种属性的组合程度；,3用户对软件产品的综合反映程度；,4软件在使用过程中满足用户需求的程度。,2.3.2 软件质量的度量模型,1976年，Boehm提出了定量度量软件质量的概念，他给出了软件质量的层次模型，并给出了60个软件质量度量公式；1978年，Walters和McCall提出了三层次软件质量度量模型；1985年，ISO提出了SQM（Software Quality Metric，软件质量度量）工作报告等等。,1McCall等人的软件质量度量模型,McCall等人提出了由软件质量要素、评价准则、定量度量三个层次组成的三层次度量模型。,其中:第一层是将对软件质量的度量归结为对直接影响软件质量的若干个软件质量要素的度量；第二层是用若干个可度量的评价准则来间接度量软件质量要素；第三层是对相应评价准则的直接度量。,图2-3-1 软件质量三层次度量模型,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）通信通用性（communication commonality）：使用标准接口、协议和带宽的程度；5）数据通用性（data commonality）：在程序中使用标准数据结构和类型的程度；6）容错性（error-tolerance）：在各种异常情况下软件能继续提供操作的能力；,评价准则新概念,7）执行效率（execution efficiency）：软件运行效率；8）可扩充性（expandability）：结构、数据、过程等设计可以扩充的程度；9）通用性（generality）：程序潜在应用领域的多少；10）硬件独立性（hardware independence）：软件与其运行的硬件环境无关的程度；11）检测性（instrumentation）：程序监视自身运行并标识错误的程度；12）可操作性（operability）：操作该软件的难易程度；,评价准则新概念,13）安全性（security）：控制或保护程序和数据不被破坏、非法访问等机制的能力；14）自文档化（self-documentation）：源代码提供自身说明文档的程度；15）简单性（simplicity）：程序易于理解的程度；16）软件独立性（software independence）：软件与非标准编程语言特征、操作系统特征等软件环境约束无关的程度；17）易培训性（training）：软件对使用它的新用户的支持程度。,18）可追踪性（traceability）：是指根据软件需求对软件设计、程序进行正向追踪，或根据程序、软件设计对软件需求进行逆向追踪的能力。19）模块化（modularity）：把一个程序划分成若干个模块，每个模块完成一个子功能，将这些模块组装成一个整体，即可完成该程序指定的功能。20）一致性（consistency）：整个软件系统（包括程序、数据和文档）的各个模块应使用一致的概念、符号和术语；程序内部接口应保持一致；软件与环境的接口应保持一致；系统规格说明应与系统行为保持一致；用于形式化规格说明的公理系统应保持一致。21）完全性（completeness）：软件系统不丢失任何重要成分，完全实现所需的系统功能的程度。,评价准则新概念,表2-13 质量要素与评价准则的关系,4软件质量要素的度量,第j种软件质量要素Fj（j=1,2,11）的计算公式为：Fj=Cj k M k,其中：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.10.7+0.30.6+0.40.5+0.20.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）参数按地址调用（Call by reference）比按值调用（Call by value）复杂；9）函数副作用比显式参数传递难理解；10）作用不同的变量同名时较难理解；11）模块、过程间联系密切的程序较复杂；12）程序嵌套层数越多越复杂。以上这些基本原则是指导我们进一步研究定量度量软件复杂性的基础。,2.4.2 McCabe度量模型,该方法是把程序流程图转化为程序图：即把程序看成是有一个入口结点和一个出口结点的有向图，图中每个结点对应一个语句、一个简单判断或一个顺序流程的代码块，原来程序流程图中的箭头变成连接各结点的有向弧（或称为边）。一般地，可以假设从程序图中的开始结点可以到达图中的任一结点，而从图中的任一结点都可以到达出口结点。程序图又称为程序控制结构图或程序流图。,2.4.2 McCabe度量模型,McCabe给出了程序控制结构图G的巡回秩数V（G）作为程序控制结构复杂性的度量，其度量模型为：V（G）=E N+2 其中：E 程序图G中边的总数；N 程序图中结点的总数。V（G）又称为图G的环形复杂度。可以证明，V（G）的值等于结构图中有界和无界的封闭区域的个数。,图2-4-1 三种基本结构的程序图,（a）顺序结构,V（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,2.4.2 McCabe度量模型,程序结构的复杂性度量值V（G）取决于程序控制流的复杂程度。当程序内的分支数和循环数增加时，V（G）值将随之增加，即程序的复杂性增大。McCabe研究大量程序后指出，V（G）可作为程序规模的定量指标，V（G）值越高的程序往往是越复杂、越容易出问题的程序。McCabe建议模块规模应满足：V（G）10,【例2.5】程序流程图如图2-4-2所示，试求出其巡回秩数V（G）,解：（1）画出程序流程图对应的程序图。,图2-4-3 程序图,图2-4-2 程序流程图,【例2.5】程序流程图如图2-4-2所示，试求出其巡回秩数V（G）,（2）由程序图（或流图）可得：,（3）由程序图可以看出，其有界区域有R1、R2、R3共3个，还有1个无界区域R4，共4个封闭区域，所以：,V（G）=E N+2=11 9+2=4,V（G）=4,2.4.3 Halstead度量模型,20世纪70年代初，Halstead给出了称为文本复杂性度量的模型。它是根据统计程序中的操作符和操作数的个数来度量程序的复杂程度。程序可以看成是由操作符和操作数组成的符号序列。操作符是指程序中出现的语法符号，如+、if-then-else、while等。操作数是操作对象，如程序中定义或使用的变量、常量、数组、指针等。令：N1为程序中操作符出现的总个数，N2为程序中操作数出现的总个数。则程序的语言符号长度N定义为：N=N1+N2。,2.4.3 Halstead度量模型,如果已经测得程序中不同操作符的个数n1和不同操作数的个数n2，则程序的长度N可用下式来估算：N n1 log2 n1+n2 log2 n2 Halstead用下式来定义程序量（即程序在词汇上的复杂性）：V=N log 2（n1+n2）Halstead还给出了预测错误数的公式如下：E=N log 2（n1+n2）/3000,2.4.3 Halstead度量模型,可以对多个某种程序设计语言的程序进行统计分析，从而得出每千代码行（KLOC）或每个功能点（FP）所包含的操作符和操作数个数CL或CF，于是，可以将程序语言符号长度N折合成相应的代码行数或功能点数。,2.5 软件可靠性度量,软件可靠性定义为在某个给定时间间隔内，程序按照规格说明成功运行的概率。,1软件可靠性,令：随机变量 t 表示发生故障的时刻，t0，；函数f（t）为随机变量t 的概率密度函数，F（t）表示分布函数；P（0 t t1）表示从初始时刻到t1时刻程序发生故障的概率。设：初始时刻程序运行正常，即F（0）=0。于是有：F（t）=f（x）dx f（t）=d F（t）,d t,0,t,令：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）=1Pf（t）=1 F（t）=1 f（x）dx 上式说明，当软件残留的错误数一定时，程序运行的时间越长，发生故障的次数越多，软件的可靠性越小。,0,t,下面引入故障率函数Z（t），以比较一个程序在不同时期、或不同程序在同一时期的可靠性。设系统一直成功运行至时刻t，tt1，t1+t，P（t1tt1+t，tt1）是系统在t1，t1+t时间间隔且tt1时发生故障的概率。故障率函数Z（t1）的值定义为：Z（t1）=lim P（t1tt1+t，tt1）/t 可以证明：Z（t）=对前式的两端对时间t求导得：dF（t）/dt=dR（t）/d t，代入上式，得：=Z（t）d t,1R（t）,d F（t）d（t）,d R（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 k t 2/2 上式称为故障率是时间的线性函数时的可靠性模型。即当存在损耗和退化时，故障率将随着时间的增加而线性增加。该模型一般不适合于软件产品。需要指出，软件中的错误一般都是人为的设计错误，其中多数是逻辑错误。随着对软件的测试及修复，软件系统中的错误会越来越少。因此，实际软件系统的故障率函数曲线应如图2-5-1所示，即软件故障率不是常数、也不是线性函数，而是按指数规律下降。实际的统计结果也说明了这一点。,图2-5-1 软件系统故障率,2软件的有效性及其度量,软件的有效性函数A（t）定义为软件系统在时刻t按照规格说明成功运行的概率。可靠性与有效性之间的差别是，可靠性强调软件系统在0t这段时间间隔内都有效，而有效性强调软件系统在时刻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（mean time between failurs，即程序正常运行时间的平均值）和平均修复时间MTTR（mean time to repair，即平均停机时间），则软件系统的稳态有效性为：A=MTBF/（MTBF+MTTR）采用上述方法，在开发阶段和投入运行后都可以定量地度量软件系统的有效性和可靠性。软件系统投入运行的一段时间内，可以用各种输入和操作来引发程序中残留的错误，经过多次修复后错误将逐渐减少，有效性和可靠性将不断提高。,2.5.2 软件可靠性的估算,软件可靠性估算模型大致分为宏观和微观模型两类。宏观模型是从程序中残留错误数的角度建立模型，并用统计方法确定模型参数。而微观模型则以程序的控制结构和语句分析为基础。下面仅介绍几个典型的宏观模型。,1残留错误总数的估算模型 对残留错误总数的估算是可靠性估算的基础。典型的估算模型：错误植入模型；分别测试模型。,1）错误植入模型,Mills首先提出了估算程序中残留错误总数的错误植入模型。即在进行测试之前，由专人（比如统计人员）在程序中随机地植入一些错误（称为带有标记的错误），测试人员测试之后，通过统计测试人员发现的原有错误和植入错误的比例来估算程序中原有错误总数。设：N t 植入的错误数，n 测试发现原有的错误数，n t发现植入的错误数，ET 原有的错误总数。则有：ET/N t n/n t于是ET的估算模型为：ET=N tn/n t,2）分别测试模型,1973年，Hyman对错误植入模型做了改进，即用甲、乙两个程序测试员同时对一个程序的两个副本进行独立测试。设：ET 程序中原有的残留错误总数，E1 甲在0，时间内发现的错误数，E2 乙在0，时间内发现的错误数，E0 两人在0，时间内发现的相同的错误 的个数，则有：ET=E1E2/E0 Hyman提出的分别测试模型无论在技术上还是在 经济上都比错误植入模型优越。,2软件平均故障间隔时间的估算,软件的平均故障间隔时间MTBF是可靠性度量的一个重要参数，往往作为一个重要的质量指标由用户提出来。下面介绍MTBF的估算方法。1）软件故障率为常数 当软件故障率为常数时，假设程序运行H小时，共发生r次故障，则的估算值为：r/H于是有：MTBF=1/=H/r,2）软件故障率与程序残留错误数成正比,设：IT 程序代码长度；ET 测试之前程序中残留错误总数；E c（）0，区间内改正的错误数；E r（）在时刻程序中剩余的错误数；其中为调试和排错时间。于是，剩余的错误数为：E r（）=ET E c（）,2）软件故障率与程序残留错误数成正比,E r（）=ET E c（）用IT去除上式的两边，有：E r（）/IT=ET/IT E c（）/IT令：r（）=E r（）/IT，T=ET/IT，c（）=E c（）/IT，于是有：r（）=T c（）,2）软件故障率与程序残留错误数成正比,由于软件故障率=（）与程序残留错误数成正比，所以有：=kr（）=k（T c（）其中的比例因子k可通过实验测试和统计的方法来估算。设进行n次软件排错实验，时间区间为0，j，到j 时刻为止，共排除了E c（j）个错误，而在时间区间0，j 内，程序运行了H j小时，出现了rj个错误，j=1，2，n。此时k的估计值为：k=r j/H j T c（j）,nj=1,nj=1,2）软件故障率与程序残留错误数成正比,k=r j/H j T c（j）当n=1时，k=r/HT c（）当n=2时，k=（r1+r2）/H1T c（1）+H2T c（2）k的值估算出来之后，即可利用公式估算MTBF，它是的函数。,2）软件故障率与程序残留错误数成正比,对于确定的值，=kr（）为常数，于是，经过0，区间的排错后，软件可靠性估算为：R（t）=exp kr（）t=exp（t/MTBF）上式中时间参数以月计，表示对程序调试和维护的时间，t 0，以小时计，表示程序运行的时间。上式可理解为经过个月的调试后所达到的软件可靠性。,2.6 软件开发过程的管理,为达到软件工程的目标，必须对软件开发项目的工作范围、所需的工作量和成本、必需的人力和软硬件资源、可能遇到风险、进度的安排、待实现的任务、经历的里程碑等进行管理。软件开发过程的管理应在所有技术工作开始之前启动，直至软件工程过程的结束。,软件开发项目管理过程主要包括以下几个方面：,1启动一个软件项目,2成本估算,3风险分析,4进度安排,5追踪和控制,风险分析,风险的特点：,不确定性，某项风险可能发生也可能不发生；,损失，一旦某项风险变成了现实，就必然会给项目带来不良的影响和损失，甚至灾难性后果。,（1）按照风险的影响范围分类 项目风险 技术风险 商业风险,2.风险分类：,（2）按照风险的可预测性分类 已知风险 可预测的风险 不可预测的风险,风险分析,3.风险分析的三个主要活动：,风险标识；风险估算；处理风险的策略。,If you dont actively attack the risks,they will actively attack you.Tom Gilb(1988),1风险标识,Boehm建议使用各类风险检测表来标识风险。在风险检测表中列出所有可能的与每一个风险因素有关的问题。,包括产品规模风险检测表、商业风险检测表、客户风险检测表、过程风险检测表、开发环境风险检测表、技术风险检测表、人员风险检测表等等。,例如，“人员风险检测表”可如表2-14所示。在表2-14中，可以根据实际情况选用0、1、2、3、4、5来回答每一个问题，某个问题取值越大表示该项风险也越大。人员风险检测表反映了人的因素可能对软件项目的影响。,表2-14 人员风险检测表,2风险估算风险预测,风险预测(也称为风险估算)试图从两个方面来评估每个风险：风险变成现实的可能性或概率，以及当风险变成现实时所造成的后果。,（1）评估风险后果 美国空军建议从性能、支持、成本和进度等四个方面评估风险的后果，他们把上述四个方面称为四个风险因素。下面给出这四个风险因素的定义。性能风险 成本风险 支持风险 进度风险,2风险估算,根据风险发生时对上述四个风险因素影响的严重程度，可以把风险后果划分成四个等级：可忽略的、轻微的、严重的和灾难性的。,（2）建立风险表,评估风险后果,3处理风险的策略,对于绝大多数软件项目来说，上述的4个风险因素(性能、成本、支持和进度)都有一个临界值，超过临界值就会导致项目被迫终止。也就是说，如果性能下降、成本超支、支持困难或进度延迟(或这4种因素的组合)超过了预先定义的限度，则因风险过大项目将被迫终止。如果风险还没有严重到迫使项目终止的程度，则项目组应该制定一个处理风险的策略。一个有效的策略应该包括下述三方面的内容：风险避免(或缓解)；风险监控；风险管理和意外事件计划。,（1）风险缓解 如果软件项目组采用主动的策略来处理风险，则避免风险总是最好的策略。这可以通过建立风险缓解计划来达到。（2）风险监控 随着项目的进展，风险监控活动也就开始了。项目管理者监控某些能指出风险概率正在变高还是变低的因素。（3）风险管理和意外事件计划 风险管理和意外事件计划假设缓解风险的努力失败了，风险变成了现实。,3处理风险的策略,项目管理者的目标是定义全部项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。为了做到这一点，管理者必须制定一个足够详细的进度表，以便监督项目进度，并控制整个项目。软件项目的进度安排是一项活动，它通过把工作量分配给特定的软件工程任务，并规定完成各项任务的起、止日期，从而将估算的工作量分布于计划好的项目持续期内。,进度安排,基本原则下述的基本原则能够指导软件项目的进度安排。1.划分2.相互依赖性3.时间分配4.工作量确认5.定义责任6.定义结果7.定义里程碑,进度安排,1、Gantt Chart（甘特图）,优点：简单，能动态地反映开发进展。,缺点：难以反映多个任务间的逻辑关系。,进度安排,2、PERT(Program Evaluation&Review Technique)和CPM(Critical Path Method),例：开发三个模块A、B、C。A为公用模块，B、C的测试须等A的调试完成后进行。A的编码需6天，测试8天，调试6天。B的编码需7天，测试8天，调试6天。C利用已有的模块，须先理解原模块8天，再修改8天，测试9天，调试7天。最后三模块集成测试需5天完成。,(1)标出