软件项目管理复习提纲.docx
《软件项目管理复习提纲.docx》由会员分享,可在线阅读,更多相关《软件项目管理复习提纲.docx(11页珍藏版)》请在冰豆网上搜索。
![软件项目管理复习提纲.docx](https://file1.bdocx.com/fileroot1/2023-1/31/37c372d8-3d31-4991-9542-7871b33461ec/37c372d8-3d31-4991-9542-7871b33461ec1.gif)
软件项目管理复习提纲
软件项目管理复习提纲
前言
1、软件项目管理是软件工程和项目管理的交叉学科,是项目管理的原理和方法在软件工程领域的应用。
2、软件项目的抽象性决定了软件项目管理的难度要大于一般的工程项目管理。
3、软件项目需求管理、项目估算与进度管理、项目配置管理、项目风险管理、项目质量管理、项目资源管理等六个方面对软件项目中的管理问题进行了探讨。
第一章导论
1、软件工程的概念:
一类求解软件的工程。
应用计算机科学、数学以及管理科学等原理、借鉴传统工程的原则、方法,创建软件以达到提高质量、降低成本的目的,使计算机设备的能力借助于软件成为对人类有用的东西。
其中,计算机科学、数学用于构造模型和算法,工程科学用于制定规范、设计模式、评估成本及确定权衡,管理科学用于计划、资源、质量、成本等管理。
软件工程框架:
软件工程——目标:
可用性、正确性、合算性
活动:
问题定义、可行性分析、需求分析、设计、实现、确认、支持
原则:
开发范型、设计方法、支持过程、管理过程
2、项目管理
项目是指在一定约束条件下具有特定目标的一项一次性任务。
这里所说的
●一次性,又称为单件性,指这次任务完成之后,不会再有与此完全相同的另一任务。
●目标,即项目的目标有成果性目标和约束性目标。
成果性目标——项目的功能性要求,约束性目标——资源消耗、时间要求、质量规定等限制条件。
●作为管理对象的整体性,即一个项目是一个整体管理对象。
项目的生命周期:
项目从开始到结束,一般都要经历启动、计划、实施、结束几个阶段,称之为项目的生命周期
启动阶段要进行可行性分析,以便确定是否接受项目。
计划阶段建立解决需求或问题的方案,向客户提交各种计划书。
实施阶段就是执行计划阶段提出的解决方案,在各种因素的制约下,实现项目的目标。
项目的结束阶段就是正式验收项目,使得项目圆满完成。
项目管理的定义:
在一个确定的时间范围内,为了完成一个既定的目标,通过特殊形式的临时性组织运行机制,经有效的计划、组织、领导和控制,充分利用既定有限资源的一种系统管理方法。
项目管理具有如下特点:
(1)综合性;
(2)创造性;(3)时间性
关于创造性:
由于项目具有一次性的特点,因而既要承担风险又必须发挥创造性。
这也是与一般重复性管理的主要区别。
关于时间性:
项目具有寿命周期,项目管理的本质是计划和控制一次性的工作,在规定期限内达到预定目标。
对每个阶段开始和完成的条件与时间要有明确的定义,以便于审查其完成程度。
项目管理的要素:
项目目标的实现主要由六个因素制约,分别为范围、时间、成本、质量、组织及客户满意度,称为项目管理的六要素
3、软件项目管理:
软件项目产品的特点:
1.抽象性;2.缺陷检测的困难性;3.高度的复杂性;4.缺乏统一规则
软件项目失控的原因诸如:
(1)需求不明确;
(2)不充分的计划和过于乐观的评估;(3)采用新技术;(4)管理方法缺乏或不恰当;(5)性能问题;(6)团队组织不当;(7)人际因素
软件项目管理的定义:
在软件项目活动中运用一系列知识、技能、工具和技术,以满足软件需求方的整体要求。
软件项目管理的内容:
软件项目需求管理;软件项目估算与进度管理;软件项目配置管理;软件项目风险管理;软件项目质量管理;软件项目资源管理
第二章软件项目需求管理
软件需求的定义:
(1)用户解决问题或达到目标所需的条件或能力。
(2)系统或系统部件要满足合同、标准、规范或其他正式文档所需具有的条件或能力。
(3)一种反映上面第一点或第二点所描述的条件或能力的文档说明。
软件需求在软件项目中的作用:
软件需求在软件项目中占有重要地位,是软件设计和软件实现的基础。
需求的改变将导致其后一系列过程的更改,因而软件需求与软件项目中其他过程有着密切关系
软件需求的抽象层次:
从问题求解过程来看,软件需求可以分成四个抽象的层次:
原始问题描述;用户需求;系统需求;软件设计描述
用户需求:
从用户的角度描述系统的需求,以便没有专业技术背景的用户能看懂。
它只描述系统的外部行为,尽量避免涉及系统内部的设计特性,通过自然语言、图表、图形等来叙述。
在编写用户需求文档的时候,应该遵守如下一些简单的原则:
(1)标准的格式
(2)使用一致的语言(3)使用特殊文本(4)尽量避免专业术语
系统需求:
是比用户需求更为详细和专业的需求描述,是系统实现的依据。
一个完整且一致的系统需求描述,是软件设计的起点。
需求文档的编制与作用:
软件需求分析和描述的最终目的是在用户和软件开发组织之间就将要开发的软件系统达成一致的协议,从而产生正式的需求文档,以便为软件设计和实现提供依据。
软件需求文档包括用户需求和详细的系统需求描述,是对软件系统要求的正式陈述。
软件需求质量度量的九个元素:
正确性、无歧义性、完备性、一致性、分级性、可验证性、可修改性、可跟踪和可理解性。
需求管理:
需求管理的必要性:
1.需求供求双方固有的矛盾:
软件开发人员的思维贯穿了软件设计的全过程,同样也贯穿了需求过程,而普通人没有这方面的思维,因而他们都觉得和软件开发人员打交道极为困难。
因此需求过程中,需求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当大的出入等情况。
2.需求具有易变性和难以表述性:
3.需求错误出现的高频性和修复的高昂成本
需求变更管理:
变更管理过程:
原需求-变更描述→变更分析→变更实现-修正后的需求
变更影响分析:
进行需求变更影响分析,应评估每项选择的需求变更,以确定它对项目计划安排和其他需求的影响,同时明确与变更相关的任务并评估完成这些任务需要的工作量。
变更影响分析通过对变更内容的检验及对变更建议的准确理解,有助于变更控制委员会做出信息量充分的变更决策,确定对变更是修改还是抛弃,或者创建新系统以及评估每个任务的工作量。
需求跟踪的必要性:
进行需求跟踪的目的是建立和维护从用户需求开始到测试之间的一致性与完整性,确保所有的实现都以用户需求为基础,而实现的需求也全部覆盖了预期的需求,同时确保所有的输出与用户需求的符合性
需求跟踪的作用:
(1)在需求验证中的作用
(2)有助于需求变更影响分析(3)便于需求的维护(4)便于测试时找出问题所在(5)便于项目跟踪(6)减小项目的风险(7)简化了系统的再设计(8)易于软件重用
需求管理质量保证:
(1)需求验证【需求验证可按如下四个步骤进行:
i审查需求文档ii依据需求编写测试用例iii编写用户手册iv确定合格的标准】;
(2)需求评审
第3章软件项目成本管理
成本:
生产一种产品所需的全部费用。
软件项目成本大体包括以下4个方面:
人力资源成本(软件项目有关人员的工资、福利、招聘和培训等的费用)
软硬件资源成本(开发测试工具等的成本)
商务活动成本(项目开发过程中的差旅、交通、通信及接待等的费用)
其它成本(未在上述罗列的费用)
软件项目估算:
估算是指通过预测构造软件项目所需要的工作量的过程。
软件项目估算包括工作量估算和成本估算两个方面,通常笼统的表示为成本估算。
估算的意义:
软件估算作为软件项目管理的一项重要内容,是确保软件项目成功的关键因素。
软件项目工作量估算的失真,将导致软件成本上升,开发周期延长,从而使项目管理失效,开发者受损、使用者不能如期得到合约规定的产品,最终使项目失败。
初步的估算用于确定软件项目的可行性,详细的估算用于指导项目计划的制定。
软件规模:
软件规模是软件工作量的主要影响因素。
对软件规模的估计要从软件的分解开始。
规模度量标准有两种:
代码行LOC和功能点FP
代码行(LOC):
代码行是常用的源代码程序长度的度量标准。
可以分为无注释的源代码行和注释的源代码行。
功能点度量方法通过研究初始应用需求来确定各种输入、输出、查询、外部文件和内部文件的数目,从而确定功能点数量。
软件生产率【LOC/PM(每个人月生产代码的数量)】:
生产率数据的获取
(1)选择一些最近完成的相似的项目;
(2)获得各个项目的LOC数据;
(3)对于更改过的程序,记录更改代码所占比例;
(4)计算投入到每个项目上的人员数量;
(5)计算各个项目的软件生产率,即LOC/PM(每个人月生产代码的数量)
软件项目成本估算
成本估算方法:
成本估算是对完成软件项目所需费用的估计和计划。
在软件项目管理过程中,为了使时间、费用和工作范围内的资源得到最佳利用,人们开发出了不少成本估算方法,以尽量得到较好的估算。
算法模型:
算法模型提供一个或多个数学算法,这些算法将软件成本估算值看成是主要成本驱动因素的若干变量的函数。
常见的算法形式有线性模型、乘积模型、解析模型、表格模型、复合模型。
线性模型:
工作量=a0+a1x1+……+anxn
式中,x1,……,xn是成本驱动因素变量,a0,……,an是一组经过选择的、能使本模型与一组观察数据点之间的拟合度最佳的系数。
开发成本一般通过将工作量乘以某一恒定的劳动力成本而求出。
虽然简单,但由于在软件开发中非线性相互作用太多,以至于线性模型效果并不好。
乘积模型:
工作量=a0a1x1……anxn
式中,x1,……,xn是成本驱动因素变量,a0,……,an是一组经过选择的、能使本模型与一组观察数据点之间的拟合度最佳的系数。
专家判定:
专家判定就是与一位或多位专家商讨,专家根据自己的经验和对项目的理解对项目成本做出估算。
类比:
类比法就是把当前项目和以前作过的类似项目比较,通过比较获得其工作量的估算值;
自顶向下:
从软件项目的整体出发,即根据将要开发的软件项目的总体特性,结合以前完成项目积累的经验,推算出项目的总体成本或工作量,然后按比例分配到各个组成部分中去。
自底向上:
把待开发的软件逐步细化,直到能明确工作量值,然后把所有部分相加。
成本估算步骤:
(该过程表明软件成本估算工作本身也是一种小型项目,需要相应的规划、复审和事后跟踪。
)
Boehm提出的成本估算方法:
(1)建立目标;
(2)规划需要的数据和资源;
(3)确定软件需求;
(4)拟定可行的细节;
(5)运用多种独立的技术和原始资料;
(6)比较并迭代各个估算值;
(7)随访跟踪
第四章软件项目进度管理
制定项目计划:
定义工作并确定完成工作的方式,对主要任务及需要的时间和资源进行估计,定义管理评审和控制的框架。
正确的文档化计划与项目实际的结果进行对比,能够使计划人员发现估计的错误从而改进估计过程,提高估计的准确性。
分阶段交付:
(1)必要性:
对于规模较大的软件项目,制定项目计划时,项目的交付最好采用按阶段交付的形式。
(2)分阶段交付的过程:
分阶段交付不会自发产生,它要求稳固的体系结构、精心的管理和详细的技术计划。
这是对软件项目的一个明智投资,因为它能够消除一般项目的下述风险:
逾期交付、集成失败、软件特征的逐渐增加及客户、经理与开发人员之间的摩擦。
进度安排:
(1)进度安排的整体过程:
在确定了项目的资源(总成本及时间等)后,把其分配到各个项目开发阶段中,即确定项目的进度。
这时候,软件组织在类似项目的历史经验数据很有借鉴价值。
如果缺乏经验数据,则可以参考一些公开发表的数据。
(2)进度中的并行性:
一般软件项目经常是很多人同时参加工作,因而项目工作中就会出现并行的情形。
进度安排的方法:
进度是计划的时间表。
软件项目的进度安排与任何一个多重任务工作的进度安排类似。
为了清楚地表达各项任务之间进度的相互依赖关系,采用图示方法。
常用的有
(1)甘特图:
甘特图(GanttChart),又称横道图,是各种任务活动与日历表的对照图。
它用水平线段来表示任务的工作阶段,其中线段的长度表示完成任务所需要的时间,起点和终点分别表示任务的开始和结束时间。
优缺点见P83;
(2)网络图:
用网络分析的方法编制的进度计划称为网络图,它是20世纪50年代末发展起来的一编制大型工程进度计划的有效方法。
第五章软件项目风险管理
风险:
定义为损失的可能性。
风险具有两大属性:
可能性和损失。
可能性是风险发生的概率,损失是指预期与后果之间的差异。
风险管理:
项目风险管理就是贯穿于项目开发过程中的一系列管理步骤。
风险管理人员通过风险识别,风险分析,合理使用多种风险管理方法、技术与手段对项目风险实施有效的控制,以尽可能少的成本保证安全可靠地实现项目目标。
任何项目,只要采用了风险管理,并且由此产生的后果都可以接受时,我们就说解除了风险。
风险管理过程包括两个主要活动。
第一是风险评估,为风险下定义。
风险评估是一个识别风险来源及评估它们潜在影响的发现过程。
第二是风险控制,目的在于解除风险。
风险控制是一个开发风险解除计划,监视风险状态,实施风险应对计划和纠正计划偏差的过程。
软件风险:
软件风险是有关软件项目、软件开发过程和软件产品损失的可能性。
分为
(1)软件项目风险、
(2)软件过程风险和(3)软件产品风险
软件风险管理:
软件风险管理是对影响软件项目、过程或产品的风险进行估计和控制的实践过程。
从目标逆向思维可发现软件风险。
首先,定义目标。
然后根据不确定性、损失和时间来描述风险。
风险管理同项目管理的关系:
软件风险管理是整个项目管理的一部分。
面对有限的资源、有待改进的技术以及瞬息万变的环境,对复杂系统的强烈需求,要求管理人员必须具备管理项目不确定性的能力。
风险管理与项目管理的目标一致;风险管理为项目计划的制定提供了依据;项目风险管理通过风险分析,指出有哪些可能的计划外费用,并估计它的多少;许多风险都在项目实施过程中由潜在变为现实。
软件风险管理的主要内容:
(1)制定风险管理计划;
(2)风险识别;(3)风险分析;(4)风险计划;(5)风险跟踪;(6)风险应对;(7)风险管理验证
风险识别过程:
将项目的不确定性转变为风险陈述的过程。
它包括以下活动:
(1)进行风险评估;
(2)系统地识别风险;(3)风险定义及分类;(4)将风险编写为文档
风险识别的工具与技术:
头脑风暴法:
召集项目组全体会议,进行关于项目风险的自由讨论,项目组成员完全自由地发言,不受限制,产生关于项目风险的概念。
该方法是一种智力爆发的方法,因此项目经理和技术权威不太适合参加这种讨论。
同时还应坚持不进行过多讨论,不对别人的意见进行判断性评论,甚至明确不许使用身体语言表达评判意见,如:
咳嗽、冷笑等。
这样做的目的是最大限度地发挥民主,搜集来自项目各方面的意见。
意见可以是多余的,但尽可能不要遗漏任何重要信息。
风险应对:
风险应对就是处置风险的过程。
我们无法完全避免风险,对某些风险也无需完全避免。
重要的是把风险置于人们控制之下。
第六章软件项目配置管理
配置管理概念:
软件项目配置管理中涉及很多概念:
(1)软件:
配置管理中的软件是指由逻辑和功能特性构建的信息。
在整个开发过程中,它以多种形态和表现被创建和维护。
(2)配置:
配置由部件表和部件分解图组成。
部件分解图定义了基线中包含的所有要素以及如何将它们安装在一起。
(3)标识:
识别产品的结构、产品的构件及其类型,为其分配惟一的标识符,并以某种形式提供对它们的存取。
(4)软件配置项:
软件配置项SCI(softwareConfigurationItem)是为了配置管理的目的而作为一个单位来看待的软件要素的集合例子见表6.2。
(5)版本:
是一个基线或一个软件配置项的特例。
(6)基线:
是开发过程的里程碑,以一个或多个软件配置项的交付为标准:
基线由通过正式评审的软件配置项组成,是进一步开发的基础;基线只有通过正式的变更控制过程才能改变。
(7)控制:
通过建立产品基线,控制软件产品的发布和在整个软件生命周期中对软件产品的修改。
(8)状态统计:
记录并报告构件和修改请求的状态,并收集关于产品构件的重要统计信息。
(9)审核:
确认产品的完整性并维护构件间的一致性,即确保产品是一个严格定义的构件集合。
(10)生产:
对产品的生产进行优化管理。
它将解决最新发布的产品应由哪些版本的文件和工具来生成的问题。
(11)过程管理:
确保软件组织的规程、方针和软件周期得以正确贯彻执行。
它将解决要交付给用户的产品是否经过测试和质量检查的问题。
(12)小组协作:
控制开发统一产品的多个开发人员之间的协作。
例如,它将解决是否所有本地程序员所做的修改都已被加入到新版本的产品中的问题。
(13)配置控制委员会:
负责评审和批准对基线的变更,通常由项目选出的代表组成。
软件配置管理
配置管理CM(ConfigurationManagement)是在系统生命周期中对系统中的配置项进行标识和定义的过程。
该过程是通过控制配置项的发布及后续变更、记录并报告配置项的状态及变更请求、确保配置项的完整性和正确性来实现的。
软件配置管理SCM(SoftwareConfigurationManagement)是应用于由软件组成的系统的配置管理,通过一套工程规范,在整个软件生命周期中跟踪、记录软件,保证全部变更都记录在案,并保证软件的当前状态是已知的和可重复的。
配置管理功能
配置标识:
配置标识惟一的标识软件配置项,使它们可用某种方式访问。
配置标识的目标是在整个系统生命周期中标识系统的构件,提供软件和软件相关产品之间的追踪能力。
配置控制:
配置控制是在软件生存周期中控制软件产品的变更和发布,其目标是建立有助于确保软件质量的机制
(1)版本控制:
在软件产品开发过程中以及产品发布以后可靠地建立和重新创建版本是软件配置管理的一个必备功能。
在开发过程中,会建立产品的中间版本,并按照常规对其进行测试。
因为经常需要回到以前的版本,所以要能准确地重建以前的版本。
开发完成后,还需要管理发布给用户的软件版本,因而必须对所有必要的信息进行维护,如编译程序、连接程序以及使用的其他工具,以确保每一个已发布的软件产品版本能够重建。
(2)变更管理:
有模块变更管理和基线管理
模块变更管理:
①差异代码管理:
差异代码管理把基本的代码部分和差异代码分开。
对基本代码进行维护时,只要不涉及与差异代码的接口,补充简要的防止误用说明后就可以直接进行变更。
同样,也可以单独对差异代码进行维护,但不能涉及到基本代码部分。
②条件代码管理:
条件代码管理面对的问题是从几种可供选择的模块中选择一种,以实现特定功能。
此时所有情况下的模块都在模块库中,但每次只使用一个。
使用条件代码时,只有一个模块,差异表现在条件代码中。
基线管理:
基线是软件开发过程中的特定点,其作用是使软件项目各个阶段的划分更加明确,使本来连续的工作在这些点上断开,以便于检查和肯定阶段成果。
基线由软件配置项组成,是软件配置管理的基础,为以后的开发工作建立了一个标准的起点。
随着软件配置项的建立,产生了一系列基线(见图6.9)。
对这些基线必须进行管理和控制。
配置状态报告:
配置状态报告的目的是提供软件开发过程的历史记录。
内容包括软件配置项当前的状态及何时因何故发生了变更,使相关人员了解配置和基线情况。
配置管理人员应定期或在需要的时候提交配置状态报告。
配置状态报告主要描述配置项的状态、变更的执行者、变更时间和对其他工作有何影响。
配置状态报告的结果存入数据库中,管理者和开发者可以查询变更信息并对变更进行评估。
基于构件的配置管理:
软件复用:
软件复用是在软件开发中避免重复劳动的解决方案,其出发点是软件项目的开发不再采用“一切从零”开始”的模式,而是以已有的工作为基础,充分利用过去项目开发中积累的知识和经验,将开发的重点集中于项目的特有构成成分。
通过软件复用,在应用系统开发中可以充分地利用已有的开发成果,消除了包括分析、设计、编码、测试等在内的许多重复劳动,从而提高了软件开发的效率。
同时,通过复用高质量的已有开发成果,避免了重新开发可能引入的错误,从而提高了软件的质量。
项目开发中的重复劳动主要在于下述前两类构成成分的重复开发。
软件项目通常包括如下三类成分:
(1)基本构件:
是特定于计算机系统的构成成分,如基本的数据结构、用户界面元素等,它们可以存在于各种软件项目中。
(2)领域共性构件:
是软件项目所属领域的共性构成成分,它们存在于该领域的各个软件项目中。
(3)应用专用构件:
是每个软件项目的特有构成成分。
软件构件技术
构件是软件系统中多个相关文件构成的一个逻辑整体,如一个完整的功能模块。
构件是指软件系统中可以明确辨识的构成成分。
可复用构件是指具有相对独立的功能和可复用价值的构件。
软件产业要发展并形成规模经济,标准构件的生产和构件的复用是关键因素,这也正是软件复用受到高度重视的根本原因。
基于构件的版本管理
版本管理的粒度:
基于构件软件开发方法物理上表现为多个文件之集合体的构件是系统的有机构成成分,在开发过程中是作为一个原子单位使用的。
系统的开发者关心的是构件整体的开发、演化(传统的版本管理以文件作为管理的基本粒度,记录、维护每个文件的演化历史)。
以构件为粒度的版本管理有以下特点:
(1)构件的抽象级别比文件高。
构件是应用系统中可以明确辨识的构成成分,记录、维护构件的版本比文件的版本管理更有意义。
(2)构件的粒度可以比文件大很多。
一个项目中可能有诸多分布的逻辑单元,这些逻辑单元与构件相对应,构件的数量较少且整体逻辑意义明显,可以更清晰地体现项目的演化历史。
(3)在构件基础上,可以体现出系统的层次性、构造性等特征,同时构件版本管理也可以满足对文件版本的管理需求,使版本管理既有大粒度,又有灵活性。
第七章软件项目资源管理
人力资源管理
具体的工作是由如下任务所组成:
(1)进行人力资源规划和分析,包括:
人力资源规划、人力资源分析、人力资源信息和评价系统;
(2)贯彻平等就业机会原则;(3)聘任员工,包括:
招聘、选拔;(4)规定员工与劳资关系,包括:
健康、人身安全与财务安全;员工权利与人力资源政策;工会与资方关系;(5)制定报酬和福利制度,包括:
工资与薪水管理、制定奖励制度、制定福利制度。
人力资源计划的平衡:
在制定人力资源计划时,就要在基本按照项目前后期用人少、中间用人多的状况配备人力的同时,尽量使某个阶段的人力稳定,确保整个项目期人员的波动不要太大。
软件资源管理
软件资源的可复用性:
在软件开发的过程中,应该尽可能地重复使用以前开发活动中曾经积累或使用过的软件资源。
这些软件资源被称为可复用软件资源。
这些软件资源不仅包括源代码,还包括软件开发方法、需求规格说明、设计结构、开发工具与支撑环境、测试分析数据和维护信息等。
软件复用技术不仅可以提高软件生产率和软件质量,而且也是降低开发成本、缩短开发周期的重要途径。
可复用软件资源的管理:
为提高软件生产率和软件质量,需要把有重用价值的软件模块或控件收集起来,再把相关的资料组织在一起,标注说明,建立索引,从而建立可复用的软件部件库。
软件构件库的建立和使用、维护,是实现可复用软件资源管理的主要内容。
硬件资源管理:
软件项目中的硬件资源包括:
(1)宿主机,即软件开发阶段所使用的计算机和外围设备。
(2)目标机,即运行所开发软件的计算机和外围设备。
(3)其他硬件设备,指专用软件开发时所需要的特殊硬件资源。
硬件资源的管理是指硬件设备运行全过程的管理,包括对设备经济状态和技术状态的全面管理。
经济管理首先是固定资产的管理,包括硬件设备的计价与硬件设备的折旧两项具体内容。
设备的技术管理包括硬件设备的选择、维护及更新
第八章软件项目质量管理
质量管理的概念:
软件质量:
(1)从用户的角度看,软件运行可靠,不死机,界面友好,系统运行速度快,结果正确,产品交货及时,服务好。
(2)从软件开发人员角度看,质量好的软件应该是技术上没有差错,符合标准及规范的要求,技术文档齐全正确,并且系统容易维护。
(3)专业人员使用的指标用以衡量软件的质量:
每千行代码中包含的缺陷数。
国家标准对软件质量可用六个特性来评价:
功能性、可靠性、可用性、效率、可维护性和可移植性。
详见P152。
软件产品质量与过程质量:
近年来质量管理向过程质