山东大学软件过程管理复习纲要

1、项目管理支持活动有哪些？

配置管理，度量和分析，决策分析。

2、CMM/CMMI、PSP、TSP、RUP、XP、SCRUM、PDCA、MSG、SEPG、WBS、SPI

CMM——软件能力成熟度模型（CapabilityMaturity Model，CMM）是美国卡内基.梅隆大学软件工程研究所（SEI）汇集了世界各地软件过程管理者的检验和智慧而产生的软件过程改进的指导性模型。该模型经过世界各地软件组织的实际应用，证明其对软件过程改进具有建设性作用。

CMMI——软件能力成熟度模型集成（CapabilityMaturity Model Integration）

PSP——个体软件过程（Personal SoftwareProcess）是一种可用于控制、管理和改进个人工作方式的自我持续改进过程，是一个包括软件开发表格、指南和规程的结构化框架。

TSP——团队软件过程（Team SoftwareProcess）是一个已经被良好定义和证明的支持构建和管理团队的最佳实践，指导团队中的成员如何有效地规划和管理所面临的项目开发任务，告诉管理人员如何指导软件开发队伍。

RUP——Rational统一过程（Rational Unified Process）由Rational公司推出的一种软件过程框架。包括六条开发经验，迭代式开发、管理需求、使用基于构建的体系结构、可视化建模、验证软件质量、控制软件变更。

XP——极限编程（eXtreme Programming）是敏捷过程中最负盛名的一个，其名称“极限”二字的含义是指把好的开发实践运用到极致。

SCRUM——是一种迭代式增量的敏捷软件开发过程，包括了一系列时间和预定义角色的过程骨架。

PDCA——（Plan-Do-Check-Action计划-执行-检查-行动）PDCA循环式能使任何一项活动有效进行的一种合乎逻辑的工作程序，特别是在质量管理中得到了广泛的应用。

MSG——管理层指导组（Management SteeringGroup，MSG）

SEPG——软件工程过程组（SoftwareEngineering Process Group，SEPG）

WBS——工作分解结构（Work BreakdownStructure）是以可交付成果为导向的对满足项目目标和开发交付产物的项目相关工作进行的分解。

SPI——软件过程改进（Software ProcessImprovement，SPI）

3、软件过程与软件质量的关系

软件产品的质量取决于开发软件的过程管理的质量，对于一个软件组织来讲，可以通过软件过程改进来提高其所开发的软件产品的质量。

4、PROBE估算产品规模的基本流程

（1） 概要设计

初步设计，为了辅助估算而进行的一种类似于搭积木的游戏的工作。

（2） 代理识别

根据概要设计的结果，为每一块“积木”制定合适的类型，定义合适的相对大小，从而确定其规模。

（3） 估算并调整程序规模

代理规模与程序规模往往不一样，以面向对象程序设计语言为例，一般情况下，除了类以及类中的方法之外往往还有一些代码在类的外部或者方法的外部，估算的时候也需要考虑这些代码。此外，由于估算本质上是一种主观判断，因此难免出现偏差，而且，这种偏差不能简单地根据上一次的偏差进行补偿修正。

（4） 估算并调整资源

对于项目所需资源的估计也是由代理规模通过线性回归的方法进行调整计算而得。

（5） 计算预测区间

在获得了调整后的估算结果之后，还需要对估算结果进行评价，通常采取的方法就是计算预测区间。

5、相关性和显著性描述什么

相关性——描述的是两组变化的数据之间相互关联的程度。

显著性——描述的是两组数据的相关关系出现的偶然程度，显著性越小越好。

6、应用PROBE方法估算规模时，A，B，C，D四类方法的数据要求是什么

7、质量指标的含义和计算（Yield、A/FR、PQI、评审速度、DRL）

Yield——用以度量每个阶段在消除缺陷方面的效率。

Phase Yield（某个阶段缺陷消除的效率）=100*（某个阶段发现的缺陷个数）/（某个阶段注入的缺陷个数+进入该阶段前遗留的缺陷个数）

Process Yield（第一次编译之前消除缺陷的效率）=100*（第一次编译前发现的缺陷个数）/（第一次编译前注入的缺陷个数）

A/FR——是一个用以指导软件工程师合理安排评审和测试时间的指标。

A/FR=PSP质检成本/PSP失效成本

（1）理论上，A/FR的值越大，往往意味着越高的质量。

（2）过高的A/FR往往意味着做了过多的评审，反而会导致开发效率的下降。作为指南，

（3）在PSP中A/FR的期望值就是2.0

PQI——（Process Quality Index，过程质量指标）用以度量PSP过程的整体质量。范围是从0.0-1.0。

PQI=设计质量*设计评审质量*代码评审质量*代码质量*程序质量。

设计质量：设计的时间应该大于编码的时间

设计评审质量：设计评审的时间应该大于设计时间的50%

代码评审质量：代码评审时间应该大于编码时间的50%

代码质量：代码的编译缺陷密度应当小于10个/千行

程序质量：代码单元测试缺陷密度应当小于5个/千行

l  评审速度——（Review Rate）是一个用以指导软件工程师开展有效评审的指标。高质量的评审又需要软件工程师投入足够的时间进行评审。在PSP的实践中，代码评审速度小于200 LOC/小时，文档评审速度小于4 Page/小时。

DRL——（Defect-Removal Leverage，缺陷消除效率比）度量的是不同缺陷消除手段消除缺陷的相对效率。

DRL=其他阶段每小时发现的缺陷数/该测试阶段每小时发现的缺陷数

8、两阶段小组评审的过程，如何估算小组评审之后评审对象遗留的缺陷数（不知道为什么，感觉会出计算题，建议看懂。）

（1）小组评审只有两个人参加。假设评审人员A和B分别发现了a个缺陷和b个缺陷，其中c个缺陷两人同时发现。利用捕鱼（统计学中经典的估算池塘中鱼总数的方法，即先捕一网，对所有捕获的鱼进行标记，再将鱼放回池塘，过一段时间，再捕一网，那么通过该网中被标记的鱼的数目和未被标记的鱼的数目比例，即可大致测算整个池塘的鱼总数的方法。这个是解释，考试不用写。打字手疼。）的思想，选择a-c和b-c中较大值，如果相等则可以任选一值。假设a-c是选定的值，那么就可以估算出评审对象经过小组评审之后，还遗留a*b/c-(a+b-c)个缺陷。

（2）小组有多人参加。小组评审如果有多人参与，那么情况就会相对复杂，我们采取一个简化的计算方法，即选择某个独立发现缺陷最多的评审员作为A，而其他所有参与人员的整体作为B。那么我们仍然可以使用上述的方式来估算小组评审之后评审对象中遗留的缺陷数。

9、失效成本、质检成本、预防成本的差异

是质量成本的三个组成部分

失效成本——分析失效现象、查找原因、做必要的修改所消耗的成本。

质检成本——评价软件产品，确定其质量状况所消耗的成本。

预防成本——识别缺陷根本原因、采取措施预防其再次发生所消耗的成本。

为了操作方便，在PSP中对上述定义稍作简化，PSP中主要关注失效成本和质检成本，而预防成本一般包含在总结阶段以及平时评审检查表的维护中，因此，不专门进行计算。PSP中定义的失效成本为编译时间和单元测试时间之和，PSP中定义的质检成本为设计评审时间与代码评审时间之和。

10、           PSP中各设计模板的作用

（1） OST（OperationalSpecification Template，操作规格模板）描述的是系统与外界的交互，具体而言，是描述“用户”与待设计系统的正常情况和异常情况下的交互。可以用来定义测试场景和测试用例，也可以作为和系统用户讨论需求的基础，特别是操作相关的需求描述。

（2） FST（FunctionalSpecification Template,功能规格模板）描述的是系统对外的接口，这是一种静态的描述，在FST中提供的典型信息包括类和继承关系、外部可见的属性和外部可见的方法等。在使用FST模板的时候，消除二义性非常重要。因此，应尽量用形式化符号来描述方法行为。

（3） SST（StateSpecification Template，状态规格模板）可以精确定义程序的所有状态、状态之间的转换以及伴随每次状态转换的动作。在SST模板中，需要描述以下信息——所有状态的名称、所有状态的简要描述、在SST中需要使用的参数和方法的名称与描述、状态转换的条件、伴随状态转换而发生的动作。

（4） LST（LogicalSpecification Template，逻辑规格模板）可以精确描述系统的内部静态逻辑。为了消除描述的二义性，一般建议用伪代码配合形式化符号来描述设计结果。在LST模板中，需要描述如下信息——关键方法和静态逻辑、方法的调用、外部引用、关键数据的类型和定义。

11、           正确的状态机设计应该满足哪些要求

一个设计正确的状态机的状态转换必须满足两个条件，即必须满足完整性和正交性。状态转换完整性是指对于状态机中任何一个状态，对应的所有条件组合，下一个状态的转换都有定义。状态转换正交性是指对于状态机中任何一个状态，其所有下一个状态的转换条件不能相同，简言之，在一个正确状态机中，任何一个状态，当对应的条件组合一样时，其下一个状态必须唯一定义。

对于状态机的验证，通常采取如下步骤进行，

（1） 检验状态机，消除死循环和陷阱状态。

（2） 检查状态转换，验证完整性和正交性。

（3） 评价状态机，检验是否体现设计意图。

12、           PSP中验证设计主要有哪些方法？各有什么优势和不足

包括状态机验证、符号化验证、执行表验证、跟踪表验证、正确性验证。

（1） 状态机验证步骤如上

（2） 符号化执行验证的基本思想是将描述设计的逻辑规格（一般用伪代码程序表示）用代数符号来表示，然后系统地开展分析和验证。具体步骤如下：识别伪码程序中的关键变量；将这些变量用代数符号表示，重写伪码程序；分析伪码程序的行为。

优缺点：

符号化验证的方法实施简单，可以给出一般化的验证结果，很多时候往往是唯一提供全面验证的方式。

这种方法通常用在验证一些复杂算法中，特别是对遗留系统的改造中，往往应用这种方法来识别和理解原有的设计。

但是这种验证方法不适用于有复杂逻辑的场合，而且，纯手工的验证方法也容易引入一些人为的错误。

（3） 执行表验证用一种有序的方法来跟踪伪码程序的执行状况，分析程序行为，从而验证设计。具体步骤如下：识别伪码程序的关键变量；构建表格，表格左侧填入主要程序步骤，右侧填入关键变量；初始化被选定的变量；跟踪被选择的关键变量的变化情况，从而判断程序行为。

优缺点：

执行表验证可以用以复杂逻辑的验证，实施简单，结果可靠。

而这种方法也有一些不足，比如每次只能验证一个用例，手工验证既耗时，也容易出错等。

（4） 跟踪表验证方法是对执行表验证方法的一种扩充。具体步骤如下：识别伪码程序的关键变量；构建表格，表格左侧填入主要程序步骤，右侧填入关键变量；初始化被选定的变量；识别将伪码程序符号化的机会，并加以符号化；定义并且优化用例组合；跟踪被选择的关键变量的变化情况，从而判断程序行为。

（5） 正确性检验将伪码程序当成数学定理，采用形式化方法加以推理和验证。这种方法的步骤如下：分析和识别用例；对于复杂伪码程序的结构，应用正确性检验的标准问题逐项加以验证；对于不能明确判断的复杂程序结构，使用跟踪表等辅助验证。

13、           解释客户需求、产品需求和产品组件需求的区别和联系

（1） 客户需求描述的是客户的期望。客户在实际工作中碰到了一些具体问题，希望通过软件系统来帮忙解决这些问题，客户的这种解决问题的愿望，往往就代表为客户需求。

（2） 产品需求描述的是开发团队所提供的解决方案，即针对客户需求，开发团队设计出一个可以帮助客户解决工作中碰到的问题的方案。该方案往往就表述为产品需求。产品需求是对客户需求的一个提炼和精化，把客户需求真正表述为开发人员够理解的语言，同样，产品需求需要进行验证，以确保客户的真实意图得到了体现。

（3） 产品需求组件描述的是组成产品的各个组件的需求价格，与产品需求相比，这是在更细小的颗粒上，更为细致地描述了上述解决方案中的某个组建的功能、性能、形式等。

14、           产品集成有哪些典型的策略，优缺点是什么

产品集成策略包括大爆炸集成、逐一添加集成、集簇集成、以及扁平化集成等。

（1） 大爆炸集成策略，将所有已经完成的组件放在一起，进行一次集成。测试用例最少，每个用例测试次数最少，但是，难以定位缺陷位置，系统越复杂，规模越大，问题越突出。

（2） 逐一添加集成策略，与大爆炸集成策略完全相反，采取一次添加一个组建的方式进行集成。优点是很容易定位缺陷的位置，但是需要测试的用例最多，大量的回归测试会消耗很多时间。

（3） 集簇集成策略，是对逐一添加集成策略的改进，为了提升测试效率，把有相似功能或者有关联的模块优先进行集成，形成可以工作的组件，然后以组件为单位继续进行较高层次的集成。优点是可以尽早获得一些可以工作的组件，有利于其他组件测试工作的开展。缺点是过于关注个别组件，缺乏系统的整体观，不能尽早发现系统级的缺陷。

（4） 扁平化集成策略，要求尽快构建一个可以工作的扁平化系统，优先集成高层的部件，然后逐步将各个组件、模块的真正实现加入系统。优点是可以尽早发现系统层面的缺陷，缺点是为了确保完成系统，需要大量的打“桩”，即提供一些直接提供返回值的伪实现。这种测试方式往往不能覆盖整个系统应该处理的多种状态。

15、           项目计划阶段需要制定哪些计划？约定的内容是什么？

任务计划、日程计划、质量计划、风险计划等

项目各项计划完成之后，需要与各类计划的相关干系人开展评审工作，解决计划中相互矛盾与不一致的地方，并获得参与项目的各方对项目计划的承诺。

(1)识别每一项计划所需支持，并与相关干系人协商承诺。

(2)记录所有的承诺，包括完整的承诺和临时的承诺，并确保由适当层次的人员签署。

(3)适时与资深管理人员一起审查承诺。

16、           什么是风险？风险应对的方法。

风险，可能会给项目目标的实现带来负面影响的潜在问题。

风险管理是一个持续的、前瞻的过程，此过程是项目管理的重要部分。有效的风险管理是通过相关干系人的合作与参与，尽早且积极地识别风险，制定项目风险管理计划。风险管理须同时考虑有关成本、进度、绩效及其他风险的内部及外部来源。因为在项目初期进行变更或修正的工作负荷，通常比在项目后期来得容易、花费较低及较不具破坏性，所以，早期及积极的风险侦测是重要的。风险管理大致分成两部分，即风险识别和风险应对。

风险应对的方法

风险转嫁

风险转嫁是指通过某种安排，在放弃部分利益的同时，将部分的项目风险转嫁到其他的团队或者组织。比如有的公司采取外包的方式，把一部分有技术风险的产品组件交由其他公司开发，在放弃部分收益的同时，也规避了技术风险。

风险解决

风险解决是指采取一些有效措施，使得风险的来源不再存在。这往往是一种预防性的手段。比如针对项目面临的技术风险，采取技术调研或者引进技术专家的手段，使得原有的风险来源不再存在或者存在可能性极低，从而测试解决该风险。

风险缓解

风险缓解是指容忍风险的存在，采取一些措施监控风险，不让风险对项目最终目标的实现造成负面影响。一般情况下，都需要制定相应的风险缓解计划。理性对待每个关键性的风险，研究可选择的应对方案，并对每个风险皆制定相应的行动过程，是风险缓解计划的关键内容。特定风险的风险缓解计划包括规避、降低及控制风险发生可能性的技术和方法，或降低风险发生时遭受的损失程度的方法，或上述两者。监控风险，当风险超过设定的阈值时，实施风险缓解计划，以使受冲击的部分回归到可接受的风险等级。只有当风险结果评定为高或无法接受时，才相应制定风险缓解计划和紧急应变计划，其它其他情况只需要适当监控即可。

17、           挣值管理方法的原理

（1）BAC表示按照PV值的曲线，当项目完成的时候所需预算或者时间

（2）成本差异CV = EV-AC，表示的是已经完成的的工作与所消耗的成本的差异。可以表示为消耗的时间，也可以表示为消耗的资金。

（3）成本差异指数CPI = EV/AC，表示单位成本创造的价值。<1表示超支，=1表示与预期一致，>1表示成本低于预期。

（4）日程偏差SV = EV – PV，表示进度偏差。<0表示进度落后，=0表示进度正常，>0表示进度超前。

（5）日程偏差指数SPI = EV/PV

（6）预计完成成本EAC = AC+(BAC-EV)/CPI = BAC/CPI，表示的是按照目前的进展以及成本消耗情况，整个项目完成的时候所需消耗的成本。

18、           BAC、PV、EV、AC、CV、SV、CPI、SPI、EAC

(1)BAC（项目总预算）

(2)PV（PlanningValue，计划价值）

(3)EV（EarnedValue，挣值）

(4)AC（ActualCost，实际成本）

(5)CV（CostVariance，成本差异）

(6)SV（ScheduleVariance，日程偏差）

(7)CPI（CostPerformed Index，成本差异指数）

(8)SPI（SchedulePerformed Index，日程偏差指数）

(9)EAC（ExpectedAccomplished Cost，预计完成成本。

l  BAC表示按照PV值的曲线，当项目完成的时候所需预算或者时间

l  成本差异CV = EV-AC

l  成本差异指数CPI = EV/AC

l  日程偏差SV = EV – PV

l  日程偏差指数SPI = EV/PV

l  预计完成成本EAC = AC+(BAC-EV)/CPI = BAC/CPI

（课本习题）

BAC 1000

PV 200

EV 50

AC 100

CV -50

SV -150

CPI 0.5

SPI 0.25

EAC 2000

ETC 1900

19、           项目跟踪的意义

（1） 在项目进展过程中开展跟踪活动的目的在于了解项目进度，以便在项目实际进展与计划产生严重偏离时，可采取适当的纠正措施。开展及时有效地项目跟踪就是期望及时发现和处理项目实际进展与计划之间的偏差，从而消除累积的偏差对项目造成的负面影响。

（2） 判断项目进度滞后需要参照物，文档化的项目计划就是监控各项项目活动，沟通状态及采取纠正措施的依据。

（3） 项目跟踪除了发现偏差之外，更重要的是管理针对偏差而采取的纠偏措施。

（4） 项目小组需要对项目纠偏措施进行跟踪和管理，其目的是确保项目香足所采取的纠偏措施真正有效。

在项目进展过程中开展跟踪活动的目的在于了解项目进度，以便在项目实际进展与计划产生严重偏离时，可采取适当的纠正措施。

项目进度滞后与否需要参照物，即项目计划。

项目跟踪需要管理针对偏差而采取的纠偏措施。

20、           项目总结的目的和意义

（1） 软件项目的特点决定了持续改善对于软件工程师的重要性。

（2） Rita Mae Brown在书中写到的那样“所谓的愚蠢（Insanity）就是反复做同样的事情，但是期望有不同的结果”

（3） 提供一个系统化的方式来总结经验教训、防止犯同样的错误、评估项目团队绩效、积累过程数据等。提供给项目团队成员持续学习和改进的机会。

21、           配置项、基线

（1） 配置项是在配置管理当中作为单独实体进行管理和控制的工作产品集合。

（2） 基线是配置项持续演进的稳定基础。发布一个基线包括该基线所有的配置项以及这些配置项的最新变更，因此，可以将基线作为接下来工作的基础。典型的发布基线时间点为需求分析之后、设计完成之后、单元测试之后以及最终产品发布。

22、           配置管理的目标和活动

配置管理的目的是建立与维护工作产品的完整性。

配置管理的活动

（1）   识别配置项

（2）   建立配置管理系统

（3）   创建和发布基线

（4）   跟踪变更请求

（5）   控制配置项变更

（6）   建立配置管理记录

（7）   配置审计

23、           GQM方法原理

GQM从管理的目标出发，将目标归纳、分解为可度量的指标，并把这些指标提炼成可以测量的值。实施过程是从上到下的分析过程和从下到上的执行过程。首先提出度量目标G（Goal）；然后将该目标细化为关于过程或产品的特定问题Q（Question）；这些问题以度量M（Metric）的方式得到回答。

GQM方法在三个层次上定义度量模型：

概念层（目标）

操作层（问题）

量化层（度量）

24、           自主团队的特点

（1） 自行定义项目的目标

（2） 自行决定团队组成形式以及成员的角色

（3） 自行决定项目的开发策略

（4） 自行定义项目的开发过程

（5） 自行制定项目的开发计划

（6） 自行度量、管理和控制项目工作

25、           组织级过程改进的一般工作思路

（1） 启动组织级的软件过程改进

（2） 诊断存在的问题

（3） 给出改进计划

（4） 建立基础设施

（5） 执行改进计划

（6） 分析结果