（软考）系统分析师——项目管理

ps:本博客内容只针对博主复习期间对考点的一些总结，内容可能并不全面，还望海涵。也欢迎大家补充和指点错误~~

项目生命周期

• 概念阶段
  • 提出并论证项目是否可行
  • 主要工作有：
    • 需求收集
    • 项目策划
    • 可行性研究
    • 风险评估
    • 项目建议书
• 开发阶段
  • 主要任务是对项目任务和资源进行详尽计划和配置
  • 主要工作：
    • 确定范围和目标
    • 确立项目组主要成员
    • 确立技术路线
    • 工作分解
    • 确定主计划
    • 转项计划（费用、质量保证、风险控制、沟通）等工作
• 实施阶段
  • 按项目计划实施项目的工作
  • 主要工作：
    • 根据项目的工作分解结构和网络计划来组组协调，确保各项任务保质量、按时间完成
• 结束阶段
  • 完成项目的工作，最终产品成型
  • 主要工作：
    • 项目组织者要对项目进行财务清算、文档总结、评估验收、最终交付客户使用和对项目总结评价

项目计划内容

项目计划内容可以分为9个内容：

1. 工作计划（实施计划）
   1. 为保证项目顺利开展，围绕项目目标的最终实现而制定的实施方案；
   2. 主要内容是说明采取什么方法组织实施项目，研究如何最佳的利用资源，用尽可能少的资源获取最佳效益
2. 人员组织计划
   1. 主要表明工作分解结构图中的各项工作应该由谁来承担，以及各项工作间的关系如何
   2. 主要表达形式有： 框图式、职责分工说明式、混合式
3. 设备采购供应计划
   1. 项目涉及的仪器设备的采购；
   2. 会直接影响项目的质量及成本
4. 其他资源供应计划
   1. 项目建设所需的材料、半成品、物件等资源的供应问题；
   2. 直接关系到项目的工期和成本
5. 变更控制计划
   1. 计划和实际不符合的情况经常发生；
6. 进度计划
   1. 根据实际条件和合同要求，以拟建项目的竣工投产或交付使用时间为目标 ，按照合理的顺序所安排的实施日程
7. 成本投资计划
   1. 包括各层次的项目单元计划成本
8. 文件控制计划
   1. 由一些能保证项目顺利完成的文件管理方案构成，需要阐明文件控制方式、细则，负责建立并维护好项目文件，以供项目组成员在项目实施期间使用
9. 支持计划
   1.主要有软件支持、培训支持和行政支持，还有项目考评、文件、批准或签署、系统测试、安装等支持方式

项目监督与控制

• 目的是提供对项目进展的理解，从而在项目表现明显偏移计划时能够采取适当的纠正措施；
• 项目监督的内容包括 进展监督、工作量和成本监督、监督工作产品与任务的属性、监督提供并使用的资源、监督项目成员的知识与技能、项目风险监督等；
• 项目控制可采取正规和非正规两种方式
  • 正规：通过定期或不定期的进展情况汇报和检查，以及项目进展报告进行；
  • 非正规：项目经理频繁的到项目管理现场同项目管理人员交流，了解情况，及时解决问题；
• 根据控制的时间先后，项目控制分为预先控制、过程控制、事后控制
• 根据控制的对象不同，项目控制分为直接控制、间接控制

范围管理

• 项目范围是为了达到项目目标，为了交付具有某种特质的产品和服务，项目所规定要做的，而项目范围管理就是确定哪些应该做，那些不应该做；
• 在信息系统项目中，有两个相互关联的范围：
  • 产品范围（需求分析）
    • 产品范围是指信息系统产品或者服务所应该包含的功能
  • 项目范围
    • 项目范围是指为了能够交付信息系统项目所必须做的工作
  • 两个范围的关系和区别
    • 产品范围是项目范围的基础，产品的范围定义是信息系统要求的量度，而项目范围的定义是产生项目计划的基础；
    • 需求分析更加偏重于软件技术，而项目范围管理则更偏向于管理 ；
    • 判断项目范围是否完成，要以项目管理计划、项目范围说明书、WBS、WBS词汇表来衡量；
    • 信息系统产品或服务是否完成，则根据产品或服务是否满足需求规划说明书的要求
• 范围管理的主要活动：
  • 范围计划的编制
    • 项目范围管理计划说明项目组将如何进行项目的范围管理，具体来说，包括如何进行项目范围定义，如何制定WBS，如何进行项目范围确认和控制；
    • 包括的内容：
      • 如何从项目初步的范围说明书来编制详细的范围说明书
      • 如何进行更加详细的项目范围说明书编制WBS，如何核准和维持编制的WBS
      • 如何确认和验收项目所完成的可交付成果；
      • 如何进行变更请求的批准
  • 范围定义
    • 最重要的任务是详细定义项目的范围边界
  • 创建工作分解结构
    • 组织并定义整个项目范围
    • 分层的特点有：
      • 每层中的所有要素之和是下一层的工作之和；
      • 每个工作要素应该具体指派给一个层次，而不应该指派给多个层次；
      • WBS需要有投入工作的范围描述，这样才能使所有的人对要完成的工作有全面的了解
    • 在每个分解单元中，都存在可交付成果和里程碑；里程碑和可交付成果紧密联系在一起，但并不是一个事物；里程碑标志着某个可交付成果或者某阶段的正式完成，关注于是否完成，例如：正式的用户认可文件；可交付成果可能包括报告、原型、成果和最终系统。
    • 最底层的工作单元是工作包。
    • 努力水平（投入水平）：是指测量不容易用明显的成就来衡量的辅助性工作的一种手段。这类工作的特点是在一段时间内以均匀的速度进行
    • 在制作WBS的过程中，需要生成一些配套文件，这些文件称为WBS词汇表或WBS字典，主要包括：WBS组成部分的详细内容、账户编码、工作说明、负责人、进度里程碑清单，还可能包括 合同信息、质量要求、技术文献、计划活动、资源、费用估计等。
    • 创建WBS没有所谓的正确方式，既可以使用白板、草图等，也可以使用专门的项目管理软件（Microsoft Project）
  • 范围确认
    • 范围的确认主要体现在与用户的沟通上，需要让用户意识到，虽然项目范围确认是正式的，但并不意味着项目范围就是板上钉钉无法修改的，且无论是现在更改范围还是以后更改范围都会引起项目进度和费用上的变化。
    • 范围确认主要是确认项目的可交付成果是否满足项目干系人的要求，项目干系人进行范围确认时，要检查：
      • 可交付成果是否是确定的、可核实的；
      • 每个交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件
      • 是否有明确的质量标准，可交付成果和其标准之间是否有明确的联系。
      • 审核和承诺是否有清晰的表达
      • 项目范围是否覆盖了需要完成的产品（或服务）进行的所有活动，有没有遗漏或错误
      • 项目范围的风险是否太高，管理层是否能够减低可预见的风险发生时对项目的冲击
  • 范围控制

成本管理

成本估算

• 成本估算是对项目投入的各种资源的成本进行估算，并编制费用估算书；
• 基本估算方法：
  • 自顶向下的估算法
    • 从项目整体出发，进行类推
    • 优点：
      • 管理层会综合考虑项目中的资源分配，能够相对准确把握项目的整体需要，控制预算
    • 缺点：
      • 如果下层人员认为所估算的成本不足以完成任务时，由于地位不同，很有可能会保持沉默等待管理层发现问题并去纠正
      • 对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分；
  • 自底向上的估算法
    • 优点：
      • 由于项目实施人员对任务需要资源的了解在估算上更为精确
    • 缺点：
      • 缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量，往往估算值偏低，必须用其他方法进行检验和校正；
  • 差别估算法（类比估算法）
    • 综合上诉两种方法的优点，主要思想是把待开发的软件项目与过去已完成的软件项目进行类比，从其开发的各个子任务中区分出类似的部分和不同的部分，类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算；
    • 优点：
      • 可以提高估算的准确程度
    • 缺点
      • 不容易明确类似的界限

成本预算

• 项目成本预算是进行项目成本控制的基础，是将项目的成本估算分配到项目的各项具体工作上，已确定项目各项工作和活动的成本定额
• 预算的步骤：
  • 分摊项目总成本到WBS的各个工作包中，为每一个工作包建立总预算成本，再将所有工作包的预算成本进行相加时，结果不能超过项目的总预算成本；
  • 将每个工作包分配得到的成本再次分配到工作包所包含的各项活动上
  • 确定各项成本预算支出的时间计划，以及每一时间点对应的累积预算成本，制定出项目成本预算计划
• 直接成本与间接成本
  • 非直接成本：
    • 包括租金、保险和其他管理费用
  • 直接成本：
    • 与产品生产工艺直接有关的成本；如原料、主要材料、外购半成品、生产工人工资、机器设备折旧等；
  • 隐没成本
    • 当前项目的以前尝试已经发生过的成本
  • 学习曲线
    • 项目组成员在学习使用曾经未使用过的技术和方法的学习过程中，许多时间和劳动投入到尝试和试验中，这些尝试和试验会增加项目的成本
  • 项目完成的时限
    • 一般项目完成的时限越短，那么项目完成的成本越高
  • 质量要求
  • 保留
    • 保留是为风险和未预料的情况而准备的预留成本
• 零基准预算（与类比估算法相反）
  • 并不以过去的相似项目成本作为成本预算的基准，而是以零作为基准，估计所有的工作任务的成本；
  • 零基准预算通常用于一系列的项目，整个组织和时间跨度为几年的项目

挣值分析

• 基本参数
  • 计划工作量的预算费用(BCWS / PV)：指项目实施过程中某阶段计划要求完成的工作量所需的预算工时(费用)
    • BCWS=计划工作量×预算定额
  • 已完成工作量的实际费用(ACWP / AC)：实际完成的工作量所消耗的工时（费用）
  • 已完成工作量的预算成本(BCWP / EV)：实际完成工作量按预算定额计算出来的工时（费用）
    • BCWP=已完成工作量×预算定额
  • 剩余工作的成本（ETC)：完成项目剩余工作预计还需要花费的成本
    • ETC=PV-EV
• 评价指标
  • 进度偏差(SV)
    • SV=EV-PV
  • 费用偏差(CV)
    • CV= EV-AC
  • 成本绩效指数(CPI)
    • CPI=EV/AC
  • 进度绩效指数(SPI)
    • SPI=EV/PV
• 项目出现成本偏差，意味着原来的成本预算出现了问题，需要重新估算项目的成本，这个重新估算的成本为最终估算成本(EAC)，也称为完工估算，有三种进行再次预算的方法
  • 第一种是认为项目日后的工作将和以前的工作效率相同；
    • EAC=BAC/CPI(BAC为完成工作预算，即整个项目成本的预算值）
  • 第二种是假定未完成的工作的效率和已完成的工作的效率没有什么关系
    • EAC=AC+BAC－EV
  • 第三种是重新对未完成的工作进行预算工作，这需要一定的工作量
    • EAC=ACWP+ETC

进度管理

• 主要活动：
  • 活动定义：确定完成项目各项可交付成果而需要开展的具体活动
  • 活动排序：识别和记录各项活动之间的先后关系和逻辑关系
  • 活动资源估算：估算完成各项活动所需要的资源类型和数量
  • 活动历时估算：估算完成各项活动所需要的具体时间
  • 制定进度计划：分析活动顺序、活动持续时间、资源要求和进度制约因素，制定项目进度计划
  • 进度控制：根据进度计划开展项目活动，如果发现偏差，则分析原因或进行调整。
• 前导图法(PDM)
  • 也称为单代号网络图法，是一种用方格或矩形表示活动，并用表示依赖关系的剪线将节点连接起来的一种项目网络图的绘制法；
  • 包括4种依赖关系或先后关系：
    • 完成对开始(FS)：后一活动开始要等前一活动完成
    • 完成对完成(FF)：后一活动完成要等前一活动完成
    • 开始对开始(SS)：后一活动开始要等前一活动开始
    • 开始对完成 (SF)：后一活动完成要等前一活动开始
  • 绘制PDM时，需要遵守下列规则：
    • 图中不能出现回路
    • 图中不能出现双向箭头或无箭头的连线，不能出现无箭尾节点的箭线或无箭头节点的箭线；
    • 图中只能有一个起始节点和一个终止节点
• 箭线图法(ADM)
  • 也称双代号网络图法(AOA)，是一种利用剪线表示活动，并在节点处将其连接起来，以表示其依赖关系的一种项目网络图的绘制法；
  • 在ADM中，有三个基本原则：
    • 每一个事件必须有唯一的一个代号；
    • 任何两项活动紧前事件和紧后事件代号至少有一个不相同
    • 流入（流出）同一事件的活动，均有共同的后继活动（或先行活动）
• 确定依赖关系
  • 通常使用三种依赖关系来进行活动排序
    • 强制性依赖关系（硬逻辑关系、工艺关系）
      • 这种关系是活动之间本身存在的、无法改变的逻辑关系
    • 可自由处理的依赖关系（软逻辑关系、组织关系、首选逻辑关系、优先逻辑关系）
      • 人为确定的一种优先关系
    • 外部依赖关系
      • 涉及项目与非项目活动之间的关系
  • 逻辑关系的表达：
    • 平行关系（并行关系）
      • 两项活动同时开始
    • 顺序关系
      • 相邻两项活动先后进行
    • 搭接关系
      • 两项活动只有一段时间是平行进行
• 活动资源估算
  • 进行活动资源估算的方法：
    • 专家判断法
      • 通常由项目成本管理专家根据以往类似项目的经验和对本项目的判断，经过周密思考，进行合理预测，从而估算出项目资源
    • 替换方案的确定
      • 如果某项活动存在替代方案，或提供的资源有替代支持可能，则需要明确声明
    • 公开的估算数据
      • 有些公司会定期公开一些生产率或人工费率数据，包括很多国家和地区的劳动力交易、材料和设备信息，这些数据可以作为参考
    • 估算软件
      • 依靠软件强大功能，可以定义资源可用性、费率，以及不同的资源日历
    • 自下而上的估算
      • 将每项工作所需要的资源估算出来，然后汇总即整个活动所需要的资源数量
• 活动历时估算
  • 软件项目的工作量
  • 德尔菲法，最流行的专家评估技术，结合专家判断法和三点估算法
  • 类比估算法，通过新项目与历史项目的比较得到规模估计，估计结果的精准度取决于历史项目数据的完整性和准确性
  • 功能点估计法，在需求分析阶段基于系统功能的一种规模估计方法
• 关键路径法（CPM)
  • CPM是一种基于项目进度分析方法，
  • 甘特图 (Gantt)将关键路径法分析的结果应用到项目日程表中；
  • PERT网分析是关键路径法的延伸，为项目实施过程中引入活动持续期的变化；
  • 优先日程图法允许相互依赖的活动可以部分并行进行；
  • 进度计划启发式方法主要用于较为复杂的项目计划的分析中
  • CPM是借助网络图和各活动所需时间，计算每个活动的最早或最迟开始和结束时间，CPM的关键是计算总时差，核心思想是将WBS分解的活动按逻辑关系加以整合，统筹计算出整个项目的工期和关键路径；
  • 关键路径是最早开始时间和最晚开始时间相等的活动进行串联；
  • 关键路径的工期决定整个项目的工期，是总时差最小的活动；
  • 可以存在多个关键路径；
  • 活动总时差：是指在不延误总工期的前提下，该活动的机动时间；
  • 活动总时差等于该活动最迟完成时间与最早完成时间之差或最迟开始时间与最早开始时间之差；
  • 活动自由时差：是指在不影响紧后活动的最早开始时间前提下该活动的机动时间
  • 费用斜率：描述的是某一项活动加急所需要的代价比©
    • C=(加急需要的费用－标准所需费用)/(标准所需时间－加急所需时间)
  • 进度压缩
    • 进度压缩是指在不改变项目范围的条件下缩短项目进度的途径；
    • 常用进度压缩的技术：
      • 赶工
      • 快速跟进
    • 进度压缩的方法：
      • 加强控制
      • 资源优化
      • 提高资源利用率
      • 改变工艺或流程
      • 加强沟通、加班、外包、缩小范围
• 甘特图(Gantt)和网络计划/关键路径方法(PERT/CPM)
  • 甘特图(Gantt)
    • 可以随时将实际进度与计划进度进行比较
  • 网络计划/关键路径方法(PERT/CPM)
    • 使管理者明确一个作业的延迟对另一个作业的影响
    • 清晰表明了各个作业之间的衔接关系
    • 清晰定义了关键路径
• 甘特图(Gantt)和时标网络图
  • 甘特图：把计划和进度安排智能结合在一起，用水平线段表示活动的工作阶段，线段的起点和终点分别对应着活动的开始时间和完成时间，线段的长度表示完成活动所需的时间；
  • 在甘特图中必须交付应交付的文档与通过评审为标准；
  • 甘特图的优点是 标明了各活动计划进度和当前进度，能动态的反映项目进展情况，能反映活动之间的静态的逻辑关系；
  • 甘特图的缺点是 难以反映多个活动之间存在的复杂的逻辑关系，没有指出影响项目生命周期的关键所在，不利于合理的组织安排整个系统，更不利于对整个系统进行动态优化管理，只适用于小型项目，大型项目用于高级管理层了解全局；
  • 时标网络图：克服甘特图的缺点，用带有时标的网状图表示各子任务的进度情况，以反映各子任务在进度上的依赖关系；
• 进度控制
  • 当出现进度偏差时，需要分析该偏差对后续活动及总工期的影响，主要从以下方面进行分析；
    • 分析产生进度偏差的活动是否为关键活动，若是关键活动，则会对后续工作和总工期产生影响，必须进行进度计划更新；若出现偏差的不是关键活动，需根据偏差值与总时差和自由时差的大小关系进行判断；
    • 分析进度偏差是否大于总时差，若大于总时差，影响后续活动和总工期，应采取相应的调整措施；
    • 分析进度偏差是否大于自由时差，若大于则会对后续活动产生影响，如何调整，应根据后续活动允许影响的程度而定
• 项目进度计划的调整
  • 项目进度计划的调整往往是一个持续反复的过程，一般分为：
    • 关键活动的调整
    • 非关键活动的调整
    • 增减工作量
    • 资源调整

配置管理

• 配置管理是标识和确定系统中配置项的过程，在系统整个生存期内控制这些配置项的投放和变动，记录并报告配置的状态和变动要求，验证配置项的完整性和正确性
• 配置项包括：文档、程序、数据和软件开发环境
  • 文档：与合同、过程和产品有关的文档和资料；
  • 程序：源代码、目标代码和可执行代码
  • 软件：相关软件工具、库内的可重用软件、外购软件
• CMMI对配置管理的定义：
  • 配置管理的目的在于运用配置标识、配置控制、配置状态和配置审计，建立和维护工作产品的完整性。
• 配置管理流程
  • 编制项目配置管理计划
  • 配置标识
    • 是配置管理的基础性工作，是配置管理的前提；配置标识是确定哪些内容应该进入配置管理形成配置项，并确定配置项如何命名，用那些信息来描述该配置项；
  • 变更管理和配置控制
  • 配置状态说明
  • 配置审核
  • 版本管理和发行管理
• 基线
  • 基线是项目生存期各开发阶段末尾的特定点，也称为里程碑，在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段产品；
  • 有三种基线最受人们关注：
    • 功能基线
      • 是指被认可的相关文档中所规定的对待开发系统的规格说明；
    • 分配基线（指派基线）
      • 是指被认可的相关文档中所规定的软件需求的规格说明；
    • 产品基线
      • 是指被认可的相关文档中所规定的有关所开发的软件产品的全部配置项的规格说明；

变更管理

• 变更是指在信息系统项目的实施过程中，由于各种原因对项目的部分或全部功能、性能、体系结构、技术、指标、集成方法和项目进度等方面做出改变，变更是正常、不可避免的，变更越早，损失越小；
• 变更产生的原因主要有以下几个方面：
  • 项目外部环境发生变化，例如政府政策的变化；
  • 项目总体设计、项目需求分析不够周密详细，有一定的错误或遗漏；
  • 新技术的出现，设计人员提出了新的设计方案或新的实现手段；
  • 建设单位由于机构重组等原因造成业务流程的变化；
• 配置库
  • 配置库也称为配置项库，是用来存放配置项的工具；
  • 配置库有三种类型：
    • 开发库
      • 存放开发过程中需要保留的各种信息，供开发人员个人专用，库中信息可能有较为频繁的修改；
    • 受控库（主库）
      • 在开发某个阶段结束时，将工作产品存入或将有关的信息存入，存入信息包括计算机可读的以及人工可读的文档资料，需对库内信息的读写和修改加以控制。
      • 受控库也称主库，对应配置管理系统中的主系统；
    • 产品库
      • 在产品完成系统测试之后，作为最终产品存入库中，等待交付用户或现场安装
      • 产品库也称为备份库，对应配置管理系统中的静态系统（受控系统）
• 变更控制委员会（CCB）/配置控制委员会
  • 任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施
  • 成员通常包括：项目经理、用户代表、质量控制人员、配置控制人员、测试人员
• 变更控制流程：
  • 变更申请：应记录变更的提出人、日期、申请变更的内容等信息
  • 变更评估：对变更的影响范围、严重程度、经济和技术可行性进行系统分析
  • 变更决策：由具有相应权限的人员或机构决定是否实施变更；
  • 变更实施：由管理者制定的工作人员在受控下实施变更；
  • 变更验证：由配置管理人员或受到受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符，相关内容是否进行了更新，工作产物是否符合版本管理的要求。
  • 沟通存档：将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。

版本管理

• 通常有2种版本命名的方法：
  • 号码版本标识
    • 以数字表示，如用1.0，2.0，1.2，2.1.1等表示版本号
  • 符号版本标识
    • 将重要的版本属性有选择的给出，如Windows XP,Windows 2003,Jbuilder 2005等将版本产生的时间给出

质量管理

• 主要活动过程：
  • 质量计划的编制
  • 质量保证
  • 质量控制
• 项目的实施过程，也是质量的形成过程，质量关系到产品的整个生命周期，并涉及产品的各层面；
• 质量管理是指确立质量方针及实施质量方针的全部职能及工作内容，并对其工作效果进行评价和改进的一系列工作；
• ISO 9000系列标准是现代质量管理和质量保证的结晶，ISO 9000由4个项目标准组成：
  • ISO 9000：2000 质量管理体系——基础和术语
  • ISO 9001：2000 质量管理体系——要求
  • ISO 9004：2000 质量管理体系——业绩改进指南
  • ISO 19011：2000 质量和环境审核指南
• ISO 9000实际上是由 计划、控制、文档工作3部分组成循环的体系；
• ISO 9000标准是以质量管理中的8项原则为基础的，8项原则分别为：
  • 以顾客为关注焦点
  • 领导作用
  • 全员参与
  • 过程方法
  • 管理的系统方法
  • 持续改进
  • 以事实为基础进行决策
  • 与供方互利的关系
• 质量保证
  • 项目质量保证指为项目符合相关质量标准要求树立信心，而在质量系统内部实施的各项有计划地系统活动，质量保证应贯穿于项目始末；
  • 质量保证可以分为
    • 内部质量保证
      • 由项目管理团队以及实施组织的管理层实施
    • 外部质量保证
      • 由客户和其他未实际参与项目工作的人们实施
• 质量控制
  • 质量控制指监视项目的具体结果，确定其是否符合相关的质量标准，并判断如何能够去除造成不合格结果的根源
  • 对于信息系统项目，一般采用软件测试和配置管理等质量控制手段来有效控制信息系统产品质量；
• 软件质量管理
  • 软件质量是指软件产品中能够满足规定需求的各种特性的综合，这些特性称作质量特性，包括：
    • 功能性
    • 可靠性
    • 易使用性
    • 时间经济性
    • 资源经济性
    • 可维护性
    • 可移植性
• 质量特性和质量子特性
  • 功能性
    • 适宜性
    • 准确性
    • 互用性
    • 依从性
    • 安全性
  • 可靠性
    • 成熟性
    • 容错性
    • 可恢复性
  • 可用性
    • 可理解性
    • 易学性
    • 可操作性
  • 效率
    • 时间特性
    • 资源特性
  • 可维护性
    • 可分析性
    • 可修改性
    • 稳定性
    • 可测试性
  • 可移植性
    • 适应性
    • 易安装性
    • 一致性
    • 可替换性
• McCall质量模型体系：
  • 软件运行
    • 正确性
      • 程序能够满足规格说明和完成用户业务目标的程度
    • 可靠性
      • 程序能够按要求的精确度实现其预期功能的程度
    • 效率
      • 程序实现其功能所需要的计算资源量
    • 完整性
      • 软件或数据不受未授权人控制的程度
    • 可使用性
      • 学习、操作程序、为其准备输入数据、解释其输出的工作量
  • 软件修改
    • 可维护性
      • 对运行的程序找到错误并排错的工作量
    • 可测试性
      • 为保证程序执行规定功能所需的测试工作量
    • 灵活性
      • 修改运行的程序所需的工作量
  • 软件移植
    • 可移植性
      • 将程序从一种硬件配置和/或环境转移到另一硬件配置和/或环境所需工作量
    • 可重用性
      • 程序可被用于与其实现功能有关的其他应用问题的程度
    • 互操作性
      • 让系统与另一系统协同运行所需的工作量

人力资源管理

• 项目人力资源管理主要包括：
  • 编制人力资源计划
    • 识别项目中的角色、职责和汇报关系，并形成文档，也包括项目人员配置管理计划
  • 组建项目团队
    • 获取项目所需要的人力资源
  • 项目团队建设
    • 提高个人和团队的技能以改善项目绩效
  • 管理项目团队
    • 跟踪个人和团队的绩效、提供反馈、解决问题并协调各种变更以提高项目绩效
• 人力资源计划编制
  • 描述项目的角色和职责的工具主要有
    • 层次结构图
    • 文本格式
    • 责任分配矩阵(RAM)
• 组建项目团队
  • 人员招收一般可以通过如下手段获得：
    • 谈判
    • 事先分派（往往发生在项目是方案竞争的结果）
    • 外部采购（招聘、雇佣、转包等）
    • 虚拟团队（很少有时间或没有时间面对面开会）
• 项目团队建设
  • 可以采取下列措施进行团队建设：
    • 一般管理技能
      • 如经常与项目团队成员沟通，了解其后顾之忧，帮助解决；
    • 培训
      • 培训个人和团队，以分别提高二者的绩效
    • 团队建设活动
      • 每一次的集体活动都是一次团队建设活动，也可以通过专门的团队建设活动来进行
    • 共同的行为准则
      • 越早建立清晰的准则，越少的误解，提高生产率
    • 尽量集中办公
      • 若是条件不允许，可通过大会、虚拟技术等方式弥补
    • 恰当的奖励与表彰措施
      • 尽量采用赢——赢的奖励与表彰措施，少用输——赢的奖励与表彰措施
  • 团队发展过程
    • 团队发展过程包括4个时期：
      • 形成期、震荡期、正规期、表现期
  • 团队建设理论
    • 需求层次理论
      • 马斯洛首创需求层次理论，将人的需要分为5个层次：生理上的需要、和安全的需要属于生存方面；社交的需要、尊重的需要属于归属方面；自我实现的需要属于成长方面；
    • 激励理论
      • 赫兹伯格提出激励理论将人的激励因素分为2种，一种是保健卫生，包括薪金福利、工作环境以及老板对员工的看法，对应于马斯洛需求层次理论的生理、安全、社交需要；一种是激励需求，类似于马斯洛的自尊和自我实现需要；
    • X理论和Y理论
      • 麦格雷戈提出的X理论和Y理论是管理学中关于人们工作源动力的理论，是一对基于两种完全相反假设的理论；X理论认为人们有消极的工作源动力，Y理论认为人们有积极的工作源动力；
      • 持X理论的管理者会趋向于设定严格的规章制度，以减低员工对工作消极性，或采取一种软措施，即给予员工奖励，激励和指导等；
      • 持Y理论的管理者会趋向于对员工授予更大的权力，让员工有更大的发挥机会，以激发员工对工作的积极性
  • 管理项目团队
    • 项目经理有2种方法来最有效的使用项目团队中的成员，分别是
      • 资源负荷
        • 资源负荷是指在特定的时间内现有的进度计划所需要的各种资源的数量，如果在特定的时间内分配给某项工作的资源超过项目的可用资源，则称为资源超负荷；
      • 资源平衡
        • 资源超负荷本身就是一种资源冲突的现象，为了消除超负荷，项目经理需修改进度表，尽量使资源得到充分的利用或充分利用项目活动的浮动时间，这种叫资源平衡
        • 资源平衡的主要目的是更加合理的分配使用的资源，使项目的资源达到最有效的利用

沟通管理

• 项目沟通管理包括
  • 沟通计划编制
    • 确定项目干系人的信息和沟通需求，谁需要何种信息，何时需要以及如何向他们传递
  • 信息分发
    • 以合适的方式及时向项目干系人提供所需要的信息
  • 绩效报告
    • 收集并分发有关项目绩效的信息，包括：状态报告、进展报告、预测
  • 项目干系人管理
    • 对项目沟通进行管理，以满足信息需要者的需求并解决项目干系人的问题
• 沟通渠道：
  • 是项目中沟通的排列组合数量，
  • CC=n×(n-1)/2[CC表示沟通渠道，N表示项目中成员数]
  • 由于沟通需要花费项目成本，所以应尽量控制团队规模，避免大规模团队中常常出现的沟通不畅问题
• 沟通方法
  • 正式沟通
    • 通过项目组织明文规定的渠道进行信息传递和交流的方式
    • 优点是沟通效果好，有较强的约束力；
    • 缺点是沟通速度慢，
  • 非正式沟通
    • 旨在正式渠道之外进行信息传递和交流；
    • 优点是沟通方便，沟通速度快，且能提供一些正式沟通中难以获得的信息
    • 缺点是容易失真
• 沟通障碍
  • 在沟通过程中出现大量信息在上行沟通或下行沟通过程中损失掉的现象，称为过滤；
  • 过滤是项目中沟通的障碍因素
• 绩效报告
  • 绩效报告是一个收集并发布项目绩效信息的动态过程，项目干系人通过审查项目绩效报告，可以随时掌握项目的最新动态和进展，分析项目的发展趋势，及时发现项目进展过程中所存在的问题，从而有的放矢的制定和采取必要的纠偏措施
  • 绩效报告包括
    • 状态报告
      • 描述项目在某一特定时间点所处的项目阶段
    • 进展报告
      • 描述项目团队在某一特定时间段工作完成情况
    • 项目预测
      • 在历史资料和数据基础上，预测项目的将来状况与进展
  • 绩效报告的另一种重要方法是状态评审会议
• 如何改进项目沟通
  1. 把握项目沟通基本原则
     1. 沟通内外有别
        • 团队作为一个整体对外意见要一致，一个团队要用一种声音说话；
     2. 非正式的沟通有助于关系的融洽
        • 私下场合人的语言风格往往是非正规和随意的，反而能获得更多的信息；
     3. 采用对方能接受的沟通风格
        • 注意肢体语言、语态给对方的感受
     4. 沟通的升级原则
        • 需要合理把握横向沟通和纵向沟通关系，以有利于项目问题的解决；
        • 沟通四步骤，反映了沟通的升级原则：第一步，与对方沟通；第二步，与对方的上级沟通；第三步，与自己的上级沟通；第四步，自己的上级和对方的上级沟通
     5. 扫除沟通的障碍
        • 职责定义不清、目标不明确、文档制度不健全、过多使用行话等都是沟通的障碍，必须消除
  2. 进行良好的冲突管理
     • 常见的冲突包括：进度、项目优先级、资源、技术、管理过程、成本、个人冲突
     • 产生冲突原因：项目的高压环境、责任模糊、多个上级的存在、新技术的流行等
     • 解决冲突的5种基本策略：
       • 问题解决
         • 从根本上把冲突源消灭掉，正视问题，正视冲突，要求有一种明确的结局，是克服分歧、解决冲突的最积极的有效途径，也称为面对模式；
       • 妥协
         • 协商并寻求冲突双方在一定程度上都满意的方法是该策略的实质，主要是寻求一种折中方案
       • 圆滑
         • “求同存异”是该策略的本质，尽量在冲突中强调意见一致的方面，最大可能的忽视差异，不过作为一种缓和或调停冲突的方式，并不利于问题的彻底解决；
       • 强迫
         • 采用“非赢即输”的方法来解决冲突，通过牺牲别人的观点来推行自己的观点。这是一种积极解决冲突的方式，但是可能出现极端的情形
       • 撤退
         • 是指卷入冲突的某方从一个实际的或可能的不同意见中撤退或让步，这是最不令人满意的冲突处理模式
  3. 召开高效的会议
     • 事先制定一个例会制度
     • 放弃可开可不开的会议
     • 明确会议的目的和期望结果
     • 发布会议通知，在通知中明确 会议目的、时间、地点、参加人员、会议议程、议题
     • 在会议之前将会议资料发到参会人员
     • 可以借助视频设备
     • 明确会议规则
     • 会议后要总结，提炼结论
     • 会议要有纪要
     • 做好会议的后勤保障

风险管理

• 项目风险是一种不确定的时间或条件，一旦发生，会对项目目标产生某种正面或负面的影响；
• IT项目常见的风险：
  • 需求风险、技术风险、团队风险、关键人员风险、预算风险、范围风险
• 项目风险管理的基本过程：
  • 风险管理计划编制
  • 风险识别
    • 识别和确定出项目究竟有哪些风险
    • 识别风险的方法：头脑风暴法、假设分析、风险检查表、专家评估法
  • 风险定性分析
    • 对已识别风险进行优先级排序，以便采取进一步措施，如进行风险量化分析或风险应对；初步估算、大致评估；对已识别的风险进行逐行的评估，并更新风险表
  • 风险定量分析（更难操作）
    • 定量分析风险对项目目标的影响，对不确定因素提供一种量化方法，以帮助做出尽可能恰当的决策
    • 一般先进行风险的定性分析，在有了对风险相对清晰的认识后，在进行定量分析，分析风险对项目的负面和正面影响，制定相应的策略
  • 风险应对计划编制
  • 风险监控
    • 跟踪已识别的危险，监测残余风险和识别新的风险，保证风险计划的执行，并评价这些计划对减轻风险的有效性
• 风险分析
  • 风险定性分析
    • 风险可能性与影响分析
    • 确定风险优先级
    • 确定风险类型
  • 风险定量分析
    • 风险定量分析的工具和方法：
      • 数据收集
      • 表示技术（风险信息访谈、概率分布、专家判断）
      • 定量风险分析和建模技术（灵敏度分析、期望货币价值分析、决策树分析、建模和仿真）
• 风险应对措施
  • 通常把风险应对策略分为两种类型：
    • 防范策略
      • 指的是在风险发生前，项目组会采取一定措施对风险进行防范
    • 响应策略
      • 在风险发生后采取相应措施以降低风险带来的损失
  • 制定风险防范策略
    • 消极的风险（负面风险，威胁）防范策略是最常用的策略，目的是降低风险发生的概率或减轻风险带来的损失，例如：
      • 避免策略
        • 想方设法阻止风险的发生或消除风险发生的危害 ；针对技术风险聘请技术专家，针对项目进度风险采取延长项目时间或缩短项目范围的方法
      • 转移策略
        • 将风险转嫁给其他的组织或个体，通过这种方式来降低风险发生后的损失，例如，在需求签字确认时，对于超出签字范围的需求变更需要客户增加费用
      • 减轻策略
        • 当风险很难避免或转移时，可以考虑的风险策略，通过前期一些工作减低风险发生的可能性或通过一些准备降低风险发生的损失；
    • 正向风险（机会）的应对策略：开拓、分享、强大
  • 制定风险响应策略
    • 与防范策略不同，无论风险是否发生，风险防范策略都需要体现在项目计划中，并需要有人来执行相应的防范策略，而响应策略是事件触发的，风险发生才会执行，若没发生，始终不会被安排到项目活动中

软件过程改进

• 能力成熟度模型（CMM）
  • 初始级
    • 软件过程的特点是无秩序的、有时甚至是混乱的；
  • 可重复级
    • 已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪；
  • 已定义级
    • 用于管理和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程
  • 已管理级
    • 软件过程和产品质量有详细的度量标准
  • 优化级
    • 通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断的、持续的的进行过程改进
• 能力成熟度模型集成（CMMI）
  • 与CMM相比，CMMI涉及面更广，专业领域覆盖 软件工程、系统工程、集成产品开发和系统采购
  • 也分5个级别：
    • 初始级
      • 代表了以不可预测为特征的过程成熟度，过程处于无序状态，成功主要取决于团队技能
    • 已管理级
      • 代表了以可重复项目执行为特征的过程成熟度；
    • 严格定义级
      • 代表了以组织内改进项目执行为特征的过程成熟度
    • 定量管理级
      • 代表了以改进组织性能为特征的过程成熟度
    • 优化级
      • 代表了以可快速进行重新配置的组织性能和定量的、持续的过程改进为特征的过程成熟度