天津理工大学计算机项目管理期末复习

项目管理期末考试

15个缩写/30分 6个问答题/30分 分析题3题/40分

第一章

What is software project management? Is it really different from ‘ordinary’ project management?

软件项目的特性：不可见性、复杂性、一致性、灵活性 软件项目管理在管理方面的特性。管理包括以下活动：

● ● ● ● ● ● ● ●

策划：决定要做什么 组织：进行安排

人员：选择合适的人员来完成任务等 指导：作出指示 监督：检查进展

控制：采取行动以清除项目的障碍 革新：提出新的解决方案

代表：与客户、用户、开发人员、供应商以及其他利益相关者进行沟通

②How do you know when a project has been successful? 就软件项目而言，可以总结为以下目标：

? 实现既定功能。 ? 达到质量要求。 ? 按时。 ? 在预算内。

就商业方面而言，一个项目的成功是指项目的收益高于成本。

③Stakeholders? 利益相关者

利益相关者是指在项目中有利害关系的人。 利益相关者可以分为以下几类：

1）项目组内部人员 这意味着项目负责人直接管理这类利益相关者。

2）项目组外部人员但属于同一组织内部 例如需要用户的帮助来执行系统测试，此时有关人员的委托必须经过协商。

3） 项目组和组织的外部人员 外部的利益相关者可能是受益于所实现系统的客户（或用户）。这些人之间的关系大多建立在具有法律效力的合同之上。

④Some ways of categorizing software projects 软件项目分类的方式

1、强制使用用户和自愿使用用户

在工作场所中，有一些系统是员工完成工作（比如记录销售业务）必须使用的系统，然而有些系统的使用是自愿而非强制的，比如游戏软件。我们很难用一个业务系统从潜在客户那里引导出精确的需求。游戏软件的内容主要依靠开发人员丰富的创造力，以及市场调查、关注群体和原型评价等技术手段。 2、系统与嵌入式系统：

信息系统与嵌入式系统之间存在着传统的区别。信息系统可以帮助员工完成事务处理操作，如库存管理系统。嵌入式（或过程控制）系统用于控制机器，比如建筑物的空调设备的控制系统。有些系统可能兼有二者的要素，比如上述库存管理系统也可以控制一个自动化仓库。

3、目标与产品

要区别项目的目标是为了生产一种产品，还是为了满足一定目标。 项目可能是生产一种其细节由客户规定并负责证实的产品。

另一方面，项目可能是为了满足一定目标，这些目标可能有多种方法来达到。

很多软件项目有两个阶段。第一阶段是目标驱动项目，可产生项目的建议书；第二阶段是实际创建该软件产品。

⑤Activities covered by software project management 软件管理覆盖的活动 开发新系统通常有三个连续的步骤：

1）可行性研究 评估一个预期的项目是否值得开始——即存在一个有效的业务案例。 2）策划 如果可行性研究的结果指出预期的项目可行，那么就可进入策划阶段。 3）项目实施 现在可以实施项目了，项目实施通常包括设计和实现两个子阶段。

第二章

①Cost-benefit evaluation techniques 成本效益评价技术

净利润（net profit）：是在项目的整个生命周期中总成本和总收入之差。 回收期（payback period）：是达到收支平衡或偿还初始投入所花的时间。

投资回报率（Return On Investment，ROI）：也称作会计回报率（Accounting Rate of Return，ARR），提供了一种方法来比较净收益率与需要的投入。 ROI=（平均年利润/总投资）×100%

※净现值（Net Present Value，NPV）：是一种项目评价技术，它考虑了项目的收益率和要产生的现金流的时限。

现值=第t年的值/(1+r)t

r是贴现率，用十进制小数值表示。t是现金流在未来出现的年数。

练习 假定贴现率为10%，计算项目的NPV。

②Programme management 项目集管理

项目集：为了获得利益，用协同方式管理的一组项目，而这些项目不能进行独立的管理。 项目集的存在形式： 商业周期项目集 战略项目集 基础设施项目集 研究和开发项目集 创新的伙伴关系

第三章

Step-Wise methods 步进式方法

第一步：标识项目的范围和目标 第二步：标识项目的基础设施 第三步：分析项目的特征 第四步：标识项目的产品和活动 第五步：估算每个活动的工作量 第六步：标识活动的风险 第七步：分配资源 第八步：评审/发布计划

第九步和第十步：执行计划并进行较低层次的策划

第四章

①Take account of the characteristics of the system to be developed.

选择通用的生命周期方法： 控制系统（control system）

信息系统（information system） 用户可用性（availability of users） 专用技术（specialized techniques） 硬件环境（hardware environment）

安全性关键的系统（safety-critical system） 不准确的需求（imprecise requirement）

②Select an appropriate process model. 选择合适的过程模型 —— Waterfall process model 瀑布模型

One-shot 一次完成 once-through 一次通过

V-process model V过程模型是瀑布模型的扩展 Spiral model 螺旋模型是研究瀑布模型的另一种方法 —— prototypes model 原型模型

原型是已规划的系统的一个或多个方面的工作模型。

原型分类：

抛弃型原型：只验证某些想法，然后在真正开发系统时抛弃 进化型原型：开发和修改原型，直至它最终成为可运行的系统

——

increment model 增量式模型

增量式交付是将应用程序分解为小的构件，然后按顺序实现和交付构件，每个要交付的构件应该给用户带来一些效益。

时间盒（time-boxing）通常与增量式方法相关联。每个增量可交付物的时机严格受已批准的最终期限的约束。这个最终期限必须满足，甚至可以删掉一些计划的功能，或者可以转移到后面的增量去实现。

——

aqile development methods

第五章

①Avoid the changers of unrealistic estimates. 避免不现实估计

估计过高可能导致项目花更长的时间。 ● 帕金森定律（Parkinson Law） ● 布鲁克斯定律（Brooks Law） 估计过低的危险是影响质量。

②Understand the range of estimating methods that can be used.

软件开发工作量估计的主要方法：

算法模型 使用代表目标系统和实现环境特征的“工作量驱动因子”来预测工作量。 专家判断 征求知识渊博的员工的建议。

类比 标识一个类似的已完成的项目的实际工作量作为新项目的基础。 帕金森法 标识做一个项目可利用的员工工作量，并用来作为“估计”。 赢的价格 “估计”似乎是一个相当低的赢得合同的数字。

自顶向下 明确地规划整个项目的总体估计，然后分解成为构件任务所需要的工作量。 由底向上 标识和确定构件任务的大小，然后累计这些单独的估计。 序 1 2 3 4 5 6 7 测算方法 算法模型 自底向上 自顶向下 类比 专家判断 价格致胜 帕金森法 适用范围 系统规划阶段 系统规划 系统分析/设计 准备开发 系统规划 准备开发阶段 准备开发 系统规划阶段 项目投标 项目洽谈

自顶向下法

自顶向下法通常和参数模型相关。参数模型公式如下：工作量=系统规模/生产率 预测软件开发工作量的模型有两个关键构件：第一个是评估要承担的软件开发任务的规模的方法；第二个是评估做每项任务的效率。

③Estimate projects using a bottom-up approach. 由底向上估计

估计人员将项目分解成构件任务，然后估计执行每个任务需要多少工作量。 由底向上法最适合于后期的更详细项目策划阶段。 如果一个项目完全是新颖的或者没有可用的历史数据，那么建议估计人员最好使用由底向上方法。

④Count the function points for a system. 计算功能点 功能点发进行估算的时候具体过程是： 1.对估算功能单元的类型进行识别 2.计算每种类型的复杂度． 3.计算总体的调整前的功能点数 4.根据调整因子对功能点数进行调整 FP = UFC *TCF

其中， UFC表示未调整的功能点计数； TCF表示技术复杂度因子。 对于每个事务，为调整的功能点的计算方法： Wi × (输入数据元素类型数) + We × (引用的实体类型数) + Wo × (输出数据元素类型数)

这里，Wi、We和Wo表示权重，可以通过询问开发人员在先前的项目中花在开发处理输入、访问和修改已存储的数据及处理输出的各部分软件上所占的工作量比例来导出。

⑤Estimate the effort needed to implement software using a precedural programming

language.

工作量=c×规模k

工作量（effort）是按人月（pm）度量的。规模（size）是按kdsi度量的，kdsi是指要交付的千行源代码指令。c和k是常量。

⑥Understand the COCOMO approach to developing effort model.

分为基本COCOMO模型，和中级COCOMO模型两种，前者是一个静态单变量模型，对整个软件系统进行估算；后者是一个静态多变量模型，将软件系统模型分为系统和部件两个层

次，系统是有部件组成的。

第六章

①Produce an activity plan for a project. 产生项目的活动计划

产生项目计划的第一步是确定需要执行什么活动以及以什么次序执行这些活动。第二步，理想的活动计划是活动风险分析的对象，目的是标识潜在的问题。第三步是资源分配。最后一步是产生进度表。

②Estimate the overall duration of a project. 估计项目的总周期

③Create a critical path and a precedence network for a project. 创建项目的关键路径和优先网络

Activity-on-node networks

Float = LF - ES - duration

关键路径是通过网络的最长路径

Activity-on-arrow networks

练习6.1 使用优先网络约定为表6-1所指定的项目绘制一个活动网络。完成之后，请将结果与图6-14进行比较。

练习6.2 参看图6-7描绘的Amanda的CPM网络。使用表6-2中给出的活动周期，计算项目的最早完成日期，并标识网络上的关键路径。

第七章

①Definition of ‘risk’and ‘risk management’.

风险：用来描述不希望的时间或结果。 风险管理：对危险和可能的问题进行标识、对其重要性进行评价以及编制监控和处理这些问题的计划。

②Some ways of categorizing risk. 风险分类——据风险内容划分

1）技术风险：如果项目采用了复杂的或者高新的技术，或者采取了非常规的方法，就存在一些潜在的问题。另外，如果技术目标制定过高，技术标准发生变化等也可能造成技术的风险发生。

2）管理风险：在项目中，进度计划制定和资源配置不合理，计划草率且质量控制差，项目管理的基本原则适用不当等，都可能带来管理的风险。

3）组织风险：常见的组织内部对目标未达成一致，高层对项目不重视，资金不足，项目组织的人员结构不合理或者与其他项目有资源冲突等，都是潜在的组织风险。

4）外部风险：法律法规的变化，与项目相关各方的情况发生变化，这些事件和外部环境变化往往是不可控制的。但注意，一般将不可控制的“不可抗力”不作为风险，这些事件往往作为灾难防御。

③Risk management ※

—— Risk identification — what are the risks to a project? 风险标识：减少不确定性，清楚项目风险的因素和作用范围 —— Risk analysis — which ones are realty serious? 风险分析：根据风险的严重度对风险的优先级进行排序 —— Risk planning — what shall we do?

风险规划：制定各种风险应对计划、策略、行动方案 风险策划和控制策略： ? 风险预防 ? 降低可能性 ? 风险规避 ? 风险转移 ? 应急计划

—— Risk monitoring — has the planning worked? 风险控制：检查和检验决策的结果

④We will also look at PERT risk and critical chains. ‘expected time’期望周期te = （a + 4m + b）/6 te 期望周期 a 乐观的时间 m 可能的时间 b 悲观的时间

‘activity standard deviation’活动标准偏差 s = (b - a)/6

PERT技术使用以下三个步骤来计算满足或不满足目标日期的概率： ● 计算每个项目事件的标准偏差。 ● 计算有目标日期的每个事件的z值。 ● 转换z值为概率。

计算每个项目事件的标准偏差

事件3的标准偏差只取决于活动B的标准偏差。因此，事件3的标准偏差是0.33。 对事件5，有两条可能的路径B+E或F。路径B+E的总标准偏差是， 而路径F的总标准偏差是1.17。因此，事件5的标准偏差是两者之中的大者，即1.17。 计算z值

其中，te是期望日期，而T是目标日期。

事件4的z值是（10-9.00）/0.53=1.8867。 转换z值为概率

练习7.5 表7-6为图6-29所示的网络提供了附加的活动周期估计。有新的估计a和b及原来的活动周期估计用作最可能的时间m，计算每个活动的期望周期te。

第八章

①How to match the activity plan to available resources.

产生资源分配计划的第一步是列出所要求的资源以及要求的期望等级。产生资源需求列表后，下一步是将这个列表映射为活动计划，然后评估项目期间所需要的资源分布。

②Assess the efficacy of changing the plan to fit the resources.

③Schedules.

—— Activity schedule — Indicating start and completion dates for each activity. —— Resource schedule — Indicating dates when resources are needed and level of

resources.

—— Cost schedule — showing the planned accumulative exp.

资源分配的最终结果通常包括：

活动进度 表示每个活动计划的开始日期和完成日期。 资源进度 表示每个资源要求的日期以及要求的调度等级。 成本进度 表示资源使用过程中计划的累积花费。

第九章

①Monitor the progress of projects. 监督项目的进展

②Assess the risk of slippage. 评估偏离的风险

③Visualize and assess the state of a project. 可视化和评估项目的状态

甘特图

一种最简单也是最早的跟踪项目进展的方法就是甘特图。本质上，这是一种活动条形图，它指出计划的活动日期以及随着活动的浮动而频繁增大的周期。

延迟图

延迟图是另一种非常类似的图。这种图对于那些没有按进度计划进展的活动，提供了更加醒目的可视化指示：延迟线越弯曲，对计划的偏离就越大。

时间线

到目前为止，描述的所有图都存在一个缺点，即不能清除地显示贯穿整个项目生命周期的项目完成日期的拖延情况。

时间线图是记录和显示在项目期间目标变更的一种方法。

时间线图在项目执行期间以及作为后期实现部分的评审都是有用的。时间线图的分析和变化的原因可以指出估计过程的失误或者其他可能的错误，有了这方面的信息，将来就能避免这些失误。

④Reuse targets to correct or counteract drift. 修订目标以纠正或抑制偏离 CPI可以用来修正项目的成本预算（或者完成估计EAC）。EAC计算公式为BAC/CPI，其中BAC（Budget At Completion，BAC）是项目当前计划的预算。如果BAC原来是100 000英镑，那么修订的EAC将是100 000/0.64即156 250英镑。可以通过目前的SPI修正估计的项目周期。

⑤Control changes to a project’s requirements. 控制项目的需求变更 系统范围的变更

在IS开发项目中，经常发生系统规模不断增大的情况。原因之一在于用户提出了对需求的变更请求。

项目范围需要谨慎地加以监督和控制，一种方法是在关键里程碑处按照SLOC或者功能点重新估计系统规模。

第十章

①Follow the stages needed to acquire software from an external supplier.

合同部署阶段 需求分析 评估计划 邀请投标 评估提议

②Distinguish between the different types of contract 合同的种类 1、固定价格合同

在这种情况下，当合同签订时价格已经是确定的了。客户知道，如果合同的条款没有变

化，这就是项目完成时应该支付的价格。为了让这种机制更加有效，在开始时必须让承包商知道客户的需求，并且这些需求不能改变。用另一种说法就是，如果这个合同是为了构建一个软件系统，则必须完成详细的需求分析，一旦开始开发，客户就不能再没有重新商定价格的情况下更改他们的需求。 这种合同的优点是：

知道客户的花费 如果需求是明确的而且不变更的，客户有明确费用。 供应商的动机 供应商以成本效益为动机。 其缺点是：

意外情况下的价格较高 供应商承受任何估算错误所带来的风险。为了减少这种风险的影响，供应商将在投标书中计算价格时留出足够的余地。

修改需求困难 在开发过程中，有时需要修改需求的范围，这有可能造成供应商和客户之间的摩擦。

增加修改成本的压力 在和其他投标商竞争时，供应商不得不给出尽可能低的价格。一旦合同签订了，当给出进一步的需求时，供应商就会提出很高的修改价格。 对系统质量的威胁 为了满足固定的价格，软件的质量可能得不到保证。 2、时间和材料合同

在这种合同中，客户必须为每一个单位（例如每一个员工时）的工作量付出一定的报酬。供应商通常会基于他们当前对客户需求的理解给出成本，但是这并不是最终报酬的基础。供应商通常会定期（例如每月）向客户列出已完成工作的清单。 这种合同的优点如下：

改变需求容易 需求修改很容易处理。如果项目有一个研究方向，但随着项目的深入，项目的研究方向会发生变化，那么这可能是恰当的计算报酬的办法。 没有价格的压力 没有价格的压力能创造出更高质量的软件。 这种合同的缺点是：

客户的义务 客户要承受与需求定义不妥和需求变更相关的所有风险。

供应商缺乏动力 在以合算的方式工作或者在控制交付系统的范围方面，供应商没有动力。

3、每单位固定价格合同

这经常与计算功能点相关。在项目开始时，已经计算或者估计好要交付的系统的规模。交付系统的规模可以通过代码行数来估计，但是可以从需求文档中更容易、更可靠地获得功能点（FP）数。每一个单位的价格都会清楚地注明，最终价格就是单位价格乘以单位数量得到的。

这种方法的优点如下：

客户的理解 客户可以清楚地知道价格是如何计算的，并知道修改需求之后价格如何变化。

可比较性 不同的价格表可以进行比较。 产生新功能 供应商不承担增加功能的风险。

供应商的效率 与实践和材料合同不同，供应商仍有以合算的方式交付所需要的功能的动力。

生命周期的范围 需求不需要在开始时明确，因此，开发合同既能覆盖项目的分析阶段，又能覆盖项目的设计阶段。 这种方法的缺点是：

软件规模度量有困难 代码行数很容易由于采用较为冗长的编码风格而膨胀。对于FP而言，可能在FP的数量上产生分歧——在某些情况下，FP的计算规则可能对供应商或者客户不公平。特别是，用户几乎不熟悉FP的概念，因而需要特殊的训练。这个问题的解决方法就是使用一个独立的FP计算器。

修改需求 有一些修改可能会严重影响现有的事务处理，却不会对FP的数量有什么影响。因而必须就如何处理这些修改做出决定。开发末期的修改几乎总要比开发前期的修改费力。

练习10.1 Amanda会选择这三种系统中的哪一种作为IOE维护组账户系统呢？她需要考虑什么因素？

● 定制的系统，一种特地为一个客户从头开发的系统。

● 买来就用的商用软件包，有时指简易包装（shrink-wrapped）的软件。 ● 定制的商用软件（COTS），这是一种对基本的核心系统进行修改以满足特定客户需要的软件。

练习10.2 一个将要设计和实现的系统有3200个FP。根据表10-1，这个系统总的费用将是多少？

练习10.3 合同规定设计、构建和交付计算机应用程序的成本是每个FP600美元。验收测试之后，客户要求修改系统的某些功能，总计有500个FP，并要求增加一些新的功能，总计有200个FP。请用表10-2计算附加的费用。

本文来源：https://www.bwwdw.com/article/a02w.html