[软件项目管理]期末考试题-问答题|项目管理期末考试题

项目的特征有哪些？

 有明确的目标

 项目之间的活动具有相关性

 限定的周期

 有独特性

 资源成本的约束性

 项目的不确定性

项目与日常运作有什么不同？

 项目是一次性的，日常运作是重复进行的

 项目是以目标为导向的，日常运作是通过效率和有效性体现的

 项目是通过项目经理及其团队工作完成的，而日常运作是职能式的线性管理  项目存在大量的变更管理，而日常运作则基本保持连贯性的。

软件项目有什么特殊性？

 为逻辑实体而非物理实体，具有抽象性

 没有明显的制造过程，也不存在重复生产

 软件项目的开发受到计算机硬件的制约

 不可能完全摆脱手工开发模式

 软件本身是相当复杂的，涉及因素众多，需求多变

 软件项目投入大、成本高

软件项目管理有什么特征？

 软件是纯知识产品，其开发进度和质量很难估计和度量，生产率也难以预测和保证。

 项目周期长，复杂度高，变数多。

 软件项目提供的是一种服务，需要满足一群人的期望，即需要满足一群想法和利益各不相同的人的需求。

PMBOK包括哪9个知识领域？

 集成管理

 范围管理

 时间管理

 成本管理

 人力资源管理

 沟通管理

 风险管理

 质量管理

 采购管理

常用的生存期模型有哪些？各适用于什么项目？

 瀑布模型：分析、设计、编码、测试和维护严格按步骤进行，适合于项目开始前有明确需求和明确的解决方案的项目，如公司的财务系统、库存管理系统、短期项目等。

 V模型：是瀑布模型的变种，强调测试的重要性，将开发活动与测试活动紧密联系在一起。适合于对系统的性能、安全有严格要求的项目。

 原型模型：适合于在项目开始前对项目需求不明确，为了减少项目需求的不确定性而先开发项目的基本原型系统以验证可行性，然后逐步补充完善。

 增量模型：由瀑布模型演变而来，假设需求可分阶段，分成一系列增量产品分别开发。适合于项目开始明确了需求的大部分，但对市场和用户把握不是很准。对于有庞大和复杂功能的系统也可考虑增量开发。

 螺旋式模型：该模型在四个象限上分别表达了计划制定、风险分析、项目实施、客户评估四个方面的活动，通过一系列瀑布模型的不断循环来逐步规避风险。适合于不确定因素较多、风险较大的项目。

 渐近式阶段模型：综合了增量模型和螺旋式模型的一个实用模型，渐进式前进，阶段式提交。适合各种规模的项目，尤其是大中型项目，以及希望随时看到未来的项目。

如何为项目选择合适的生成期模型？

 熟悉各种生存期模型

 评审、分析项目的特性

 选择适合项目的生存期模型

 标识生存期模型与项目不一致地方,并进行裁减

何谓需求获取？它包括哪些主要活动？

 需求获取指通过与用户的交流、对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。

 需求获取的主要活动包括：

- 了解客户方的所有用户类型及潜在的类型

- 对用户进行访谈和调研，包括会议讨论、邮件提问、自行搜集等各种形式 - 对收集到的用户需求作进一步分析整理

- 将调研得到的用户需求以适当的形式呈交给用户和开发方相关人员

需求分析的主要内容有哪些？如何处理不明确需求？

 需求分析的主要内容有：

- 以图形表示的方式描述系统的整体结构，包括边界和接口等

- 通过原型、页面流或其它方式向用户提供可视化界面，以便用户对需求作出自己的评价

- 以模型描述系统的功能项、数据实体、外部实体以及实体间的关系、状态转换等  不明确需求的处理方法有：

- 让用户参与开发，以便及时对不明需求作出修正

- 开发用户界面原型，以便用户更好地确认需求

- 召开需求讨论会议，汇总和确认需求

- 强化需求分析和评审，让用户参与需求评审并签字认可

如何做好需求变更管理？

 建立需求基线

 确定需求变更控制过程

 成立变更控制委员会(SCCB)

 进行需求变更影响分析

 跟踪所有受需求变更影响的工作产品

 建立需求基准版本和需求控制版本文档

 维护需求变更的历史记录

 跟踪每项需求的状态

 衡量需求的稳定性

何谓任务分解？为什么要进行任务分解？

 任务分解就是将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。它是一个化繁为简，分而治之的过程。

 任务分解的作用：

- 提供了项目范围基线，是范围变更的重要输入

- 为评估和分配任务提供具体的工作包

- 进行估算和编制项目进度的基础

- 对整个项目成功的集成和控制起到非常重要的作用

假设你是某图书馆借阅系统的项目经理，请参照教材“校务通系统”项目计划案例进行需求分析和任务分解，提交需求规格说明书和任务分解WBS图表或清单。

简述软件项目进度(时间)管理的主要任务。

 活动定义

 活动排序

 活动历时估计

 任务资源估计

 制定进度计划

 进度控制(项目跟踪)

项目进度(历时)估算需考虑的因素有哪些？

 实际工作时间：一周几天、一天几小时

 项目的人员规模

 生产率：LOC/天

 有效工作时间：除去聊天、打电话、上卫生间等的时间

 连续工作时间：不被打断的持续工作时间

 人员级别：不同人员的生产率不同，成本不同

 历史项目：参考以往类似项目

项目进度估算的基本方法有哪些？

 定额估算法：根据项目规模、投入资源及单位生产率计算项目历时，公式为T = Q /(R×S)

 经验导出模型：使用根据大量历史项目统计得出的模型公式计算，如COCOMO模型等

 工程评价技术(PERT)：利用PDM任务网络图和加权历时估算公式计算项目总历时  基于承诺的进度估计法：从需求出发，由开发人员承诺项目进度

 Jones的一阶估算准则：根据项目功能点数及开发商评级，使用公式粗略估计项目历时

 其它：专家估计法、类推估计法、模拟估计法等

何谓正推法？简述其计算任务历时的基本步骤及计算公式。

 正推法是按照时间顺序计算任务网络图上各活动的最早开始时间和最早完成时间的有效方法。

 其计算步骤如下：

- 首先建立项目的开始时间，项目的开始时间是网络图中第一个活动的最早开始时间

- 从左到右，从上到下进行计算，遍历所有路径

- 当一个任务有多个前置任务时，其最早开始时间应取前置任务其中最大的最早完成时间

 计算公式:

- EF = ES + Duration（Duration为任务历时）

- ES(2) = EF(1) + Lag（1为前置任务，2为后置任务， Lag为滞后时间） 何谓逆推法？简述其计算任务历时的基本步骤及计算公式。

 逆推法是按照逆时间顺序计算任务网络图上各活动的最晚开始时间和最晚结束时间的有效方法。

 其计算步骤如下：

- 首先建立项目的结束时间，项目的结束时间是网络图中最后一个活动的最晚结束时间

- 从右到左，从上到下进行计算，遍历所有路径

- 当一个任务有多个后置任务时，其最晚完成时间应取后置任务中最小的最晚开始时间。

 计算公式:

- LS = LF - Duration（Duration为任务历时）

- LF(1) = LS(2) – Lag （1为前置任务，2为后置任务， Lag为滞后时间） 何谓类比估算法？它适用什么情况？具有什么特点？

 类比估算法是根据以往完成的类似项目所消耗的总成本（或工作量）来推算将要开发的软件的总成本（或工作量），然后按比例将它分配到各个开发任务单元中，是一种自上而下的估算形式。

 该方法主要适用于在合同期和市场招标时，或因信息不足或只需粗略估算，或有类似的历史项目数据时。

 它的特点是简单易行，花费少。但具有一定的局限性，准确性差，容易导致低估。 何谓自下而上估算法？它适用什么情况？具有什么特点？

 自下而上估算法是利用任务分解结构图，对各个具体工作包进行详细的成本估算，然后将结果累加起来得出项目总成本。

 该方法主要适用于项目开始以后和WBS的开发阶段，或需要进行准确估算的时候。

 它的特点是估算结果比较准确，准确度决定于每个任务的估算情况。但非常费时，估算本身的费用较大，且可能发生虚报夸大成本现象。

简述提高估算准确性的主要措施。

 作好充分的估算准备

 留出估算的时间，并做好计划

 充分参考以前的项目数据

 以开发人员提供的数据为基础估算

 分类法估算(多种方法分别估算并对比)

 详细的较低层次上的估算

 使用软件估算工具

 使用几种不同估算技术，并比较它们的结果

简述资源冲突的表现及解决措施。

 资源冲突的表现为：

- 分配给一个资源的工时总量大于它的最大可用工时量。

- 同一种资源被分配给时间上重叠的几个任务或项目中。

 解决资源冲突的方法：

- 资源调配

- 推迟资源开始工作时间

- 替换资源

- 设置资源加班时间

- 调整资源日历

- 只使用资源的一部分工作时间。

简述降低预算成本的常用方法。

 降低资源的费率：降低资源的费率往往会打击工作人员的积极性，但可以通过降低其他资源的费率来实现，比如降低能源消耗、设备费用。

 减少任务的工时：适当的减少工时，可以降低任务的费用。但减少工时同时也影响项目的工期。

 减少加班：加班需要支付加班费率，这通常要高于资源费率，所以减少加班可以有效的减少任务成本。

 替换资源：用廉价的资源替换比较高价的资源，但有一个前提，那就是替换的资源同样能胜任这项任务。

 减少任务的固定成本：固定成本就是任务本身所需要的成本。

 删除任务：确认删除该任务对项目没有影响或影响在可控制范围内才可采用 优化进度，缩短工期的主要方法有哪些？

 分解关键任务，使它们同步进行以缩短工期

 给任务增加资源(如人员)以加快进度

 缩减关键任务的工期

 重叠关键任务

 设置日历增加工作时间

 通过分配加班工时来缩短关键任务

简述McCall软件质量模型的三个方面的11项特性。

McCall软件质量模型包括如下三方面11项特性：

 运行：

- 正确性(我能按我的需要正确地工作吗)

- 健壮性(我对各种可能的意外能很好地适应吗)

- 效率(完成预定功能它需要的资源多吗)

- 完整性(它能有效地保证数据的完整性吗)

- 可用性(我能容易地学会使用它吗)

 修正：

- 可维护性(遇到问题它能容易修复吗)

- 灵活性(我能方便地对它作一些调整吗)

- 可测试性(我能对它作必要的测试吗)

 转移：

- 可移殖性(我能在别处使用它吗)

- 可复用性(我能对它的某些部分再利用吗)

- 互连性 (它能与其它系统方便对接吗)

简述软件项目审计的基本内容。

 审计是将审核的主体与为该主体以前建立的一组规程和标准进行比较，以便对过程或者产品进行质量评估。

 软件项目审计是一种常见的软件质量保证活动，包括项目执行过程评审和项目产品审计两方面。

 项目执行过程评审是对项目的执行过程进行检查，确保所有活动遵循规程进行，然后提交审计报告。

 项目产品审计是对项目过程中的工作产品进行质量审查，记录不符合项，编写产品审计报告。

简述职能型组织结构的优缺点。

 优点：

- 可以充分发挥职能部门的资源集中优势

- 部门的专家可以同时为部门内不同项目使用

- 便于相互交流 , 相互支援

- 可以随时增派人员

- 可以将项目和本部门的职能工作融为一体

 缺点：

- 项目和部门利益发生冲突，职能部门更重视本部门的目标,会忽视项目目标 - 资源平衡会出现问题

- 权利分割不利于各个职能部门的交流和团结协作

- 行政隶属关系使得项目经理没有充分的权利

简述项目型组织结构的优缺点。

 优点：

- 项目经理对项目可以负全责

- 项目目标单一，以项目为中心,有利于项目顺利进行

- 避免多重领导

- 组织结构简单，交流简单,效率高

 缺点：

- 资源不能共享

- 各个独立的项目处于相对封闭状态,不利于公司政策的贯彻

- 对项目组织的成员缺少一种事业上的连续性和安全感

- 项目组织之间处于分割状态,缺少信息交流

简述矩阵型组织结构的优缺点。

 优点：

- 专职的项目经理负责整个项目,以项目为中心

- 公司的多个项目可以共享各个职能部门的资源

- 即利于项目目标的实现,又利于公司目标方针的贯彻

- 项目成员的顾虑减少了

 缺点：

- 容易引起职能经理和项目经理权力的冲突

- 资源共享也能引起项目之间的冲突

- 项目成员有多头领导

简述项目沟通计划的主要内容。

 分析沟通需求：什么人什么时候需要沟通

 确定沟通的内容：沟通的格式、内容及详细程度

 确定沟通方式和方法：口头、书面、会议、E-Mail等

 确定沟通的收发职责：管理沟通信息的发布与接收

 安排沟通的时间频度

 沟通计划修订维护

简述软件项目存在较大风险的原因。

 软件项目的需求变化大

 软件项目计划和估算难度大

 软件项目管理的难度大

 承包方信用问题

 人员变动问题

 技术问题

 政策变化问题

 性能达不到

简述风险的基本性质。

 风险的客观性：是不以人的意志为转移的

 风险的不确定性：风险难以度量和掌控

 风险的不利性：风险发生时将导致损失或破坏

 风险的可变性：在一定的条件下风险可以转化

 风险的相对性：不同的主体对风险的承受办不同

 风险同利益的对称性：风险与利益共存

简述软件外包的基本步骤及管理措施。

 步骤：

- 竞标邀请：向候选乙方分发“外包项目竞标邀请书”及相关材料，乙方参与竞标 - 评估候选乙方的综合能力，对候选乙方进行粗筛选和综合评估。

- 选出最合适的承包商。

 管理措施：

- 保障沟通：要有承包方开发小组的订技术人员或主管亲自负责协调沟通。 - 做好计划：要制定详细、完整的项目计划，并在计划中详细列出每一件工作需要哪方面的哪些人力来共同执行，计划中的每一个进度都需要进行确认才能继续。 - 避免延误：计划中要预留足够的时间来进行确认工作，也只能在正式确认后才可继续接下来的工作。

何谓软件配置管理？简述其功能和目标。

 软件配置管理是一套规范、高效的管理软件开发及各种中间软件产品的方法和规则。

 配置管理的主要功能是记录软件产品的演化过程，实施有效的版本管理和变更管理，最终保证软件产品的完整性、一致性、追朔性、可控性。

 配置管理的基本目标是：

- 有计划地对各种项目产品进行标识管理

- 让各种项目产品能够被识别、控制和获取

- 让各种项目产品的更改得到有效控制

- 让相关组织或个人及时了解软件基线的状态和内容

简述基线变更管理的基本过程。

 基线变更需要经过SCCB授权，按程序进行控制并记录基线修改过程。变更过程包括如下4步：

(1) 首先提出变更申请并填写相应的变更申请表

(2) 对变更申请进行评估，对变更的类型及可能产生的影响进行评审

(3) 根据评估结果决定批准或拒绝变更，并确定版本更新(若批准)

(4) 从基线库提取基线产品修改，完成变更和版本升级。

简述导致项目执行偏差的原因及控制偏差的措施。

 导致偏差的原因：

- 对项目的范围没有做明确透彻的分析和定义

- 对项目所涉及的资源、环境、工具等的成本分析不够完善准确

- 对于项目的质量不够重视，或者说不具备质量管控的能力。

- 许多项目的风险分析并未引起项目管理者的足够重视

- 项目组成员的职业素养不够

 控制偏差的措施：

- 设立里程碑，并给予里程碑事件足够的重视。只要能保证里程碑事件的按时完成，整个项目的进度也就有了保障。

- 关注薄弱环节，实现动态平衡。在项目进度的管理过程中，需要不断调度、协调，保证项目的均衡发展，实现项目整体的动态平衡。

- 明确每个成员的责任。定任务、定人员、定目标，进一步明确责任，确保关键任务的进度。

简述质量保证与质量控制的关系。

 质量保证的焦点在过程；而质量控制的焦点在产品推出前的质量把关。

 质量保证是通过各种手段来保证高质量的软件结果的过程，属于管理职能；而质量控制是直接对项目工作结果的质量进行把关的过程，属于检查职能。

 质量控制是针对具体的产品或者具体的活动的质量管理；而质量保证是针对一般的、具有普遍性的问题，或者说软件开发的过程中的问题进行的质量管理。质量保证促进了质量的改善，可以导致企业的性能产生一个突破。

 质量保证是从总体上提供质量信心，而质量控制是从具体环节上提高产品的质量。通过质量保证和质量控制可以提高项目和产品的质量，最终达到满意的目标。 简述海兹伯格的激励理论，并提出相应的激励策略。

 海兹伯格的激励理论认为，人的行为受两类因素的影响，一是激励因素（内在因素），包括成就感，责任感，晋升，被赏识、认可等；二是保健因素（外在因素），包括工作环境，薪金，工作关系，安全等。

 激励策略：

- 从外在因素角度，要密切注意员工的情绪波动，多与员工沟通，消除和缓解不满情绪；对制度和政策多作解释工作以消除误解；向上级反映员工的合理要求与建议，以完善相关政策制度；协调好项目组内的人际关系，对出现的紧张关系要及时加以调解；公正地评价员工表现并安排晋升。

- 从内存因素角度，项目经理要鼓励和帮助员工制订个人成长计划，为员工的进步和成长提供机会，对骨干进行适当授权，对成绩及时肯定，提高员工的成就感和责任感。

简述常见风险及其处理措施。

 项目缺少可见性：可以通过迭代开发、技术评审、持续集成来增强项目的可见性。  新技术引入：通过原型开发、充分论证、多阶段评审、同行经验等措施可降低新技术风险。

 技术兼容性：可以通过设计先行、售前产品测试等方法来降低这种风险。

 性能问题：可以通过性能规划、性能测试、充足的调试时间等方法来降低这种风险。

 仓促上线：可以通过应急预案、分步切换、交叉培训等方法降低风险。

 可用性问题：可以通过了解用户、参与设计、竞争性分析等方法降低风险。