软件项目管理复习题.docx
- 文档编号:6368979
- 上传时间:2023-01-05
- 格式:DOCX
- 页数:17
- 大小:609KB
软件项目管理复习题.docx
《软件项目管理复习题.docx》由会员分享,可在线阅读,更多相关《软件项目管理复习题.docx(17页珍藏版)》请在冰豆网上搜索。
软件项目管理复习题
第1讲项目管理
(1)有效的软件项目管理集中于四个P上,即人员、产品、过程和项目。
它们的顺序不是任意的。
(2)在制定项目计划之前,应该首先确定产品的目标和范围,考虑可选的解决方案,识别技术和管理上的限制。
(3)确定产品的范围,要标识出产品的主要数据、功能和行为特性,而且更为重要的是,应以量化的方式界定这些特性。
(4)成功的项目负责人应采用一种解决问题的管理风格。
(5)“最好的”团队结构取决于组织的管理风格、团队里的人员数目与技能水平,以及问题的总体难易程序。
(6)规划软件工程团队结构时的七个项目因素:
(1)待解决问题的难度;
(2)开发程序的规模,以代码行或功能点来度量;(3)团队成员需要共同工作的时间(团队生存期);(4)能够对问题做模块化划分的程度;(5)待开发系统的质量要求和可靠性要求;(6)交付日期的严格程度;(7)项目所需要的友好交流的程度。
(7)软件工程团队的四种“组织范型”:
封闭式范型、随机式范型和开放式范型以及同步式范型。
(8)封闭式范型:
按照传统的权利层次来组织团队。
当开发与过去已经做过的产品相似的软件时,这种团队十分有效。
但在这种封闭式范型下难以进行创新性的工作。
(9)随机式范型:
松散地组织团队,团队工作依赖于团队成员个人的主动性。
当需要创新或技术上的突破时,按照这种随机式范型的团队很有优势。
但当需要“有次序地执行”才能完成工作时,这种团队就会陷入困境。
(10)开放式范型:
试图以一种具有封闭式范型的控制性,又包含随机式范型的创新性的方式来组织团队。
工作是大家相互协作完成的。
良好的沟通和根据团队整体的意见做出决策是开放式范型的特征。
开放式范型的团队结构特别适合于解决复杂的问题,但可能不像其他类型的团队那么有效。
(11)同步式范型:
依赖于问题的自然划分,组织团队成员各自解决问题的一部分,他们之间没有什么交流。
(12)5个“培育潜在含毒团队环境”的因素
(1)狂乱的工作氛围
(2)引起团队成员产生摩擦的重大挫折(3)“碎片式的或协调很差”的软件过程(4)在软件团队中没有清晰的角色定义(5)“接连不断地重蹈覆辙”。
(13)敏捷团队是小型的充满活力的团队,它不必保持单一的团队结构,而是采用随机、开放、同步式的范型,并且拥有制定计划和做技术决定的自主权。
(14)软件项目管理的第一项活动是确定软件范围。
(15)软件范围是通过项目环境、信息目标以及功能和性能定义的。
(16)软件项目范围在管理层和技术层都必须是无歧义的和可理解的。
(17)问题分解,有时称为问题划分或问题细化,它是软件需求分析的核心活动。
(18)成本和进度估算都是面向功能的。
(19)过程框架是不变的,是软件组织所进行的所有软件工作的。
(20)10个表示信息系统项目正处于危险状态的信号
(21)W5HH
(22)项目是一个特定的、待完成的有限任务,是在一定时间内,满足一系列特定目标的多项相关工作的总称。
(23)项目与常规运作的不同体现:
⏹项目是一次性,常规运作是重复进行;
⏹项目是以目标为导向,常规运作是通过效率和有效性体现的;
⏹项目是通过项目经理及其团队工作完成的,而日常运作是职能式的线性管理;
⏹项目存在大量的变更管理,而日常运作则基本保持续的连贯性。
(24)项目生命周期有3个与时间相关的重要概念:
检查点、里程碑和基线。
(25)基线:
指一个(或一组)配置项在项目生命期的不同时间点上,通过正式评审而进入正式受控的一种状态。
(26)软件管理的关键实践:
⏹基于度量的项目管理
⏹经验成本和进度估计
⏹获得价值跟踪
⏹正式的风险管理
⏹根据质量目标跟踪缺陷
⏹人员计划管理
第2讲过程和项目度量
(27)测量可以应用于软件过程中,目的是持续地改进软件过程。
(28)测度对一个产品过程的某个属性的范围、数量、维度、容量或大小提供了一个量化的指示。
(29)测量是确定一个测度的行为。
(30)度量为“对一个系统、构件或过程具有的某个给定属性的度的一个定量测量”。
(31)度量:
度量是一个系统、构件或过程具有给定属性的量化测量程度。
(32)当收集了一个数据点(例如:
在一个软件构件中发现的错误数),就建立了一个测度。
(33)收集一个或多个数据点(例如:
一些构件评审、调查单元测试以收集每个单元测试错误数的测度),由此产生测量。
(34)软件的度量以某种形式(例如:
每次评审发现错误的平均数,或每个单元测试所发现错误的平均数)与单个测度相关。
(35)软件工程师收集测量结果并产生度量,这样就可以获得指标。
指标是一个度量或度量的组合,它对软件过程、软件项目或产品本身提供了更深入的了解
(36)软件工程师收集测度并开发度量以便获得指标?
?
35那句是真的?
(37)私有过程数据是软件工程师个人改进其工作的重要驱动力。
(38)公用过程数据可由团队进行复查,以找出能够改善小组性能的指标。
公用度量一般吸取了原本是个人的或团队的私有信息。
(39)软件度量规则:
⏹解释度量数据时使用常识,并考虑组织的敏感性。
⏹向收集测量和度量的个人及团队定期提供反馈。
⏹不要使用度量去评价个人。
⏹与开发者和团队一起设定清晰的目标,并确定为达到这些目标需要使用的度量。
⏹不要用度量去威胁个人或团队。
⏹指出问题区域的度量数据不应该被“消极地”看待,这些数据仅仅是过程改进的指标。
⏹不要在某一个别的度量上纠缠,而无暇顾及其他重要的度量。
(40)在大多数软件项目中,项目度量的第一个应用是在估算阶段。
(41)项目度量的目的:
⏹能够指导进行一些必要的调整以避免延迟,并减少潜在问题及风险,从而使得开发时间减到最少。
⏹在项目进行的基础上评估产品质量,并且可在必要时修改技术方法以改进质量。
(42)面向规模的度量(LOC)和面向功能的度量(FP)都是规范化的方法。
(43)面向规模的度量选择代码行(LOC)作为规范化值(度量:
错误数、缺陷数、成本、文档页数)。
(44)面向功能的软件度量使用功能(由应用系统提供)测量数据作为规模化值。
应用最广泛的面向功能的度量是功能点(FunctionPoint,FP)。
(45)面向对象的度量:
⏹场景脚本的数量
⏹关键类的数量
⏹支持类的数量
⏹每个关键类的平均支持类数量
⏹子系统的数量
(46)面向用例的度量
(47)Web工程项目度量:
⏹静态Web页的数量
⏹动态Web页的数量
⏹内部页面链接的数量
⏹永久数据对象的数量
⏹通过界面连接的外部系统的数量
⏹静态内容对象的数量
⏹动态内容对象的数量
⏹可执行的功能的数量
(48)定制指数C=Ndp/(Ndp+Nsp)
(49)软件工程的基本高目标就是在某个时间框架内开发出满足市场需要的高质量的系统、应用软件或产品。
(50)缺陷排除效率DRE=E/(E+D)(把项目作为一个整体时)
DREi=Ei/(Ei+Ei+1)
(51)度量基线由从以往开发的软件项目中收集的数据构成,是估算的基础。
(52)度量评估主要是分析结果产生的根本原因,并生成一组指导项目或过程的指标。
(53)小型组织的度量:
“保持简单”,通过表决来确定一个需要改进和目标。
(54)保持简单的缺陷排除效率:
DRE=Echange/(Echang+Dchange)。
第3讲产品度量
(55)软件质量是对明确陈述的功能和性能需求、明确记录的开发标准以及对所有专业化软件开发应具备的隐含特征的符合度。
(56)影响软件质量的因素可分为两大类:
⏹可以直接测量的因素(如:
测试期间发现的缺陷)
⏹只能间接测量的因素(如:
易用性和可维护性)
(57)产品度量的作用主要包括:
⏹辅助分析模型和设计模型的评估
⏹提供过程设计和源代码复杂性的指示
⏹方便更有效测试的设计
(58)测量过程的五个活动(测量原则):
⏹公式化。
导出适合于所考虑软件表示的测量和度量。
⏹收集。
用于导出公式化度量所需数据和积累机制。
⏹分析。
度量的计算和数学工具的使用。
⏹解释。
为获得对表示的质量的理解而评价度量。
⏹反馈。
从对递交给软件团队的产品度量的解释中获得建议。
(59)功能点度量(FP)可用做测量系统交付功能的有效手段。
(60)问题复杂性的指标Fi:
(61)分析模型的度量侧重于分析模型的三个成分:
功能、数据和行为。
第4讲估算
1.软件项目策划的目标是提供一个管理人员对资源、成本及进度做出合理估算的框架。
2.项目策划任务集:
a)规定项目范围
b)确定可行性
c)分析风险
d)确定需要的资源
e)估计成本和工作量
f)指定项目进度计划
3.软件范围描述了将要交付给最终用户的功能和特性、输入和输出的数据、使用软件时要呈现给用户的“内容”,以及界定系统的性能、约束条件、接口和可靠性。
4.定义范围可以使用两种方法:
a)在与所有共利益者交流之后,写出对软件范围的叙述性描述。
b)由最终用户开发一组用例。
5.软件可行性有四个固定的因素:
技术、经济、时间和资源。
6.在制定计划时应该考虑四种软件资源:
a)成品构件
b)具有完全经验的构件
c)具有部分经验的构件
d)新构件
7.每种可行的软件成本估算方法,其效果的好坏取决于估算使用的历史数据。
8.项目估算的准确程度取决于待完成工作的规模估算。
规模是指软件项目的可量化的结果。
如果采用直接的方法,规模可以用代码行(LOC)来测量。
如果选择间接的方法,规模可以用功能点(FP)来表示。
9.四种估算规模问题的方法:
a)“模糊逻辑”法
b)功能点法
c)标准构件法
d)修改法
10.LOC和FP估算共同的特性:
项目计划人员从界定的软件范围陈述入手,根据该说明将软件分解成一些可分别独立进行估算的功能问题。
然后,估算每个功能的LOC或FP(即估算变量)。
11.基于LOC估算(重点):
通过乐观值(Sopt)、可能值(Sm)和悲观值(Spess)估算的加权平均值来计算估算变量(规模)的期望值S:
S=(Sopt+4Sm+Spess)/6 (“可能”估算值的权重最大)
总代码行估算值=Σ(Si)
成本估算值=总代码行估算值 * 每行代码的成本
12.基于FP估算(重点):
FPestimated=总计×[组织平均生产率+0.01×Σ(Fi)]
成本估算值=FPestimated×每个FP的成本
13.基于过程的估算:
过程分解一组较小的任务,并估算完成任务所需的工作量。
将问题功能与过程活动()结合起来,计划人员就可以针对每个软件功能,估算完成各个软件过程活动所需的工作量(如人·月)。
14.估算一个步骤就是计算每一个功能及框架活动的成本和工作量。
如果基于过程的估算是不依赖LOC和FP估算而实现的,我们现在就已经有了两组或三组成本与工作量的估算,可以进行比较、调和。
如果两组估算非常一致,则有理由相信估算是可靠的。
反过来,如果这些分解技术得到的结果不一致,则必须做进一步调查和分析。
15.基于用例的估算(不是重点):
LOC估算=N×LOCavg+[(Sa/Sh-1)+(Pa/Ph-1)]×LOCadjust
N:
实际的用例数
LOCavg:
在这种类型的子系统中,每用例的历史平均LOC值。
LOCadjust:
校正值,以LOCavg的n%来表示,其中n根据当前项目的情况来确定,表示该项目与“一般”项目的差异。
Sa:
每个用例包含的实际场景数。
Sh:
在这种类型的子系统中,每个用例包含的平均场景数。
Pa:
每个用例的实际页数。
Ph:
在这种类型的子系统中,每个用例的平均页数。
16.基于用例的估算方法还有困难:
a)描述用例没有标准形式。
b)用例表现常常在不同的抽象级别上建立
c)用例没有标识出它所描述的功能和特性的复杂性。
d)用例没有描述出涉及很多功能和特性的复杂行为(如,交互)。
17.在用例能够用于估算之前,首先要
(1)建立结构层次内的层次,
(2)确定每个用例的平均长度(页数),(3)定义软件的类型(如,实时、商业、工程/科学、嵌入式),(4)考虑系统大致的体系结构。
18.估算之间差别很大的原因:
a)计划人员没有充分了解或误解了项目范围。
b)在基于问题的估算技术中所使用的生产率数据不适合本应用系统,过时了,或者被误用了。
19.典型的估算模型的总体结构具有下列形式(不重要):
E=A+B×(ev)C
其中,A、B、C是经验常数,
E是工作量(以人·月为单位),
ev是估算变量(LOC或FP)
20.COCOMOⅡ模型也需要使用规模估算信息,在模型层次结构中有三种不同的规模估算选项:
a)对象点
b)功能点
c)源代码行
21.COCOMOⅡ模型计算对象点时,使用如下的数值:
a)(用户界面的)屏幕数
b)报表数
c)构造应用可能需要的构件数
22.对象点数NOP=初始的对象实例数*表中的加权因子
23.采用基于构件的开发或一般的软件利用时,
对象点数NOP=对象点×[(100-复用的百分比)/100]
24.生产率=PROD=NOP×人·月
25.估算工作量=NOP/PROD
26.软件方程E=[(LOC×B0.333)/P3]×(1/t4)
27.最短开发时间定义为:
tmin=8.14(LOC/P)0.43,以月为单位,用于tmin>6个月的情况
28.E=180Bt3,以人月为单位,用于E≥20人月的情况
注意方程中的t是以年为单位的。
29.面向对象项目的估算
第5讲项目进度安排
1.软件延期交付的原因:
期限不切实际、需求变更、估计不足、出现风险、技术困难、人力困难和交流不畅以及未能发现进度拖后。
2.当管理者要求的项目结束期限我们无法实现时,我们应该怎么办?
⏹按照以往项目的历史数据进行详细的估算,确定项目的估算工作量和工期。
⏹采用增量过程模型,制定一个软件开发策略,以保证能够在规定的交付日期提供主要功能,而将其他功能的实现推到以后。
然后将这一计划做成文档。
⏹与客户会谈并(用详细估算结果)来解释为什么规定的交付日期是不现实的,一定要指出所有这些估算都是基于以往的项目实践,而且一定要指出为了在目前规定的交付期限完成项目,与以往相比在工作效率上必须提高的百分比
⏹将增量开发策略作为可选计划提交给客户
3.项目计划的早期,首先建立一个宏观进度表,该进度表标识出所有主要的软件工程活动和这些活动影响到的产品功能。
4.项目进度安排基本原则:
⏹划分
⏹相互依赖性
⏹时间分配
⏹工作量确认
⏹确定责任
⏹明确结果
⏹确定里程碑
5.在一定程度上可以缩短项目交付日期(通过增加额外资源),也可以拖延项目交付日期(减少资源数量)。
6.PNR曲线表名完成一个项目的时间与投入该项目的人员工作量之间是高度非线性的:
开发工作量E=L3/(P3t4)(P:
生产率参数,t:
项目工期,L:
代码函数)
7.软件过程中的工作量分配通常采用40-20-40法则。
总体工作量的40%分配给前期的分析和设计,40%的用于后期测试。
因此,你可以推断出编码工作(20%的工作量)是次要的。
8.软件的重要性决定了所需测试工作的分量,如是果软件系统是人命相关的,就应该考虑分配更高的测试工作量比例。
9.没有能普遍适用于所有软件项目的任务集合。
10.一个任务集包括软件工程工作任务、里程碑,以及为完成某个特定项目就必须完成的工作产品。
11.概念开发项目的完成需要应用以下主要任务:
⏹确定概念范围。
⏹初步的概念策划。
⏹技术风险评估。
⏹概念证明。
⏹概念实现。
⏹客户对概念的反应。
12.任务网络,也称为活动网络,是一个项目的任务流程的图形表示。
13.程序评估和复审技术(programevaluationandreviewtechnique,PERT)和关键路径方法(criticalpathmethod,CPM)就是两种可以用于软件开发的项目进度安排方法。
14.项目的工作分解结构(workbreaddownstucture,WBS),其定义可以是针对整个产品,也可以是针对单个功能进行的。
15.输入工作分解结构(WBS)后,就可以产生时序图,也叫做甘特图(GanttChart)。
16.甘特图水平条表示每个任务的工期,同一时段中存在多个水平条时,就代表任务之间存在并发,菱形表示里程碑。
17.输入了生成时序图所需的信息之后,大多数软件项目进度安排工具都会生成项目表——列出所有项目任务的表格,项目表中列出了各个任务的开始与结束日期及各种相关信息。
18.在面对交付期限的巨大压力时,有经验的项目管理者有时会使用一种称为“时间盒”的项目进度安排和控制技术,选择增量软件开发范型。
19.迭代模型是最好的OO项目框架。
20.OO项目技术里程碑:
(1)OO分析完成
(2)OO设计完成(3)OO程序设计完成(4)OO测试
21.用于项目进展的定量分析技术,称为挣值分析(earnedvalueanalysis,EVA),是对项目进展的测量。
22.预算成本BCWS,BCWSi指工作任务i的计划工作量。
23.完成工作的预算BAC=∑(BCWSi)。
24.已完成工作的预算成本BCWP
25.进度表执行指标 SPI=BCWP/BCWS
26.进度表偏差 SV=BCWP-BCWS
27.预定完成百分比=BCWS/BAC
28.完成百分比=BCWP/BAC
29.成本执行指标CPI=BCWP/ACWP(已完成工作的实际成本),CPI值越接近1.0说明项目与预算越接近。
30.成本偏差CV=BCWP-ACWP
31.计划活动是软件项目管理的重要组成部分,而进度安排是计划活动的首要活动,进度安排始于过程分解(WBS)。
32.计划活动进度安排过程分解(WBS)时序图或甘特图项目表
第6讲风险管理
1.风险是潜在的-它可能发生也可能不发生。
2.风险管理的步骤:
a)风险识别
b)分析风险
c)制定计划管理风险
3.风险管理工作产品:
a)风险缓解
b)监测和管理(RMMM)计划或一组风险信息表单(RiskInformationSheet,RIS)
4.风险的定义:
(1)未来将要发生的事情
(2)风险涉及改变(3)风险设计选择
5.大多数软件项目团队还是仅仅依赖于被动的风险策略(救火模式)。
6.主动风险策略早在技术工作开始之前就已经启动了
7.主动风险策略是制定一个风险计划,目标是回避风险,但不是所有的风险都能够回避,必须制定一个应急计划。
8.软件风险包含两个特性:
a)不确定性
b)损失
9.风险分析时,重要的是量化每个风险的不确定性程度和损失程度。
10.风险类型:
a)第一种:
⏹项目风险(威胁到项目计划)
⏹技术风险(威胁到要开发软件的质量及交付时间)
⏹商业风险(威胁到要开发软件的生存能力)
b)第二种:
⏹一般性风险
⏹产品特定的风险
11.识别风险的一种方法是建立风险条目检查表。
12.风险因素包括:
性能、成本、支持和进度。
13.风险影响类别:
可忽略的、轻微的、严重的或灾难的。
14.风险预测又称风险估计,风险估计的两个方面:
a)可能性或概率
b)产生的后果
15.分析预测的方法是建立风险表,采用电子表格模式来实现:
16.风险驱动因子的评估是基于定性的概率等级,可表示为:
不可能、不一定、可能和极可能。
17.风险的性质、范围和时间这三个因素可能会影响风险所产生的后果。
18.风险显露度RE=P×C(P:
风险发生的概率,C:
风险发生时带来的项目成本)
19.实现方法之一是按条件-转化-结果(condition-transition-consequence,CTC)格式来表示风险,即采用如下方式来描述风险:
给定<条件>,则(可能)将导致:
<结果>。
20.所有风险分析活动都只有一个目的:
辅助项目团队制定处理风险的策略。
21.处理风险有效的策略必须考虑三个问题:
a)风险回避。
b)风险监测。
c)风险管理及应急计划。
22.项目管理者可以将Pareto的80-20规则用于软件风险上,整个项目的80%风险可能是由只占20%的已经识别出的风险所引发。
23.风险监测活动有三个主要目的:
a)评估所预测的风险是否真正发生了
b)保证正确地实施了各风险缓解步骤
c)收集能够用于今后风险分析的信息
24.软件安全和危险分析是一种软件质量保证活动,主要用来识别和评估可能对软件产生负面影响并使整个系统失败的潜在灾难。
25.风险管理策略可以包含在软件项目计划中,也可以将风险管理步骤组织成一个独立的风险缓解、监测和管理计划(RMMM计划)。
26.RMMM计划将所有风险分析工作文档化,有些软件团队并不建立正式的RMMM文档,而是将每个风险分别使用风险信息表单(RIS)进行文档化。
第7讲质量管理
1.用户满意度=合格的产品+好的质量+按预算和进度安排交付
2.软件质量保证由评估质量控制活动有效性和完整性的一系列审核和报告功能构成。
3.软件质量保证的目的是:
为管理层提供了解产品质量所必需的数据,从而获得产品质量是否符合预定目标的认识和信心。
4.质量成本可以细分为与预防成本、鉴定成本及失效成本。
5.软件质量的定义:
软件要符合明确的功能和性能需求,符合已清晰文档化的开发标准,并且具有专业人员开发的软件所应有的隐含特征。
6.软件质量保证(SQA)的参与者:
软件工程师和SQA小组
7.SQA小组的职责是辅助软件团队实现高质量的软件产品。
8.SQA活动:
a)编制项目质量保证计划
b)参与项目的软件过程描述的编写
c)评审软件工程活动,以验证是否符合规定的软件过程
d)审核指定的软件工作产品以验证是否遵守作为软件过程一部分的那些规定
e)确保根据文档化的规程记录和处理软件工作及工作产品中的偏差
f)记录各种不符合的部分,并报告给高层管理人员
9.软件评审是最为重要的质量控制活动之一,是软件过程中的“过滤器”,软件评审方式有:
a)非正式会谈
b)将软件架构正式介绍给客户、管理层和技术人员
c)正式技术评审(FTR)
10.正式技术评审(FTR)的主要目标是在此过程中发现错误,以使它们不会在软件交付之后变成缺陷。
正式技术评审的最明显的优点是可以早发现错误,以防止错误被传播到软件过程的后续阶段。
11.缺陷的放
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 项目 管理 复习题
![提示](https://static.bdocx.com/images/bang_tan.gif)