软件项目管理与案例分析思考题及答案.docx

软件项目管理与案例分析思考题及答案.docx

《软件项目管理与案例分析思考题及答案.docx》由会员分享，可在线阅读，更多相关《软件项目管理与案例分析思考题及答案.docx（25页珍藏版）》请在冰豆网上搜索。

软件项目管理与案例分析思考题及答案

软件项目管理

第一章

思考题：

1、当我们选择软件项目的负责人时，我们在寻找什么？

成功的项目负责人应采用一种解决问题的管理风格。

也就是说，软件项目经理应该注重理

解要解决的问题、把握住涌现 的各种意见、同时让项目团队的每一个人知道质量很重要，

不能妥协。

2、选择软件团队的结构时，应该考虑哪些因素？

（1）待解决问题的难度；

（2）开发程序的规模，以代码行或功能点来度量；（3）团队成

员需要共同工作的时间（团队生存期）；（4）能够对问题做模块化划分的程度；（5）待开

发系统的质量要求和可靠性要求；（6）交付日期的严格程度；（7）项目所需要的友好交

流的程度。

3、定义软件的结构时，我们有哪些选择？

封闭式范型。

按照传统的权利层次来组织团队。

当开发与过去已经做过的产品相似的软件

时，这种团队十分有效。

但在这种封闭式范型下难以进行创新性的工作。

随机式范型。

松散地组织团队，团队工作依赖于团队成员个人的主动性。

当需要创新或技

术上的突破时，按照这种随机式范型的团队很有优势。

但当需要“有次序地执行”才能完

成工作时，这种团队就会陷入困境。

开放式范型：

试图以一种具有封闭式范型的控制性，又包含随机式范型的创新性的方式来

组织团队。

工作是大家相互协作完成的。

良好的沟通和根据团队整体的意见做出决策是开

放式范型的特征。

开放式范型的团队结构特别适合于解决复杂的问题，但可能不像其他类

型的团队那么有效。

同步式范型。

依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没

有什么交流。

4、何谓有凝聚力的团队？

一个有凝聚力的团队是一组团结紧密的人，他们的整体力量大于个体力量的总和。

与一般

团队相比，有凝聚力的团队成员 有更高的生产率和更大的动力。

他们拥有共同的目标和共

同的文化，而且在很多情况下，“精英意识”使得它们独一无二。

5、为什么有些团队没有凝聚力？

并非所有的团队具有凝聚力。

事实上，很多团队都受害于 Jackman[ JAC 98]称之为“团队

毒性”的东西。

她定义了 5 个“培育潜在含毒团队环境”的因素

（1）狂乱的工作氛围

（2）引起团队成员产生摩擦的重大挫折（3）“碎片式的或协调很差”的软件过程（4）在

软件团队中没有清晰的角色定义（5）“接连不断地重蹈覆辙”。

6、我们如何定义关键的项目特性

W5HH 原则

为什么（Why）要开发这个系统？

对这个问题的回答，可以使所有参与者评估软件工作的商业理由的有效性。

换句话说，该

系统的商业目的值得花费这些人员、时间和金钱吗？

将要做什么（What）?

对这个问题的回答将制定完成项目所需的任务清单。

什么时候（When）做？

就是标识出何时开展项目任务和何时达到里程碑，对这个问题的回答能够帮助团队安排好

项目进度。

某功能由谁（Who）负责？

必须规定软件团队的每个成员的角色和责任。

他们的机构组织位于何处（Where）?

并非所有角色和责任均属于软件团队，客户、用户和其他共利益者也有责任。

如何（How）完成技术工作和管理工作？

一旦确定了产品范围，必须定义项目的管理策略和技术策略。

每种资源需要多少（How much）?

对这个问题的回答，是在对前面问题回答的基础上，通过估算而得到

小结：

软件项目管理是软件工程的普适性活动。

它先于任何技术活动之前开始，且持续贯穿于整

个计算机软件的定义、开发和维护之中。

4 个 P－人员、产品、过程和项目，对软件项目管理具有重大的影响。

必须将人员组织成有效率的团队，激励他们完成高质量的软件工作，并协调他们实现有效

的沟通。

产品需求必须在客户与开发者之间进行交流，划分（分解）成各个组成部分，并分配给软

件团队。

过程必须适合于人员和问题。

选择通用过程框架，采用合适的软件工程范型，并挑选工作

任务集合来完成项目的开发。

最后，必须采用确保软件团队能够成功的方式来组织项目。

第二章

思考题：

1、对软件度量的私有使用和公用使用有什么不同？

不同类型的过程数据的使用可以分为“私有的和公用的”。

私有过程数据是软件工程师个人改进其工作的重要驱动力。

公用度量一般吸取了原本是个人的或团队的私有信息。

收集和评估项目级的缺

陷率（肯定不能归因于某个个人）、工作量、时间及相关的数据，以找出能够改

善组织过程性能的指标。

2、当我们收集软件度量时，应该采用什么指导原则？

软件度量规则：

解释度量数据时使用常识，并考虑组织的敏感性。

向收集测量和度量的个人及团队定期提供反馈。

不要使用度量去评价个人。

与开发者和团队一起设定清晰的目标，并确定为达到这些目标需要使用的度量。

不要用度量去威胁个人或团队。

指出问题区域的度量数据不应该被“消极地”看待，这些数据仅仅是过程改进

的指标。

不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。

3、在项目中，我们应该如何使用度量？

软件过程度量主要用于战略的目的。

软件项目度量则是战术的。

在大多数软件

项目中，项目度量的第一个应用是在估算阶段。

从过去的项目中收集的度量可

以作为估算当前软件工作工作量及时间的基础。

随着技术工作的启动，其他项

目度量也开始有意义了。

生产率可以根据创建的模型、评审的时间、功能点以

及交付的源代码行数来测量。

4、什么是度量基线？

它能为软件工程师提供什么益处？

度量基线由从以往开发的软件项目中收集的数据构成，一个包含过程和产品测

量的数据库。

基线是估算的基础。

通过建立度量基线，软件工程师及管理者能

够更好地了解他们所做的工作和开发的产品，在过程级、项目级和产品（技术）

级上都能获得收益。

5、我们应该怎样导出一组“简单的”软件度量？

不是从测量而是从结果入手，软件小组通过表决来确定一个需要改进的目标，

根据这个目标，小型 组织可以选择一些易于收集的测量，从而得出度量，并进

行过程改进。

6、一个 Web 工程团队已经开发了一个包含 145 个网页的电子商务 WebApp。

在这些页面中，65 个是动态页面，即根据最终用户的的输入而在内部生成的页

面。

那么，该应用的定制指数是多少？

Nsp = 静态 Web 页的数量Ndp = 动态 Web 页的数量

定制指数 C = Ndp /（ Ndp + Nsp ）

=65/145

≈0.448

小结：

测量能使管理者和开发者改进软件过程，辅助进行软件项目的计划、跟踪及控

制，评估生成的产品（软件）的质量。

对过程、项目及产品的特定属性的测量可

用于计算软件度量。

分析这些度量可获得指导管理及技术行为的指标。

过程度量使得一个组织能够从战略角度深入了解一个软件过程的功效。

项目度

量是战术性的，能使项目管理者实时改进项目的工作流程及技术方法。

面向规模的度量和面向功能的度量在业界都得到了广泛的应用。

面向规模的度

量以代码行作为其他测量（如人·月，缺陷）的规范化因子。

功能点则是从信

息域的测量及对问题复杂度的主观评估中导出的。

软件质量度量（如生产率度量）关注的是过程、项目及产品。

一个组织通过建

立并分析质量的度量基线，能够纠正引起软件缺陷的软件过程区域。

测量会带来企业文化的改变。

如果开始进行度量，则数据收集、度量计算及度

量分析是必须完成的三个步骤。

通常，目标驱动的方法有助于一个组织关注于

对其业务的正确度量。

通过建立度量基线——一个包含过程和产品测量的数据

库，软件工程师及管理者能够更好地了解他们所做的工作和开发的产品。

第三章

思考题:

1、有效测量过程的步骤是什么？

1　公式化。

导出适合于所考虑软件表示的测量和度量。

2　收集。

用于导出公式化度量所需数据和积累机制。

3　分析。

度量的计算和数学工具的使用。

4　解释。

为获得对表示的质量的理解而评价度量。

5　反馈。

从对递交给软件团队的产品度量的解释中获得建议。

2、用于提供问题复杂性的指标有哪些？

Fi 用于提供问题复杂性的指标。

Fi（i＝1~14）是值调整因子（VAF），它基于对下列问题的回答来确定：

系统需要可靠的备份和恢复吗？

需要专门的数据通信从应用系统中传输信息或将信息传输到应用系统吗？

存在分布处理功能吗？

性能是关键的吗？

系统将运行在一个现有的、紧张使用的操作环境吗？

系统需要在线数据项吗？

在线数据项需要对多个屏幕或操作建立输入事务吗？

ILF 在线更新吗？

输入、输出、文件或查询复杂吗？

内部处理复杂吗？

所设计的代码是可复用的吗？

转换与安装包括在设计中吗？

系统是为不同组织中的多个安装而设计的吗？

应用系统是为便于变更和易于为用使用而设计的吗？

每个问题可用从 0（不重要或不适用）到 5（绝对必需）间的数值来回答。

小结：

软件度量为产品内部属性的质量评估提供了一种定量方法，从而可以使软件工

程师在产品开发出来之前进行质量评估。

度量为创建有效的分析模型、设计模

型、可靠的代码和完全的测试提供了必要的理解。

为在现实世界中有用，软件度量必须是简单和可计算的、有说服力的、一致和

客观的。

它应该是与程序设计语言无关的，且为软件工程师提供有效的反馈。

分析模型的度量侧重于分析模型的三个成分：

功能、数据和行为。

第四章

思考题：

1、基于 LOC 和基于 FP 的估算有什么共同点？

LOC 和 FP 估算是两种不同的估算技术，但两者有很多共同的特性：

项目计划

人员从界定的软件范围陈述入手，根据该说明将软件分解成一些可分别独立进

行估算的功能问题。

然后，估算每个功能的 LOC 或 FP（即估算变量）。

2、我们如何计算软件规模的期望值？

可以通过乐观值（Sopt）、可能值（Sm）和悲观值（Spess）估算的加权平均值来计算估

算变量（规模）的期望值 S：

S = （Sopt + 4Sm + Spess ） / 6

3、为什么开发基于用例的估算技术很困难？

描述用例时，可以采用多种格式和风格－没有标准形式。

用例表现的是软件的外部视图（用户视图），常常在不同的抽象级别上建立

用例没有标识出它所描述的功能和特性的复杂性。

用例没有描述出涉及很多功能 和特性的复杂行为（如，交互）。

4、什么是对象点？

对象点是一种间接的软件测量。

计算对象点时，使用如下的数值：

1）（用户界面的）屏幕数

2）报表数

3）构造应用可能需要的构件数

小结：

在项目开始之前，软件项目计划人员必须先估算三件事：

需要多长时间、需要

多少工作量、以及需要多少人员。

此外，计划人员必须预测所需要的资源（硬件

及软件）和蕴含的风险。

范围陈述能够帮助计划人员使用一种或多种技术进行估算，这些技术主要分为

两大类：

分解和经验建模。

分解技术需要划分出主要的软件功能，接着估算：

（1）LOC 的数量；

（2）信息域内的选择值；（3）用例的数量；（4）实现每

个功能所需的人·月数；或者，（5）每个软件工程活动所需的人·月数。

经验

技术使用根据经验导出的关于工作量和时间的公式来预测这些项目数字，可以

使用自动 工具来实现特定的经验模型。

对项目做精确估算时，一般至少会用到上述 3 种技术中的两种。

通过对不同技

术产生的估算值进行比较和调和，计划人员更有可能得到精确的估算。

软件项

目估算永远不会是一门精确的科学，但可靠的历史数据与系统化的技术结合起

来能够提高估算的精确度。

第五章

思考题：

1、当管理者要求的项目结束期限我们无法实现时，我们应该怎么办？

在这种情况下，推荐以下的处理步骤：

1）按照以往项目的历史数据进行详细的估算。

确定项目的估算工作量和工期。

2）采用增量过程模型，制定一个软件开发策略，以保证能够在规定的交付日

期提供主要功能，而将其他功能的实现推到以后。

然后将这一计划做成文

档。

3）与客户会谈并（用详细估算结果）来解释为什么规定的交付日期是不现实的，

一定要指出所有这些估算都是基于以往的项目实践，而且一定要指出为了

在目前规定的交付期限完成项目，与以往相比在工作效率上必须提高的百

分比

4）将增量开发策略作为可选计划提交给客户

2、在软件过程的工作流程中应如何分配工作量？

软件过程中的工作量分配通常采用 40－20－40 法则。

总体工作量的 40%分配给

前期的分析和设计，40%的用于后期测试。

因此，你可以推断出编码工作（20%的

工作量）是次要的。

这种工作量分配法只能作为指导原则。

各个项目的特点决

定了其工作量如何分配。

3、如何计算挣值以评估项目进展？

确定挣值的步骤：

1）为进度表中的每个工作任务确定其预计工作的预算成本 BCWS

BCWSi 是指工作任务 i 的计划工作量。

为了确定在项目进度表中某特定时间点

的项目进展状况，BCWS 的值是在项目进度表中该时间点应该完成的所有工作

任务的 BCWSi 值之和。

2）所有工作任务的 BCWS 值加起来，可计算出完成工作的预算 BAC

对所有任务 k，　BAC＝∑（BCWSk）

3）计算已完成工作的预算成本 BCWP。

BCWP 的值是在项目进度表中该时间

点已经实际完成的所有工作任务的 BCWS 值之和。

4、人员和时间的关系是高度非线性的。

使用 Putnam 的软件方程式编制一个表，

以反映软件项目中人员数量与项目工期之间的关系。

此项目需要 50000LOC 和

15 人年的工作量（生产率参数为 5000）。

假定该软件必须在 24±12 个月的时间

期限内交付。

小结：

计划活动是软件项目管理的重要组成部分，而进度安排是计划活动的首要活动。

进度安排与估算方法及风险相结合，可以为项目管理者画出一张路线图。

进度安排始于过程分解。

根据项目特性，为将要完成的工作选择适当的任务集。

任务网络描述了各项工作任务、每一项任务与其他任务之间的依赖关系以及计

划工期。

任务网络可以用来确定项目的关键路径、时序图以及各种项目信息。

以进度表为指导，项目管理者可以跟踪和控制软件工程过程中的每一个步骤。

第六章

思考题：

1.在建造软件时可能会遇到什么类型的风险？

1）项目风险（project risk）威胁到项目计划。

项目风险是指预算、进度、人员（聘用职员及组织）、资源、利益相关者、需求

等方面的潜在问题以及它们对软件项目的影响。

2）技术风险（technical risk）威胁到要开发软件的质量及交付时间。

技术风险指设计、实现、接口、验证和维护等方面的问题。

此外，规格说明的

歧义性、技术的不确定性、陈旧的技术以及“前沿”技术也是技术风险因素。

3）商业风险（businessrisk）威胁到要开发软件的生存能力，且常常会危害到

项目或产品。

五个主要的商业风险是：

（1）开发了一个没有人真正需要的优秀产品或系统（市场风险）；

（2）开发的产品不再符合公司的整体商业策略（策略风险）；

（3）开发了一个销售部门不知道如何去销售的产品（销售风险）；

（4）由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）；

（5）没有得到预算或人员的保证（预算风险）。

2.我们正在进行的软件项目面临严重的风险吗？

3.如何评估风险产生的后果？

如果风险真的发生了，有三个因素可能会影响风险所产生的后果，即风险的性

质、范围和时间。

以下的步骤被建议用来确定风险的整体影响：

1）确定每个风险因素发生的平均概率。

2）确定每个因素的影响。

3）填写风险表，并分析其结果。

4.用什么好的方式来描述风险？

按条件－转化－结果（condition-transition-consequence,CTC）格式来表示风险，

即采用如下方式来描述风险：

给定<条件>，则（可能）将导致：

<结果>

5.如何缓解风险？

为了缓解这个风险，项目管理者必须制定一个策略来减少人员变动。

可能采

取的步骤包括：

1）与现有人员一起探讨人员变动的起因（如恶劣的工作条件、报酬低、竞争

激烈的劳动力市场）。

2）在项目开始之前采取行动，设法缓解那些我们能够控制的起因。

3）项目启动之后，假设会发生人员变动，当人员离开时，找到能够保证工作

连续性的方法。

4）组织项目团队，使用得每一个开发活动的信息能被广泛传播和交流

5）制定工作产品标准，并建立相应机制以确保能够及时创建所有的模型和文

档。

6）同等对待所有工作的评审（使得不止一个人能够“跟上进度”）。

7）给每个关键的技术人员都指定一个后备人员。

小结：

对软件项目期望很高时，一般都会进行风险分析。

不过，即使进行这项工作，

大多数软件项目管理者都是非正式地和表面上地完成它。

花在识别、分析和管

理风险上的时间可以从多个方面得到回报：

更加平稳的项目进展过程；较高的

跟踪和控制项目的能力；在问题发生之前已经做了周密计划而产生的信心。

风险分析需要占用大量项目计划的工作量。

识别、预测、评估、管理和监测都

要花费时间。

但这是值得的。

引用中国 2500 多年前的军事家孙子的一句话：

“知己知彼，百战不殆”。

对于软件项目管理者而言，这个“彼”指的就是风险。

第七章

思考题

1、什么是软件质量控制？

质量控制是为了保证每一件工作产品都能满足对它的需求而应用于整个开发周

期中的一系列审查、复审和测试。

质量控制在创建工作产品的过程中包括一个反馈循环。

测量和反馈相结合，使

得我们能够在得到的工作产品不能满足其规格说明时调整开发过程。

质量控制中的关键概念之一就是所有工作产品都具有明确的和可测量的规格说

明，我们可以将每个过程的产品 与这一规格说明进行比较。

反馈循环对于减少

产生的缺陷是至关重要的。

2、质量成本的构成有哪些？

质量成本包括所有由质量工作或者进行与质量有关的活动所引发的成本。

质量成本可以细分为与预防成本、鉴定成本 及失效成本。

▪ 预防成本包括质量计划、正式技术复审、测试设备及培训。

▪鉴定成本包括为深入了解“首次通过”各个过程时的产品状态而开展的那些

活动。

如：

过程内和过程间的审查，设备校准和维护，测试。

▪ 失效成本是指如果将产品交付给客户之前没有缺陷的话就不会存在的成本。

3、如何定义软件质量？

软件要符合明确的功能和性能需求，符合已清晰文档化的开发标准，并且具有

专业人员开发的软件所应有的隐含特征。

定义强调了以下三个重要方面：

1）软件需求是进行质量测量的基础。

与需求不符就是质量不高。

2）规定的标准定义了一组指导软件开发的准则。

如果不能遵照这些准则，就

极有可能导致质量不高。

3）通常有一组“隐含需求”是不会被明确提出的（如对易用性和易维护性的

需求）。

如果软件明确提出的需求，却没有满足隐含需求，软件质量仍然值

得怀疑。

4、SQA 小组的作用是什么？

SQA 小组的职责是辅助软件团队实现高质量的软件产品。

SQA 活动都是由一个独立的 SQA 小组完成的，包括以下的工作：

1）编制项目质量保证计划

2）参与项目的软件过程描述的编写

3）评审软件工程活动，以验证是否符合规定的软件过程

4）审核指定的软件工作产品以验证是否遵守作为软件过程一部分的那些规定

5）确保根据文档化的规程记录和处理软件工作及工作产品中的偏差

6）记录各种不符合的部分，并报告给高层管理人员

5、我们什么时候进行 FTR，我们的目标是什么？

FTR 的目标是：

（1）发现软件的任何一种表示形式中的功能、逻辑或实现上的错误；

（2）验证评审中的软件是否满足其需求；

（3）保证软件的表示符合预先定义的标准；

（4）得到以统一的方式开发的软件；

（5）使项目更易于管理。

FTR 一般从介绍会议日程并由生产者做简单的介绍开始。

然后由生产者“走查”

该工作产品，并对材料做出解释，而评审者则根据预先的准备提出问题。

当发

现了有根据的问题或错误时，记录员逐一加以记录。

6、假设需求模型引入了 10 个错误，每个错误按 2：

1 的比例在设计阶段放大，

设计阶段引入了另外的 20 个错误，并且这 20 个错误按 1.5：

1 的比例在编码阶

段放大，在编码阶段又引入了另外 30 个错误。

进一步假设，所有单元测试会发

现所有错误的 30%，集成测试将找到剩余错误的 30%，验证测试会发现剩余错

误的 50%。

没有进行评审，有多少错误将被发布到现场？

10×2＝20

20×1.5＋20＋30＝80

80×﹙1－30％﹚＝56

56×﹙1－30％﹚＝39

39×﹙1－30％﹚＝20

7、重新考虑第 6 题所述情形，但现在进行了需求评审、设计评审和代码评审，

并且这些步骤能有效地发现所有错误的 60%。

有多少错误将被发布到现场？

10×0.4＝4

﹙4×2＋20﹚×0.4＝11

﹙11×1.5＋30﹚×0.4＝19

19×0.7＝13

13×0.7＝9

9×0.5＝5

8、重新考虑第 6 题和第 7 题所述情形，对于每个发布到现场的错误，发现和改

正的成本是 4800 美元，在评审时发现并改正每个错误花费 240 美元，通过进行

评审节约多少钱？

评审阶段发现并改正的错误：

10×0.6＋﹙4×2＋20﹚×0.6＋﹙11×1.5＋30﹚×0.6＝51

节约的钱：

22×4800－﹙5×4800＋51×240﹚＝69360

9、完成基于统计的 SQA 需要哪些步骤？

1）收集和分类软件缺陷信息。

2）追溯每个缺陷的形成原因（例如，不符合规格说明、设计错误、违背标准、

缺乏与客户的交流）。

3）使用 Pareto 规则（80％的缺陷可以追溯到所有可能原因中的 20％），将这

20％（重要的少数）原因分离出来。

4）一旦找出这些重要的少数原因，就可以开始纠正引起缺陷的问题。

10、六西格玛方法学的核心步骤 是什么？

六西格玛方法学有 3 个主要的核心步骤：

1．定义：

通过与客户交流的方法来定义客户需求、可交付的产品及项目目

标。

2．测量：

测量现有的过程及其产品，以确定当前的质量状况（收集缺陷度

量信息）

3．分析：

分析缺陷度量信息，并挑选出重要的少数原因。

如果某个现有软件过程是适当的，只是需要改进，六西格玛还需要另外两个核

心步骤：

改进：

通过消除缺陷根本原因的方式来改进过程。

控制：

控制过程以保证以后的工作不会再引入缺陷原因。

以上 3 个核心步骤和另两个附加步骤有时叫做 DMAIC 方法。

小结：

软件质量管理是在软件过程中的每一步都进行的“普适性活动”－包括质量控

制和质量保证两部分。

SQA 包括：

对方法和工具有效应用的规程，正式技术评

审，测试策略和技术，变更控制规程，保证符合标准的规程，以及测量和报告

机制。

软件质量，是计算机程序的一种属性，其定义是“与明确和隐含定义的需求的

符合程度”。

软件质量本质上的复杂性也使 SQA 复杂化。

但是一般说来，软件

质量包括了许多不同的产品和过程因素及其相关的度量信息。

软件评审是最为重要的质量控制活动之一。

评审作为所有软件工程活动的过滤

器，当发现及改正错误的成本比较小时，就消除错误。

正式技术评审是一种典

型的评审会议，在实践中已经证明这种形式对于发现错误极其有效。

为了正确软件质量保证，必须收集、评估和发布有关软件工程过程的数据。

基

于统计的 SQA 有助于提高产品和过程本身的质量。

软件可靠性模型将测量加以

扩展，能够由所收集的缺陷数据推导出相应的失效率和进行可靠性预测。

第八章

思考题

1、软件请求变更的起