第12章--软件工程.ppt

1、1,12章软件工程管理,本章内容： 软件工程管理概述 软件规模估算 人员组织 软件配置管理 软件质量保证 软件工程标准与软件文档 本章重点： 软件配置管理 软件质量保证,2,12.1 软件工程管理概述,1. 软件产品的特点 抽象性， 同一功能的软件多样性， 生产、开发维护复杂易错性， 要考虑其安全性，可移植性等问题， 有新技术需要进一步的研究与实践,3,12.1 软件工程管理概述,2. 软件工程管理的重要性 3. 软件工程管理的内容 包括对软件开发成本、软件开发控制、开发人员、组织机构、用户、软件开发文档、软件质量等方面的管理。,4,12.2 软件规模估算,12.2.1 软件开发成本估算方法

2、自顶向下 自底向上 差别估算 算式估算 类推估算,5,1) 自顶向下估算方法,估算人员参照以前完成的项目所耗费的总成本（或总工作量），来推算将要开发的软件的总成本（或总工作量），然后把它们按阶段、步骤和工作单元进行分配， 这种方法称为自顶向下估算方法。 自顶向下估算方法的主要优点是对系统级工作的重视，所以估算中不会遗漏系统级的诸如集成、用户手册和配置管理之类的事务的成本估算， 且估算工作量小、速度快。 它的缺点是往往不清楚低层次上的技术性困难问题，而往往这些困难将会使成本上升。 ,6,2) 自底向上估算方法,这种方法的优点是对每一部分的估算工作交给负责该部分工作的人来做， 所以估算较为准确。其

3、缺点是其估算往往缺少与软件开发有关的系统级工作量，如集成、配置管理、质量管理和项目管理等，所以估算往往偏低。 一般两种方法结合起来一起使用,7,3) 差别估算方法,差别估算是将开发项目与一个或多个已完成的类似项目进行比较，找出与某个相类似项目的若干不同之处，并估算每个不同之处对成本的影响， 导出开发项目的总成本。 该方法的优点是可以提高估算的准确度， 缺点是不容易明确“差别”的界限 除以上方法外，还有许多方法，大致分为专家、类推和算式估算法。,8,别的方法,1) 专家估算法 依靠一个或多个专家对要求的项目做出估算，其精确性取决于专家对估算项目的定性参数的了解和他们的经验。 2) 类推估算法 自

4、顶向下的方法中，它是将估算项目的总体参数与类似项目进行直接比较相比得到结果。自底向上方法中，类推是在两个具有相似条件的工作单元之间进行。 3) 算式估算法 专家估算法和类推估算法的缺点在于，它们依靠带有一定盲目和主观的猜测对项目进行估算。算式估算法则是企图避免主观因素的影响。 用于估算的方法有两种基本类型：由理论导出和由经验得出。 ,9,12.2.2 代码行技术和任务估算技术 1. 代码行技术 2. 任务估算技术,10,估算软件规模,1 代码行技术 这种方法依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。 当有以往开发类似产品的历史数据可供参考时，用这种方法估计出的数

5、值还是比较准确的。 把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。,11,为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。每个人都估计程序的最小规模(a)、最大规模(b)最可能的规模(m)，分别算出这3种规模的平均值之后，再用下式计算程序规模的估计值：,12,用代码行技术估算软件规模时，当程序较小时常用的单位是代码行数(LOC)，当程序较大时常用的单位是千行代码数(KLOC)。 代码行技术的主要优点是，代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。 代码行技术的缺点是：源程序仅是软件配置的一个成分，用它的规模

6、代表整个软件的规模似乎不太合理；用不同语言实现同一个软件所需要的代码行数并不相同；这种方法不适用于非过程语言。为了克服代码行技术的缺点，人们又提出了功能点技术。,13,功能点估算与代码行估算的区别,1、 FP功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高，假如这个时候使用LOC代码行估算法，则误差会比较大。 2、 使用FP功能点估算法无需懂得软件使用何种开发技术。LOC代码行估算法与软件开发技术密切相关。 3、 FP功能点法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算的。 4、 通过一些行业标准或企业自身度量的分析，FP功能点估算法是

7、可以转换为LOC代码行的。,14,2功能点技术 功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法以功能点(FP)为单位度量软件规模。 功能点是对软件功能和规模的间接定量测量，它基于客观的外部应用接口和主观的内部应用复杂度以及总体的性能特征。,15,功能点发进行估算的时候具体过程是：1.对估算功能单元的类型进行识别2.计算每种类型的复杂度3.计算总体的调整前的功能点数4.根据调整因子对功能点数进行调整,16,功能点估算中有5种信息域需要进行描述：其中事务类的有EI,EO和EQ，数据存储类有ILF和EIF.外部输入(EI):通过界面等的输入，插入更新等操作都是典型外部输

8、入外部输出(EO):仅仅输出，导出，报表，打印等输出外部查询(EQ):先要输入数据，在根据输入数据计算输出，如查询内部逻辑文件(ILF):可以理解为业务对象，可能对应多个数据表外部接口文件(EIF):其它应用提供的接口数据,17,A.对事务类功能点的估算：对事务类的功能点估算需要确定DET和FTR两个指标：DET:可以理解为界面的录入具体数据项，按钮也要作为数据项FTR:事务功能需要操作的数据文件的数目 B.对数据存储类功能点的估算对数据存储类功能点的估算需要确定DET和RET两个指标DET:具体数据存储文件的数据项的数目RET:数据文件是复合文件时候关联或引用的个数如订单数据文件由于存在订单

9、头和明细关联引用,RET应该算2.,18,信息域数据估算完成后可以开始考虑调整因子：调整因子是一种补偿机制，即通过五个信息域和复杂度都还没有办法考虑到的因素就应该做为调整因子 如同样一个软件系统一种是系统要支持分布式和自动更新，而另一种是不考虑这种需求，如果不考虑调整因子这两者的规模是一样的，但很明细第一种情况复杂度和规模都会更大些,19,有了调整因子后最终可以得到调整后的功能点数:AFP(调整后功能点)= UFP (未调整功能点数目)* AF (影响因子),20,12.2.3 COCOMO2模型,COCOMO2模型分为3个层次，在估算软件开发工作量时，对软件细节问题考虑的详尽程度逐层增加：

10、应用系统组成模型：用于估算构建原型的工作量，这种模型考虑到大量使用已有构件的情况。 早期设计模型：用于软件结构设计阶段。 后期设计模型：用于软件结构设计完成之后的软件开发阶段。 COCOMO2模型把软件开发工作量表示成代码行（KLOC）的非线性函数，如式（12.1）所示。 其中，E是开发工作量（以人月为单位）， 是模型系数， KLOC是估算的源代码行数（以千行为单位）， b是模型指数， fi（i =117）是成本因素。,21,1) COCOMO估算模型 结构性成本模型COCOMO(Constructive Cost Mode)是最精确、最易于使用的成本估算方法之一。该模型分为： 基本COCOM

11、O模型， 它是一个静态单变量模型，对整个软件系统进行估算； 中级COCOMO模型，它是一个静态多变量模型，将软件系统模型分为系统和部件两个层次，系统是由部件构成的，它把软件开发所需人力（成本）看作是程序大小和一系列“成本驱动属性”的函数，用于部件级的估算，更精确些； 详细COCOMO模型，将软件系统模型分为系统、子系统和模块 3 个层次，它除包括中级模型中所考虑的因素外，还考虑了在需求分析、软件设计等每一步的成本驱动属性的影响。 ,22,COCOMO2给出了3个层次的软件开发工作量估算模型，在估算工作量的时候，对软件细节考虑的详尽程序逐级增加 应用系统组成模型：这种模型考虑到大量使用已有构件的

12、情况。 早期设计模型：用于软件结构设计阶段。 后期设计模型：用于软件结构设计完成之后的软件开发阶段。,23,见书P210,24,4) Putnam成本估算经验模型 Putnam估算模型是一种动态多变量模型，它是假设在软件开发的整个生存期中工作量的分布。 根据曲线导出关于提交的代码行数L， 人力K（人年）和开发时间td(年)之间的估算公式： L = CkK1/3 t 4/3 d 式中Ck是技术状况有关的常数，它反映“妨碍开发进展的限制”，取值因开发环境而异它的典型值如下： ,25,26,软件复杂性的度量方法 1. 代码行度量法 度量程序的复杂性，最简单的方法就是统计程序的源代码行数。此方法的基本

13、考虑是统计一个程序的源代码行数，并以源代码行数作为程序复杂性的度量。 若设每行代码的出错率为每100行源程序中可能的错误数目， 例如每行代码的出错率为1%，则是指每100行源程序中可能有一个错误。 Thayer曾指出，程序出错率的估算范围是从0.04%7%之间，即每100行源程序中可能存在0.047个错误。 他还指出， 每行代码的出错率与源程序行数之间不存在简单的线性关系。 Lipow进一步指出，对小程序，每行代码的出错率为1.3%1.8%；对于大程序，每行代码的出错率增加到2.7%3.2%之间。,27,但这只是考虑了程序的可执行部分，没有包括程序中的说明部分。 Lipow及其他研究者得出一个

14、结论: 对于少于100个语句的小程序，源代码行数与出错率是线性相关的； 随着程序的增大，出错率以非线性方式增长。所以，代码行度量法只是一个简单的， 估计得很粗糙的方法。 2. McCabe度量法 McCabe度量法是一种基于程序控制流的复杂性度量方法。 McCabe复杂性度量又称环路度量，它认为程序的复杂性很大程度上取决于控制的复杂性，单一的顺序程序结构最为简单，循环和选择所构成的环路越多，程序就越复杂。这种方法以图论为工具，先画出程序图，然后用该图的环路数作为程序复杂性的度量值。,28,程序图是退化的程序流程图，即把程序流程图中每个处理符号都退化成一个结点，原来联结不同处理符号的流线变成连接

15、不同结点的有向弧，得到的有向图就叫做程序图。 程序图仅描述程序内部的控制流程，完全不表现对数据的具体操作以及分支和循环的具体条件。因此，它往往把一个简单的IF语句与循环语句的复杂性看成是一样的，把嵌套的IF语句与CASE语句的复杂性看成是一样的。下面给出计算环路复杂性的方法。 根据图论， 在一个强连通的有向图G中， 环的个数V（G）由以下公式给出： V（G）=m-n+2p,29,其中，V（G）是有向图G中环路数，m是图G中弧数， n是图G中结点数，p是G中的强连通分量个数。 在一个程序中， 从程序图的入口点总能到达图中任何一个结点，因此，程序总是连通的，但不是强连通的。为了使图成为强连通图，

16、从图的入口点到出口点加一条用虚线表示的有向边，使图成为强连通图。 这样就可以使用上式计算环路复杂性了。 在图13.4所给出的示例中， 结点数n=6， 弧数m=9， p=1， 则有： V（G）=m-n+2p=9-6+2=5 ,30,即McCabe环路复杂度度量值为5。 另一种简单的方法是程序图的拓扑结构把平面划分为封闭区域和开放区域的个数。在图13.4中， 有4个封闭区域和1个开放区域， 共5个区域，则V(G)=5。 当分支或循环的数目增加时，程序中的环路也随之增加， 因此McCabe环路复杂度量值实际上是为软件测试的难易程序提供了一个定量度量的方法， 同时也间接地表示了软件的可靠性。 实验表明

17、，源程序中存在的错误数以及为了诊断和纠正这些错误所需的时间与McCabe环路复杂度度量值有明显的关系。 ,31,图 13.4 程序图的复杂性,32,利用McCabe环路复杂度度量时， 有以下几点说明： (1) 环路复杂度取决于程序控制结构的复杂度。 当程序的分支数目或循环数目增加时其复杂度也增加。环路复杂度与程序中覆盖的路径条数有关。 (2) 环路复杂度是可加的。例如，模块A的复杂度为3，模块B的复杂度为4， 则模块A与模块B的复杂度是7。 (3) McCabe建议， 对于复杂度超过10的程序， 应分成几个小程序， 以减少程序中的错误。 ,33,McCabe复杂度度量的缺点有如下几种： (1)

18、 对于不同种类的控制流的复杂性不能区分。 (2) 简单IF语句与循环语句的复杂性同等看待。 (3) 嵌套IF语句与简单CASE语句的复杂性是一样的。 (4) 模块间接口当成一个简单分支一样处理。 (5) 一个具有1000行的顺序程序与一行语句的复杂性相同。 尽管McCabe复杂度度量法有许多缺点， 但它容易使用， 而且在选择方案和估计排错费用等方面都是很有效的。 ,34,12.2.4程序环行复杂度的度量,(1) V(G)=m-n+2 =7-6+2=3 (2)V(G)=P+1 =2+1=3 (3) 强连通的程序图中， 线性无关的有向环的个数为 3。,35,12.3 人员组织,1. 开发人员 2.

19、 组织机构 3. 用户,36,人员管理 1. 开发人员 软件开发人员一般分为: 项目负责人、系统分析员、高级程序员、程序员、初级程序员、 资料员和其他辅助人员。 根据项目规模的大小，有可能一人兼数职，但职责必须明确。不同职责的人，要求的素质不同。 如项目负责人需要有组织能力、 判断能力和对重大问题能做出决策的能力；系统分析员需要有概括能力、分析能力和社交活动能力；程序员需要有熟练的编程能力等。 人员要少而精，选人要慎重。软件生存期各个阶段的活动既要有分工又要互相联系。因此，要求选择各类人员既能胜任工作，又要能相互很好地配合，没有一个和谐的工作环境很难完成一个复杂的软件项目。 ,37,组织机构,

20、按课题划分的模式（Project Format） 按职能划分的模式（Functional Format） 矩阵形模式（Matrix Format） 程序设计小组的组织形式有3种： 主程序员组、民主组织及层次式组织。,38,39,2. 组织机构 组织机构不等于开发人员的简单集合, 要求有好的组织结构；合理的人员分工；有效的通讯。软件开发的组织机构没有统一的模式。下面简单介绍主程序员、专家组及民主组织 3 种组织机构： (1) 主程序员组织机构：是由一位高级工程师(主程序员)主持计划、协调和复审全部技术活动；一位辅助工程师（或辅助程序员）协助主程序员工作， 并在必要时代替主程序员工作；若干名技术人

21、员(程序员)负责分析和开发活动；可以有一位或几位专家和一位资料员协助软件开发机构的工作。资料员非常重要，负责保管和维护所有的软件文档资料，帮助收集软件的数据，并在研究、分析和评价文档资料的准备方面进行协助工作。 ,40,主程序员组的制度突出了主程序员的领导，责任集中在少数人身上， 有利于提高软件质量。 (2) 专家组组织机构：是由若干专家组成一个开发机构， 强调每个专家的才能，充分发挥每个专家的作用。这种组织机构虽然能发挥所有工作人员的积极性，但往往有可能出现协调上的困难。 (3) 民主组织机构：是由从事各方面工作的人员轮流担任组长。很显然，这种组织机构对调动积极性和个人的创造性是很值得称道的

22、，但是，由于过多地进行组长信息“转移”，不符合软件工程化的方向。 ,41,3. 用户 软件是为用户开发的， 在开发过程中自始至终必须得到用户的密切合作和支持。 作为项目负责人，要特别注意与用户保持联系，掌握用户的心理和动态，防止来自用户的各种干扰和阻力。其干扰和阻力主要有: (1) 不积极配合: 指当用户对采用先进技术有怀疑， 或担心失去自己现有的工作时，可能有抵触情绪，因此在行动上表现为消极、漠不关心，有时不配合。 在需求分析阶段，做好这部分人的工作是很重要的，通过他们中的业务骨干，才能真正了解到用户的要求。 (2) 求快求全：指对使用计算机持积极态度的用户， 他们中一部分人急切希望马上就能

23、用上计算机。要他们认识到开发一个软件项目不是一朝一夕就能完成的，软件工程不是靠人海战术就能加快的工程；同时还要他们认识到计算机并不是万能的，有些杂乱无章的、随机的和没有规律的事物计算机是无法处理的。 另外，即使计算机能够处理的事情，系统也不能一下子包罗万象，贪大求全。,42, (3) 功能变化： 指在软件开发过程中， 用户可能会不断提出新的要求和修改以前提出的要求。从软件工程的角度，不希望有这种变化。但实际上，不允许用户提出变动的要求是不可能的。 因为一方面每个人对新事物有一个认识过程，不可能一下子提出全面的、正确的要求；另一方面还要考虑到与用户的关系。 对来自用户的这种变化要正确对待，要向用

24、户解释软件工程的规律，并在可能的条件下，部分或有条件地满足用户的合理要求。 ,43,12.4 软件配置管理,软件配置（Software Configuration）是软件产品在软件开发或运行过程中产生的全部信息。 软件配置管理（Software Configuration Management）简称SCM，是在软件的整个生命周期内管理变更的一组活动。 软件配置管理(Software Configuration Management，简称SCM)的四项任务: ()标识变更。 ()控制软件配置的全部变动，即“控制变更”。 ()确保变更正确地实现。 ()报告配置的变更。,44,软件配置管理,在软件开

25、发时，变更是不可避免的，而变更时由于没有进行变更控制，可能加剧了项目中的混乱。为协调软件开发使得混乱减到最小，使用配置管理技术，使变更所产生的错误达到最小并最有效地提高生产率。 软件配置管理(Software Configuration Management, 简称SCM)用于整个软件工程过程。其主要目标是标识变更；控制变更； 确保变更正确地实现；报告有关变更。SCM是一组管理整个软件生存期各阶段中变更的活动。,45,.1 基线 基线是软件生存期中各开发阶段的一个特定点，它的作用是把开发各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开， 以便于检查与肯定阶段成果。因此基线可以作为一个

26、检查点，在开发过程中，当采用的基线发生错误时， 可以知道其所处的位置，返回到最近和最恰当的基线上。软件开发各阶段基线示例如图15.6所示。 ,46,图 15.6 软件开发各阶段基线示例,47,.2 软件配置项 随着软件工程过程的进展，软件配置项（Software Configuration Item, 简称SCI）是软件工程中产生的信息项, 它是配置管理的基本单位， 对已成为基线的SCI，虽然可以修改， 但必须按照一个特殊的、正式的过程进行评估，确认每一处的修改。以下的SCI是SCM的对象，并可形成如下基线： (1) 系统规格说明书。 (2) 软件项目实施计划。 (3) 软件需求规格说明书。

27、(4) 设计规格说明书（数据设计、 体系结构设计、 模块设计、 接口设计和对象描述（使用面向对象技术时）。,48,(5) 源代码清单。 (6) 测试计划和过程、 测试用例和测试结果记录。 (7) 操作和安装手册。 (8) 可执行程序（可执行程序模块、 连接模块）。 (9) 数据库描述（模式和文件结构、 初始内容）。 (10) 用户手册。 (11) 维护文档（软件问题报告、 维护请求和工程变更次序）。 (12) 软件工程标准。 (13) 项目开发小结。 ,49,版本控制 软件配置实际上是一动态的概念，它一方面随着软件生存期向前推进， SCI的数量在不断增多，一些文档经过转换生成另一些文档，并产生

28、一些信息；另一方面又随时会有新的变更出现，形成新的版本。 表达系统不同版本的一种表示如图15.7所示的演变图， 在图中各个结点是一个完全的软件版本。软件的每一个版本都是SCI（源代码、 文档及数据）的一个收集，且各个版本都可能由不同的变种组成。图的右边具体说明一个简单的程序版本：它由1，2，3，4和5版本组成，其中版本4在软件使用彩色显示器时使用，版本5在软件使用单色显示器时使用。 因此，可以定义版本的两个变种。 ,50,图 15.7 版本演变与变种图,51,.4 变更控制 软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，保持修改信息，并把精确、清晰的信息

29、传递到软件工程过程的下一步骤。 变更控制包括建立控制点和建立报告与审查制度。对于一个大型软件来说，不加控制的变更很快就会引起混乱。因此变更控制是一项最重要的软件配置任务，变更控制的过程如图15.8所示。 其中“检出”和“登入”处理实现了两个重要的变更控制要素，即存取控制和同步控制。存取控制管理各个用户存取和修改一个特定软件配置对象的权限。同步控制可用来确保由不同用户所执行的并发变更。 ,52,图 15.8 变更控制的过程,53,12.5 软件质量保证,计算机软件质量是软件的一些内部特性的组合，质量不是在软件产品中被测试出来的，而是在软件开发和生产过程中形成的。 软件质量（Software qu

30、ality）的定义为： （1）软件产品中能满足给定需要的性质和特性的总体。 （2）软件具有所期望的各种属性的组合程度。 （3）顾客和用户觉得软件满足其综合期望的程度。 （4）确定软件在使用中将满足顾客预期要求的程度。,54,上述定义包括以下含义： (1) 软件需求是度量软件质量的基础。 不符合需求的软件就不具备质量。 (2) 专门的标准中定义了一些开发准则，用来指导软件人员用工程化的方法来开发软件。如果不遵守这些开发准则，软件质量就得不到保证。 (3) 往往会有一些隐含的需求没有明确地提出来。 例如， 软件应具备良好的可维护性。如果软件只满足那些精确定义了的需求而没有满足这些隐含的需求，软件质

31、量也不能保证。 软件质量是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不同。 ,55,软件质量的度量和评价 一般说， 影响软件质量的因素可以分为如下两大类： (1) 可以直接度量的因素， 如单位时间内千行代码（KLOC）中所产生的错误数。 (2) 只能间接度量的因素， 如可用性或可维护性。 在软件开发和维护过程中，为了定量地评价软件质量， 必须对软件质量特性进行度量，以测定软件具有要求质量特性的程度。1976年，Boehm等人提出了定量评价软件质量的层次模型(见图13.1)；1978年Walters和McCall提出了从软件质量要素、 准则到度量的 3 个层次式的软

32、件质量度量模型(见图13.2)； G.Murine根据上述等人的工作， 提出软件质量度量（SQM）技术(见图13.3)，用来定量评价软件质量。 ,56,图 13.1 Boehm软件质量度量模型,57,图 13.2 McCall软件质量度量模型,58,为保证软件充分满足用户要求而进行的有计划、有组织的活动称为软件质量保证，其目的是生产高质量的软件。 2. 质量保证的策略 质量保证策略的发展大致可以分为以下 3 个阶段： (1) 以检测为重。产品制成后才进行检测，这种检测只能判断产品的质量，不能提高产品质量。 (2) 以过程管理为重。 把质量保证工作重点放在过程管理上，对制造过程的每一道工序都进行

33、质量控制。 (3) 以新产品开发为重。许多产品的质量问题源于新产品的开发设计阶段，因此在产品开发设计阶段就应采取有力措施， 以便消灭由于设计原因而产生的质量隐患。 由上可知，软件质量保证应从项目计划和设计开始，直到投入使用和售后服务的软件生存期的每一阶段中的每一步骤。,59,3. 质量保证的主要任务 为了提高软件的质量， 软件质量保证的任务大致可归结为以下几点： (1) 正确定义用户要求: 软件质量保证人员必须正确定义用户所要求的技术。必须十分重视领导全体开发人员收集和积累有关用户业务领域的各种业务资料和技术技能。 (2) 技术方法的应用: 开发新软件的方法，最普遍公认的成功方法就是软件工程学

34、的方法。标准化、设计方法论、工具化等都属此列。 应当在开发新软件的过程中大力使用和推行软件工程学中所介绍的开发方法和工具。 (3) 提高软件开发的工程能力: 只有高水平的软件工程能力才能生产出高质量的软件产品。,60,因此须在软件开发环境或软件工具箱的支持下， 运用先进的开发技术、工具和管理方法提高开发软件的能力。 (4) 软件的复用: 利用已有的软件成果是提高软件质量和软件生产率的重要途径。不要只考虑如何开发新软件，首先应考虑哪些已有软件可以复用，并在开发过程中，随时考虑所生产软件的复用性。 (5) 发挥每个开发者的能力: 软件生产是人的智能生产活动， 它依赖于开发组织团队的能力。开发者必须

35、有学习各专业业务知识、 生产技术和管理技术的能动性。管理者或产品服务者要制定技术培训计划、技术水平标准，以及适用于将来需要的中长期技术培训计划。 ,61,(6) 组织外部力量协作: 一个软件自始至终由一软件开发单位来开发也许是最理想的, 在现实中难以做到。因此需要改善对外部协作部门的开发管理, 必须明确规定进度管理、质量管理、 交接检查和维护体制等各方面的要求，建立跟踪检查的体制。 (7) 排除无效劳动：最大的无效劳动是因需求说明有误、 设计有误而造成的返工。定量记录返工工作量，收集和分析返工劳动花费的数据非常重要。另一种较大的无效劳动是重复劳动，即相似的软件在几个地方同时开发。 这多是因项目

36、开发计划不当，或者开发信息不流畅造成的。为此，要建立互相交流、信息往来通畅和具有横向交流特征的信息流通网。 ,62,(8) 提高计划和管理质量：对于大型软件项目来说， 提高工程项目管理能力是极其重要的。必须重视项目开发初期计划阶段的项目计划评价、计划执行过程中及计划完成报告的评价将评价、评审工作在工程实施之前就列入整个开发工程的工程计划之中。 4. 质量保证与检验 软件质量必须在设计和实现过程中加以保证。如果工程能力不够，或者由于各种失误导致产生软件差错，其结果就会产生软件失效。为了确保每个开发过程的质量，防止把软件差错传递到下一个过程，必须进行质量检验。 因此须在软件开发工程的各个阶段实施检

37、验。检验的实施有实际运行检验（即白盒测试和黑盒测试）和鉴定两种形式, 可在各开发阶段中结合起来使用。 ,63,质量度量模型,2.1 McCall 质量度量模型 McCall质量度量模型是McCall等人于1979年提出的软件质量模型，如图 13.2 所示。 针对面向软件产品的运行、修正和转移，软件质量概念包括如下11个特性。 1) 面向软件产品运行 面向软件产品运行的定义如下： (1) 正确性： 指软件满足设计说明及用户预期目标的程度。 (2) 可靠性： 指软件按照设计要求， 在规定时间和条件下不出故障，持续运行的程度。,64,(3) 效率： 为了完成预定功能， 软件系统所需的计算机资源和程序

38、代码数量的程度。 (4) 完整性： 对非授权人访问软件或数据行为的控制程度。 (5) 可用性： 用户熟悉、 使用及准备输入和解释输出所需工作量的大小。 2) 面向软件产品修正 面向软件产品修正的定义如下： (1) 可维护性： 指找到并改正程序中的一个错误所需代价的程度。 (2) 可测试性： 指测试软件以确保其能够执行预定功能所需工作量的程度。 ,65,(3) 适应性： 指修改或改进一个已投入运行的软件所需工作量的程度。 3) 面向软件产品转移 面向软件产品转移的定义如下： (1) 可移植性： 指将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需的工作量。 (2) 可重

39、用性： 指一个软件（或软件的部件）能再次用于其他相关应用的程度。 (3) 可互操作性： 指将一个系统耦合到另一个系统所需的工作量。,66,通常，对以上各个质量特性直接进行度量是很困难的， 在有些情况下甚至是不可能的。因此，McCall定义了一些评价准则，使用它们对反映质量特性的软件属性分级，以此来估计软件质量特性的值。软件属性一般分级范围从0（最低）10（最高）。 主要评价准则定义如下： (1) 可跟踪性: 指跟踪一个设计说明或一个实际程序部件返回到需求的能力（可追溯）。 (2) 完备性： 指所需功能实现的程度。 (3) 一致性： 指在整个软件开发项目中使用统一的设计和文档编制技术的程度。 (

40、4) 安全性： 指防止软件受到意外的或蓄意的存取、 使用、 修改及毁坏，或防止失密的程度。 ,67,(5) 容错性： 是在系统出错时，能以某种预定方式，做出适当处理，得以继续执行和恢复系统的能力，它又称为健壮性。 (6) 准确性： 指能达到的计算或控制精度， 又称为精确性。 (7) 可审查性： 指检查与标准是否符合的难易程度。 (8) 可操作性： 指软件操作的难易程度。 (9) 可训练性： 指软件使新用户使用该系统的辅助程度。 (10) 简洁性： 在不复杂、 可理解的方式下， 定义和实现软件功能的程度。 (11) 简明性：又称可理解性，指软件易读的程度。 (12) 模块性：指软件系统内部接口达

41、到的高内聚、低耦合的程度。,68,(13) 自描述性：对软件功能进行自身说明的程度。 (13) 通用性：指软件功能覆盖面宽广的程度。 (15) 可扩充性：指软件的体系结构、 数据设计和过程设计的可扩充的程度。 (16) 硬件独立性：指不依赖于某个特定设备及计算机而能工作的程度。 (17) 通信共用性：指使用标准接口、协议和带宽的程度。 (18) 数据共用性：指使用标准数据结构和数据类型的程度。,69,2.2 ISO的软件质量评价模型 按照ISO/TC97/SC7/WG3/1985-1-30/N382， 软件质量度量模型由 3 层组成， 如图13.3所示。 高层是软件质量需求评价准则（SQRC）

42、。 中层是软件质量设计评价准则（SQDC）。 低层是软件质量度量评价准则（SQMC）。 ISO认为， 应对高层和中层建立国际标准，在国际范围内推广软件质量管理（SQM）技术, 而低层可由各使用单位视实际情况制定。ISO的 3 层次模型来自McCall等人的模型。高层、中层和低层分别对应于McCall模型中的特性、 度量准则和度量。 其中SQRC由8个元素组成。,70,图13.3 ISO的3层模型,71,按1991年ISO发布的ISO/IEC9126质量特性国际标准， SQRC已降为6个。在这个标准中，3 层次中的第一层称为质量特性，第二层称为质量子特性，第三层称为度量。 ,72,12.5.1

43、软件质量的特性,软件质量是指软件满足明确规定或隐含定义的需求的程度。 软件质量的要点： 软件功能必须满足用户规定的需求； 软件应遵守规定标准所定义的一系列开发准则； 软件应满足某些隐含的需求。如，可理解性、可维护性等。 软件质量的特性: 功能性 可靠性 易使用性 效率 可维护性 可移植性,73,12.5.2 软件质量保证措施,软件质量保证是软件工程管理的重要内容。 包括以下措施： 应用好的技术方法 测试软件 进行正式的技术评审 标准的实施 控制变更 程序正确性证明 记录、保存和报告软件过程信息,74,12.6 软件工程标准与软件文档,12.6.1 软件工程标准 1. 软件工程标准化的定义 2软

44、件工程标准的分类 FIPS 135是美国国家标准局发布的软件文档管理指南 NSAC-39是美国核子安全分析中心发布的安全参数显示系统的验证与确认 ISO 5807-985是国际标准化组织公布的信息处理数据流程图、程序流程图、程序网络图和系统资源图的文件编制符号及约定，已成为中华人民共和国国家标准GB1526-89。 3. 软件工程标准的层次 （1） 国际标准 （2） 国家标准 （3） 行业标准 （4） 企业规范 （5） 项目（课题）规范 12.6.2 软件文档的编写,75,.4 软件工程标准化与软件文档,软件工程标准化的定义 随着软件工程学的发展，人们对计算机软件的认识逐渐深入。软件工作的范围

45、从只是使用程序设计语言编写程序，扩展到整个软件生存期。诸如软件概念的形成、 需求分析、设计、实现、测试、安装和检验、运行和维护，直到软件淘汰（为新的软件所取代）。同时还有许多技术管理工作（如过程管理、 产品管理和资源管理）以及确认与验证工作（如评审和审计、 产品分析及测试等）常是跨软件生存期各个阶段的专门工作。 所有这些工作都应当逐步建立其标准或规范来。由于计算机发展迅速，未形成标准之前，在行业中先使用一些约定， 然后逐渐形成标准。 ,76,软件工程标准的类型也是多方面的。它可能包括过程标准（如方法、技术及度量等）、产品标准（如需求、 设计、 部件、 描述及计划报告等）、 专业标准（如职别、

46、道德准则、 认证、 特许及课程等）以及记法标准（如术语、 表示法及语言等）。 下面根据中国国家标准GB/T 15538-1995软件工程标准分类法给出软件工程标准的分类。 软件工程的标准主要有以下 3 个： (1) FIPS 135是美国国家标准局发布的软件文档管理指南（National Bureau of Standards，Guideline for Software Documentation Management， FIPS PUB 135， June 1984）。,77,(2) NSAC-39是美国核子安全分析中心发布的安全参数显示系统的验证与确认（Nuclear Safety Analysis Center， Verification and Validation fro Safety Parameter Displlay Systems， NASC-39， December 1981）。 (3) ISO 5807是国际标准化组织公布（现已成为中国的国家标准）的信息处理数据流程图、程序流程图、程序网络图和系统资源图的文件编制符号及约定。 这个图表不仅表明了