软件项目管理笔记

1.概述

莱温的领导方式理论把领导者的领导方式分为三种:
专制型领导 民主型领导 放任型领导
领导：
领导就是率领和引导，是一种个体引导群体达成共同目标的行为，是控制、指挥、协调多种工作和人际关系的行为系统
领导(leadership)就是一种影响力，是对人们施加影响，从而使人们心甘情愿地为实现组织目标而努力的艺术过程
案例：
都江堰工程
鲁布革的启发
曼哈顿计划
项目管理的作用
成功=科学技术+项目管理
项目定义：项目是为完成某个独特的产品或服务所做的一次性工作.
工作分两类：常规运作和独特的一次性任务。
无论常规运作还是项目，均要有个人或组织机构来完成，并受制于有限的资源，遵循某种程序，进行计划、执行和控制。
两者不同点：
项目属性：
目标性，其结果只可能是一种期望的产品或服务。
独特性，每一个项目都是唯一的。
一次性，有确定的起点和终点。
约束性，每一个项目的资源、成本和时间都是有限的。
关联性，所开展的活动是密切相互关联的。
多方面性，一个项目涉及多个相关利益者
不可逆转性。不论结果如何，项目结束了，结果也就确定了
项目与日常运作的区别：
项目是一次性的，日常运作是重复进行的
项目是以目标为导向的，日常运作是通过效率和有效性体现的
项目是通过与项目经理及其团队工作完成的，而日常运作是职能式的线形管理
项目存在大量的变更管理，而日常运作则基本保持持续的连贯性的
例子：
项目：野餐活动 集体婚礼 开发操作系统 神州飞船计划
日常运作：上课 社区保安 每天的卫生保洁
软件项目的特点：
软件是逻辑实体，不是具体的物理实体，具有抽象性
软件的开发受计算机系统的限制，对硬件系统有不同程度的依赖。
软件具有复杂性特点，其开发成本昂贵，制约因素很多
项目管理的定义：
项目管理是以项目为对象，通过使用知识、技能、工具和方法来组织、计划、实施并监控项目，使之满足项目目标需求的过程。
硬技能 Samples （计划、跟踪、控制、报告）
软技巧 Samples（领导、团队建设、冲突解决、激励、训练、协商、沟通、倾听）
软件项目管理的必要性：
无规则、混乱的开发状态，进度滞后，费用超支等失败的例子很多
业务失败，合同纠纷，法律诉讼，客户投诉等困扰软件业
软件危机
就是软件生产能力和业务发展需求不相适应的现象
就是弱的软件生产能力和强的业务发展需求之间的矛盾
软件危机表现
开发过程随心所欲
时间计划和费用估算缺乏现实的基础
管理者主要在应付突发事件
对产品质量缺乏客观基础
软件开发的成败建立在个人能力基础上
失败和管理的关系
软件项目失败涉及到软件项目研制中的计划制定、进度估计、资源使用、人员配备、组织机构和管理方法等软件管理的许多问题。
如果有很好的项目管理，其中大部分的问题是可以避免的。如果没有良好的项目管理，其中许多问题一而再、再而三地出现，项目难以成功 。
项目成功的标志：
在规定的时间内完成项目
项目成本控制在预算之内
功能特性达到规格说明书所要求的水平（质量）
项目通过客户或用户的验收
项目范围变化是最小的或可控的
没有干扰或严重影响整个组织的主要工作流程
没有改变公司文化或改进了公司的文化。
项目生命周期：

项目管理知识体系–PMBOK：
PMBOK 9 大过程领域

项目管理的对象-3P

PMBOK 5 大过程组

项目管理成功要素
制定计划：预估和确定项目的工作量大小、所需资源和进度、风险应对措施等；
建立组织：建立项目组，并有明确的角色定义和任务分工；
配备资源：任用各种层次的技术人员和管理人员，以及准备所需的软硬件；
监控执行：协调项目各方人员，监控各种风险，督促项目进展，随时检查实施情况，确保项目按计划进行，按时、按质完成任务。
总结提高：项目完成后，及时进行总结，吸取教训，分享经验，丰富组织的项目管理数据库或知识库。
本章小结
项目是为实现一个独特目的而进行的临时性任务，项目具有独特性、临时性及需要资源等特性，每个项目都有一个项目发起人并含有不确定性。
项目管理的三项约束是指管理项目的范围、时间和成本这三个维度。
项目管理是指在项目活动中运用相关的知识、技能、工具和技术，以满足项目要求的活动。
利益相关者是指参与项目或受项目活动影响的人。
PMBOK核心知识领域四个：范围管理、时间管理、费用管理和质量管理。因为在这几个方面形成具体的项目目标。
PMBOK辅助知识领域四个：采购管理、人力资源管理、风险管理和沟通管理。因为项目目标的实现是辅助实现的。
范围（产生项目产品所包括的所有工作及产生这些产品经过的所有）过程。
项目范围：指包括什么不包括什么的定义与控制，没有包含在（工作分解结构即WBS）里的工作是不应该做的。

1. 以下哪一项最能表现某个项目的特征©
   A. 运用进度计划技巧
   B. 整合范围与成本
   C. 确定期限
   D. 利用网络进行跟踪
2. （A）就是将知识、技能、工具和技术应用到项目活动，以达到组织的要求
   A.项目管理
   B. 项目组管理
   C. 项目组合管理
   D. 需求管理
3. 项目管理九大知识域是什么
   

2.项目准备和启动

项目建议书 (project proposal )，顾名思义，就是项目立项申请报告。它可以比较简要，也可以比较详尽，而重点是如何向有关的投资方或上级阐述立项的必要性
项目建议书的内容：
项目的背景。
项目的意义和必要性。
项目产品或服务的市场预测。
项目规模和期限。
项目建设必需的条件、已具备和尚不具备的条件分析。
投资估算和资金筹措的设想。
市场前景及经济效益初步分析。
其它需要说明的情况
项目建议书的关键点：
项目能解决那些诟病
项目具备社会效益
项目模式怎样
项目可行性和迫切性
项目建设是否有经济效益
项目建设状况和财务的可行性
可行性分析因素：

可行性分析–成本效益分析方法
回收期法

优点：容易理解，计算简单。
缺点：不能反映投资回收以后的情况，忽略了时间价值。
例1：假设项目最初投资费用是5万元，如果每年净现金流入是2万元，则回收期多少？
净现值法
净现值（Net-Present-Value）:就是未来报酬的总现值减去原先的投入。为正值则采纳，为负值不采纳。
动态回收期法：动态投资回收期=累计的利润净现值开始出现正值的年份数-1+上一年累计的利润净现值的绝对值/出现正值年份的利润净现值（当年挣的钱）

可行性分析方法
技术分析-通过对技术方案或演示模型的比较和分析，判断其技术的成熟性和实用性；最常用、有效的方法是专家评定法。
风险分析-主要是对内部和外部的风险评估，主要对市场风险、技术风险及财务风险等各因素的定量和定性分析为项目决策提供依据。常用方法-定量分析–决策树。画决策树注意：
画决策树时一定按照标准的决策树图形画,不要自创图形 
决策点和状态点做好数字编号
决策树上要标出损益值

决策树法案例
Ⅰ：开发新产品A ,需要追加投资180万元，经营期限5年，此间产品销路好，可获利170万元；销路一般可获利90万元；销路差可获利-6万元；三种情况的概率分别为30%，50%，20%。
Ⅱ：开发新产品B ,需要追加投资60万元，经营期限4年，此间产品销路好，可获利100万元；销路一般可获利50万元；销路差可获利20万元；三种情况的概率分别为60%，30%，10%。

方案A=1700.35+900.55+(-6)0.25=770万元
方案B=1000.64+500.34+200.14=308万
方案A=770-180=590万元 最优。
方案B=308-60=248万元
投标两个阶段：
第一个阶段是参加竞标的供应商在规定的时间内提交投标书。标书包含：可行性研究方案和相关的财务分析
第二个阶段是需求方（客户）对投标书进行评估，得出竞标结果。评估前需要制定相应的评估标准，确保公平合理。如从需求满足、技术能力管理方案和财务预算等
软件项目合同条款合同评审
制定合同 评审合同 签订合同
技术合同软件项目合同主要是技术合同；
技术合同是法人之间、法人和公民之间、公民之间以技术开发、技术转让、技术咨询和技术服务为内容，明确相互权利义务关系所达成的协议；
技术合同有三种环境：需（甲）方环境、供（乙）方环境和内部环境；
技术合同一般包括主合同和合同附件。
技术合同管理是围绕合同生存期进行的
软件开发模型
3种基本类型
以软件需求确定为前提，各项软件活动为线性分布的瀑布模型
以响应变化，紧密沟通合作、快速持续交付有价值软件来满足客户的敏捷开发
快速实现一个可实际运行的系统初步模型，供开发人员和用户进行交流和评审，可快速原型实现模型。
瀑布模型 快速原型 实现模型 增量模型 敏捷开发 极限编程



敏捷开发：是一种思想或方法论， 以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。
极限编程：极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；
例子：开发XP项目是收集用户故事，是一段与技术无关的文本，目的在于提供一些特殊场景的详细描述；而不是估计系统的复杂性。用户故事确认，接着是制定发布计划；确定那些故事需要在哪个版本中实现。
计划；选择要实现的用户故事及其要说明的细节。
编码；实现用户故事。
测试；单元测试。
验收测试：测试成功新功能开发完成，否则，进入下一次迭代。
项目组织结构：职能型，纯项目型，矩阵型
职能型：经营活动按照职能划分成部门。项目功能都在本职能部门内部讨论完成再递交到下一个部门。如果完成期间涉及其他职能部门的问题，只能报告给本职能部门经理，由各职能部门经理进行协调和沟通。
纯项目型：项目经理拥有领导权，项目内所有成员直接向项目经理汇报。每个项目就是一个独立自主单位。它就如同一个子公司那样运作，拥有完整的人员配备-像技术人员，行政人员，财务人员等。
矩阵型：它是职能型和纯项目型的结合体。但是项目内的成员受项目经理和职能经理双重领导。
职能型
纯项目型
矩阵型
软件项目的组织架构
微软组织结构
软件项目经理是整个软件项目的核心和灵魂。一个合格的项目经理必须具备良好的自身素质和较强的管理、技术能力。
软件团队建设
团队合作的指导方针
作为一名团队领导，我将：
避免团队目标向政治问题妥协；向团队目标显示个人的承诺；不用太多优先级的事物冲淡团队的工作；公平,公正的对待团队成员；愿意面对和解决与团队成员不良表现有关的问题；对来自员工的新思维和新信息采取开放的态度。
作为一名团队成员，我将：
展示对于个人角色和责任的真实理解；展示目标和以事实为基础的判断；和其他团队成员有效的合作；使团队目标优先于个人目标；展示投身于任何项目成功所需的努力的愿望；愿意分享信息、感受和产生适当的反馈；当其他成员需要时给与适当的帮助；展示对自己的高标准要求；支持团队的决策；展示直接面对重要问题的勇气和信念；以为团队的成功奋斗的方式体现带头作用；对别人的反馈做出积极的反映。
QA与QC
QA(Quality Assurance-质量保证，也是质量管理的一部分，它致力于提供质量要求会得到满足的信任。
QA通过建立和维持质量管理体系来确保产品质量没有问题，是过程质量审计者。在软件开发过程中，QA也就是质量组成员。QA所关注的是软件产品质量保证体系。
QC-质量控制，检验产品的质量，保证产品符合客户的需求；是产品质量检查者。在软件开发过程中，QC其实就是测试组成员。QC所关注的是产品，而非系统（体系）。
软件项目相关利益人
其实就是软件项目干系人（stakeholders），是指积极参与项目或其利益在项目执行中或成功后受到积极或消极影响的组织和个人。
梦断代码Chandle项目技术牛人痴迷技术，没有从客户的角度想问题。也是导致项目失败的重要原因之一。
做好相关利益人的分析和管理：
识别-》分析-》管理软件项目相关利益人
两矩阵:
影响力/利益矩阵是根据利益相关者与其持有的影响力大小的关系，以及从何种程度上表现出对组织战略的兴趣，对其分类。称为影响力/利益矩阵。
SWOT矩阵：SWOT分析法是用来确定企业自身的竞争优势、劣势、机会和威胁，从而将公司的战略与公司内部资源、外部环境有机地结合起来的一种科学的分析方法

项目启动会

3.项目计划

1.（A ）是软件项目的一个突出的特点，也是软件项目最为普遍的一个特点。
A.需求变更 B. 暂时性 C. 阶段性 D. 约束性
2.项目建议书是（C）阶段开发的文档 A.项目执行 B.项目结尾 C.项目初始 D.项目计划

什么是项目计划？
计划是事先确定项目的目标和实现目标所需要的原则、方法、步骤和手段等完整方案的管理活动。
软件项目计划（Software Project Planning）的目的是制定一套软件项目实施及管理的解决方案，其主要工作包括确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的（时间）进度计划、成本和预算计划、人力资源计划等。
编制计划----甘特图
软件项目计划的作用
指导软件项目实施 得到项目相关干系人的承诺 获得资源的承诺
明确项目人员的分工和工作责任 及早了解项目存在的问题和风险 获得组织在项目预算上的承诺
是软件项目实施结果评估的依据 软件项目实施过程的文档化
项目计划的内容
项目计划内容可归结4个W+1个H为:why ,what ,how,when who；
其中why ,what已经在可行性分析中阐述过了。计划内容主要包括以下几方面：
目标 策略 流程 标准 质量
进度安排：预算 资源 风险 配置管理
项目计划内容及其关系

项目计划主要内容说明
目标与范围 ：范围规划、定义及其任务工作分解结构
项目估算：采用恰当的评估技术，完成资源估算、活动持续时间估算以及费用估算
风险：一般性风险和特定产品的风险都应该被系统化地标识出来，并建立风险条目检查表
资源 ：人员、硬件、网络、软件等需求和安排，还包括项目组成员的角色、责任和具体分配的任务
进度安排：任务排序、里程碑设置等
跟踪和控制机制：QA、变更控制、项目成员报告等
项目计划的方法
滚动计划方法
滚动计划方法一种动态编制计划的方法，按照“近细远粗”的原则制定一定时期内的计划，然后按照计划的执行情况和环境变化，调整和修订未来的计划，并逐期向后移动，把短期计划和中期计划结合起来的一种计划方法。
滚动计划方法的要点
分而治之：分为多个阶段，针对不同的阶段制定不同的计划。
逐步求精：随着时间的推移，预测计划逐步变成实施计划。
动态规划：以计划的“变（调整）”来主动适应用户需求和软件开发环境的变化，即“以变应变”。
和谐过渡：可以解决生产的连续性与计划的阶段性之间的矛盾
滚动计划方法的实施

WBS方法
WBS方法是（Work Breakdown Structure，工作分解结构）一种将复杂的问题分解为简单的问题，然后再根据分解的结果进行计划的方法
关注项目目标和澄清职责，并防止遗漏项目的可交付成果
建立可视化的项目可交付成果，以便估算工作量和分配工作
改进时间、成本和资源估计的准确度
为绩效测量和项目控制定义一个基准，容易获得项目人员的承诺
辅助分析项目的最初风险、沟通清晰的工作责任
为其他项目计划的制定建立框架或依据
WBS要求和原则
某项具体的任务应该在一个工作包且只能在一个工作包中出现
WBS中某项任务的内容是其下所有WBS项的总和一个工作包只能由一个人负责
任务的分解，尽量与实际执行方式保持一致。
分解合理，具有良好的稳定性和适应性
鼓励项目团队成员积极参与创建WBS
所有成果需要文档化
WBS步骤
分解工作任务
定义各项活动/任务之间的依赖关系
安排进度和资源


网络计划技术 第5章，将详细讨论网络计划方法
网络计划方法是一种应用网络模型直观地表示软件开发众多工作（工序）之间的逻辑关系与时间关系，对完成软件工程项目所需时间、费用、资源进行求解和优化的计划方法，其基本类型是关键路线法/计划评审技术（CPM／PERT）。
自学）3.4 如何有效地完成项目计划 3.5项目的具体计划
计划各项内容的制定
确定项目范围 策略制定 资源计划 进度计划 成本计划 风险计划 质量计划
软件项目范围
软件产品规范，即一个软件产品应该包含哪些功能特性，这就是产品需求文档（Product requirement document，PRD）所描述的。更具体的要求就是功能规格说明书（Functional Specification），但这是在计划过程中或之后产生。一般在确定PRD的过程中，就开始进行项目计划。
项目工作范围，即为了交付具有上述功能特性的产品所必须要做的工作。工作范围在一定程度上是产生项目计划的基础。
资源计划
项目资源计划，是指通过分析和识别项目的资源需求，确定出项目需要投入的资源。
资源计划包括人力资源计划、软硬件资源计划。
项目资源计划重点在人力资源计划，采用有效的方法进行人力资源计划。
实际的人力资源计划的模型

进度计划制定原则
项目的实际参与人员制定进度
尽可能地先安排难度高的任务，后安排难度低的事
进度前面紧，后面松，比较好
项目进度中都会设置若干个里程碑
进度表中必须留有缓冲时间
发现项目应交付的期限不合理，应调整进度
当需求发生变化时，就要重新评估进度表

成本构成
软件项目成本分为直接成本和间接成本
直接成本是项目本身的任务所引起的成本，包括为该项目购买的设备和软件工具、参与该项目工作的人员工资等。间接成本是许多项目共享的成本，例如办公楼的租金、水电费用、公司管理费用、网络环境和邮件服务等各种间接费用。
成本计划
费用预算，在成本估算基础之上，针对各项成本来估算可能产生的其他费用，从而确定费用预算
费用控制是为了保证实际发生的费用低于预算。一般会采用阶段性控制和单项费用控制相结合的方法，更关键是需求变更控制和质量控制。
风险计划
风险识别、风险评估和风险对策计划
风险计划并不是在资源计划、进度计划和成本计划之后再制定，而是和这些计划同时进行，因为软件项目的风险会来自于各个方面，包括人力资源风险、进度风险和成本风险等，而且在如何应对风险或针对风险采取相应的对策时，对资源计划、进度计划都有影响
质量计划内容
质量目标，包括功能特性和非功能性特性的质量要求；
质量目标分解，总体质量目标分解到各个阶段或各项任务相关标准和规范
组织保证机制，包括确定责任人、质量保证人或管理人员质量属性满足的优先级和成本效益分析
质量控制策略，包括测试覆盖率、代码评审的频率等；
质量特性的相互依赖关系的分析，确定质量特性的优先级
潜在的质量问题分析，并找出应对策略
流程评审、测试计划和测试用例评审等方面的具体要求；
其它质量保证或控制措施、质量相关活动。
小结
编制计划包括：实施范围、定义递交的工作成果、主要的风险、实施的（时间）进度计划、成本和预算计划、人力资源计划等。
项目范围：是指开发项目产品所包括的工作以及产生这些产品所用的过程。项目干系人必须在项目要产生什么样的产品方面达成共识，也要在如何生产这些产品方面达成一定的共识。
计划内容：项目计划内容可归结4个W+1个H
计划方法：滚动计划方法、WBS方法、网络计划技术
WBS分解将一个项目分解为更多的工作细目或者子项目，使项目变得更小，更易管理，更易操作。这样可以提高估算成本，时间和资源的准确性，使工作变得更易操作，责任分工更加明确。任务分解的规模和数量因项目而异；对于项目最底层的工作要非常具体，任务分解结果必须有利于责任分配；WBS分解的规模和数量因项目而异；参考类似项目的WBS；最低层是可控的和可管理的，但是不要过细，最好不要超过7层；软件项目推荐分解到40小时的任务。

4.项目估算

项目管理知识体系（PMBOK）包括哪10个知识领域？
项目集成管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理、项目人力资源管理、项目沟通管理、项目风险管理、项目采购管理、项目干系人管理
请简述项目管理的5个过程组及其关系？
（1）启动过程组：主要是确定一个项目或一个阶段可以开始了，并要求着手实行；定义和授权项目或者项目的某个阶段。
（2）计划过程组：为完成项目所要达到的商业要求而进行的实际可行的工作计划的设计、维护，确保实现项目的既定商业目标。计划基准是后面跟踪和监控的基础。
（3）执行过程组：根据前面制定的基准计划，协调人力和其他资源，去执行项目管理计划或相关子计划。
（4）控制过程组：通过监控和检测过程确保项目达到目标，必要时采取一些修正措施。集成变更控制是一个重要的过程。
5）收尾过程组：取得项目或阶段的正式认可并且有序地结束该项目或阶段。向客户提交相关产品，发布相关结束报告，并且更新组织过程资产并释放资源。
关系：各个过程组通过其结果进行连接，一个过程组的结果或输出是另一个过程组的输入。其中，计划过程组、执行过程组、控制过程组是核心管理过程组。
2.项目管理过程5个过程组可以对应到PDCA循环中，（C ）过程组与PDCA循环中的检查和行动相对应。即计划（Plan）、执行（Do）、检查（Check）、处理（Act）。
A.规划 B.执行 C.监控 D.收尾
3.在项目招投标阶段，甲乙双方的主要任务分别是什么？
甲方在招投标阶段的主要任务是：招标书定义、供方选择、合同签署
乙方在招投标阶段的主要任务是：进行项目选择。
4、招标书主要包括那几部分内容？
招标书主要包括三部分内容：技术说明、商务说明和投标说明。
技术说明主要对采购的产品或者委托的项目进行详细的描述，商务说明主要包括合同条款。投标说明主要是对项目背景、标书的提交格式、内容、提交时间等做出规定。
知识点
1.任务分解是将一个项目分解为更多的工作细目或者子项目，是项目变得更小、更易管理、更易操作。
2. 一般来说，进行项目分解时，可以采用清单或图表两种形式来表达任务分解的结果。
3.WBS的全称是任务分解结构Work Breakdown Structure。
4.WBS最底层次交付成果是工作包work package。
判断题
1.WBS提供了项目范围基线。（√）
2.一个工作包可以分配给另一个项目经理去完成。（√）
原文：工作包应当由唯一主体负责，可以分配给另外一位项目经理通过子项目的方式完成。
3.如果开发人员对项目比较熟悉或者对项目大局有把握，开发WBS时最好采用自底向上方法。（×）
4.对于一个没有做过的项目，开发WBS时可以采用自底向上方法。（√）
5.在任务分解结果中，最底层的要素必须是实现项目目标的充分必要条件。（√）
6.任务分解是将一个项目分解为更多的工作细目或者子项目，是项目变得更小、更易管理和操作。（√）
1.试写出任务分解的方法和步骤。
答：任务分解的基本步骤：1） 确认并分解项目的组成要素(WBS编号)。 2） 确定分解标准，按照项目实施管理的方法分解，而且分解的标准要统一。 3） 确认分解是否详细，是否可以作为费用和时间估计的标准，明确责任。 4） 确定项目交付成果（可以编制WBS字典）。 5） 验证分解正确性。验证分解正确后，建立一套编号系统。
试写出任务分解的方法
1） 模板参照方法 2） 类比方法 3） 自上而下 4）自下而上
2**.检验任务分解结果的标准是什么？**
答：检验任务分解结果的标准有： 1）最底层的要素是否是实现目标的充分必要条件 2）最底层要素是否有重复的 3）每个要素是否清晰完整定义 4）最底层要素是否有定义清晰的责任人5）是否可以进行成本估算和进度安排
为什么项目要估算？
软件估算对进度与成本控制非常重要！ 只有准确的估算软件的功能，才能比较精确地估算出软件的成本，并制定出合理的进度计划。解决三个问题
1、需要多长时间？时间估算2、需要多少工作量？工作量估算 ->>> 规模估算3、需要多少人？人员资源估算
4.1 项目估算的挑战（自学）
4.2 项目估算的基本内容
注意：首要确定软件范围
从产品的范围描述开始， 在“范围”被“界定”前，不可能得出一个有意义的估算。
软件范围描述了将被处理的数据和控制，功能、性能、约束、接口及可靠性
成本和进度估算都是以面向功能的基础的。
项目估算的基本内容
规模估算 (size estimation)：如代码行数、功能点数、对象点或特征点等
工作量估算(workload ～)：任务分解并结合人力资源水平来估算
进度估算(schedule ～)：通过工作量估算、有效资源分配等对项目进度给出正确的评估。
风险估算(risk ～)：一般通过 风险发生的“概率和所带来的损失”来评估风险。
其他估算，如需求稳定因子、资源利用效率、文档复审水平等
估算的基本内容及其关系

4.3 基本估算方法
1)分解方法，采用“分而治之”的策略，对软件项目进行分解，再采用逐步求精的方式进行估算，最后通过累加获得整体的估算结果。
2)算术模型，通过估算模型来产生估算。
3)专家判断或经验法，如德尔菲法(Delphi technique)。
4)比例法是比较科学的一种传统估算方法，是基于类比的估算技术，根据过去类似的项目，直接进行类比获得当前项目的估算结果。
WBS估算法
自顶向下估算模式，首先估算出项目一级的工作量，然后层层往下分摊，把上一层工作量分摊到下一层的阶段、活动或任务。通常使用 FPA方法或 COCOMO II 来估算项目一级的工作量。
自底向上估算模式，要求先估算出底层任务/活动一级的工作量，然后层层向上汇总到阶段和项目级。通常使用 QIF 估算方法或专家判断来估算项目低层 WBS 元素的工作量。
基于量化的影响因子（QIF, Quantitative Influencing Factors）
软件项目分解 5.WBS举例:信息网络工程


4.4 软件规模估算
4.4.1 德尔菲法(Delphi的专家)

德尔菲法也叫专家法。（PERT法-计划评审技术）
比如估计进度：每个人估计三个值（最大a，可能b，最小c），然后求其平均值。E=(1+4b+c)/6

例子: 项目经理正在进行一个媒体信息查询系统项目的估算，他采用的delphi的成本估算方法 ，邀请2位专家估算，第一个专家给出1万， 8万，9万的估算值，第二个专家给出了4万， 6万 ，8 万的估算，计算这个项目的成本估算值是多少？
第一个专家E1=（1+48+9）/6=42/6=7
第二个专家E2=（4+46+8）/6=36/6=6
期望值E=（E1+E2）/2=13/2=6.5
4.4.2 代码行估算方法
LOC指所有可执行的源代码行数，包括控制语句、数据定义、数据类型声明、等价声明、格式声明等
在生产效率的研究中，LOC又具有一定的误导性。如果把LOC和缺陷率等结合起来看，会更完整些
4.4.3 功能点分析方法
功能点分析法(FPA)是在需求分析阶段基于系统功能的一种规模估算方法，其国际标准
Alain Abran等人提出的全面功能点法 软件估算共同协会(COSMIC)提出的COSMIC-FFP方法
功能点计算元素
外部输入数(EI)：计算每个用户输入
外部输出数(EO)：计算每个用户输出(报表、屏幕、出错信息等)
内部逻辑文件(ILF)：计算每个逻辑的主文件，如数据的一个逻辑组合
外部接口文件(EIF)：计算所有机器可读的接口，如磁带或磁盘上的数据文件。
外部查询数(EQ)：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应

4.4.4 标准构件法
软件由若干不同的“标准构件”组成，这些构件对于一个特定的应用领域而言是通用的。项目计划者估算每一个标准构件的出现次数，然后使用历史项目数据来确定每个标准构件交付时的大小。
例如，一个信息系统的标准构件是子系统、模块、屏幕、报表、交互程序、批程序、文件、LOC以及对象级的指令。
在实际估算工作中，一般先采用分解的方法，将项目分解到某个层次上，然后再采用对比分析方法和经验方法。任何估算方法都要结合实际来考虑。
4.4 工作量估算
COCOMO （方法）或 模型
构造性成本模型(COCOMO：constructive cost model)是一种精确、易于使用的基于模型的成本估算方法：
1)基本COCOMO模型，静态单变量模型，用已估算出来的源代码行数(LOC)为自变量的函数来计算软件开发工作量。
2)中间COCOMO模型，在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。
3)详细COCOMO模型，包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。
COCOMO基本变量
DSI(源指令条数)，定义为代码行数，包括除注释行以外的全部代码。若一行有两个语句，则算做一条指令。
KDSI即为千代码行数。
MM(估算单位为人月)表示开发工作量。
TDEV(估算单位为月)表示开发进度，由工作量决定。
COCOMO模型影响因素
产品因素：软件可靠性、数据库规模、产品复杂性。
硬件因素：执行时间限制、存储限制、虚拟机易变性、环境周转时间。
人的因素：分析员能力、应用领域实际经验、程序员能力、虚拟机使用经验、程序语言使用经验。
项目因素：现代程序设计技术、软件工具的使用、开发进度限制
COCOMO方法实例
例1.如果某软件公司正在进行一个项目，预计有50KLOC的代码量，项目是中等规模的半嵌入型的项目，采用中等COCOMO模型，项目属性中只有可靠性为很高级别（即取值为1.3），其他属性为正常（书上说，正常就是1），计算项目是多少人月的规模，如果是2万元/人月，则项目的费用是多少？
答：Effort=a（KLOC）bF 查表a=3，b=1.12，F=1
Effort=3.0501.121.31=311.82（人月）
所以项目的费用为2 Effort=623.64万元
资源估算基本过程
根据WBS进行估算 由工作量和开发周期来估算
资源特征描述 资源分配给任务 定义项目角色 人员分配
根据WBS进行估算
根据WBS的分解结果来估算资源，主要是一些独立的工作应该由独立的人员去完成，而减少人员沟通成本，减少人员之间的依赖性，并使人员的经验和特长得到发挥，力求达到最高的工作效率。
由工作量和开发周期来估算
人员数量= 工作量估算（人日）/工期估算（日）
在不同的阶段所需要的人力资源是不同的，会随时间变化

资源特征描述
每一类资源都由四个特征来说明：
资源描述、可用性说明、需要该资源的时间、及该资源被使用的持续时间。
资源的可用性必须在开发的最初期就建立起来，包括人力资源、软硬件和可复用的构件。
资源分配给任务
在进行资源分配的时候，要对资源的可支配时间进行充分的考虑：
完全可分配资源。
外部资源，指项目外非直接可支配的资源。
多项目资源，多个项目共享的资源。
特殊技能资源。
备用资源。
项目角色职能确定

人员分配

4.7 工期估算和安排*
常用方法是专家(经验）估算法、基于历史数据的类比法
三点估算法（也叫PERT法）工期估算。
PERT:(Program Evaluation and Review Technique,计划评审技术）。
对于指定的估计单元（可能是规模、进度、工作量等），由直接负责人给出估计结果，估计结果由3个值构成：最小值、最大值、最可能值，通过计算公式：
理论基础：假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。
计划时间 =（T乐观 + 4×T可能 + T悲观）/6
标准差=（T悲观 - T乐观）/6 方差=标准差的平方
例子：A公司的某项目即将开始，项目经理估计该项目10天即可完成，如果出现问题耽搁了也不会超过20天完成，最快6天即可完成。根据项目历时估计中的三点估算法，你认为该项目的历时为（1），该项目历时的估算标准差为（2）。 （1）A．10天 ** B．11天 C．12天 D．13天 （2）A．2.1天 B．2.2天 ** C．2.3天 D．2.4天

用PERT公式计算出来的是完成某活动的平均工期，即有50%的可能性在该工期内完成。
用正态统计分布图，工期落在平均工期1个标准差范围之内的概率是68.26%,2个标准差之内的概率是95.46%,3个标准差的概率是99.73%,这三个概率必须要记住，如果我们用1个标准差来估算工期，那工期就是在平均工期加/减1个标准差的范围内。其他一样

完成活动A悲观估计36天，最可能估计21天，乐观估计6天，求该活动的期望完成时间、标准差。（根据标准差和活动的范围确定标准差的区间，然后判断概率。）请问：
（1）A在16天到26天内完成的概率是多少？
（2）在16天内完成的概率是多少？
（3）在21天内完成的概率是多少？
（4）在21天之后完成的概率是多少？
（5）在21天到26天之间完成的概率是多少？
（6）在26天完成的概率是多少。
带入公式计划PERT估算结果为：（36+21*4+6）/6=21
带入公式计算标准差为：（36-6）/6=5
分析（1）根据正太分布：16(21-5)~26(21+5)这个区间范围内的概率都是68.26%。注：在正负一个标准差的概率有 68.26%算出了16~26这个区间的概率，用100%-这个区间的概率68.26%即得到了不在这个区间的概率（100%-68.26%=31.74%），算出31.74%之后，再用个概率除以2即得小于16天和大于26天分别所对应的概率（31.74%/2=15.87%）
（2）在16天内完成的概率是多少？——15.87%（(100%-68.26)/2=15.87%）
（3）在21天内完成的概率是多少？——50%（μ=21，(68.26/2%+15.87%)=50%）
（4）在21天之后完成的概率是多少？——50%（μ=21，所以正好是50%）
（5）在21天到26天之间完成的概率是多少？——68.26%/2=34.13%（正负一个标准差的概率有 68.26%的一半）
（6）在26天完成的概率是多少。——84.13%（100%-15.87%=84.13%或者50%+68.26%/2=84.13%）
4.8 成本估算
**4.8.1 成本估算方法 **
同样可以使用专家评估办法、经验法、比例法和WBS方法等.FPA(Function Ponint Analysis)计算成本

4.8.2 学习曲线

5.项目进度和成本管理

进度、成本管理的重要性

软件估算解决三个问题 1、需要多长时间？2、需要多少工作量？3、需要多少人？
什么是项目活动？
项目活动就是把项目的工作量分解为易管理的具体任务，而每一项任务都要有明确的时间和资源的限制，它是项目进度表编制的基础。
如何标识项目活动？
两条主线：以酒店管理系统开发为例
软件开发周期

软件开发功能点

5.2　确定项目活动的次序
前导和后续活动
活动A是前导活动，B是A的后续活动。活动框的前端是开始点，后端是结束点。
确定项目活动的次序
任务(活动)之间的关系
活动之间的3种关系
结束后才开始（Finish-Start），这是一类最普遍也是最常用的活动类型。项目中的大多数活动之间都是这种关系。
开始后才开始（Start-Start），是指一个活动开始后，另一个活动才能开始。这经常表示某种并行而且具有一定依赖关系的活动。
结束后才结束（Finish-Finish），一个活动必须在另一个活动结束之前才能结束。这也经常表示某种并行，但其产出物具有一定依赖关系的活动。
确定项目活动的次序—网络图
网络图——展示项目中的各个活动以及活动之间的逻辑关系； 网络图是活动排序的一个输出；网络图可以表达活动的历时
常用网络图 :
PDM:节点法（前导图法） (单代号)网络图
ADM:箭线法 (双代号)网络图
甘特图法:（横道图或条状图）
里程碑图：
网络图特点
在网络图中一个活动用一个方框、节点或者其他方式表示
每一个活动被各种关系线相连接着
将项目中的各个活动的逻辑关系表示出来
网络图开始于一个任务、工作、活动、里程碑
网络图结束于一个 任务、工作、活动、里程碑
有些活动前置任务或者后置任务.
软件项目进度计划
1：PDM(Precedence diagram )-前导图法
构成PDM网络图的基本特点是节点(Box)
节点(Box)表示活动(工序,工作)
用箭线表示各活动(工序,工作)之间的逻辑关系.
可以方便的表示活动之间的各种逻辑关系
没有时标
在软件项目中PDM比ADM更通用
PDM网络图的关系

软件开发示例

确定项目活动的次序
2：ADM（ Arrow diagram ）
ADM也称为AOA （activity-on-arrow）或者双代号项目网络图
在ADM网络图中,箭线表示活动(工序\工作)
节点Node（圆圈:circle）表示前一道工序的结束,同时也表示后一道工序的开始
只适合表示结束-开始的逻辑关系
可以有时标
箭线图法（ADM） 代码评审活动为例

ADM图例

3：甘特图又称（横道图或条状图）：以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。
特点：显示基本的任务信息。
可以查看任务的工期、开始时间和结束时间以及资源的信息。
只有时标，没有活动的逻辑关系。
有两种表示方法（棒状、三角形）。
甘特图-实例

4：里程碑图 完成阶段性工作的标志

5.3关键路径分析
关键路径和关键活动
在项目网络中有一条路线的时间最长。这条路线决定着项目的工期时间，称之为关键路径。位于关键路径上的活动就是关键项目活动。请找出下图的关键路径和关键活动。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RgHigMZs-1686550368799)(https://cdn.nlark.com/yuque/0/2023/png/22334367/1686467173831-75072671-8c97-4a64-89d0-2f9a0c6af89d.png#averageHue=%23000000&clientId=u40bbfb26-b053-4&from=paste&height=192&id=u04dbb05d&originHeight=429&originWidth=864&originalType=binary&ratio=1.25&rotation=0&showTitle=false&size=17462&status=done&style=none&taskId=u974d6cd8-eeb5-4820-a579-2cac08976ba&title=&width=386)]
活动缓冲期 （浮动时间）
任何关键活动的延迟都会导致项目预估工期的延期，所以关键活动的缓冲期都是0。(下图A,B,E,G,H是关键活动，他们缓冲期为0）
其他非关键活动的缓冲期是如何计算的呢？见P132
关键路径的时间基本术语
最早时间(Early start)
最晚开始时间(Late start)
最早完成时间(Early finish)
最晚完成时间(Late finish)
自由浮动（Free Float）
总浮动（ Total Float）
超前(Lead)
滞后(Lag)
缓冲时间（浮动时间(Float)
浮动时间是一个活动的机动性,它是一个活动在不影响其它活动或者项目完成的情况下可以延迟的时间量
Float>0：时间安排比较合理
Float=0：比较紧张
Float<0：项目进度会推迟
自由浮动（Free Float） 在不影响后置任务最早开始时间本活动可以延迟的时间
总浮动（Total Float） 在不影响项目最早完成时间本活动可以延迟的时间
2. 关键路径法计算公式及相关规则
例题1： 活动A历时为3天，开始于星期一（4号），后置活动B与活动A具有完成-开始的依赖关系。完成-开始关系有3天的滞后，而且活动B历时为4天,星期天为非工作日,从这些数据可以得出什么结论（ B）
A) 两项活动的总历时为8天
B) 活动A开始到活动B完成之间的日历时间(calendar time)是11天
C) 活动B完成是星期三,14号
D) 活动A开始与活动B完成之间的日历时间14天
例2：如果在一个项目网络图中，任务A有15天的自由浮动和25天的总浮动，但是任务A的最早开始时间延误了30天，那么这对项目意味着什么？（ A ）
A) 任务A的下一个任务的最早开始时间将延迟15天
B) 任务A的工期将缩短15天
C) 项目的完成时间延长25天
D) 对项目没有影响
自由浮动时间 = 后面活动的最早开始时间 - 此活动的最早结束时间
总浮动时间 = 自己的最晚开始时间 - 自己的最早开始时间
5.4网络模型的遍历
通过执行网络模型的遍历来计算出每个活动最早开始和最早结束时间、最迟开始和最早结束时间。

5.4.1 正向遍历5.4.2 反向遍历
网络计划技术正向计算
目的：计算最早时间
方法：根据逻辑关系
方向：从网络图始端向终端计算
第一个任务的开始为项目开始时间
任务完成时间为开始时间加持续时间
后续任务开始时间根据前置任务的时间和搭接时间而定
多个前置任务存在时，根据最迟的任务时间定
正向遍历
正向遍历就是按照活动开始到活动结束的顺序对网络中的每个活动进行遍历。通过执行正向遍历来计算出每个活动最早开始和最早结束时间。

网络计划技术反向计算
反向计算 – (自右向左,减法,取小值)
目的：计算最晚时间
方法：根据逻辑关系
方向：从网络图终端向始端计算
最后一个任务的完成时间为项目完成时间
任务开始时间为完成时间减持续时间
前置任务完成时间根据后续任务的时间和搭接时间而定
多个后续任务存在时，根据最早的任务时间定
反向遍历和正向遍历相反，就是按照活动结束到活动开始的倒序对网络中的每个活动进行遍历。通过执行反向遍历来计算出每个活动最迟开始和最迟结束日期。

有关时差定义
时差（slack):在不影响项目最后完成时间的前提下，某活动可以推迟开始的最大时间量。
总时差（total slack,TS)：在不影响项目最后完成时间的前提下，项目可以推迟开始的最大时间量。 TS=LF-EF或LS-ES
总时差—total slack
总时差为负值，表明完成项目缺少时间余量，需要加速完成。
工期总和：7+5+3
要求20天完工，三项活动可延迟5天
确定关键路径
确定关键路径：找出那些具有最小时差的活动
总时差 = 最晚开始时间 - 最早开始时间 = 最晚完成时间 - 最早完成时间
时差等于0和小于0的任务组成关键路径
可以改变确定关键路径的条件
那些具有正总时差的路径是非关键路径。
关键路径？

路径1：A-D-H-J 长度=1+4+6+3=14天
路径2：B-E-H-J 长度=2+5+6+3=16天
路径3：C-G-I-J 长度=3+6+2+3=14天
由于关键路径是整个网络图中最长的路径，故路径2，即 B-E-H-J 是项目的关键路径

已知某项工作作业顺序及时间如表所示，绘制网络图，并根据关键路径确定工程周期，进行活动时差估算。



计算ES、EF、LS、LF以及时差，找出关键路径该项目能否在30周内完成？


压缩工期
压缩关键路径的工期是指在现有的资源、成本、任务不变的前提下，针对关键路径进行优化，结合资源、成本、时间因素、活动的可调度等因素对整个计划进行调整，直到关键路径所用的时间不能再压缩为止，得到最佳时间进度计划。
准关键活动标识的必要性
非关键活动可能成为关键活动。关键路径随之改变。网络中各活动缓冲期变化。
准关键活动的识别
缓冲期小于它们自身周期的10%，如果不加关注，这样的活动缓冲期比较容易很快用完。
活动的路径上只有一、两个活动是非关键活动。这一两个活动延迟时间超过缓冲期的时候，它们就变成了关键活动。
一些有依赖关系的活动，由于其依赖关系的特殊性，没有100%的把握保证之前的活动（前导活动）准时完成，那么这类活动也需要定期或者及时关注。以防它们变成关键活动
根据项目的情况来识别。
5.5里程碑
什么是里程碑？
里程碑原指的是标志公路及城市郊区道路里程的碑石。项目管理中将进度时间表上一些重要的时间检查点设置为里程碑，以便及时掌控项目进度。软件开发生命周期的重要里程碑

建立里程碑5个步骤
1．设立合理的里程碑检查点
2. 制定里程碑的完成目标
3. 明确里程碑的验证标准
4. 确认里程碑的利益相关人
5. 标识里程碑的进度百分比
里程碑设定表举例

管理里程碑
要想有效管理里程碑，应该注意几个方面：重点关注。提前定期检查。及时总结。.
特效武器
“银弹”并不存在，在实践中去发现问题、解决问题，总结经验、规律和方法，才是最有效的途径。
5.6进度计划编制
制定进度表
制定软件项目进度计划，一般需要划分两个阶段进行：
在软件产品需求范围确定之前的初步进度时间表。
在软件产品需求范围确定之后的详细进度时间表。
进度计划编制的内容
项目具体活动及其相互依赖关系的活动。
每一具体活动的计划开始日期和期望完成日期。
活动负责人。
资源的安排。
备用的进度计划。
进度风险估计。
进度编制策略十要点

1. 重视与客户的沟通
2. 进度计划最好按需制定。
3. 项目组成员共同参与制定项目进度计划
4. 任务分解与并行化
5. 任务、人力资源、时间分配要与进度相协调
6. 项目的工作安排一定要责任到人。
7. 工作量分布要合理
8. 充分利用一些历史数据。
9. 考虑相关风险，计划意外事故缓冲时间
10. 制定和使用进度计划检查清单

进度编制方法
常用的有；
关键路径法（CPM）（已讲）
计划评审技术PERT（第4章已讲）
甘特图（已讲）
表格表示法
计划评审技术---- PERT估算
1、简单的PERT估算 假设软件规模满足正态分布。
只需估算两个量：其一是软件可能的最低规模a;其二是软件可能的最大规模b.
该软件的期望规模：E=(a+b)/2
估算值的偏差为：σ=(b-a)/6
注：a和b在软件实际规模在a和b之间的概率为0.997.
2. PERT较好估计方法：
基于正态分布和软件各部分单独估算方法，方法是一种基于统计原理的估计方法，是一种简单易用、实效性强的软件估计方法。
对于指定的估计单元（可能是规模、进度、工作量等），由直接负责人给出估计结果，估计结果由3个值构成：最小值、最大值、最可能值，
通过计算公式：期望值 =（最大规模 + 4 最可能规模 + 最小规模）/ 6 （根据给出的三个值，推算出来最有可能接近实际值的规模。 ）
标准偏差=（最大规模 - 最小规模）/6 得到估计的结果。（[ 期望值 - 标准偏差，期望值 + 标准偏差 ] 是一个可以接受的规模估计范围，如果你的最终实际值能够落到该范围内，则可以被认为你的估计是成功的。初期该范围可以较大，随着估计的不断精确，该范围应该逐渐被有意识的减少以求得更准确的估计。 ）
Pert法
Pert法的理论基础是假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。PERT可以估计整个项目在某个时间内完成的概率。



3：甘特图法
4：表格表示法
用表格来表示各个活动历时和相互之间的依赖关系。

进度表审查和修改
进度计划审查可以按照以下几个步骤进行：
进度计划的单元模块评审；
进度计划的完整评审；
修改项目进度计划；
批准项目进度计划。
5.7进度和成本控制
软件项目跟踪控制过程
项目进度、成本、资源控制
根据跟踪采集的进度、成本、资源等数据，并与原来的基准计划比较，对项目的进展情况进行分析，以保证项目在可以控制的进度、成本、资源内完成。

项目性能分析方法
图解控制法
能清楚确定项目状况，但没有量化信息
进度—甘特图
成本—累计费用曲线图
人力物力资源—资源载荷图
挣值分析法（盈余分析法、已获取价值分析法） ——Eared Value Analysis
利用成本会计评估项目进展情况的一种方法，可以提供更多量化的信息
图解控制法－图例

挣值分析原理
挣值分析是在对范围、进度和成本进行综合测量的基础上评价项目绩效的一种方法。它涉及每项工作的3个关键值：
计划值（PV）在规定的时间内在工作上将要花费的获得批准的成本估算部分
实际成本（AC）在规定时间内完成工作所花费的实际成本（直接和间接成本的总额）
挣值（EV）实际完成工作的价值
这3个值的综合使用可以提供评价工作绩效好坏的尺度。
最常用的尺度是：成本偏差（CV）=EV-AC 进度偏差（SV）=EV-PV
CV和SV这两个值，可以转化为效率指示器，反映任何工作项的成本与进度计划绩效。
成本绩效指数（CPI）=EV/AC
进度绩效指数（SPI）=EV/PV
CPI被广泛用于预测完工时的项目成本。SPI有时与CPI一起被用于预测项目完工估算。
完工估算（完成全部工作所需的成本）的计算公式如下：EAC=总预算/CPI or EAC=AC-（总预算-EV）/CPI
通过一个例子来介绍挣值分析的原理
【例子】：某项目中的某可交付成果，成本总预算是13万元，要求10周内完成。该可交付成果包括3个工作包，成本预算分别是：工作包1：2万元；工作包2：10万元；工作包3：1万元。

软件项目跟踪控制过程
分析未来趋势一切顺利：AC,EV,PV,应该重合或接近重合*
项目在控制下按照计划进行： AC, 接近PV
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aXlxGnqA-1686550368811)(https://cdn.nlark.com/yuque/0/2023/png/22334367/1686478761608-438ea2df-c025-4695-8080-07c0abc9720f.png#averageHue=%23fbfaf8&clientId=u40bbfb26-b053-4&from=paste&height=246&id=u62482d4c&originHeight=503&originWidth=975&originalType=binary&ratio=1.25&rotation=0&showTitle=false&size=85967&status=done&style=none&taskId=u17756340-7ad0-4e7f-810b-d02244856a9&title=&width=477)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9RK9ZLls-1686550368812)(https://cdn.nlark.com/yuque/0/2023/png/22334367/1686479013005-2519065d-6f82-48ce-9795-69162e71bd86.png#averageHue=%23f9f8f7&clientId=u40bbfb26-b053-4&from=paste&height=211&id=uc0187f13&originHeight=592&originWidth=902&originalType=binary&ratio=1.25&rotation=0&showTitle=false&size=100261&status=done&style=none&taskId=uaafa850e-2ee5-4866-bdde-d6c133dba16&title=&width=322)]

项目完成的预测时间 SAC(Schedule At Completion )=完成时的进度计划/SPI


5


**项目风险的跟踪控制 **
实施和跟踪风险管理计划
确保针对风险策略正在合理使用
监视剩余的风险和识别新的风险，
收集可用于将来的风险分析信息
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jTmodS3P-1686550368819)(https://cdn.nlark.com/yuque/0/2023/png/22334367/1686479913516-33a3ae6a-ab32-4c06-8604-d335550eec33.png#averageHue=%2391a081&clientId=u40bbfb26-b053-4&from=paste&height=110&id=u700f17ff&originHeight=260&originWidth=885&originalType=binary&ratio=1.25&rotation=0&showTitle=false&size=38701&status=done&style=none&taskId=u3837686f-0715-44b5-a060-3af140b1a36&title=&width=375)]
影响进度的因素

1. 从进度计划本身分析
   1. 进度计划制定不细致。
   2. 进度计划的约束条件和依赖环境考虑不全。
   3. 工作量评估不准确。
2. 从进度控制角度考虑
   1. 进度信息收集问题。
   2. 进度监控和管理问题。
   3. 计划变更调整要及时。
3. 从团队协调方面考虑
   项目团队成员有三种常见的心态影响了进度的控制：一是完美主义，二是自尊心，三是想当然主义。
4. 从项目管理三角关系考虑（范围、质量、成本）

进度控制
项目阶段情况汇报与计划项目负责人定期对进度进行汇报和总结，可以及时发现总进度的偏离，及时采取相应措施来纠正或者预防。
定期和不定期的项目进度检查
制定适当的进度控制的流程
调整各种项目目标之间的平衡
影响成本的因素
项目的质量对成本的影响
项目管理水平对成本的影响
人力资源对成本的影响

挣值管理
进度成本控制平衡
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-APxALyOH-1686550368821)(https://cdn.nlark.com/yuque/0/2023/png/22334367/1686480113826-8038627d-bb28-4222-8169-3c27d206fcdf.png#averageHue=%23e0e7c1&clientId=u40bbfb26-b053-4&from=paste&height=281&id=u24bcb698&originHeight=565&originWidth=873&originalType=binary&ratio=1.25&rotation=0&showTitle=false&size=114668&status=done&style=none&taskId=u290d669e-fef2-4b75-ad41-9ba90efbb84&title=&width=434)]
知识点回忆
项目活动
活动之间的3种关系
确定项目活动的次序—网络图
常用网络图 :PDM:ADM:甘特图法:里程碑图：
关键路径和关键活动
活动缓冲期 （浮动时间）
网络模型的遍历
挣值分析法
项目跟踪控制
三个关键中间变量
⑴ 项目计划工作的预算成本-计划值 计划值 PV=BCWS，(Budgeted cost of work scheduled)
⑵ 项目已完成工作的实际成本 实际成本AC=ACWP,
⑶ 挣值（已完成工作的预算成本）。 挣值 EV=BCWP,表示按照预算价格所计算的某项目实际已完成工作的成本。

**自由浮动时间 = 后面活动的最早开始时间 - 此活动的最早结束时间 **
总浮动时间 = 自己的最晚开始时间 - 自己的最早开始时间


1：项目的成本绩效指数（CPI）是0.84，这意味着你应该 B ：
A、重点提高实际进展的及时性.
B、重新评估产品的生命周期成本，包括生命周期阶段的长度.
C、承认你最初的估算存在根本性缺陷，并且项目处于非典型状态.
D、重点提高正在执行的工作的生产率.
8.关于网络图，下面哪个是不正确的？（ D ）
A. 网络图可用于安排计划
B.网络图展示任务之间的逻辑关系
C.网络图可用于跟踪项目
D.网络图可用于详细的时间管理

6.软件项目质量管理

软件质量保证
软件质量概述
质量管理是指确定质量方针、目标和职责，并通过质量体系中的质量策划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动
软件的质量管理贯穿了整个软件开发周期。不仅确保项目最终交付的产品满足质量要求，而且要保证项目实施过程中阶段性成果的质量。
质量定义：质量是产品或服务满足明示或者暗示需求能力的特性和特征的集合。
包括三方面：（1）内在质量，即产品本身的缺陷率和可靠性。（2）客户满意度，即产品与用户需求的一致性。（3）过程质量，即为了确保产品的内在质量和客户满意度，而对产品的设计与开发过程中所进行的监管和改进措施的效果。
软件质量定义：等于软件内在质量、过程质量与客户满意度的综合。包括三方面：（1）软件需求是度量软件质量的基础，不符合需求的软件就不具备质量。（2）应在各种标准中定义开发准则，用于指导软件人员采用工程化的方法来开发软件产品。（3）往往会有一些隐含的需求没有明确地提出来，若忽略了这些隐含需求将无法保证软件质量。
软件质量的核心：是需求和标准
6.1.2质量管理过程
软件质量控制 (SQC，Software Quality Control) 是科学地测量过程状态的基本的方法。就象汽车表盘上的仪器，可以了解行驶中的转速、速度、油量等。
软件质量保证 (SQA，Software Quality Assurance) 则是过程和程序的参考与指南的集合。就像汽车中的用户手册。
软件质量计划 (SQP，Software Quality Plan) 是进行项目质量管理、实现项目质量方针和目标的具体规划。

6.1.2 软件质量管理层次 续
检查，通过检验保证产品的质量，符合规格的软件产品为合格品，不符合规格的产品为次品。相当于“软件测试/质量控制”;
保证，质量目标通过软件开发部门来实现，制定质量计划，保证软件开发流程合理性、流畅性和稳定性。相当于初期的“质量保证”;
预防，软件质量以预防为主，以过程管理为重，把质量的保证工作重点放在过程管理上、相当于成熟的“质量保证”;
完美，以客户为中心，贯穿于软件开发生存期过程，全员参与，追求卓越，相当于“全面软件质量管理”。
6.1.3 质量工作 续
软件质量的复杂度，主要体现两方面：
（1）理解用户的需求难度很大(p50)（2）制定和遵循标准的难度很大

1. 质量管理过程的目的是确保项目满足需要执行的过程。主要过程不包含以下哪一项（A）
   A.质量评审   B. 质量保证   C. 质量规划   D. 质量控制
2. 解释质量控制：
   质量控制是确定项目结果与质量标准是否相符，同时确定消除不符的原因和方法，控制产品的质量，及时纠正缺陷的过程。软件质量控制主要就是发现和消除软件产品的缺陷。
3. 解释质量保证：
   QA致力于按照正确方法、在正确的时间做正确的事情：从做事方法上按照既定流程来保障产品质量，控制开发工作而不是解决具体存在的BUG。

6.2 质量度量
质量度量的作用
有效的沟通和改进可见性。
尽早的发现和更正问题。
作出关键的权衡。
跟踪特定的项目目标。
管理风险。
有助于决策。
计划未来的项目。
6.2.1 软件质量模型
（1）基于经验的模型
层次模型：McCall质量模型、Boehm模型 ISO9126质量模型
关系模型：Perry质量模型
2）基于构建的模型
1.McCall模型
McCal质量模型框架：
目标：基于分解法，通过分层的方式对要评估的软件性能进行定义，同时提供相关的方法来用于提取这些反映软件性能的质量特征。
模型分为三层架构：
质量因素:
质量准则：
质量度量：

软件质量因素分三个方面：
产品运行：指操作方面的能力
产品修正：软件后期维护所需的工作量
产品移植：对新环境的适应能力
McCall模型围绕每个质量因素分别总结了11个质量特性。


McCall等人认为，特性是软件质量的反映，软件属性可用做评价准则.

第二层评价准则：共21个，可审查性、准确性、通信通用性、完全性、简明性、一致性、数据通用性、容错性、执行效率、可扩充性、通用性、独立性、检测性、模块化、可操作性、安全性、自文档性、简单性、软件系统独立性、可追踪性和易培训性。
2 Boehm模型
Boehm模型从软件相关的所有使用者的角度来描述软件的质量要求，
主要分为三类用户：初始用户：其他用户：系统维护用户：
Boehm质量模型的特点：
Boehm质量模型为分层结构。
Boehm质量模型包含了McCall模型中没有的硬件特性。
Boehm质量模型反映了对软件质量的全过程理解，即软件做了用户要它做的；有效地使用系统资源；易于用户学习和使用；易于测试和维护。
Boehm 模型和 McCall 模型比较
Boehm 模型和 McCall 模型有些相似，区别在于 McCall 模型主要关注于高层属性（“As-is utility”）的精确度量上，而 Boehm 模型则基于更广泛的属性，并且对可维护性做了更多的关注。
6.2 .2 ISO/IEC9126质量模型
主要包含三部分：内部质量模型，外部质量模型，使用质量模型。
其中内在质量和外在质量的六个特征,它们还可以再继续分成更多的子特征。
这个模型：
第一层：质量特性（6个）
第二层：子特性（27个）
没有像McCall模型和Boehm模型的那种交叉关系。
1、内部质量 内部质量是站在开发人员和质量保证人员的角度，从内部观点出发评判软件产品的质量特性。2、外部质量 外部质量是站在开发人员和质量保证人员的角度，从外部观点出发评判软件产品的质量特性，即在预定的系统环境中运行时可能达到的质量水平。
3、使用质量模型 使用质量是从用户观点出发，来看待软件产品用于特定环境和条件下的质量，反映的是从用户角度看到的软件产品在适当系统环境下满足其需求的程度。

小结：内外部质量软件的六个质量特征
(1)功能性(Functionality):
(2)可靠性(Reliability):在规定时间内不出现故障。
(3)使用性(Usability):是否容易理解和学习
(4)效率(Efficiency):耗费计算机资源
(5)可维护性(Maintainability):容易分析、修改和保持稳定。 
(6)可移植性(Portability):从一台移到另一台所需工作量。
McCall模型、Boehm模型ISO9126质量模型比较
均属于层次模型，其基本思想是利用质量因素、准则和度量由上而下构成一个三层结构，然后根据经验总结出能反映软件质量的属性、准则和度量。
优势：能为软件产品质量提供一致的术语、为指定软件质量需求和确定软件性能的平衡点指定一个可行的框架。
缺点：仅能描述质量属性之间的有利影响关系，对复杂的关系无法表达。
6.2.3软件质量度量的内容
软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程，目的在于对此加以理解、预测、评估、控制和改善。
度量：包括顾客满意度度量、质量度量、项目度量、以及品牌资产度量、知识产权价值度量等。
度量取向要依靠事实、数据、原理、法则；其方法是测试、审核、调查；其工具是统计、图表、数字、模型；其标准是量化的指标。
1 软件内在质量度量
软件产品本身评价包括两方面：
开发角度（缺陷数）
用户角度（发现的问题、满意度）
1）缺陷密度：指软件在一定软件规模下的分布。采用不同方式衡量：代码行、功能点、对象点等。
缺陷密度越低，产品质量越高。
1、（质量）是满足要求的程度，包括符合规定的要求和客户隐含的需求。
2、质量成本包括预防成本和（缺陷成本）。
3、质量管理包括（软件质量计划）（软件质量保证）（软件质量控制）等过程。
4、（软件质量）是软件满足明确说明或者隐含的需求的程度。
5、McCall质量模型关注的3个方面是（产品运行）、（产品转移）、（产品修改）。
6、质量管理总是围绕着质量保证和（质量控制）过程两个方面进行。

2）平均失效时间MTTF
用户关心的是程序的失效，并非缺陷数。
MTTF:两次失效之间的时间间隔。
缺陷和失效是两个关于软件的bug重要术语。
缺陷密度是从规模上衡量，容易计算。对软件开发商而言，通过研究缺陷密度有利于提高测试过程的质量。MTTF是从时间上对失效进行计算。
MTTF的测量比较困难，往往难以记录测试和运行过程中出现的所有失效，商业中运用不多，主要应用于对安全性要求较高的软件开发中。
3）复杂性：用于评估软件系统的可测试性、可靠性和可维护性，可提高工作量估计的有效性和精度。
复杂度测量包括：文本复杂度、环复杂度、基本复杂度等。
（1）文本复杂度：以程序中出现的操作数和操作符为计数对象从而估算工作量的大小。
n=n1+n2 n1:是唯一操作数的数量。n2:是唯一操作符的数量。
N1是P中出现的所有操作数的种类，N2是程序中出现的所有操作符的种类，
可得到：程序长度N=N1+N2,程序容量V=NLog2n
（2）环复杂度对程序结构复杂情况的一种度量模型，能反映判断节点的引入对程序结构以及执行路径数目带来的不利影响。方法：观察法、公式法和判断节点法。
（1）观察法：环复杂度等于1加上程序图中封闭区域的个数。
（2）公式法：V(G)=e-n+2 e:表示图中边的数目 n：表示图中节点的总数.例：
（3）判定节点法：V(G)=p+1 p表示图中独立判定节点的数目。适用：程序具有单入口、单出口的情况。例：教材p63图4-8.
4）文档缺陷密度：
W1文档规范相关的缺陷,W2文档内容方面的缺陷 N1对应w1缺陷数, N2对应w2缺陷数 P文档总页数
5）用户问题度量：指一段时间内的用户上报的平均问题数，可称其为用户问题率，包括
缺陷性问题（缺陷率度量）
非缺陷性问题（使用性问题、不明确的文档或者信息、有据缺陷的重复出现
计算公式如下：用户问题度量=一段时间内的用户上报问题总数/(已销售软件套数时间间隔)
6）用户满意度度量 非常满意 满意 一般 不满意 非常不满意
2.软件过程质量度量
1）需求分析过程质量度量
主要体现在需求文档质量和需求稳定性的度量。
需求文档质量：完整性、正确性、可理解性、可测试性、一致性、可追踪性、可修改性、精确性可复用性。
稳定性度量：RSI=1-累计需求变化请求数/（初始需求请求列表数+累计需求变化请求数-待定需求变化请求数）2）开发过程质量度量 是程序员编写代码、修改代码以正确实现软件产品功能的过程。
3）测试过程质量度量度量指标有： 测试用例深度、用例效率、用例质量、执行质量、执行效率、缺陷报有效性、报告质量、缺陷清除率。p65
3软件维护质量度量
(1)缺陷积压处理度量：一段时间内修复的缺陷问题总数与该段时间内发现的缺陷问题数，该度量反映了开发团队对缺陷的处理能力。
2）缺陷修复响应时间度量：所有问题从发现到解决的平均时间。
3）缺陷修复响应度量：用户期望的修复响应。
4）缺陷修复质量度量：针对软件缺陷能够正确的修复，确保修复后不植入新的缺陷。
6.2.4软件质量工具
对软件质量相关活动进行跟踪记录，实现质量的控制，往往需要多种类型的质量工具。
数据库、图形和报告工具:对度量数据存储和管理，最基本的度量工具。
数据收集工具:自动从工程元素中收集数据。统计分析工具：收集、整理和分析，提供进一步推理。
估计模型：支持对软件质量的预测，利用相关指标对高层次软件质量属性进行预测。主要有7中工具。
1.表格类工具：调查表或者统计分析表，是一种列表形式。 面向项目组的检查表：列表项主要与过程控制项有关。 面向用户的检查表：像指导手册，列出的项目与用户的日常使用有关。
2.柱状图类工具直方图 ：帕累托图
3.折线图类工具
4.游程图：又称趋势图或统计图。
5.控制图：又称管制图
6.枝状图类工具
5.离散点图类工具
6.3软件 质量保证措施
6.3.1 质量计划的内容
目的和范围
参考的文件列表
质量目标
质量的任务
参与质量管理的相关人员及其责任
对一些关键文档提出要求。
重申适合项目的相关标准
评审的流程和标准
配置管理要求
问题报告和处理系统
采用的质量控制工具、技术和方法等质量
6.3.2 质量计划制定的步骤
了解项目的基本概况，收集项目有关资料
确定项目的质量目标
确定围绕质量目标的工作任务
明确项目质量管理组织机构
制定项目质量控制程序
项目质量计划的评审
6.3.3 质量计划的实施和控制
通过设置检查点、验证点，对阶段性成果进行评审或完成质量评估，以确定项目阶段性成果是否达到所设定的质量标准。
项目收尾阶段的质量控制是一个非常重要而又容易忽视的内容
6.4软件测试过程管理
软件评审
评审可分为：教育评审、管理评审、同行评审、项目后的评审等多种。
同行评审：重要性不言而喻。是一种有效的软件质量保证活动之一。主要基于缺陷预防。
同行评审方法：审查、团队评审、走查、结对编程、同行桌查、轮查及特别检查

6.6.1软件测试过程模型
软件测试过程模型：V模型 W模型 H模型
1.软件测试过程模型－V模型 是软件 开发 瀑布模型的变种，主要反映测试活动与分析和设计的关系。
局限性：把测试作为编码之后的最后一个活动， 需求分析 等前期产生的错误直到后期的 验收测试 才能发现 。
软件测试过程模型－V模型 

2.软件测试过程模型－W模型
 在V模型的基础上，增加开发阶段的同步测试，形成W模型；测试与开发同步进行，有利用尽早的发现问题 。
局限性：仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整 
软件测试过程模型－W模型

3.软件测试过程模型－H模型 

H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。
4、X模型  :提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序

5.测试过程使用的策略
 V模型: 强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试  
W模型: 补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明。  
H模型: 强调测试是独立的，只要测试准备完成，就可以执行测试。
6.6.2 软件测试过程管理实践
1.测试人员的管理
人是测试工作中最有价最重要的资源，没有一个合格的、积极的测试小组测试就不可能实现。
测试经理、测试组长、分析师、 测试工程师 测试评审员、实验室管理
2.工作产品的管理 测试相关文档包括测试计划、测试设计、测试用例、缺陷报告、测试脚本及测试总结报告。 （1）测试用例的管理 组织性、重复性及跟踪性 。有八个步骤： 整理模块需求；撰写测试计划；设计测试思路；编写测试用例、评审测试用例、修改更新测试用例、执行测试用例及分析评估测试用例质量。
（2）缺陷管理 测试人员的主要任务之一是发现缺陷，并确保缺陷在产品发布前得到及时、正确的修复。 缺陷或缺陷报告在整个生命周期中会处于不同的状态，这些状态定义了不同角色的人对缺陷的处理的方式。
（3）测试环境的管理软件测试环境是实施的重要环节，环境是否适合将严重影响测试结果的真实性和正确性。 1）测试环境测试环境=硬件+软件+网络+历史数据
2）良好测试环境的要素：5个要素：硬件、软件、网络、数据、工具
3）测试环境的规划明确软硬件相关问题、协调其他部门
4）测试环境的维护和管理 设置测试环境管理员、明确测试环境管理所需的文档、管理测试环境的访问权限、备份管理测试环境变更、备份和恢复测试环境。
6.6.3软件测试过程可持续改进
软件质量工作的第一阶段是质量控制，即提高质量测量工具，发现工作产品中的问题。
质量控制=技术+管理+过程
软件测试改进主要包括：（1）建立和管理测试度量程序（2）调整测试活动的时序关系（3）优化测试活动的资源配置（4）提高测试计划的执行力度（5）提高测试覆盖率

7.项目风险管理

警示一：超级战舰瓦萨号
警示二：中程喷气式客机“彗星”号
什么是风险
风险是遭受损失、伤害、破坏的可能性。
风险是不利的情况(或损失)发生的不确定性 （不期望发生事件的客观不确定性 ）。
风险是在给定情况下和特定时间内，那些可能发生的结果之间的差异，差异越大则风险越大。
风险类型
预测风险：已知风险 可预测风险 不可预测风险
范围风险： 商业风险、管理风险、人员风险、技术风险、开发环境风险、客户风险、过程风险、产品规模风险等
项目风险的特点
具有不确定性，必然发生的事情不是风险。
不期望发生的事情。客观存在的，不以人的意志为转移。
是相对的，尽管风险是客观存在的，但它却依赖于决策目标。
主要取决于两个要素：行动方案和未来环境状态。
**项目风险的三要素：**风险事件 事件概率 事件影响
风险管理的四个过程：

1)风险识别
风险识别是识别风险事件,系统化地确定对项目计划的威胁，识别已知和可预测的风险。
2)风险评估
对风险事件发生概率的评估，对项目风险影响的评估，给出项目风险排序。
3)风险规划
针对风险分析的结果，制定一定的行动和策略来对付、减少、以至于消灭风险事件造成的影响。
4)风险控制
风险控制是在项目执行过程中实施和监控风险计划，同时，不断进行风险识别、风险分析、风险规划的过程。
**风险识别方法 **德尔菲方法 头脑风暴法 情景分析法 利用风险条目检查表
风险条目检查表—实例
1.你以前是否曾与这个客户合作过？
2.该客户是否很清楚需要什么；他能否花时间把需求写出来？
3.该客户是否同意花时间召开正式的需求收集会议，以确定项目范围？
4.该客户是否愿意参加复审工作？
5.待开发的软件是否需要使用新的或未经证实的硬件接口？
6.是否有足够的人员可用？





敏感性分析的一般步骤包括(A，B，C，E )。
A．确定评价指标，选择需要分析的不确定性因素
B．计算各影响因素对评价指标的影响程度
C．确定敏感性因素
D．计算敏感度系数和临界点
E．通过分析和计算敏感因素的影响程度，确定项目可能存在的风险的大小及风险影响



AHP法风险分解过程

AHP法（风险清单）示例









风险管理案例1
某公司召开会议，商量是否实施ERP项目，三个部门主要负责人就此问题发表自己的看法。
甲：我们公司不应该实施这个项目。现在我们刚把办公自动化系统搞好，还没有适应，工作效率也没提高多少，再上ERP有些不适应，而且这个ERP项目花费太大。ERP在国内很多企业都搞失败了，成功的几率不会多大。如果我们也失败了，会给公司带来灾难性的后果。利用搞ERP的这些钱我们可以做一些短、平、快的项目，多招一些开发高手，提高公司的收益，而不是搞这些无端的风险投资。
乙：不应该一棒子打死ERP o ERP是一种新兴事务，ERP不是万能的，但是不上ERP又是万万不行的。企业规模到了一定程度，管理和决策就是一个重要的问题。ERP是知识经济时代的管理方案，是面向供应链和“流程制”的智能决策支持系统，其先进的管理思想可以帮助企业最大限度地利用已有资源，解决管理和决策问题。但是实施 ERP风险很大，很多企业都失败了，主要原因在于项目实施的管理问题，没有及时识别项目中的风险并及时处理，项目监控机制不好，高层支持不够，老员工的适应性差等，最终导致“ERP天折”。我们公司以后想获得更大发展，应该实施ERP o现在有些条件不够，整体上ERP不太可行，我们可以分步实施。我们可以借鉴其他企业实施ERP的经验，先进行小范围ERP试验、积累经验，等以后时机成熟了，我们就整体实施ERP 。
丙：ERP应该上，而且要迅速上，不应该等。如果其他企业都上了ERP,那么我们公司再依靠ERP获得收益就没有什么希望了。ERP本身就是一把双刃剑，虽然有风险，但是收益也大，现在我们的目标是收益，对于风险要想法化解。项目实施中要注意借鉴其他企业的经验，摸着石头过河，形成自己的特色，提高自己公司的管理和决策水平，争取把公司做大做强。小的、可以自己解决的风险自己处理；难以处理的、不确定的风险进行外包，实施风险转移；如果管理有问题的话，可以从专业咨询公司招聘顾问来担当项目经理的职务。总之，尽一切可能实施ERP，实现收益最大化。
问题：
1： 如图1所示，横轴表示项目投资的大小，纵轴表示项目成功的概率，A、B, C代表三种不同应对风险的人。请写出A,B,C的名字和特征，并且指出上述案例中甲、乙、丙分别属于哪一种对象(250字左右)。

2：如果公司有以下三种职位，你认为甲、乙、丙分别适合做什么：项目经理、程序员、产品销售人员(请说清楚原因，不超过150字)。
1.答： A为风险规避者：属于保守派。他们自始至终都不愿意接受较大的风险，希望利用少量投资就可以得到较高的成功概率；随着投资的增加，他们希望成功概率越来越大，最后达到百分之百。 　B为风险中立者：属于中庸派。当投入少时，他们可以接受较大的风险；当投入逐渐增加时，他们就开始变得谨慎起来，希望获得成功的概率提高了，最后达到百分之百。 C为风险冒险者：属于冒险派。他们自始至终都愿意接受较大的风险，当投入少时，他们可以接受较大的风险；随着投入的增加，他们也会变得谨慎一些，希望成功概率有所增加，最后达到百分之百。 上述案例中，甲、乙、丙分别对应A, B, C.
2.答： 甲属于风险规避者，做事小心谨慎，不愿意冒大风险，比较适合做程序员。 乙属于风险中立者，做事深思熟虑、讲究章法，制定计划切实可行、可进可退，比较适合做项目经理。 丙属于风险冒险者，做事大胆，敢于冒风险，一切以效益为先，积极追求成功，具有强烈的成功欲望，比较适合做产品销售人员。
风险管理案例2：
利用决策树风险分析技术来分析如下两种情况的，以便决定你会选择哪种方案：（要求画出决策树）方案１：随机投掷硬币两次，如果两次投掷的结果都是硬币正面超上，你将获得１０元；投掷的结果背面每朝上一次你需要付出１.５元。方案２：随机投掷硬币两次，你需要付出２元；如果两次投掷的结果都是硬币正面朝上，你将获得１０元。

7.7 风险管理高级技术
7.7.1 VERT技术7.7.2 蒙特卡罗法7.7.3 SWOT 分析法7.7.4 关键链技术
**风险管理的主要技术 **

VERT技术
在PERT（计划评审技术）、GERT（图形～）基础上发展起来的。
属于数学的随机网络模型，通过带有时间、费用和性能等变量值的弧和节点，按照其相互关系连接起来的网状图
风险信息系统的成本分析法（Risk Information System Cost Analysis，RISCA）
全面风险评估成本风险网络（ Total Risk Accessing Cost Analysis Net，TRACENET）
SWOT分析法

当项目进行到某一阶段，项目经理发现项目组的一些人（包括关键人）要离开公司，这时项目经理首先应该做什么？（ ） A) 修改WBS B) 招募人员 C) 批评这些人 ** D) 实施风险计划 **

9.项目监督和控制

监督与控制



9.6 变更控制
流程 策略
变更控制流程

变更控制策略
变更预防 变更控制委员会 变更执行管理 变更适应—敏捷开发 变更经验收集与总结

**案例1：**实施项目中变更，好事变坏事在一个正在实施的系统集成项目中，出现下述情况，一个系统的用户向他认识的一个开发人员抱怨系统软件中的一项功能问题，并且表示他希望能够修改，于是该开发人员直接对系统软件进行了修改，解决了该问题，针对这一问题请分析如下：问题一、说明上述情况中存在哪些问题？问题二、说明上述情况会导致什么样的结果？问题三、说明配置管理中完整的变更处理流程。
问题一、上述情况中存在的问题： 1、对用户的要求未进行记录， 2、对变更请求未进行足够的分析，也没有获得批准3、在修改过程中没有注意进行版本管理 4、修改完成后未进行验证 5、修改的内容未与项目干系人进行沟通
 问题二、上述情况会导致的结果1、缺乏对变更请求的分析，可能会导致对产品的变更工作出现欠缺，与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定的影响2、缺乏对变更请求的记录可能会导致对产品的变更里是无法追溯，并会导致对工作的产物的整体变化时去把握。3、在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延，另一方面，对于组织财富和经验的积累也是不利的，4、修改完成后不进行验证则难以确认变更是否正确实施，为变更付出的工作量也无法得到承认 5、未与项目干系人进行沟通可能导致项目干系人之间的工作出现不一致之处，进而影响项目的整体质量。
问题三、配置管理中完整的变更处理流程： 1、变更申请，应记录变更的提出人、日期、申请变更的内容等事项，2、变更评估，对变更的影响范围、严重程度、经济和技术可行性方面进行评估。 3、变更决策，由具有相应权限的人员或机构决定是否实施变更4、变更实施，由管理者指定的人员在受控状态下实施变更。5、实施验证：由配置管理人员或者受到影响的人员对结果进行评价，确定变更结果和预期相符，相关内容进行了更新，符合版本管理的要求，6、沟通存档：将变更后的内容通知可能会受到影响的人员，将变更记录汇总归档，如提出的变更在决策时被否定，起初是记录也应予以保存。