管理信息系统讲义 系统开发项目管理 哈尔滨工业大学 张洁 0引言 ?1我们所处的时代 ?2所谓成功经验 ?3做好非重复的事 ?4适应客户 ?5向知识型企业的转变 1我们所处的时代 ? 企业的终结者时代 – 竞争与死亡：无论大小企业 – 企业兼并与价格战 – 2001年美国宣布破产的大型公司 257家，总资 产高达 2580亿美元；财富：如果事态继续发展， 恐怕明年我们列齐 500强都有困难；安然，安 达信，施乐，世界电信 – 高科技公司 – 微软告诫：离破产永远只有 18个月 2过去的成功经验也许是最可怕的 ? 在瞬息万变的今天，墨守成规只能自取灭 亡 ? 我们今天唯一不变的就是变化 ? 1990， GE公司的杰克 “与 90年代的发展速 度相比， 80年代就象在公园里散步。 ” ? 1999，微软比尔 :”数字信息速度的增加，使 得未来企业 10年的变化将超过过去 50年变 化的总和 ” 3做好非重复性的事 ? 应对变化：变化不是问题，使我们不得不 面对的环境；既然无法改变环境，企业必 须适应环境。 ? 企业生存来源于利润，利润来源于何方？ ? 来源于创新优势 4适应客户是出发点 ? 企业从来没有像如今这样依赖于稳定的客户群， 这不仅是因为获得一个新客户的代价是维持一个 老客户的 5－ 10倍，更主要的是，稳定客户群所 带来的收益占整个企业的总收益比例反映了一个 企业抗拒风险的能力 。 ? 企业的客户群：使用企业产品 /服务的人；出钱购 买产品的人；决定购买产品的人。 客户离开企业的原因 1 3 9 14 68 5 0 1020304050607080 死亡 搬迁 价格 产品 感觉 其他 原因 比例（% ） 5向知识型企业转变 ? 企业要想获得附加价值必须尽量将自己的 主要资源投放到那些非重复性的工作方面； 要努力适应每一个客户，根据客户的需要 改变自己的工作方式。 ? 企业必须使自己变成知识型企业，或在某 种程度上变成知识型企业。 ? 企业不适应客户是没有前景的；企业不能 向知识型企业转化是难以生存的。 两种企业类型的区别 制造型企业 知识型企业 低 对 客户的适应程度 高 大型 小型 生产性 创造性 层次管理 机变管理 人员密集 知识密集 教育程度低 教育程度高 生产有规模经济 生产无规模经济 无形资产有规模经济 速度是关键 ? 如果说，适应客户是企业考虑问题的出发 点，那么，满足客户需求的速度就是企业 的决胜条件。 产品的生命周期 时间 开发 阶段 成长 阶段 衰退 阶段 成熟 阶段 总市场 销售额 典型的 产品生 命周期 曲线 时间 开发 阶段 成长 阶段 衰退 阶段 成熟 阶段 总市场 销售额 时间压 力下的 产品生 命周期 曲线 结论 ? 选择合适的项目 ? 项目管理！ ? 用尽量少的资源作好项目管理 ? 用最快的速度来完成项目 参考书 参考书 ? IT项目管理（第二版）Information Technology Project Management， [美] Kathy Schwalbe著，机械工业出版 社 ?软件项目管理实践 软件项目管理实践 [印 印 ] Pankaj Jalote著，施平安等译，清华 著，施平安等译，清华 大学出版社， 大学出版社， ISBN7-302-06392-3， ， 2003 年 年 4月， 月， 第一章 :基本项目知识 ?1.1什么是项目 ?1.2什么是项目管理 ?1.3项目资源 ?1.4国际项目管理发展 ?1.5项目管理知识体系 1.1项目定义 ? 定义： 定义：项目是为完成某一独特的产品和服 务的一种临时性任务。 ? 临时性 临时性 ——项目有明确的开始时间和结束时间。当项目目 标已经实现，或因项目目标不能实现而项目被终止时，就 意味着项目的结束。 ? 独特性 独特性 ——项目所创造的产品或服务与已有的相似产品或 服务相比较，在有些方面有明显的差别。项目要完成的是 以前未曾作过的工作，所以它是独特的。 项目基本属性： –过程的一次性 – 运作的独特性 – 组织的临时性和开放性 – 成果的不可挽回性 项目与日常工作 ? 共同点： – 由人来实施 – 受制于有限的资源 – 需要计划、实施和控制 ? 不同点 项目与日常工作的作用 日常工作 项目 项目 组 织 进 步 日常工作 日常工作 项目 Windows操作系统完成时间线 1.2项目管理 ? 定义 定义 :项目管理是在项目活动中运用知识、技能、 工具和技术，以满足和超过项目干系人对项目的 需求和期望。 ? ——项目管理就是把各种资源应用于项目，以实 现项目的目标。 项目管理的三要素 时间 范围 成本 项目干系人的 满意程度 项目干系人 ? 项目干系人：积极参与项目或其利益在项 目执行中或成功后受到积极或消极影响的 组织和个人。 ? 主要的项目干系人：顾客、项目经理、项 目组、执行组织、项目发起者。 —内部的和外部的、业主和资金提供者、项 目班子成员、政府机构和媒体、市民和社 会团体 …整个社会。 主要项目干系人 ? 项目发起人 ： 即确定项目正式存在的人员，他们常常属于 企业的高层管理人员。他们期望项目能够给企业带来商业 价值。 ? 项目客户 ：即最终接受或使用项目成果的人。他们期望项 目的成果（又称为项目产品）在特征与特性等方面能够满 足他们的要求。 ? 项目经理 ：即具体负责项目实施，对项目成果的取得负责 的人。 ? 项目团队成员 ：即在项目经理的管理下，具体负责完成项 目任务的人。 ? 相关职能部门及其经理 ：即为项目提供人、财、物和其他 必要资源的部门或个人。因为项目是临时性的，没有固定 的资源，所有项目的资源都在职能部门，职能部门对项目 的支持是十分重要的 24 1.3资源 ? 资源 : 一切具有现实和潜在价值的东西 – 自然资源和人造资源，内部资源和外部资源，有形资 源和无形资源 – 人力和人才 (man)、材料 (material)、机械 (machine)、 资金 (money)、信息 (message)、科学技术 (method of S&T)及市场 (market)等 .<7M> ? 项目管理作为方法和手段，也是资源。 1.4项目管理的历史和发展 ? 古代:追溯到长城、埃及金字塔、古罗马的供水渠 … ? 近代项目管理的萌芽:公认为20世纪40年代， ‘曼哈顿计 划 ’。 ? 近代项目管理的成熟: 关键路线法（CPM）和计划评审技术 (PERT） 阿波罗登月计划 ? 现代项目管理的新发展: 适应产品的创新速度，面向市场和竞争；适应现代 的复杂项目系统；适应以客户满意为核心的服务理念。 软件项目管理状况（1） ? IT项目管理现状 1994年， Standish Group 对于 IT行业的 8400个 项目的研究结果： – 项目实现其目标 16.2% – 项目需要补救 52.7% – 彻底失败 31.1% 软件项目管理状况（2） z项目平均预算超出 89%，进度超出 122% z项目总数 33%既超出预算又进度推迟 z52.7% 的项目费用是原估算的 189 %以上 . z只有 16.2%项目按预算和进度完成 z平均时间超出量是原估算的 222% - 在大公 司，只有 9% 的项目按预算，按进度完成 1994-2000项目成功失败调查 16% 27% 26% 28% 31% 40% 28% 23% 53% 33% 46% 49% 0% 20% 40% 60% 80% 100% 1994 1996 1998 2000 succeeded failed challenged 来源： The Standish Group CHAOS Report 2000 Success Criteria Points No Success Criteria P1 P2 P3 P4 1. User Involvement 19 NO(0) NO(0) YES(19) YES(19) 2. Executive Management Support 16 NO(0) YES(16) YES(16) YES(16) 3. Clear Statement of Requirements 15 NO(0) NO(0) YES(15) NO(0) 4. Proper Planning 11 NO(0) NO(0) YES(11) YES(11) 5. Realistic Expectations 10 YES(10) YES(10) YES(10) YES(10) 6. Smaller Project Milestones 9 NO(0) NO(0) YES(9) YES(9) 7. Competent Staff 8 NO(0) NO(0) YES(8) YES(8) 8. Ownership 6 NO(0) NO(0) YES(6) YES(6) 9. Clear Vision & Objectives 3 NO(0) NO(0) YES(3) YES(3) 10. Hard-Working, Focused Staff 3 NO(0) YES(3) YES(3) YES(3) No TOTAL 100 10 29 100 85 项目出现问题的常见原因 无明确的目标 缺乏详细的 WBS结构 没有正式的沟通 没有有效的监控 缺乏工具 清晰的需求定义 不合理的时间计划 对目标的一致理解 明确的责任 高昂的士气 合理的期望 成员之间的不信任 冲突的解决 缺乏支持与执行 国际项目管理组织1 ? 美国项目管理协会 PMI （ Project Management Institute) – 创建： 60年代，性质：国际性组织 – 分会： 245个 – 成员：企业、高校、研究单位 – 职能：促进国际间项目管理发展 国际项目管理组织2 ? 国际项目管理协会 IPMA(International Project Management Association） – 创建： 1965，性质：非盈利的国际性组织 – 成员：国家级项目管理协会 – 职能：促进国际间项目管理发展 – 产品和服务：研究和发展，教育与培训，标准 和资质认证 1.5国际项目管理知识体系 ? 美国 PMI——项目管理的知识体系 – PMBOK (Project Management Body of Knowledge) – 九个知识领域 ? 欧洲 IPMA——项目管理能力基础 – ICB (IPMA Competence Baseline) –42个知识和实践元素，其中核心元素 28 个，增加元素 14个。 范围 管理 时间 管理 成本 管理 质量 管理 人力 资源 管理 沟通 管理 风险 管理 采购 管理 项目整体管理 9大知识领域的核心功能 促成功能 工具和 技术 项目 成功 项目 相关 人员 的需 要和 期望 项目管理框架 PMBOK 项目管理知识体系 项目管理与其他管理学科的关系 一般管理知识 和实践 . 一般公认的项 目管理知识 和做法 应用领域知识 和实践 项目管理知识体系 此图表示学科领域 之间关系的概念 , 搭接的范围并非按 比例的 . 国际项目管理专业资格认证 第二章项目管理环境 ?2.1项目阶段和项目生命期 ? 2.2 IT的项目阶段 ?2.3组织对项目的影响 ?2.4项目经理 ?2.5社会经济的影响 2.1项目生命期和阶段性 ? 项目阶段 ---项目的执行组织通常将项目分成若干 个项目阶段，以便提供更好的管理控制，并与项 目组织的持续运作之间建立恰当联系。 ? 项目生命期 --项目阶段的全体被称为项目生命期。 ? 项目生命期通常分为启动阶段、中间阶段（含一 个或多个，规划、实施）、收尾阶段 项目生命期 开始 资源投入水平 时间 结束 起动阶段 中间阶段（一个或多个） 收尾阶段 各阶段的工作内容 ? 启动阶段：提出问题和解决方案 ? 中间阶段：解决问题 ? 收尾阶段：结果的评价 项目的生命周期 ? 项目进展的情况（按完成的百分比）： ? 慢速开始，中期加速，缓慢结束 100 0 t 项目生命期的特点 项目生命期特征： a)在项目开始时费用和人员投入水平较低，随着项 目的进展逐渐增加，在项目收尾时又迅速降低； b)在项目开始时，成功完成项目的概率是低的，风 险和不确定性也最高。随着项目的进展，完成项 目的概率通常会逐步提高； c）项目干系人影响项目费用和项目产品最终特性的 能力最高，随着项目的进展通常会逐步降低。 （变更和错误纠正的成本逐步增加） 有关项目阶段的三个概念 ? 检查点（ Checkpoint） 在规定的时间间隔 内对项目进行检查，比较实际与计划之间的差 异，并根据差异进行调整。常见的间隔是每周 一次，项目经理需要召开例会并上交周报。 ? 里程碑（ Milestone） 完成阶段性工作的标 志，不同类型的项目具有不同的里程碑。 ? 基线（ Baseline） 基线是指一个或一组配置 项在项目生命周期的不同时间点上，通过正式 评审而进入正式受控的一种状态。 2.2 IT的项目阶段、里程碑、成果 识别需求 可行性研究 立项 项目章程 文档整理 项目验收 最后评审 启动 规划 实施和控制 收尾 概念 conceive 开发 develop 执行 execute 结束 finish 通过立项评审 通过系统规格评审 人员确定 系统设计 成果确立 成本分析 工作分解 项目建议书 团队建立 项目实施 编码，单元 测试，整体 测试 项目监督 项目控制 通过测试评审 投入 力量 时间 典型的项目生命期 1 IT项目生命期可分为六个阶段 ? 需求分析 ? 概要设计 ? 详细设计 ? 系统实施 ? 系统测试 ? 安装维护 典型生命周期 2 IT项目生命期可分为九个阶段 ? 需求定义 Requirements definition ? 需求分析 Requirements analysis ? 初步设计 Preliminary design ? 详细设计 Detailed design ? 系统实施 Implementation ? 系统测试 System testing ? 接受性测试 Acceptance testing ? 运行和维护 Maintenance and operation 典型的项目生命期 3 螺旋型软件开发项目生命期 评 审 识 别 设 计构 造 配置 运行 和 产 品 支 持 单元 要求 子系 统 要求 子系 统 要求 商业 需 求 概念性 设计概念 证 实 逻辑 设计 实体 设计 最后 设计 最后 开发 二次 开发 最后 开发 测试 评估 结果 评估 结果 风险 分析 一次 开发 项目阶段和管理评审的重要性 ? 每个项目在继续进人下一个阶段之前都必须顺利 通过前面的每一个项目阶段。随着项目的不断推 进，组织通常会投入越来越多的资金，因此，有 必要在每个项目阶段结束后进行管理评审，以对 项目进度、成功的可能性以及项目与商业目标持 续的兼容性做出评价。这些管理评审被称为阶段 出口或终止点。 ? 项目是否应该继续、重新定位或终止？对于进行 此类决策以及保持项目按计划进行而言，这种管 理评审都是非常重要的。 2.3组织结构 ? 项目所在的组织既要承担项目，又需具备各类常规的业务 职能，。若用一个系列来描述的话，一端是职能式，另一 端是项目单列式，中间有多种类型的矩阵式： ? 职能式：明确的直接上司，成员按专业划分组成部门，如 生产、经销、工程、财务等。职能式组织中的项目事宜是 由职能部门负责人来协调解决的。 ? 项目单列式组织：大部分的成员和资源按项目划分，组织 项目班子，投入项目工作，并且项目经理有很大的独立性 和权限。 ? 矩阵式组织：是职能式和项目单列式之间的几类（过渡形 式）。其中弱矩阵式保留了职能式组织的许多特点，项目 经理只相当于协调人的角色，强矩阵式具有许多项目单列 式组织的特点，项目经理人有相当大的权限。 职能型组织 总裁 职能部门经理 员工 员工 员工 职能部门经理 员工 员工 员工 职能部门经理 员工 员工 员工 项目协调 (黑框代表了参与项 目活动的员工） 项目型组织 总裁 项目经理 员工 员工 员工 项目经理 员工 员工 员工 项目经理 员工 员工 员工 项目 协 调 (黑框代表了参与项 目活动的员工） 弱矩阵组织形式 总裁 职能部门经理 员工 员工 员工 职能部门经理 员工 员工 员工 职能部门经 理 员工 员工 员工 项目 协调 (黑框代表了参与项目活动的员工） 平衡矩阵组织形式 总裁 职能部门经理 员工 员工 项目经理 职能部门经理 员工 员工 员工 职能部门经 理 员工 员工 员工 项目 协调 (黑框代表了参与项目活动的员工） 强化矩阵组织形式 总裁 项目 协调 (黑框代表了参与项目活动的员工） 职能部门经理 员工 员工 员工 职能部门经理 员工 员工 员工 职能部门经理 员工 员工 员工 项目经理的上 级 项目经理 项目经理 项目经理 组织结构形式对项目的影响 矩 阵 式 项目单列 组织形式 项目特征 职能式 弱矩阵式 平衡矩阵 强矩阵 项目经理权限 很少或没有 有限 从小到中等 从中等到大 很高， 甚至全权 全时在项目工 作的百分比 几乎没有 0－ 25％ 15－ 60％ 50－ 95％ 85－ 100％ 项目经理任务 半时 半时 全时 全时 全时 项目经理任务 的常用头衔 项目协调员 / 项目领导人 项目协调员 /项目负责人 项目经理 /项目主任 项目经理 /计划经理 项目经理 /计划经理 项目管理行政 人员 半时 半时 半时 全时 全时 组织的影响 ? 项目的组织结构对于项目的管理会产生一定影响， 特别在资源的提供和使用方面有不同形式的限制。 ? 一般来讲，职能式结构有利于发挥效率。项目单 列式结构有利于取得效果。 ? 矩阵式结构兼具有两者优点，但也带来某些不利 因素。例如，各个项目可能在同一个职能部门中 争夺资源；一个成员有两个顶头上司，既难处， 也难管。 1. 确定项目的范围 2. 识别项目于系人、决策人 和逐级程序 3. 制定详细的任务清单（工 作分解结构） 4. 估计时间要求 5. 制定初步的项目管理流程 图 6. 确定所需的资源和预算 7. 评估项目要求 8. 识别和估计项目风险 9. 制定应急计划 10.明确相互关系 11.确认并跟踪项目的关 键里程碑 12.参与项目阶段的评估 13.保障所需的资源 14.管理变更控制过程 15.汇报项目状态 资料来源： <<为未来打基础：信息技术业的能力标准 >> V， Belleview，华盛顿州， 1997。 2.4项目经理的职能 有效的项目经理与低效的项目经理 有效的项目经理 低效的项目经理 ? 有表率作用 表率作用差 ? 有洞察力 不自信 ? 技术过硬 缺乏专业技能和经验 ? 有决断力 不善于沟通 ? 善于沟通 不会激励他人 ? 善于激励他人 ? 必要时能够支持上级领导 ? 支持团队成员 ? 鼓励新观念新思想 资料来源： Zimmerman和 Yasin， l998。 2.5社会经济的影响 社会经济领域的现状和发展趋势可能对项目产生的影响 1、标准和规则：可选 —强制 2、国际化 3、文化影响 1989-1993美国经济萧条前后对项目管理的影响 因素 萧条前 萧条后 战略重点 短期 长期 组织构建 获得权利 靠近客户 管理重点 人员管理 工作及成果管理 培训重点 数量化 定性的 风险分析 最低限度 协同一致 权威 明示的 潜在的 团队建设 职能团队 跨职能团队 第三章项目管理过程 3.1项目管理过程 3.2过程组 3.3过程关系及相互作用 3.1项目管理过程 定义：为实现项目目标而进行的一系 列相互联系的过程，包括启动、计划、 执行、控制和收尾五个过程组。 3.2过程组 项目管理过程可被分成 项目管理过程可被分成 5个过程组，每个过 个过程组，每个过 程组有一个或多个管理过程 程组有一个或多个管理过程 ： ： ? 启动过程 启动过程 ：确定一个项目或一个阶段可以开始了，并要 求着手实行 ； ? 计划过程 计划过程 ：进行计划并且保持一份可操作的进度安排， 确保实现项目的既定商业目标 ； ? 执行过程 执行过程 ：协调人力和其它资源，执行计划 ； ? 控制过程 控制过程 ：通过监督和检测过程确保项目达到目标，必 要时采取一些修正措施 ； ? 收尾过程 收尾过程 ： 取得项目或阶段的正式认可并有序地结束 该项目或阶段 项目不同时间点的资源投入 活 动 的 层 次 启动过程 计划编 制过程 实施过程 控制过程 收尾过程 阶段结束阶段开始 时间 3.3过程之间的联系 启动过程 计划过程 控制过程 执行过程 收尾过程 过程相互作用 在每个过程组中，各个过程通过他们的 输入和成果进行联系。我们可用下列术语 描述每一个过程： ? 输入 —书面文件或书面表述的工作任务，下达开 始工作的指令 ； ? 工具和技术 —由输入产生输出的途径（各种方法） ? 输出 —书面文件或书面表述的工作成果，它们是 每个程序结束后得出的结果 。 项目各个阶段的交互作用 阶段之间相互影响 启动过程 计划过程 控制过程 执行过程 收尾过程 启动过程 计划过程 控制过程 执行过程 收尾过程 设计阶段 实施阶段 项目过程与项目知识领域的关系 项目过程与项目知识领域的关系 知识领域 项 目过 程 起始过程 计划过程 执行过程 控制过程 收尾过程 项目整体 管理 项目计划 制定 项目计划 执行 整体变更 控制 范围管理 起始 范围计划 范围定义 范围验证 范围变更 控制 时间管理 活动定义 活动顺序 活动历时 估计 进度安排 进度控制 成本管理 资源计划 成本估算 成本预算 成本控制 知识领域 项 目过 程 起始过程 计划过程 执行过程 控制过程 收尾过程 质量管理 质量计划 质量保证 质量控制 人力资源 管理 组织计划 成员物色 团队建立 沟通管理 沟通计划 信息发布 绩效报告 管理终止 风险管理 风险管理 计划 风险识别 风险定性 分析 风险定量 分析 风险应对 计划 风险监督 与控制 采购管理 采购计划 揽货计划 揽货 货源选择 合同结束 第四章项目整体管理 ?4.1整体管理 ?4.2项目计划的制定 ?4.3项目计划的执行 ?4.4变更控制 ? 4.5IT项目中的变更控制 ?4.6软件配置管理 4.1 项目整体管理 ? 含义： 在项目生命周期中协调所有其他的知识领域所涉 及的任务。确保项目的各要素在正确的时间结合到一起， 以成功的完成项目。 ? 原则： ? 优秀的项目经理 ? 让项目干系人满意 – 界面管理：识别和管理项目不同要素间的相互 作用点。 – 不仅注重内部协调，也注重外部协调 4.2项目计划的制定 ? 4.2.1项目计划 ? 4.2.2项目干系人分析 项目开发计划（ GB8567—88） ? ? 1.1编写目的 ? 1.2 背景 ? 1.3定义 ? 1.4参考资料 ? 2项目概述 ? 2.1工作内容 ? 2.2主要参加人员 ? 2.3产品 ? 2.3.1程序 ? 2.3.2文件 ? 2.3.3服务 ? 2.3.4非移交的产品 ? 2.4验收标准 ? ? 2.6本计划的批准者和批准 日期 ? ? 3.1工作任务的分解与人员 分工 ? 3.2接口人员 ? 3.3进度 ? 3.4预算 ? 3.5关键问题 ? 4支持条件 ? 4.1计算机系统支持 ? 4.2需由用户承担的工作 ? 4.3由外单位提供的条件 ? 5专题计划要点 2.5完成项目的最迟期限 1引言 3实施计划 IEEE软件项目管理计划 1、介绍 项目概述 项目可交付成果 计划的制定过程 参考资料 定义和术语说明 2、项目组织 过程模型 组织结构 组织界限和界面 项目责任 3、管理过程 管理目标优先级 假设和约束 风险管理 监督与控制机制 人员计划 4、技术过程 方法、工具和技巧 软件文件 项目各项辅助职能 5、工作包、进度和预算 工作包 依赖关系 资源要求 预算与资源分配及进度计划 NASA软件项目计划内容 1 ? 1. INTRODUCTION ? 1.1 Purpose — brief statement of the project's purpose. ? 1.2 Background ? 1.3 Organization and Responsibilities ? 1.3.1 Project Personnel ? 1.3.2 Interfacing Groups ? 2. STATEMENT OF PROBLEM ? 3. TECHNICAL APPROACH ? 3.1 Reuse Strategy — description of the current plan for reusing software from existing systems. ? 3.2 Assumptions and Constraints — that govern the manner in which the work will be performed. 软件项目计划 2 ? 3.3 Anticipated and Unresolved Problems. ? 3.4 Development Environment — target development machine and programming languages. ? 3.5 Activities, Tools, and Products — for each phase, a matrix showing: a) the major activities to be performed, b) the development methodologies and tools to be applied, and c) the products of the phase Includes discussion of any unique approaches or activities. ? 3.6 Build Strategy. 软件项目计划 3 ? 4. MANAGEMENT APPROACH ? 4.1 Assumptions and Constraints —including project priorities. ? 4.2 Resource Requirements — tabular lists of estimated levels of resources required ? 4.3 Milestones and Schedules — list of work to be done, who, and when ? 4.4 Metrics ? 4.5 Risk Management — statements of each technical and managerial risk or concern and how it is to be mitigated. 软件项目计划 4 ? 5. PRODUCT ASSURANCE ? 5.1 Assumptions and Constraints. ? 5.2 Quality Assurance (QA) — table of methods and standards used to ensure the quality of the development process and products (by phase). ? 5.3 Configuration Management (CM) — table showing products controlled, tools and procedures used to ensure the integrity of the system configuration: ? 6. REFERENCES ? 7. PLAN UPDATE HISTORY — development plan lead sheets from each update indicating which sections were updated. 4.2.2项目干系人分析 ahmed susan eric mark david 组织 内部上级 项目组 项目组 供应商 内部其他项目 的经理 角色 发起人 DNA专家 首席程序 员 提供仪器 硬件 竞争资源 情况 苛求，关注 细节，斯坦 福 MBA 聪明，生物学 博士，易于和 作，有个 8岁 小孩 最棒的程 序员，有 幽默感 项目能使 他赚很多 钱 好人，老职 员，三个小 孩上大学 利益程 度 很高 很高 高 很 高 中等以下 影响程 度 很高； 课题专家，成 败关键 高，难以 代替 低，可替 代 中等以下 关系建 议 经常汇报工 作，遵照指 示，快速实 施 确保其领导试 验，可以占用 一点下班时间 让其开心 股权激励 喜欢墨西 哥菜 给其足够 的备货时 间 其项目处于 次要地位， 可以从他那 里学到知识 4.3项目计划实施的工具和技术 1、 一般管理技术。诸如领导 、 沟通和谈判。 2、 IT技能和知识。 3、工作授权体系。批准项目工作的一个正式程序， 用来确保合格的人员、按着恰当的时间、以合适的 顺序完成工作。 典型的授权形式是开始某具体活动或工作包的书 面授权。授权体系的设计应使得提供的控制与控制 成本相平衡。例如，对许多小型项目，采用口头授 权更为合适。 4、执行状况检查例会。 5、项目管理信息系统或项目管理软件。 4.4整体变更控制 整体变更控制所关心的是： ? 对变更因素施加有利的影响； ? 确定变更的发生； ? 当变更已经发生和发生时对实际变更进行 管理。 ? 下图描述了知识领域间的变更协调，例如 一个建议的进度变更通常将影响到项目成 本、风险、质量和人员配置。 协调涉及整个项目的变更 执行情况报告 整体变更控制 辅助变更控制 ?范围变更控制 ?进度变更控制 ?费用变更控制 ?质量控制 ?风险变更控制 ?合同管理 4.5IT项目中的变更控制 ? 项目管理是一个就项目目标及各干系人期 望进行不断沟通和协调的过程。 ? ----变更是贯穿于整个项目的 ? 例如，软硬件的革新 变更控制系统 ? 变更控制系统是一个正式的、文档化的过程，它定义了正式 的项目文档变更和变更的方式。变更控制系统包括文档工作、 跟踪系统。 ? 变更控制委员会（ CCB， configuration control Board），负 责批准或否决项目变更请求。 –48小时政策 ? 配置管理（ configuration management）：整体管理中的重 要管理方法，用来确保项目产品描述的正确性和完整性。 ? 沟通 2005-7-20 4.6软件配置管理 Software ConfigurationManagement ? 4.6.1概述 ? 4.6.2术语 ? 4.6.3软件配置管理的工作内容 2005-7-20 软件配置管理 ? 软件配置管理（ Software Configuration Management），是一个控制软件系统演变的学 科。 IEEE ? 正如 Pressman所说的： “软件配置管理是贯穿于 整个软件过程中的保护性活动，它被设计来（ 1） 标识变化，（ 2）控制变化，（ 3）保证变化被适 当的发现，以及（ 4）向其他可能有兴趣的人员 报告变化。 ” ? 软件配置是指一个软件产品在软件生存周期各个 阶段所产生的各种形式（机器可读或人工可读） 和各种版本的文档、程序及其数据的集合。该集 合中的每一个元素称为该软件产品软件配置中的 一个配置项（ configuration item）。 2005-7-20 术语 ? 配置项 configuration item ? 基线（ Base Line） ? 配置标识 configuration identification ? 库 /配置库 Library 2005-7-20 配置项 configuration item ? Pressman对于 SCI给出了一个比较简单的定义： “软件过程的输出信息可以分为三个主要类别： ? （ 1）计算机程序（源代码和可执行程序）， ? （ 2）描述计算机程序的文档（针对技术开发者和 用户），以及 ? （ 3）数据（包含在程序内部或外部）。 ? 这些项包含了所有在软件过程中产生的信息，总 称为软件配置项。 ” 2005-7-20 基线（ Base Line） ? 软件配置管理引入了 “基线（ Base Line） ”这一概念。 ? IEEE对基线的定义是这样的： “已经正式通过审核批 准的某规约或产品，它可作为进一步开发的基础，并 且只能通过正式的变化控制过程改变。 ? 所有需加以控制的配置项分为基线配置项和非基线配 置项两类： ? 基线配置项可能包括所有的设计文档和源程序； ? 非基线配置项可能包括项目的各类计划和报告。 2005-7-20 配置标识 configuration identification ? 所有配置项都都应按照相关规定统一编号， 按照相应的模板生成，并在文档中的规定 章节（部分）记录对象的标识信息。在引 入软件配置管理工具进行管理后，这些配 置项都应以一定的目录结构保存在配置库 中。 ? 所有配置项的操作权限应由 配置管理员 CMO严格管理，基本原则是：基线配置项 向软件开发人员开放读取权限；非基线配 置项向 PM、 CCB及相关人员开放。 2005-7-20 配置库 ? 概念：存储所有的配置管理信息和文件的总体。 ? 任何库中的文件都被视为在确定的配置管理之下。库中的 文件不能被更改。任何更改被视为创建了一个新版本的文 件。 ? 当工作于一个文件时，用户将某个版本的文件导入工作目 录，然后开始工作，处理完了，然后将文件导回库中。这 样就生成了这个文件的新版本。导出的文件自动被锁定直 到文件重新被导入，一个版本号自动与新版本文件相关联。 ? 软件的版本号自动生成，库中不但存储了文件的不同版本， 更改的理由，而且存储谁在什么时候替换了某个版本的文 件等文件历史信息。 ? 对于每个不同版本文件，只是版本间实际的差异才存储起 来：这称为增量。 ? 总而言之，库捕捉配置管理信息并把不同版本的文件存储 为不可修改的对象 2005-7-20 配置管理工作的内容 ?1． 配置库的设置 ?2． 工作空间管理 ? 3． 版本控制 ? 4．变更控制 ? 5．状态报告 ? 6．配置审计 2005-7-20 1． 配置库的设置 ? 决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组 织形式：按配置项类型分类建库和按任务建库。 按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，它 适用于通用的应用软件开发组织。这样的组织一般产品的继承性较强， 工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于 对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由 于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能 会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。 而按任务建立相应的配置库则适用于专业软件的研发组织。在这样的 组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以 就没有必要把配置项严格的分类存储，人为增加目录的复杂性。因此， 笔者认为特别是对于研发性的软件组织来说，还是采用这种设置策略 比较灵活。 按项目分类 Project Program Doc Readme .txt Module 1 Module 2 Module 3 Module n File 1 File 2 File 3 File n Readme .txt … ... … ... ... ... ... File 1 File 2 File n File 1 Readme .txt … . .. ... ... 2005-7-20 2． 分支的划分 ? 私有分支 私有分支对应的是开发人员的私有开发空间。除该开发人员外，其他人员均 无权操作该私有空间中的元素。 集成分支 集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都 从该分支获得。即各开发人员必须将私有工作空间中的开发成果归并 （ Merge）到该分支后才能进入下一个开发活动。所有涉及多人协调的开发 工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成 分支的读写权限，而其他成员只有只读权限。该分支的管理工作由系统集成 员及相关指定人员负责。 公共（主干）分支 公共分支对应的是整个软件开发组织的公共空间。各个开发小组在现阶段的 任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时， 以该分支上的版本为准。该分支对组织内的全体软件人员开放只读权限。该 分支的管理工作由系统集成员负责。 上面定义的 3类工作空间（分支）由配置管理员统一管理，根据各开发阶段的 实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发 生时，应及时做好基线的推进。 2005-7-20 3．版本控制 ? 版本控制是软件配置管理的核心功能。所有置于配置库中 的元素都应自动予以版本的标识，并保证版本命名的唯一 性。版本在生成过程中，自动依照设定的使用模型自动分 支、演进。除了系统自动记录的版本信息以外，为了配合 软件开发流程的各个阶段，我们还需要定义、收集一些元 数据（ Metadata）来记录版本的辅助信息和规范开发流程， 并为今后对软件过程的度量做好准备。当然如果选用的工 具支持的话，这些辅助数据将能直接统计出过程数据，从 而方便我们软件过程改进（ Software Process Improvement， SPI）活动的进行。 对于配置库中的各个基线控制项，应该根据其基线的位置 和状态来设置相应的访问权限。一般来说，对于基线版本 之前的各个版本都应处于被锁定的状态，如需要对它们进 行变更，则应按照变更控制的流程来进行操作。 版本 1.0 版本 版本 1.1 版本 版本 1.2 版本 版本 2.0 版本 版本 2.1 版本 版本 1.3 版本 版本 1.4 版本 版本 1.1.1 版本 版本 1.1.2 版本 演变图显 示了软件 修改情况 变种 1 2 3 54 2005-7-20 4．变更控制 ? 在本文的前面的部分中，已经把 SCI分为基线配置项和非 基线配置项两大类，所以这里所涉及的变更控制的对象主 要指配置库中的各基线配置项。 变更管理的一般流程是： A) （获得）提出变更请求； B) 由 CCB审核并决定是否批准； C) （被接受）修改请求分配人员为，提取 SCI，进行修改； D) 复审变化； E) 提交修改后的 SCI； F) 建立测试基线并测试； G) 重建软件的适当版本； H) 复审（审计）所有 SCI的变化； I) 发布新版本。 在这样的流程中， CMO通过软件配置管理工具来进行访 问控制和同步控制，而这两种控制则是建立在前文所描述 的版本控制和分支策略的基础上的。 SCIs SCIs SCIs SCIs 正式 技术 评审 软件工 程任务 SCIs SCM 控制 存储 检入 检出 项目数据库 2005-7-20 5．状态报告 ? 配置状态报告就是根据配置项操作数据库中的记录来向管 理者报告软件开发活动的进展情况。这样的报告应该是定 期进行，并尽量通过 CASE工具自动生成，用数据库中的 客观数据来真实的反映各配置项的情况。 配置状态报告应根据报告应着重反映当前基线配置项的状 态，以作为对开发进度报告的参照。同时也能从中根据开 发人员对配置项的操作记录来对开发团队的工作关系作一 定的分析。 配置状态报告应该包括下列主要内容： A) 配置库结构和相关说明； B) 开发起始基线的构成； C) 当前基线位置及状态； D) 各基线配置项集成分支的情况； E) 各私有开发分支类型的分布情况； F) 关键元素的版本演进记录； G) 其它应予报告的事项。 2005-7-20 6．配置审计 ? 配置审计的主要作用是作为变更控制的补充手段， 来确保某一变更需求已被切实实现。 ? 总之，软件配置管理的对象是软件研发活动中的 全部开发资产。因此，软件配置管理的主要任务 也就归结为以下几条：（ 1）制定项目的配置计划； （ 2）对配置项进行标识；（ 3）对配置项进行版 本控制；（ 4）对配置项进行变更控制；（ 5）定 期进行配置审计；（ 6）向相关人员报告配置的状 态。 第五章 需求与项目范围定义 ?5.1需求定义 ?5.2范围管理概述 ?5.3项目范围定义 5.1.1定义需求时的问题 ? 需求膨胀 –"把海水煮沸 "，项目范围不断扩大，最终导致偏离原来 的项目目标 ? 需求曲解 –a) 需求镀金。对用户需求进行了包装和拔高， “用户需 要的是一辆自行车，而不是宝马 ”。 –b)选择性地过滤用户的需求， “对一个拿着榔头的 4岁小 孩来说，满世界都是钉子 ”，需求分析人员可能因为自 己的价值观而片面分析问题。 ? 需求分析人员过早给出解决方案，失去了寻找更 好解决方案的机会 需求的曲解给项目带来的灾难 5.1.2定义需求时的原则 ? Traceable（可追溯） ：所有需求的来源都要明确，应可追溯到其他相 关文档。 ? Tenable（合理） ：所表述的需求必须是可实现的和可操作的。 – 能否在项目预算范围内，利用有限的资源 ，按时实施这些需求？一条需求是否与 其他需求有冲突？是不是正当需求？需求 实际上都应是必要的。也许需求用 "将 "来 描述更好一些，也就是指，导向性或非基 本功能。某个需求是否只是一般描述， 与系统功能没有什么关系？某个需求是否 超出系统控制范围，或根本不是需求？ 对每个需求，是不是都能找到用途 或用户？有没有存在的理由？ ? Testable（可测试） ： – 确定每一条需求都可以通过某种方法去测 试其是否能实现。是否已量化？容错性 和误差范围是否说明？能不能想到一个合 理的方法去测试它？这个需求的结果是 否可见？ ?Tool（工具性） ：需求管理的工具化。 ? Terminology（项目术语表） – 创建并维护项目或公司的词汇表。只要一 个行话，或一个单词、或一个缩略语在 项目中表示他们通常意义之外的意思，就 应该把他们纳入词汇表。词汇表应列为 需求文档的一项或作为需求文档的参考项目。 5.1概述 ? 项目范围：指产生项目产品所包括的所有需要完 成的工作 ,以及产生这些产品的所有过程 . ? 项目范围管理：定义及控制项目应该包括或不包 括的内容。 ? 产品范围 —产品或服务所包含的特征或功能。 ? 项目范围 —为交付具有规定特征和功能的产品或 服务所必须完成的工作。 ? 产品范围的完成是对照产品要求进行衡量的，而项目范围的完成是对 照项目计划进行衡量的，两种范围管理应该很好地结合起来，以确保 项目所做的工作能够取得规定的产品 。 项目范围管理 ? 启动 ? 范围计划编制 ? 范围定义 ? 范围核实 ? 范围变更控制 项目范围管理概要 1 一、启动 1、输入： ?产品描述 ?项目章程 ?约束条件 ?假设 2、技术和工具 ?项目分析 ?利益 /成本分析 ?其他备选技术识别 ?专家判断 3、输出 ?范围说明 ?辅助说明 ?范围管理计划 二、范围计划 三、范围定义 1、输入： ?范围说明 ?约束条件 ?其他计划输出 ?历史信息 2、技术和工具 ?工作分解结构模版 ?分解 3、输出 ?工作分解结构 1、输入： ?产品描述 ?战略计划 ?项目选择标准 ?历史信息 2、技术和工具 ?项目选择方法 ?专家判断 3、输出 ?项目章程 ?项目经理鉴定和委派 ?约束条件 ?假设 项目范围管理概要 2 四、范围核实 1、输入： ?工作结果 ?产品文件 2、技术和工具 ?检验 3、输出 ?正式接收 五、范围变更控制 1、输入： ?工作分解结构 ?执行报告 ?变更需求 ?范围管理计划 2、技术和工具 ?范围变更控制系统 ?绩效测量 ?附加计划 3、输出 ?范围变更 ?纠正行为 ?经验总结 范围定义 项目范围定义把主要的可交付成果分解 成较小的且更易管理的单元，以达到如下 目的： ? 提高对成本、时间及资源估算的准确性。 ? 为绩效（ Performance）测量和控制定义一 个基线（ baseline）。 ? 便于进行明确的职责分工。 恰当的范围定义是项目成功的关键因素之一。 工具和技术 ? WBS (Work Breakdown Structure)模版 – 来源于组织或者前面的类似项目 ? 分解方法 WBS的作用 ? 1． WBS－－信息沟通的共同基础 　　在现代大型复杂项目中，一般要涉及大量的资源和时间。这就要求所有 的有关集团要有一个共同的信息基础，一种各有关集团或用户从项目一开始 到最后完成都能用来沟通信息的工具。这些集团包括：业主、供货商、承包 人、项目管理人员、设计人员以及政府有关部门等等。而一个涉及恰当的 WBS将能够使这些集团或用户有一个较精确的信息沟通联接器，成为一种相 互交流的共同基础，因为 WBS具有编码结构及代码字典，利用 WBS作为基础 来编制预算、进度和描述项目的其他方面能够使所有与项目有关的人员或集 团都明了为完成项目所需作的工作以及项目的进程。 2． WBS－－系统综合与控制的手段 　　我们已经知道，典型的项目控制系统包括进度、费用、会计等不同的子 系统。 WBS的应用可以将这些子系统很好地综合起来。 　　 工作分解 结构 （WBS) 项目分解结构的主要用途是： （ 1）明确和准确说明项目的范围； （ 2）为各独立单元分派人员，规定这些人员的相应职责； （ 3）针对各独立单元，进行时间、费用和资源需要量的 估算， （ 4）确定项目进度测量和控制的基准； （ 5）将项目工作与项目的财务帐目联系起来； （ 6）自上而下将项目目标落实到具体的工作上 （ 7）确定工作内容和工作顺序； （ 8）估计项目整体和全过程的费用。 WBS实例 活动 1:1100 产品： 1000 活动 2:1200 活动 3:1300 任务 1:1210 任务 2:1220 任务 3:1230 某技术改造项目工作分解结构 技术改造项 目 可行性研究 审批 设计 筹资 实施 安装完成 I改建施工 O试运行 N软件调试 M职工培训 L设备安装 E改建筹资 K软件编程 J设备改造G设备筹资 B 审批 F设备设计 D改建设计 H软件系统 设计 C设计任务书 A.可行性研究 项目工作分解结构模板 XX信息系统开发项目 项目管理需求阶段系统设计系统开发项目收尾系统集成 需求分析 需求验证 初步方案 设计 网络系统 设计 设备选型 应用系统 设计 软件开发 采购 内部测试 硬件集成 网络集成 软件集成 培训 外部测试 初步验收 试运行 系统终验 a) 项目的分级树形结构图 121 基本需求 XX软件开发与实施 110 项目管理 120 确定需求 130 软件设计 140 实现 160 系统安装 150 测试 122 详细需求 131 功能设计 132 系统设计 141 模块定义 142 接口定义 143 程序编码 151 内部测试 152 集成测试 153 报告编写 161 软件安装 162 系统调测 163 培训 ? 这种表示层次清晰、直观、结构性强， 不容易修改，对于大而复杂的项目难于 表达其全景。 b) 缩进图表 项目名称： 项目经理： 单位名称： 制表日期： 工作分解结构 工作编号 工作名称 负责人 资源描述 …… 1.2 1.2.1 1.2.2 1.3 1.3.1 1.3.2 …… WBS一般方法 ?1．类比法 　 类 比法就是以一个类似项目的 WBS为基础，制定本项目的工作分 解结构。大型客机 --〉新型战斗机时。 2．自上而下法 　 自 上而下法常常被视为构建 WBS的常规方法，即从项目最大的单 位开始，逐步将它们分解成下一级的多个子项。 ?3．自下而上法 　 自 下而上法，是要让项目团队成员从一开始就尽可能的确定项目有 关的各项具体任务，然后将各项具体任务进行整合，并归总到一个整 体活动或 WBS的上一级内容当中去。 – 自下而上法一般都很费时，但这种方法对于 WBS的创建来说，效果特别 好。项目经理经常对那些全新系统或方法的项目采用这种方法，或者用 该法来促进全员参与或项目团队的协作。 ?4．使用指导方针 　 如 果存在 WBS的指导方针，那就必须遵循这些方针。 – 美国国防部 DOD为国防装备项目定义的许多工作分解结构标准。 　 WBS设计 -划分方法 ? 现在可以对不同的 WBS划分方法进行分析。 ? 按照系统功能划分项目。 – 应当说这是一种最自然的划分方法，优点是容易让人 接受，缺点是不易协调。财务子系统，销售子系统 ? 按照项目的不同阶段划分 WBS结构 – 有利于项目管理者控制中间结果。对那些不确定性比 较大的项目来说，项目最后的结果往往是未知的，控 制项目的唯一方法就是控制中间结果的进度和质量， 当然阶段的划分应该是可测量的。按照阶段划分项目 有助于管理者在不同阶段控制中间成果同时不至于使 项目管理者陷入到项目细节中去。 　 WBS设计 -WBS步骤 ?1．先明确并识别出项目的各主要组成部分，即明确项目的主要可交付 成果。一般来讲，项目的主要组成部分包括项目的可交付成果和项目管 理的本身。 – 在进行这一步时需要解答的问题是：要实现项目 的目标需要完成哪些主要工作？（一 般情况下，项目的主要工作是指贯穿项目始终的 工作，它在项目分解结构中主要被列 在第二层。） ?2． 第二步的工作是：确定每个可交付成果的详细程度是否已经达到了足 以编制恰当的成本和历时估算。对每个可 交付成果，如果已经足够详细， 则进入到第四步，否则接着进入第三步 ——这意味着不同的可交付成果 可能有不同的分解层次。 ?3． 确定可交付成果的组成元素。组成元素应当用切实的、可验证的结果 来描述，以便于进行绩效测量。 – 这一步要解决的问题是：要完成上述各组 成部分，有哪些更具体的工作要做。 ?4．核实分解的正确性。 – 即需要回答下列问题：（ 1）最底层项对项目分解来说是否是必需而且充分的呢？如 果不是，则必须修改组成元素（添 加、删除或重新定义）；（ 2）每项的定义是否清 晰完整？如果不完整，描述则需要修改或扩展；（ 3）每项是否都能够恰当地编制进 度和预算？是否能够分配到接受职责并能够圆满 完成这项工作的具体组织单元（例如 部门、项目队伍或个人）？如果不能，需要做必 要的修改，以便于提供合适的管理控 制。 企业内部网 WBS 企业内部网 WBS 表格缩进形式的企业内部网 WBS ?1.0概念 ?1.1评价现有系统 ?1.2确定要求 ? 1.2.1确定用户要求 ? 1.2.2确定内容要求 ? 1.2.3确定系统要求 ? 1.2.4确定服务器所有人的要求 ?1． 3确定特定功能确定需求 ?1． 4定义风险和风险管理方法 ?1． 5制定项目计划 ?1． 6组建网站开发小组 ?2.0站点设计 ?3.0站点开发 ?4.0投入使用 ?5.0维护 WBS设计 -WBS的结构 ? 结构 – 等级状或树状来构成 ： 子项目 --〉概要任务 --〉 工作包 – 分层（ 4-6） ? 代码 – 代码设计与结构设计是有对应关系的 – 1112， 1.2.3， f123等 ? 表现形式 – 树图分支，缩进式层次结构 分解标准应统一 ?(写一本书 )按照生命期分解 – 写草稿 – 审查草稿 – 定稿 ? 根据组成部分 – 第一章 – 第二章 – 第三章 分解标准不统一 ? 不能同时使用两种方法 – 第一章 – 第二章 – 第三章 – 审查草稿 – 定稿 检验分解结果的标准 ? 最底层要素是否有重复的 ? 最底层的要素是否是实现目标的成分必要 条件 ? 每个要素是否清晰完整定义 ? 最底层要素是否有定义清晰的责任人 ,是否 可以进行成本估算和进度安排 WBS原则 ?1．一个单位工作任务只能在 WB S中出现在一个地方 ?2．一个 WB S项的工作内容是其下一级各项工作之和。 ?3． WB S中的每一项工作都只由一个人负责，即使这项工作要多人来 做，也是如此。 ?4． WB S必须与工作任务的实际执行过程相一致。 WBS首先应当服 务于项目组，可行的话，再考虑别的什么目的。 ?5．项目组成员必须参与 WB S的制定，以确保一致性和全员参与。 ?6．每一个 WB S项都必须归档，以确保准确理解该项包括的和不包括 的工作范围。－ ?7．在正常的根据范围说明书对项目工作内容进行控制的同时，还必 须让 WB S具有一定的灵活性以适应无法避免的变更需要。 ?8。最低层是可控的和可管理的，最好不要超过 7层 Project软件 ? 工作分解结构清单：写一部间谍小说 ? 10.0.0 研究背景材料 ? 10 .1.0 去图书馆 ? 10.1.1 阅读有关美苏关系的书 ? 10.1.2 阅读其他间谍小说 ? 10.1.3 阅读时事期刊，摸清当今有趣的热门话题 ? 10.1.4 找有关城市的行政区划图（如莫斯科、华盛顿） ? 10.2.0 造访相关政府官员 ? 10.2.！访问情报机构 ? 10.2.2 访问军事机构 ? 10.2.3 访问政府机构，包括美国联邦调查局和国务院 ? 10.2.4 采访当地警察 ? 11.0.0 故事纲要 ?11.． 0 粗略情节 ? 11.2.0 详细情节 ? 12.0.0 写小说 ? 12 .1.0 第一章 ? 12.1.1 小孩子在波托马可河发现尸体 ?12 .. 确认尸体是克格勃人员 ? 12.1.3 美国联邦调查局 Frank Masters上演了这一事件 ? 12.1.4 Masters的家庭 ? 12.2.0 第二章 ?12.1［依此类推，列出所有章节的内容〕 ? 13.0.0 与出版商联系 ? 13.1.0 确定合适的出版商 ? 13.1.1 参考《作家指南》，了解出版商的要求 ? 13.1.2 与对付出版商有经验的作者交谈 ? 13.1.3 联系四个合适的出版商，并与编辑初步讨论书稿问题 1320给有希望的出版商送三章节的样本 图表