第九章 软件质量管理
9.1 软件质量的概念 GO
9.2 软件质量管理 GO
9.3 软件开发的标准与规范 GO
9.4 软件质量的综合评价 GO
9.1 软件质量的概念
9.1.1 软件质量的定义现代质量管理中，“质量”被定义为“用户的满意程度”。
M.J.Fisher将软件质量定义为：,所有描述计算机软件优秀程度的特性的组合。,所以计算机软件质量是软件的一些内部特性的组合。
参照 ANSI/IEEE Std 729-1983,软件质量又定义为：,与软件产品满足规定的和隐含的需求能力有关的特征和特性的全体,。 或者：
（ 1） 软件产品中能满足给定需求的性质和特性的总体,例如,符合规定说明；
（ 2） 软件具有所期望的各种属性组合的程度；
（ 3） 顾客或用户觉得软件满足其综合期望的程度；
（ 4） 软件的合成特性,它确定软件在使用中将满足顾客预期要求的程度 。
9.1.2 软件质量的主要特性指标
1.软件质量特性的定义通常,软件质量可由以下主要特性来定义：
（ 1） 功能性：软件所实现的功能达到它的设计规范和满足用户需求的程度；
（ 2） 效率：在规定条件下,用软件实现某种功能所需的计算机资源 （ 包括时间 ） 的有效程度；
（ 3） 可靠性：在满足一定条件的应用环境中,软件能够正常维持其工作的能力；
（ 4） 安全性：为了防止意外或人为的破坏,软件应具备的自身保护能力能力；
（ 5） 易使用性：对于一个软件,用户在学习,操作和理解过程中所做努力的程度；
9.1.2 软件质量的主要特性指标
（ 6） 可维护性：当环境改变或软件运行发生故障时,为了使其恢复正常运行所做努力的程度；
（ 7） 可扩充性：在功能改变和扩充情况下,软件能够正常运行的能力；
（ 8） 可移植性：为使一个软件从现有运行平台向另一个运行平台过度所做努力的程度
（ 9） 重用性：整个软件或其中一部分能作为软件包而被再利用的程度 。
以上所定义的软件质量特性是面向管理的观点，或者说是从使用者的观点引入的。从这个意义上讲，软件质量特性的实际价值就在于它体现了用户的观点。
2,软件生存期与质量特性从用户的角度看,软件的生存期可分为如下三个阶段：
1） 初期运用：运行新开发的软件产品 。
2） 维护与扩充：在运行过程中修改缺欠的内容；而且,
为了进一步的使用,需根据运行环境 （ 主要指应用环境和技术环境 ） 的变化做功能上和性能上的扩充 。
3） 移植和连接：把在原有平台上运行的软件向其它新的运行环境转移,或者组成软件包以便重用,或与其它软件进行连接 。
对于软件所需求的质量特性,在软件生存期的不同阶段中情况各有不同,要求也不一样,这可由下图说明 。
9.1.3 软件质量的二级特性指标从软件设计的观点出发,软件质量特性由下列二级质量特性所决定：
（ 1） 可追踪性：在特定的开发和运行环境下,提供从实现到用户需求可追溯的思路；
（ 2） 完备性：所需功能全部实现的软件属性；
（ 3） 一致性：提供软件从设计到实现技术和记号一致的属性；
（ 4） 精确性：在计算机输出时可提供用户所需求的精度；
（ 5） 简单性：在可理解的方式下,简化功能的定义和实现；
（ 6） 可操作性：决定与软件操作有关的规程,并提供有用的输入／输出；
（ 7） 培训性：提供对用户进行熟练操作培训的特性；
（ 8） 通信有效性：在执行各项功能时,使用最少的通信资源；
（ 9） 处理有效性：对于各种功能的实现,占用最少的处理时间；
（ 10） 设备有效性：对于各种功能的实现,占用最少的系统设备；
（ 11） 模块性：软件的内部结构应具有模块内高聚合,模块间低耦合的特性；
（ 12） 系统无关性：提供不依赖于运行环境 （ 主机,性能,操作系统,
外部设备 ） 的特性；
（ 13） 自描述性：对功能的实现可进行自我说明；
（ 14） 结构性：具有良好的软件结构；
（ 15） 清晰性：用不复杂的,可理解的方式对程序结构作出清楚明了的描述；
（ 16） 可扩充性：提供广泛兼容的数据存储结构和数据；
（ 17） 文档完备性：软件文档齐全,描述清楚,并符合国家标准；
（ 18） 健壮性：在意外情况下,能继续执行和快速恢复的能力；
（ 19） 公用性：采用公共的通信协议,数据表示和接口标准；
（ 20） 可见性：提供开发与操作状态可监控的特性；
（ 21） 保密性：提供对数据存储过程和传输过程的加密；
（ 22） 可防护性：授权管理与身份识别特性；
（ 23） 数据安全性：提供各类数据文件的安全备份特性；
（ 24） 通用性：在一定范围内,软件可以被普遍使用的特性 。
9.1.4 软件质量特性与二级特性的关系
Back
9.2 软件质量管理美国著名质量管理专家菲根堡姆 (A.V.Feigenbaum)把全面质量管理定义为：,为了能够在最经济的水平上、并考虑到充分满足顾客要求的条件下，进行市场研究、制造、销售和服务，把企业各部门的研制质量、维持质量和提高质量的活动，构成为一种有效的体系。,
TQC的四个基本要素是：产品质量（产品的适用性）；交货质量（时间、数量）；成本质量（价格）；售后服务质量。
这四个要素是构成商品竞争力的基础，也是经营管理过程中的重要目标。 TQC不仅仅是一种专业管理，而是紧密围绕着经营目标、即质量、利润、产量、交货期、售后服务以及企业和社会效益等进行综合管理的理论和模式。这就是 TQC的整体性和全面性。
全面质量管理包括以下几个方面内容：
管理的目标：任何管理都有设定目标，然后组织实施，以达到设定的目标。
对产品质量开展“三全”管理，即要求全体部门的全体员工都要参加质量管理，对产品形成的全过程都要实行管理。
在管理手段方面，要使用多种技术和管理工具。
建立质量保证体系。
9.2.1 软件质量管理的定义及意义软件质量管理可定义为：,为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动,。
软件质量管理包括保证软件质量的所有活动，这些活动不限于质量保证的功能。质量管理与质量保证含义不同，质量管理包括质量保证，它是一个更广泛、更综合的范畴。
为了保证软件质量，必须强调一开始就注意软件开发全过程的质量控制，尽量做到软件生存期每一阶段都能正确实行，
这就需要注意标准化，注意各种分析设计文档的编制和管理，
同时还要注意软件生存期每一阶段的评审，注意软件质量管理的能见度，特别是注意对软件生产人员的管理。从某种意义上说，软件的质量管理，实际上是对生产人员的管理。
9.2.2 软件质量管理的内容软件质量管理活动大致可以分为质量控制和质量设计，这两类活动内容在功能上是互补的。质量控制主要包括计划，
规程评价和产品评价。质量设计主要是指质量准则的运用。
1．质量控制
计划进行质量控制，必须首先制定一个软件质量管理计划，这个计划确定质量目标、确定在每个阶段为实现总目标所应达到的要求、对进度进行安排、确定所需人力、资源和成本等等，这个计划贯穿于整个软件的生存期中，并指导软件开发每个阶段的具体活动。
规程评价规程就是在软件生存期中应当遵循的一些政策、规则和标准的具体实施的描述，软件质量管理就是通过软件管理人员来监督和执行这些规程。在规格中也包括实行软件质量保证功能的描述，它们可以包括如下内容：
① 指示在何时、何地进行规程审计、文件审计和代理审计；
② 指示应当采集哪数据以及如何对其进行分析处理，例如，
在每次评审和测试中发现的错误如何进行修正；
③ 描述希望得到的质量度量；
④ 规定在项目的什么阶段进行评审以及进行什么形式的评审；
⑤ 规定在项目的什么阶段应当产生什么报告和计划；
⑥ 规定产品各方面测试应达到的水平。
产品评价软件产品评价的主要目的是确保产品和它的需求相符合，类似于硬件的产品检验，这种评价所用的方法可以是设计的走查（ walk-through）、代码的审计、测试结果的分析以及软件的质量度量和评估等。
２．质量设计在质量设计中应当确定该软件应该达到什么水平，并考虑高质量的软件如何设计以及如何通过测试来确定质量等问题。为些，在质量设计中，首先要指定期望软件产品具有的主要质量要素或属性，并尽量使它们的指标定量化。
质量管理活动的工具包括老七种与新七种，老七种工具是因果图法、排列图法、查表法、直方图法、散布图法、分层法及对策表法，新七种工具是关联图法,KJ法、系图法、矩阵图法、距阵数据分析法、过程决策程序图法（ PDPC）、箭头图法。
9.2.3 软件质量管理的主要活动
ISO 9000标准的一个重要的科学依据就是,质量形成于全生产过程中,,具体体现在事前计划,严格计划的实施,事后检查,总结分析并采取改进措施的循环模式上 。 那么怎样才能使影响软件产品质量的全部因素在产生过程中始终处于受控状态呢？ 首先我们要做的事情就是软件质量策划 。
1,软件质量策划
ISO 9000评价质量管理体系有效性的第一个方面,是组织的过程是否被恰当地识别和定义,并且形成文件化的程序,
亦即对组织的质量活动进行策划 。
具体对组织而言,质量策划的内容包括以下方面：
确定软件组织,适应其生产特点的组织结构,以及人员的安排和职责的分配 。 为建立软件组织的质量管理体系做最基础的准备 。
确定组织的质量管理体系目标,根据组织的商业需要和产品市场,确定选择 ISO 9000或 CMM作为其质量管理体系的符合性标准或模型 。
标识和定义组织的质量过程,亦即对组织的质量过程进行策划,确定过程的资源,主要影响因素,作用程序和规程,过程启动条件和过程执行结果规范等等 。
识别产品的质量特性,进行分类和比较,建立其目标,
质量要求和约束条件 。
策划质量改进的计划,方法和途径 。
质量管理体系策划的第一步就是识别并定义过程。软件组织的质量过程通常包含两种类型，即软件工程过程和组织支持过程。
软件工程过程软件工程过程，就是我们通常所说的软件生命周期中的活动，一般包括：软件需求分析、软件设计、编码、测试、
交付、安装和维护。
CMM中定义了三个关键过程区域来实现这两级过程策划：
① 组织过程定义（ Organization process definition）
② 软件项目策划（ Software project planning）
③ 软件产品工程（ Software product engjieering）
组织支持过程组织支持过程是软件组织为保证软件工程过程的实施和检查而建立的一组公共支持过程 。 通常这些支持过程不属于软件生命周期的活动 。 主要包括：
① 管理过程 。 包括：评审,检查,文档管理,不合格品管理,配置管理,内部质量审核和管理评审 。
② 支持过程 。 包括：合同评审,子合同管理,采购,培训,
进货检验,设备检验,度量和服务 。
在 CMM中,有一些对应的关键过程区域,如：
① 需求管理 （ Requirements management） 。
需求管理与 ISO 9001,2000的合同评审是对应的 。 其目的是保证客户的要求得到一致的理解,并且组织有能力满足客户的要求 。
② 软件子合同管理 （ Software subcontract management） 。
软件子合同管理对应于 ISO 9001,2000的采购过程控制 。 其目的是选择合适的分包商并对他们进行有效的管理 。
③ 软件质量保证 （ Software quality assurance） 。
软件质量保证对应于 ISO 9001,2000的设计,验证,确认,
过程检验和产品检验 。 其目的是通过对软件项目开发过程中适当的,可见的阶段性结果和最终产品进行检查,以实现对软件产品的质量管理 。
④ 软件配置管理 （ Sostware configuration management） 。
软件配置管理对应于 ISO 9001,2000的文件控制和产品标识 。
其目的是建立和维护软件项目产品在其整个生命周期中的完整性 。
⑤ 培训程序 （ Training program） 。
培训程序的目的是提高员工的技能和知识,使他们可以更有效地完成任务 。 培训是组织主动地,有计划地安排的活动,
但特殊的软件项目应该提出具体的培训要求 。
⑥ 同行评审 （ Peer reviews） 。
同行评审的目的是尽早和有效地清除软件产品中的缺陷 。 同行评审非常重要,并且可以调用软件产品工程描述的技术活动之外的其他有效的工程方法,如 Fagan风格的审查,结构化遍历及其它许多评审方法 。
2,软件质量控制与保证软件质量控制的主要目标就是按照质量策划的要求,对质量过程进行监督和控制 。 质量控制的主要内容有：
组织中的与质量活动有关的所有人员,按照职责分工进行质量活动 。
所有质量活动按照已经策划的方法,途径,相互关系和时间,有序地进行 。
对关键过程和特殊过程,实施适当的过程控制技术,如统计过程控制 （ SPC,Statistical Process Control） 以保证过程的稳定性,并在受控的情况下,提高过程的能力 。
所有质量活动的记录,都被完整,真实地保存下来,以供统计分析使用 。
对软件业而言,实施以上质量控制通常涉及的技术是：
软件配置管理软件配置管理的目的是,对软件生产过程中的所有有意义的中间产品形成文档,并以一种便于存取和检索,必要时可以逆向回溯的方式保存 。 同时配置管理还要保证文档的安全性,
保密性和及时性 。
软件过程流管理现代质量理论认为：“质量形成于过程”。软件过程流管理是软件质量控制中非常重要的环节。过程流管理的基本原则是：
① 按计划和设定条件启动和结束过程流中的质量活动
② 按照计划对中间产品进行验证，防止不合格的产品转入下道工序。
③ 记录和保持必要的过程活动的质量情况。
软件质量保证软件质量保证的目的是向组织的内部或外部提供信任依据。对内向组织的管理者表明组织的质量管理处于良好的状态，所有质量活动有效地运行；对外向顾客表明，组织有能力满足顾客的质量要求，并提供符合质量要求的产品和服务。
3,软件质量的度量和验证
软件质量度量现代质量管理理论,将质量的度量分为产品质量度量和过程质量度量两大类 。
① 产品质量度量通常产品质量度量依赖于具体的产品标准,通过测量获得产品质量特性的有关数据,辅以合适的统计技术以确定产品或同批产品是否满足了规定的质量要求 。
② 过程质量度量通过对软件产品设计,开发,检查,评审等过程的度量技术的使用,来度量软件过程的进度,成本是否按计划保证,
质量计划的变化频率,变化的诱因以及风险的管理等等 。
软件质量验证
ISO 9000,2000中对验证（ Verification）的定义是：
“通过提供客观证据对规定要求已得到满足的认定”。
CMM在关键过程域（ KPA）的公共特征（ Common
Feature） - 验证实现（ Verifying Implementation）中这样描述：“验证实现是保证活动按照已经建立的过程执行的一系列步骤，典型的验证有管理部门的评审、审核和软件质量保证”。
在软件质量管理中，对软件产品的验证通常包括：对各级设计的评审、检查，各个阶段的测试等。对软件过程的验证，则是对过程数据的评审和审核。
4,软件质量改进质量改进是现代质量管理的必然要求,ISO 9000要求组织定期进行内审和管理评审，采取积极有效的纠正预防措施，保持组织的质量方针和目标持续适合组织的发展和受益者的期望。
具体进行软件过程改进的活动包括：
度量与审核
纠正和预防措施
管理评审
9.2.4 全面质量管理全面质量管理包括以下几个方面：
（ 1）管理的目标：任何管理都要设定目标，然后组织实施，以达到所设定的目标；
（ 2）对产品质量开展“三全,管理，即要求全体部门，全体人员，对产品形成的全过程进行质量管理；
（ 3）在管理手段方面，要使用各种先进的管理思想、管理方法、管理手段、管理技术和管理工具；
（ 4）建立质量保证体系。
在这几个方面的内容中，质量管理应贯穿于软件产品形成的全过程中是尤为重要的内容，下面分为三个过程进行讲述。
1,软件开发过程的质量管理
软件生存期根据国家标准,计算机软件开发规范,,软件生命周期分为问题定义、
可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试、软件维护等 8个阶段 。
软件开发过程中质量管理的几个问题
① 通过软件质量度量技术进行质量控制软件质量度量技术的内容包括两项：第一，规定软件质量需求。第二，
在软件开发的每一阶段进行测量，并分析测量结果是否满足质量要求。
A,规定软件质量需求：规定质量需求是从质量角度对系统需求进行估价、选择质量特性、定义与这些特性相关的准则和适用的度量，并为每个质量特性确定质量标准。
B,通过质量度量进行监督、跟踪和控制,有了质量需求后，在软件开发过程中可应用质量度量方法来进行控制，质量度量一般采用三层模型，即质量特性，二级质量特性和度量。
② 建立设计评审制度在软件设计阶段与编码阶段，集体进行的检验活动尤为重要，通常称为设计评审。设计评审有两个含义：一是指在正式会议上，将一系统的初步的详细设计提交用户、顾客或有关人员供其评审或批准；二是指对现有的或提出的设计做正式的评审，其目的是找出可能会影响产品、过程或服务以及环境方面的设计缺陷并采取补救措施，或者是提供在功能，
性能和质量方面可能的改进方法。
2,软件产品复制过程的质量管理软件产品复制过程的质量管理与一般产品生产过程中的质量管理是非常相似的，应该遵循同样的生产现场质量控制的办法。
必须重视软件产品复制工序的建立软件产品的复制也应有生产工艺，需建立复制工序 。 各软件开发单位或组织都应根据自己的具体情况，结合所生产软件的产品特点，建立相应的复制工序。
必须重视软件产品复制技术文件的建立软件产品的复制技术文件是生产工人借以进行生产的必备的技术文件，
是软件产品的质量控制依据，它传达了软件产品介质复制品名的复制方法与质量检验标准等方面的信息。软件产品复制技术文件一般包括以下内容：
① 软件产品清单，产品名，各个部件名及内容等；
② 软件产品每一部件的复制方法；
③ 软件产品每一部件的质量标准及检验方法；
④ 软件产品的包装说明；
⑤ 软件产品的加密方法；
⑥ 介质的保存环境要求与工作环境要求。
必须重视软件产品介质的质量管理软件介质有源介质与目标介质两类，源介质是存放软件正本的介质，以此为兰本来进行软件产品的批量生产，目标介质是存放软件复制品的介质，是作为产品提供给用户的。软件介质的质量管理应与一般外购商品的质量管理相同，这里强调三点：
① 保证软件介质质量的关键是选择一个好的供应商；
② 要注意加强软件介质存放环境条件的改善，以保证软件介质的质量；
③ 要定期对源介质进行全面检查，因源介质并不能无限制地被复制，它也有一个使用期。
必须重视软件产品复制设备的质量管理软件产品的生产设备是保证软件复制工序能力的重要物质条件，软件产品的复制设备如计算机、拷贝机等应经常处于良好状态，因此必须采用先进的设备管理方法，搞好设备的定期维护、保养和检修。
软件产品复制过程的质量管理还有许多工作要做，它需要借鉴一般硬件产品的生产现场质量管理方法。更需要针对软件产品复制特点探索出一套新的管理方法，其中最重要的是需求收集和积累大量的资料、数据，在软件产品大批量生产的今天，应引起我们足够的重视。
2,软件产品使用过程的质量管理
软件产品使用过程质量管理的主要职能软件产品使用过程质量管理的主要职能是：
① 做好软件产品的销售工作，帮助用户正确购买；
② 做好软件产品的保管、发运工作；
③ 做好用户的技术服务、技术支持、技术咨询、技术培训等工作，保证使用效果；
④ 做好软件产品的日常维护工作，及时为用户更新版本；
⑤ 做好市场调查与分析，收集质量反馈信息，为新软件的开发提供准确可靠的情报；
⑥ 认真处理软件产品的质量问题，对有质量问题的软件应做到保换、保修、保退，树立质量信誉。
Back
软件产品使用过程中的质量管理工作在软件使用过程中质量管理要做到以下几点。
① 在软件产品的销售中应做到,广告文件准备充分，内容简洁、清晰、明了；销售时应耐心向用户解释，宣传；现场演示，试用。
② 软件产品的技术服务应包括：用户培训。应针对不同用户，不同层次；技术支持与技术咨询。应做到有求必应，热情接待。
③ 软件产品的维护工作应做到：制度化。有专人负责，定期督促与检查；规范化，维护工作应有标准的工作程序，有严格的文档记录。
④ 做好市场调查
9.3 软件开发的标准与规范
9.3.1 软件生产标准化的意义搞好软件开发标准化的工作，其意义在于：
1,软件生产标准化是推动我国软件产业按系统工程规律健康发展的指南。 软件项目的开发是一项复杂的系统工程，
要运用系统的思想和系统工程的方法，采用标准化的作业方式和手段，对系统开发的全过程进行技术指导与管理。
2,软件生产标准化是软件资源共享的前提 。 制定一套统一的数据规范，统一的分类编码，统一的交换格式，统一的名词术语，统一的文件格式和统一的指标体系，并在软件开发和使用维护过程中严格执行这一套大家所公认的相对稳定的标准规范，只有这样才能实现软件资源的充分共享。
3,软件生产的标准化是提高软件质量的重要保证 。软件质量的度量标准可以对一软件系统建立一些质量需求，在软件生存期的每一个阶段利用这些标准和质量需求指导软件的开发、测试和维护，以获得高质量的软件和质量测定结果。
4,软件生产标准化是加速建立我国软件产业的强大动力 。
9.3.2 软件开发标准与规范在软件开发的军用标准方面比较著名的是美国国防部的标准 DOD-STD-
1679A和 DOD-STD-2167。
IEEE（美国电气和电子工程师学会）和 ISO（国际标准化组织）的软件工程标准化工作方面的标准：
ANSI/IEEE Std 729-1983 软件工程术语标准词汇
ANSI/IEEE Std 730-1984 软件质量保证计划标准
IEEE Std 828-1983 软件配置管理计划标准
ANSI/IEEE Std 829-1983 软件测试文档标准
IEEE Std 830 –1984 软件需求规范说明指南
IEEE Std 983-1985 软件质量保证计划指南
ISO DP 8631 程序的构造及其使用约定其中,IEEE标准 730是 IEEE组织制定的一个软件质量工业标准。
我国的计算机与信息处理标准化技术委员会软件工程分技术委员会已开始进行这项工作，并且已制定了一些软件方面的标准（草案）。下 图列举了软件工程标准体系的大致情况。
9.3.3 文件标准与规范软件文件标准规定了软件开发过程中所应编制的软件文件的种类、名称、
及内容要求，以便有一个统一的编写格式，便于交流和学习。我国正式的国家标准是：
① 计算机软件开发规范,GB 8566-88
② 计算机软件产品开发文件编制指南,GB8567-88
③ 计算机软件工程术语标准
④ 计算机软件测试文件编制规范,GB 9386-88
⑤ 计算机软件配置管理计划规范,GB/T 12505-90
⑥ 计算机软件质量保证计划规范,GB/T 12504-90
⑦ 计算机软件需求规范说明编制指南,BG 9385-88
⑧ 数据流图,程序流图,系统流程图,程序网络图和系统资源图的文件编制符号及约定。
国家标准,计算机软件产品开发文件编制指南,是一份指导性文件。它建议在软件的开发过程中编制下述 14个文件。即：
① 可行性研究报告 ⑨ 操作手册
② 项目开发计划 ⑩ 模块开发卷宗
③ 软件需求说明书 ⑾ 测试计划
④ 数据要求说明书 ⑿ 测试分析报告
⑤ 总体设计说明书 ⒀ 开发进度表
⑥ 详细设计说明书 ⒁ 项目开发总结。
⑦ 数据库设计说明书
⑧ 用户手册该指南给出了这 14个文件的编制提示，它同时也是这 14个文件编写质量的检验准则。
1,可行性研究报告表 9.2可行性研究报告
1引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2可行性研究的前提
2.1要求
2.2目标
2.3条件 '假定和限制
2.4进行可行性研究的方法
2.5评价尺度
3对现有系统的分析
3.1数据流程和处理流程
3.2工作负荷
3.3费用开支
3.4人员
3.5设备
3.6局限性
4所建议的系统
4.1对所建议系统的说明
4.2数据流程和处理流程
4.3改进之处
4.4影响
4.4.1对设备的影响
4.4.2对软件的影响
4.4.3对用户单位机构的影响
4.4.4对系统运行的影响
4.4.5对开发的影响
4.4.6对地点和设施的影响
4.4.7对经费开支的影响
4.5局限性
4.6技术条件方面的可行性
5可选择的其它系统方案
5.1可选择的系统方案 1
5.2可选择的系统方案 2
………
6投资及收益分析
6.1支出
6.1.1基本建设投资
6.1.2其它一次性支出
6.1.3非一次性支出
6.2收益
6.2.1一次性收益
6.2.2非一次性收益
6.2.3不可定量的收益
6.3收益 /投资比
6.4投资回收周期
6.5敏感性分析
7社会条件方面的可行性
7.1法律方面的可行性
7.2使用方面的可行性
8结论可行性研究报告的目的是：说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性，论述为了合理地达到开发目标而可能选择的各种方案，说明并论证所选定的方案。可行性研究报告的编写内容见表 9.2。
2．项目开发计划编制项目开发计划的目的是用文件的形式，将在开发过程中各项工作的负责人员、开发进度、经费预算、所需软硬件条件等问题作出的安排记录下来，
以便根据本计划开展和检查项目的开发工作。编制内容要求如表 9.3。
表 9.3项目开发计划
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 项目概述
2.1工作内容
2.2主要参加人员
2.3产品及成果
2.3.1程序
2.3.2文件
2.3.3服务
2.3.4非移交产品
2.4验收标准
2.5完成项目的最迟期限
2.6本计划的审查者与批准者
3 实施总计划
3.1工作任务的分解
3.2接口人员
3.3进度
3.4预算
3.5关键问题
4 支持条件
4.1计算机系统支持
4.2需要用户承担的工作
4.3需由外单位提供的条件
5 专题计划要点
3．软件需求说明书软件需求说明书的编制是为了使用户和软件开发人员双方对该软件的初始规定有一个共同的理解，使之成为整个软件开发工作的基础。其内容要求见表 9.4。
表 9.4软件需求说明书
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 任务概述
2.1目标
2.2用户的特点
2.3假定的约束
3 需求规定
3.1对功能的规定
3.2对性能的规定
3.2.1精度
3.2.2时间特性要求
3.2.3灵活性
3.3输入输出要求
3.4数据管理能力要求
3.5故障处理要求
3.6其它专门要求
4 运行环境规定
4.1设备
4.2支撑软件
4.3接口
4.4控制
4．数据要求说明书数据要求说明书的编制目的是为了向整个软件开发时期提供关于被处理数据的描述和数据采集要求的技术信息，其内容要求列于表 9.5。
表 9.5数据要求说明书
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 数据的逻辑描述
2.1静态数据
2.2动态输入数据
2.3动态输出数据
2.4内部生成数据
2.5数据约定
3 数据的采集
3.1要求和范围
3.2输入的承担者
3.3处理
3.4影响
5．总体设计说明书总体设计说明书又称为概要设计说明书，是指项目系统，编制目的是说明对项目系统的设计考虑，包括基本处理流程、组织结构、模块结构、功能配置、接口设计、运行设计、系统配置、数据结构设计和出错处理设计等，为程序的详细设计提供基础。其内容要求见表 9.6。
表 9.6概要设计说明书
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 总体设计
2.1运行环境
2.2运行环境
2.3基本设计概念和处理流程
2.4结构
2.5功能需求与程序的关系
2.6人工处理过程
2.7尚未解决的问题
3 接口设计
3.1用户接口
3.2外部接口
3.3内部接口
4 运行设计
4.1运行模块组合
4.2运行控制
4.3运行时间
5 系统数据结构设计
5.1逻辑结构设计要点
5.2物理结构设计要点
5.3数据结构设计要点
6 系统出错处理设计
6.1 出借信息
6.2补救措施
6.3系统维护设计
6．详细设计说明书详细设计说明书又称为程序设计说明书，编制目的是说明一个软件系统各个层次中的每一个程序（模块）的设计考虑。如果软件系统比较简单，层次少，本文件可以不单独编写，有关内容可并入总体设计说明书。详细设计说明书的内容要求见表 9.7。
表 9.7详细设计说明书
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 程序系统的组织结构
3 程序 1(标识符 )设计说明
3.1程序描述
3.2功能
3.3性能
3.4输入项
3.5输出项
3.6算法
3.7流程逻辑
3.8接口
3.9存储分配
3.10注释设计
3.11限制条件
3.12测试计划
3.13尚未解决的问题
4 程序 2(标识符 )设计说明
7．数据库设计说明书数据库设计说明书的编制目的是对于设计中的数据的所有标识、逻辑结构和物理结构作出具体的设计规定。内容要求见表 9.8。
表 9.8数据库设计说明书
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 外部设计
2.1 标识符和状态
2.2使用它的程序
2.3约定
2.4专门指导
2.5支撑软件
3 结构设计
3.1概念结构设计
3.2逻辑结构设计
3.3物理结构设计
4 运用设计
4.1数据字典设计
4.2安全保密设计
8．用户手册用户手册的编制是使用非专业术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法，使用户通过本手册能够了解该软件的用途，并能够确定在什么情况下、如何使用它。具体的内容要求见表 9.9。
表 9.9用户手册
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 用途
2.1功能
2.2性能
2.2.1精度
2.2.2时间特性
2.2.3灵活性
3 运行环境
3.1硬环境
3.2支撑软件
3.3数据结构
4 使用过程
4.1安装与初始化
4.2输入
4.2.1输入数据的现实背景
4.2.2输入格式
4.2.3输入举例
4.3输出
4.3.1输出数据的现实背景
4.3.2输出格式
4.3.3输出举例
4.4文卷查询
4.5出错处理与恢复
4.6终端操作
9．操作手册操作手册的编制是为了向操作人员提供该软件每个运行的具体过程的有关知识，包括操作方法的细节。内容要求见表 9.10。
表 9.10操作手册
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 软件概述
2.1软件的结构
2.2程序表
2.3文卷表
3 安装与初始化
4 运行说明
4.1运行表
4.2运行步骤
4.3运行 1(标识符 )说明
4.3.1运行控制
4.3.2操作信息
4.3.3输入 -输出文卷
4.3.4输出文段
4.3.5输出文段的复制
4.3.6启动恢复过程
4.4运行 2(标识符 )说明
…………
5 非常规过程
6远程操作
10．模块开发卷宗模块开发卷宗是在模块开发过程中逐步编写出来的，每完成一个模块或一组密切相关的模块的复审时编写一份，应该把所有的模块开发卷宗汇集在一起，编写的目的是记录和汇总低层次开发的进度和结果，以便于对整个系统开发工作进行管理的复审，并为将来的维护提供有用的技术信息，
具体内容要求见表 9.11。
表 9.11 模块开发卷宗
1 标题
2 模块开发情况表 （ 见附表 ）
3 功能说明
4 设计说明
5 源代码清单
6 测试说明
7 复审的结论
11．测试计划测试是指整个软件系统的组装测试和确认测试，本文件的编制是为了提供一个对该软件的测试计划，包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整体理方法及评价准则。具体内容见表
9.12。
表 9.12测试计划
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 计划
2.1软件说明
2.2测试内容
2.3测试 1(标识符 )
2.3.1进度安排
2.3.2条件
2.3.3测试资料
2.3.4测试培训
2.4测试 2(标识符 )
3 测试设计说明
3.1测试 1(标识符 )
3.1.1控制
3.1.2输入
3.1.3输出
3.1.4过程
3.2测试 2(标识符 )
…………
4 评价准则
4.1范围
4.2数据整理
4.3尺度
12．测试分析报告测试分析报告的编写是为了把组装测试和确认测试的结果、发现的问题、以及分析结果写成文件形式加以保存。具体编写内容要求见表 9.13。
表 9.13测试分析报告
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 测试概要
3 测试结果及发现
3.1测试 1(标识符 )
3.2测试 2(标识符 )
…………
4 对软件功能的结论
4.1功能 1(标识符 )
4.1.1 能力
4.1.2限制
4.2 功能 2(标识符 )
…………
5 分析摘要
5.1能力
5.2缺陷和限制
5.3建议
5.4评价
6 测试资源消耗
13．开发进度月报开发进度月报的编制目的是及时向有关管理部门汇报项目开发的进度和情况，以便及时发现和处理开发过程中出现的问题。一般来说，开发进度月报是以项目组为单位每月编写的。具体内容要求见表 9.14。
表 9.14开发进度月报
1 标题
2 工程进度与状态
2.1进度
2.2状态
3 资源耗用与状态
3.1资源耗用
3.1.1工时
3.1.2机时
3.2状态
4 经费支出与状态
4.1经费支出
4.1.1支出性费用
4.1.2设备购置费
4.2状态
5 下个月的工作计划
6 建议
14．项目开发总结报告项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发成果以及对整个开发工作的各个方面的评价。具体内容要求见表 9.15。
表 9.15项目开发总结报告
1引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 实际开发结果
2.1产品
2.2主要功能和性能
2.3基本流程
2.4进度
2.5费用
3 开发工作评价
3.1对生产效率的评价
3.2对产品质量的评价
3.3对技术方法的评价
3.4出错原因的分析
4 经验与教训另外，必须对软件文件的修改活动进行严格的管理，要防止修改后所带来的不一致性以及可能对项目开发所产生的影响。修改前要提出书面的修改意见，经项目负责人或有关人员评议，审核后，经批准方可实施修改。修改过程中所产生的文件也就妥善保管，以备后查。
9.4 软件质量的综合评价
9.4.1 软件质量评价的目的
Boehm等人于 1976年提出了定量地评价软件质量的概念。并且首次提出了软件质量度量的层次模型。 1978年 Walters和 McCall提出了从软件质量要素（ factor）、准则（ riteria）到度量（ metric）的三层次式的软件质量度量模型。
G.Murine基于上述两个人的工作提出了 SQM（ Software Quality Metrics）
软件质量度量技术，用于定量地评价软件质量，且已付诸实用。
从用户的观点出发，运用新的方法和技术，从整体上来度量和评价软件的质量，确保软件产品质量特性的高标准，降低软件开发成本，已成为软件质量综合评价的主要目的之一。
9.4.2 软件质量综合评价的内容
1,规定软件质量需求规定软件质量需求是在综合考虑了要素对软件的重要性和要素间的关系后做出的，并为以后的软件质量度量建立了对照的依据。规定软件质量需求分三个部分：
决定软件质量要素
<1>,为软件定一个原始的质量指标，质量指标反映了要素对软件的相对重要性。指标通常分为三级：
A：说明这个要素对软件来说极其重要；
B：说明这个要素对软件来说是重要的；
C：说明这个要素对软件来说比较重要。
<2>,定量化地表示要素与软件质量的关系，指标应该用一个数值范围来表示。如果 x代表质量指标的值，建议 A表示,0.9≤x≤1,B表示：
0.8≤x<0.9,C表示 0.6≤x<0.8 。这样，在为软件的每个要素打分后，可以对照为软件制定的质量指标，看看软件产品的质量是否达到了要求。
<3>,考虑 3个基本质量要素对其它要素的影响，这 3个基本要素是可靠性、
功能性和可维护性。
<4>,考虑了基本的质量要素对其它要素的影响后，应该对 原始的质量指标 进行修正。
<5>,在为要素分配最终的质量指标时，还应当考虑要素间有利的和不利的关系，以决定为要素所定的指标是否可以达到。如果否定的指标不能达到，还应考虑对 <4>所修正的质量指标 进行修改，以决定最终的指标。
决定准则及其权值对每个建立了质量指标的要素（没有建立质量指标的要素不必这样），
查阅表 9.23，找出属于这个要素的所有准则（即表 9.23中打钩的准则），
把它们标出来。然后，再为这些准则加权。准则的权说明了准则和要素的特殊关系，即准则在要素中所占的比重。
加权的结果形式如矩陈 M：
nlnn
l
l
mmm
mmm
mmm
n
M
21
22221
11211
..
3
2
1
加权者加权者加权者加权者
：矩阵
l
则准则准则准
21
其中 mij代表 i个打分员为第 j个准则加的权。
对矩阵 M作适当变换，可以得到 W=(W1,W2,…WL)。其中 Wj是第 j个准则的权,Wj的计算方法如下：
决定度量和度量问题对于每个权值不为 0的准则，根据度量工作表，在考虑了系统环境及应用的特性后，为每个准则选取合适的度量，然后，再为每个度量选取合适的度量元。
l
j
jj Wa
1
n
j
l
j
ijijj mmnW
1 1
1
在考虑了准则与要不比关系后得到的权值为 Wˊ 。 Wˊ= （ Wˊ 1，
Wˊ 2,…,Wˊ l） 。如果某个要素有 l个准则，这 l个准则对某个子系统来说得分分别是 a1,a2,…,al，则这个要素对该子系统来说得分为：
2 软件质量评价方法评价软件达到的质量水平必须在每个开发阶段 （ 包括需求分析,概要设计,详细设计,实现,组装测试,确认测试,使用和维护 ） 的最后进行,
评价的依据是每个开发阶段所应提交的文件,这些文件见下表 。
表 9.30每个阶段应提交的文件评价产品达到的质量水平的过程如图 9-6所示：
软件质量评价方法分为两个部分：
1,计算要素分数要素的分数是通过度量元,度量,准则的分数得到的,要知道要素的分数首先应知道度量元的分数,度量元的分数是通过向软件提供度量工作表上的度量问题取得的 。
把对度量问题的回答转变为度量元的分数,进而算出度量,
准则和要素的分数,需要使用要素打分表 。 在每个开发阶段,
应该为每个要素准备一张要素记分表 （ 要素记分表包括了每个要素的所有准则 ） 。
度量分数是度量元分数的算术平均值 。 准则的分数是度量分数的算术平均值 。
2,分析要素分数前面计算的是每个子系统的质量要素分数,还应当把子系统的质量要素分数转化为系统的质量要素分数,此过程可分成 3步,（ 1） 找出与该要素有关的子系统； （ 2） 根据子系统的大小为子系统加权； （ 3） 把要素在每个有关的子系统中得到的分数与该子系统的权值相乘再全部相加即得到该要素在系统中的分数 。
在坐标纸上建立一个 x-y坐标系,x方向代表软件开发阶段,
y方向代表每个软件开发阶段中通过评价得到的分数,据此描出曲线,就可以看出每个要素分数的发展倾向 。
为每个要素规定的指标化作一个数值范围 （ 如指标 A可看作 0.9-1,指标 B可看作 0.8-0.9等等 ）,并把它们标在为这个要素建立的坐标系上 。 这样就可以看出要素的分数是否落在为要素规定的质量指标的数值范围内 。
在分析了要素分数不符合需求的原因以后，应该把这些原因归类，以便对软件开发中存在的问题有个清楚的认识。在综合考虑了系统的需求和限制后，提出解决问题的方案。下图是分析要素分数流程图。
9.4.3 软件过程成熟度模型 (Capability Maturity Model)
1．软件机构的成熟性对于不同的软件开发机构，在组织人员完成软件项目中所依据的管理策略有很大的差别，因而软件项目所遵循的软件过程也有很大差别。在此，可用软件机构的成熟度（ Maturity）加以区别。
不成熟软件机构的特征,
软件过程一般在项目进行中由参与开发的人员临时确定。有时即使确定了，实际上也并不严格执行；
软件机构是反应型的，管理人员经常要集中精力去应付难以预料的突发事件；
项目的进度和经费预算由于估计的不切实际，所以常常突破。在项目进度拖延，交付时间紧迫的情况下，往往不得不削减软件的功能，降低软件的质量；
产品质量难以预测。质量保证活动，如质量评审、测试等，常被削弱或被取消。
成熟软件机构具有的特征：
建立了机构级的软件开发和维护过程。软件人员对其有较好的理解。
一切活动均遵循过程的要求进行，做到工作步骤有次序，且有章可循；
软件过程必要时可做改进，但需在经小型试验和成本 -效益分析的基础上进行；
软件产品的质量和客户对软件产品的满意程度不是由开发人员，而是由负责质量保证的经理负责监控；
项目进度和预算是根据以往项目取得的实践经验确定，因而比较符合实际情况。
2．软件过程成熟度模型
1987年，美国卡内基 -梅隆大学软件工程研究所 SEI受美国国防部资助，
提出了软件机构的能力成熟度模型 CMM。
CMM将软件过程的成熟度分为 5个等级，如下图所示。以下给出具有 5
个等级的软件机构的特征：
初始级 （ initial）
工作无序,项目进行过程中常放弃开始制定的计划；
管理无章,缺乏健全的管理制度；
开发项目成效不稳定,产品的质量和性能严重依赖于个人的能力和行为 。
可重复级 （ repeatable）
管理制度化,建立了基本的管理制度和规程,管理工作有章可循；
初步实现标准化,开发工作交好地实施标准；
变更均依法进行,做到基线化；
稳定可跟踪,新项目的计划和管理基于过去的经验,具有重复以前成功项目的环境和条件 。
已定义级 （ defined）
开发过程,包括技术工作和管理工作,均已实现标准化,文档化；
建立了完善的培训制度和专家评审制度；
全部技术活动和管理活动均稳定实施；
项目的质量,进度和费用均可控制；
对项目进行中的过程,岗位和职责均有共同的理解 。
已管理级 （ managed）
产品和过程已建立了定量的质量目标；
过程中活动的生产率和质量是可度量的；
已建立过程数据库；
已实现项目产品和过程的控制；
可预测过程和产品质量趋势,如预测偏差,实现及时纠正 。
优化级 （ optimizing）
可集中精力改进过程,采用新技术,新方法；
拥有防止出现缺陷,识别薄弱环节以及加以改进的手段；
可取得过程有效性的统计数据,并可据此进行分析,从而得出最佳方法 。
3．关键过程领域除去初始级以外，其他 4级都有若干个引导软件机构改进软件过程的要点，称为关键过程领域（ KPA Key Process Area）。每一个关键过程领域是一组相关的活动，成功地完成这些活动，将会对提高过程能力起重要作用，下图给出了各成熟度等级对应的关键过程领域。
4．成熟度提问单为了把上述过程成熟度分级的方法推向实用化，需要为其提供具体的度量标尺。这个度量标尺就是成熟度提问单。 CMM
在以下七个方面列出了大量的问题，每个问题都可针对特定的被评估软件机构给出肯定或否定的回答。提问单涉及的方面包括组织结构资源、人员及培训技术、管理文档化标准及工作步骤、过程度量数据管理和数据分析、过程控制。
Back
5．利用 XMM对软件机构进行成熟度评估评估过程有以下几步：
建立评估组：评估组成员应对软件过程,软件技术和应用领域很熟悉,
有实践经验,能够提出见解 。
评估组准备：评估组具体审定评估的问题,决定对每一个问题要求展示哪些材料和工具 。
项目准备：评估组与被评估机构领导商定选择哪些处在不同开发阶段的项目和典型的标准实施作为评估对象 。 将评估时间安排通知被评估项目负责人 。
进行评估：对被评估机构的管理人员和项目负责人说明评估过程 。 评估组与项目负责人一起就所列出的问题逐一对照审查,保证对问题的回答有一致的解释,从而取得一组初始答案 。
初评：对每个项目和整个机构做出成熟度等级初评。
讨论结果：讨论初评结果 。 使用备用资料及工具演示,可进一步证实某些问题的答案,从而决定可能的成熟度等级 。
给出最后的结论：由评估组综合问题的答案,后继问题的答案,以及背景依据,作出最终评估结论 。
9.1 软件质量的概念 GO
9.2 软件质量管理 GO
9.3 软件开发的标准与规范 GO
9.4 软件质量的综合评价 GO
9.1 软件质量的概念
9.1.1 软件质量的定义现代质量管理中，“质量”被定义为“用户的满意程度”。
M.J.Fisher将软件质量定义为：,所有描述计算机软件优秀程度的特性的组合。,所以计算机软件质量是软件的一些内部特性的组合。
参照 ANSI/IEEE Std 729-1983,软件质量又定义为：,与软件产品满足规定的和隐含的需求能力有关的特征和特性的全体,。 或者：
（ 1） 软件产品中能满足给定需求的性质和特性的总体,例如,符合规定说明；
（ 2） 软件具有所期望的各种属性组合的程度；
（ 3） 顾客或用户觉得软件满足其综合期望的程度；
（ 4） 软件的合成特性,它确定软件在使用中将满足顾客预期要求的程度 。
9.1.2 软件质量的主要特性指标
1.软件质量特性的定义通常,软件质量可由以下主要特性来定义：
（ 1） 功能性：软件所实现的功能达到它的设计规范和满足用户需求的程度；
（ 2） 效率：在规定条件下,用软件实现某种功能所需的计算机资源 （ 包括时间 ） 的有效程度；
（ 3） 可靠性：在满足一定条件的应用环境中,软件能够正常维持其工作的能力；
（ 4） 安全性：为了防止意外或人为的破坏,软件应具备的自身保护能力能力；
（ 5） 易使用性：对于一个软件,用户在学习,操作和理解过程中所做努力的程度；
9.1.2 软件质量的主要特性指标
（ 6） 可维护性：当环境改变或软件运行发生故障时,为了使其恢复正常运行所做努力的程度；
（ 7） 可扩充性：在功能改变和扩充情况下,软件能够正常运行的能力；
（ 8） 可移植性：为使一个软件从现有运行平台向另一个运行平台过度所做努力的程度
（ 9） 重用性：整个软件或其中一部分能作为软件包而被再利用的程度 。
以上所定义的软件质量特性是面向管理的观点，或者说是从使用者的观点引入的。从这个意义上讲，软件质量特性的实际价值就在于它体现了用户的观点。
2,软件生存期与质量特性从用户的角度看,软件的生存期可分为如下三个阶段：
1） 初期运用：运行新开发的软件产品 。
2） 维护与扩充：在运行过程中修改缺欠的内容；而且,
为了进一步的使用,需根据运行环境 （ 主要指应用环境和技术环境 ） 的变化做功能上和性能上的扩充 。
3） 移植和连接：把在原有平台上运行的软件向其它新的运行环境转移,或者组成软件包以便重用,或与其它软件进行连接 。
对于软件所需求的质量特性,在软件生存期的不同阶段中情况各有不同,要求也不一样,这可由下图说明 。
9.1.3 软件质量的二级特性指标从软件设计的观点出发,软件质量特性由下列二级质量特性所决定：
（ 1） 可追踪性：在特定的开发和运行环境下,提供从实现到用户需求可追溯的思路；
（ 2） 完备性：所需功能全部实现的软件属性；
（ 3） 一致性：提供软件从设计到实现技术和记号一致的属性；
（ 4） 精确性：在计算机输出时可提供用户所需求的精度；
（ 5） 简单性：在可理解的方式下,简化功能的定义和实现；
（ 6） 可操作性：决定与软件操作有关的规程,并提供有用的输入／输出；
（ 7） 培训性：提供对用户进行熟练操作培训的特性；
（ 8） 通信有效性：在执行各项功能时,使用最少的通信资源；
（ 9） 处理有效性：对于各种功能的实现,占用最少的处理时间；
（ 10） 设备有效性：对于各种功能的实现,占用最少的系统设备；
（ 11） 模块性：软件的内部结构应具有模块内高聚合,模块间低耦合的特性；
（ 12） 系统无关性：提供不依赖于运行环境 （ 主机,性能,操作系统,
外部设备 ） 的特性；
（ 13） 自描述性：对功能的实现可进行自我说明；
（ 14） 结构性：具有良好的软件结构；
（ 15） 清晰性：用不复杂的,可理解的方式对程序结构作出清楚明了的描述；
（ 16） 可扩充性：提供广泛兼容的数据存储结构和数据；
（ 17） 文档完备性：软件文档齐全,描述清楚,并符合国家标准；
（ 18） 健壮性：在意外情况下,能继续执行和快速恢复的能力；
（ 19） 公用性：采用公共的通信协议,数据表示和接口标准；
（ 20） 可见性：提供开发与操作状态可监控的特性；
（ 21） 保密性：提供对数据存储过程和传输过程的加密；
（ 22） 可防护性：授权管理与身份识别特性；
（ 23） 数据安全性：提供各类数据文件的安全备份特性；
（ 24） 通用性：在一定范围内,软件可以被普遍使用的特性 。
9.1.4 软件质量特性与二级特性的关系
Back
9.2 软件质量管理美国著名质量管理专家菲根堡姆 (A.V.Feigenbaum)把全面质量管理定义为：,为了能够在最经济的水平上、并考虑到充分满足顾客要求的条件下，进行市场研究、制造、销售和服务，把企业各部门的研制质量、维持质量和提高质量的活动，构成为一种有效的体系。,
TQC的四个基本要素是：产品质量（产品的适用性）；交货质量（时间、数量）；成本质量（价格）；售后服务质量。
这四个要素是构成商品竞争力的基础，也是经营管理过程中的重要目标。 TQC不仅仅是一种专业管理，而是紧密围绕着经营目标、即质量、利润、产量、交货期、售后服务以及企业和社会效益等进行综合管理的理论和模式。这就是 TQC的整体性和全面性。
全面质量管理包括以下几个方面内容：
管理的目标：任何管理都有设定目标，然后组织实施，以达到设定的目标。
对产品质量开展“三全”管理，即要求全体部门的全体员工都要参加质量管理，对产品形成的全过程都要实行管理。
在管理手段方面，要使用多种技术和管理工具。
建立质量保证体系。
9.2.1 软件质量管理的定义及意义软件质量管理可定义为：,为了确定、达到和维护需要的软件质量而进行的所有有计划、有系统的管理活动,。
软件质量管理包括保证软件质量的所有活动，这些活动不限于质量保证的功能。质量管理与质量保证含义不同，质量管理包括质量保证，它是一个更广泛、更综合的范畴。
为了保证软件质量，必须强调一开始就注意软件开发全过程的质量控制，尽量做到软件生存期每一阶段都能正确实行，
这就需要注意标准化，注意各种分析设计文档的编制和管理，
同时还要注意软件生存期每一阶段的评审，注意软件质量管理的能见度，特别是注意对软件生产人员的管理。从某种意义上说，软件的质量管理，实际上是对生产人员的管理。
9.2.2 软件质量管理的内容软件质量管理活动大致可以分为质量控制和质量设计，这两类活动内容在功能上是互补的。质量控制主要包括计划，
规程评价和产品评价。质量设计主要是指质量准则的运用。
1．质量控制
计划进行质量控制，必须首先制定一个软件质量管理计划，这个计划确定质量目标、确定在每个阶段为实现总目标所应达到的要求、对进度进行安排、确定所需人力、资源和成本等等，这个计划贯穿于整个软件的生存期中，并指导软件开发每个阶段的具体活动。
规程评价规程就是在软件生存期中应当遵循的一些政策、规则和标准的具体实施的描述，软件质量管理就是通过软件管理人员来监督和执行这些规程。在规格中也包括实行软件质量保证功能的描述，它们可以包括如下内容：
① 指示在何时、何地进行规程审计、文件审计和代理审计；
② 指示应当采集哪数据以及如何对其进行分析处理，例如，
在每次评审和测试中发现的错误如何进行修正；
③ 描述希望得到的质量度量；
④ 规定在项目的什么阶段进行评审以及进行什么形式的评审；
⑤ 规定在项目的什么阶段应当产生什么报告和计划；
⑥ 规定产品各方面测试应达到的水平。
产品评价软件产品评价的主要目的是确保产品和它的需求相符合，类似于硬件的产品检验，这种评价所用的方法可以是设计的走查（ walk-through）、代码的审计、测试结果的分析以及软件的质量度量和评估等。
２．质量设计在质量设计中应当确定该软件应该达到什么水平，并考虑高质量的软件如何设计以及如何通过测试来确定质量等问题。为些，在质量设计中，首先要指定期望软件产品具有的主要质量要素或属性，并尽量使它们的指标定量化。
质量管理活动的工具包括老七种与新七种，老七种工具是因果图法、排列图法、查表法、直方图法、散布图法、分层法及对策表法，新七种工具是关联图法,KJ法、系图法、矩阵图法、距阵数据分析法、过程决策程序图法（ PDPC）、箭头图法。
9.2.3 软件质量管理的主要活动
ISO 9000标准的一个重要的科学依据就是,质量形成于全生产过程中,,具体体现在事前计划,严格计划的实施,事后检查,总结分析并采取改进措施的循环模式上 。 那么怎样才能使影响软件产品质量的全部因素在产生过程中始终处于受控状态呢？ 首先我们要做的事情就是软件质量策划 。
1,软件质量策划
ISO 9000评价质量管理体系有效性的第一个方面,是组织的过程是否被恰当地识别和定义,并且形成文件化的程序,
亦即对组织的质量活动进行策划 。
具体对组织而言,质量策划的内容包括以下方面：
确定软件组织,适应其生产特点的组织结构,以及人员的安排和职责的分配 。 为建立软件组织的质量管理体系做最基础的准备 。
确定组织的质量管理体系目标,根据组织的商业需要和产品市场,确定选择 ISO 9000或 CMM作为其质量管理体系的符合性标准或模型 。
标识和定义组织的质量过程,亦即对组织的质量过程进行策划,确定过程的资源,主要影响因素,作用程序和规程,过程启动条件和过程执行结果规范等等 。
识别产品的质量特性,进行分类和比较,建立其目标,
质量要求和约束条件 。
策划质量改进的计划,方法和途径 。
质量管理体系策划的第一步就是识别并定义过程。软件组织的质量过程通常包含两种类型，即软件工程过程和组织支持过程。
软件工程过程软件工程过程，就是我们通常所说的软件生命周期中的活动，一般包括：软件需求分析、软件设计、编码、测试、
交付、安装和维护。
CMM中定义了三个关键过程区域来实现这两级过程策划：
① 组织过程定义（ Organization process definition）
② 软件项目策划（ Software project planning）
③ 软件产品工程（ Software product engjieering）
组织支持过程组织支持过程是软件组织为保证软件工程过程的实施和检查而建立的一组公共支持过程 。 通常这些支持过程不属于软件生命周期的活动 。 主要包括：
① 管理过程 。 包括：评审,检查,文档管理,不合格品管理,配置管理,内部质量审核和管理评审 。
② 支持过程 。 包括：合同评审,子合同管理,采购,培训,
进货检验,设备检验,度量和服务 。
在 CMM中,有一些对应的关键过程区域,如：
① 需求管理 （ Requirements management） 。
需求管理与 ISO 9001,2000的合同评审是对应的 。 其目的是保证客户的要求得到一致的理解,并且组织有能力满足客户的要求 。
② 软件子合同管理 （ Software subcontract management） 。
软件子合同管理对应于 ISO 9001,2000的采购过程控制 。 其目的是选择合适的分包商并对他们进行有效的管理 。
③ 软件质量保证 （ Software quality assurance） 。
软件质量保证对应于 ISO 9001,2000的设计,验证,确认,
过程检验和产品检验 。 其目的是通过对软件项目开发过程中适当的,可见的阶段性结果和最终产品进行检查,以实现对软件产品的质量管理 。
④ 软件配置管理 （ Sostware configuration management） 。
软件配置管理对应于 ISO 9001,2000的文件控制和产品标识 。
其目的是建立和维护软件项目产品在其整个生命周期中的完整性 。
⑤ 培训程序 （ Training program） 。
培训程序的目的是提高员工的技能和知识,使他们可以更有效地完成任务 。 培训是组织主动地,有计划地安排的活动,
但特殊的软件项目应该提出具体的培训要求 。
⑥ 同行评审 （ Peer reviews） 。
同行评审的目的是尽早和有效地清除软件产品中的缺陷 。 同行评审非常重要,并且可以调用软件产品工程描述的技术活动之外的其他有效的工程方法,如 Fagan风格的审查,结构化遍历及其它许多评审方法 。
2,软件质量控制与保证软件质量控制的主要目标就是按照质量策划的要求,对质量过程进行监督和控制 。 质量控制的主要内容有：
组织中的与质量活动有关的所有人员,按照职责分工进行质量活动 。
所有质量活动按照已经策划的方法,途径,相互关系和时间,有序地进行 。
对关键过程和特殊过程,实施适当的过程控制技术,如统计过程控制 （ SPC,Statistical Process Control） 以保证过程的稳定性,并在受控的情况下,提高过程的能力 。
所有质量活动的记录,都被完整,真实地保存下来,以供统计分析使用 。
对软件业而言,实施以上质量控制通常涉及的技术是：
软件配置管理软件配置管理的目的是,对软件生产过程中的所有有意义的中间产品形成文档,并以一种便于存取和检索,必要时可以逆向回溯的方式保存 。 同时配置管理还要保证文档的安全性,
保密性和及时性 。
软件过程流管理现代质量理论认为：“质量形成于过程”。软件过程流管理是软件质量控制中非常重要的环节。过程流管理的基本原则是：
① 按计划和设定条件启动和结束过程流中的质量活动
② 按照计划对中间产品进行验证，防止不合格的产品转入下道工序。
③ 记录和保持必要的过程活动的质量情况。
软件质量保证软件质量保证的目的是向组织的内部或外部提供信任依据。对内向组织的管理者表明组织的质量管理处于良好的状态，所有质量活动有效地运行；对外向顾客表明，组织有能力满足顾客的质量要求，并提供符合质量要求的产品和服务。
3,软件质量的度量和验证
软件质量度量现代质量管理理论,将质量的度量分为产品质量度量和过程质量度量两大类 。
① 产品质量度量通常产品质量度量依赖于具体的产品标准,通过测量获得产品质量特性的有关数据,辅以合适的统计技术以确定产品或同批产品是否满足了规定的质量要求 。
② 过程质量度量通过对软件产品设计,开发,检查,评审等过程的度量技术的使用,来度量软件过程的进度,成本是否按计划保证,
质量计划的变化频率,变化的诱因以及风险的管理等等 。
软件质量验证
ISO 9000,2000中对验证（ Verification）的定义是：
“通过提供客观证据对规定要求已得到满足的认定”。
CMM在关键过程域（ KPA）的公共特征（ Common
Feature） - 验证实现（ Verifying Implementation）中这样描述：“验证实现是保证活动按照已经建立的过程执行的一系列步骤，典型的验证有管理部门的评审、审核和软件质量保证”。
在软件质量管理中，对软件产品的验证通常包括：对各级设计的评审、检查，各个阶段的测试等。对软件过程的验证，则是对过程数据的评审和审核。
4,软件质量改进质量改进是现代质量管理的必然要求,ISO 9000要求组织定期进行内审和管理评审，采取积极有效的纠正预防措施，保持组织的质量方针和目标持续适合组织的发展和受益者的期望。
具体进行软件过程改进的活动包括：
度量与审核
纠正和预防措施
管理评审
9.2.4 全面质量管理全面质量管理包括以下几个方面：
（ 1）管理的目标：任何管理都要设定目标，然后组织实施，以达到所设定的目标；
（ 2）对产品质量开展“三全,管理，即要求全体部门，全体人员，对产品形成的全过程进行质量管理；
（ 3）在管理手段方面，要使用各种先进的管理思想、管理方法、管理手段、管理技术和管理工具；
（ 4）建立质量保证体系。
在这几个方面的内容中，质量管理应贯穿于软件产品形成的全过程中是尤为重要的内容，下面分为三个过程进行讲述。
1,软件开发过程的质量管理
软件生存期根据国家标准,计算机软件开发规范,,软件生命周期分为问题定义、
可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试、软件维护等 8个阶段 。
软件开发过程中质量管理的几个问题
① 通过软件质量度量技术进行质量控制软件质量度量技术的内容包括两项：第一，规定软件质量需求。第二，
在软件开发的每一阶段进行测量，并分析测量结果是否满足质量要求。
A,规定软件质量需求：规定质量需求是从质量角度对系统需求进行估价、选择质量特性、定义与这些特性相关的准则和适用的度量，并为每个质量特性确定质量标准。
B,通过质量度量进行监督、跟踪和控制,有了质量需求后，在软件开发过程中可应用质量度量方法来进行控制，质量度量一般采用三层模型，即质量特性，二级质量特性和度量。
② 建立设计评审制度在软件设计阶段与编码阶段，集体进行的检验活动尤为重要，通常称为设计评审。设计评审有两个含义：一是指在正式会议上，将一系统的初步的详细设计提交用户、顾客或有关人员供其评审或批准；二是指对现有的或提出的设计做正式的评审，其目的是找出可能会影响产品、过程或服务以及环境方面的设计缺陷并采取补救措施，或者是提供在功能，
性能和质量方面可能的改进方法。
2,软件产品复制过程的质量管理软件产品复制过程的质量管理与一般产品生产过程中的质量管理是非常相似的，应该遵循同样的生产现场质量控制的办法。
必须重视软件产品复制工序的建立软件产品的复制也应有生产工艺，需建立复制工序 。 各软件开发单位或组织都应根据自己的具体情况，结合所生产软件的产品特点，建立相应的复制工序。
必须重视软件产品复制技术文件的建立软件产品的复制技术文件是生产工人借以进行生产的必备的技术文件，
是软件产品的质量控制依据，它传达了软件产品介质复制品名的复制方法与质量检验标准等方面的信息。软件产品复制技术文件一般包括以下内容：
① 软件产品清单，产品名，各个部件名及内容等；
② 软件产品每一部件的复制方法；
③ 软件产品每一部件的质量标准及检验方法；
④ 软件产品的包装说明；
⑤ 软件产品的加密方法；
⑥ 介质的保存环境要求与工作环境要求。
必须重视软件产品介质的质量管理软件介质有源介质与目标介质两类，源介质是存放软件正本的介质，以此为兰本来进行软件产品的批量生产，目标介质是存放软件复制品的介质，是作为产品提供给用户的。软件介质的质量管理应与一般外购商品的质量管理相同，这里强调三点：
① 保证软件介质质量的关键是选择一个好的供应商；
② 要注意加强软件介质存放环境条件的改善，以保证软件介质的质量；
③ 要定期对源介质进行全面检查，因源介质并不能无限制地被复制，它也有一个使用期。
必须重视软件产品复制设备的质量管理软件产品的生产设备是保证软件复制工序能力的重要物质条件，软件产品的复制设备如计算机、拷贝机等应经常处于良好状态，因此必须采用先进的设备管理方法，搞好设备的定期维护、保养和检修。
软件产品复制过程的质量管理还有许多工作要做，它需要借鉴一般硬件产品的生产现场质量管理方法。更需要针对软件产品复制特点探索出一套新的管理方法，其中最重要的是需求收集和积累大量的资料、数据，在软件产品大批量生产的今天，应引起我们足够的重视。
2,软件产品使用过程的质量管理
软件产品使用过程质量管理的主要职能软件产品使用过程质量管理的主要职能是：
① 做好软件产品的销售工作，帮助用户正确购买；
② 做好软件产品的保管、发运工作；
③ 做好用户的技术服务、技术支持、技术咨询、技术培训等工作，保证使用效果；
④ 做好软件产品的日常维护工作，及时为用户更新版本；
⑤ 做好市场调查与分析，收集质量反馈信息，为新软件的开发提供准确可靠的情报；
⑥ 认真处理软件产品的质量问题，对有质量问题的软件应做到保换、保修、保退，树立质量信誉。
Back
软件产品使用过程中的质量管理工作在软件使用过程中质量管理要做到以下几点。
① 在软件产品的销售中应做到,广告文件准备充分，内容简洁、清晰、明了；销售时应耐心向用户解释，宣传；现场演示，试用。
② 软件产品的技术服务应包括：用户培训。应针对不同用户，不同层次；技术支持与技术咨询。应做到有求必应，热情接待。
③ 软件产品的维护工作应做到：制度化。有专人负责，定期督促与检查；规范化，维护工作应有标准的工作程序，有严格的文档记录。
④ 做好市场调查
9.3 软件开发的标准与规范
9.3.1 软件生产标准化的意义搞好软件开发标准化的工作，其意义在于：
1,软件生产标准化是推动我国软件产业按系统工程规律健康发展的指南。 软件项目的开发是一项复杂的系统工程，
要运用系统的思想和系统工程的方法，采用标准化的作业方式和手段，对系统开发的全过程进行技术指导与管理。
2,软件生产标准化是软件资源共享的前提 。 制定一套统一的数据规范，统一的分类编码，统一的交换格式，统一的名词术语，统一的文件格式和统一的指标体系，并在软件开发和使用维护过程中严格执行这一套大家所公认的相对稳定的标准规范，只有这样才能实现软件资源的充分共享。
3,软件生产的标准化是提高软件质量的重要保证 。软件质量的度量标准可以对一软件系统建立一些质量需求，在软件生存期的每一个阶段利用这些标准和质量需求指导软件的开发、测试和维护，以获得高质量的软件和质量测定结果。
4,软件生产标准化是加速建立我国软件产业的强大动力 。
9.3.2 软件开发标准与规范在软件开发的军用标准方面比较著名的是美国国防部的标准 DOD-STD-
1679A和 DOD-STD-2167。
IEEE（美国电气和电子工程师学会）和 ISO（国际标准化组织）的软件工程标准化工作方面的标准：
ANSI/IEEE Std 729-1983 软件工程术语标准词汇
ANSI/IEEE Std 730-1984 软件质量保证计划标准
IEEE Std 828-1983 软件配置管理计划标准
ANSI/IEEE Std 829-1983 软件测试文档标准
IEEE Std 830 –1984 软件需求规范说明指南
IEEE Std 983-1985 软件质量保证计划指南
ISO DP 8631 程序的构造及其使用约定其中,IEEE标准 730是 IEEE组织制定的一个软件质量工业标准。
我国的计算机与信息处理标准化技术委员会软件工程分技术委员会已开始进行这项工作，并且已制定了一些软件方面的标准（草案）。下 图列举了软件工程标准体系的大致情况。
9.3.3 文件标准与规范软件文件标准规定了软件开发过程中所应编制的软件文件的种类、名称、
及内容要求，以便有一个统一的编写格式，便于交流和学习。我国正式的国家标准是：
① 计算机软件开发规范,GB 8566-88
② 计算机软件产品开发文件编制指南,GB8567-88
③ 计算机软件工程术语标准
④ 计算机软件测试文件编制规范,GB 9386-88
⑤ 计算机软件配置管理计划规范,GB/T 12505-90
⑥ 计算机软件质量保证计划规范,GB/T 12504-90
⑦ 计算机软件需求规范说明编制指南,BG 9385-88
⑧ 数据流图,程序流图,系统流程图,程序网络图和系统资源图的文件编制符号及约定。
国家标准,计算机软件产品开发文件编制指南,是一份指导性文件。它建议在软件的开发过程中编制下述 14个文件。即：
① 可行性研究报告 ⑨ 操作手册
② 项目开发计划 ⑩ 模块开发卷宗
③ 软件需求说明书 ⑾ 测试计划
④ 数据要求说明书 ⑿ 测试分析报告
⑤ 总体设计说明书 ⒀ 开发进度表
⑥ 详细设计说明书 ⒁ 项目开发总结。
⑦ 数据库设计说明书
⑧ 用户手册该指南给出了这 14个文件的编制提示，它同时也是这 14个文件编写质量的检验准则。
1,可行性研究报告表 9.2可行性研究报告
1引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2可行性研究的前提
2.1要求
2.2目标
2.3条件 '假定和限制
2.4进行可行性研究的方法
2.5评价尺度
3对现有系统的分析
3.1数据流程和处理流程
3.2工作负荷
3.3费用开支
3.4人员
3.5设备
3.6局限性
4所建议的系统
4.1对所建议系统的说明
4.2数据流程和处理流程
4.3改进之处
4.4影响
4.4.1对设备的影响
4.4.2对软件的影响
4.4.3对用户单位机构的影响
4.4.4对系统运行的影响
4.4.5对开发的影响
4.4.6对地点和设施的影响
4.4.7对经费开支的影响
4.5局限性
4.6技术条件方面的可行性
5可选择的其它系统方案
5.1可选择的系统方案 1
5.2可选择的系统方案 2
………
6投资及收益分析
6.1支出
6.1.1基本建设投资
6.1.2其它一次性支出
6.1.3非一次性支出
6.2收益
6.2.1一次性收益
6.2.2非一次性收益
6.2.3不可定量的收益
6.3收益 /投资比
6.4投资回收周期
6.5敏感性分析
7社会条件方面的可行性
7.1法律方面的可行性
7.2使用方面的可行性
8结论可行性研究报告的目的是：说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性，论述为了合理地达到开发目标而可能选择的各种方案，说明并论证所选定的方案。可行性研究报告的编写内容见表 9.2。
2．项目开发计划编制项目开发计划的目的是用文件的形式，将在开发过程中各项工作的负责人员、开发进度、经费预算、所需软硬件条件等问题作出的安排记录下来，
以便根据本计划开展和检查项目的开发工作。编制内容要求如表 9.3。
表 9.3项目开发计划
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 项目概述
2.1工作内容
2.2主要参加人员
2.3产品及成果
2.3.1程序
2.3.2文件
2.3.3服务
2.3.4非移交产品
2.4验收标准
2.5完成项目的最迟期限
2.6本计划的审查者与批准者
3 实施总计划
3.1工作任务的分解
3.2接口人员
3.3进度
3.4预算
3.5关键问题
4 支持条件
4.1计算机系统支持
4.2需要用户承担的工作
4.3需由外单位提供的条件
5 专题计划要点
3．软件需求说明书软件需求说明书的编制是为了使用户和软件开发人员双方对该软件的初始规定有一个共同的理解，使之成为整个软件开发工作的基础。其内容要求见表 9.4。
表 9.4软件需求说明书
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 任务概述
2.1目标
2.2用户的特点
2.3假定的约束
3 需求规定
3.1对功能的规定
3.2对性能的规定
3.2.1精度
3.2.2时间特性要求
3.2.3灵活性
3.3输入输出要求
3.4数据管理能力要求
3.5故障处理要求
3.6其它专门要求
4 运行环境规定
4.1设备
4.2支撑软件
4.3接口
4.4控制
4．数据要求说明书数据要求说明书的编制目的是为了向整个软件开发时期提供关于被处理数据的描述和数据采集要求的技术信息，其内容要求列于表 9.5。
表 9.5数据要求说明书
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 数据的逻辑描述
2.1静态数据
2.2动态输入数据
2.3动态输出数据
2.4内部生成数据
2.5数据约定
3 数据的采集
3.1要求和范围
3.2输入的承担者
3.3处理
3.4影响
5．总体设计说明书总体设计说明书又称为概要设计说明书，是指项目系统，编制目的是说明对项目系统的设计考虑，包括基本处理流程、组织结构、模块结构、功能配置、接口设计、运行设计、系统配置、数据结构设计和出错处理设计等，为程序的详细设计提供基础。其内容要求见表 9.6。
表 9.6概要设计说明书
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 总体设计
2.1运行环境
2.2运行环境
2.3基本设计概念和处理流程
2.4结构
2.5功能需求与程序的关系
2.6人工处理过程
2.7尚未解决的问题
3 接口设计
3.1用户接口
3.2外部接口
3.3内部接口
4 运行设计
4.1运行模块组合
4.2运行控制
4.3运行时间
5 系统数据结构设计
5.1逻辑结构设计要点
5.2物理结构设计要点
5.3数据结构设计要点
6 系统出错处理设计
6.1 出借信息
6.2补救措施
6.3系统维护设计
6．详细设计说明书详细设计说明书又称为程序设计说明书，编制目的是说明一个软件系统各个层次中的每一个程序（模块）的设计考虑。如果软件系统比较简单，层次少，本文件可以不单独编写，有关内容可并入总体设计说明书。详细设计说明书的内容要求见表 9.7。
表 9.7详细设计说明书
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 程序系统的组织结构
3 程序 1(标识符 )设计说明
3.1程序描述
3.2功能
3.3性能
3.4输入项
3.5输出项
3.6算法
3.7流程逻辑
3.8接口
3.9存储分配
3.10注释设计
3.11限制条件
3.12测试计划
3.13尚未解决的问题
4 程序 2(标识符 )设计说明
7．数据库设计说明书数据库设计说明书的编制目的是对于设计中的数据的所有标识、逻辑结构和物理结构作出具体的设计规定。内容要求见表 9.8。
表 9.8数据库设计说明书
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 外部设计
2.1 标识符和状态
2.2使用它的程序
2.3约定
2.4专门指导
2.5支撑软件
3 结构设计
3.1概念结构设计
3.2逻辑结构设计
3.3物理结构设计
4 运用设计
4.1数据字典设计
4.2安全保密设计
8．用户手册用户手册的编制是使用非专业术语的语言，充分地描述该软件系统所具有的功能及基本的使用方法，使用户通过本手册能够了解该软件的用途，并能够确定在什么情况下、如何使用它。具体的内容要求见表 9.9。
表 9.9用户手册
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 用途
2.1功能
2.2性能
2.2.1精度
2.2.2时间特性
2.2.3灵活性
3 运行环境
3.1硬环境
3.2支撑软件
3.3数据结构
4 使用过程
4.1安装与初始化
4.2输入
4.2.1输入数据的现实背景
4.2.2输入格式
4.2.3输入举例
4.3输出
4.3.1输出数据的现实背景
4.3.2输出格式
4.3.3输出举例
4.4文卷查询
4.5出错处理与恢复
4.6终端操作
9．操作手册操作手册的编制是为了向操作人员提供该软件每个运行的具体过程的有关知识，包括操作方法的细节。内容要求见表 9.10。
表 9.10操作手册
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 软件概述
2.1软件的结构
2.2程序表
2.3文卷表
3 安装与初始化
4 运行说明
4.1运行表
4.2运行步骤
4.3运行 1(标识符 )说明
4.3.1运行控制
4.3.2操作信息
4.3.3输入 -输出文卷
4.3.4输出文段
4.3.5输出文段的复制
4.3.6启动恢复过程
4.4运行 2(标识符 )说明
…………
5 非常规过程
6远程操作
10．模块开发卷宗模块开发卷宗是在模块开发过程中逐步编写出来的，每完成一个模块或一组密切相关的模块的复审时编写一份，应该把所有的模块开发卷宗汇集在一起，编写的目的是记录和汇总低层次开发的进度和结果，以便于对整个系统开发工作进行管理的复审，并为将来的维护提供有用的技术信息，
具体内容要求见表 9.11。
表 9.11 模块开发卷宗
1 标题
2 模块开发情况表 （ 见附表 ）
3 功能说明
4 设计说明
5 源代码清单
6 测试说明
7 复审的结论
11．测试计划测试是指整个软件系统的组装测试和确认测试，本文件的编制是为了提供一个对该软件的测试计划，包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整体理方法及评价准则。具体内容见表
9.12。
表 9.12测试计划
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 计划
2.1软件说明
2.2测试内容
2.3测试 1(标识符 )
2.3.1进度安排
2.3.2条件
2.3.3测试资料
2.3.4测试培训
2.4测试 2(标识符 )
3 测试设计说明
3.1测试 1(标识符 )
3.1.1控制
3.1.2输入
3.1.3输出
3.1.4过程
3.2测试 2(标识符 )
…………
4 评价准则
4.1范围
4.2数据整理
4.3尺度
12．测试分析报告测试分析报告的编写是为了把组装测试和确认测试的结果、发现的问题、以及分析结果写成文件形式加以保存。具体编写内容要求见表 9.13。
表 9.13测试分析报告
1 引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 测试概要
3 测试结果及发现
3.1测试 1(标识符 )
3.2测试 2(标识符 )
…………
4 对软件功能的结论
4.1功能 1(标识符 )
4.1.1 能力
4.1.2限制
4.2 功能 2(标识符 )
…………
5 分析摘要
5.1能力
5.2缺陷和限制
5.3建议
5.4评价
6 测试资源消耗
13．开发进度月报开发进度月报的编制目的是及时向有关管理部门汇报项目开发的进度和情况，以便及时发现和处理开发过程中出现的问题。一般来说，开发进度月报是以项目组为单位每月编写的。具体内容要求见表 9.14。
表 9.14开发进度月报
1 标题
2 工程进度与状态
2.1进度
2.2状态
3 资源耗用与状态
3.1资源耗用
3.1.1工时
3.1.2机时
3.2状态
4 经费支出与状态
4.1经费支出
4.1.1支出性费用
4.1.2设备购置费
4.2状态
5 下个月的工作计划
6 建议
14．项目开发总结报告项目开发总结报告的编制是为了总结本项目开发工作的经验，说明实际取得的开发成果以及对整个开发工作的各个方面的评价。具体内容要求见表 9.15。
表 9.15项目开发总结报告
1引言
1.1编写目的
1.2背景
1.3定义
1.4参考资料
2 实际开发结果
2.1产品
2.2主要功能和性能
2.3基本流程
2.4进度
2.5费用
3 开发工作评价
3.1对生产效率的评价
3.2对产品质量的评价
3.3对技术方法的评价
3.4出错原因的分析
4 经验与教训另外，必须对软件文件的修改活动进行严格的管理，要防止修改后所带来的不一致性以及可能对项目开发所产生的影响。修改前要提出书面的修改意见，经项目负责人或有关人员评议，审核后，经批准方可实施修改。修改过程中所产生的文件也就妥善保管，以备后查。
9.4 软件质量的综合评价
9.4.1 软件质量评价的目的
Boehm等人于 1976年提出了定量地评价软件质量的概念。并且首次提出了软件质量度量的层次模型。 1978年 Walters和 McCall提出了从软件质量要素（ factor）、准则（ riteria）到度量（ metric）的三层次式的软件质量度量模型。
G.Murine基于上述两个人的工作提出了 SQM（ Software Quality Metrics）
软件质量度量技术，用于定量地评价软件质量，且已付诸实用。
从用户的观点出发，运用新的方法和技术，从整体上来度量和评价软件的质量，确保软件产品质量特性的高标准，降低软件开发成本，已成为软件质量综合评价的主要目的之一。
9.4.2 软件质量综合评价的内容
1,规定软件质量需求规定软件质量需求是在综合考虑了要素对软件的重要性和要素间的关系后做出的，并为以后的软件质量度量建立了对照的依据。规定软件质量需求分三个部分：
决定软件质量要素
<1>,为软件定一个原始的质量指标，质量指标反映了要素对软件的相对重要性。指标通常分为三级：
A：说明这个要素对软件来说极其重要；
B：说明这个要素对软件来说是重要的；
C：说明这个要素对软件来说比较重要。
<2>,定量化地表示要素与软件质量的关系，指标应该用一个数值范围来表示。如果 x代表质量指标的值，建议 A表示,0.9≤x≤1,B表示：
0.8≤x<0.9,C表示 0.6≤x<0.8 。这样，在为软件的每个要素打分后，可以对照为软件制定的质量指标，看看软件产品的质量是否达到了要求。
<3>,考虑 3个基本质量要素对其它要素的影响，这 3个基本要素是可靠性、
功能性和可维护性。
<4>,考虑了基本的质量要素对其它要素的影响后，应该对 原始的质量指标 进行修正。
<5>,在为要素分配最终的质量指标时，还应当考虑要素间有利的和不利的关系，以决定为要素所定的指标是否可以达到。如果否定的指标不能达到，还应考虑对 <4>所修正的质量指标 进行修改，以决定最终的指标。
决定准则及其权值对每个建立了质量指标的要素（没有建立质量指标的要素不必这样），
查阅表 9.23，找出属于这个要素的所有准则（即表 9.23中打钩的准则），
把它们标出来。然后，再为这些准则加权。准则的权说明了准则和要素的特殊关系，即准则在要素中所占的比重。
加权的结果形式如矩陈 M：
nlnn
l
l
mmm
mmm
mmm
n
M
21
22221
11211
..
3
2
1
加权者加权者加权者加权者
：矩阵
l
则准则准则准
21
其中 mij代表 i个打分员为第 j个准则加的权。
对矩阵 M作适当变换，可以得到 W=(W1,W2,…WL)。其中 Wj是第 j个准则的权,Wj的计算方法如下：
决定度量和度量问题对于每个权值不为 0的准则，根据度量工作表，在考虑了系统环境及应用的特性后，为每个准则选取合适的度量，然后，再为每个度量选取合适的度量元。
l
j
jj Wa
1
n
j
l
j
ijijj mmnW
1 1
1
在考虑了准则与要不比关系后得到的权值为 Wˊ 。 Wˊ= （ Wˊ 1，
Wˊ 2,…,Wˊ l） 。如果某个要素有 l个准则，这 l个准则对某个子系统来说得分分别是 a1,a2,…,al，则这个要素对该子系统来说得分为：
2 软件质量评价方法评价软件达到的质量水平必须在每个开发阶段 （ 包括需求分析,概要设计,详细设计,实现,组装测试,确认测试,使用和维护 ） 的最后进行,
评价的依据是每个开发阶段所应提交的文件,这些文件见下表 。
表 9.30每个阶段应提交的文件评价产品达到的质量水平的过程如图 9-6所示：
软件质量评价方法分为两个部分：
1,计算要素分数要素的分数是通过度量元,度量,准则的分数得到的,要知道要素的分数首先应知道度量元的分数,度量元的分数是通过向软件提供度量工作表上的度量问题取得的 。
把对度量问题的回答转变为度量元的分数,进而算出度量,
准则和要素的分数,需要使用要素打分表 。 在每个开发阶段,
应该为每个要素准备一张要素记分表 （ 要素记分表包括了每个要素的所有准则 ） 。
度量分数是度量元分数的算术平均值 。 准则的分数是度量分数的算术平均值 。
2,分析要素分数前面计算的是每个子系统的质量要素分数,还应当把子系统的质量要素分数转化为系统的质量要素分数,此过程可分成 3步,（ 1） 找出与该要素有关的子系统； （ 2） 根据子系统的大小为子系统加权； （ 3） 把要素在每个有关的子系统中得到的分数与该子系统的权值相乘再全部相加即得到该要素在系统中的分数 。
在坐标纸上建立一个 x-y坐标系,x方向代表软件开发阶段,
y方向代表每个软件开发阶段中通过评价得到的分数,据此描出曲线,就可以看出每个要素分数的发展倾向 。
为每个要素规定的指标化作一个数值范围 （ 如指标 A可看作 0.9-1,指标 B可看作 0.8-0.9等等 ）,并把它们标在为这个要素建立的坐标系上 。 这样就可以看出要素的分数是否落在为要素规定的质量指标的数值范围内 。
在分析了要素分数不符合需求的原因以后，应该把这些原因归类，以便对软件开发中存在的问题有个清楚的认识。在综合考虑了系统的需求和限制后，提出解决问题的方案。下图是分析要素分数流程图。
9.4.3 软件过程成熟度模型 (Capability Maturity Model)
1．软件机构的成熟性对于不同的软件开发机构，在组织人员完成软件项目中所依据的管理策略有很大的差别，因而软件项目所遵循的软件过程也有很大差别。在此，可用软件机构的成熟度（ Maturity）加以区别。
不成熟软件机构的特征,
软件过程一般在项目进行中由参与开发的人员临时确定。有时即使确定了，实际上也并不严格执行；
软件机构是反应型的，管理人员经常要集中精力去应付难以预料的突发事件；
项目的进度和经费预算由于估计的不切实际，所以常常突破。在项目进度拖延，交付时间紧迫的情况下，往往不得不削减软件的功能，降低软件的质量；
产品质量难以预测。质量保证活动，如质量评审、测试等，常被削弱或被取消。
成熟软件机构具有的特征：
建立了机构级的软件开发和维护过程。软件人员对其有较好的理解。
一切活动均遵循过程的要求进行，做到工作步骤有次序，且有章可循；
软件过程必要时可做改进，但需在经小型试验和成本 -效益分析的基础上进行；
软件产品的质量和客户对软件产品的满意程度不是由开发人员，而是由负责质量保证的经理负责监控；
项目进度和预算是根据以往项目取得的实践经验确定，因而比较符合实际情况。
2．软件过程成熟度模型
1987年，美国卡内基 -梅隆大学软件工程研究所 SEI受美国国防部资助，
提出了软件机构的能力成熟度模型 CMM。
CMM将软件过程的成熟度分为 5个等级，如下图所示。以下给出具有 5
个等级的软件机构的特征：
初始级 （ initial）
工作无序,项目进行过程中常放弃开始制定的计划；
管理无章,缺乏健全的管理制度；
开发项目成效不稳定,产品的质量和性能严重依赖于个人的能力和行为 。
可重复级 （ repeatable）
管理制度化,建立了基本的管理制度和规程,管理工作有章可循；
初步实现标准化,开发工作交好地实施标准；
变更均依法进行,做到基线化；
稳定可跟踪,新项目的计划和管理基于过去的经验,具有重复以前成功项目的环境和条件 。
已定义级 （ defined）
开发过程,包括技术工作和管理工作,均已实现标准化,文档化；
建立了完善的培训制度和专家评审制度；
全部技术活动和管理活动均稳定实施；
项目的质量,进度和费用均可控制；
对项目进行中的过程,岗位和职责均有共同的理解 。
已管理级 （ managed）
产品和过程已建立了定量的质量目标；
过程中活动的生产率和质量是可度量的；
已建立过程数据库；
已实现项目产品和过程的控制；
可预测过程和产品质量趋势,如预测偏差,实现及时纠正 。
优化级 （ optimizing）
可集中精力改进过程,采用新技术,新方法；
拥有防止出现缺陷,识别薄弱环节以及加以改进的手段；
可取得过程有效性的统计数据,并可据此进行分析,从而得出最佳方法 。
3．关键过程领域除去初始级以外，其他 4级都有若干个引导软件机构改进软件过程的要点，称为关键过程领域（ KPA Key Process Area）。每一个关键过程领域是一组相关的活动，成功地完成这些活动，将会对提高过程能力起重要作用，下图给出了各成熟度等级对应的关键过程领域。
4．成熟度提问单为了把上述过程成熟度分级的方法推向实用化，需要为其提供具体的度量标尺。这个度量标尺就是成熟度提问单。 CMM
在以下七个方面列出了大量的问题，每个问题都可针对特定的被评估软件机构给出肯定或否定的回答。提问单涉及的方面包括组织结构资源、人员及培训技术、管理文档化标准及工作步骤、过程度量数据管理和数据分析、过程控制。
Back
5．利用 XMM对软件机构进行成熟度评估评估过程有以下几步：
建立评估组：评估组成员应对软件过程,软件技术和应用领域很熟悉,
有实践经验,能够提出见解 。
评估组准备：评估组具体审定评估的问题,决定对每一个问题要求展示哪些材料和工具 。
项目准备：评估组与被评估机构领导商定选择哪些处在不同开发阶段的项目和典型的标准实施作为评估对象 。 将评估时间安排通知被评估项目负责人 。
进行评估：对被评估机构的管理人员和项目负责人说明评估过程 。 评估组与项目负责人一起就所列出的问题逐一对照审查,保证对问题的回答有一致的解释,从而取得一组初始答案 。
初评：对每个项目和整个机构做出成熟度等级初评。
讨论结果：讨论初评结果 。 使用备用资料及工具演示,可进一步证实某些问题的答案,从而决定可能的成熟度等级 。
给出最后的结论：由评估组综合问题的答案,后继问题的答案,以及背景依据,作出最终评估结论 。
