中国建设银行项目文档管理规范

PAGE第72页共72页项目文档规范（V2.0）目录1 概述 61.1 目的 61.2 适用范围 61.3 主要内容 61.4 定义 61.5 参考资料 72 文档管理规范 82.1 项目各阶段应产生的文档 82.2 文档管理相关职责 82.2.1 项目主管单位职责 82.2.2 项目申请单位职责 82.2.3 项目实施单位职责 82.2.4 项目组的职责 82.3 项目文档管理的要求 92.3.1 项目文档编制基本要求 92.3.2 文档的评审 92.3.3 文档的归档和保管 102.3.4 文档的修改控制 102.4 文档编制中应该考虑的因素 112.4.1 文档的适应性 112.4.2 文档的完备性 112.4.3 文档的多样性 112.4.4 文档的灵活性 112.5 文档的命名 113 管理文档编制规范 133.1 集成项目计划 133.1.1 编写要求 133.1.2 内容要素 143.2 项目计划 143.2.1 编写要求 143.2.2 内容要素 143.3 项目主计划 163.3.1 编写要求 163.3.2 内容要素 183.4 详细进度计划 183.4.1 编写要求 183.4.2 内容要素 233.5 变更控制计划 233.5.1 编写要求 233.5.2 内容要素 233.6 人力资源计划 243.6.1 编写要求 243.6.2 内容要素 243.7 采购计划 253.7.1 编写要求 253.7.2 内容要素 253.8 培训计划 263.8.1 编写要求 263.8.2 内容要素 263.9 质量保证计划 263.9.1 编写要求 263.9.2 内容要素 263.10 风险管理计划 273.10.1 编写要求 273.10.2 内容要素 283.11 配置管理计划 283.11.1 编写要求 283.11.2 内容要素 293.12 开发合同 303.12.1 编写要求 303.12.2 内容要素 303.13 项目周/月报 303.13.1 编写要求 303.13.2 内容要素 303.14 会议纪要 303.14.1 编写要求 303.14.2 内容要素 303.15 评审报告 313.15.1 编写要求 313.15.2 内容要素 313.16 试运行报告 323.16.1 编写要求 323.16.2 内容要素 323.17 项目开发总结报告 333.17.1 编写要求 333.17.2 内容要素 333.18 项目技术报告 343.18.1 编写要求 343.18.2 内容要素 344 技术文档编制规范 354.1 项目建议书 364.1.1 编写要求 364.1.2 内容要素 364.2 可行性研究报告 364.3 项目需求书（业务需求说明书） 374.3.1 编写要求 374.3.2 内容要素 374.4 项目需求说明书（需求分析说明书） 384.4.1 编写要求 384.4.2 内容要素 384.5 项目技术方案 394.5.1 编写要求 394.5.2 内容要素 394.6 概要设计说明书 404.6.1 编写要求 404.6.2 内容要素 404.7 详细设计说明书 414.7.1 编写要求 414.7.2 内容要素 414.8 工程设计实施方案（实施工艺） 424.8.1 编写要求 424.8.2 内容要素 424.9 数据库设计说明书 434.9.1 编写要求 434.9.2 内容要素 434.10 软件开发类项目技术手册 444.10.1 编写要求 444.10.2 内容要素 444.11 工程实施类项目技术手册 454.11.1 编写要求 454.11.2 内容要素 454.12 测试计划 464.12.1 编写要求 464.12.2 内容要素 464.13 测试（分析）报告 474.13.1 编写要求 474.13.2 内容要素 474.14 上线方案 494.14.1 编写要求 494.14.2 内容要素 495 用户文档编制规范 515.1 用户手册 515.1.1 编写要求: 515.1.2 内容要素: 515.2 操作手册 525.2.1 编写要求 525.2.2 内容要素 526 文档体例要求 536.1 封面 536.2 修改记录 546.3 目录 546.4 正文页面 546.4.1 页眉 546.4.2 页脚 556.4.3 标题 556.4.4 正文 556.4.5 分节 55附件 56附件一：项目文档编制表 56附件二：项目计划模版 57附件三：项目文档格式样例 58概述目的为规范建设银行信息技术项目文档的管理和编制方法，特制定本规范。项目文档是项目产品的重要组成部分。本规范为相关人员编制项目文档提供依据，同时也作为项目文档质量检查的参照标准。适用范围本规范适用于建设银行总行正式立项的信息技术项目。本规范规定的文档和内容并不能包含项目的全部文档和要求，文档编制者可根据项目的实际情况，按照建行有关规定，进行适当剪裁。主要内容根据用途，项目文档分为三类：管理文档、技术文档和用户文档。针对这三类文档的编制和管理的要求，本规范包括以下内容：文档管理规范主要内容是明确项目各阶段应提供的重要文档的种类，并提出对项目文档管理的基本要求。项目组可参照本规范，制定具体的文档计划和文档管理制度（文档计划可编入质量保证计划）。管理文档编制规范技术文档编制规范用户文档编制规范文档体例要求定义1）管理文档是指描述项目开发过程各类管理信息的文档，如《质量保证计划》等。2）技术文档是指描述项目开发对象和过程本身的文档，如《项目需求分析说明书》。3）用户文档是指描述项目产品的文档，帮助用户了解系统的用途和用法，如《操作手册》等。参考资料《中国建设银行信息技术项目管理办法（试行）》（简称《项目管理办法》）《中国建设银行信息技术项目财务管理办法（试行）》（简称《财务管理办法》）《中国建设银行总行信息技术项目管理实施细则（试行）》（简称《总行项目管理细则》）《信息技术管理部信息技术项目状态报告制度（暂行）》（简称《项目报告制度》）《中国建设银行软件配置管理规范》（简称《配置管理规范》）《中国建设银行项目计划管理规范》（简称《计划管理规范》）《中国建设银行信息系统技术架构指标检查参考规范》（简称《架构指标规范》）GB/T16680-1996 软件文档管理指南GB/T11457-1995 软件工程术语GB/T8567-1988 计算机软件产品开发文件编制指南GB/T9385-1988 计算机软件需求说明编制指南GB/T9386-1988 计算机软件测试文件编制规范GB/T12505-1990 计算机软件配置管理计划规范GB/T12504-1990 计算机软件质量保证计划规范《金融电子化系统标准化总体规范》

文档管理规范项目各阶段应产生的文档详见附件一：项目文档编制表。文档管理相关职责项目主管单位职责项目主管单位文档管理的主要职责是：制定相关的管理制度和规范；指导相关单位的文档管理和编制工作；监督、检查各项制度、规范的执行情况；按照有关管理规定，对部分项目文档进行评审、审批、备案（详见2.3.2文档的评审）。项目申请单位职责项目申请单位文档管理的主要职责是：根据有关规定的职责要求，编制部分项目文档，或编写文档中相关部分的内容；根据有关管理规定批准项目实施单位或项目组提交的项目文档。项目实施单位职责项目实施单位文档管理的主要职责是：具体落实各项文档管理相关管理规定和规范的执行；指导项目组的文档管理和编制工作；督促辖内项目组按要求编制、提交各类项目文档，并按规定进行检查；组织或协调辖内项目组提交的项目文档评审工作（详见2.3.2文档的评审）；负责纸质项目文档的归档保存；。项目组的职责项目组文档管理的主要职责是：约定项目组内部文档编制和管理的具体办法；按照有关的管理规定，对文档编制和管理工作进行合理分工，明确职责要求；严格遵照有关管理规定和规范的要求编制、修改项目文档；按要求提交有关项目文档进行评审和批准；按照配置管理的有关制度要求，将项目文档纳入配置管理系统的管理；及时提交纸质项目文档进行归档保存。项目文档管理的要求项目文档编制基本要求项目文档的编制应符合以下基本要求：项目组应在项目初期编制文档计划（可以作为质量保证计划的一部分），约定文档编制的办法和要求，指导文档的编制和维护；文档必须按计划产生，能够覆盖整个项目开发过程；文档编制必须适合相应的读者，针对不同的读者，文档应有不同的表达方法和不同的详细程度；在项目进行过程中，应充分发挥文档的作用，指导整个项目工作；为了使文档编制更加规范，建议项目组尽可能使用一些文档编制辅助工具。文档的评审为了提高项目开发的质量，必须在每个阶段对该阶段产生的文档进行严格的评审，尽早发现问题，并及时采取措施给予解决，从而确保文档内容的正确性和合理性，为进入下一阶段工作作好准备。项目文档评审要求参考如下：项目文档评审要求序号文档名称评审要求1可行性研究报告按有关管理规定要求的流程审核、评审。2立项申请报告按有关管理规定要求的流程审核、评审。3需求说明书项目申请单位批准（或组织有项目申请单位代表参加的评审，产生评审报告），并报技术部备案。4实施方案（技术方案、推广方案、工作方案）项目实施单位组织评审，产生评审报告。5项目主计划项目主管单位审批。6其它项目计划项目实施单位组织评审，产生评审报告，并报技术部备案。7项目设计、开发、技术测试阶段性文档应用开发项目和基础设施项目的里程碑阶段性文档，项目实施单位组织评审，产生评审报告；信息研究项目，由项目实施单位和项目申请单位根据项目具体情况对项目阶段性成果进行评审，产生评审报告。8上线方案项目实施单位组织评审（专家小组由项目申请单位、技术部、运行中心以及项目应用单位的有关专家组成，涉及推广的项目还应包括不少于两个分行的专家），产生评审报告。9项目验收材料新产品、优化改造项目，技术部组织验收评审，产生项目验收报告；信息研究项目，项目申请单位将项目研究成果报项目审批单位批准；推广项目，项目申请单位整理推广总结报告，报所属业务主管单位批准。文档评审的方式一般应采用召开评审会议的形式，对部分阶段性文档可以采用函审的形式。文档评审的主要依据是项目涉及的各种管理制度和技术规范（文档评审的依据应作为质量保证计划的一部分）。文档的归档和保管文档是项目开发过程的真实记录，是重要的信息资源，因此必须实行统一管理，保证其安全、完整、便于使用。项目组应及时将项目文档纳入配置管理系统管理，用户文档在归档前由项目管理部门进行必要的审核。对含有签字（或盖章）的申请件、报告、批复件等纸质文档，由各级项目管理部门统一进行归档保管。纸质文档的保管包括登记、保存、借阅、修改和销毁工作。文档应按保密要求严格限定借阅范围，履行申请、审批、登记手续，秘密级以上资料的借用需经项目文档管理部门负责人批准。文档的修改控制在项目开发过程中，随着项目的逐步实施，项目各种文档也在不断产生、修改或补充。因此应对文档的修改加以周密的控制，以保持文档与项目产品的一致性，保持文档之间的一致性和文档的安全性。项目组内文档的修改流程按照建行软件配置管理的有关规定进行。文档编制中应该考虑的因素文档编制是一个不断改进和完善的过程。从最初的设想到形成最后交付使用的文档，其中每一步都要做很多工作。为了既不浪费资源，又能保证文档的质量，应在文档编制中考虑以下因素：文档的适应性每种文档都有自己的特定读者。这些读者包括操作人员、测试人员、项目开发人员，对项目进行维护的技术人员以及管理人员和各级领导。他们期待能通过文档了解项目情况，更好地开展工作。因此，文档编写人员必须了解读者的需要，采用不同的表达形式和详细程度编写各种文档，以适应这些读者的水平、习惯和要求。文档的完备性为了方便每种文档各自的读者，应该使每类文档自成体系，尽量避免读者在阅读一种文档时又不得不去参考另一文档。文档中的重复一般具体体现在两处：一是每种文档的引言部分；二是文档中对项目的说明部分。当然在重复的地方，还是应该根据文档的特点有所差别。文档的多样性本规范只规定了项目应具备的基本的文档种类，若不能满足某些项目的特殊要求时，项目组可以根据需要增加一些适合本项目使用的文档。对这些文档的编制要求可以在质量保证计划中加以说明。文档的灵活性本规范对重要文档要包含的要素作了说明，可以按照这些标题编制文档，同时也可以根据项目特点对章节内容进行细化和扩展。文档的格式可以采用自然语言或其他格式化的语言（如表格等）。文档的命名项目文档在纳入配置管理系统管理或归档时，要目录清晰、分类合理、命名规范，详见《配置管理规范》。向总行单个报送的项目文档统一命名规则，要求如下：项目名称_文档名称_版本号（如V2.0）_编制日期（如050320）管理文档编制规范在项目开发工作中，项目管理人员负有对项目开发的过程进行管理的责任。管理过程从任务书下达之日开始，在计划阶段，管理人员应当制定项目开发计划，组织需求分析工作；在实施阶段，管理人员应履行对实施过程的控制，调查、分析和解决发现的问题，问题及其解决办法都应写成文档；管理人员应在约定的阶段对项目进展写出报告；当每一阶段任务完成后，管理人员应对产品进行检查和评价，保证产品和计划的完整性和一致性。管理文档就是记录项目开发过程各类管理信息的文档。本章主要提供了应用开发类项目和基础设施类项目在开发过程中所应产生的管理文档的编写要求和内容要素，期望通过规范管理文档的形式来规范项目管理行为，从而达到提高项目开发质量的目的。管理过程一般包括计划、对计划实施的控制以及对工作结果的评审和评价。以下将对管理文档提出具体编写要求和内容要素。集成项目计划编写要求集成项目计划由项目实施单位采用MicrosoftProject工具进行编制。计划的命名、任务层次及阶段划分等参考主计划和详细进度计划的要求。集成项目计划的主要编写要求如下：（1）计划任务的第一层为计划编制单位名称（如XX开发中心）；（2）计划任务的第二层按集成任务类型分类（如采购、测试）；（3）计划任务的第三层为具体的关联任务：将项目间存在关联的项目任务（包括与其他单位或项目组关联的任务）按时间顺序逐一编入相应的任务类型中；（4）集成项目计划必须包含项目采购任务，并将本单位所有项目的采购任务按时间顺序逐一编入。（5）根据项目的变化情况，集成项目计划的内容要实时更新。内容要素集成项目计划具体格式参见附件二项目主计划MPP格式文件。项目计划编写要求项目计划是指项目总计划。按照建行项目管理有关制度的要求，项目计划包括：项目主计划、项目详细进度计划、变更控制计划、人力资源计划、质量保证计划、配置管理计划、风险管理计划、采购计划、培训计划等。内容要素1.引言1.1编写目的说明本计划的编制目的，指出预期的读者。1.2背景说明项目的名称、任务提出者、开发部门及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.项目范围和目标简述项目的范围及实现目标。3、项目成果列举计划产生的项目成果。4、项目环境对项目的开发环境、运行环境要求进行分述。5、支持条件综述项目需要的用户单位及其它单位的必要支持。6、项目主计划简述项目各阶段的划分、进度及主要责任人，并标注：详见《项目主计划》（必须单独编制）。7、详细进度计划标注：详见《项目详细进度计划》（必须单独编制）。8、变更控制计划参照《项目变更控制计划》编制，内容较多时应单独编制，并标注：详见《项目变更控制计划》。9、人力资源计划参照《项目人力资源计划》编制，内容较多时应单独编制，并标注：详见《项目人力资源计划》。10、采购计划参照《项目采购计划》编制，内容较多时应单独编制，并标注：详见《项目采购计划》。11、培训计划参照《项目培训计划》编制，内容较多时应单独编制，并标注：详见《项目培训计划》。12、质量保证计划标注：详见《项目质量保证计划》（必须单独编制）。13、风险管理计划参照《项目风险管理计划》编制，内容较多时应单独编制，并标注：详见《项目风险管理计划》。14、配置管理计划参照《项目配置管理计划》编制，内容较多时应单独编制，并标注：详见《项目配置管理计划》。15、其它计划内容较多时应单独编制，并标注：详见“[其它计划名称]”。项目主计划编写要求项目主计划，即里程碑计划。项目经理依据项目目标，将项目划分为几个里程碑阶段，并设置相互之间的依赖关系，每个里程碑阶段应有确定的起止日期和责任人。（1）主计划命名规则项目主计划采用MicrosoftProject工具进行编制。项目主计划命名规则：[项目名称]_[版本号]_[YYMMDD].[文件后缀]。项目名称（以及主计划内容）尽可能用中文进行标识，惯用法、专业词汇等除外。版本号用V[序号].[序号]进行标识，立项后主计划第一次审批后版本号是V1.0，之后主计划每次变更并审批通过后，第一个序号加1；第二个序号标识详细进度计划的变更，该变更不影响主计划。注：项目主计划和详细进度计划物理上是同一个文件。项目主计划变更并获得项目处批准后，形成新的基线，用另存为.mpp文件的方式保存每个基线。每个基线通过命名新的版本号进行标识。（2）任务根据项目选择的不同开发模型，主计划任务层次（大纲级别）可能不同。原则上，主计划任务层次不超过四层：1）第一层：项目名。2）第二层：项目大阶段，规定的阶段有：计划阶段、实施阶段、收尾阶段。需上级部门协调的重要外部任务单独作为一个阶段在第二层中表示。计划中的外部任务指项目组需要外部资源完成的任务，一般该任务对项目组内部的任务有直接影响。外部任务在项目主计划中多标识为里程碑事件。3）第三层：分阶段的功能释放，分阶段的项目目标实施。大型项目、复杂项目、或者非瀑布模型的项目，在实施阶段中往往出现类似的多个子阶段。4）第四层：开发阶段，如：软件工程阶段。瀑布模型的项目主计划，一般采用三层任务结构（没有上述第三层）。非瀑布模型的项目主计划，根据需要，可以采用四层任务结构，如迭代开发模型，实施阶段中先分功能释放大阶段，每个阶段下再细分开发阶段。原则上，主计划底层任务包括三种：1）软件工程阶段，如：需求、设计、编码、测试、试运行、推广。在project中一般用阶段任务表示。2）项目管理过程，如：项目启动、计划、采购、培训、验收、收尾。在project中一般用阶段任务表示。3）关键任务或关键里程碑事件，如：重要外部任务、重要事件点。规定的重要外部任务有：采购获取（从提交采购文件到采购资源可用，如公司人员到位、设备到货）；开发环境就绪、（集成、用户）测试环境就绪、运行环境就绪；相关系统配合（接口）就绪。关键里程碑事件如：系统切换。项目主计划定位为里程碑计划，任务数量不宜过多，也不宜过少，一般底层任务数在10-20个左右（不强制要求）。任务属性包括：WBS编码、工期、开始时间、完成时间、完成百分比、提交件、资源、前置任务。注：project中还增加了“是否主计划任务？”属性，主要原因是，项目主计划和详细进度计划共用同一个project文件，为区分两个计划，增设了该属性，缺省值是“否”。这样做的优点是有利于维持两个计划的一致性，减少计划编制者的工作量。（3）WBS编码WBS编码规则：[序号].[序号]……例如：项目管理系统项目，主计划第二层第一个任务WBS编码为“1.1”。（4）工期、开始时间、完成时间、完成百分比项目主计划编制的开始时间为项目任务书下达的项目启动时间，时间周期不能超过任务书规定的工期。主计划任务工期的单位应该为工作日。完成百分比按照实际进度及时跟踪。注：因为主计划的变更要走变更流程，所以，每个任务的时间要尽量考虑周全，避免频繁的变更手续。（5）提交件原则上，主计划底层任务都要有正式提交件，标志该任务的完成。提交件的例子如：需求说明书、概要设计说明书、测试报告等。注：主计划任务的提交件是标志本任务完成的主要提交件，不是其子任务（属于详细进度计划任务）提交件的集合。（6）资源最底层任务应明确标识资源：项目组内部任务填写责任人，外部任务填写组织或单位名称。（7）前置任务各任务之间的依赖关系必须标识清楚。（8）其他主计划中不允许涉及预算、采购金额等保密信息。项目主计划模板见附件二。注：模版并不涵盖所有的项目类型，除本文规定的任务外，模版中的很多信息都是示意性的，项目组需根据本规范的原则，对模版进行剪裁。内容要素具体各种类型项目模版请参见附件二MPP格式文件，包括应用开发类项目计划模版、推广类项目计划模版及基础设施类项目计划模版。详细进度计划编写要求（1）编制顺序确定要素确定要素任务分解工期估计关联设定关键路径计算开始结束计划调整（2）计划要素详细进度计划的描述要素几乎等同于里程碑计划的要素。（3）任务拆分原则1）四十小时原则这个原则表述的意思是处于层次最末端的工作可以在一周内完成，这样可以把任务执行检查的周期控制在一周以内，从而大幅度的增加任务分解的可靠性和任务执行的及时性。2）最末端的工作可以分配给某个具体的人或者某个团队最末端的工作需要明确责任人或者资源，如果某个任务虽然已经在一周内可以完成，但是执行该任务的资源却大于1人，则应该按照每个人的任务再进行分解，直到明确每个人或者每个团队具体的任务和职责。按照这一原则划分的WBS不仅可以分清职责，而且在项目后评估的时候，可以清楚的得知每个团队或者每个人的工作量和工作质量。3）最末端的工作不应含有较高的风险例如“解决技术问题”这一任务，有可能一周内可以完成，但是有个别问题的解决存在着较大的风险，能不能解决还不能确定，由此就需要再将该任务按照具体的技术问题进行分解，或者按照具体的解决步骤进行分解。通过进一步的明确，该任务的风险可以被很大程度上化解。4）逐步求精原则详细进度计划制订不是一蹴而就的，需要随着项目的进展逐步细化，因此不要在项目计划编制阶段一味追求计划的完美性，而耽误了项目的进程。当然即将要开始执行的任务一定要尽量的细化，以保证计划执行的可靠性；如果目前还暂时不涉及的工作，如项目还处在“需求分析阶段”就不需要将项目收尾阶段的工作分解得特别细。5）使用团队力量原则项目计划的制订不是项目经理一个人的工作，因为项目具体任务的执行者具体的工作能力和工作意愿项目经理不可能非常清楚的了解，所以具体工作任务的分解需要项目经理与各成员一起商讨完成，从而做到在项目计划阶段所划分的每个任务都是经过该责任人或者资源所认可和承诺的。只有充分调动整个团队的力量参与项目计划的编制，项目计划的可行性才可以得到最大程度上的保证。以往很多计划失去意义便是因为项目经理仅仅按照自己的意愿编制所产生的。（4）工期估计1）工期估计的时机在任务分解的同时，没有必要进行工期估计，因为凡是有子任务的任务，工期应该由所属子任务的工期来累算，自己输入的工期难免出现错误。所以，工期估计应该在任务分解完成后，针对最末端的任务进行逐一的工期估算（自下向上）。2）工期的单位工期的单位可以采用“月”、“周”、“天”、“小时”等。通常采用“天”为单位，而且需要明确的是“天”指的是工作日，并非是自然日，例如工期为“21天”实际上需要一个自然月；如果项目的后期任务很多，而且在现阶段不能确定具体天数的情况下，可以采用“周”或者“月”来表示，其中“一周”应该是“5天”，“一月”应该是20天或者21天或者根据实际情况自行定义。3）工期估计的方式具体任务的工期估计可以参考PERT技术，这一参考过程并非需要照搬，而是在理解其中精髓的情况下灵活使用。例如，项目经理与某一个组员商讨“编写立项管理模块”这一任务的工期时，项目经理可以向组员询问两个工期：“乐观工期”＝a和“悲观工期”＝b，项目经理再告诉组员一个“期望工期”＝m。项目经理利用这三个工期进行简单的PERT计算（te＝(a+4m+b)/6），便可得出最可能的工期te，得出之后再与组员进行确认，利用这种办法可以在一定程度上保证工期的可行性。（5）关联性设定详细进度计划的编制工作应该使用Project完成，使用过程中，当任务分解和工期估计完成后，不需要给每个任务单独设置“开始时间”和“结束时间”，只需要设置好任务之间的关联性，上述两项内容便可以由软件自动计算出结果。1）关联性分类通常做计划用的网络图的形式为单代号（AON），在单代号网络图中，关联性有以下四种：完成－开始（FS）说明：如果任务B的开始是以任务A的完成为前提，则任务A和任务B之间有FS的关系。B的前置任务是A。开始－开始（SS）说明：如果任务B的开始是以任务A的开始为前提，则任务A和任务B之间有SS的关系。B的前置任务是A。开始－完成（SF）说明：如果任务B的完成是以任务A的开始为前提，则任务A和任务B之间有SF的关系。B的前置任务是A。完成－完成（FF）说明：如果任务B的完成是以任务A的完成为前提，则任务A和任务B之间有FF的关系。B的前置任务是A。2）关联性设置原则项目经理应该深刻理解以上四种关联性的定义，在为每个任务寻找“前置任务”的时候，实际上是在为B任务找A任务，即哪一个任务与当前任务有何种关联关系。任何一个任务可以有多个“前置任务”；任何一个任务也可以被多个任务“前置”。（6）关键路径1）关键路径定义当任务之间的关联性设置完成后，为了进一步优化计划，便可以确定该计划的关键路径。关键路径是一条能够决定项目结束日期的路径，关键路径上的每个任务都是关键任务。判断某个任务是不是关键任务，最关键的是判断这个任务的工期变化会不会影响项目的结束日期，如果影响则是，否则不是。任何一个项目计划肯定会有关键路径；而且有可能有多条。2）关键路径用途关键路径的重要性非常高，项目经理在制订合理的、可行的进度计划时，应该不时的观察关键路径的变化。具体作用如下：当工期需要压缩的时候，应该压缩关键任务的工期。当项目发生延期的时候，应该将资源优先考虑关键任务的执行。3）关键路径计算关键路径的手工计算方法相对比较复杂，这里不作赘述，请参考相关书籍。项目经理应该在Project中寻找关键路径，该软件已经固化了原有的公式，可以自动的计算各种条件下的关键路径。（7）计划调整设置任务间的关联性后，以及每个任务的开始时间、结束时间后，Project会自动计算出结果，如果有个别的任务的时间不符合Project自动计算的结果，可以根据任务的具体情况进行手动设置，还可以增加一些限制条件，具体的一些条件有：必须开始于某个日期必须完成于某个日期不得晚于某个日期开始不得晚于某个日期结束不得早于某个日期开始不得早于某个日期结束越晚越好越早越好内容要素同项目主计划。变更控制计划编写要求为了保证项目开发工作的相对稳定性，确保开发质量，项目组应该认真编写变更控制计划。该计划中所指的项目变更是项目范围、进度、费用等各种类型、不同程度的变更，变更控制要符合建行有关项目管理的规定。内容要素1.引言1.1编写目的说明本计划的编制目的，指出预期的读者。1.2背景说明项目的名称、任务提出者、开发部门及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2、变更控制的角色对变更控制涉及的角色进行定义，明确职责分工。3、变更控制的流程对项目范围、进度、费用等不同类型的变更，规定具体的控制办法，制定控制流程。人力资源计划编写要求人力资源计划描述了项目组织结构，说明了项目各阶段的人力投入计划。内容要素1.引言1.1编写目的说明本计划的编制目的，指出预期的读者。1.2背景说明项目的名称、任务提出者、开发部门及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.项目组织规划项目组织结构，定义角色职责。3.项目人力阶段投入计划对项目各阶段的人力投入进行规划，简要阐述理由。并标注：详细人力投入计划见《项目详细进度计划》。采购计划编写要求采购计划对项目进度的影响有时是致命的。某些开发任务可能因为所需要的产品没有到货而不能开始，某些测试任务因为某些硬件平台不能及时到货而发生延期。采购计划中的进度应该与项目进度计划保持一致。采购计划可以采用Excel表格形式编制。内容要素项目采购计划采购批次序号项目阶段采购时间采购内容规格型号单价数量总价采购目的采购方式候选公司到货时间到货地点责任人备注112…2345………总预算计算采购的总预算，并分述采购支出结构培训计划编写要求培训计划一般包括两方面的内容：项目执行期间，为了提高项目成员某些技能所进行的培训；项目结束后，为了让项目的交付物顺利地被使用，对相关应用部门的人员进行的培训。培训计划中的进度应该与项目进度计划保持一致。培训计划可以采用Excel表格形式编制。内容要素项目培训计划培训期次培训时间培训地点培训内容培训目的培训教材培训老师人员范围培训人数考核形式备注123…质量保证计划编写要求质量保证计划是保证系统开发质量的关键，因此应在项目计划阶段形成完善的质量保证计划。质量保证计划应着重阐明系统开发过程中项目组的质量管理人员的职责、各项质量保证活动的具体内容。内容要素1.引言1.1.目的说明本计划的编制目的，指出预期的读者。。1.2背景说明项目的名称、任务提出者、开发部门及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.管理2.1.质量保证组织2.2.任务描述各阶段的任务，重点是质量保证活动。2.3.职责指名每个任务的负责单位或成员的责任。3.文档列出软件开发过程中需要编制的文档名称，并描述对文档进行评审与检查的准则。（文档计划）4.系统开发过程中应遵守的标准、规范和约定5.评审和检查规定需进行的技术和管理两方面的评审和检查工作，以及相关的评审和检查规程、通过的技术准则。尤其是应明确对委托其它公司参与开发部分的评审和检查。6.质量活动的支持工具、技术和方法7.开发过程中对购买软件的控制8.系统开发期间有关质量保证活动的记录的收集、维护和保存风险管理计划编写要求为了有效预防和控制风险，项目组必须认真编制风险管理计划。计划要求对项目中可能遇到的风险进行识别，对每个风险项计算概率和影响程度，按照风险值矩阵计算风险值，按优先级进行排序，填写到项目风险管理计划表中。项目风险管理计划可以采用Excel表格形式编制。内容要素项目风险管理计划序号风险描述项目阶段阶段任务风险概率影响程度风险值预计发生时间责任人防范和控制计划风险状态123…备注：1）风险概率的值在0-1之间；2）影响程度在0-1之间；3）风险值=风险概率*影响程度；4）风险状态设置为open或close。配置管理计划编写要求配置管理的对象主要是项目开发所依据和产生的配置项，配置项是指软件生命周期各个阶段产生的各种版本的文档、软件及其数据、使用的开发工具和系统环境的集合中的每一个元素。配置管理计划应在计划阶段完成，主要应包括以下内容：（1）项目组内负责系统配置管理的组织及其职责。（2）配置管理活动。包括配置项的标识和追踪、更改控制和配置状态报告等方面内容。配置项的标识和追踪主要围绕制定和实施两个过程开展，对每个配置项的标识应唯一，该计划要便于追踪配置项的每个更改过程和更改历史，并能清楚地掌握该配置项当前的准确状态；更改控制应包括对更改的标识、记录、评审、批准、验收的步骤和要求；配置状态报告的对象包括三个方面，即配置项的状态，更改申请和对已被批准更改的实施情况。（3）配置管理使用的工具、技术和方法。内容要素1.引言1.1.目的说明本计划的编制目的，指出预期的读者。。1.2背景说明项目的名称、任务提出者、开发部门及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。管理2.1项目组内配置管理的组织及任务2.2配置管理人员及职责2.3配置管理中适用的标准、条例和约定配置管理活动3.1配置标识3.2配置控制3.3配置状态报告和记录3.4配置检查和评审工具、技术和方法在系统的开发过程中，使用了哪些与配置管理有关的工具：系统测试工具、配置管理工具、文档辅助生成工具和图形编辑工具。对外保部分的控制系统开发期间有关配置管理活动的记录的收集、维护和保存开发合同编写要求具体内容格式参考建行的有关规定。在正式合同文本中应强调质量条款。内容要素应包括的质量条款：1）验收准则2）在开发过程中对需求更改的处理3）对验收后出现的问题的处理，包括与质量有关的索赔和投诉4）指明需求方应进行的活动5）指明采用的标准和规程6）软件和文档的交付、安装的要求项目周/月报编写要求项目周/月报是向上级主管部门提供项目进展情况的报告，主要说明项目计划执行情况和进展状况以及问题解决办法。内容要素参见《项目报告制度》。会议纪要编写要求项目组与其他部门的正式会议以及项目组内部的工作会议形成会议纪要。内容要素会议纪要编号：会议名称会议时间会议地点会议主持出席人员缺席人员会议记录会议内容对于重要的会议，可以详细记录与会人员的发言；一般性的会议，可以经过总结只记录会议要点。该部分内容可以根据情况灵活掌握。会议结论会议是否达到了预期目的，如果没有达到，是否有必要再次召开相关会议进行讨论。呈送发送评审报告编写要求在项目开发过程中的适当时间对项目阶段性工作结果进行评审，是保证项目开发质量的重要方法。在每次评审中，必须编写评审报告，以利于项目管理工作。内容要素评审报告编号：项目名称项目经理项目所处阶段评审任务说明本次评审的主要任务以及主要的评审材料评审时间评审地点评审记录本次评审发现的问题记录及建议，如果内容较多，以附件形式体现。评审结论对评审是否通过提出结论性意见。对通过的项目确定是否需要再做修改；对未通过的项目说明问题原因，并确定问题修改后是否需要再作评审。评审组成员工作单位职务/职称签字……试运行报告编写要求试运行报告应在项目试运行阶段后期，由试运行的用户编制完成。编制的目的是为了总结本项目试运行的情况，分析判断系统是否满足项目需求，评价项目能否取得预期的效益，总结经验与教训，为实际投入正常运行或推广提供经验。内容要素1.引言1.1目的说明编写本文的目的，指出预期的阅读范围。1.2背景说明项目的名称、任务提出者、开发部门及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.试运行情况2.1试运行进度安排2.2系统试运行功能介绍2.3业务情况或使用效果用数据说明试运行前后业务对比情况。3.试运行结论3.1满足项目需求情况3.2预期项目效益情况3.3经验与教训3.4评价项目开发总结报告编写要求项目开发总结报告应在项目试运行阶段编制完成。编制的目的是为了总结本项目开发工作的经验，说明实际取得的开发成果以及对整个开发工作各方面的评价，因此应着重说明本项目的经验与教训。内容要素1.引言1.1目的说明编写项目总结报告的目的，指出预期的阅读范围。1.2背景说明项目的名称、任务提出者、开发部门及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.实际开发结果2.1最终提交的产品2.2最终应用系统主要实现功能和性能2.3主要实现功能和性能是否达到预期的目标2.4系统的基本处理流程2.5项目实际的开发进度2.6项目实际的费用支出3.对开发工作的评价3.1对开发进度的评价3.2对应用系统质量的评价3.3对技术方法的评价3.4对开发过程中出现错误的原因分析4.经验与教训说明这项开发工作中得到的经验与教训，对今后的项目开发工作的建议。项目技术报告编写要求项目技术报告应在项目试运行阶段编制完成。编制的目的是为了总结本项目所开发的系统，在关键技术或新技术方面的应用情况，进行评价，并说明经验与教训。内容要素1.引言1.1目的说明编写本文的目的，指出预期的阅读范围。1.2背景说明项目的名称、任务提出者、开发部门及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.实际开发结果2.1最终提交的产品2.2最终应用系统主要实现功能和性能2.3主要实现功能和性能是否达到预期的目标3.对技术方面的评价3.1关键技术及评价3.2新技术应用及评价3.3其他技术应用情况及评价4.经验与教训说明本次项目开发工作中，技术应用方面的经验与教训，对今后项目开发技术应用方面的建议。技术文档编制规范项目技术文档是描述项目开发对象和过程的文档，包括需求、设计、测试、实施等内容。在一个项目的开发过程中，要产生各种技术文档，各个文档的内容、要求和侧重点不同，产生的时间不同，预期的读者不同，有些文档的编写工作可能要在若干个阶段中持续进行。本章主要提供了软件开发类项目和工程实施类项目在开发过程中所应产生的技术文档的编写要求和内容要素。在编制文档的过程中，要保证文档的质量，体现每个项目的特点，综合考虑各方面的因素，灵活掌握文档的编制种类和详细程度，进行合理的裁减、合并或细化、扩展。以下将对基本的技术文档提出具体编写要求和内容要素。项目建议书编写要求项目建议书在可行性研究初期，由项目申请单位编写。描述所建议开发系统的背景和必要性，说明项目目标和范围，测算项目产出。内容要素1、引言1.1目的说明编写本需求书的目的，指出预期的读者。1.2背景说明待开发的项目名称及提出部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2、背景推荐项目背景及开发的必要性和迫切性。3、目标简要说明推荐项目的目标。4、范围逐一列出为实现目标，待开发项目需实现的功能或任务。5、产出分析量化分析产出，说明推荐项目的价值。可行性研究报告参照有关项目管理规定的要求编制。项目需求书（业务需求说明书）编写要求项目需求书在需求分析前，由需求人员编写完成，它要求完整、准确地描述所建议开发系统的具体实现功能，对输入输出数据的要求，作为需求分析的基础和依据。内容要素1、引言1.1目的说明编写本需求书的目的，指出预期的读者。1.2背景说明需开发的项目名称及提出部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2、功能描述描述现有系统的业务处理流程和业务量说明要求开发的系统实现的功能对于系统输入输出数据的要求要求准确、完整地说明需开发系统的输入输出数据相互之间的关系，对输入数据的限制和输出数据的要求对于要求开发系统的性能要求说明需开发系统在处理数据的能力和速度等方面的要求信息安全保密方面的要求应用系统操作方面的要求运行保障方面的要求项目需求说明书（需求分析说明书）编写要求项目需求说明书的编制是为了使项目提出者与开发者双方对项目的需求有一个共同的理解，使之作为整个开发工作的前提和基础。项目需求说明书应在项目开发的需求分析阶段形成，要求详细、准确地说明待开发项目的任务和具体实现功能，准确描述待开发系统的全部功能、性能、安全性和可靠性，这些需求应完整地、无歧义地写明，并足够精确，以便作为产品验收时确认的依据。内容要素1.引言1.1目的说明编写本需求说明书的目的，指出预期的读者。1.2背景待开发的系统名称；待开发项目的提出部门、开发部门及使用部门；该项目同其它项目或其它部门的相互关系。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.待开发项目任务概述2.1说明待开发项目的应用范围和使用部门2.2说明待开发项目所需实现的目标2.3解释本项目与其它项目之间的关系3.待开发项目的需求规定3.1对实现功能的规定3.2对系统性能的规定3.3对输入输出项的要求3.4对数据的要求3.5故障处理能力的要求3.6安全要求3.7其他专门的要求，如使用方便、可维护性、可扩展性、可靠性、可移植性等方面的要求4.说明待开发项目对运行环境的规定4.1对硬件设备的规定4.2运行所需的支持软件的规定4.3待开发项目与其它项目之间的接口、协议等4.4运行的方法项目技术方案编写要求在新产品、优化改造项目的计划阶段，项目组必须认真编制项目技术方案，对项目立项申请报告中的实施方案进行细化。内容要素1.引言1.1目的说明编写本文的目的，指出预期的读者。1.2背景待开发系统的名称、任务的提出者、开发者及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.系统功能目标综述系统要实现的目标和功能。3.系统架构4.接口设计5.环境规划规划项目开发、运行所需的硬件、软件、网络环境要求。6.安全保密设计7.系统维护设计概要设计说明书编写要求概要设计说明书应在概要设计阶段完成，说明了软件系统的设计考虑，它的内容应侧重于该软件系统的基本处理流程、系统的组织结构设计、接口设计、运行设计、数据结构设计和出错处理设计等，为程序的详细设计提供基础。内容要素1.引言1.1目的说明编写本文的目的，指出预期的读者。1.2背景待开发系统的名称、任务的提出者、开发者及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.待开发软件的总体设计方案说明待开发软件：数据采集、主要的输入输出项、实现功能和性能方面的要求待开发项目运行的硬件环境和支持软件基本设计概念和处理流程软件系统的整体设计框架软件系统中需人工处理的过程概要设计中尚未解决的问题3.接口设计4.系统数据结构设计5.系统出错处理设计在系统出错处理设计中，应考虑：出错信息补救措施6.安全保密设计7.系统维护设计详细设计说明书编写要求详细设计说明书应在详细设计阶段完成。详细设计说明书应说明该系统中各个层次的每一个功能实现的设计细节。如果一个系统比较简单，则详细设计说明书可与概要设计说明书合并编写。内容要素1.引言1.1目的说明编写本文的目的，指出预期的读者。1.2背景待开发系统的名称、任务的提出者、开发者及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.系统的层次结构关系3.详细设计说明说明每个模块的设计考虑、设计思路、处理流程，作为具体实施时的依据和编码的基础。3.1模块1说明：模块的简单描述；模块实现的功能；模块所需达到的性能要求；数据采集和输入输出项；逻辑流程描述；和其它模块的接口和限制条件；测试要点；目前设计中尚未解决的问题。3.2模块2工程设计实施方案（实施工艺）编写要求工程设计实施方案（实施工艺）应在工程实施类项目的设计阶段编写完成。设计实施方案说明了该系统的设计考虑，它的内容应侧重于系统的实现功能、设计方案、实施方案、技术方法说明等，为工程具体实施提供依据。内容要素1.引言1.1目的说明编写本文的目的，指出预期的读者。1.2背景待开发系统的名称、任务的提出者、开发者及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.系统总体设计方案说明：工程建设要求达到的目标工程建设完成的功能和性能方面的要求支持系统运行的硬件设备环境通讯网络环境的设计支持系统运行的主要建筑物的设计、施工和改造应用软件和数据库系统的设计、开发系统安全保密设计工程设计中尚未解决的问题3、具体实施方案说明：支持工程实施的人员、设备、资金情况各子系统的具体实施方案4、对工程实施中的技术难点和关键步骤的分析5、对工程实施中可能出现问题的分析和处理方法数据库设计说明书编写要求数据库设计说明书应在概要设计阶段开始，在详细设计阶段完成。它的编写目的是设计软件系统所使用的数据库，以便具体建立数据库。该设计说明书应侧重于描述待开发软件系统中所用的数据库的所有标识、逻辑结构和物理结构。内容要素1、引言1.1目的说明编写本文的目的，指出预期的读者。1.2背景待开发系统的名称、任务的提出者、开发者及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2、外部设计数据库的代码和名称提供给从事该数据库的生成、测试、维护人员的说明与该数据库直接相关的支持软件3、结构设计说明数据库的数据项、记录之间的关系说明数据库所确定的关键字和属性说明数据索引设计说明访问数据的方式方法4、运用设计说明数据字典的设计说明数据库安全保密方面的设计软件开发类项目技术手册编写要求软件开发类项目技术手册应在设计阶段开始编写，在测试阶段结束后完成。每审查完一个模块或一组密切相关的模块后编写一部分。技术手册编写目的是为将来的维护和修改工作提供有用的技术信息。它的主要内容应包括：模块开发情况；功能说明；设计说明；本模块包含的源代码说明及本模块的修改记录等。内容要素1.引言1.1目的说明编写本文的目的，指出预期的读者。1.2背景待开发系统的名称、任务的提出者、开发者及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.介绍各模块的开发情况简要说明各个功能模块的名称、实现功能、完成日期和通过测试情况。3.模块功能说明模块1说明：本模块的功能，主要是输入、处理流程、输出的数据；本模块在软件系统中所处的层次，它同其它模块的接口；本模块的处理流程、牵涉到的数据设计限制、驱动方式和出错信息；本模块的源代码测试情况；关键部分的详细程序流程描述。模块24.数据库说明工程实施类项目技术手册编写要求工程实施类项目技术手册应在工程实施阶段编写完成。为了方便今后的升级维护工作，大型和一般项目对于不同的子系统应分别提供单独的技术手册。内容要素1.引言1.1目的说明编写本文的目的，指出预期的读者。1.2背景待开发系统的名称、任务的提出者、开发者及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.分别描述各子系统的功能、设计和实现细节说明：应用系统和数据库系统技术说明硬件系统技术说明通讯网络系统技术说明有关机房建设的技术说明测试计划编写要求项目的测试计划应按项目的进展情况，编制单元测试计划、集成测试计划、系统测试计划、用户测试计划。测试计划的内容应说明测试的内容、进度安排、资源调度、测试用例及评价准则。内容要素1.引言1.1目的说明编写本文的目的，指出预期的读者。1.2背景待开发系统的名称、任务的提出者、开发者及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.具体测试计划测试项说明说明被测试项预期实现的功能和性能指标描述测试的内容测试1说明对于该项测试的测试内容、测试方法和测试人员。测试2……3.测试用例进行测试过程所需的数据集。根据需要可单独编制《测试用例集》，也可以包含在测试计划中。4.测试设计测试1说明测试内容的测试设计考虑，记录测试的控制方式、输入数据及预期输出的数据、测试过程、中间结果和运行信息。测试2……5.评价准则评价所选择的测试用例能够检查的范围及其局限性说明测试工作是否能通过的评价标准6.测试的组织管理测试（分析）报告编写要求测试（分析）报告应按项目的进展情况，编制单元测试报告、集成测试报告、系统测试报告和用户测试报告。测试分析报告的内容应说明测试的概要、发现的问题及分析、处理情况和测试结论。内容要素1.引言1.1编写目的说明编写本测试分析报告的目的，指出预期的读者。1.2背景说明测试的项目名称、测试任务，指出测试环境与实际运行环境之间可能存在的差异以及这些差异对测试结果的影响。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.测试概要列出每一项测试及其测试内容。若实际进行的测试工作内容与测试计划中预先设计的内容之间有差别，说明改变的原因。3.测试结果及发现的问题该项内容可用测试记录的方式体现。测试1把本项测试中实际得到的输出（包括内部生成数据输出）结果同测试计划中预期的输出结果进行比较而得出测试的结论，若存在差异，需说明原因。测试2……4.测试分析描述经过测试证实的缺陷和限制，说明这些缺陷、限制对系统可能造成的影响。5.结论5.1评价说明被测试系统是否达到预期目标，并对未能达到目标的内容进行分析说明。5.2建议提出对测试中发现问题的改进建议。上线方案编写要求项目上线试运行是项目实施的重要环节，风险性较高。上线试运行前，项目组必须认真编写上线方案。项目实施单位负责组织项目申请单位、运行管理部门、项目应用单位等相关单位的专家进行评审，确认项目具备上线条件、上线方案可行后，方可上线试运行。内容要素1.引言1.1目的说明编写本文的目的，指出预期的读者。1.2背景待开发系统的名称、任务的提出者、开发者及使用部门。1.3定义本文中用到的专门术语的定义。1.4参考资料本文中引用的参考资料和文件。2.组织机构介绍项目上线组织机构。3.上线计划指项目上线的总体安排，包括：上线方式、时间和进度安排等内容。4.培训不再单独编制，标注：详见《项目培训计划》。5.运行环境详细说明项目对运行环境的要求以及对现有系统的影响，运行环境指系统、网络和数据等软硬件环境。6.试运行对试运行的方案作详细说明，包括试运行的方式及其合理性分析、试运行检验的重点环节、试运行用户的选择、试运行计划、试运行准备、试运行切换和应急措施等内容。7.其它上线准备工作包括人员的准备、业务制度的准备、后勤保障、社会宣传以及告知客户的