第2章软件项目管理_第1页
第2章软件项目管理_第2页
第2章软件项目管理_第3页
第2章软件项目管理_第4页
第2章软件项目管理_第5页
已阅读5页,还剩73页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

会计学1第2章软件项目管理22.1软件项目管理的概念

项目:以一套独特而相互联系的任务为前提,有效的利用资源,为实现一个特定目标所作的工作。项目的成功受以下几个因素的制约:技术范围、成本、进度、用户满意度、人员等。

项目管理的职责:确保项目目标的实现,即在预算内按时完成质量合格的产品。

软件项目管理:是对传统项目管理进行软件工程化的一种扩展与拓延,是它在软件工程的任何技术活动之前开始,并持续贯穿于整个软件定义、开发和支持阶段的庇护性活动,是决定一个产品或项目能否成功最重要的指标之一。

第1页/共78页34个P(People、Product、Process、Project)对软件项目管理有实质性的影响:

人员必须被组织成有效的开发团队。

产品需求被划分成较小的组成部分,便于分配给软件开发小组。开发过程应根据人员和产品选择合适的开发模型。

项目必须被组织成便于控制和管理的方式,使有计划的进行。第2页/共78页4◆

人员:人员是一个成功软件项目中最重要的因素。可分为5类:⑴高级管理者:负责定义业务问题,影响着项目。⑵技术管理者:组织、激励和控制开发人员。⑶开发人员:负责开发一个产品或应用所需的技术。⑷客户(customer):负责说明待开发的软件需求。⑸最终用户(user):直接使用发布的软件。第3页/共78页5

每一个软件项目都有上述的人员参与。必须被组织成有效的小组,最大限度的发辉每个人的技术和能力,激励他们进行高质量的工作,并协调他们实现有效的通信。Constantine提出4个“组织范型”:(1)封闭式范型:传统的控制层次,垂直通信,难以创新。(2)随机式范型:小组管理较松散,依赖于成员个人的主动性。不适合“有次序地完成”。(3)开放式范型:具有封闭式范型的控制性,又包含随机式范型的创新性。适合于解决复杂问题。可能不像其他类型小组那么有效率。(4)同步式范型:依赖于问题的自然划分,小组成员各自解决问题的独立部分。主动通信差。建立一个有凝聚力的小组,要有团队精神。第4页/共78页6

产品:进行项目计划之前,应该首先定义产品的目的和范围,考虑可选的解决方案,标识技术和管理的约束。无这些信息,就不可能进行合理的、准确的成本估算、有效的风险评估、适当的项目任务划分、可管理的项目进度安排。

“目的”指从用户的角度标识出该产品的总体目标而不考虑这些目标如何实现。

“范围”指标识出与产品相关的主要数据、功能和行为。确定了目的和范围,就可以根据产品交付的期限、预算的限制、可用的人员、技术接口及各种其他因素,选择最好的解决方案途径。

第5页/共78页7◆过程

根据以下条件选择一个合适的软件过程模型:⑴开发人员及需要该产品的用户⑵产品本身的特征⑶项目组的工作环境采用如下的框架活动集合:客户交流、计划、风险分析、工程实施、构造及发布、用户评估。这些活动可被修改以适应不同软件项目的特征和项目组的需求。每个活动可被分解为更详细的工作任务。如客户交流活动可能需要下列任务:第6页/共78页8

⑴列出需要澄清问题的清单⑵安排与用户进行讨论的会议⑶评审用户要求及范围的陈述⑷研究推荐的解决方案⑸为正式的会议准备工作文档⑹共同制订能反映软件的数据、功能和行为特征的规约,形成软件范围的文档⑺评审文档⑻根据需求修改文档

……庇护性活动贯穿于整个过程。第7页/共78页9

◆项目有计划的控制软件项目,Boehm提出了一种方法,强调项目目标、里程碑、进度、责任、管理和技术方法以及需要的资源,称之为W5H2原则。通过下面一系列的提问和回答,可以导出项目的关键特征并产生项目计划的大纲:⑴为什么(Why)该系统被开发?值得吗?⑵将做什么(What)?什么时候(When)做?建立项目进度,标识关键的项目任务和里程碑。⑶某功能由谁(Who)负责?开发人员的角色和责任。⑷哪里需要(Where)?客户、用户和其他投资者也有责任。⑸工作将如何(How)进行?定义项目的管理和技术策略。⑹资源需要多少(Howmuch)?

第8页/共78页10

软件项目管理中的主要元素及之间的关系

开发人员、小组、角色、任务、工作产品、进度表(UML类图)之间的关系第9页/共78页11

软件项目管理的主要内容:

•定义问题(确定新系统的作用域-目标)

•确认项目的可行性

•建立项目的进度计划

•建立项目的质量保证体系

•建立项目配置管理体系和准则

•项目版本变更管理

跟踪、监控项目的进展

•风险管理

•团队建设(人员管理,包括绩效评估等)

第10页/共78页122.2可行性研究

1、可行性研究的任务和目的GB8566-88《计算机软件开发规范》中指出:

可行性研究的主要任务是了解客户的要求及现实环境,从技术、经济和社会因素等方面研究并论证本软件项目的可行性,编写可行性研究报告供项目管理人员评审,以便作出是否开发软件项目的决策。第11页/共78页13◆技术可行性

度量一个系统解决方案的实用性及技术资源的可用性。考虑的问题:(1)开发风险分析(2)资源分析(3)相关技术的发展(现有技术能否实现新系统、技术难点、建议采用技术的先进性)第12页/共78页14◆经济可行性

主要内容:成本/效益分析不可能得到精确的分析结果․系统成本:①软件开发费用②购置并安装软硬件机有关设备的费用估算③系统安装、运行和维护费用④人员培训费用․系统效益包括经济效益和社会效益经济效益:可通过直接的或统计的方法估算社会效益:定性的方法估算第13页/共78页15◆社会因素可行性

政策、法律、使用、环境等2、可行性研究的步骤(1)复查确认系统目标、规模(2)研究现行系统的工作流程(3)导出目标系统高层逻辑模型(4)导出和评价供选择的方案(5)推荐可行的方案(6)编写可行性研究报告,送审第14页/共78页163、可行性研究报告的编写提示(1)引言:编写目的、背景、定义、参考资料;(2)可行性研究的前提:要求、目标、条件、假定和限制、进行可行性研究的方法、评价尺度;(3)对现有系统的分析:工作流程、工作负荷、费用开支、人员、设备、局限性;(4)所建议的系统:说明、数据流程和处理流程、改进之处、影响、局限性、技术条件的可行性;(5)可选择的其它系统方案;(6)投资及收益分析:支出、收益、收益/投资比、投资回收期等;(7)社会条件方面的可行性(法律、使用)。

第15页/共78页17例:一个软件系统的开发费用(一次):人员:2名系统分析员(450小时/名,45美元/小时)$40,500

5名系统开发人员(275小时/名,36美元/小时)$49,5001名数据通讯专家(60小时/名,42美元/小时)$2,520

1名数据库管理员(30小时/名,42美元/小时)$1,2602名技术写作者(120小时/名,25美元/小时)$6,0001名秘书(160小时/名,15美元/小时)$2,4002名在转换期间数据输入人员$960(40小时/名,12美元/小时)

第16页/共78页18培训:三天的开发人员内部培训课程$7,00030个用户,三天的内部培训课程$10,000复印$500磁盘、纸张等消耗品$650购买硬件、软件:20台工作站Windows软件$1,00020台工作站内存升级$8,000网络软件$17,50020台工作站办公软件产品$20,000系统开发总费用$167,790(成本)第17页/共78页19

一个系统的年运行费用(每年):人员:维护程序员/分析员(250小时/年,42美元/小时)$10,500网络管理员(300小时/年,50美元/小时)$15,000购买硬件、软件升级:硬件$5,000软件$6,000物资和杂项$3,500每年总运行费用$40,000第18页/共78页202.3软件度量

软件度量(metrics)域分为过程度量、项目度量和产品度量。对过程、项目及产品的特定属性进行度量产生指导管理及技术动作的指标,使得管理者和开发者能够:

改善软件过程

辅助软件项目计划

跟踪及控制软件项目的进展

评价软件产品的质量第19页/共78页21

软件度量的方式:直接度量间接度量

•软件工程过程的直接度量包括所投入的成本和工作量。

•软件产品的直接度量包括产生的代码行数(LOC)、执行速度、存储量大小、在某种时间周期中所报告的错误数。

•软件产品的间接度量包括功能性、复杂性、效率、可靠性、可维护性和许多其它的质量特性。第20页/共78页221.过程和项目的度量

◆过程度量:

使一个组织从战略上考察已有过程的功效,如开发范型、工程任务的划分、工作产品、里程碑等,使管理者评估那些部分起了作用。度量数据的收集跨越所有的项目,经历较长的时间,目的是改善软件过程。间接的度量一个软件过程的功效:

•软件发布之前发现的错误数

•交付给用户后报告的缺陷数

•花费的工作量、时间、成本

•与进度计划是否一致

第21页/共78页23

个体软件过程(如PSP)提供了表格、脚本、标准以帮助开发人员估算、计划以及度量、跟踪自己工作的方法。过程度量对于一个组织(如企业)提高其总体的过程成熟度能提供很大的帮助。如一个产品中,需求规约缺陷占了25.5%,原因如图所示。通过分析一个完整的鱼骨图可以导出能改进软件过程以降低错误和缺陷率的频率。

第22页/共78页24

◆项目度量:

是战术的,使项目管理者能够以实时的方式改进项目的工作流程及技术方法,如软件项目的工作量及时间的估算。

项目度量的基础是历史项目中收集的数据。随着项目的进展,所花费的工作量及时间和预算的值进行比较,从而控制项目的进展。另外,可根据文档的页数、评审的时间、功能点及源代码行数来度量软件的生产率。

第23页/共78页25

项目度量可在项目进行的基础上评估产品的质量,以指导在必要时修改技术方法以改进质量。软件项目度量建议每个项目都应该测量:

•输入:完成工作所需要的资源(如人员、环境);

•输出:软件工程过程中产生的工作产品;

•结果:最终产品的有效性。项目度量集成起来产生对整个软件组织公用的过程度量。

第24页/共78页262.软件度量的方法

(1)面向规模的度量

是对软件和软件开发过程的直接度量。可以建立一个面向规模的数据表格来记录项目的某些信息。该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应面向规模的数据。

第25页/共78页27

基于所生产软件的“规模”,使用代码行作为其他计算的规范化因子。计算:

•每千行代码(KLOC)的错误数。

•每KLOC

的缺陷数。

•每个LOC的花费成本。

•每KLOC的文档页数

•每人月的错误数。

•每人月的代码行。

•每页文档的成本。

第26页/共78页28

可制作一个如下的表:

对该方法的有效性有争议:

支持:易计算,很多软件估算模型以它为关键的输入。

反对:LOC依赖于语言,不适用于非过程化语言,在分析与设计完成之前难以估算。项目名KLOC工作量(人月)成本(万元)文档页数错误缺陷人员BETA1236101556085第27页/共78页29

(2)面向功能的度量

“功能”不能直接测量,利用其他的测量数据间接地导出。Albrecht提出来的一种称为功能点的度量。用下表计算5个信息域的值:

第28页/共78页30其中:

•用户输入数:每个用户向系统提供的不同应用的输入数据。

•用户输出数:系统向每个用户提供的信息,如报表、屏幕信息、出错信息等。

•用户查询数:每个不同的询问/响应的交互操作。

•文件数:可以是数据库的一部分或是一个独立的文件。

•外部接口数:与系统中其他设备通过外部接口读写信息的次数。

“简单、平均、复杂”中的常量值是加权因子,根据经验确定。

第29页/共78页31

利用以下公式计算功能点(FP):FP=总计数值×(0.65+0.01×

Fi)

其中Fi(i=1~14)是回答14个方面问题而得到的复杂度调整值(值域为0~5),如输入、输出、查询及内部处理复杂吗?代码复用吗?有分布处理吗等等(详见p64)。计算出功能点。就可进行以下度量:

•每个功能点的错误数。

•每个功能点的缺陷数。

•每个功能点的成本。

•每个功能点的文档页数。

•每人月完成的功能点数。第30页/共78页32代码行和功能点度量之间的关系依赖于实现软件所采用的程序设计语言及设计的质量。下面给出了在不同的程序设计语言中建造一个功能点所需的平均代码行数的统计:程序设计语言LOC/FP

汇编语言320

C128FORTRAN106Pascal90C++64Java46VisualBASIC32PowerBuilder16SQL12

第31页/共78页33

3、软件质量度量

软件工程的目标是产生高质量的系统或产品。质量依赖于描述问题的需求、建模、设计、编码、测试。质量度量贯穿于软件工程的全过程中以及软件交付用户使用之后。应评估分析与设计模型、源代码、测试案例的质量。

第32页/共78页34

在软件交付之前得到的度量数据可作为判断设计和测试质量好坏的依据。这一类度量包括程序复杂性、有效的模块性和总的程序规模。

在软件交付之后的度量数据则把注意力集中于还未发现的缺陷数和系统的可维护性方面。

McCall提出了影响软件质量的11个因素(详见P367),其中重要的有以下几点:

•正确性:软件完成所需功能的程度,最常用

“缺陷数/kLoc”来测量。第33页/共78页35

•可维护性:遇到错误时程序能被修改的容易程度、环境变化时程序能被适应的容易程度、用户希望改变需求时程序能被增强的容易程度,一种最简单的测量方法是计算平均修改时间(MTTC)。

•完整性:测量系统在安全方面的抗攻击性。

完整性=Σ[(1-威胁)×(1-安全性)]

其中威胁是某个特定类型的攻击在给定时间内发生的可能性。安全性是某个特定类型的攻击将被击退的可能性。

•可用性:用户友好性。另外还有可靠性、效率、可测试性、可移植性、可复用性等等。

第34页/共78页362.4软件项目计划

项目计划既指出了项目组织未来努力的方向和奋斗目标,又是当前行动的准则。针对不同工作目标,软件项目计划有:

•项目实施计划(软件开发计划)这是软件开发的综合性计划,通常应包括任务、进度、人力、环境、资源、组织等多个方面。

•质量保证计划把软件开发的质量要求具体规定为每个开发阶段可以检查的质量保证活动。

•软件测试计划规定测试活动的任务、测试方法、进度、资源、人员职责等。

第35页/共78页37

•文档编制计划规定所开发项目应编制的文档种类、内容、进度、人员职责等。

•用户培训计划规定对用户进行培训的目标、要求、进度、人员职责等。

•综合支持计划规定软件开发过程中所需要的支持,以及如何获取和利用这些支持。

•软件发布计划软件开发项目完成后,如何提交给用户。这里,主要针对综合计划来介绍。第36页/共78页38项目管理是一个创造的过程,项目早期的不确定性因素,使计划不可能在启动阶段就全部一次完成,需逐步展开和不断修正,这又取决于计划执行情况的反馈与及时的信息交流。制订项目基准计划(BaselinePlan)的步骤:①定义项目目标,确定软件范围②把项目按项目范围分解为多个任务③确定对应每个任务必须执行的活动④将每个任务分配给一个小组,并为每个开发者分配角色和职责⑤用Gantt图或PERT图表示出项目的进度

第37页/共78页391、软件项目估算项目计划的一个重要的前提是项目估算(有时在可行性研究阶段完成),一般以团队的历史经验为基础,让团队中的一线人员参与估算,才能保证项目计划的可行性。成本及工作量的估算不是一门精确的科学,有几种选择:

基于已完成的类似项目进行估算;

•使用分解技术以生成项目成本及工作量的估算;

•使用一个或多个经验模型;

(1)分解技术分解技术采用“分而治之”的策略进行软件项目估算。将项目分解成若干主要功能及相关的软件过程活动,通过逐步求精的方式进行成本及工作量估算。具体方法为:

第38页/共78页40

划分主要的软件功能,接着估算:①Loc的数量②对于FP,估算每个信息域特征(输入、输出、数据文件、查询、外部接口)及14个复杂度调整值③实现每个功能所需的人月数④每个软件过程活动所需人月数基本的估算方法:

•自顶向下估算:总成本按阶段、步骤、工作单元•自底向上估算:先划分,分别估算每个子任务所需的工作量,然后∑。

第39页/共78页41•差别估算法:与类似项目比较,估算每个不同之处对成本的影响。还有专家估算法等等。(2)经验估算模型经验估算模型可用于补充分解技术,并提供一种潜在有价值的估算方法。该模型是基于经验(历史数据)的,可以用下面的形式表示:

=ƒ()其中

是要估算的值(如工作量、成本、项目持续时间)之一,是选择出来的独立参数(如被估算的Loc或FP)。第40页/共78页42

由经验导出的公式,最著名的是COCOMO模型,构造型成本模型(COnstructiveCOstMOdel)。初期的模型广泛的使用于软件成本估算,发展到反映不同阶段的成本。

初始模型的分类:•基本COCOMO模型是静态单变量模型,用源代码行数(LOC)为自变量的经验函数计算软件开发工作量。•中间COCOMO模型该模型在用LOC为自变量的函数计算软件开发工作量的基础上,用涉及产品、硬件、人员、项目等方面的影响因素调整工作量估算。•详细COCOMO模型该模型包括中间COCOMO模型的所有特性,但用上述各种影响因素调整工作量估算时,还要考虑对软件工程过程中每一步骤(分析、设计等)的影响。

第41页/共78页43

模型的扩展:COCOCOMⅡ使用对象点、功能点、源代码行作为不同层次模型的参数。

对象点只是一种间接软件测量数,使用以下计数:①用户界面上的屏幕数②报表数③建立应用软件需要的构件数。每个对象实例(如一个屏幕或一个报表)给出三个复杂度权数(简单、中等、复杂),如一个屏幕的权简单为1,中等为2,复杂为3。通过以下公式计算总对象点数:第42页/共78页44Σ(初始的对象实例数×加权因子)=总的对象点(NOP)当应用基于构件的开发时,对象点计数调整为:NOP=NOP×[(100-%复用)/100]进而计算:生产率=NOP/人月针对不同级别的开发者经验和开发环境成熟度,给出对象点的生产率:非常低低额定高非常高47132550项目工作量=NOP/生产率第43页/共78页45

2、项目进度安排项目计划中的一个重要内容是建立进度表,该表对项目进度进行科学度量、调整项目计划起很重要的作用。在众多软件项目中,缺乏合理的进度安排是造成项目泄后的最主要原因。进度安排为项目管理者和开发者建立了一张行路图。

(1)进度安排的指导原则:

•划分:项目分解成若干易于管理的任务。如何进行任务的分解呢?可从两个方面获得帮助:①软件开发模型:模型帮助将整个项目进行阶段性的划分,这些阶段可以做计划中很重要的里程碑。

软件开发需求:开发模型只给项目计划提供了个框架,需求的整理与规格化,是细化项目计划的基础。

第44页/共78页46

相互依赖性:各个被划分的活动或任务之间的相互关系必须是确定的。有些任务必须顺序进行,有些可以并发进行。

时间分配:必须为每个被调度的任务分配一定数量的工作单位(如,人天、人月),并指定开始和结束日期。

工作量确认:每个项目都有预定数量的人员参与。在进行时间分配时,必须确保在任意时段中分配给任务的人员数量不会超过项目组中的人员总量。

定义的责任:每个被调度的任务都应该指定某个特定的小组成员来负责。

定义的结果:每个被调度的任务都应该有一个定义好的输出结果,输出结果通常是一个工作产品或某个工作产品的一部分。

定义的里程碑:每个任务或任务组都应该与一个项目里程碑相关联。当一个或多个工作产品经过质量评审并且得到认可时,标志着一个里程碑的完成。

第45页/共78页47(2)工作量分配(指导原则)计划需求分析设计编码测试

2%~3%10%~25%20%~25%15%~20%30%~40%(3)进度表(图)

甘特图(GanttChart)

也称时间表,所有的项目任务都在左边的栏目中列出。水平条表示每个任务的持续时间,当同一时间段中存在多个水平条时,表示任务之间存在并发。

PERT(ProgramEvaluationReviewTechnique)图也称任务网络图,表示一个项目的任务流程,刻画了各项任务、任务之间的依赖关系及任务的持续时间。它的最简单形式可当作宏观进度表使用。第46页/共78页48

Gantt图Gantt图可清晰的表达每个任务活动的进展以及并发活动。水平条的颜色既可以表示概要任务和详细任务的分解,也可以表示任务完成的情况。用一个特定的符号(如黑菱形)表示一个活动的结束(里程碑),以便检查阶段成果和最后成果。

第47页/共78页49

PERT图PERT图另一个重要的用途是用来判断关键路径,关键路径表明了完成该项目可能需要的最小时间,并能识别最有可能成为瓶颈的活动,该路径上的活动是项目负责人或小组长抓的主要工作。非关键路径上的活动延迟,不会导致项目总体进度偏离。下图是一个项目的总的PERT图。

第48页/共78页50第49页/共78页51说明:①考虑进度表中的变化:建立进度表时,项目分解为哪些任务以及任务持续的时间往往根据历史数据估算而来,项目进展过程中未预料到的事件,如需求的变化或较晚发现的设计缺陷,都会打乱进度表,因此在进度表中为将来可能的变化留有余地。②进度表可有不同的抽象层次:高层进度表反映整个项目的进度,应包括所有可交付产品的期限,底层进度表是任务和时间的分解。可制作短期内的进度表,其余部分在项目进行过程中完成。底层进度表可用于指导每个小组的进度。③每个里程碑可以附带一个标识进度值的百分比,用来说明项目完成了多少,如:30%。

第50页/共78页52

项目开展阶段管理活动图(UML活动图)

2.5项目进度的跟踪

第51页/共78页53

1、项目启动

进行项目计划

2、项目开展

项目的监督与跟踪

(1)收集状况信息的方式

定期报告:非正式的会议和交流,报告工作产品、进度误差等需要及早沟通的信息。

里程碑的监督与验证:里程碑可以是事件,也可以是工作产品,验证是否在预定时间内完成。

项目检查:正式会议,所有开发人员交换活动进展状况,比较各项任务实际开始日期与计划开始日期。

代码检查:同事之间的正式代码检查。

原型示范:原型是为了验证需求或为了评估技术和功能而部分实现的系统,可用来估算初始进度。

第52页/共78页54

度量:主要是修正错误数目的度量,即还需要付出多少努力的估量。

(2)项目再计划根据项目的变化动态更新项目计划,应对一些新的需求、新的变化、突发因素做出响应,或解决问题以适应计划,或调整计划以保证最后按时交付产品。

(3)风险管理风险是一些不利因素实际发生的可能性。如:人员跳槽,管理层变更,硬件缺乏,需求变化,描述延迟,低估了系统的规模,工具性能差,技术变更,产品竟争等等。

第53页/共78页55风险管理的活动有:

•风险识别:确定风险的类型(管理、技术)。

•风险分析:评估风险出现的可能性及其后果。

•风险规划:制定避免或降低风险的策略。

•风险控制:定期进行风险评估,及时修正缓解风险的计划。3、项目总结

•用户验收:根据项目协议中规定的验收标准对系统进行评价,并通过场景演示,测试系统功能性和非功能性需求。

•安装:在目标环境下安装、运行系统并提交文档。

•总结:总结经验教训,建立团队工作效率的历史档案,以便提高个人和团队整体的软件工程能力。第54页/共78页562.6软件质量保证

1、概述软件质量是软件产品、体系或过程的一组固有特性满足(顾客和其他相关方)要求的程度。软件质量保证(SoftwareQualityAssurance,SQA)是一种应用于整个软件过程的庇护性活动,包含:

•质量管理方法

•有效的软件工程方法和工具

•过程中采用的正式技术评审

•多层次的测试策略

•对软件文档及其修改的控制

•保证与开发标准符合的规程

•软件度量及报告机制等等方面的内容第55页/共78页57

软件质量保证的对象一般有三方面:产品、过程和质量体系实施软件质量保证需运用几种支持过程作为质量保证的手段。

•验证或确认:通过提供客观证据对规定要求已得到满足的认定。

•评审或审核:确定主题事项达到规定目标的适应性、充分性和有效性所进行的活动。联合评审是由任何两方(评价方和被评价方)用来在适当时机对项目的某个活动的状态和产品进行评价并可能形成文件的过程。

第56页/共78页58

2、软件质量保证过程中的数据

SQA过程中必然产生有关产品、过程和体系质量的多种数据,是进行下一步工作的决策依据,对于提高质量管理效果和改进质量管理过程至关重要。要收集、存储、及时分析和使用这些数据,才能做好质量保证工作。质量数据有多种:

•项目规模:FP表示软件大小,以功能点计数;

•工作量E:表示项目的人力总投入,以人月计数;

•生产率:

P=FP/E;

•缺陷数:D1表示软件交付前发现的错误数,D2表示交付后发现的缺陷数;

•质量:Q=D2/FP,表示每个功能点包含多少交付的缺陷,

•缺陷引入率:DI=(D1+D2)/FP,整个项目生存期中每个功能点发现的缺陷数;•缺陷排除率:

DR=D1/DI第57页/共78页59

3、SQA的实施(1)SQA小组的职责

SQA活动与两种不同的参与者相关:做开发工作的软件工程师和独立的SQA小组。软件开发人员对质量的考虑:采用可靠的技术方法,进行正式的技术评审,严格的、按计划的测试软件。

SQA小组的职责是辅助开发人员得到高质量的产品,负责质量保证的计划、监督、记录、分析及报告工作。

(2)SQA过程的进入与退出

•进入准则:①方针明确②能力具备

③项目已定义

④已有SQAP制定规程和偏差处理规程

第58页/共78页60

•退出准则:

①产品符合需求

②数据记录完整、受控

•具体活动的输入(需要的数据)与输出(产生的结果):输入包括合同中的有关说明或协议,软件开发标准和规范,软件设计准则,软件测试标准或规范,软件配置管理规范,软件质量保证规范,软件质量数据采集规程等。输出包括SQAP,项目采用的标准和规程,各种评审和审核活动的记录和报告、问题报告、问题解决报告和软件质量有关的数据。

(3)SQA活动流程(见下图)

第59页/共78页61

SQA活动流程第60页/共78页62需要指出的是,软件测试与软件质量保证是由不同人员实施的两种不同过程,软件测试是软件开发过程的一个阶段,而软件质量保证贯穿于整个软件开发过程。软件开发过程需要多人合作,不按照一定的标准、规程、准则去做,很难将众多的工作产品集成起来。不把开发过程分解为可控制的阶段并对每个阶段的工作和结果加以控制,很难保证产品的质量。正式技术评审是软件质量保证的主要手段之一,也是使用最多的监督方法。为了使评审取得应有的效果,注意三点:①有计划,②有规程,③认真执行计划和规程。第61页/共78页632.7软件配置管理

1、概念

软件配置管理(SoftwareConfigurationManagement,SCM)是应用于整个软件过程中的庇护性活动。软件配置是一个软件产品在生存期各个阶段的不同形式和不同版本的程序、文档及相关数据的集合。软件开发过程中,会得到许多工作产品或阶段产品,还会用到许多工具软件,所有这些信息都需要管理,以便在提出某些特定的要求时能将其进行约定的组合来满足使用的目的(见下图)。

第62页/共78页64

两个产品具有不同的配置

第63页/共78页65软件开发属于变化驱动的过程。软件时时处于演化变更状态。技术的快速发展、业务环境的不断改变、不同用户的不同需求、需求在开发中的频繁变更、开发人员对阶段产品的改变等等,都会对产品的最后质量造成影响。

SCM是对软件生存期过程中的各阶段产品和最终产品演化和变更的管理,是CMM第二级中的关键过程域。它的主要目的是对变更加以控制,将变更对成本、进度和质量影响降到最小。SCM的任务:

•制定SCM计划

•配置标识

•变更控制

•配置审核

•版本管理和发行管理

第64页/共78页662、软件配置标识

(1)确定配置项(SCI)大中型软件项目在开发中产生几十个、上百个文档,每个阶段都在演化,后期版本是对前期的修改及扩展(两者有继承关系),确定配置项就是确定哪些文档需要被保存、被管理。

(2)配置项标识

唯一性:在一个项目内不能出现重名,

•可追溯性:名字能体现相邻配置项之间的关系,如采用层次式命令规则反映树状结构。第65页/共78页673、变更管理

(1)软件变更

•软件变更的不可避免性:变更来源于用户或开发人员;

•变更的复杂性:涉及一些相关部件和文档,需要将某些变更通知相关人员。

(2)变更管理的任务

•分析变更:研究变更的必要性、经济可行性(成本-效益比,是否合理)和技术可行性(能否实现)。•记录和追踪变更。

•采取措施保证变更在受控状态下进行。第66页/共78页68

(3)建立配置项库

◆配置项库的作用

①记录与配置相关的所有信息,其中很重要的内容是存放受控的软件配置项。

②利用库中的信息评价变更的后果,对变更控制有重要的意义。③从库中提取各种配置管理过程的管理信息,可利用库中的信息查询回答许多配置管理问题,例如:

•哪些客户已提取了某个特定的系统版本?•运行一个给定的系统版本需要什么硬件和系统软件?

•一个系统到目前已生成了多少个版本,何时生成的?•如果某一特定的构件变更了,会影响到系统的哪些版本?•一个特定的版本曾提出过哪几个变更请求?•一个特定的版本有多少已报告的错误?第67页/共78页69

◆配置项库的类别

开发库存放开发过程中需要保留的各种信息,供开发人员个人使用,库中的信息无需对其做任何限制,可以有较为频繁的修改。

•受控库在软件开发的某个阶段工作结束时,将工作产品或有关信息存入,应该对库内的信息的读写和修改加以控制。

•产品库所开发的软件产品完成系统测试后,作为最终产品存入库内,库内的信息也应加以控制。受控库和产品库的规范化运行是实现软件配置项管理的重要手段。第68页/共78页70

(4)建立配置基线(baseline)

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论