软件项目管理复习整理.docx

软件项目管理复习整理.docx

《软件项目管理复习整理.docx》由会员分享，可在线阅读，更多相关《软件项目管理复习整理.docx（20页珍藏版）》请在冰点文库上搜索。

软件项目管理复习整理

软件项目管理考试要点整理

考点一：

生存期模型（生存期模型有几个，每一个的特点和适用情况，题目会给出一个项目例子，要求分析项目是属于哪种模型，为什么？

）

瀑布模型

特点

简单、易用、直观

开发进程比较严格，一个进程顺着一个进程进行

模型中没有反馈过程

模型执行过程中需要严格控制

允许基线和配置早期接受控制

一个新的项目不适合瀑布模型，除非在项目的后期

用户直到项目结束才能看到产品的质量，用户不是渐渐地熟悉系统

不允许变更或者限制变更

适合情况

在项目开始前，项目的需求已经被很好地理解，也很明确，而且项目经理很熟为实现这一模型所需要的过程，同时解决方案在项目开始前也很明确，很多的短期项目可以采用瀑布模型

V模型

特点

简单易用，只要按照规定的步骤一步一步执行即可

V模型强调测试过程与开发过程的对应性和并行性，

适合情况

项目的需求在项目开始前很明确，解决方案在项目开始前也很明确，项目对系统的性能安全很严格

原型模型

特点

需求定义之前，需要快速构建一个原型系统

用户根据快速构建的原型系统的优缺点，给开发人员提出反馈意见

根据反馈意见修改软件需求规格，以便系统可以更正确地反映用户的需求

可以减少项目的各种假设以与风险等

适合情况

当项目的需求在项目开始前不明确，或者需要减少项目的不确定性的时候，可以采用原型方法

增量式模型

特点

可以避免一次性投资太多带来的风险，将主要的功能或者风险大的功能首先实现，然后逐步完善，保证投入的有效性

可以更快地开发出可以操作的系统

可以减少开发过程中用户需求的变更

一些增量可能需要重新开发（如果早期开发的需求不稳定或者不完整）

适合情况

项目开始时，明确了大部分的需求，但是需求可能会发生变化的项目

对于市场和用户把握不是很准，需要逐步了解的项目

对于有庞大和复杂功能的系统进行功能

螺旋式模型

特点

表现为瀑布模型的多次迭代

可以将每个阶段进行更细的划分

可以进行灵活设计

通过风险管理进行驱动

用户可以更早看到产品

用户可以不断对产品进行评估

用户可以与开发人员进行精密的合作

项目的投资不用一次性投入

可以给开发人员更多的反馈信息

适合情况

项目中风险是主要的制约因素

项目中的不确定因素和风险限制了项目的进度

用户对自己的需求不是很明确

需要对一些基本的概念进行验证

可能发生一些重大的变更

项目规模很大

项目中采用了新技术

渐近式阶段模型

特点：

阶段式提交一个可运行的产品

关键的功能更早出现

早期预警问题，避免软件缺陷不知不觉的增长

减少报告负担

阶段性完成可以降低估计失误

阶段性完成均衡了弹性与效率

适合情况：

可以适合任何规模的项目，主要是中型或大型项目

希望随时看到未来的项目

考点二：

关键路径法（计算题必考，参照课堂实例）

课堂实例

作为项目经理，你需要给一个软件项目做计划安排，经过任务分解后得到任务A，B，C，D，E，F，G，假设各个任务之间没有滞后和超前，下图是这个项目的PDM网络图。

通过历时估计已经估算出每个任务的工期，现已标识在PDM网络图上。

假设项目的最早开工日期是第０天，请计算每个任务的最早开始时间，最晚开始时间，最早完成时间，最晚完成时间，同时确定关键路径，并计算关键路径的长度，计算任务F的自由浮动和总浮动.

考点三：

时间压缩法（计算题可能会考参照课堂实例）

考点四：

质量管理的案例分析（题目给出项目案例，分析质量管理过程有哪些？

）

质量管理的过程：

软件项目的质量计划：

确定项目应达到的质量标准

决定如何满足质量标准的计划安排和方法

软件质量保证

通过评价项目整体绩效，建立对质量要求的信任

提供项目和产品可视化的管理报告

该任务本身并不能提高产品的质量

项目执行过程审计

项目执行产品审计

由质量保证部门人员实施

质量保证的要点

对项目进行评价

推测能否达到质量指标

建立对项目的信心

软件质量控制

确定项目结果与质量标准是否相符

确定消除不符的原因和方法

控制产品的质量、与时纠正缺陷

任务本身提高产品的质量

有开发人员实施

质量控制的要点

检查工作结果

按照标准跟踪检查

确定措施消灭质量问题

质量控制的活动

技术评审

代码走查

测试

返工

控制图

趋势分析

抽样

考点五：

决策树分析（计算题可能会考参照课堂实例）

课堂实例：

利用决策树风险分析技术来分析如下两种情况的，以便决定你会选择哪种方案：

（要求画出决策树）

方案１：

随机投掷硬币两次，如果两次投掷的结果都是硬币正面朝上，你将获得１０元；投掷的结果背面每朝上一次你需要付出１.５元。

方案２：

随机投掷硬币两次，你需要付出２元；如果两次投掷的结果都是硬币正面朝上，你将获得１０元。

考点六：

净值分析法（计算题必考参照课堂实例）

计算公式如下：

BCWS计划完成工作的预算成本

ACWP已完成工作的实际成本

BCWP已完成工作的预算成本

BAC工作完成的预算成本

SV（进度差异）=BCWP–BCWS

CV（费用差异）=BCWP–ACWP

SPI（进度效能指标）=BCWP/BCWS

CPI（成本效能指标）=BCWP/ACWP

进度差异:

SV=BCWP-BCWS

=0：

按照进度进行

<0：

落后于进度

>0：

超前于进度

费用差异:

CV=BCWP-ACWP

=0：

按照预算进行

>0：

低于于预算

<0：

超出于预算

成本效能指数：

CPI=BCWP/ACWP

费用的支出速度

=1：

按照预算进行

>1：

低于预算

<1：

超出预算

进度效能指标：

SPI=BCWP/BCWS

已完成工作百分比

=1：

按照进度进行

>1：

超前于进度

<1：

落后于进度

课堂实例：

你被指定负责一个软件项目，其中有４部分，项目总预算为53000,A任务为26000,B任务为12000,C任务为10000,D任务为5000,截止到5月31日，A任务已经全部完成，B任务过半，C任务刚开始，D任务还没有开始，采用50/50规则计算截止到5月31日的CV，SV，CPI，SPI？

任务

ＢＣＷＳ

ＡＣＷＰ

ＢＣＷＰ

Ａ

26000

25500

Ｂ

9000

5400

Ｃ

4800

4100

Ｄ

0

0

总计

A的BCWP=26000

B的BCWP=6000

C的BCWP=5000

D的BCWP=0

任务

ＢＣＷＳ

ＡＣＷＰ

ＢＣＷＰ

Ａ

26000

25500

26000

Ｂ

9000

5400

6000

Ｃ

4800

4100

5000

Ｄ

0

0

0

总计

39800

35000

BCWS=26000+9000+4800+0=39800元

ACWP=25500+5400+4100+0=35000元

BCWP=26000+6000+5000+0=37000元

SV=BCWP–BCWS=37000-39800=-2800元

CV=BCWP–ACWP=37000-35000=2000元

SPI=BCWP/BCWS=37000/39800=93%

CPI=BCWP/ACWP=37000/35000=106%

考点七：

软件质量控制案例分析（质量的控制方法有哪些？

阐述质量管理中的问题，如何用质量控制的方法解决项目管理的问题）

质量控制方法：

（1）技术评审：

技术评审的目的是尽早发现工作成果中的缺陷，并帮助开发人员与时消除缺陷，从而有效地提高产品的质量。

技术评审例子：

1、召开评审会议：

一般应有3至5相关领域人员参加，会前每个参加者做好准备，评审会每次一般不超过2小时；

2、在评审会上，由开发小组对提交的评审对象进行讲解；

3、评审组可以对开发小组进行提问;提出建议和要求;也可以与开发小组展开讨论；

4、会议结束时必须做出以下决策之一：

接受该产品，不需做修改；

由于错误严重，拒绝接受；

暂时接受该产品,但需要对某一部分进行修改。

开发小组还要将修改后的结果反馈至评审组。

5、评审报告与记录；所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审报告

（2）代码评审和走查

代码评审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。

代码走查是在代码编写阶段，开发人员自己检查自己的代码

（3）测试

测试是程序的执行过程，目的在于发现错误；

一个好的测试用例在于能发现至今未发现的错误；

一个成功的测试是发现了至今未发现的错误的测试。

（4）返工

返工是将有缺陷的和不合格项改造为与需求和规格一致的行为

（5）控制图法

控制图法是一种图形的控制方法，它显示软件产品的质量随着时间变化的情况，在控制图法中标识出质量控制的偏差标准。

（6）趋势分析

趋势分析指运用数字技巧，依据过去的成果预测将来的产品。

（7）抽样统计

抽样统计是根据一定的分布概率抽取部分产品进行检查。

它是以小批量的抽样为

准进行检验，以确定大量或批量产品质量的最常使用的方法。

考点八：

项目总结案例分析（项目总结的过程有哪些，为什么要做？

怎么做？

对具体项目案例分析）

项目总结：

项目总结是一个把实际运行情况与项目计划不断比较以提炼经验教训的过程。

通过项目质量计划和总结，项目过程中的经验和教训将得到完整的记录和升华，成为“组织财富”。

总结包括：

总结成功的经验和失败的教训

总结软件项目历程文件

详细参考书P258-259的内容

课堂案例题：

例题一：

你是一个项目的项目经理，计划了一个项目需要36个月完成，然后提交领导，由于领导的原因导致项目的开始日期推延2个月，但是领导要求你按照计划完成，作为项目经理，你应该如何做？

解：

暂时没有找到答案

例题二：

系统集成公司A于2009年1月中标某市政府B部门的信息系统集成项目。

经过合同谈判，双方签订了建设合同，合同总金额1150万元，建设内容包括：

搭建政府办公网络平台，改造中心机房，并采购所需的软硬件设备。

A公司为了把项目做好，将中心机房的电力改造工程分包给专业施工单位C公司，并与其签订分包合同。

在项目实施了2个星期后，由于政府B部门为了更好满足业务需求，决定将一个机房分拆为两个，因此需要增加部分网络交换设备。

B参照原合同，委托A公司采购相同型号的网络交换设备，金额为127万元双方签订了补充协议。

在机房电力改造施工过程中，由于C公司工作人员的失误，造成部分电力件备损毁，导致政府B部门两天无法正常办公，严重损害了政府B部门的社会形象，因此B部门就此施工事故向A公司提出索赔。

【问题1】（4分）

请指出A公司与政府B部门签订的补充协议有何不妥之处，并说明理由。

【问题2】（5分）

请简要叙述合同的索赔流程。

【问题3】（6分）

请简要说明针对政府B部门向A公司提出的索赔，A公司应如何处理。

解：

[问题1]的解答思路

补充协议的金额超过了原合同的10%，根据采购法这是不允许的。

    A公司和B部门的补充协议有漏项，没有对增加部分网络交换设备导致中心机房的供电变化做出明确的说明。

补充协议没有说明增加设备引起的变更对机房的影响。

A公司和B部门的补充协议没有对分拆中心机房导致的风险与责任归属做出明确的规定。

A公司和B部门的补充协议应该明确规定双方的责任以与工作的X围。

如果分包的中心机房的电力改造工程属于A公司和B部门合同的主要部分，则A公司与C公司的该分包应争得B部门的同意。

A公司应该按规X的采购流程，事前审查分包商的资格并争得B部门的同意、最好由B部门直接与C公司签订协议以免责。

[问题2]的解答思路

（1）提出索赔要求

（2）报送索赔资料

    （3）索赔答复

    （4）索赔认可

    （5）提交索赔报告

    或（4）索赔存在分歧，进入仲裁与诉讼。

索赔流程如下：

[问题3]的解答思路

与B部门和C公司协商解决。

如三家协商不成，则可与C公司单独协商，由C赔偿B部门的损失。

如B部门或C不能接受，即可考虑进入仲裁或诉讼程序。

在A公司处理索赔事件应该厘清责任归属，陈述应清楚、准确、有根据、文字要精炼、条理要清楚，对C公司的索赔计算必须合理、正确。

例题三：

C公司是一家从事电子商务的外国公司，为了在中国开展业务，派出S主管和W翻译来中国寻找合适的系统集成商，试图在中国建设一套业务系统。

S主管精通软件开发，但是不懂汉语，而W翻译对计算机相关技术知之甚少。

W翻译通过中国朋友介绍，找到了从事系统集成的H公司。

H公司指派杨工为该业务系统建设项目经理，与C公司进行交流。

经过需求调研，杨工认为，C公司想要建设一个视频聊天，并据此完成了系统方案。

在W的翻译下，S审阅并认可了H公司的系统方案。

经过进一步的谈判，C公司和H公司签订了合同，并把该系统方案作为合同附件，作为将来项目验收的标准。

合同签订后，杨工迅速组织人力投入系统开发。

由于杨工系统集成经验丰富，开发过程进展顺利，对项目如期完工很有把握。

系统开发期间，S主管和W翻译忙于在全国各地开拓市场，与H公司没有再进行接触。

就在系统开发行将结束之际，S主管和W翻译来到H公司查看开发进度。

当看到杨工演示的即将完工的业务系统时，S主管却表示，视频聊天只是系统的一个基本功能，系统的核心功能则是通过视频聊天实现网上交易的电子商务活动，要求H公司完善系统功能并如期交付。

杨工拿出系统方案作为证据，据理力争。

W翻译承认此前他的工作有误，导致双方对项目X围的认识产生了偏差，并说服S主管将交付日期延后2个月。

为了完成合同，杨工同意对系统功能进行扩充完善，并重新修订了系统方案。

但是，此后C公司又多次提出X围变更要求。

杨工发现，不断修订的系统方案已经严重偏离了原始方案，系统如期交付已经是不可能的任务了。

【问题1】（6分）

请结合案例简要说明，详细的项目X围说明书应包含哪些内容，并指出C公司和H公司对哪些方面的理解出现了重大偏差。

【问题2】（6分）

请指出S主管的要求是否恰当？

为什么？

并请结合本案例简要分析导致C公司多次提出X围变更的可能原因。

【问题3】（3分）

作为项目管理者，杨工此时应关注的X围变更控制的要点有哪些？

解：

[问题1]的解答思路

对本案例而言，详细的项目X围说明书应包含如下内容：

①   项目的目标

②   产品X围描述

③   项目的可交付物

④   项目边界

⑤   产品验收标准

⑥   项目的约束条件

⑦   项目的假定

对照本案例，本案例缺乏上述条款、或上述条款太过粗略、或上述条款陈述得不详细。

C公司和H公司对如下方面的理解出现了重大偏差：

①   C公司和H公司对项目产品的理解上出现了重大偏差。

H公司认为待开发的是视频聊天，C公司要开发的是通过视频聊天实现网上交易的电子商务系统。

另外，

②   C公司缺乏科学的企业管理，同时也缺乏科学的X围变更管理。

[问题2]的解答思路

“S主管却表示，视频聊天只是系统的一个基本功能，系统的核心功能则是通过视频聊天实现网上交易的电子商务活动，要求H公司完善系统功能并如期交付。

”

评论：

S主管这个要求可以理解但并不恰当。

这是因为：

①   在项目的更早阶段，案例的【说明】中已指出“在W的翻译下，S审阅并认可了H公司的系统方案。

经过进一步的谈判，C公司和H公司签订了合同，并把该系统方案作为合同附件，作为将来项目验收的标准”。

②   “S主管要求H公司完善系统功能并如期交付”意味着H公司还要做大量的协议外的工作，而这些工作的完成即需要时间也需要成本。

因此如果H公司不追加投资还要求H公司如期交付就不太合理。

C公司多次提出X围变更的可能原因：

①   C公司自己的思路没有梳理清楚，没有明确表达出通过项目要开发的是个什么样的产品；

②   H公司没有获得客户的真实需求，或没有规X的X围管理流程，或项目X围管理计划有漏项，尤其是没有X围变更管理流程，导致X围蔓延；

③   H公司的工作不能使C公司满意。

H公司应该根据C公司的要求对原方案进行彻底的改造。

[问题3]的解答思路

作为项目管理者，杨工此时应关注的X围变更控制的要点如下：

①   建立X围基准，并征得甲方同意。

②   事先建立变更控制系统和变更控制委员会；

③   记录X围变更的全过程；

④   监控项目基准WBS与项目实际工作之间的偏差；

⑤   对X围变更申请进行甄别；

⑥   对造成X围变更的因素施加影响，使这些变更得到批准或拒绝；

⑦   当X围变更发生时，按变更流程对实际的变更进行管理，杜绝X围蔓延。

⑧   如变更得到批准，则变更项目的X围基准（重订X围基准）和项目计划；

⑨   使用配置管理系统等工具对变更进行管理。