精华内容
下载资源
问答
  • 软件项目管理考前复习资料

    万次阅读 多人点赞 2018-12-12 16:53:27
    软件项目管理概述 1.实现项目目标的制约因素有: 项目范围 成本 进度计划 客户满意度 2.项目管理包括: 启动过程组 计划过程组 执行过程组 控制过程组 收尾过程组 3.什么是项目: 为了创造一个唯一的产品或者...

    可以直接进入的github上面下载试卷,课后答案,以及对应的笔记总结,点击进入

    第一章.软件项目管理概述

    1.实现项目目标的制约因素有:

    • 项目范围
    • 成本
    • 进度计划
    • 客户满意度

    2.项目管理包括:

    • 启动过程组
    • 计划过程组
    • 执行过程组
    • 控制过程组
    • 收尾过程组

    3.什么是项目:

    为了创造一个唯一的产品或者提供一个唯一的服务而进行的临时性的努力,所以说项目具有临时性特性

    4.过程管理就是对过程进行管理,目的是要让过程能够被共享,复用,并得到持续的改进

    5.项目与日常运作的区别与共同点:

    项目 日常运作
    以目标为导项 通过效率和有效性的体现
    通过项目经理及其团队工作完成的 职能式的线性管理
    项目是一次性的 日常运作可以重复进行

    共同点:

    都需要人来做;而且都受资源限制;都需要规划,执行,控制

    6.项目的特征:项目均是有时间范围的,所以最能表现项目特征的是确定期限

    7.请简述项目管理的 5 个过程组及其关系

    (1)启动过程组:主要是确定一个项目或一个阶段可以开始了,并要求着手实行;定义
    和授权项目或者项目的某个阶段。 (2)计划过程组: 为完成项目所要达到的商业要求而进行
    的实际可行的工作计划的设计、 维护, 确保实现项目的既定商业目标。 计划基准是后面跟踪
    和监控的基础。 (3)执行过程组:根据前面制定的基准计划,协调人力和其他资源,去执行
    项目管理计划或相关子计划。 (4)控制过程组: 通过监控和检测过程确保项目达到目标, 必
    要时采取一些修正措施。 集成变更控制是一个重要的过程。 (5)收尾过程组: 取得项目或阶
    段的正式认可并且有序地结束该项目或阶段。 向客户提交相关产品, 发布相关结束报告, 并
    且更新组织过程资产并释放资源。
    关系:各个过程组通过其结果进行连接,一个过程组的结果或输出是另一个过程组的输入。
    其中,计划过程组、执行过程组、控制过程组是核心管理过程组。

    8.项目的特征是什么

    目标性、相关性、临时性、独特性、资源约束性、不确定性

    第二章.项目确立

    1.项目立项之后,项目负责人会进行自造购买决策,确立待开发产品的哪些部分的应该采购,外包开发,自主研发等

    2,项目经理的主要职责是:

    • 开发计划
    • 组织实施
    • 项目控制

    3.在(立项)阶段,应该明确项目的目标、时间表、使用的资源和经费,而且得到项目发起人的认可。注意:项目立项是需求方(甲方)提出的需求

    4.项目招标阶段

    • 甲方过程:

    (招标书定义) 、(供方选择)、(合同签署)

    • 乙方过程:

    (项目分析) 、(竞标)、(合同签署)
    总而言之:甲方:客户(上帝),乙方:软件开发方

    5.项目建议书是项目立项阶段(项目的初始阶段)开发的文档

    6.甲方(顾客,需求方)招标阶段的任务是:

    • 招标书定义
    • 供方选择
    • 合同签署

    7.某公司希望开发一套软件产品, 如果选择自己开发软件的策略, 公司需要花费 30000 元,根据历史信息,维护这个软件每个月需要 3500 元。如果选择购买软件公司产品的策略,需要 18000 元,同时软件公司为每个安装的软件进行维护的费用是 4200 元/月。该公司该如何决策?

    自制方案:
    制造费 30000 元 维护费 3500 元/月
    购买方案:
    购买费 18000 元 维护费 4200 元/月
    制造差额: 30000-18000=12000 元
    服务差额: 4200-3500=700 元
    自制方案承受月份: 12000/700=17.14
    如果产品在 17 个月以内可以选择购买方案,如果超过 17 个月选择自造方案。

    8.什么是项目章程?

    项目章程是项目执行组织高层批准的一份以书面签署的确认项目存在的文件, 包括对项
    目的确认、对项目经理的授权和项目目标的概述等。

    9.招标书主要包括那几部分内容?

    招标书主要包括三部分内容:技术说明、 商务说明和投标说明。技术说明主要对采购的
    产品或者委托的项目进行详细的描述, 商务说明主要包括合同条款。 投标说明主要是对项目
    背景、标书的提交格式、内容、提交时间等做出规定。

    第三章.生存期模型

    1.瀑布模型 生存期模型中, 要求项目所有的活动都严格按照顺序进行,一个阶段的输入是下一个阶段的输入。

    2.敏捷开发通过迭代和快速用户反馈应对管理的不确定性和变更

    3,每日站立会议是(Scrum)模型敏捷开发实践

    4.瀑布模型适合短期项目

    5.增量式模型可以避免一次性投资太多带来的风险

    6.各个模型的优缺点:

    模型 特点 缺点 使用范围
    瀑布模型 线性,阶段计划分明,以项目的阶段评审和文档控制为手段有效的对整个开发过程进行指导 缺乏灵活性,无法解决需求不明确或者不准确的情况;(2)由于开发是线性的,只有到末期才能见到开发成果,增加了开发的风险;(3)早期的错误到后期才能发现 适用于需求明确,解决方案明确的项目
    V模型 纠正了人民不重视测试阶段的重要性的错误认识,将测试分等级,并且和前面的开发阶段对应 仍然将测试作为一个独立的阶段,并没有提高抗风险能力 与瀑布模型类似
    快速原型模型 有助于增进软件人员和用户对系统服务需求的理解 文档容易被忽略,建立原型的许多工作会被浪费掉,项目难以规划和管理 适用于需求不明确,动态变化的项目
    增量模型 增强了客户使用的信心,逐步提出对后续增量的需求;增量由高到低的优先级确定保障了系统重要功能部分的可靠性;项目总体失败的风险比较低 增量粒度选择问题,确定所有的基本服务比较苦难 适用于需求大部分明确,系统较为复杂,有一定的技术风险

    渐进式模型:

    • 缺点:需要精心规划各个阶段目标,每个阶段提交的是正式版本,所以工作量会增加
    • 使用范围:主要适用于中型或者大型项目,是目前开发中最常用的开发模型
      敏捷生存模型:通过迭代和快速的用户反馈管理不确定性和应对变更
      敏捷开发宣言:

    个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;相应变化胜过遵循计划
    适用于需求不明确的情况下采用

    7.三种你熟悉的生存期模型,并说明这些模型适用于什么情况下的项目

    (1)瀑布模型
    适用于软件需求很明确的软件项目, 即一般适用于功能明确、 完成、 无重大变化的软件系统
    的开发,即:
    1) 在项目开始前,项目的需求已经被很好的理解、也很明确,而且项目经理很熟悉为实现
    这一模型所需要的过程。
    2) 解决方案在项目开始前也很明确。
    3) 短期项目可采用瀑布模型。
    (2)V 模型
    适用于项目需求在项目开始前很明确、解决方案在项目开始前也很明确,项目对系统的
    安全很严格,如航天飞机控制系统、公司的财务系统等。
    (3)快速原型模型
    适用于项目的需求在项目开始前不明确,需要减少项目的不确定性的时候。

    第四章 软件项目范围计划——需求管理

    1.需求管理包括:

    • 需求获取
    • 需求分析
    • 需求规格编写
    • 需求验证
    • 需求变更

    2.原型分析方法 是其中一种需求建模方法。

    3.结构化分析方法是一种自下而上逐步求精的分析方法

    4.软件项目管理需求过程:

    • 需求获取
    • 需求分析
    • 需求规格编写

    5.数据字典组成部分:

    • 数据项
    • 数据流
    • 数据文件

    6.下列不属于 UML 需求视图的是?

    甘特图(甘特图用于做计划的视图)
    属于需求的视图的是:用例图,状态图,顺序图

    7.属于需求建模的方法:

    • 原型方法
    • 面向对象的用例分析方法
    • 功能列表方法

    8.(需求变更)软件项目的一个突出特点,可以导致软件项目的蔓延

    9.结构化方法设计有:

    • 数据流图
    • 数据字典
    • 系统流程图

    10.我们常常从哪些方面着手处理需求不明确的问题?

    (1)让用户参与开发
    (2)开发用户界面原型
    (3)需求讨论会议
    (4)强化需求分析和评审

    第五章 软件项目范围规划——任务分解

    1.任务分解是将一个项目分解为更多的工作细目或者 子项目 ,是项目变得更小、更易管理、更易操作

    2.一般来说,进行项目分解时,可以采用 清单 或图表 两种形式来表达任务分解的结果。

    3.WBS的全称是 任务分解结构 :Work Breakdown Structure。

    4.WBS最底层次可交付成果是 :工作包 work package。

    5.WBS提供了项目范围基线

    6. 一个工作包可以分配给另一个项目经理去完成。(注:工作包应当由唯一主体负责,可以分配给另外一位项目经理通过子项目的方式完成。)

    7.对于一个没有做过的项目,开发 WBS时可以采用自底向上方法。

    8. 在任务分解结果中,最底层的要素必须是实现项目目标的充分必要条件。

    9.任务分解是将一个项目分解为更多的工作细目或者子项目, 使项目变得更小、 更易管理和操作。

    10.一个工作包应当由唯一主体负责。

    11.WBS的最底层任务是能分配到一个人完成的任务。

    12…WBS非常重要,因为:

    帮助组织工作,防止遗漏工作,为项目估算提供依据 但是不包括确定团队成员责任

    13.WBS中的每一个具体细目通常都指定唯一的编码

    14.创建 WBS的方法有:

    自顶向下 ,自底向上 ,模板参照,不包括控制方法

    15.任务分解时,

    (自底向上)方法从特殊到一般的方向进行,首先定义一些特殊的任务,然后将这些任务组织起来,形成更高级别的 WBS层。
    (自顶向下)方法从一般到特殊的方向进行,从项目的大局着手,然后逐步分解子细目,将项目变为更细、更完善的部分

    16.WBS的定义:

    (1)WBS是任务分解的结果;(2)不包括再 WBS中的任务就不是该项目的工作;(3)可以采用清单或者图表的形式标识WBS的结果

    17.检验 WBS分解结果的标准:

    • 最底层的要素是否是实现目标的充分必要条件
    • 最底层元素是否有重复
    • 最底层要素是否有清晰完整定义

    18.WBS是对项目由粗到细的分解过程,它的结构是:分级的树形结构

    19.任务分解的方法和步骤

    任务分解的基本步骤:

    • 确认并分解项目的组成要素 (WBS编号 ) 。
    • 确定分解标准,按照项目实施管理的方法分解,而且分解的标准要统一。
    • 确认分解是否详细,是否可以作为费用和时间估计的标准,明确责任。
    • 确定项目交付成果(可以编制 WBS字典)。
    • 验证分解正确性。验证分解正确后,建立一套编号系统。

    任务分解方法:

    • 模板参照方法
    • 类比方法
    • 自上而下
    • 自下而上

    20.当项目过于复杂是,可以对项目进行任务分解,这样做的好处是什么?

    将一个项目分解为更多的工作细目或者子项目, 使项目变得更小、 更易管理、 更易操作,这样可以提高估算成本、时间和资源的准确性,使工作变得更易操作,责任分工更加明确。

    21.检验任务分解结果的标准是什么?

    检验任务分解结果的标准有:

    • 最底层的要素是否是实现目标的充分必要条件
    • 最底层要素是否有重复的
    • 每个要素是否清晰完整定义
    • 最底层要素是否有定义清晰的责任人
    • 是否可以进行成本估算和进度安排

    第六章 项目成本计划

    1.软件项目成本包括直接成本和间接成本,一般而言,项目人力成本归属于直接成本。

    2.再在项目初期,一般采用的成本估算方法是类比估算法。

    3.功能点方法中 5 类功能组件的计数项是外部输入、外部输出、外部查询、内部逻辑文件、外部接口文件。

    4.软件项目的主要成本是人的劳动的消耗所需要的代价。

    5.用例点方法通过分析用例角色、场景和技术与环境因子等来进行软件估算

    6.人的劳动消耗所付出的代价是软件产品的主要成本。

    7.估算时既要考虑直接成本又要考虑间接成本。

    8.(规模)是成本的主要因素,是成本估算的基础

    9.常见的成本估算方法:

    代码行,功能点,类比法;记住不包括关键路径法

    10.UFC的功能计数项:

    UFC:未调整功能点计数
    包括:外部输出,外部文件,内部文件

    11.成本预算的目的是:产生成本基线

    12.估算的基本方法包括:

    1)代码行,功能点;2)参数估算法;3)专家估算法;记住不包括函数估算法

    13.在项目初期,进行竞标合同时,一般采用的成本估算方法是类比估算法

    14.软件项目规模单位有:

    • 代码长度(LOC)
    • 功能点(FP)
    • 人天,人月,人年
      不包括小时

    15.在成本管理过程中,每个时间段中等各个工作单元的成本是(预算)

    16.项目经理正在进行一个图书馆信息查询系统的项目估算,他采用 Delphi 的专家估算方法,邀请了 3 位专家进行估算, 第一位专家给出了 2 万元、 7 万元、 12 万元的估算值, 第二位专家给出了 4 万元、 6 万元、 8 万元的估算值,第三位专家给出了 2 万元、 6 万元、 10 万元的估算值,试计算这个项目的成本估算值

    专家一: Ei=(ai+4mi+bi)/6= (2+47+12)/6=7
    专家二: Ei=(ai+4mi+bi)/6=(4+4
    6+8)/6=6
    专家三: Ei=(ai+4mi+bi)/6= (2+4*6+10 )/6=6
    Ei=(7+6+6)/3=6.33 (万元)

    17.如果某软件公司正在进行一个项目,预计有 50KLOC的代码量,项目是中等规模的半嵌入型的项目,采用中等 COCOMO模型,项目属性中只有可靠性为很高级别(即取值为 1.3),其他属性为正常 (书上说, 正常就是 1),计算项目是多少人月的规模, 如果是 2 万元 /人月,则项目的费用是多少?

    Effort=a* (KLOC)b F
    查表 a=3,b=1.12,F=1
    Effort=3.0
    50
    1.12 1.31=311.82 (人月)
    所以项目的费用为 2* Effort=623.64 万元

    18.已知某项目使用 C语言完成,该项目共有 85 个功能点,请用 IBM 模型估算源代码行数、工作量项目持续时间、人员需要量以及文档数量。

    C 语言代码行与功能点的关系近似为 150LOC/FP,所以, 85 个功能点代码行数为
    L=85150=12750 行=12.75KLOC,则:工作量估算 E=(5.2L)的0.91次方 =(5.212.75)的0.91次方≈52.725(人月)
    项目时间 D=(4.1
    L)的0.36次方 =(4.112.75)的 0.36次方 ≈10.25(月)
    人员需求量 S=(0.54
    E)的 0.6次方 =0.5452.725的0.6次方 ≈5.829(人)
    文档数量 DOC=49
    L 的1.01次方 =49*12.75的1.01次方≈640.857(页)

    第七章软件项目进度计划

    1.关键路径 决定了项目在给定的金钱关系和资源条件下完成项目所需的最短时间

    2.时间 是一种特殊的资源,以其单向性、不可重复性、不可替代性而有别于其他资源,是项目计划中灵活性最小的因素 。

    3.在 ADM 网络图中,箭线表示 活动(任务),结点表示前一个任务的结束,同时表示后一个任务的开始 。

    4.应急法 和平行作业法 都是时间压缩法。

    5.任务(活动) 之间的排序依据主要有 强制性依赖关系、 软逻辑关系、 外部依赖关系 等。

    6.工程评估评审技术采用加权平均的公式是 PERT历时 =(O+P+4M)/6 ,其中 O 是乐观值, P是悲观值, M 是最可能值。

    7.一个工作也可以通过多个活动完成。

    8.在项目进行过程中,关键路径是可变的

    9.在 PDM 网络图中,箭线表示的是任务之间的逻辑关系,节点表示的是活动。

    10.在资源冲突问题中,过度分配也属于资源冲突。

    11.浮动是在不增加项目成本的条件下,一个活动可以延迟的时间量

    12.在使用应急法压缩时间时,要在关键路径上选择活动来进行压缩,因为能够压缩的都是关键路径。

    13.时间是项目规划中灵活性最小的因素。

    14.常用的公式:

    • EF(最早完成时间)=ES(最早开始时间)+duration(任务的历时时间)
    • LS(最晚开始时间)=LF(最晚完成时间)-duration(任务的历时时间)
    • TF(总浮动:在不影响项目最早完成时间)=LS(最晚开始时间)-ES(最早开始时间)=LF(最晚完成时间)-EF(最早完成时间)
    • FF(自由浮动:在不影响后置任务最早开始的时间)=ES(最早开始时间)-EF(最早完成时间)-lag(本任务与后置任务之间的之后时间)

    15.常见的依赖关系:

    • 强制性依赖关系
    • 软逻辑关系
    • 外部依赖关系
    • 里程碑

    16.(甘特图)可以显示任务的基本信息,使用该类图能方便的查看任务的工期、开始时间、结束时间以及资源的信息。

    17.(进度问题)是项目冲突的主要原因,尤其在项目后期。

    18.编制进度的基本方法:

    • 关键路径法
    • 时间压缩法
    • 资源平衡法
      注:系统图法不是

    19.快速跟进是指采用并行执行任务,加速项目进展

    20.(lag)将延长项目的进度

    21.(总浮动)可以决定进度的灵活性

    22.对一个任务进行进度估算时, A 是乐观者,估计用 6 天完成, B 是悲观者,估计用 24天完成, C是有经验者,认为最有可能用 12 天完成,那么这个任务的历时估算介于 10天到 16 天的概率是多少?

    E=(6+24+4*12)/6=13 , δ=(24-6)/6=3
    E-δ =10
    E+δ=16
    查表(p139)得任务历时估算介于 10—— 16 天的概率为: 68.3%

    23.请将下图所示的 PDM(优先图法)网络图改画为 ADM(箭线法)网络图。

    上图对应的 ADM 图如下所示:

    24.根据下面任务流程图和下表给出的项目历时估算值,采用 PERT方法估算,求出项目在14-57 天内完成的概率的近似值。


    标准差:δ=(P-O)/6;

    第八章软件项目质量计划

    1.(审计)是对过程或产品的一次独立质量评估。

    2.质量成本包括预防成本和(缺陷成本)。

    3.质量管理包括(软件质量计划) 、(软件质量保证) 、(软件质量控制)等过程。

    4.(软件质量)是软件满足明确说明或者隐含的需求的程度。

    4.McCall 质量模型关注的 3 个方面是(产品运行) 、(产品转移) 、(产品修改)。

    5.质量管理总是围绕着(质量保证)和(质量控制)过程两个方面进行。

    6.质量保证的主要活动是(项目执行过程审计)和(项目产品审计)

    7.质量是满足要求的程度 ,包括符合规定的要求和满足顾客隐含需求

    8. 软件质量是软件满足明确说明或者隐含的需求的程度。

    9.质量形成于产品或者服务的开发过程中, 而不是事后的检查 (测试) 把关等。

    10.质量计划可以确定质量保证人员的特殊汇报渠道。

    11.质量管理过程:

    • 质量计划
    • 质量保证
    • 质量控制

    12.项目质量管理的目标是满足(项目)的需要

    13.质量成本:

    • 预防成本(评估费用和评估费用)
    • 缺陷成本(内部费用和外部费用)

    14.软件质量模型:

    • Boehm 质量模型
    • McCall 质量模型
    • ISO/IEC 9216质量模型

    15.质量控制非常重要,但是进行质量控制也需要一定的成本, (使用抽样统计)可以降低质量控制的成本。

    16.McCall 质量模型包含:

    • 产品修改
    • 产品转移
    • 产品运行
    • 不包括产品特点

    17.质量计划中可以采用哪些方法?

    质量计划中可以采用以下几种方法:
    (1)试验设计:试验设计是一种统计学方法,确定哪些因素可能会对特定变量产生影响。
    (2)基准对照:是一种寻找最佳实践的方法,是利用其他项目的实施情况作为当前项目性能衡量的标准。
    (3)质量成本分析:质量计划必须进行质量成本的综合分析,以便决定质量活动。
    (4)流程图方法:可以显示系统的各种成分是相互的关系,帮助我们预测在何处可能发生何种质量问题。
    (5)因果分析图:也称鱼刺图。描述相关的各种原因和子原因如何产生潜在问题或影响,将影响质量问题的 “人员、 设备、参考资料、 方法、环境”等各方面的原因进行细致的分解,方便地在质量计划中制定相应的预防措施。

    18. 简述质量保证的主要活动,以及质量保证的要点。

    质量保证的主要活动是项目执行过程审计和项目产品审计。
    质量保证的要点是:对项目进行评价、推测能否达到质量指标、建立对项目的信心

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

    质量保证( QA)是通过评价项目整体绩效 ,建立对质量要求的信任,提供项目和产品可
    视化的管理报告。 这个任务本身并不能提高产品的质量, 但是通过质量保证的一系列工作可
    以间接地提高产品的质量。质量保证一般由质量保证部门人员实施。
    质量控制( QC)是确定项目结果与质量标准是否相符 ,同时 ,确定消除不符的原因和方法,它
    控制产品的质量,及时纠正缺陷。这个任务本身提高产品的质量,一般由开发人员实施。
    质量保证是后期质量活动,质量控制是前期质量活动。它们是有区别的 :质质量保证是针对
    项目实施过程的管理手段,质量控制是针对项目产品的技术手段 ;实施质量保证是针对过程
    改进和审计的, 强调的是过程改进和信心保证。 实施质量控制是按照质量要求, 检查具体可
    交付成果的质量,强调的是具体的可交付成果。

    第九章软件配置管理计划

    1. 配置管理最终保证软件产品的(完整性) 、(一致性)、(追溯性)、(可控性)。

    2.(完整性和可跟踪性)是软件配置管理的核心功能。

    3.(基线)标志开发过程中一个阶段的结束和里程碑。

    4. 基线变更控制包括(变更请求) 、(变更控制) 、(变更批准 /拒绝)、(变更实现)等步骤。

    5.(版本管理) 、(变更管理)是配置管理的主要功能。

    6. 基线变更时,需要经过( SCCB)授权。

    7. SCCB的全称是(软件配置控制委员会) 。

    8.基线提供了软件生存期中各个开发阶段的一个特定点(记住是各个开发阶段,不是单独的某一个开发阶段)

    9.一个(些)配置项形成并通过审核,即形成基线。

    10.变更控制系统包括从项目变更申请、 变更评估、 变更审批到变更实施的文档化流程。

    11. 基线修改应受到控制,而且一定要经 SCCB授权。

    12.基线产品是可以修改的

    13.基线的修改需要每次都按照正式的程序执行。

    14. 软件配置项是项目需定义其受控于软件配置管理的款项, 每个项目的配置项不一定是相同的。

    15.SCCB的职责:

    • 评估变更
    • 与项目管理层沟通
    • 对变更进行反馈
    • 注意:提出变更申请不是sccb的职责

    16.为了更好地管理变更, 需要定义项目基线, 关于基线:

    可以变化,但是必须通过基线变更控制流程处理

    17.软件配置管理可以确保软件产品完整性,一致性,可控性,但是无法确保产品的正确性

    18.变更控制需要关注的是:标识变更,提出变更,管理变更

    19.配置管理的基本过程:

    (1)配置项标识、跟踪; ( 2)配置管理环境建立; (3)基线变更管理; (4)配置管理审
    计;(5)配置状态统计; ( 6)配置管理计划。

    20.软件配置控制委员会( SCCB)的基本职责:

    评估变更、批准变更申请、在生存期内规范变更申请流程、对变更进行反馈、与项
    目管理层沟通。

    21.配置管理在软件 开发中的作用,并列举至少两种配置管理工具

    软件配置管理是软件项目管理的重要内容,也是保证软件质量的重要手段。它能
    够对软件开发过程进行有效管理和控制, 从而实现软件产品的完整性、 一致性、可控性,使
    产品极大程度地与用户需求相吻合。 它能够控制、 记录、追踪对软件的修改并形成规范文档,
    方便日后维护和升级,更重要的是能够保护代码资源,积累软件财富,提高软件重用率。
    配置管理工具有: Harvest、 Perforce、ClearCase、PVCS、CVS\SVN、 VSS

    22.写出几个常见的软件配置项

    软件项目计划、需求分析结果、软件需求规格说明书、设计规格说明书、源代码清
    单、厕所规格说明书、 测试计划、 测试用例与实验结果、 可执行程序、 用户手册、 维护文档。

    第十章软件项目人员与沟通计划

    1. 沟通管理的基本原则是及时性、准确性、完整性、可理解性。

    2.可以充分发挥部门资源优势集中的组织结构为职能型组织结构

    3. 沟通计划用于确定谁需要信息,需要什么信息,何时需要信息,以及如何将信息分发给他们。

    4. 组织结构的主要类型:

    • 职能型(适用于主要由一个部门完成的项目或技术比较成熟的项目组织结构,是目前最普遍的项目组织形式,它是一个标准的金字塔型组织形式)
    • 项目型(在这种组织结构中项目成员没有安全感)
    • 矩阵型(项目涉及多的领域和特性)

    5. 会议形式 沟通最有可能协助解决复杂的问题。

    6.当项目中有 20 个人时,沟通渠道最多有 190。

    公式:N(N-1)/2  其中N:表示人员总数
    

    7.项目干系人是项目计划的一部分。

    8.项目沟通的基本原则是及时性、准确性、完整性和可理解性

    9.在 IT 项目中,成功的最大威胁是沟通的失败

    10.责任分配矩阵是明确项目团队成员的角色与职责的有效工具

    11.对于紧急的信息, 应该通过口头的方式沟通; 对于重要的信息, 应采用书面的方式沟通

    12.人员计划描述项目的团队人员什么时候,以及如何加入和离开团队

    13.沟通计划包括确定谁需要信息, 需要什么信息, 何时需要信息, 以及如何接收信息等

    14.人员管理计划没有明确的具体体现形式, 作为项目计划的一部分, 其详细程度因项目而异

    15.项目经理花在沟通上的时间是 75%-90%

    16.干系人:

    • 影响项目决策的个人、群体或者组织
    • 影响项目活动的个人、群体或者组织
    • 影响项目结果的个人、群体或者组织
    • 注意只有这三种,并不是适应所有的项目人员

    17.编制沟通计划的基础是沟通需求分析

    18. 团队:

    • 是一定数量的个体成员的集合
    • 团队应注重个人发挥,应该将某项任务分工给擅长该技术的职员
    • 团队的目的是开发出高质量的产品
    • 团队包括自己组织的人、供应商、分包商,注意没有客户

    19.写出 5 种以上项目沟通方式

    沟通方式主要有书面沟通和口头沟通、 语言沟通和非语言沟通、 正式沟通和非正式沟通、
    单向沟通和双向沟通、网络沟通等

    20.矩阵型项目组织结构的优缺点是什么

    优点是: 1、专职的项目经理负责整个项目,以项目为中心,能迅速解决问题。在最短的时间内调配人才,组成一个团队,把不同职能的人才集中在一起。
    2、多个项目可以共享各个职能部门的资源。在矩阵管理中,人力资源得到了更有效的利用,减少了人员冗余。
    3、既有利于项目目标的实现,也有利于公司目标方针的贯彻
    4、项目成员的顾虑减少了,因为项目完成后,他们任然可以回到原来的职能部门,不用担心被解散,而且他们能有更多机会接触自己企业的不同部门。
    缺点是 1、容易引起职能经理和项目经理权利的冲突。
    2、资源共享可能引起项目之间的冲突
    3、项目成员有多位领导,即员工必须要接受双重领导,因此经常有焦虑与压力

    第十一章软件项目风险计划

    1.风险评估的方法包括

    • 定性风险分析
    • 定量风险分析。

    2.决策树分析是一种 形象化的图表分析 方法。

    3.项目风险的三要素是

    • 风险事件
    • 风险事件发生的概率
    • 风险造成的影响

    4.(回避)风险是指尽可能地规避可能发生的风险, 采取主动放弃或者拒绝使用导致风险的方案

    5.风险规划的主要策略(应对风险的常见策略)是:

    • 回避风险
    • 转移风险
    • 损失控制
    • 自留风险

    6.软件项目风险识别常采用 德尔菲方法、头脑风暴法、情景分析法、风险条目检查表、其他等方法。

    7.定量风险评估主要包括 访谈、盈亏平衡分析、决策树分析、模拟法、敏感性分析 等方法。

    8.风险管理的 4 个过程:

    • 风险识别
    • 风险评估
    • 风险规划
    • 风险控制

    9.风险的三要素:

    • 一个事件
    • 事件发生的概率
    • 事件的影响

    10.险评估方法:

    • 盈亏平衡分析
    • 模拟法
    • 决策树分析

    11.一个项目在进行规划的时候,碰到了一个风险问题,项目经理决定是否采用方案 A。如果采用方法 A 需要使用一个新的开发工具,而能够掌握这个工具的概率是 30%,通过使用这个工具可以获利 5 万元,如果采用方案 A 而不能掌握这个工具,将损失 1 万元。利用决策树分析技术说明这个项目经理是否应该采用这个方案 A?(绘制决策树)


    EMV:损益期望值
    公式:EMV=(outcome(回报)*成功概率-亏本 * 亏本概率)
    EMV=(50000 * 30%-10000 * 70%) =8000

    12.某企业在今年有甲乙两种产品方案可以选择,每种方案的状态、收益和概率如表 11-11 所示,绘制决策树时,判断哪种方案将有更大收益。


    第十二章软件项目合同计划

    1.买房风险最高的合同类型: FFP(固定总价合同)

    2.为执行项目而从项目团队外获取产品、服务或者成果的过程称为:采购

    3.合同双方当事人承担不同角色,这些角色包括:甲方、乙方

    4.软件外包的基本步骤:竞标邀请、评估候选乙方的综合能力、确定承包商

    5.如果 CPPC合同类型中成本百分比是 10%,估计成本是 10 万元,当实际成本是 20 万元是,合同金额应该为: 22 万元

    20+10% * 20=22万

    6.一个 CPFF合同类型,估计成本是 10 万元,固定费用是成本 1.5 万元,当成本提高至 20万元是,合同金额为: 21.5 万元

    20+1.5=21.5万

    7.合同类型有:

    • 成本补偿类合同(CPCC)
    • 固定价格类合同(FFP)
    • 单价类合同()
    • 成本加奖金( CPIF)合同
    • 成本加成本百分比(CPPC)
    • 固定成本加奖金(FPIF)

    8.招标书可以是合同计划的输出

    9.对于甲方来说,风险最高的是 CPCC合同类型,风险最低的是 FFP合同类型,乙方则相反

    10.某项目采用成本加奖金的成本补偿类合同,当预算成本为 20 万元,利润 4 万元,且奖励分配为 80/20 时,如果实际成本降至 16 万元,则项目总价为

    项目总价=成本+奖金(节约成本 * 20%)+利润=16+(节约成本=20-16=4)4 * 20%+4=20.8万

    11.合同是需要靠( 相关法律法规)约束的

    12.项目预计成本 10 万,成本百分比 20%,如实际成本 8 万,则合同金额:

    8+20%*8=9.6

    13.成本加奖金合同,激励比 80/20; 估计成本 12 万,利润 1 万。如实际成本 12 万,则合同金额为: 12+1=13 万;如实际成本为 11 万,则合同金额为

    11+1+(12-11)20%=12.2

    第十三章项目集成计划

    1.软件项目管理最终要的 4 个要素是:

    • 范围
    • 质量
    • 进度
    • 成本

    2.质量和成本成一定的正比关系,进度和成本成一定的反比关系,范围和成本成一定的正比关系

    3.为了加快项目进度,可以适当见减低过程中的质量标准

    4.项目集成管理包括:

    • 对计划的集成管理和项目跟踪控制的集成管理
    • 保证项目各要素协调
    • 在相互影响的项目目标和方案中做出权衡
    • 没有软件设计文档

    5.设成本 C 是范围 S、质量 Q、进度 T的一个函数 C=F(S,Q,T),在成本或时间不充足的情况下,可以通过减小范围或者( 降低质量)来解决。

    6.项目管理过程中的进度目标,成本目标,质量目标,范围目标等各个目标之间是(相互关联和制约的)

    7.软件项目管理要素:

    • 范围
    • 质量
    • 成本
    • 不包含交互

    8.项目集成计划的特点:

    • 综合性
    • 全局性
    • 内外兼顾性
    • 不包含针对性

    第十四章项目集成计划执行控制

    1.项目执行控制的基本步骤:

    1)建立计划标准; 2)观察项目的性能; 3)测量和分析结果; 4)采取必要措施; 5)做好计划修订工作,控制反馈。

    第十五章项目核心计划执行控制

    1.软件项目中的软件开发成本是总成本的主要部分。

    2.当 SV=BCWP-BSWS<0时,表示项目进度落后。

    3.代码评审由一组人对程序进行阅读、讨论和争议,它是质量控制过程。

    4.挣值分析法也称为已获取价值分析,是对项目的实施进度、成本状态进行绩效评估的有效方法。

    5.从质量控制图的控制上限和控制下线,可以知道接受的过程的偏差范围。

    6.范围控制的重点是避免需求的变更。

    7. 一个任务原计划 3 个人全职工作 2 周完成,而实际上只有 2 个人参与这个任务,到第二周末完成了任务的 50%,则 CPI=?

    CPI(成本效能指标)=BCWP(已经完成工作的成本预算)/ACWP(到目前为止花了多少钱) * 100%
    * CPI>1:低于预算 ;=1:按照计划进行;<1:超过预算

    8.记录反映当前项目状态的项目性能数据是控制项目的基础。

    9. 项目进度成本控制的基本目标是在给定的限制条件下,用最短时间、最小成本、以最小风险完成项目工作。

    10.代码走查是在代码编写阶段,开发人员自己检查自己的代码。

    11. 在使用应急法压缩进度时,能够进行压缩的只有关键路径。

    12. 累计费用曲线中某时间点 ACWP(到目前为止花了多少钱)比 BCWS(到目前为止本应该完成的工作是多少)高,意味着在这个时间点为止,实际的成本要比计划的高,二者之间的差值就是成本差异。

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

    14. 项目原来预计于 2014.5.23 完成 1000 元的工作,但到 2014.5.23 只完成 850 元工作,而为了这些工作花费 900 元,则成本偏差和进度偏差分别是

    SV(进度差异)=BCWP(到目前为止实现了多少价值)-BCWS(到目前为止应该完成多少)
    所以SV=850-1000=-150
    CV(费用差异)=BCWP(到目前为止实现了多少价值)-ACWP(到目前为止花了多少钱)
    所以CV=900-850=50

    15.如果成本效能指标 CPI=90%,他说明投入 1 元产生 0.9 元的效果

    16.进度控制重要的一个组成部分是确定进度偏差是否需要采取纠正措施

    17.资源平衡最好用于(非关键路径)活动

    18.当项目进展到(20%)左右时, CPI处于稳定

    19.抽样统计的方法中,以小批量的抽样为基准进行检验

    20.质量控制的3 个要点:

    • 检查项目结果
    • 依据相关质量标准进行跟踪检查
    • 确定消灭质量问题的措施

    21.某项目由 1、2、3、4 四个任务构成,该项目目前执行到第 6 周末,各项工作在其工期内的每周计划成本、每周实际成本和计划工作量完成情况下表所示:

    1.根据提供的信息,计算截至第 6 周末该项目的 BCWS、ACWP、BCWP

    BCWS=10+15+5+10+10+10+20+10+10+5+5=100;
    ACWP=10+16+8+10+10+12+24+12+5+5=112
    BCWP=10+15+5+(10+10+10+20+10+10)/2+(5+5+25+5)/2=95

    2.计算第 6 周末的成本偏差 CV、进度偏差 SV,说明结果的实际意义

    CV=BCWP-ACWP= -17
    SV=BCWP-BCWS= -5

    3.照目前情况,计算完成整个项目实际需要投入多少资金?写出计算公式。

    CPI=BCWP/ACWP=84%
    EAC=BAC/CPI=170/84% = 202

    22.某项目正在进行中,下表是项目当前运行状况的数据,任务 1、2、3、4、5、6 计划是按顺序执行的,表中也给出了计划完成时间和实际的执行情况。

    1.计算 BAC

    BAC=5+25+120+40+60+80=330

    2.计算截至 2014 年 4 月 1 日的 BCWP、BCWS、 ACWP、 SV、SPI 、 CV、CPI等指标。

    BCWP=5+25+40=70
    BCWS=10+20=30
    ACWP=10+20+50=80
    SV=BCWP-BCWS=40
    SPI=BCWP/BCWS=175%
    CV=BCWP-ACWP=-10
    CPI=BCWP/ACWP=87.5%

    23.试述 Pareto 规则

    80%的问题是由 20%的原因引起。

    第十六章项目辅助计划执行控制

    1.项目周例会是一种正式沟通方式。

    2.在马斯洛的需求层次理论中,最高层需求是自我实现。

    3. Y理论属于参与理论

    4.风险管理是连续的过程。

    5.管理干系人参与和控制干系人参与都是干系人管理的任务。

    6.敏捷生存期模型中的每天站立会议是很有效的一种沟通方式。

    7.对于冲突而言,冲突常常是有利的事情

    8.项目培训特点:

    • 时间短
    • 针对性强
    • 见效快

    9.冲突解决方法:

    • 解决问题( confrontationorproblemsolving )
    • 妥协( compromise )
    • 强迫方式( forcingmode )
    • 撤退( withdrowal )

    10.项目中的小组成员要同时离开公司,项目经理首先应该( 实施风险计划 )。

    11.一个软件项目团队中一般有哪些人员角色?

    项目经理、架构分析师、系统分析师、 DBA、程序开发人员、测试人员、系统工程师、
    质量管理人员

    十七章 项目结束过程

    1.项目目标已经成功实现,可交付成果已经出现;或者项目无法继续进行,这时项目可以 终止 了。

    2.项目结束过程包括

    • 制定结束计划
    • 完成收尾工作
    • 项目最后评审。

    3.是否在预算成本内完成项目、是否实现目标、是否达到项目客户的期望等都是检验项目成功与失败的标准。

    4. 项目验收过程是甲方对乙方交付的产品或服务进行验收检验,以保证它满足合同条款的要求。

    5. 项目计划中确定的可交付成果已经出现, 项目的目标已经成功实现时, 可终止项目。

    6.一个项目的交付验收,意味着项目的结束

    7.当一个项目的目标已经实现,或者明确看到目标已经不可能实现时,项目就应该终止。

    8. 客户接受项目的交付结果之前,项目经理应该检查交付结果的质量

    9.不包括在项目验收过程中的是 项目总结

    10.项目终止的条件:

    • 项目计划中确定的可交付成果已经出现,项目的目标已经成功实现
    • 项目已经不具备实用价值
    • 项目由于各种原因而导致无限期拖长
    • 不包括项目需求发生了变化

    11.项目成功与失败的标准是:

    • 是否实现目标
    • 可交付成功如何
    • 是否达到项目客户的期望
    • 不包括项目人数庞大

    12. 在项目的末期,与卖方的合同还有尚未解决的索赔,项目经理(进行合同收尾,合同收尾之后,可能采取法律行动)。

    展开全文
  • 研发项目管理软件对比调研报告

    千次阅读 2015-05-26 11:54:32
    报告说明:根据前段时间自己的调研,和公司的使用情况,做了个简单的比较。...希望这个报告能给正在寻找项目管理软件的你带来一些帮助。 在线体验账号: 统御项目管理软件oKit:http://www.kingre

    报告说明:根据前段时间自己的调研,和公司的使用情况,做了个简单的比较。以下完全是个人使用后的心得体会,也可能有使用不全面的地方,说的不对还请指正。


    从使用情况来说,个人还是比较偏向统御项目管理软件oKit,因为公司团队已经决定部署这套软件了。希望这个报告能给正在寻找项目管理软件的你带来一些帮助。


    在线体验账号:

    统御项目管理软件oKit:http://www.kingrein.com/pms/logout.action  (用户名、密码在页面上有提示)

    QC系统:http://192.168.1.122/qcbin/start_a.htm   用户名:test  密码:123456

    JIRA系统:http://192.168.1.122:8888/secure/Dashboard.jspa   用户名:test  密码:123456


    统御项目管理oKit,评分(27)

     

    多项目管理

    需求管理

    版本化管理

    测试支持

    支持自定义项目目录,可以创建多级子项目,支持复制项目基本信息和设置角色模板(2)

    提供需求管理模块,支持需求版本化、层次化、条目化管理,可以关联需求到相应的产品版本,并支持建立需求跟踪矩阵(3)

    有版本控制、版本发布功能(一个项目内可包括多个产品、多个版本)(3)

    提供了缺陷管理和测试管理模块,测试管理可以创建测试用例库,发布测试活动和测试阶段,并记录测试结果,缺陷管理支持自定义流程,比较全面,基本满足目前的使用习惯(2)

    工时统计

    任务燃尽图

    SVN集成

    电子邮件

    有工时统计分析(3)

    支持自定义需要监控的父级任务,查看任务的整体进展情况。(3)

    自带配置管理功能,支持界面操作,输入SVN地址和密码即可集成,操作简单。(3)

    无需安装任何插件,自带内部邮件。也可以配置外部接收邮箱地址。(3)

    工作流

    报告功能

    支持自定义需求和缺陷工作流模板。(2)

    强大的定期报告能力,还配有项目简报和其他模块的报告输出,报表支持自定义样式,支持输出到word和EXCEL,报告做的比较成熟。(3)

     

    总结:

    1.      简单、比较容易上手,团队协同办公很方便,之前公司研发部门一直在用这套软件。

    2.      测试、开发和整个流程时间的管理可以串联起来

    3.      提供永久免费版本,安装方便;版本升级较容易。                

    4.      提供了即时通讯工具叮咚,这个工具和oKit进行了无缝结合,团队用起来非常方便,确实加强了沟通,提高了效率。

    5.      虽然提供了需求和缺陷的工作流模板,但不是专业的工作流,扩展性不强。

    6.      4.0免费版本开发了全部的功能模块,值得表扬,可惜限制了人数和项目数量,不过小团队可以接受。

     

     

    JIRA系统,评分(19)


    多项目管理

    需求管理

    版本化管理

    测试支持

    将一个项目可以分若干task,再将task分解sub-task(2)

    没有集中的需求模块,位置较松散(2)

    新建多个项目,对应不同的版本(2)

    测试功能对比禅道稍弱,问题指派功能不好用(1)

    工时统计

    任务燃尽图

    SVN集成

    电子邮件

    无工时概念(0)

    有,但不支持自定义(2)

    安装svn插件(2)

    安装邮件插件(2)

    工作流

    报告功能

    有清晰的工作流信息,并可以自定义工作流模板(3)

    有XML和word版本报告(3)


    总结:

    1.      项目管理的风格不是简单易懂;

    2.      距离实际的使用需求有一定的差异

    3.      收费软件,免费的license有人员数量的限制


     

    QC系统,评分(15)

     

    多项目管理

    需求管理

    版本化管理

    测试支持

    项目、子项目管理比较清晰,设置不同用户的不同权限,具有不同项目的权限(3)

    专门的需求模块(3)

    需要admin账户创建多个项目(每个项目只能表示一个产品一个版本,后期版本发布比较繁琐)(1)

    测试功能最全面,包括测试用例编写、用例执行结果、用例覆盖率等。功能较详细,对应测试的人力投入量较大(3)

    工时统计

    任务燃尽图

    SVN集成

    电子邮件

    无工时概念(0)

    无此概念(0)

    多与vss集成,与svn集成较困难(1)

    系统自带,需手动发送邮件(1)

    工作流

    报告功能

    无工作流概念(0)

    有报告功能。测试方面的报告很全面(3)

     

     

    总结:

    1.      测试管理部分相当专业;

    2.      同时进行的多项目管理,可以为不同用户指派不同项目的权限,与本项目无关的用户不能查看项目信息;

    3.      没有整体项目预计工时的概念,无法整体管理项目;

    4.      不是正宗的项目管理软件,所以同时拿它既管项目又管缺陷很多概念和流程无法实现。



    其他软件还有待研究。


    展开全文
  • 软件项目管理笔记

    万次阅读 2020-05-13 09:51:18
    软件项目管理概述 1.实现项目目标的制约因素有: 项目范围 成本 进度计划 客户满意度 2.项目管理包括: 启动过程组 计划过程组 执行过程组 控制过程组 收尾过程组 3.什么是项目: 为了创造一个唯一的产品或者...

    第一章.软件项目管理概述

    1.实现项目目标的制约因素有:

    • 项目范围
    • 成本
    • 进度计划
    • 客户满意度

    2.项目管理包括:

    • 启动过程组
    • 计划过程组
    • 执行过程组
    • 控制过程组
    • 收尾过程组

    3.什么是项目:

    为了创造一个唯一的产品或者提供一个唯一的服务而进行的临时性的努力,所以说项目具有临时性特性

    4.过程管理就是对过程进行管理,目的是要让过程能够被共享,复用,并得到持续的改进

    5.项目与日常运作的区别与共同点:

    项目 日常运作
    以目标为导项 通过效率和有效性的体现
    通过项目经理及其团队工作完成的 职能式的线性管理
    项目是一次性的 日常运作可以重复进行

    共同点:

    都需要人来做;而且都受资源限制;都需要规划,执行,控制

    6.项目的特征:项目均是有时间范围的,所以最能表现项目特征的是确定期限

    7.请简述项目管理的 5 个过程组及其关系

    (1)启动过程组:主要是确定一个项目或一个阶段可以开始了,并要求着手实行;定义
    和授权项目或者项目的某个阶段。 (2)计划过程组: 为完成项目所要达到的商业要求而进行
    的实际可行的工作计划的设计、 维护, 确保实现项目的既定商业目标。 计划基准是后面跟踪
    和监控的基础。 (3)执行过程组:根据前面制定的基准计划,协调人力和其他资源,去执行
    项目管理计划或相关子计划。 (4)控制过程组: 通过监控和检测过程确保项目达到目标, 必
    要时采取一些修正措施。 集成变更控制是一个重要的过程。 (5)收尾过程组: 取得项目或阶
    段的正式认可并且有序地结束该项目或阶段。 向客户提交相关产品, 发布相关结束报告, 并
    且更新组织过程资产并释放资源。
    关系:各个过程组通过其结果进行连接,一个过程组的结果或输出是另一个过程组的输入。
    其中,计划过程组、执行过程组、控制过程组是核心管理过程组。

    8.项目的特征是什么

    目标性、相关性、临时性、独特性、资源约束性、不确定性

    第二章.项目确立

    1.项目立项之后,项目负责人会进行自造购买决策,确立待开发产品的哪些部分的应该采购,外包开发,自主研发等

    2,项目经理的主要职责是:

    • 开发计划
    • 组织实施
    • 项目控制

    3.在(立项)阶段,应该明确项目的目标、时间表、使用的资源和经费,而且得到项目发起人的认可。注意:项目立项是需求方(甲方)提出的需求

    4.项目招标阶段

    • 甲方过程:

    (招标书定义) 、(供方选择)、(合同签署)

    • 乙方过程:

    (项目分析) 、(竞标)、(合同签署)
    总而言之:甲方:客户(上帝),乙方:软件开发方

    5.项目建议书是项目立项阶段(项目的初始阶段)开发的文档

    6.甲方(顾客,需求方)招标阶段的任务是:

    • 招标书定义
    • 供方选择
    • 合同签署

    7.某公司希望开发一套软件产品, 如果选择自己开发软件的策略, 公司需要花费 30000 元,根据历史信息,维护这个软件每个月需要 3500 元。如果选择购买软件公司产品的策略,需要 18000 元,同时软件公司为每个安装的软件进行维护的费用是 4200 元/月。该公司该如何决策?

    自制方案:
    制造费 30000 元 维护费 3500 元/月
    购买方案:
    购买费 18000 元 维护费 4200 元/月
    制造差额: 30000-18000=12000 元
    服务差额: 4200-3500=700 元
    自制方案承受月份: 12000/700=17.14
    如果产品在 17 个月以内可以选择购买方案,如果超过 17 个月选择自造方案。

    8.什么是项目章程?

    项目章程是项目执行组织高层批准的一份以书面签署的确认项目存在的文件, 包括对项
    目的确认、对项目经理的授权和项目目标的概述等。

    9.招标书主要包括那几部分内容?

    招标书主要包括三部分内容:技术说明、 商务说明和投标说明。技术说明主要对采购的
    产品或者委托的项目进行详细的描述, 商务说明主要包括合同条款。 投标说明主要是对项目
    背景、标书的提交格式、内容、提交时间等做出规定。

    第三章.生存期模型

    1.瀑布模型 生存期模型中, 要求项目所有的活动都严格按照顺序进行,一个阶段的输入是下一个阶段的输入。

    2.敏捷开发通过迭代和快速用户反馈应对管理的不确定性和变更

    3,每日站立会议是(Scrum)模型敏捷开发实践

    4.瀑布模型适合短期项目

    5.增量式模型可以避免一次性投资太多带来的风险

    6.各个模型的优缺点:

    模型 特点 缺点 使用范围
    瀑布模型 线性,阶段计划分明,以项目的阶段评审和文档控制为手段有效的对整个开发过程进行指导 缺乏灵活性,无法解决需求不明确或者不准确的情况;(2)由于开发是线性的,只有到末期才能见到开发成果,增加了开发的风险;(3)早期的错误到后期才能发现 适用于需求明确,解决方案明确的项目
    V模型 纠正了人民不重视测试阶段的重要性的错误认识,将测试分等级,并且和前面的开发阶段对应 仍然将测试作为一个独立的阶段,并没有提高抗风险能力 与瀑布模型类似
    快速原型模型 有助于增进软件人员和用户对系统服务需求的理解 文档容易被忽略,建立原型的许多工作会被浪费掉,项目难以规划和管理 适用于需求不明确,动态变化的项目
    增量模型 增强了客户使用的信心,逐步提出对后续增量的需求;增量由高到低的优先级确定保障了系统重要功能部分的可靠性;项目总体失败的风险比较低 增量粒度选择问题,确定所有的基本服务比较苦难 适用于需求大部分明确,系统较为复杂,有一定的技术风险

    渐进式模型:

    • 缺点:需要精心规划各个阶段目标,每个阶段提交的是正式版本,所以工作量会增加
    • 使用范围:主要适用于中型或者大型项目,是目前开发中最常用的开发模型
      敏捷生存模型:通过迭代和快速的用户反馈管理不确定性和应对变更
      敏捷开发宣言:

    个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;相应变化胜过遵循计划
    适用于需求不明确的情况下采用

    7.三种你熟悉的生存期模型,并说明这些模型适用于什么情况下的项目

    (1)瀑布模型
    适用于软件需求很明确的软件项目, 即一般适用于功能明确、 完成、 无重大变化的软件系统
    的开发,即:
    1) 在项目开始前,项目的需求已经被很好的理解、也很明确,而且项目经理很熟悉为实现
    这一模型所需要的过程。
    2) 解决方案在项目开始前也很明确。
    3) 短期项目可采用瀑布模型。
    (2)V 模型
    适用于项目需求在项目开始前很明确、解决方案在项目开始前也很明确,项目对系统的
    安全很严格,如航天飞机控制系统、公司的财务系统等。
    (3)快速原型模型
    适用于项目的需求在项目开始前不明确,需要减少项目的不确定性的时候。

    第四章 软件项目范围计划——需求管理

    1.需求管理包括:

    • 需求获取
    • 需求分析
    • 需求规格编写
    • 需求验证
    • 需求变更

    2.原型分析方法 是其中一种需求建模方法。

    3.结构化分析方法是一种自下而上逐步求精的分析方法

    4.软件项目管理需求过程:

    • 需求获取
    • 需求分析
    • 需求规格编写

    5.数据字典组成部分:

    • 数据项
    • 数据流
    • 数据文件

    6.下列不属于 UML 需求视图的是?

    甘特图(甘特图用于做计划的视图)
    属于需求的视图的是:用例图,状态图,顺序图

    7.属于需求建模的方法:

    • 原型方法
    • 面向对象的用例分析方法
    • 功能列表方法

    8.(需求变更)软件项目的一个突出特点,可以导致软件项目的蔓延

    9.结构化方法设计有:

    • 数据流图
    • 数据字典
    • 系统流程图

    10.我们常常从哪些方面着手处理需求不明确的问题?

    (1)让用户参与开发
    (2)开发用户界面原型
    (3)需求讨论会议
    (4)强化需求分析和评审

    第五章 软件项目范围规划——任务分解

    1.任务分解是将一个项目分解为更多的工作细目或者 子项目 ,是项目变得更小、更易管理、更易操作

    2.一般来说,进行项目分解时,可以采用 清单 或图表 两种形式来表达任务分解的结果。

    3.WBS的全称是 任务分解结构 :Work Breakdown Structure。

    4.WBS最底层次可交付成果是 :工作包 work package。

    5.WBS提供了项目范围基线

    6. 一个工作包可以分配给另一个项目经理去完成。(注:工作包应当由唯一主体负责,可以分配给另外一位项目经理通过子项目的方式完成。)

    7.对于一个没有做过的项目,开发 WBS时可以采用自底向上方法。

    8. 在任务分解结果中,最底层的要素必须是实现项目目标的充分必要条件。

    9.任务分解是将一个项目分解为更多的工作细目或者子项目, 使项目变得更小、 更易管理和操作。

    10.一个工作包应当由唯一主体负责。

    11.WBS的最底层任务是能分配到一个人完成的任务。

    12…WBS非常重要,因为:

    帮助组织工作,防止遗漏工作,为项目估算提供依据 但是不包括确定团队成员责任

    13.WBS中的每一个具体细目通常都指定唯一的编码

    14.创建 WBS的方法有:

    自顶向下 ,自底向上 ,模板参照,不包括控制方法

    15.任务分解时,

    (自底向上)方法从特殊到一般的方向进行,首先定义一些特殊的任务,然后将这些任务组织起来,形成更高级别的 WBS层。
    (自顶向下)方法从一般到特殊的方向进行,从项目的大局着手,然后逐步分解子细目,将项目变为更细、更完善的部分

    16.WBS的定义:

    (1)WBS是任务分解的结果;(2)不包括再 WBS中的任务就不是该项目的工作;(3)可以采用清单或者图表的形式标识WBS的结果

    17.检验 WBS分解结果的标准:

    • 最底层的要素是否是实现目标的充分必要条件
    • 最底层元素是否有重复
    • 最底层要素是否有清晰完整定义

    18.WBS是对项目由粗到细的分解过程,它的结构是:分级的树形结构

    19.任务分解的方法和步骤

    任务分解的基本步骤:

    • 确认并分解项目的组成要素 (WBS编号 ) 。
    • 确定分解标准,按照项目实施管理的方法分解,而且分解的标准要统一。
    • 确认分解是否详细,是否可以作为费用和时间估计的标准,明确责任。
    • 确定项目交付成果(可以编制 WBS字典)。
    • 验证分解正确性。验证分解正确后,建立一套编号系统。

    任务分解方法:

    • 模板参照方法
    • 类比方法
    • 自上而下
    • 自下而上

    20.当项目过于复杂是,可以对项目进行任务分解,这样做的好处是什么?

    将一个项目分解为更多的工作细目或者子项目, 使项目变得更小、 更易管理、 更易操作,这样可以提高估算成本、时间和资源的准确性,使工作变得更易操作,责任分工更加明确。

    21.检验任务分解结果的标准是什么?

    检验任务分解结果的标准有:

    • 最底层的要素是否是实现目标的充分必要条件
    • 最底层要素是否有重复的
    • 每个要素是否清晰完整定义
    • 最底层要素是否有定义清晰的责任人
    • 是否可以进行成本估算和进度安排

    第六章 项目成本计划

    1.软件项目成本包括直接成本和间接成本,一般而言,项目人力成本归属于直接成本。

    2.再在项目初期,一般采用的成本估算方法是类比估算法。

    3.功能点方法中 5 类功能组件的计数项是外部输入、外部输出、外部查询、内部逻辑文件、外部接口文件。

    4.软件项目的主要成本是人的劳动的消耗所需要的代价。

    5.用例点方法通过分析用例角色、场景和技术与环境因子等来进行软件估算

    6.人的劳动消耗所付出的代价是软件产品的主要成本。

    7.估算时既要考虑直接成本又要考虑间接成本。

    8.(规模)是成本的主要因素,是成本估算的基础

    9.常见的成本估算方法:

    代码行,功能点,类比法;记住不包括关键路径法

    10.UFC的功能计数项:

    UFC:未调整功能点计数
    包括:外部输出,外部文件,内部文件

    11.成本预算的目的是:产生成本基线

    12.估算的基本方法包括:

    1)代码行,功能点;2)参数估算法;3)专家估算法;记住不包括函数估算法

    13.在项目初期,进行竞标合同时,一般采用的成本估算方法是类比估算法

    14.软件项目规模单位有:

    • 代码长度(LOC)
    • 功能点(FP)
    • 人天,人月,人年
      不包括小时

    15.在成本管理过程中,每个时间段中等各个工作单元的成本是(预算)

    16.项目经理正在进行一个图书馆信息查询系统的项目估算,他采用 Delphi 的专家估算方法,邀请了 3 位专家进行估算, 第一位专家给出了 2 万元、 7 万元、 12 万元的估算值, 第二位专家给出了 4 万元、 6 万元、 8 万元的估算值,第三位专家给出了 2 万元、 6 万元、 10 万元的估算值,试计算这个项目的成本估算值

    专家一: Ei=(ai+4mi+bi)/6= (2+47+12)/6=7
    专家二: Ei=(ai+4mi+bi)/6=(4+4
    6+8)/6=6
    专家三: Ei=(ai+4mi+bi)/6= (2+4*6+10 )/6=6
    Ei=(7+6+6)/3=6.33 (万元)

    17.如果某软件公司正在进行一个项目,预计有 50KLOC的代码量,项目是中等规模的半嵌入型的项目,采用中等 COCOMO模型,项目属性中只有可靠性为很高级别(即取值为 1.3),其他属性为正常 (书上说, 正常就是 1),计算项目是多少人月的规模, 如果是 2 万元 /人月,则项目的费用是多少?

    Effort=a* (KLOC)b F
    查表 a=3,b=1.12,F=1
    Effort=3.0
    50
    1.12 1.31=311.82 (人月)
    所以项目的费用为 2* Effort=623.64 万元

    18.已知某项目使用 C语言完成,该项目共有 85 个功能点,请用 IBM 模型估算源代码行数、工作量项目持续时间、人员需要量以及文档数量。

    C 语言代码行与功能点的关系近似为 150LOC/FP,所以, 85 个功能点代码行数为
    L=85150=12750 行=12.75KLOC,则:工作量估算 E=(5.2L)的0.91次方 =(5.212.75)的0.91次方≈52.725(人月)
    项目时间 D=(4.1
    L)的0.36次方 =(4.112.75)的 0.36次方 ≈10.25(月)
    人员需求量 S=(0.54
    E)的 0.6次方 =0.5452.725的0.6次方 ≈5.829(人)
    文档数量 DOC=49
    L 的1.01次方 =49*12.75的1.01次方≈640.857(页)

    第七章软件项目进度计划

    1.关键路径 决定了项目在给定的金钱关系和资源条件下完成项目所需的最短时间

    2.时间 是一种特殊的资源,以其单向性、不可重复性、不可替代性而有别于其他资源,是项目计划中灵活性最小的因素 。

    3.在 ADM 网络图中,箭线表示 活动(任务),结点表示前一个任务的结束,同时表示后一个任务的开始 。

    4.应急法 和平行作业法 都是时间压缩法。

    5.任务(活动) 之间的排序依据主要有 强制性依赖关系、 软逻辑关系、 外部依赖关系 等。

    6.工程评估评审技术采用加权平均的公式是 PERT历时 =(O+P+4M)/6 ,其中 O 是乐观值, P是悲观值, M 是最可能值。

    7.一个工作也可以通过多个活动完成。

    8.在项目进行过程中,关键路径是可变的

    9.在 PDM 网络图中,箭线表示的是任务之间的逻辑关系,节点表示的是活动。

    10.在资源冲突问题中,过度分配也属于资源冲突。

    11.浮动是在不增加项目成本的条件下,一个活动可以延迟的时间量

    12.在使用应急法压缩时间时,要在关键路径上选择活动来进行压缩,因为能够压缩的都是关键路径。

    13.时间是项目规划中灵活性最小的因素。

    14.常用的公式:

    • EF(最早完成时间)=ES(最早开始时间)+duration(任务的历时时间)
    • LS(最晚开始时间)=LF(最晚完成时间)-duration(任务的历时时间)
    • TF(总浮动:在不影响项目最早完成时间)=LS(最晚开始时间)-ES(最早开始时间)=LF(最晚完成时间)-EF(最早完成时间)
    • FF(自由浮动:在不影响后置任务最早开始的时间)=ES(最早开始时间)-EF(最早完成时间)-lag(本任务与后置任务之间的之后时间)

    15.常见的依赖关系:

    • 强制性依赖关系
    • 软逻辑关系
    • 外部依赖关系
    • 里程碑

    16.(甘特图)可以显示任务的基本信息,使用该类图能方便的查看任务的工期、开始时间、结束时间以及资源的信息。

    17.(进度问题)是项目冲突的主要原因,尤其在项目后期。

    18.编制进度的基本方法:

    • 关键路径法
    • 时间压缩法
    • 资源平衡法
      注:系统图法不是

    19.快速跟进是指采用并行执行任务,加速项目进展

    20.(lag)将延长项目的进度

    21.(总浮动)可以决定进度的灵活性

    22.对一个任务进行进度估算时, A 是乐观者,估计用 6 天完成, B 是悲观者,估计用 24天完成, C是有经验者,认为最有可能用 12 天完成,那么这个任务的历时估算介于 10天到 16 天的概率是多少?

    E=(6+24+4*12)/6=13 , δ=(24-6)/6=3
    E-δ =10
    E+δ=16
    查表(p139)得任务历时估算介于 10—— 16 天的概率为: 68.3%

    23.请将下图所示的 PDM(优先图法)网络图改画为 ADM(箭线法)网络图。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RbSNI3en-1589334555768)(1.png)]

    上图对应的 ADM 图如下所示:

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wJ2BirqS-1589334555770)(2.png)]

    24.根据下面任务流程图和下表给出的项目历时估算值,采用 PERT方法估算,求出项目在14-57 天内完成的概率的近似值。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Tpm3FGPR-1589334555772)(3.png)]
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-p2qjSfsr-1589334555774)(4.png)]

    标准差:δ=(P-O)/6;

    第八章软件项目质量计划

    1.(审计)是对过程或产品的一次独立质量评估。

    2.质量成本包括预防成本和(缺陷成本)。

    3.质量管理包括(软件质量计划) 、(软件质量保证) 、(软件质量控制)等过程。

    4.(软件质量)是软件满足明确说明或者隐含的需求的程度。

    4.McCall 质量模型关注的 3 个方面是(产品运行) 、(产品转移) 、(产品修改)。

    5.质量管理总是围绕着(质量保证)和(质量控制)过程两个方面进行。

    6.质量保证的主要活动是(项目执行过程审计)和(项目产品审计)

    7.质量是满足要求的程度 ,包括符合规定的要求和满足顾客隐含需求

    8. 软件质量是软件满足明确说明或者隐含的需求的程度。

    9.质量形成于产品或者服务的开发过程中, 而不是事后的检查 (测试) 把关等。

    10.质量计划可以确定质量保证人员的特殊汇报渠道。

    11.质量管理过程:

    • 质量计划
    • 质量保证
    • 质量控制

    12.项目质量管理的目标是满足(项目)的需要

    13.质量成本:

    • 预防成本(评估费用和评估费用)
    • 缺陷成本(内部费用和外部费用)

    14.软件质量模型:

    • Boehm 质量模型
    • McCall 质量模型
    • ISO/IEC 9216质量模型

    15.质量控制非常重要,但是进行质量控制也需要一定的成本, (使用抽样统计)可以降低质量控制的成本。

    16.McCall 质量模型包含:

    • 产品修改
    • 产品转移
    • 产品运行
    • 不包括产品特点

    17.质量计划中可以采用哪些方法?

    质量计划中可以采用以下几种方法:
    (1)试验设计:试验设计是一种统计学方法,确定哪些因素可能会对特定变量产生影响。
    (2)基准对照:是一种寻找最佳实践的方法,是利用其他项目的实施情况作为当前项目性能衡量的标准。
    (3)质量成本分析:质量计划必须进行质量成本的综合分析,以便决定质量活动。
    (4)流程图方法:可以显示系统的各种成分是相互的关系,帮助我们预测在何处可能发生何种质量问题。
    (5)因果分析图:也称鱼刺图。描述相关的各种原因和子原因如何产生潜在问题或影响,将影响质量问题的 “人员、 设备、参考资料、 方法、环境”等各方面的原因进行细致的分解,方便地在质量计划中制定相应的预防措施。

    18. 简述质量保证的主要活动,以及质量保证的要点。

    质量保证的主要活动是项目执行过程审计和项目产品审计。
    质量保证的要点是:对项目进行评价、推测能否达到质量指标、建立对项目的信心

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

    质量保证( QA)是通过评价项目整体绩效 ,建立对质量要求的信任,提供项目和产品可
    视化的管理报告。 这个任务本身并不能提高产品的质量, 但是通过质量保证的一系列工作可
    以间接地提高产品的质量。质量保证一般由质量保证部门人员实施。
    质量控制( QC)是确定项目结果与质量标准是否相符 ,同时 ,确定消除不符的原因和方法,它
    控制产品的质量,及时纠正缺陷。这个任务本身提高产品的质量,一般由开发人员实施。
    质量保证是后期质量活动,质量控制是前期质量活动。它们是有区别的 :质质量保证是针对
    项目实施过程的管理手段,质量控制是针对项目产品的技术手段 ;实施质量保证是针对过程
    改进和审计的, 强调的是过程改进和信心保证。 实施质量控制是按照质量要求, 检查具体可
    交付成果的质量,强调的是具体的可交付成果。

    第九章软件配置管理计划

    1. 配置管理最终保证软件产品的(完整性) 、(一致性)、(追溯性)、(可控性)。

    2.(完整性和可跟踪性)是软件配置管理的核心功能。

    3.(基线)标志开发过程中一个阶段的结束和里程碑。

    4. 基线变更控制包括(变更请求) 、(变更控制) 、(变更批准 /拒绝)、(变更实现)等步骤。

    5.(版本管理) 、(变更管理)是配置管理的主要功能。

    6. 基线变更时,需要经过( SCCB)授权。

    7. SCCB的全称是(软件配置控制委员会) 。

    8.基线提供了软件生存期中各个开发阶段的一个特定点(记住是各个开发阶段,不是单独的某一个开发阶段)

    9.一个(些)配置项形成并通过审核,即形成基线。

    10.变更控制系统包括从项目变更申请、 变更评估、 变更审批到变更实施的文档化流程。

    11. 基线修改应受到控制,而且一定要经 SCCB授权。

    12.基线产品是可以修改的

    13.基线的修改需要每次都按照正式的程序执行。

    14. 软件配置项是项目需定义其受控于软件配置管理的款项, 每个项目的配置项不一定是相同的。

    15.SCCB的职责:

    • 评估变更
    • 与项目管理层沟通
    • 对变更进行反馈
    • 注意:提出变更申请不是sccb的职责

    16.为了更好地管理变更, 需要定义项目基线, 关于基线:

    可以变化,但是必须通过基线变更控制流程处理

    17.软件配置管理可以确保软件产品完整性,一致性,可控性,但是无法确保产品的正确性

    18.变更控制需要关注的是:标识变更,提出变更,管理变更

    19.配置管理的基本过程:

    (1)配置项标识、跟踪; ( 2)配置管理环境建立; (3)基线变更管理; (4)配置管理审
    计;(5)配置状态统计; ( 6)配置管理计划。

    20.软件配置控制委员会( SCCB)的基本职责:

    评估变更、批准变更申请、在生存期内规范变更申请流程、对变更进行反馈、与项
    目管理层沟通。

    21.配置管理在软件 开发中的作用,并列举至少两种配置管理工具

    软件配置管理是软件项目管理的重要内容,也是保证软件质量的重要手段。它能
    够对软件开发过程进行有效管理和控制, 从而实现软件产品的完整性、 一致性、可控性,使
    产品极大程度地与用户需求相吻合。 它能够控制、 记录、追踪对软件的修改并形成规范文档,
    方便日后维护和升级,更重要的是能够保护代码资源,积累软件财富,提高软件重用率。
    配置管理工具有: Harvest、 Perforce、ClearCase、PVCS、CVS\SVN、 VSS

    22.写出几个常见的软件配置项

    软件项目计划、需求分析结果、软件需求规格说明书、设计规格说明书、源代码清
    单、厕所规格说明书、 测试计划、 测试用例与实验结果、 可执行程序、 用户手册、 维护文档。

    第十章软件项目人员与沟通计划

    1. 沟通管理的基本原则是及时性、准确性、完整性、可理解性。

    2.可以充分发挥部门资源优势集中的组织结构为职能型组织结构

    3. 沟通计划用于确定谁需要信息,需要什么信息,何时需要信息,以及如何将信息分发给他们。

    4. 组织结构的主要类型:

    • 职能型(适用于主要由一个部门完成的项目或技术比较成熟的项目组织结构,是目前最普遍的项目组织形式,它是一个标准的金字塔型组织形式)
    • 项目型(在这种组织结构中项目成员没有安全感)
    • 矩阵型(项目涉及多的领域和特性)

    5. 会议形式 沟通最有可能协助解决复杂的问题。

    6.当项目中有 20 个人时,沟通渠道最多有 190。

    公式:N(N-1)/2  其中N:表示人员总数
    

    7.项目干系人是项目计划的一部分。

    8.项目沟通的基本原则是及时性、准确性、完整性和可理解性

    9.在 IT 项目中,成功的最大威胁是沟通的失败

    10.责任分配矩阵是明确项目团队成员的角色与职责的有效工具

    11.对于紧急的信息, 应该通过口头的方式沟通; 对于重要的信息, 应采用书面的方式沟通

    12.人员计划描述项目的团队人员什么时候,以及如何加入和离开团队

    13.沟通计划包括确定谁需要信息, 需要什么信息, 何时需要信息, 以及如何接收信息等

    14.人员管理计划没有明确的具体体现形式, 作为项目计划的一部分, 其详细程度因项目而异

    15.项目经理花在沟通上的时间是 75%-90%

    16.干系人:

    • 影响项目决策的个人、群体或者组织
    • 影响项目活动的个人、群体或者组织
    • 影响项目结果的个人、群体或者组织
    • 注意只有这三种,并不是适应所有的项目人员

    17.编制沟通计划的基础是沟通需求分析

    18. 团队:

    • 是一定数量的个体成员的集合
    • 团队应注重个人发挥,应该将某项任务分工给擅长该技术的职员
    • 团队的目的是开发出高质量的产品
    • 团队包括自己组织的人、供应商、分包商,注意没有客户

    19.写出 5 种以上项目沟通方式

    沟通方式主要有书面沟通和口头沟通、 语言沟通和非语言沟通、 正式沟通和非正式沟通、
    单向沟通和双向沟通、网络沟通等

    20.矩阵型项目组织结构的优缺点是什么

    优点是: 1、专职的项目经理负责整个项目,以项目为中心,能迅速解决问题。在最短的时间内调配人才,组成一个团队,把不同职能的人才集中在一起。
    2、多个项目可以共享各个职能部门的资源。在矩阵管理中,人力资源得到了更有效的利用,减少了人员冗余。
    3、既有利于项目目标的实现,也有利于公司目标方针的贯彻
    4、项目成员的顾虑减少了,因为项目完成后,他们任然可以回到原来的职能部门,不用担心被解散,而且他们能有更多机会接触自己企业的不同部门。
    缺点是 1、容易引起职能经理和项目经理权利的冲突。
    2、资源共享可能引起项目之间的冲突
    3、项目成员有多位领导,即员工必须要接受双重领导,因此经常有焦虑与压力

    第十一章软件项目风险计划

    1.风险评估的方法包括

    • 定性风险分析
    • 定量风险分析。

    2.决策树分析是一种 形象化的图表分析 方法。

    3.项目风险的三要素是

    • 风险事件
    • 风险事件发生的概率
    • 风险造成的影响

    4.(回避)风险是指尽可能地规避可能发生的风险, 采取主动放弃或者拒绝使用导致风险的方案

    5.风险规划的主要策略(应对风险的常见策略)是:

    • 回避风险
    • 转移风险
    • 损失控制
    • 自留风险

    6.软件项目风险识别常采用 德尔菲方法、头脑风暴法、情景分析法、风险条目检查表、其他等方法。

    7.定量风险评估主要包括 访谈、盈亏平衡分析、决策树分析、模拟法、敏感性分析 等方法。

    8.风险管理的 4 个过程:

    • 风险识别
    • 风险评估
    • 风险规划
    • 风险控制

    9.风险的三要素:

    • 一个事件
    • 事件发生的概率
    • 事件的影响

    10.险评估方法:

    • 盈亏平衡分析
    • 模拟法
    • 决策树分析

    11.一个项目在进行规划的时候,碰到了一个风险问题,项目经理决定是否采用方案 A。如果采用方法 A 需要使用一个新的开发工具,而能够掌握这个工具的概率是 30%,通过使用这个工具可以获利 5 万元,如果采用方案 A 而不能掌握这个工具,将损失 1 万元。利用决策树分析技术说明这个项目经理是否应该采用这个方案 A?(绘制决策树)

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tZxOV8Nj-1589334555777)(5.png)]
    EMV:损益期望值
    公式:EMV=(outcome(回报)*成功概率-亏本 * 亏本概率)
    EMV=(50000 * 30%-10000 * 70%) =8000

    12.某企业在今年有甲乙两种产品方案可以选择,每种方案的状态、收益和概率如表 11-11 所示,绘制决策树时,判断哪种方案将有更大收益。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ya7FxaAB-1589334555778)(6.png)]
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-M7GW4oxz-1589334555780)(7.png)]

    第十二章软件项目合同计划

    1.买房风险最高的合同类型: FFP(固定总价合同)

    2.为执行项目而从项目团队外获取产品、服务或者成果的过程称为:采购

    3.合同双方当事人承担不同角色,这些角色包括:甲方、乙方

    4.软件外包的基本步骤:竞标邀请、评估候选乙方的综合能力、确定承包商

    5.如果 CPPC合同类型中成本百分比是 10%,估计成本是 10 万元,当实际成本是 20 万元是,合同金额应该为: 22 万元

    20+10% * 20=22万

    6.一个 CPFF合同类型,估计成本是 10 万元,固定费用是成本 1.5 万元,当成本提高至 20万元是,合同金额为: 21.5 万元

    20+1.5=21.5万

    7.合同类型有:

    • 成本补偿类合同(CPCC)
    • 固定价格类合同(FFP)
    • 单价类合同()
    • 成本加奖金( CPIF)合同
    • 成本加成本百分比(CPPC)
    • 固定成本加奖金(FPIF)

    8.招标书可以是合同计划的输出

    9.对于甲方来说,风险最高的是 CPCC合同类型,风险最低的是 FFP合同类型,乙方则相反

    10.某项目采用成本加奖金的成本补偿类合同,当预算成本为 20 万元,利润 4 万元,且奖励分配为 80/20 时,如果实际成本降至 16 万元,则项目总价为

    项目总价=成本+奖金(节约成本 * 20%)+利润=16+(节约成本=20-16=4)4 * 20%+4=20.8万

    11.合同是需要靠( 相关法律法规)约束的

    12.项目预计成本 10 万,成本百分比 20%,如实际成本 8 万,则合同金额:

    8+20%*8=9.6

    13.成本加奖金合同,激励比 80/20; 估计成本 12 万,利润 1 万。如实际成本 12 万,则合同金额为: 12+1=13 万;如实际成本为 11 万,则合同金额为

    11+1+(12-11)20%=12.2

    第十三章项目集成计划

    1.软件项目管理最终要的 4 个要素是:

    • 范围
    • 质量
    • 进度
    • 成本

    2.质量和成本成一定的正比关系,进度和成本成一定的反比关系,范围和成本成一定的正比关系

    3.为了加快项目进度,可以适当见减低过程中的质量标准

    4.项目集成管理包括:

    • 对计划的集成管理和项目跟踪控制的集成管理
    • 保证项目各要素协调
    • 在相互影响的项目目标和方案中做出权衡
    • 没有软件设计文档

    5.设成本 C 是范围 S、质量 Q、进度 T的一个函数 C=F(S,Q,T),在成本或时间不充足的情况下,可以通过减小范围或者( 降低质量)来解决。

    6.项目管理过程中的进度目标,成本目标,质量目标,范围目标等各个目标之间是(相互关联和制约的)

    7.软件项目管理要素:

    • 范围
    • 质量
    • 成本
    • 不包含交互

    8.项目集成计划的特点:

    • 综合性
    • 全局性
    • 内外兼顾性
    • 不包含针对性

    第十四章项目集成计划执行控制

    1.项目执行控制的基本步骤:

    1)建立计划标准; 2)观察项目的性能; 3)测量和分析结果; 4)采取必要措施; 5)做好计划修订工作,控制反馈。

    第十五章项目核心计划执行控制

    1.软件项目中的软件开发成本是总成本的主要部分。

    2.当 SV=BCWP-BSWS<0时,表示项目进度落后。

    3.代码评审由一组人对程序进行阅读、讨论和争议,它是质量控制过程。

    4.挣值分析法也称为已获取价值分析,是对项目的实施进度、成本状态进行绩效评估的有效方法。

    5.从质量控制图的控制上限和控制下线,可以知道接受的过程的偏差范围。

    6.范围控制的重点是避免需求的变更。

    7. 一个任务原计划 3 个人全职工作 2 周完成,而实际上只有 2 个人参与这个任务,到第二周末完成了任务的 50%,则 CPI=?

    CPI(成本效能指标)=BCWP(已经完成工作的成本预算)/ACWP(到目前为止花了多少钱) * 100%
    * CPI>1:低于预算 ;=1:按照计划进行;<1:超过预算

    8.记录反映当前项目状态的项目性能数据是控制项目的基础。

    9. 项目进度成本控制的基本目标是在给定的限制条件下,用最短时间、最小成本、以最小风险完成项目工作。

    10.代码走查是在代码编写阶段,开发人员自己检查自己的代码。

    11. 在使用应急法压缩进度时,能够进行压缩的只有关键路径。

    12. 累计费用曲线中某时间点 ACWP(到目前为止花了多少钱)比 BCWS(到目前为止本应该完成的工作是多少)高,意味着在这个时间点为止,实际的成本要比计划的高,二者之间的差值就是成本差异。

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

    14. 项目原来预计于 2014.5.23 完成 1000 元的工作,但到 2014.5.23 只完成 850 元工作,而为了这些工作花费 900 元,则成本偏差和进度偏差分别是

    SV(进度差异)=BCWP(到目前为止实现了多少价值)-BCWS(到目前为止应该完成多少)
    所以SV=850-1000=-150
    CV(费用差异)=BCWP(到目前为止实现了多少价值)-ACWP(到目前为止花了多少钱)
    所以CV=900-850=50

    15.如果成本效能指标 CPI=90%,他说明投入 1 元产生 0.9 元的效果

    16.进度控制重要的一个组成部分是确定进度偏差是否需要采取纠正措施

    17.资源平衡最好用于(非关键路径)活动

    18.当项目进展到(20%)左右时, CPI处于稳定

    19.抽样统计的方法中,以小批量的抽样为基准进行检验

    20.质量控制的3 个要点:

    • 检查项目结果
    • 依据相关质量标准进行跟踪检查
    • 确定消灭质量问题的措施

    21.某项目由 1、2、3、4 四个任务构成,该项目目前执行到第 6 周末,各项工作在其工期内的每周计划成本、每周实际成本和计划工作量完成情况下表所示:

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8g7YrGmu-1589334555781)(8.png)]

    1.根据提供的信息,计算截至第 6 周末该项目的 BCWS、ACWP、BCWP

    BCWS=10+15+5+10+10+10+20+10+10+5+5=100;
    ACWP=10+16+8+10+10+12+24+12+5+5=112
    BCWP=10+15+5+(10+10+10+20+10+10)/2+(5+5+25+5)/2=95

    2.计算第 6 周末的成本偏差 CV、进度偏差 SV,说明结果的实际意义

    CV=BCWP-ACWP= -17
    SV=BCWP-BCWS= -5

    3.照目前情况,计算完成整个项目实际需要投入多少资金?写出计算公式。

    CPI=BCWP/ACWP=84%
    EAC=BAC/CPI=170/84% = 202

    22.某项目正在进行中,下表是项目当前运行状况的数据,任务 1、2、3、4、5、6 计划是按顺序执行的,表中也给出了计划完成时间和实际的执行情况。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Pqy65eOI-1589334555782)(9.png)]

    1.计算 BAC

    BAC=5+25+120+40+60+80=330

    2.计算截至 2014 年 4 月 1 日的 BCWP、BCWS、 ACWP、 SV、SPI 、 CV、CPI等指标。

    BCWP=5+25+40=70
    BCWS=10+20=30
    ACWP=10+20+50=80
    SV=BCWP-BCWS=40
    SPI=BCWP/BCWS=175%
    CV=BCWP-ACWP=-10
    CPI=BCWP/ACWP=87.5%

    23.试述 Pareto 规则

    80%的问题是由 20%的原因引起。

    第十六章项目辅助计划执行控制

    1.项目周例会是一种正式沟通方式。

    2.在马斯洛的需求层次理论中,最高层需求是自我实现。

    3. Y理论属于参与理论

    4.风险管理是连续的过程。

    5.管理干系人参与和控制干系人参与都是干系人管理的任务。

    6.敏捷生存期模型中的每天站立会议是很有效的一种沟通方式。

    7.对于冲突而言,冲突常常是有利的事情

    8.项目培训特点:

    • 时间短
    • 针对性强
    • 见效快

    9.冲突解决方法:

    • 解决问题( confrontationorproblemsolving )
    • 妥协( compromise )
    • 强迫方式( forcingmode )
    • 撤退( withdrowal )

    10.项目中的小组成员要同时离开公司,项目经理首先应该( 实施风险计划 )。

    11.一个软件项目团队中一般有哪些人员角色?

    项目经理、架构分析师、系统分析师、 DBA、程序开发人员、测试人员、系统工程师、
    质量管理人员

    十七章 项目结束过程

    1.项目目标已经成功实现,可交付成果已经出现;或者项目无法继续进行,这时项目可以 终止 了。

    2.项目结束过程包括

    • 制定结束计划
    • 完成收尾工作
    • 项目最后评审。

    3.是否在预算成本内完成项目、是否实现目标、是否达到项目客户的期望等都是检验项目成功与失败的标准。

    4. 项目验收过程是甲方对乙方交付的产品或服务进行验收检验,以保证它满足合同条款的要求。

    5. 项目计划中确定的可交付成果已经出现, 项目的目标已经成功实现时, 可终止项目。

    6.一个项目的交付验收,意味着项目的结束

    7.当一个项目的目标已经实现,或者明确看到目标已经不可能实现时,项目就应该终止。

    8. 客户接受项目的交付结果之前,项目经理应该检查交付结果的质量

    9.不包括在项目验收过程中的是 项目总结

    10.项目终止的条件:

    • 项目计划中确定的可交付成果已经出现,项目的目标已经成功实现
    • 项目已经不具备实用价值
    • 项目由于各种原因而导致无限期拖长
    • 不包括项目需求发生了变化

    11.项目成功与失败的标准是:

    • 是否实现目标
    • 可交付成功如何
    • 是否达到项目客户的期望
    • 不包括项目人数庞大

    12. 在项目的末期,与卖方的合同还有尚未解决的索赔,项目经理(进行合同收尾,合同收尾之后,可能采取法律行动)。

    展开全文
  • 本想写下这么多年的管理心得,却发现已经有人总结的比我还好,主要观点和我高度相同(红字),他山之石可以攻玉,于是就顺势转了。 本人做项目经理工作多年,感到做这个工作最要紧的就是要明白什么是因地制宜、...

    本想写下这么多年的管理心得,却发现已经有人总结的比我还好,主要观点和我高度相同(红字),他山之石可以攻玉,于是就顺势转了。

    本人做项目经理工作多年,感到做这个工作最要紧的就是要明白什么是因地制宜、因势利导,只有最合适的,没有什么叫对的,什么叫错的,项目经理最忌讳的就是完美主义倾向,尤其是做技术人员出身的,喜欢寻找标准答案,耽误了工作进度,也迷茫了自己。以下是本人一些做项目的个人体会,写出来供大家指点,在讨论过程中共同提高水平。

      项目开始阶段是一个最重要的阶段。项目经理在接手一个新项目的时候,首先要尽可能地多从各个方面了解项目的情况,如:

      1.这个项目是什么项目,具体大概做什么事情,是谁提出来的,目的是解决什么问题。在国内很多客户都很不成熟的情况下,千万不要根据项目的名称望文生义地去想象项目的目标。一个名为“办公自动化”的项目很有可能在你进场以后一个月才发现客户其实需要的是一个计算机生产管理辅助信息系统系统。前期了解情况的工作越详细,后面的惊讶就越少,项目的风险就越小。

    2.这个项目里牵涉哪些方面的人,如投资方、具体业务干系方、项目建成后的运营方、技术监督方等等,很多项目里除了业主单位的结构很复杂以外,还有一些其他单位也会牵涉进来,如项目监理公司、业主的行业主管机构等。项目经理需要了解每个方面的人对这个项目的看法和期望是什么。事先了解各个方面的看法和期望,可以让你在做项目碰到问题的时候,就每件事情分析哪些人会在什么方面支持你,哪些人会出于什么目的反对你,从而提前准备联合朋友去对抗敌人,让事情向你所希望的方向发展。没有永远的朋友,也没有永远的敌人,只有一致的利益,这句话作为项目经理是一定要记住的;

      3.基本了解了客户的情况后,下面的事情就是了解自己公司各方面对这个项目的看法。首先是高层领导是否重视,这个决定了你在需要资源的时候,公司是否会根据你的要求提供最有力的支持。领导口头肯定是说支持的,你需要做的是了解公司对这个项目的实际期望,是想把项目越做越大还是想赚钱?是想做样板工程还是干脆想敷衍了事,公司领导对项目的态度决定了你做这个项目的战略,而这个战略方针将对你做项目计划产生直接的影响;

      4.在做整体项目计划前,还要大致计算一下你手上的资源。首先是时间,现在市场竞争激烈,往往很多项目要求在几乎不可能的时间范围里完成。对于这一点,你在做项目的风险控制计划的时候要充分考虑。其次是人员,根据项目预算和已往经验,大致计算一下未来的项目小组有多少种角色,每个角色目前公司是否有人,是否能完全归这个项目使用,是否需要另外招聘一些人员,招聘的准备工作要尽早启动。最后就是一些设备的准备,项目所需大件关键设备要尽早预定,以后不管发生设备等人还是人等设备的情况,浪费的都是你的时间

      5.现在是做项目说明书的时候了。一份好的项目说明书不仅将要做的事情描述得很清楚(主要是讲做什么,而不是说怎么做),而且把如何检查也说明得很透彻。也就是说它不仅说明白了要做哪些事情,也让客户的业务人员(一般不懂技术)知道项目做成什么样就算完成了。简单地说,项目说明书描述项目做哪些事情和每件事情做到什么程度以及如何检查每一个结果。

      6. 是到做总体计划的时间了吗?不,你现在已经知道了客户的目标和你手上的资源,那么做计划以前,你还需要和你的经理和客户充分沟通资源的问题。因为很多资源是还不明确的,你需要写一份报告详细分析这个项目的风险以及对资源的需求情况。如果一些问题不能得到解决的话,将发生什么样的后果。如果资源不够,就要高层改变策略,增加对这个项目的投入。甚至在条件许可的情况下,有些公司会放弃这个项目。总之,没有人能完成一个不可能完成的任务,

      如果项目经理不能尽早发现风险,那么就只能去当烈士了。 7.明白了要做哪些事情和你手上的筹码以及你做这个项目的总体策略,现在是成立项目小组的时候了。很多项目经理都没有自己选择组员的权利,那么,就尽量发挥你的影响力去寻找那些你想要的人吧。成员的组成根据项目不同,相差较大,很难有什么具体要求,但是,一定要有精通客户业务的人,很多小项目里,这个人就是项目经理本人,大项目里会配备行业专家(Industry expert),这样和客户沟通起来才不会鸡同鸭讲,双方才可以相互理解。我经常看到的情况是我们的技术人员和客户交谈时满口的专业术语,结果搞得客户一头雾水,反过来,他还指责客户不懂技术。其实,明白自己想做什么的客户已经是很好的客户了,不知道自己要做什么,更不懂怎么做还要指手画脚的客户到处存在,但是要明白,是客户选择了你,而不是你选择了客户,有了客户你才有工资拿,心平气和一点吧。

      8.现在你要面对三群人:你的领导、你的组员和你的客户,和这些人沟通,让他们知道你打算怎么做,什么时候要他们做什么准备这些事情将是你的主要工作。既然沟通这么重要,那些事先定义一下沟通的原则也是一件很要紧的事情。很多沟通原则都是潜规则,如果你在一个部门时间做长了,对这些规则的运用觉得是一件理所应当的事情,但是,你现在面对的是多个部门甚至多个单位,不把沟通规则说清楚,你以后就会吃亏。下面的东西看起来无聊,其实还是很管用的:第一个是规定信息的流动方式和介质,是推还是拉。推的意思就是项目经理将主动发布信息,不管通过电话、邮件还是书面方式,保证将信息传达到每个人。这种情况适合小项目,人少;拉的意思就是项目经理就是一个类似web服务器,你自己需要什么信息就去问他。当然,没有项目经理把自己搞得那么累,他会用发布信息到公共介质的方式公布信息,简单的是白板,复杂一点的是项目的公共信息交互区,潜规则就是我发了你没去看就不要说我没告诉你。说这些看似很无聊,其实里面牵涉信息传达不完全的责任问题。当然,这些都是指一般的方式,而且不要绝对化,一般情况下,主动沟通和被动访问是同时存在的,尤其是对领导,项目经理更加应该主动去和领导沟通。第二个问题就是文档问题,很多人怕写文档,但是项目经理一定要牢记“好记性不如烂笔头”的道理。有理有时候为什么会说不清呢?就是因为没有证据。所以项目经理开始就要和客户说清楚有些文档是必须签字的,比如项目经理的项目日志,每个星期至少让客户签字,另外所有达成共识的东西,比如会议纪要,甚至领导的讲话记录,都要写成文档,双方签字,这样以后扯皮的时候,就能做到有据可查。记住:说了的就和没说一样,只有写下来大家签字后才算真正发生了的。还有一些问题,比如你提交的报告,给领导(包括本方领导和客户领导)做一个选择题,结果领导压住不批,让你无所适从,结果拖延了进度。这时候,你可以等,但是注意要留记录,标明是谁的责任;另外,如果你在开始阶段就和领导商定:如果批示提交三天后没有得到领导答复就算对方同意,这样你就会主动很多。再比如不同事件的审批流程问题:什么等级的事情记录在项目日志里、什么等级的事情要双方项目经理专门签署备忘录、什么等级的事情要双方领导出面签署合同附件等等。事先想得越周到,以后的工作就越主动。

      9. 好了,做了很多前期工作,定义了一些游戏规则,现在是坐下来做计划的时候了。这一节,任意找一本项目管理的书都会说得比我好,所以我就少写一点,说一些自己的体会就是了。首先是找几个关键组员,比如客户业务专家、系统分析员等等,做一下项目模块划分工作。项目分成几块去做,每一块完成什么,模块之间的信息如何交换等等。需求定义的是做什么的问题,而这里说的是怎么

      做的问题。这里要强调一点:完成一个目标有很多种方式,你要选一种你最熟悉的,而不是看上去最完美的,这个思路会让你的项目减少很多风险。有时候客户会被某种新技术打动,坚持要你采用那种新技术,你就应该告诉他:你选我做这个项目,就应该容许我采用自己最喜欢的方式做事情,新技术之所以有诱惑力,就是因为吃亏的人还不多,我不希望你成为第一批受害者。采用一个计划会让你的工作更加明确,比如用微软的Project软件,你填写完表格以后,就可以知道这个项目有多少件事情要做,每件事情需要什么资源,他们之间的前后关系如何,消耗的时间有多长,完成后有什么标志等。所有的结果最后用一个叫做甘特图的形式表现出来。你做完这个表以后会惊奇地发现,甘特图上项目的结束时间会远远落后于你的计划结束时间(签合同的人永远不会先征求你的意见的)。当然,学过项目管理的人会大谈什么WBS、优化路径之类的东西,但是我的经验是你再优化也不可能把这些东西安排到计划的时间结束。如果你没碰到这个问题,在我恭喜你挑了一个轻松活之前,请你再去确认你是否罗列了所有要做的事情和正确评估了他们所需要的时间。这时候,你就要考虑牺牲一些任务的时间(也意味着质量)了。按照什么标准牺牲?这个项目的战略!我们在第三节提到过的战略。我的经验是如果你什么都赶进度,其结果可能就是十件事情你一件也没做好,想想多么失败啊。所以,把资源投到你熟悉和有把握的事情上,最后的结果是十件事情,你有三件做成了精品,三件完成,还有四件因为某些原因延误,成绩单是否靓丽了很多呢?战略决定优先级,而正确排列事情的优先级是一个项目经理能力的主要体现。

      好,现在项目已经完成了前期工作,了解了项目的目标、搞清楚了手上的资源,制定了项目的策略,然后编制了项目的整体计划,项目进入实施阶段。进入这个阶段反而是项目经理比较空闲的 时候,不像前期的时候项目经理要象记者一样到处和不同的人接触,搞清楚他们在说什么,努力猜测他们在想什么和他们的真正目的,那才是最累人的事情。当然,小项目的项目经理往往自己也是一个资源,要做很多事情,这时候反而比谁都苦。项目经理这段时间的主要工作是保持和客户领导以及自己领导的沟通。和客户领导沟通时特别要注意,除非你需要对方给你支持,那么你才需要讲得具体一点,否则,告诉他一切正常就可以了,而且态度要积极一些,千万不要说一些领导不懂的细节,比如:“王局长,最近项目进度还算正常,就是JVM经常发生一些内存泄漏的情况?”王局长:“(*&$@@”。和自己的领导汇报也要注意这个问题,除非他是一个技术高手,你需要他的技术经验,否则一般就汇报进度是否正常以及有问题时你的对策和打算就可以了,有些需要他支持的地方,比如资源调用需要说详细一点。

      和组员开会,除了一些项目进度跟踪会议以外,还有很多讨论会,需要大家用头脑风暴方法给出解决问题。与会人员很多都是技术人员,他们的特点是注重细节、缺乏大局观、有点消极悲观、自尊心强(如果总结得不对,欢迎大家拍砖),所以,你作为会议的主持人,只要负责提出问题和记录下他们的观点,千万不要做评判者的角色。一个问题,有很多方面,从不同的角度看,现象是完全不同的,想想盲人摸象的故事吧。这些技术人员,他们往往精通一个方面,就自己的角度发表见解,除非一些很特别的情况,你都应该认为,他们提出的方案,从他们的角度来看是最合理的。你的长处是掌握事情的优先级,评估各个方面的轻重缓急,从而根据他们的意见得出一个合适的(而不是正确的)方案。所以,在会议上,你要充分尊重每一个人和他的意见,夸奖那些意见提得比较好的人,千万不要把会议带入无休止的争论(你要让大家知道事情不是非黑即白的,而是多元的,唉, 我们的教育惹的祸?)。会后,你自己写文档,做决定。会议上大家的面子都被照顾了,自然实施起来的阻力就小,如果还有意见的,你就私下找他聊,如果还不能说服他,你就要让他明白,因为你负责这个项目、你担当风险,所以,这个优先级应该你来判断。组织中的高层,并不见得水平会比一般的成员高,但是,他要承担组织的风险,加之信息的不对称性,所以,对事情的优先级的判断肯定比下属强。

      在开发过程中,内部管理还要注意的一点是时刻强调以验收为目的的思想,每个任务的最终可交付成果一定要是可以被检查的,比如,【界面要求:美观大方、简洁明快】,这个要求我就不知道如何检查。所以,给开发小组布置任务的时候就要考虑如何检查结果,比如我见过一个计划,里面有一个任务【开发人员熟悉EJB编程】,这个任务,除了让这些人去参加一些专业认证考试,否则,结果很难被检查。所以,时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情,我听说有些老项目经理拿到项目是倒排计划的,即首先看如何验收和验收标准,然后决定工作计划。很多项目开始了很久,还不知道如何验收,那么这个项目出问题的可能性就很大了。做项目就是为了验收,我们的角色不是研究机构,我们的目的就是在付出那么多劳动后得到结果。另外我插一句:我是极其不主张到客户现场开发的。尤其是一大群技术人员直接和客户交流,很容易引起冲突和矛盾(技术人员的本性决定的)。我的做法是项目经理和项目实施人员到现场,软件开发人员还是在公司做项目。项目实施人员就是初级项目经理,他们了解自己的产品,懂得一些客户的业务,关键是在于他们具有良好的沟通能力,俗称“皮厚”。他们是客户和研发人员的桥梁,其职业方向也是很机动灵活,以后可以有很多方向可以转,比开发人员的路要宽得多。

      接着,我们再谈谈最让人头痛的需求变更问题。变更通常分为两种:一种是部分更改了原先的目标,即需求变更;另一种是没改变目标,但是客户不满意目前的实现方式,大到流程的实现,小到界面的布局,都是属于这类。碰到这种情况是难以避免的,主要是事先沟通的不够充分和客户随着项目的进展,慢慢想清楚了问题,改变了以前的思路。这时候,如果需要改并且你的战略是容许这种情况的,那么注意下面几点:

      1. 确保以前的文档,就是记载着以前的结论的东西,客户是否签过字,如果没有,赶紧把你的工作停下来,赶快再和客户自己确认一下你的方案,然后让他签字,避免以后说话没有凭据; 2.和客户坐下来,自己探讨他修改的根本目的是什么,是不是有同样能达到相同目的,但是对你来说有代价更小的选择? 3.(项目初期的工作)明确更改流程,一般是客户指定一人签字(否则客户每个领导都有权力来插一杠子,你就废了),以正式项目文件的方式提交给你,然后,你做评估分析,分析对成本、进度的影响,在你的领导同意后,出相应意见书,主要是要说明更改设计的原因和指出由此带来的不确定后果(这个东西先写出来,后面如果真的发生了,至少不是你的错)。然后再让客户在上面签字。见过医院给病人做手术以前让家人签的免责条款吗?对,就学习那个,让大家都意识到任何的更改都有成本和代价 所以,对于这种需求天天变的客户,你就一定要事先做好规矩:

      一、统一联系人,客户指定一个人和项目组进行沟通,不能张领导、王领导都来说几句,如果他们意见不一致,那你只有得罪领导的选择了,所以,项目的最初就要定好规矩,我项目组只认一个的意见,有什么要求你们内部先统一再和我谈,我不想卷入你们内部业务部门之间的矛盾之中;

      二、所有需求变更全部要有书面文字,这点切记!这样做好处多多:

      *有书面证据,以后他还想改,你有了他以前要求的证据,告诉他:你以前可是这么说的;

      *便于需求变更管理,需求如何慢慢演变的历史可以看清楚,从而更深切地体会客户的目的;

      *对于客户来说,嘴巴一动最方便,反正是你们做,不花他的资源,所以要求是否合理,是否和项目的目的一致,他是不负责任的。但是如果要他写书面要求,还要签字盖章,他就要谨慎多了,而且一写东西,思想就会更加深入,很多无理要求也就这样胎死腹中了;

      系统开发告一段落后,就进入客户培训、系统验收阶段,这个阶段,我一般会注意以下几个问题:

      

      给客户做培训前,多注意一些表面功夫。很多程序员认为,既然很多系统采用原型法,有一个由粗到精的过程,那么系统的逻辑核心是否正确才是关键,至于界面如何,界面上的用词是否准确,那是无关紧要的问题;而且培训的时候也是空手上台、信手拈来,想到哪里说到哪里,下面听讲的人不知所云,云山雾罩,培训效果自然可以想象。我的体会是,给客户做培训的版本,如果你在做多次测试以后仍然不能确定逻辑是否合乎要求,那么,你至少要在界面上多花一点功夫。注意每个界面的布局、用词、链接的正确性等等,总之不要让客户看到一些他不该看到的东西,否则,仅仅因为一些无关紧要的报错就让客户第一印象觉得系统不稳定,那你就真的比窦娥还冤了。如果工作再做得详细一点,可以做一些类似Flash的东西,把一些你要强调的重点用通俗易懂、轻松愉快的方式表达出来。文档方面,准备至少两个文档:用户手册和培训手册。这两个文档的内容很多都是一致的,但是角度完全不同。用户手册往往是站在系统设计者的角度,按照自己的思路,分模块讲解系统的操作和功能;而培训手册,一定要站在客户业务人员的角度,根据每个角色面对不同业务的办理,如何通过使用本系统的一系列功能来实现目标。所以,第一次培训以前,系统界面是否完整正确、培训文档是否完备、培训时所举的例子是否有代表性都是很关键的因素,第一炮打不响,以后就麻烦很多。

      

      上面讲的是培训的时候,丑媳妇要化妆好再去见公婆的问题。其实,项目实施中还有一个考验项目经理功力的就是如何调动客户积极性的问题。一般来说,客户是懒的,这就是他花钱找你做事情的原因。一个项目的成败,和客户的配合程度很有关系。根据我的分析,一般项目中的客户都可以分为三类:支持的、消极观望的、抵触的。他们人数的分布一般是一个纺锤形:支持的和抵触的人少,观望的人多(如果你接了一个人人都抵触你的项目,那你还是不要做了)。首先,分析一下那些人为什么支持你和抵触你。很简单,于公于私两个方面分析,上了新系统,谁的工作量有所变化?谁的潜在利益是否受到威胁?谁的岗位是不是因为新系统而消失?传统的利益格局因为新系统的使用而发生怎么样的变化,这些东西,都是项目经理必须去了解的,这样,你才能团结那些支持你的人,消减那些抵触你的人。项目经理是一个很奇怪的角色,属于典型的责任大、权力小的角色,他能做的只有借力打力,不管在自己公司还是在客户那里,一定要依靠别人才能完成自己的目的。只有了解哪些人会因为什么而帮助你,哪些人会因为什么而抵触你,你才能让客户配合你做工作。比如上一些内部计算机辅助管理系统,

      其必然后果就是让本来管理混乱时有人可以浑水摸鱼的一些利益消失掉了,这样,有些人肯定就要捣乱,到处诋毁这个系统。这时候,你就可以散布一些"谁抵制新系统就说明自己屁股上有屎"这类的论调去压制他们,减弱他们的影响。总之,团结积极分子,打压敌对分子,带动大多数是你的基本策略。

      还有一个体会和大家分享:千万不要觉得对方的领导(中层干部)是应该配合你工作的,特别是一些国营单位,多一事不如少一事,他干吗要帮你?我的经验是:对方领导如果没有拿你的事情作为内部斗争的武器而从中作梗(当然,他针对的不一定是你),那已经是算合作的了,记住,他不捣乱就是帮你忙了。

      

      作为项目经理,其实脑子里就是几样东西:做哪些事情、做到什么程度、怎么交货、手上的资源以及各个事情的优先级。所谓多快好省那是人类的梦想,这四个方面都是相互矛盾的,属于典型的又要马儿跑,又要马儿不吃草的类型。一般说来,项目经理在考虑问题的轻重缓急方面,往往是把快放在第一位,各方领导都会给你最后期限,所以保进度是第一位的;省是第二位的,企业的根本目的是盈利,如果收入不能增加的话,至少费用要控制住;好是第三位的,没办法,谁都想精益求精,但是,没有强大的资源保障,质量只好先牺牲了;最后是多,客户的要求源源不断,如何降低客户的期望值,把项目控制在一个合适的范围内,让客户从理想回到现实也是项目经理的分内工作。

      

      验收前,除了做好文档工作,即可交付成果以外,多花时间搞清楚客户的做事情流程是很重要的事情,一个公司做事情必定有流程,所以搞清楚流程十分关键。比如验收、付款这些你极其关心的事情,客户那边的流程是怎么样的,谁牵头组织、哪些人参加,要什么文件、走什么程序、哪些人签字、最后出什么文档等等,都要搞清楚,特别要事先分析和打听哪个环节容易卡壳,做好事先的准备。

      

      我对验收最大的体会就是举证问题。即千万不要让客户这么想:你必须有证据证明你的系统是没问题的。这样你就没戏了,微软那么多天才,做了个Windows还天天打补丁,要你的程序没问题,既不可能,你也没办法拿出证据。你要让客户明白,所谓验收,就是我按照测试文档的测试用例跑一遍,结果和预期结果一致就应该算通过了,而且还容许有一些小错误留在验收后改正,他可以对测试用例提意见。所以,验收前双方要确认测试计划和测试用例。如果他认为系统不符合要求,那么他应该举证,证明这个系统和最初设计相背离的。所以,参考法律概念,千万不要举证倒置。另外,认为系统完美了才能验收的想法也是错误的,软件开发合同里一定要注明验收以后维护期的费用问题,否则,客户担心一旦验收就得不到你们的支持,自然不配合验收,那么,你这个项目经理就很难交功课了。

      最后,我想谈谈如何评价项目经理的绩效的问题,我认为,项目经理有以下几个档次:

      

      *最差的项目经理:项目过程中总是出现意外,然后自己又解决不了,结果成为烈士;

      *二流的项目经理:项目也经常出现意外,但是他一马当先,奋勇向前,解决了一个又一个问题,最后,勉强算把项目结束了,获得了领导的一致好评;

      *一流的项目经理:平时很少见他做具体的事情,整天找人聊天,然后就是写报告、做计划,最后项目顺利结束,整个过程平淡无奇;

      

      项目管理到底是一门科学还是一门艺术呢?所谓科学就是经过反复论证,输入和输出有必然规律的东西,种瓜得瓜;而艺术就是思想火花的闪耀,主要靠灵感。项目管理这个东西,据一个前辈说,在国外是科学,80%是有规律可循的;在国内是艺术,主要靠个人魅力、感染能力等东西。看明白了PMBOK,学会了一些做事情的方式,只是搞懂了那个20%的科学的东西,还有80%的空间,属于见仁见智的领域了。所以,加强很多方面的个人能力,如练就出色沟通能力、提升自己的个人魅力对于项目经理来说是多么重要啊,无论是对内还是对外。作为一个一流的专业人士,在顺利让客户签字的同时,如何让自己的领导知道你的价值,这也是体现自己能力的一种途径。

      MIS软件项目经理应具有三种协调关系:

      一、协调好和客户的关系

      二、协调好和上级的关系

      三、协调好和下属的关系

      MIS软件项目经理应具有的四个能力:

      一、学会引导客户

      二、对客户需求的认知及把握开发进度估算

      三、如何有技巧地说不和点头

      四、计划与实际现场运作的时间点观念及协调统一

      我国的软件企业大部分是以接项目的形式做为生存和发展的途径,项目有大有小,大的二三百万,小的三五万,因此项目的成败及效率就直接影响着公司运营成本和利润以及大家的薪金收入。而项目经理的人选则决定了项目的成败和收益,因此结合自己的经验谈谈项目经理在主持项目实际运作时的二个责任观点三种协调关系和应具备的四个能力。希望对大家的实际工作会有所帮助!

      MIS软件项目经理应时刻记住自己的两个责任和观点:

      一、如何尽快地将项目验收回款,为公司和团队创造更多的利润,为下属带来更多的利益。

      二、如何在做项目的过程中将项目提练成产品。

      作者的观点是以项目提炼出产品并养活产品,而产品则更好地为项目服务以创造更大的利润和发展空间。

      MIS软件项目经理应具有三种协调关系:

      一、协调好和客户的关系,保证客户交流时的气氛活跃活泼,事情做不完,明天可以再做,但客户的心情一定要开心!

      二、协调好和上级的关系,这样你才会有行使项目经理的职权及争取到更好的资源配置。

      三、协调好和下属的关系,他们才是为真正为项目打拼并出成绩的核心人员。 MIS软件项目经理应具有的四个能力:

      一、学会引导客户。

      作为MIS软件,会不会引导客户是整个项目进度的成败。因为一个软件公司做项目时一般都有一个半成品,这时候项目经理和客户谈程序时的作用就是举重若轻,若会引导客户,则程序的二期开发量将会非常小,笔者当初拿着一个程序版本和客户谈时,连续三个大模块都获得客户的认可,只有3×0.5天工作量,而内部计划里则是3×20天的工作量的,同样项目提前了近两个月就转入验收期

      了。笔者当初获得这么大的成功,主要有两点:一是对自身软件产品非常熟,谈时扬长避短,并引导了客户。二是当时和客户谈时我说的都是模块的整体业务和模块的业务流程运作,引导客户并在大方向上达成了一致,不陷入技术细节。题外话:当时讲解时出现保存不正确的现象,我当时则没陷入这问题,而是说数据保存后将转入到下一个流程而过关的。

      二、对客户需求的认知及把握开发进度估算

      在项目推进过程中,不可避免地出现程序需求差异,需求变更和新需求的情况。此时项目经理就肩负着项目开发周期和任务及资源的调整问题,这就要求项目经理能够对客户需求的正确认知和把握及对开发进度的估算。当项目经理面临着需求变更程序变动时,需在最短时间在心里做完的事情是:1、估算出需要的人力和工作日 2、如果做则对整个项目时间周期的影响 3、此项工作的重要度和紧急度,应当安排在什么时候做。然后将结果和客户交流并达成一致,最好用书面形式留档。以项目中一个三个工作日新模块的开发为例,在充分理解客户的基础上如果会引导客户,则三个工作日后该模块就可顺利完成并得到客户的认可。如果不会引导客户,再加上自己对需求的理解不正确又没把握好,用上两个月都有可能,这样使得合同里是半年的项目最后做成了一年而程序还在开发,项目成了程序垃圾的汇集地。国内不少软件公司或多或少都存在这现象。

      三、如何有技巧地说不和点头

      在项目推进过程中将会出现非常多的需求,其中有些需求是当初没考虑好,有些需求是迫切的(比如领导发现后提的),有些需求是无理的而且困难度大,有些需求则是没有意义的,有些需求是技术上达不到的,有些需求是必要的,有些是合理的,有些是合理但不必要的,??。因为需求的变更必然引起工作量的增加和人员的调配,有时处理不好就会使得项目验收遥遥无期甚至和客户关系变僵,所以此时就需要项目经理有技巧地说不和点头了。记住一点:客户是上帝,但你不是基督教徒。笔者有一次在准备将项目转入验收期和他们的老总谈程序时,那老总要求在一个FORM单独做报表打印,而我们的报表打印都是集中在一起的,在和那老总交流解释后我宣布的就是:做,而且连夜赶工,明天一早就得在纸上看到。结果当然是项目顺利转入验收期了。笔者常用的说不的方法是现在的工作重点是什么什么,你所提的问题我们将在几个月后程序升级时自动将这需求解决的。

      四、计划与实际现场运作的时间点观念及协调统一

      在项目推进过程中经常会出现计划变更等情况,这时项目经理要做的事:一、根据实际情况调整你的计划,并做好充分的预估(笔者一般是将困难说大一点,日期长一些)。二、将变更原因和你的新计划向你的上级汇报。三、和你的同事开会协商宣布时同时宣布人员安排和日期安排。记住一点:项目要想做好,时间点是个关键。这样就会因为团队的实力和项目经理的能力而出现加班和强度压力工作的频繁情况,如何让你的下属能够更愿意为这项目打拼,就需要你的协调交流和组织能力了。大家不要忘了两句话:我们的职权是谁赋于的?项目经理和你的同事一样都是打工的。所以大家也知道我在做项目时一和二的用途了吧!

    展开全文
  • 软件项目管理

    千次阅读 2019-08-16 15:53:35
    管理软件销售是最合适顾问式销售技术,但很难想象一个没有实际实施项目经验的顾问可以有效把握企业需求和打动对软件供应商本质上都保持狐疑的潜在客户,这些都只有通过经验丰富的项目经理才可以做到。 如果一家...
  • 软件项目管理 问答题

    千次阅读 2019-07-06 18:50:12
    软件项目管理》 第三版 课后题 问答题总结 来源:百度文库
  • 体验环境 体验方式:PC端 ...了解华为软件开发云的项目管理服务功能,分析其优缺点; 瀑布化开发到敏捷开发的转型分析,以及未来软件开发模式的发展方向; 产品简介 产品名称:华为软件开发云
  • 软件项目管理》课程学习报告

    千次阅读 2007-04-23 15:04:00
    短短的一个月转眼过去了,林老师的软件项目管理课已经结束了。我用了一星期的时间细细的品位了那段美好时光,我希望能用今天完成的学习报告来记录下这段短暂的回忆。希望在未来的日子里每当我翻开这篇报告时就能带给...
  • 软件项目管理流程总结

    万次阅读 2017-12-19 21:54:09
    转自:风尘浪子项目管理与软件开发的质量、效率、最终成果息息相关,本文主要讲述软件项目的风险评估、成本预算、客户沟通、需要分析、开发管理、成品交付等多个流程。 在现今国内的项目的管理形式十分零乱,对管理...
  • 软件项目管理导论

    千次阅读 2020-01-04 16:01:28
    软件的设计与编程完全实现自动化,需要真正“智能”的机器
  • 软件项目管理案例分析

    千次阅读 2014-01-16 15:36:43
    为建立符合中国国情的软件开发过程和组织体系,培训中心特举办“软件项目管理案例分析”培训班,具体事宜通知如下: 一、培训对象 软件开发机构高级管理人员、项目经理、系统架构师、系统分析师、资深开发人员、...
  • 软件项目管理案例教程 第4版 课后习题答案

    万次阅读 多人点赞 2019-11-30 01:18:05
    软件项目管理案例教程 第4版 课后习题答案 第一章 一、填空题 1.敏捷模型包括(4)个核心价值,对应(12)个敏捷原则。 2.项目管理包括(启动过程组)、(计划过程组)、(执行过程组)、(控制过程组)、(收尾...
  • 软件项目管理存在的问题及改进措施 随着计算机应用范围的日益广泛深人,应用软件的规模及复杂程度也日趋大型化、复杂化,这就导致软件开发的方式也从早期的单兵作战式或手工作坊式渐渐转变为集团化、工厂流水线式的...
  • 软件项目管理》课程知识总结

    万次阅读 2014-11-25 17:06:02
    这篇文章是结合《软件项目管理》课程知识进行总结,相当于自己的在线笔记,主要包括9大知识领域:范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和综合管理,希望对大家有所...
  • 项目管理 : 对软件项目管理的探讨

    千次阅读 2006-01-12 08:31:00
    各软件企业都在积极将软件项目管理引入开发活动中,对开发实行有效的管理。我公司是西安一家中型软件企业,在公司中已经实行了项目管理制度,软件项目管理是整个项目管理中的一个重要组成部分。 从概念上讲,软件...
  • 软件项目管理 第2章 项目启动

    千次阅读 2020-03-18 08:27:01
    软件项目管理 第2章 项目启动第2章 项目启动节内测试项目启动概述 第2章 项目启动 节内测试 项目启动概述 1.对于IT项目而言,有哪些项目干系人? 正确答案:项目相关利益者,是指积极参与项目、或其利益会受到项目...
  • 要写软件项目管理实践报告。。头疼!有人能给点建议吗?
  • 软件工程——软件项目管理总结

    千次阅读 2018-07-19 17:01:57
    项目管理 1.概念:项目管理是一系列的伴随着项目的进行而进行的、目的是为了确保项目能够达到期望的结果的一系列管理行为。 2.项目管理核心范围 范围 进度 成本   3.成本估计 软件开发成本主要是指软件开发...
  • 目录[隐藏]1 软件项目管理的概述 2 软件项目的计划 3 软件项目的控制 4 软件项目管理的特性 5 软件项目管理的组织模式 6 软件项目管理的内容 7 软件项目管理的成功原则 if (window.showTocToggle) { var tocShowText...
  • 软件项目管理(4)

    千次阅读 2007-04-13 09:22:00
    软件项目管理(4)软件项目启动阶段的知识与管理软件项目启动即项目的筹备、规划与准备阶段,是软件项目实施的前期工作。软件项目启动由两个重要的工作阶段构成:一是项目的立项,而是项目的全面计划。立项阶段完成...
  • 软件项目管理(3)

    千次阅读 2007-04-10 00:33:00
    软件项目管理(3)软件项目全生命周期的阶段划分软件项目分门别类,不同阶段管理的侧重点有所区别,正确划分软件项目全生命周期过程的各个阶段,是保证整个项目成功的基本条件和基础要素。1、软件项目分类软件项目...
  • 山大软件项目管理复习整理

    千次阅读 2018-06-29 12:44:07
    项目与日常运作的区别:项目是一次性的,日常运作是重复进行的项目是以目标为导向的,日常运作是通过效率和有效性体现的项目是通过与项目经理及其团队工作完成的,而日常运作是职能式的线性管理项目存在大量...
  • 关于软件项目管理的一些问题

    千次阅读 2020-06-06 20:54:21
    1. 项目管理计划书的制作过程 确定项目范围 可交付成果,wbs 项目资源 项目进度计划 角色、责任、项目组织结构 成本和预算 风险 2. 怎么确定项目范围 把客户的需求转变为对项目产品的定义 通过wbs,把项目...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 142,241
精华内容 56,896
关键字:

软件项目管理报告