西安交通大学 刘海岩 1
第 2章 软件项目管理
软件项目管理的概念
软件度量
软件项目计划
项目进度安排与跟踪
软件质量管理
软件配置管理西安交通大学 刘海岩 2
2.1 软件项目管理的概念
项目,以一套独特而相互联系的任务为前提,有效的利用资源,为实现一个特定目标所作的工作。
项目的成功受以下几个因素的制约:
技术范围、成本、进度、用户满意度、人员等。
项目管理的职责,确保项目目标的实现,即在预算内按时完成质量合格的产品。
软件项目管理,是对传统项目管理进行软件工程化的一种扩展与拓延,是它在软件工程的任何技术活动之前开始,并持续贯穿于整个软件定义、开发和支持阶段的庇护性活动,是 决定一个产品或项目能否成功最重要的指标之一。
西安交通大学 刘海岩 3
4个 P( People,Product,Process,Project)
对软件项目管理有实质性的影响:
人员 必须被组织成有效的开发团队。
产品 需求被划分成较小的组成部分,便于分配给软件开发小组。
开发 过程 应根据人员和产品选择合适的开发模型。
项目 必须被组织成便于控制和管理的方式,使有计划的进行。
西安交通大学 刘海岩 4
◆ 人员,
人员是一个成功软件项目中最重要的因素。
可分为 5类:
⑴高级管理者:负责定义业务问题,影响着项目。
⑵技术管理者:组织、激励和控制开发人员。
⑶开发人员:负责开发一个产品或应用所需的技术。
⑷客户( customer),负责说明待开发的软件需求。
⑸最终用户( user),直接使用发布的软件。
西安交通大学 刘海岩 5
每一个软件项目都有上述的人员参与。必须被组织成有效的小组,最大限度的发辉每个人的技术和能力,激励他们进行高质量的工作,并协调他们实现有效的通信。 Constantine
提出 4个,组织范型,,
(1) 封闭式范型,传统的控制层次,垂直通信,难以创新。
(2) 随机式范型,小组管理较松散,依赖于成员个人的主动性。不适合,有次序地完成,。
(3) 开放式范型,具有封闭式范型的控制性,又包含随机式范型的创新性。适合于解决复杂问题。可能不像其他类型小组那么有效率。
(4) 同步式范型,依赖于问题的自然划分,小组成员各自解决问题的独立部分。主动通信差。
建立一个有凝聚力的小组,要有团队精神 。
西安交通大学 刘海岩 6
◆ 产品,
进行项目计划之前,应该首先定义产品的 目的 和 范围,
考虑可选的解决方案,标识技术和管理的约束。无这些信息,就不可能进行合理的、准确的成本估算、有效的风险评估、适当的项目任务划分、可管理的项目进度安排。
,目的,指从用户的角度标识出该产品的总体目标而不考虑这些目标如何实现。
,范围,指标识出与产品相关的主要数据、功能和行为。
确定了目的和范围,就可以根据产品交付的期限、预算的限制、可用的人员、技术接口及各种其他因素,选择最好的解决方案途径。
西安交通大学 刘海岩 7
◆ 过程根据以下条件选择一个合适的软件过程模型:
⑴开发人员及需要该产品的用户
⑵产品本身的特征
⑶项目组的工作环境采用如下的框架活动集合:
客户交流、计划、风险分析、工程实施、构造及发布、用户评估。这些活动可被修改以适应不同软件项目的特征和项目组的需求。每个活动可被分解为更详细的工作任务。
如客户交流活动可能需要下列任务:
西安交通大学 刘海岩 8
⑴列出需要澄清问题的清单
⑵安排与用户进行讨论的会议
⑶评审用户要求及范围的陈述
⑷研究推荐的解决方案
⑸为正式的会议准备工作文档
⑹共同制订能反映软件的数据、功能和行为特征的规约,形成软件范围的文档
⑺评审文档
⑻根据需求修改文档
……
庇护性活动贯穿于整个过程。
西安交通大学 刘海岩 9
◆ 项目有计划的控制软件项目,Boehm提出了一种方法,
强调项目目标、里程碑、进度、责任、管理和技术方法以及需要的资源,称之为 W5H2原则。通过下面一系列的提问和回答,可以导出项目的关键特征并产生项目计划的大纲:
⑴为什么( Why)该系统被开发?值得吗?
⑵将做什么( What)? 什么时候 (When)做?
建立项目进度,标识关键的项目任务和里程碑。
⑶某功能由谁( Who)负责?开发人员的角色和责任。
⑷哪里需要( Where)?客户、用户和其他投资者也有责任。
⑸工作将如何( How)进行?定义项目的管理和技术策略。
⑹资源需要多少 (How much)?
西安交通大学 刘海岩 10
软件项目管理中的主要元素及之间的关系开发人员、小组、角色、任务、
工作产品、进度表( UML类图)之间的关系西安交通大学 刘海岩 11
软件项目管理的主要内容:
定义问题 (确定新系统的作用域 -目标)
确认项目的可行性
建立项目的进度计划
建立项目的质量保证体系
建立项目配置管理体系和准则
项目版本变更管理
跟踪、监控项目的进展
风险管理
团队建设(人员管理,包括绩效评估等)
西安交通大学 刘海岩 12
2.2 可行性研究
1,可行性研究的任务和目的
GB 8566-88,计算机软件开发规范》中指出:
可行性研究的主要任务是了解客户的要求及现实环境,从技术、经济和社会因素等方面研究并论证本软件项目的可行性,编写可行性研究报告供项目管理人员评审,以便作出是否开发软件项目的决策。
西安交通大学 刘海岩 13
◆技术可行性度量一个系统解决方案的实用性及技术资源的可用性。
考虑的问题,
(1)开发风险分析
(2)资源分析
(3)相关技术的发展(现有技术能否实现新系统、
技术难点、建议采用技术的先进性)
西安交通大学 刘海岩 14
◆经济可行性主要内容:
成本 /效益分析不可能得到精确的分析结果
系统成本,
①软件开发费用
②购置并安装软硬件机有关设备的费用 估算
③系统安装、运行和维护费用
④人员培训费用
系统效益 包括经济效益和社会效益经济效益,可通过直接的或统计的方法估算社会效益:定性的方法估算西安交通大学 刘海岩 15
◆社会因素可行性政策、法律、使用、环境等
2、可行性研究的步骤
(1)复查确认系统目标、规模
(2)研究现行系统的工作流程
(3)导出目标系统高层逻辑模型
(4)导出和评价供选择的方案
(5)推荐可行的方案
(6)编写可行性研究报告,送审西安交通大学 刘海岩 16
3、可行性研究报告的编写提示
( 1)引言:编写目的、背景、定义、参考资料;
( 2)可行性研究的前提:要求、目标、条件、假定和限制、进行可行性研究的方法、评价尺度;
( 3)对现有系统的分析:工作流程、工作负荷、
费用开支、人员、设备、局限性;
( 4)所建议的系统:说明、数据流程和处理流程、
改进之处、影响、局限性、技术条件的可行性;
( 5)可选择的其它系统方案;
( 6)投资及收益分析:支出、收益、收益 /投资比、
投资回收期等;
( 7)社会条件方面的可行性(法律、使用)。
西安交通大学 刘海岩 17
例,一个软件系统的开发费用(一次):
人员,
2名系统分析员 (450小时 /名,45美元 /小时 ) $40,500
5名系统开发人员 (275小时 /名,36美元 /小时) $49,500
1名数据通讯专家 (60小时 /名,42美元 /小时 ) $2,520
1名数据库管理员 (30小时 /名,42美元 /小时 ) $1,260
2名技术写作者 (120小时 /名,25美元 /小时 ) $6,000
1名秘书 (160小时 /名,15美元 /小时 ) $2,400
2名在转换期间数据输入人员 $960
( 40小时 /名,12美元 /小时 )
西安交通大学 刘海岩 18
培训,
三天的开发人员内部培训课程 $7,000
30个用户,三天的内部培训课程 $10,000
复印 $500
磁盘、纸张等消耗品 $650
购买硬件、软件,
20台工作站 Windows软件 $1,000
20台工作站内存升级 $8,000
网络软件 $17,500
20台工作站办公软件产品 $20,000
系统开发总费用 $167,790
(成本)
西安交通大学 刘海岩 19
一个系统的年运行费用(每年),
人员:
维护程序员 /分析员 (250小时 /年,42美元 /小时 )
$10,500
网络管理员 (300小时 /年,50美元 /小时 )
$15,000
购买硬件、软件升级:
硬件 $5,000
软件 $6,000
物资和杂项 $3,500
每年总运行费用 $40,000
西安交通大学 刘海岩 20
2.3 软件度量软件度量( metrics)域分为过程度量、项目度量和产品度量。对过程、项目及产品的特定属性进行度量产生指导管理及技术动作的指标,使得管理者和开发者能够:
改善软件过程
辅助软件项目计划
跟踪及控制软件项目的进展
评价软件产品的质量西安交通大学 刘海岩 21
软件度量的方式:
直接度量间接度量
软件工程过程的 直接度量 包括所投入的成本和工作量。
软件产品的 直接度量 包括产生的代码行数( LOC)、
执行速度、存储量大小、在某种时间周期中所报告的错误数。
软件产品的 间接度量 包括功能性、复杂性、效率、
可靠性、可维护性和许多其它的质量特性。
西安交通大学 刘海岩 22
1,过程和项目的度量
◆ 过程度量,
使一个组织从战略上考察已有过程的功效,如开发范型、工程任务的划分、工作产品、里程碑等,使管理者评估那些部分起了作用。度量数据的收集跨越所有的项目,
经历较长的时间,目的是改善软件过程。
间接的度量一个软件过程的功效:
软件发布之前发现的错误数
交付给用户后报告的缺陷数
花费的工作量、时间、成本
与进度计划是否一致西安交通大学 刘海岩 23
个体软件过程(如 PSP) 提供了表格、脚本、标准以帮助开发人员估算、计划以及度量、跟踪自己工作的方法。
过程度量对于一个组织(如企业)提高其总体的过程成熟度能提供很大的帮助。如一个产品中,需求规约缺陷占了 25.5%,原因如图所示。
通过分析一个完整的鱼骨图可以导出能改进软件过程以降低错误和缺陷率的频率。
西安交通大学 刘海岩 24
◆ 项目度量:
是战术的,使项目管理者能够以 实时 的方式改进项目的工作流程及技术方法,如软件项目的工作量及时间的估算。
项目度量的基础 是历史项目中收集的数据。随着项目的进展,所花费的工作量及时间和预算的值进行比较,
从而控制项目的进展。
另外,可根据文档的页数、评审的时间、功能点及源代码行数来度量软件的生产率。
西安交通大学 刘海岩 25
项目度量可在项目进行的基础上评估产品的质量,
以指导在必要时修改技术方法以改进质量。
软件项目度量建议每个项目都应该测量:
输入:完成工作所需要的资源(如人员、环境);
输出:软件工程过程中产生的工作产品;
结果:最终产品的有效性。
项目度量集成起来产生对整个软件组织公用的过程度量。
西安交通大学 刘海岩 26
2,软件度量的方法
( 1)面向规模的度量是对软件和软件开发过程的直接度量。
可以建立一个面向规模的数据表格来记录项目的某些信息。该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据 。
西安交通大学 刘海岩 27
基于所生产软件的,规模,,使用代码行作为其他计算的规范化因子。计算:
每千行代码( KLOC) 的错误数。
每 KLOC 的缺陷数。
每个 LOC的花费成本。
每 KLOC 的文档页数
每人月的错误数。
每人月的代码行。
每页文档的成本。
西安交通大学 刘海岩 28
可制作一个如下的表:
对该方法的有效性有争议:
支持,易计算,很多软件估算模型以它为关键的输入。
反对,LOC依赖于语言,不适用于非过程化语言,在分析与设计完成之前难以估算。
项目名 KLOC 工作量
(人月)
成本
(万元)
文档页数错误 缺陷 人员
BETA 12 36 10 155 60 8 5
西安交通大学 刘海岩 29
( 2)面向功能的度量
,功能,不能直接测量,利用其他的测量数据间接地导出。 Albrecht提出来的一种称为 功能点 的度量。用下表计算 5个信息域的值:
西安交通大学 刘海岩 30
其中:
用户输入数:每个用户向系统提供的不同应用的输入数据。
用户输出数:系统向每个用户提供的信息,如报表、屏幕信息、出错信息等。
用户查询数:每个不同的询问 /响应的交互操作。
文件数,可以是数据库的一部分或是一个独立的文件。
外部接口数:与系统中其他设备通过外部接口读写信息的次数。
,简单、平均、复杂,中的常量值是加权因子,
根据经验确定。
西安交通大学 刘海岩 31
利用以下公式计算功能点( FP):
FP=总计数值 × ( 0.65+0.01 ×? Fi)
其中 Fi( i=1~14)是回答 14个方面问题而得到的复杂度调整值(值域为 0~5),如输入、输出、查询及内部处理复杂吗?代码复用吗?有分布处理吗等等(详见
p 64)。
计算出功能点。就可进行以下度量:
每个功能点的错误数。
每个功能点的缺陷数。
每个功能点的成本。
每个功能点的文档页数。
每人月完成的功能点数。
西安交通大学 刘海岩 32
代码行和功能点度量之间的关系依赖于实现软件所采用的程序设计语言及设计的质量。下面给出了在不同的程序设计语言中建造一个功能点所需的平均代码行数的统计:
程序设计语言 LOC/FP
汇编语言 320
C 128
FORTRAN 106
Pascal 90
C++ 64
Java 46
Visual BASIC 32
Power Builder 16
SQL 12
西安交通大学 刘海岩 33
3、软件质量度量软件工程的目标是产生高质量的系统或产品。质量依赖于描述问题的需求、建模、设计、编码、测试。
质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。应评估分析与设计模型、源代码、测试案例的质量。
西安交通大学 刘海岩 34
在软件交付之前得到的度量数据 可作为判断设计和测试质量好坏的依据。这一类度量包括程序复杂性、有效的模块性和总的程序规模。
在软件交付之后的度量数据 则把注意力集中于还未发现的缺陷数和系统的可维护性方面。
Mc Call 提出了影响软件质量的 11个因素 (详见 P367),
其中重要的有以下几点:
正确性:软件完成所需功能的程度,最常用
,缺陷数 /kLoc”来测量。
西安交通大学 刘海岩 35
可维护性:遇到错误时程序能被修改的容易程度、
环 境变化时 程序能被适应的容易程度、
用户希望改变需求时程序能被增强的容易程度,一种最简单的测量方法是 计算平均修改时间( MTTC)。
完整性,测量系统在安全方面的抗攻击性。
完整性= Σ[(1-威胁 )× (1-安全性 )]
其中威胁是某个特定类型的攻击在给定时间内发生的可能性。安全性是某个特定类型的攻击将被击退的可能性。
可用性,用户友好性。
另外还有可靠性、效率、可测试性、可移植性、可复用性等等。
西安交通大学 刘海岩 36
2.4 软件项目计划项目计划既指出了项目组织未来努力的方向和奋斗目标,又是当前行动的准则。
针对不同工作目标,软件项目计划有:
项目实施计划(软件开发计划) 这是软件开发的综合性计划,通常应包括任务、进度、人力、环境、资源、组织等多个方面。
质量保证计划 把软件开发的质量要求具体规定为每个开发阶段可以检查的质量保证活动 。
软件测试计划 规定测试活动的任务、测试方法、
进度、资源、人员职责等 。
西安交通大学 刘海岩 37
文档编制计划 规定所开发项目应编制的文档种类、
内容、进度、人员职责等。
用户培训计划 规定对用户进行培训的目标、要求、
进度、人员职责等。
综合支持计划 规定软件开发过程中所需要的支持,
以及如何获取和利用这些支持。
软件发布计划 软件开发项目完成后,如何提交给用户。
这里,主要针对综合计划来介绍。
西安交通大学 刘海岩 38
项目管理是一个创造的过程,项目早期的不确定性因素,使计划不可能在启动阶段就全部一次完成,需逐步展开和不断修正,这又取决于计划执行情况的反馈与及时的信息交流。
制订项目基准计划 (Baseline Plan)的步骤:
① 定义项目目标,确定软件范围
② 把项目按项目范围分解为多个任务
③ 确定对应每个任务必须执行的活动
④ 将每个任务分配给一个小组,并为每个开发者分配角色和职责
⑤ 用 Gantt图或 PERT图表示出项目的进度西安交通大学 刘海岩 39
1、软件项目估算项目计划的一个重要的前提是项目估算(有时在可行性研究阶段完成),一般以团队的历史经验为基础,让团队中的一线人员参与估算,才能保证项目计划的可行性。
成本及工作量的估算不是一门精确的科学,有几种选择:
基于已完成的类似项目进行估算;
使用分解技术以生成项目成本及工作量的估算;
使用一个或多个经验模型;
( 1) 分解技术分解技术采用,分而治之,的策略进行软件项目估算。
将项目分解成若干主要功能及相关的软件过程活动,通过逐步求精的方式进行成本及工作量估算。具体方法为:
西安交通大学 刘海岩 40
划分主要的软件功能,接着估算:
① Loc的数量
② 对于 FP,估算每个信息域特征(输入、输出、数据文件、查询、外部接口)及 14个复杂度调整值
③ 实现每个功能所需的人月数
④ 每个软件过程活动所需人月数基本的估算方法:
自顶向下估算:
总成本 按阶段、步骤、工作单元
自底向上估算:
先划分,分别估算每个子任务所需的工作量,
然后 ∑。
西安交通大学 刘海岩 41
差别估算法:
与类似项目比较,估算每个不同之处对成本的影响。
还有专家估算法等等。
( 2)经验估算模型经验估算模型可用于补充分解技术,并提供一种潜在有价值的估算方法。该模型是基于经验(历史数据)
的,可以用下面的形式表示:
=?()
其中? 是要估算的值(如工作量、成本、项目持续时间)之一,是选择出来的独立参数(如被估算的 Loc或
FP)。
西安交通大学 刘海岩 42
由经验导出的公式,最著名的是 COCOMO模型,构造型成本模型( COnstructive COst MOdel)。 初期的模型广泛的使用于软件成本估算,发展到反映不同阶段的成本。
初始模型的分类,
基本 COCOMO模型是静态单变量模型,用源代码行数 (LOC) 为自变量的经验函数计算软件开发工作量。
中间 COCOMO模型该模型在用 LOC为自变量的函数计算软件开发工作量的基础上,用涉及产品、硬件、人员、项目等方面的影响因素调整工作量估算。
详细 COCOMO模型该模型包括中间 COCOMO模型的所有特性,但用上述各种影响因素调整工作量估算时,还要考虑对软件工程过程中每一步骤(分析、设计等)的影响。
西安交通大学 刘海岩 43
模型的扩展,
COCOCOMⅡ 使用 对象点、功能点、源代码行 作为不同层次模型的参数。
对象点 只是一种间接软件测量数,使用以下计数:
① 用户界面上的屏幕数
② 报表数
③ 建立应用软件需要的构件数。
每个对象实例(如一个屏幕或一个报表)给出三个复杂度权数(简单、中等、复杂),如一个屏幕的权简单为 1,
中等为 2,复杂为 3。
通过以下公式计算总对象点数:
西安交通大学 刘海岩 44
Σ ( 初始的对象实例数×加权因子)=总的对象点( NOP)
当应用基于构件的开发时,对象点计数调整为:
NOP= NOP× [(100-%复用 )/100]
进而计算:生产率= NOP/人月针对不同级别的开发者经验和开发环境成熟度,给出对象点的生产率:
非常低 低 额定 高 非常高
4 7 13 25 50
项目工作量= NOP/生产率西安交通大学 刘海岩 45
2、项目进度安排项目计划中的一个重要内容是建立进度表,该表对项目进度进行科学度量、调整项目计划起很重要的作用。在众多软件项目中,缺乏合理的进度安排是造成项目泄后的最主要原因。进度安排为项目管理者和开发者建立了一张行路图。
( 1)进度安排的指导原则,
划分,项目分解成若干易于管理的任务。如何进行任务的分解呢?可从两个方面获得帮助:
① 软件开发模型,模型帮助将整个项目进行阶段性的划分,这些阶段可以做计划中很重要的里程碑 。
② 软件开发需求,开发模型只给项目计划提供了个框架,
需求的整理与规格化,是细化项目计划的基础。
西安交通大学 刘海岩 46
相互依赖性,各个被划分的活动或任务之间的相互关系必须是确定的。有些任务必须顺序进行,有些可以并发进行。
时间分配,必须为每个被调度的任务分配一定数量的工作单位(如,人天、人月),并指定开始和结束日期。
工作量确认,每个项目都有预定数量的人员参与。在进行时间分配时,必须确保在任意时段中分配给任务的人员数量不会超过项目组中的人员总量。
定义的责任,每个被调度的任务都应该指定某个特定的小组成员来负责。
定义的结果,每个被调度的任务都应该有一个定义好的输出结果,输出结果通常是一个工作产品或某个工作产品的一部分。
定义的里程碑,每个任务或任务组都应该与一个项目里程碑相关联。当一个或多个工作产品经过质量评审并且得到认可时,标志着一个里程碑的完成。
西安交通大学 刘海岩 47
( 2)工作量分配 (指导原则)
计划 需求分析 设计 编码 测试
2% ~3% 10%~25% 20%~25% 15%~20% 30%~40%
(3) 进度表(图)
甘特图 ( Gantt Chart)
也称时间表,所有的项目任务都在左边的栏目中列出。
水平条表示每个任务的持续时间,当同一时间段中存在多个水平条时,表示任务之间存在并发。
PERT(Program Evaluation Review Technique)图也称任务网络图,表示一个项目的任务流程,刻画了各项任务、任务之间的依赖关系及任务的持续时间。它的最简单形式可当作宏观进度表使用。
西安交通大学 刘海岩 48
Gantt图
Gantt图可清晰的表达每个任务活动的进展以及并发活动。水平条的颜色既可以表示概要任务和详细任务的分解,
也可以表示任务完成的情况。用一个特定的符号(如黑菱形)
表示一个活动的结束(里程碑),以便检查阶段成果和最后成果。
西安交通大学 刘海岩 49
PERT图
PERT图另一个重要的用途是用来判断关键路径,关键路径表明了完成该项目可能需要的最小时间,并能识别最有可能成为瓶颈的活动,该路径上的活动是项目负责人或小组长抓的主要工作。非关键路径上的活动延迟,不会导致项目总体进度偏离。 下图是一个项目的总的 PERT图。
西安交通大学 刘海岩 50
西安交通大学 刘海岩 51
说明:
① 考虑进度表中的变化:
建立进度表时,项目分解为哪些任务以及任务持续的时间往往根据历史数据估算而来,项目进展过程中未预料到的事件,如需求的变化或较晚发现的设计缺陷,都会打乱进度表,因此在进度表中为将来可能的变化留有余地。
② 进度表可有不同的抽象层次:
高层进度表反映整个项目的进度,应包括所有可交付产品的期限,底层进度表是任务和时间的分解。可制作短期内的进度表,其余部分在项目进行过程中完成。底层进度表可用于指导每个小组的进度。
③ 每个里程碑可以附带一个标识进度值的百分比,用来说明项目完成了多少,如,30%。
西安交通大学 刘海岩 52
项目开展阶段管理活动图( UML活动图)
2.5 项目进度的跟踪西安交通大学 刘海岩 53
1,项目启动 进行项目计划
2,项目开展 项目的监督与跟踪
( 1)收集状况信息的方式
定期报告,非正式的会议和交流,报告工作产品、
进度误差等需要及早沟通的信息。
里程碑的监督与验证,里程碑可以是事件,也可以是工作产品,验证是否在预定时间内完成。
项目检查,正式会议,所有开发人员交换活动进展状况,比较各项任务实际开始日期与计划开始日期。
代码检查,同事之间的正式代码检查。
原型示范,原型是为了验证需求或为了评估技术和功能而部分实现的系统,可用来估算初始进度。
西安交通大学 刘海岩 54
度量,主要是修正错误数目的度量,即还需要付出多少努力的估量。
( 2) 项目再计划根据项目的变化动态更新项目计划,应对一些新的需求、新的变化、突发因素做出响应,或解决问题以适应计划,或调整计划以保证最后按时交付产品。
( 3)风险管理风险是一些不利因素实际发生的可能性。如:人员跳槽,管理层变更,硬件缺乏,需求变化,描述延迟,
低估了系统的规模,工具性能差,技术变更,产品竟争等等。
西安交通大学 刘海岩 55
风险管理的活动有:
风险识别:确定风险的类型(管理、技术)。
风险分析:评估风险出现的可能性及其后果。
风险规划:制定避免或降低风险的策略。
风险控制:定期进行风险评估,及时修正缓解风险的计划。
3、项目总结
用户验收,根据项目协议中规定的验收标准对系统进行评价,并通过场景演示,测试系统功能性和非功能性需求。
安装,在目标环境下安装、运行系统并提交文档。
总结,总结经验教训,建立团队工作效率的历史档案,
以便提高个人和团队整体的软件工程能力。
西安交通大学 刘海岩 56
2.6 软件质量保证
1,概述软件质量是软件产品、体系或过程的一组固有特性满足(顾客和其他相关方)要求的程度。
软件质量保证 (Software Quality Assurance,SQA)是一种应用于整个软件过程的庇护性活动,包含:
质量管理方法
有效的软件工程方法和工具
过程中采用的正式技术评审
多层次的测试策略
对软件文档及其修改的控制
保证与开发标准符合的规程
软件度量及报告机制等等方面的内容西安交通大学 刘海岩 57
软件质量保证的对象一般有三方面:
产品、过程和质量体系实施软件质量保证需运用几种支持过程作为质量保证的手段。
验证或确认,通过提供客观证据对规定要求已得到满足的认定。
评审或审核,确定主题事项达到规定目标的适应性、充分性和有效性所进行的活动。联合评审是由任何两方(评价方和被评价方)用来在适当时机对项目的某个活动的状态和产品进行评价并可能形成文件的过程。
西安交通大学 刘海岩 58
2、软件质量保证过程中的数据
SQA过程中必然产生有关产品、过程和体系质量的多种数据,是进行下一步工作的决策依据,对于提高质量管理效果和改进质量管理过程至关重要。要收集、存储、及时分析和使用这些数据,才能做好质量保证工作。
质量数据有多种:
项目规模,FP表示软件大小,以功能点计数 ;
工作量 E,表示项目的人力总投入,以人月计数 ;
生产率,P=FP/E;
缺陷数,D1表示软件交付前发现的错误数,D2表示交付后发现的缺陷数;
质量,Q=D2/FP,表示每个功能点包含多少交付的缺陷,
缺陷引入率,DI=(D1+D2)/FP,整个项目生存期中每个功能点发现的缺陷数 ;
缺陷排除率,DR=D1/DI
西安交通大学 刘海岩 59
3,SQA的实施
( 1) SQA小组的职责
SQA活动与两种不同的参与者相关:做开发工作的软件工程师和 独立的 SQA小组。
软件开发人员对质量的考虑,采用可靠的技术方法,
进行正式的技术评审,严格的、按计划的测试软件。
SQA小组的职责是辅助开发人员得到高质量的产品,
负责质量保证的计划、监督、记录、分析及报告工作。
( 2) SQA过程的进入与退出
进入准则:
① 方针明确
② 能力具备
③ 项目已定义
④ 已有 SQAP制定规程和偏差处理规程西安交通大学 刘海岩 60
退出准则:
① 产品符合需求
② 数据记录完整、受控
具体活动的输入(需要的数据)与输出(产生的结果):
输入 包括合同中的有关说明或协议,软件开发标准和规范,软件设计准则,软件测试标准或规范,软件配置管理规范,软件质量保证规范,软件质量数据采集规程等。
输出 包括 SQAP,项目采用的标准和规程,各种评审和审核活动的记录和报告、问题报告、问题解决报告和软件质量有关的数据。
( 3) SQA活动流程 (见下图 )
西安交通大学 刘海岩 61
SQA活动流程西安交通大学 刘海岩 62
需要指出的是,软件测试与软件质量保证 是由不同人员实施的两种不同过程,软件测试是软件开发过程的一个阶段,而软件质量保证贯穿于整个软件开发过程。
软件开发过程需要多人合作,不按照一定的标准、规程、准则去做,很难将众多的工作产品集成起来。不把开发过程分解为可控制的阶段并对每个阶段的工作和结果加以控制,很难保证产品的质量。
正式技术评审是软件质量保证的主要手段之一,也是使用最多的监督方法。为了使评审取得应有的效果,注意三点:
①有计划,
②有规程,
③认真执行计划和规程。
西安交通大学 刘海岩 63
2.7 软件配置管理
1、概念软件配置管理 ( Software Configuration Management,SCM)
是应用于整个软件过程中的庇护性活动。 软件配置 是 一个软件产品在生存期各个阶段的不同形式和不同版本的 程序,
文档及相关数据的集合 。软件开发过程中,会得到许多工作产品或阶段产品,还会用到许多工具软件,所有这些信息都需要管理,以便在提出某些特定的要求时能将其进行约定的组合来满足使用的目的(见下图 )。
西安交通大学 刘海岩 64
两个产品具有不同的配置西安交通大学 刘海岩 65
软件开发属于变化驱动的过程。软件时时处于演化变更状态。技术的快速发展、业务环境的不断改变、不同用户的不同需求、需求在开发中的频繁变更、开发人员对阶段产品的改变等等,都会对产品的最后质量造成影响。
SCM是 对软件生存期过程中的 各阶段产品和最终产品演化和变更的管理,是 CMM第二级中的关键过程域。它的主要目的是对变更加以控制,将变更对成本、进度和质量影响降到最小。
SCM的任务,
制定 SCM计划
配置标识
变更控制
配置审核
版本管理和发行管理西安交通大学 刘海岩 66
2、软件配置标识
( 1)确定配置项( SCI)
大中型软件项目在开发中产生几十个、上百个文档,
每个阶段都在演化,后期版本是对前期的修改及扩展
(两者有继承关系),确定配置项就是确定哪些文档需要被保存、被管理。
( 2)配置项标识
唯一性,在一个项目内不能出现重名,
可追溯性,名字能体现相邻配置项之间的关系,如采用层次式命令规则反映树状结构。
西安交通大学 刘海岩 67
3、变更管理
( 1)软件变更
软件变更的不可避免性,变更来源于用户或开发人员 ;
变更的复杂性:涉及一些相关部件和文档,需要将某些变更通知相关人员。
( 2)变更管理的任务
分析变更:研究变更的必要性、经济可行性(成本-
效益比,是否合理)和技术可行性(能否实现)。
记录和追踪变更。
采取措施保证变更在受控状态下进行。
西安交通大学 刘海岩 68
( 3)建立配置项库
◆ 配置项库的作用
① 记录与配置相关的所有信息,其中很重要的内容是存放受控的软件配置项。
② 利用库中的信息评价变更的后果,对变更控制有重要的意义。
③ 从库中提取各种配置管理过程的管理信息,可利用库中的信息查询回答许多配置管理问题,例如:
哪些客户已提取了某个特定的系统版本?
运行一个给定的系统版本需要什么硬件和系统软件?
一个系统到目前已生成了多少个版本,何时生成的?
如果某一特定的构件变更了,会影响到系统的哪些版本?
一个特定的版本曾提出过哪几个变更请求?
一个特定的版本有多少已报告的错误?
西安交通大学 刘海岩 69
◆ 配置项库的类别
开发库存放开发过程中需要保留的各种信息,供开发人员个人使用,库中的信息无需对其做任何限制,可以有较为频繁的修改。
受控库在软件开发的某个阶段工作结束时,将工作产品或有关信息存入,应该对库内的信息的读写和修改加以控制。
产品库所开发的软件产品完成系统测试后,作为最终产品存入库内,库内的信息也应加以控制。
受控库和产品库的规范化运行是实现软件配置项管理的重要手段。
西安交通大学 刘海岩 70
( 4)建立配置基线( base line)
基线是软件生存期各开发阶段末尾的特定点,也称为里程碑。在这些特定点上,阶段工作已结束,并且已经取得了正式的阶段产品。
建立基线的概念是为了把各开发阶段的工作划分得更加明确,这样有利于检验和肯定阶段工作的成果。同时也有利于变更控制。有了基线的规定后,就可以禁止跨越里程碑去修改另一开发阶段“已冻结”的工作成果。
西安交通大学 刘海岩 71
( 5)变更请求与变更控制
变更请求变更请求是实施变更控制的起始步。最常见的变更理由可能是清除缺陷、或适应运行平台的变更、或是软件扩展提出的要求,例如增加功能、提高性能等。
利用配置库实现变更控制变更控制过程从变更请求开始,处于开发状态 SCI尚未稳定下来,不受 SCM的控制,对 SCI的变更不受限制。
但当开发人员认为工作已告完成,可供其他配置项使用时,
配置项进入评审状态,若通过评审作为基线允许进入配置项库( check-in),配置项处于受控状态,开发人员不允许对其做任何修改。
配置项的状态变化见下图。
西安交通大学 刘海岩 72
配置项的状态变化变更控制过程见下图。
西安交通大学 刘海岩 73变更控制过程西安交通大学 刘海岩 74
( 6)两个变更控制因素
访问控制,管理哪个程序员有权访问和修改 SCI。
同步控制,保证两个不同人员完成的并行变更不会相互覆盖。
访问控制与同步控制流程如下图所示。
西安交通大学 刘海岩 75
访问控制和同步控制流程加锁,使得当前被提取的版本在放回之前别人不能对它作任何修改(同步控制)。
解锁,在经过 SQA和测试后,新的基线对象被解锁并提交修改后的版本。
西安交通大学 刘海岩 76
4、配置审核配置审核是一个 SQA活动,确保 SCM的有效性,
不允许出现混乱现象。
如何实施:
( 1) 实施的时机,
软件产品交付或正式发行前;
开发过程中的阶段工作结束之后;
在维护工作中定期进行。
( 2) 审核的责任人,软件配置管理员或审核员。
( 3) 审核工作的开展,
西安交通大学 刘海岩 77
项目经理决定配置审核的时间和范围;
审核员准备配置审核检查单;
审核员安排时间审核文档和记录,审核活动可能涉及到:项目范围、评审记录、测试记录、变更请求、
配置项的入库和出库记录、配置项的变更历史、文件的命名、版本的编号等等;
审核员发现不符合现象时做出记录;
项目经理负责消除不符合现象;
审核员验证所有不符合现象确已得到解决。
西安交通大学 刘海岩 78
5、配置状态报告其 任务是有效地记录和报告管理配置所需要的信息,
以便及时、准确地给出软件配置的当前状况,加强 SCM工作。
需要跟踪捕获的状态报告信息有:
SCI的当前标识、已交付软件的配置、变更请求或问题报告的状态、已获准变更的状态。
软件开发中,存在着“右手不知左手在干什么”。两个开发者可能以不同的意图去修改同一个 SCI,配置状态报告能 改善 开发人员之间的 通信,更好的控制软件版本的变更。