XX集团项目经理手册.pdf

东软项目经理手册 （解决方案业务线） 东软集团股份有限公司 2009-2-2 版权声明 东软项目经理手册的版权归东软集团股份有限公司所有。未经东软集团股份有限 公司的书面准许，不得将本规范的任何部分以任何形式、采用任何手段（电子的或机械的， 包括照相复制或录制）、或为任何目的，进行复制或扩散。 版权所有，翻制必究。 序 项目管理是一门复杂的科学和艺术，其成败取决于很多因素，但最关键的因素是需要 一个称职的项目经理（pm/psm），做一名合格或优秀的 pm/psm 非常不容易，需要具有 项目管理的科学、专业能力，更需要有很强的责任心和沟通艺术。一名优秀的 pm/psm 不 仅仅是开发实施流程规范的执行者，更多的是项目的经营者，他能遵守实施方法论，综合 考虑技术和业务因素，制定出符合实际的项目计划并恪守项目进度；能够合理分派工作， 调动并发挥每一个项目组成员的潜力；能够主动与客户沟通，听取客户的建议，想在客户 所想之前，提升客户满意度，将项目实施过程变成再销售过程；项目经理要会灵活运用方 法和技巧，注重关键里程碑的目标导向，重视对客户培训和内部培训，关注上线后的服务 支持和维护计划；作为经营者角色，就需要思考如何做才能够达成项目的最佳绩效，学会 精打细算，学会最佳调动资源，学会控制项目实施成本和风险，要让你所负责的项目能赚 钱。本手册给出的是东软项目经理应该具备的基础能力和有关要求，期待你们在做项目过 程中执行并贡献更多的实践案例。 前 言 欢迎您加入东软项目经理团体！ 当您翻开本手册的第一页，您已经或即将成为东软的项目（软件）经理，将带领团队 与员工一起共赴“沙场”，为了我们和公司共同的事业与梦想，“浴血奋战”、无怨无悔！ 您的经验和智慧将成为公司快速发展过程中不可缺少的财富，您也将成为公司和部门的中 流砥柱，公司将本着“以人为本、追求个人与社会的共同发展”的企业理念，协助您更好 更快的成长。 这本项目经理手册，将指导您了解公司目前的项目管理流程及相关规定，同时对一些 常见问题给出一些建议的做法，希望能够起到抛砖引玉的作用。同时本手册只针对国内相 关部门，暂不涉及外包领域。 尽管本手册注入了我们大量的心血，但由于时间、人力等资源的有限，疏忽纰漏之处 在所难免，恳请读者朋友提出建议和批评。联系信箱： ，我们将虚心 接受您的意见，在下次改版中进行调整和优化。同时，本手册在编写过程中得到了无数幕 后人员的精力的倾入，在此，对他们的辛劳一并表示衷心感谢！ 项目经理手册编写小组 - i - 阅读指南 手册目标 本手册主要对东软集团股份有限公司、国内各业务线的所有项目（软件）经理、尤其是 即将进入该岗位的项目管理经验尚不丰富的员工， 对公司项目管理有个整体的初步认识， 并 进行部分经验分享。但由于实际情况千变万化，本手册很难一次做到面面俱到，需要逐渐完 善。 阅读对象 本手册是为东软集团股份有限公司、 国内各业务线的所有项目经理、 项目软件经理所编 写的。 手册构成 本手册由四部分组成： 1. 第1章， “项目管理知识体系概述”，简要介绍公司目前使用的项目管理知识体系。 2. 第2章，“工作环境”，指出项目经理工作的内外部工作环境，明确相关资源及接 口人，以便后续工作在需要资源时方便深入展开。 3. 第3章，“专业与行业知识”，其中，重要阐述了两部分，一是公司目前的项目管 理过程及体系文件等相关规定； 二是对一些实际常见问题给出一些建议， 但不是绝 对建议，因为每个项目的情况不同，我们在阅读时可以有所选择。 4. 第4章，“任职说明”，本章指出项目经理的工作内容和职责，同时对我们重点关 注的职位差异能力进行阐述。 手册约定 本手册遵循以下约定： 1. 手册中所提的“项目经理”也包含“项目软件经理”。 - i - 目目 录录 手册目标手册目标 i 阅读对象阅读对象 i 手册构成手册构成 i 手册约定手册约定 i 第 1 章第 1 章 项目管理知识体系概述项目管理知识体系概述 - 1 - 1.1 nup简介.- 1 - 1.2 qms2005 简介 - 2 - 1.3 cmm/cmmi简介 .- 2 - 第 2 章第 2 章 工作环境工作环境- 4 - 2.1 组织支撑.- 4 - 2.2 规章制度.- 4 - 2.3 系统工具.- 4 - 2.3.1 pm-online- 5 - 2.3.2 service-online- 5 - 2.3.3 其它- 5 - 第 3 章第 3 章 专业与行业知识专业与行业知识- 6 - 3.1 专业领域知识 .- 6 - 3.2 行业领域知识 .- 8 - 3.2.1 业务知识- 8 - 3.2.2 行业规则- 8 - 3.2.3 专业术语- 8 - 3.2.4 客户文化- 8 - 3.3 项目管理过程 .- 9 - 3.3.1 项目启动- 9 - 3.3.2 需求管理 - 11 - 3.3.3 项目策划- 16 - 3.3.4 设计- 19 - 3.3.5 编码- 20 - 3.3.6 测试- 21 - 3.3.7 软件实施- 24 - 3.3.8 验收- 30 - 3.3.9 项目总结- 32 - 3.3.10 风险管理- 33 - 3.3.11 沟通管理- 34 - 3.3.12 配置管理- 37 - 3.3.13 项目度量- 41 - 3.3.14 评审管理- 42 - 3.3.15 软件开发过程及主要输出物- 45 - 3.4 推荐的操作技巧 .- 45 - - ii - 3.4.1 项目启动- 46 - 3.4.2 需求管理- 47 - 3.4.3 项目策划- 51 - 3.4.4 软件实施- 53 - 3.4.5 验收- 55 - 第 4 章第 4 章 任职说明任职说明- 57 - 4.1 项目经理的工作职责和内容- 57 - 4.2 重点关注（职位差异）能力项- 57 - 4.3 培养途径.- 59 - 附录附录.- 60 - 附录a-缩略语- 60 - - - 1 - - 第1章 项目管理知识体系概述 第1章 项目管理知识体系概述 本章主要简单介绍目前公司所采用的项目管理体系。 项目管理知识体系是在项目管 理实践中成熟的理论、方法、工具及技术的总称。为提高在项目管理专业领域知识运用 的经济性和适用性， 公司对不同业务形态的项目提供了有针对性的项目管理方法论， 熟 悉并灵活运用这些知识体系是项目经理的基本功。 1.1 nup简介简介 nup(东软统一过程)的英文全称是neusoft unified process。nup是rup在东软的 实践、最佳经验的总结和扩展，是公司r&d项目中关于软件开发过程中对方法、过程、 文档、评估和度量等方面要求的体系文件。 nup的核心框架包括四个阶段(先启、精化、构建、产品化)、六个最佳实践(迭代 式开发、需求管理、以架构为中心、可视化建模、持续质量验证、变更管理)和九个规 程(业务建模、需求、分析设计、实现、测试、部署、配置与变更管理、项目管理、环 境)。nup的核心框架可参见图1-1。 图 1-1 除r&d项目外，nup同样也适应于在较高的技术复杂度(如：嵌入式、实时、分布 式、容错；定制、无先例、体系结构重建；高性能等方面要求)、较高的管理复杂度(大 规模、合约式、大量项目干系人)要求的项目。 - - 2 - - 1.2 1.2 qms2005 简介 qms2005 简介 qms(质量体系文件)的英文全称是quality management system。 qms中确定了公 司的质量方针、质量目标、质量管理的程序和要求，是实施满足iso 9001:2000标准的 质量管理体系。 适用于公司计算机软件产品、 系统解决方案、 技术服务项目的设计开发、 实现和维护过程。qms的当前版本是qms2005-a。其文件结构主要包括管理职责、资 源管理、产品实现和测量、分析与改进四个部分，同时对其中的19个过程的输入、输 出、规程、资源和测量进行了定义、规范，并对具体操作提供了方法和模板。qms2005 体系文件框架可参见图1-2。 图 1-2 qms目前在公司主要应用于行业解决方案项目。 1.3 1.3 cmm/cmmi简介 cmm/cmmi简介 cmm/cmmi(能力成熟度模型/能力成熟度集成模型)的英文全称是capability maturity model/capability maturity model integration ，是美国卡内基梅隆大学软件工 程学院(sei)开发的、作为采购商评估软件供应商的过程能力成熟度与组织成熟度的标 准。其中cmmi是一个针对产品与服务开发的过程改进成熟度模型，它包含开发与维护 活动的最佳实践，涵盖产品从起始到交付与维护的生命周期。同时cmmi构造了一个软 件过程成熟度框架，该框架描述了一条从无序的、混乱的过程到成熟的、有纪律的软件 - - 3 - - 过程的进化途径。cmmi将组织的软件过程的成熟度划分为不同的阶段，并将这些阶段 排序，每个阶段对应一个成熟度等级。包括五个成熟度等级，每一个等级都是进行下一 个等级的基础，标示由编号1 到5，如图1-3所示。 图 1-3 cmm/cmmi目前在公司主要应用于服务外包项目。 - - 4 - - 第2章 工作环境 第2章 工作环境 熟悉项目所处的内外部环境有利于后期管理工作的顺利开展，同时pm不仅要有运 用各种管理工具进行计划和控制的专业技术能力，还要有经营管理等其它方面的能力， 因此了解公司内部的工作环境是成为pm的第一项工作。 2.1 组织支撑组织支撑 目前公司组织是一个矩阵式的架构(如图2-1所示)， 大区/事业部是项目的执行主体， 各部门的pmo负责组织层面的项目管理职能，各职能部门能够为项目提供人力资源、 财务、技术等方面的支持与保障。 图 2-1 2.2 规章制度规章制度 pm作为项目组的领导者，除了需要遵循项目管理职业规范，还应该遵守公司相关 规范制度，包括： 员工手册、 公司外埠差旅费报销管理制度、 qms2005-a、 重大事件上报制度、客户现场工作规范、内部分包管理制度、公文管理 规范、公章管理制度、信息安全规范以及客户方的机房管理规范、信息安全 规范、现场工作规范等。 2.3 系统工具系统工具 在项目管理过程中，经常会用到一些系统工具来辅助进行项目管理，目前公司为 pm提供的项目管理工具主要有：pm-online、service-online等。 - - 5 - - 2.3.1 pm-online pm-online系统是公司为规范项目管理流程，控制项目执行过程，提高项目管理水 平， 为pmo工作者、 pm等相关人员提供的项目管理应用系统。 系统实现了从项目立项、 编制项目计划、计划评审、填写项目周报(在周报中可记录项目组成员工作量)、项目执 行过程跟踪、项目结项的项目管理全过程的监控和管理。 相关指引请参阅pm-online系统操作指引。 访问方式及访问地址： 1. 通过公司网站portal（）进行统一登陆访问； 2. 通过网址进行访问； 2.3.2 service-online service-online系统主要用于客户服务中心、各业务部门的客服或项目管理人员处 理客户提出的请求或问题、 进行工作分派并跟踪服务过程状态等工作， 系统中保留了完 整的服务过程记录。 service-online系统管理的业务范围主要针对小批量、短期的咨询、产品安装、售 后服务和技术支持服务等工作。 相关指引请参阅service-online操作手册、case管理办法。 访问方式及访问地址： 1. 通过公司网站portal（）进行统一登陆访问； 2. 通过网址进行访问； 2.3.3 其它 其它 其它日常工作一般还涉及如下信息系统工具， 均可通过公司网站portal （）进行统一登陆访问或通过如下域名进行登陆。 1. 邮件服务系统：； 2. 人力资源自助平台：； 3. 网上报销个人自助平台：； 4. tcoe技术经验交流共享：； - - 6 - - 第3章 专业与行业知识 第3章 专业与行业知识 3.1 专业领域知识专业领域知识 美国项目管理学会(project management institute，简称为pmi)提出了项目管理知 识体系指南（project management body of knowledge, 简称为pmbok）。在pmbok 中描述了有效的项目管理要求项目管理团队应具备的5个专业领域知识和技能(如图3-1 所示)：项目管理知识体系；应用领域知识、标准与规章制度；理解项目环境；通用管 理知识与技能；处理人际关系技能。 图 3-1 其中项目管理知识体系是项目管理职业的知识总和。pmbok的目的是识别项目管 理知识体系普遍公认为良好做法的那一部分。它是由九个知识域和五个过程组成(如图 3-2所示)：启动，计划，执行，控制，收尾。通过项目经理和项目组织的努力，运用系 统理论和方法对项目及其资源进行计划、组织、协调、控制，旨在实现项目特定目标的 管理方法。 - - 7 - - 图 3-2 具体涉及的项目管理专业知识技能和工具可参照pmbok。 - - 8 - - 3.2 行业领域知识行业领域知识 除具备系统的项目管理理论知识、技能外，pm还需具备行业知识。不同行业的项 目具备不同的行业特征， 如果缺少基本的专业知识和术语， 那么对专业性任务进行计划、 组织和协调都将十分困难；另外pm只有掌握了行业的专门知识技术才能够正确理解客 户需求，与客户进行高效沟通。 具体内容参照业务单位行业线。 3.2.1 业务知识 3.2.1 业务知识 作为项目经理， 通常需要了解甚至熟悉本项目应用领域的业务知识， 以便更加明确快速 的掌握客户需求及控制项目范围， 如果我们对业务领域有深刻的了解， 甚至能够称之为业务 领域“专家” ，那我们将更能得到客户的认可与信赖。 例如：在电力行业，国家发改委不定期发布相关行业定价规则，项目过程中应能够进行 相应的调整和设置。行业内部由于地区性的差异，营业规则会有不同程度的差别，我们在项 目中都需要提前了解和分析。 3.2.2 行业规则 3.2.2 行业规则 通常项目所在的业务领域都有一些行业规则规范，有国家发布的，也有行业领域、 企业等遵循标准和规章制度等， 甚至一些没有明确行文但是已经形成的规则， 这些也都 是项目或多或少应该遵循的， 对行业规则的了解和掌握有助于项目的通用性， 并能够得 到业内客户的认可。 3.2.3 专业术语 3.2.3 专业术语 对专业术语的掌握有助于同客户的沟通及对业务需求的理解， 同时可以规范化系统 的通用性。 例如：在erp领域,bom(bill of material)是指物料清单或产品结构表,so指销售订 单,po指采购订单。我们必须将本领域的专业术语熟记于心,同客户交流时才能游刃有 余。 3.2.4 客户文化 3.2.4 客户文化 了解和认同客户文化有助于同客户的沟通交流， 也便于把握客户的习惯、 心理等影 响因素，有助于项目的顺利达成。 - - 9 - - 3.3 项目管理过程项目管理过程 为了方便pm快速地熟悉项目管理全生命周期(如图3-3)，下面主要针对国内解决方 案形态的软件开发项目、参照qms2005-a质量体系对主要的项目管理过程进行介绍。 图 3-3 项目生命周期模型 3.3.1 项目启动 项目启动 过程概述 过程概述 合同签订后或合同提前执行申请批准通过后，大区/事业部根据合同或其它约定条 件参照pmo发布的项目立项规则进行项目立项、任命项目经理、组成项目团队， 明确项目组成员的不同责任人，将职员按专业特点化分，指派专门的责任人，分别对项 目经理、项目软件经理、测试、质量、采购等负责人进行任命；是项目正式启动的标志。 - - 10 - - 步骤 步骤 1. 下达项目任务书 项目管理部门在下达项目任务书时，与销售和开发负责人共同确定项目中的主 要角色，明确软件开发项目计划编制与评审的时间。 2. 编制项目启动计划 对于新产品开发和解决方案 r&d 项目必须编制项目启动计划。其他软件开 发项目如果项目启动阶段的任务很明确，可直接填写软件开发项目计划。 pm负责协调产品经理、 psm 、 cml 、 sqal 共同完成项目启动阶段的任务。 编制项目计划 ，包括启动阶段的资源调配、进度安排及提交工作产品。编制完成 的项目启动计划，参照公司和部门的评审规程提交项目管理部门组织评审。 3. 建立 sow（工作陈述） pm（或与客户共同）可在项目启动之后前建立有关的项目工作陈述（sow），以 此明确履行合同双方的责任与义务、 项目的范围与验收的基本准则，从而减少项目实 施过程中产生的冲突与变动， 避免交付期间产生的争议。sow也可以在合同签订阶段 完成。 4. 项目启动会议 在项目启动阶段， 项目经理需要组织项目组成员在公司召开项目内部启动会议。 之 后与用户一起召开项目外部启动会议。 项目内部启动会应让项目团队成员对项目的整体情况 （包括项目的建设背景、 项目 总体规划及项目团队成员等信息） 和各自的工作职责有一个清晰的认识和了解， 为日后 协同开展工作做准备；同时获得领导对项目资源的承诺和保障，激励项目团队的士气。 项目外部启动会让项目建设方、 用户方、 监理方等项目主要干系方对项目的整体情 况（包括项目的建设背景、项目总体规划及项目团队成员等信息）有一个清晰的认识和 了解，让项目各主要干系人清楚各自的职责和义务，让项目建设方、用户方在项目建设 的过程中所需要给予的支持和配合给予承诺， 从而让各方就项目建设的相关事宜达成共 识。 控制要点 控制要点 1. 项目启动阶段需要下达正式的项目任务书。 2. 项目启动阶段需要召开内、外部的项目启动会议。 - - 11 - - 输出产物 输出产物 表 3-1 过程 活动 过程输出产物 是否必要(?) 制定启动计划 项目计划 否 评审启动计划 评审记录 否 编写sow 项目sow 否 项目启动 召开项目启动会议 会议纪要 是 参与角色及职责 参与角色及职责 表 3-2 角色 职责 项目总监 批准项目立项，任命项目经理 公司/部门pmo 完成立项工作，下达项目经理任命书 pm/psm 协调产品经理、 psm 、 cml 、 sqal 共 同完成项目启动阶段的任务 3.3.2 需求管理 需求管理 过程概述 过程概述 按照项目任务书或项目启动计划 的要求， pm 负责全程的需求管理，组建需 求分析小组进行需求调研与分析。在需求分析阶段需要完成需求调研、需求分析、需求 评审等活动。完善的需求管理将明确项目的范围，有利于项目管理。 步骤 步骤 1. 需求管理： 需求开发与管理是软件项目中一项十分重要的工作， 需求管理的目的是保持项目进 行过程中计划、工作产品以及相关活动与软件需求保持一致性，确保进度计划的实现， 降低成本的浪费，提高客户满意度。具体的软件需求管理流程图如下： - - 12 - - 图 3-4 2. 需求完善控制： 项目进行过程中，产品经理/客户代表、项目组内部、smg/部门负责人均有可能提 出在某些细节层面上完善需求的请求， 应通过适当方式， 统一需求完善请求的受理途径， 记录修改内容。具体流程如下图： - - 13 - - 图 3-5 3. 需求变更控制： 项目进行过程中，产品经理/客户代表、项目组内部、smg/部门负责人均有可能提 出从功能、性能等较高层面上变更需求的请求。pm/psm 受理变更请求， 记录修改内容。具体流程如下图： - - 14 - - 图 3-6 4. 用户现场开发需求管理 项目组在用户现场开发与在开发现场的开发活动有所差异， 主要体现在对进度要求 的松紧程度、需求改变的频繁程度、项目跟踪与监控的规范化程度等方面。 - - 15 - - 具体流程如下图： 图 3-7 控制要点 控制要点 1. 需求管理过程中要注意需求评审环节，原则上需求调研之后的需求必须经过公司 或部门的需求评审和用户的签字确认。 2. 必须对需求变更进行控制，需要针对用户的实际情况，制定需求变更管理流程， - - 16 - - 成立 ccb（需求变更控制委员会） ，在需求变更管理上按照需求变更控制流程开 展工作。 输出产物 输出产物 表 3-3 过程 活动 过程输出产物 是否必要 用户需求调研 需求调查表 、 需求分析报 告 、 需求跟踪矩阵 是 评审需求 评审记录 是 需求管理 签字确认 客户确认的需求分析报告 是 需求变更控制 客户确认的需求变更记录 、 部门评审记录 是 参与角色及职责 参与角色及职责 表 3-4 角色 职责 pm/psm 负责全程的需求管理 需求评审小组 评审需求 3.3.3 项目策划 项目策划 过程概述 过程概述 根据合同要求及项目启动阶段结果编制软件开发项目计划， 指导项目参与人员进行 项目实施活动。 软件开发项目计划生效前须经过评审， 并严格控制软件开发项目计划变 更。 策划输入 策划输入 1) 合同、标书，确定系统项目实施内容、进度要求，以及其他有关条款； 2) 前期工作记录、相关技术文档； 3) 采购设备到货信息，明确项目设备的采购交付日期； 4) 客户未在合同中明确的其他要求，了解客户的其他需求； 5) 部门资源配置，了解实施人员工作安排； 6) 相关法律、法规要求。 - - 17 - - 步骤 步骤 1) 制定软件开发项目计划 pm 组织相关实施人员编制实施计划。pm 综合考虑合同要求、软件实施要求及设 备采购期等条件， 确定项目各个阶段的开始与截止日期、 所需的各种资源以及进度安排， 在 pm-online 系统中维护项目里程碑计划及采购计划。合同额度较小、实施方案较为 简单的项目，项目里程碑计划也必须包含合同计划中的里程碑。 psm负责根据项目特点和项目启动阶段的需求分析，按照要求进行开发策划。开 发策划包括项目概述；任务分解及可复用资源、软件估计；阶段划分及角色职责；确定 里程碑和对应的评审计划， 明确保证项目顺利完成的内部与外部支持条件与约束； 明确 项目的成本预算以及需要的培训支持，制定培训计划；项目风险管理；明确配置管理的 基本信息，包括角色职责、配置库信息，更新项目的配置库结构层次图和权限控制 ， 确定提交的配置项的信息， 界定基准配置项的变更与完善控制， 明确配置审计的时机与 参与人员。 2) 过程裁剪 项目立项后，由 pm 组织项目组成员根据合同实际情况对项目执行过程进行裁剪， 并提交软件开发过程裁剪工作表 。过程裁剪是针对整个项目执行过程的初期策划， 裁剪的结果用于项目计划的编制。裁剪过程是针对整个集成项目实施过程的初期策划， 初步确定项目实施过程中需完成的基本工作，针对裁剪表中的内容，pm 可选取新增活 动、删除活动及保留原活动除保留原活动外，其余裁剪方式均须提出相应的裁剪理由。 裁剪的主要依据来源于合同要求、项目风险的大小、项目规模、复杂程度等。裁剪后的 过程必须包含 3.3.15 章节中的必要活动。 3) 风险计划 对项目执行过程进行风险评估，识别风险，并提出相应的风险防范措施。风险评估 活动应在整个集成项目的执行过程中持续进行，并在至少保证在每个项目里程碑处实 施。 项目实施过程每阶段开始前或项目发生重大变更时，pm/psm 需组织相关人员对 本阶段进行风险分析，识别风险并编制项目风险管理表 ，此表应在项目组内共享。 风险识别后，pm 组织相关人员针对识别出的风险制定相应的控制措施，并在实施 风险控制措施后根据实际执行情况完善 项目风险管理表 在进行阶段性的风险评估时， 应首先针对项目风险管理表中的已存在风险进行回顾，评估风险状态以及应对措施 的有效性，然后根据项目进程对其余的项目活动进行风险评估。阶段性风险评估后， pm 负责对项目风险管理表进行更新。 4) 质量策划 pm负责根据项目特点和项目启动阶段的需求分析，会同psm、sqal按照质量策 划要求进行质量策划。编制完成项目软件质量保证计划 （一般为软件开发项目计 划中的“项目质量目标”） ，同时进行 软件的生命周期模型的选取，并提交项目的 软 - - 18 - - 件开发过程裁剪工作表 。 5) 计划评审 编制完成的软件开发项目计划和项目风险管理表须提交事业部项目管理人 员参照评审规程(可参照 章节)组织部门级评审。在 pm-online 系统中，由评审 组织人组织相关业务部门对项目计划进行评审。 采购部门负责评审采购部分， 项目管理 部门整合各部门意见。 如果是会议评审， 会后一个工作日内将记录的评审结果填写在 评 审记录中，上传到 pm-online 系统。无论采用哪一种评审方式必须在三个工作日内 完成项目计划的评审。 控制要点 控制要点 1. 项目计划中必须明确包含里程碑设置。 2. 两个里程碑时间时隔不可超过一个月（根据实际情况可适当放宽，但不能超过三 个月） 。 3. 里程碑计划必须包含合同回款点。 4. 项目里程碑点发生延迟（指不能按计划在当月达成里程碑） ，必须进行项目计划变 更。 5. 项目计划必须经过部门项目管理部门的评审才能生效，项目计划的变更也需要经 过部门项目管理部门的评审。 输出产物 输出产物 本过程主要设计下面输出产物： 表 3-5 过程 活动 过程输出产物 是否必要 制定软件开发项目计划 软件开发项目计划 是 过程裁剪 软件开发过程裁剪工作表 是 风险管理 项目风险管理表 是 质量策划 项目软件质量保证计划 是 项目策划 评审计划 评审记录 是 参与角色及职责 参与角色及职责 参与本过程的角色及职责如下： 表 3-6 角色 职责 pm/psm 负责全程的需求管理 - - 19 - - 项目计划评审小组 评审需求 3.3.4 设计 设计 过程概述 过程概述 系统设计人员进行系统设计之前，必须考虑产品的功能、性能以及安全性要求、法 律和法规要求、以前的经验等，解决不完善的、含糊的或矛盾的要求，仔细研究并确保 理解软件需求规格说明书 的内容要求。 步骤 步骤 1. 系统设计要求输出文档化的系统设计报告 并进行相应的评审。如有必要，针 对各模块或子系统进行详细设计，输出详细设计报告作为 sdr 的分册，格式可参 照系统设计报告或自定。 2. 按照软件开发项目计划 的进度安排，系统设计人员依据 系统设计报告模 板 ，并结合项目的实际特点，编制适当形式的系统设计报告 ，如果客户有特 殊要求，可按照与客户共同约定的规则编制。 3. 系统设计的评审按照软件开发项目计划 的规定进行相应形式的评审。按照评 审规程进行系统设计报告的评审。如对各模块或子系统进行了详细设计，须 分别进行评审。存在问题，修改后重新进行评审。通过评审的系统设计报告 作为基准配置项输入编码实现阶段。 按照配置管理的要求对 sdr 及相应的评审记 录进行管理和控制。 4. 系统设计评审通过后，psm 须组织项目策划小组对软件开发项目计划进行调 整，调整的内容包括：任务分解结构 wbs 的细化、进一步的软件估计、项目计划 进度表的更新。调整后的软件开发项目计划须按照配置管理进行变更控制， 按照评审规程重新组织评审，并填写软件开发项目计划中的“修改记录”。 5. 设计的变更及完善要做好变更记录，并进行审核，同时调整计划。 控制要点 控制要点 设计要尽量详细，并且评审要充分，尽可能在设计阶段将问题排除。 输出产物 输出产物 表 3-7 过程 活动 过程输出产物 是否必要 系统设计 系统设计报告 是 - - 20 - - 参与角色及职责 参与角色及职责 表 3-8 角色 职责 pm/psm 负责全程的管理 评审小组 评审设计 系统设计人员 负责设计 3.3.5 编码 编码 过程概述 过程概述 开发人员在开发前要认真阅读并充分理解系统设计报告 ，确保设计要求得以 实现。 各开发部门须编制所使用的编程工具对应的“计算机源代码编写规范”，作为部门正 式文件进行管理。各项目编码实现过程中 psm 须选择或定义与选用的编程工具相应的 “计算机源代码编写规范”。编码实现过程要求输出满足系统设计报告要求的源代码、 可执行程序及技术报告和用户手册 。 步骤 步骤 1. 开发人员通过代码编写实现系统设计要求。在编码过程中，为确保代码的质量， 一定要严格遵守确定的“计算机源代码编写规范”。在编码实现过程中，开发人员应 注意保存必要的编码信息和用户使用信息，并整理这些信息，编制技术报告 和用户手册 。 根据项目的实际情况，可将系统设计报告和技术报告 合为一份完整的报告。 2. 对一个正在开发的系统来说，并非所有的错误纠正都来自于正式的测试。在编码 过程中，项目开发组可采用各种方式（如会议检查、互查等）进行代码检查，以 预先检查模块的质量，提高软件测试的效率。 3. 代码检查的内容一般包括： 1) 检查所有的全局变量； 2) 检查每个常数的类型和值是否都被声明过了； 3) 对所有的函数（局部函数、全局函数和系统函数）的调用仔细检查； 4) 检查所有的错误信息显示是否清楚、易理解和准确； 5) 对每个从结构化查询语言的查询中返回的数据须进行错误状态的检查； 6) 检查源代码与确定的 “计算机源代码编写规范” 和相关命名协议的符合性； 7) 系统中的每个模块是否都在内部进行了足够的注释和说明； - - 21 - - 8) 检查是否使用了错误的数据库处理对象， 或者由于过多使用或用完后忘记 释放而耗尽了对象资源。 4. 根据项目具体情况，编码过程中至少应对核心代码进行两次以上的代码检查；编 码结束，提交系统测试前必须以重点抽查的形式进行代码检查。代码检查的时间 安排应体现在 软件开发项目计划 的“阶段计划进度表”中。 代码检查人员使用 代 码检查表记录代码检查过程以及检查过程中发现的问题，及时发送给被检查的 代码编写人员。psm 负责跟踪问题的解决情况直到关闭。 控制要点 控制要点 一定要严格遵守确定的“计算机源代码编写规范”，并必须以重点抽查的形式进行代 码检查。 输出产物 输出产物 表 3-9 过程 活动 过程输出产物 是否必要 编码实现 源代码、可执行程序、 技 术报告 、 用户手册 是 编码 代码检查 代码检查表 是 参与角色及职责 参与角色及职责 表 3-10 角色 职责 psm 负责全程的管理 开发人员 编码 3.3.6 测试 测试 过程概述 过程概述 软件测试可分为五个阶段：单元测试、集成测试、系统测试、验收测试和确认评估 测试。测试活动主要包括四项：测试计划、测试设计、测试执行与测试总结。 对于单元测试，不要求参照组织文件模板输出文档，但应保存适当形式测试记录。 对于集成测试、系统测试和确认评估测试，须执行以上全部四项活动，参照组织文 件模板输出测试文档和记录。 对于验收测试，须执行以上全部四项活动，但是输出文档除测试执行时须使用 - - 22 - - fd207 测试问题卡 进行记录外， 其他三项活动的输出文档格式可参照组织文件模板， 也可由项目组与客户共同确定。 步骤 步骤 测试阶段的主要工作步骤如下： 1. 编制测试计划： 1） 测试负责人tl依据项目的进展情况编制集成测试或系统测试的 测试计划 ， 参照评审规程进行评审。评审内容主要包括：测试内容、错误等级描述、测试 环境、选用的测试工具、资源分配、测试进度、测试风险及测试输出等。 2） 系统测试须在用户手册中描述的系统运行环境下进行，如果条件允许，还 应对低于系统运行环境的条件进行测试。如果无法搭建适当的测试环境或有特 殊要求，须在测试计划中重点说明。 3） 对于产品升级项目， 测试计划中应考虑对前一版本的遗留问题着重进行验 证。须将上一版本 测试总结报告的“遗留问题分析表”作为本次测试测试 计划的附件，并在其中记录对遗留问题的测试结果。 2. 测试设计： 测试设计的活动是按照一定的编写格式、内容及注意事项编制测试设计的各种文 档，为测试人员在测试执行过程提供测试过程、方法、步骤及使用的测试数据。以保证 回归测试过程中的完整性和充分性。 为进行全面、 准确的测试设计工作， 测试负责人 tl 须从项目配置库中获得最新的需求分析文档、系统设计文档、编码结束后的 技术报 告以及 用户手册的最新版本，并与 psm 进行讨论以对上述工作产品准确无误 的理解。 3. 测试执行： 1） 测试环境准备：项目组根据系统的运行条件准备测试环境。tl负责对测试环境 进行确认：确认计算机硬件、网络、软件支撑环境已满足所测试软件对其的要 求，并确认这些环境运行正常；消除病毒干扰：首先使用杀毒软件对测试环境 进行病毒的检测和杀毒处理；其次对被测试的软件进行病毒的检测和杀毒处 理。软件对测试环境进行病毒的检测和杀毒处理；其次对被测试的软件进行病 毒的检测和杀毒处理。在上述各种环境不能正常运行时，tl 向设备管理部门 提出对测试环境进行维护的申请。维护工作完成后，tl须再次进行测试环境确 认。在上述各种环境不能正常运行时，tl向设备管理部门提出对测试环境进行 维护的申请。维护工作完成后，tl须再次进行测试环境确认。测试环境的准备 情况经tl确认后须填写在测试大纲中。tl组织相关人员按照测试计划 中的要求准备测试工具。 测试工具在使用前由tl和psm共同确认， 并对选用的 各种测试工具留下适当形式的确认记录。 2） 正式执行测试： 项目配置管理负责人cml向测试负责人tl提交测试版本的软件 项；测试人员以测试大纲 、 测试用例 ，及相应的需求规格说明、系统设 计文档和用户手册为依据，进行测试并在测试过程中通过测试问题卡 的方式及时报告发现的系统问题，并对上一测试版本中发现问题的修改情况进 - - 23 - - 行确认；开发人员根据测试中发现的问题对软件进行修改，开发人员将修改后 的新版本提交配置管理负责人cml； 测试负责人tl再次组织进行测试工作， 重 复上面所述步骤，直至整个系统达到 “测试通过准则”；在整个系统达到“测试通 过准则”的情况下，psm组织项目组成员根据各模块最新版本的功能校对、修 改用户手册。 4. 测试总结： 在软件的所有模块达到测试通过准则，项目配置管理负责人 cml 对系统各模块的 执行程序及源程序统一进行备份，测试负责人 tl 要组织测试小组成员对测试工作进行 总结，tl 向项目 cml 提交测试过程文档。 控制要点 控制要点 测试是否通过需要遵循下面的测试通过准则，即当所测试的软件满足如下要求时， 才能认为通过测试（错误类型 a 、 b 、 c 、 d 的规定） ： 1. 全部功能需求均已实现； 2. 测试用例全部通过； 3. “a“、“b“、“c“三类错误数均为零；允许存在“d“类错误； 如有特殊情况而存在遗留问题，不能通过准则 1） 、2） 、3） ，则必须由指定的仲裁 人进行确认后方可释放。 输出产物 输出产物 本过程主要设计下面输出产物： 表 3-11 过程 活动 过程输出产物 是否必要 编制测试计划 测试计划及评审记录 是 测试设计 测试大纲 、测试用例 及 评 审记录 是 测试执行 测试问题卡 是 测试 测试总结 测试总结报告 及 评审记录是 参与角色及职责 参与角色及职责 参与本过程的角色及职责如下： 表 3-12 角色 职责 pm/psm 负责全程的需求管理 需求评审小组 评审需求 项目配置管理负责人 cml - - 24 - - 测试负责人 tl 3.3.7 软件实施 软件实施 过程概述 过程概述 根据公司软件开发项目现场实施过程中所作的工作，分为实施准备、现场实施、试 运行、验收、总结几个阶段。其中验收、总结两个阶段在后两个小节中进行介绍。 - - 25 - - 图 3-8 - - 26 - - 步骤 步骤 1. 实施策划 1) 实施准备 i. 公司产品交付前要经制作部门复制、包装并检验合格。 ii. 除公司产品以外的其它项目， 必须有符合验收准则的测试通过证据， 并记 录经授权负责产品放行的责任者。应有记录表明以下内容： ? 最终交付的软件版本标识； ? 变更控制方式（变更请求、审批和记录） ； ? 最终测试结果； ? 用户要求的文档。 iii. 根据合同要求，明确向客户交付的物品、数量、交付时间、交付方式（邮 送、传送、派人交付） 、交付地点等事项，确保实施交付的过程安全、及 时。 iv. 实施负责人： 项目实施前需组建实施小组， 并且由项目经理明确软件的实 施负责人，以及软件实施负责人的职责。 v. 实施资料：项目实施前需准备实施的资料，即实施计划、培训资料、用户 手册、实施记录、培训记录、验收报告等，同时对于实施人员需明确实施 的工作准则。 vi. 客户的沟通： 在项目实施前期， 需要同客户积极沟通了解客户现场的软件、 硬件、网络设备的准备情况，经过实施人员验收现场的环境合格后，项目 实施方可进行下一步工作。在现场实施人员要同客户保持良好的沟通。 （ 硬件集成实施方案模板之附表客户现场环境调查表 ） 2) 软件实施计划 vii. 计划编制： 软件具体实施前， 软件实施负责人负责编制 软件实施计划 ， 包括实施范围的确定、实施阶段的划分、实施进度表、培训计划等。实施 的工作量的估计要以细致为原则， 充分考虑软件实施过程中可能发生的情 况良好的实施计划可为其它项目奠定良好的基础。 当软件的实施工作需要 分阶段进行时， 在各阶段进行软件实施的之前一定要有与之相对应的实施 计划。 软件实施要充分响应客户提出的实施要求， 根据客户的现场情况确 定实施计划，并同客户共同确认实施计划安排。 viii. 计划评审： 软件实施计划由项目管理部门按照 评审规程 组织相应的评 审，并获得客户确认。 ? 识别风险与存在问题，责任者修改后重新评审； ? 评审通过； ? 客户确认计划安排，进入下一阶段。 3) 风险管理 i. 在软件实施过程中，实施负责人应参见 风险管理，预测在软件实施过程 - - 27 - - 中起关键作用的人和设备以及整个实施过程存在的风险并采取预防措施。 ii. 在软件实施过程中针对所发生的变化， 可参见实施计划的安排召开风险评 估会。 4) 配置管理 i. 按照“配置管理规范”的要求，对软件实施过程中的文档及评审记录（各 种计划、安装环境、更改说明、测试结果等）进行管理和控制。在客户现 场配置管理实施条件不足时，可另行特殊规定其配置管理方法。 2. 现场实施 1) 软件交付 交付软件产品时，向客户提供一份软件交付书 ，明确交付/实施负责人，说明软 件产品的交付状态， 并由合同双方共同确认交付产品的正确性及完整性。 交付活动可采 用现场或传真签收。 2) 安装调试 i. 软件产品的安装： 软件产品经与客户协商后可由客户自行安装； 软件项目 均由公司负责组织安装实施。 ? 客户自行安装：客户按照系统安装手册/用户手册即可自行实现软件 安装并运行。客户只需在软件交付书中注明软件工作产品的交付 状态以确认安装运行， 并以传真或邮寄等方式回复， 项目管理部门归 档。 ? 服务工程师安装： 软件销售部门根据合同要求或与客户协商， 可指派 部门内部的服务工程师进行现场安装。 工程师到达现场后应向客户方 负责人说明来意， 并与客户方人员共同确认现场的安装环境。 服务工 程师应与客户方相关人员共同开启软件外包装， 确认包装内物品与物 品清单相符，并请客户签署软件交付书 。现场安装结束后，服务 工程师应填写软件安装记录 ，记录安装过程。 ii. 合同项目的现场安装： ? 安装前软件实施负责人需要同硬件集成实施负责人及客户积极沟通 确认客户现场的软件硬件及网络环境。具备实施条件后，sil 可组织 客户方召开开工会议，确认实施工作的开始，并请客户签署开工报 告 。 ? 安装调试与计划跟踪 ? 软件实施负责人根据项目进展情况及 软件实施计划 组织实施 工程师进行现场安装调试，并严格遵守 工程师现场服务规范； ? 现场实施过程中，如果需要对客户硬件配置及网络环境进行调 整， 应首先征得事业部负责人及客户方相关人员同意； 如硬件集 成实施由公司承担，则应请硬件实施人员协助调整； ? 实施工程师应以日报或周报的形势向软件实施负责人报告现场 情况、所发生的问题及问题解决方式。如由于环境变化，需要对 软件实施计划 进行调整， 软件实施负责人应及时向 pm 提交 - - 28 - - 变更控制报告 ，说明计划变更原因及所受影响，同时拟订变 更后的软件实施计划 ； ? 实施过程中所发现的问题均应记录在实施问题记录表中，问 题包括： ? 与实施方案中不一致的地方及原因； ? 实施过程中发生的错误（包括纠错方法） ； ? 客户的新需求。 ? 现场实施结束后，sil 应向客户方提交现场实施结束通知单 ， 说明现场实施工作已经结束。 3) 客户培训 i. 客户培训可参照客户培训，根据制订的软件实施计划进行； ii. 培训人员应认真实施培训，记录培训情况，并将其结果作为运行、验收的 输入。 3. 试运行 1) 试运行阶段： 经过培训的用户相关责任人协同实施人员将准备好的静态和动态 数据导入已安装调试的系统进行模拟运行。 2) 试运行过程问题处理 i. 系统的问题 ? 针对系统在安装调试期间出现的问题