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

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）是1种可用于控制、管理和改进个人工作方式的自我延续改进进程，是1个包括软件开发表格、指南和规程的结构化框架。

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

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

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

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

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

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

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

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

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

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

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

4、PROBE估算产品范围的基本流程

（1） 概要设计

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

（2） 代理辨认

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

（3） 估算并调剂程序范围

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

（4） 估算并调剂资源

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

（5） 计算预测区间

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

5、相干性和显著性描写甚么

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

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

6、利用PROBE方法估算范围时，A，B，C，D4类方法的数据要求是甚么

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

Yield——用以度量每一个阶段在消除缺点方面的效力。

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

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

A/FR——是1个用以指点软件工程师公道安排评审和测试时间的指标。

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

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

（2）太高的A/FR常常意味着做了过量的评审，反而会致使开发效力的降落。作为指南，

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

PQI——（Process Quality Index，进程质量指标）用以度量PSP进程的整体质量。范围是从0.0⑴.0。

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

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

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

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

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

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

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

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

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

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

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

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

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

是质量本钱的3个组成部份

失效本钱——分析失效现象、查找缘由、做必要的修改所消耗的本钱。

质检本钱——评价软件产品，肯定其质量状态所消耗的本钱。

预防本钱——辨认缺点根本缘由、采取措施预防其再次产生所消耗的本钱。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

优缺点：

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

这类方法通经常使用在验证1些复杂算法中，特别是对遗留系统的改造中，常常利用这类方法来辨认和理解原本的设计。

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

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

优缺点：

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

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

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

（5） 正确性检验将伪码程序当做数学定理，采取情势化方法加以推理和验证。这类方法的步骤以下：分析和辨认用例；对复杂伪码程序的结构，利用正确性检验的标准问题逐项加以验证；对不能明确判断的复杂程序结构，使用跟踪表等辅助验证。

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

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

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

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

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

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

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

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

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

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

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

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

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

(1)辨认每项计划所需支持，并与相干干系人协商许诺。

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

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

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

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

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

风险应对的方法

风险转嫁

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

风险解决

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

风险减缓

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

17、           挣值管理方法的原理

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

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

（3）本钱差异指数CPI = EV/AC，表示单位本钱创造的价值。<1表示超支，=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 ⑸0

SV ⑴50

CPI 0.5

SPI 0.25

EAC 2000

ETC 1900

19、           项目跟踪的意义

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

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

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

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

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

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

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

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

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

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

（3） 提供1个系统化的方式来总结经验教训、避免犯一样的毛病、评估项目团队绩效、积累进程数据等。提供给项目团队成员延续学习和改进的机会。

21、           配置项、基线

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

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

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

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

配置管理的活动

（1）   辨认配置项

（2）   建立配置管理系统

（3）   创建和发布基线

（4）   跟踪变更要求

（5）   控制配置项变更

（6）   建立配置管理记录

（7）   配置审计

23、           GQM方法原理

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

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

概念层（目标）

操作层（问题）

量化层（度量）

24、           自主团队的特点

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

（2） 自行决定团队组成情势和成员的角色

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

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

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

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

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

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

（2） 诊断存在的问题

（3） 给出改进计划

（4） 建立基础设施

（5） 履行改进计划

（6） 分析结果

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠