01-软件研发项目工作手册.doc

文件编码 文件密级 内部公开文件 最新发布日期 当前版本 1.0 XX软件股份有限公司 研发项目工作手册 郑重声明：XX软件股份有限公司版权所有。本文档中任何部分未经XX软件股份有限公司书面授权，不得将材料泄露给第三方，不得以任何手段、任何形式进行复制与传播 变更履历 版本 日期 变更位置 变更理由/变更内容 变更人 备注 目 录 1. 概述 5 1.1 文档目的 5 1.2 适用范围 5 1.3 角色与职责 5 1.3.1 技术与产品管理委员会 5 1.3.2 项目管理委员会 5 1.3.3 项目高层经理 5 1.3.4 项目变更控制委员会(CCB) 5 1.3.5 研发项目经理 5 1.3.6 系统分析/架构师 6 1.3.7 软件开发工程师 6 1.3.8 美术设计师 7 1.3.9 测试工程师 7 1.3.10 实施工程师 8 1.3.11 配置管理工程师 8 1.3.12 品质保证工程师 8 2. 研发项目过程说明 9 2.1 项目立项 9 2.1.1 工作描述 9 2.1.2 相关工作产品 9 2.1.3 文档编写指南 10 2.1.4 经验分享 11 2.1.5 自检要素 11 2.2 项目计划与成本估算 12 2.2.1 工作描述 12 2.2.2 交付工作产品 13 2.2.3 文档编写指南 13 2.2.4 经验分享 14 2.2.5 方法与工具 14 2.2.6 自检要素 16 2.3 需求分析 17 2.3.1 工作描述 17 2.3.2 交付工作产品 17 2.3.3 文档编写指南 17 2.3.4 经验分享 18 2.3.5 方法与工具 18 2.3.6 自检要素 19 2.4 设计与开发 20 2.4.1 工作描述 20 2.4.2 交付工作产品 20 2.4.3 文档编写指南 20 2.4.4 经验分享 20 2.4.5 方法与工具 21 2.4.6 自检要素 23 2.5 测试 24 2.5.1 工作描述 24 2.5.2 交付工作产品 24 2.5.3 文档编写指南 24 2.5.4 经验分享 25 2.5.5 方法与工具 25 2.5.6 自检要素 26 2.6 发版 26 2.6.1 工作描述 26 2.6.2 交付工作产品 27 2.6.3 文档编写指南 27 2.6.4 经验分享 27 2.6.5 自检要素 27 2.7 系统上线/试运行 27 2.7.1 工作描述 27 2.7.2 交付工作产品 28 2.7.3 文档编写指南 28 2.7.4 经验分享 28 2.7.5 自检要素 29 2.8 项目验收 29 2.8.1 工作描述 29 2.8.2 交付工作产品 29 2.8.3 文档编写指南 29 2.8.4 经验分享 30 2.8.5 自检要素 30 2.9 项目结项 30 2.9.1 工作描述 30 2.9.2 交付工作产品 31 2.9.3 文档编写指南 31 2.9.4 经验分享 32 2.9.5 自检要素 32 3. 研发项目例行工作 33 3.1 项目管理 33 3.1.1 项目周例会 33 3.1.2 项目周报 33 3.1.3 项目里程碑报告 34 3.1.4 项目评审 34 3.1.5 风险管理 34 3.2 配置管理 35 3.2.1 项目及文档命名规范 35 3.2.2 项目变更 36 4. 过程裁剪指南及模板链接 37 5. 附录FAQ 45 1. 概述 1.1 文档目的 对公司研发项目管理流程进行详细描述，介绍研发项目工作流程、要点、指南和模板，为各研发项目组提供日常工作的指南。在经验总结、项目总结基础上，不断完善规范的有效性，提高项目文档质量，所有项目过程文档都能真正为项目所用；协助项目组解决项目过程中发生的问题，帮助推进项目，保证项目质量，提升研发项目生产效率，确保项目成功。 1.2 适用范围 适合公司所有研发项目，包括以研发为主导，连带实施的定制开发类项目组使用。 1.3 角色与职责 1.3.1 技术与产品管理委员会 技术与产品管理委员会是公司技术与产品方向的最高管理机构。委员会组成包括:副总和事业部班子成员。 1.3.2 项目管理委员会 项目管理委员会是项目管理相关问题的最高管理机构。委员会组成包括：副总和事业部班子成员。 1.3.3 项目高层经理 项目组高层领导负责总体项目监督工作。从战略层面上监控项目。 1.3.4 项目变更控制委员会(CCB) 负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。负责审核项目的变更。CCB一般有项目经理、高层经理、实施负责人、测试负责人等组成。 1.3.5 研发项目经理 研发项目经理负责建立和领导整个研发项目团队。通常项目经理应在一个或多个功能领域有管理层和操作层经验，并有管理过开发项目的经历。项目经理管理项目计划、预算、人员配置、资源、进度，负责创建和维护项目综合文档，评估并管理项目风险，整合项目立项报告和可行性研究报告并提交给技术与产品管理委员会和项目管理委员会进行审批，以做出投资决策和评审。项目经理负责对团队和相关人员进行培训，持续监控和管理项目，在项目结束后组织经验教训总结。主要职责如下： u 从技术与产品管理委员会、项目管理委员会、高层经理处获得承诺，确保所需资源的及时到位，并创建项目所需环境。 u 对项目的成本、进度、质量负责 u 建立和领导整个项目团队，负责团队建设 u 制定和管理跨部门的项目管理计划和项目进度计划，确保开发、测试、实施和支撑部门紧密相连 u 做出并满足项目交付、预算和时间进度方面的承诺，进行范围、成本、风险、计划、进度、质量、人员、沟通的管理 u 组织和参与各阶段的评审，确保各阶段评审材料和评审报告的有效性 u 跟踪项目过程中的问题，并对无法解决的重大问题进行上报 u 项目各阶段度量分析和经验总结 1.3.6 系统分析/架构师 系统分析/架构师由具有多年相关产品开发经验、具备多个领域的扎实专业知识和实践经验的人员担任。在一些项目中，可以由一个群体共同来承担系统分析/架构师的角色。系统分析/架构师在平台软件产品项目中承担确定总体规划、总体技术方案，主导需求分析、架构设计、接口设计以及关键技术等工作，并主导各个技术性评审。 u 参与项目总体规划、确定项目总体技术方案 u 提出项目技术备选方案和软件保护策略 u 整合不同种类和来源的需求，确定产品需求 u 对需求进行详细分析，完成《需求规格说明书》 u 对需求进行分解和分配 u 进行架构设计，完成《系统设计说明书》； u 在拥有开发接口的产品项目中，进行开发接口的设计，完成《接口设计说明书》 u 进行并指导软件开发工程师进行模块设计，主导非正式的模块设计评审 u 参与并主导各个技术评审，包括需求评审、技术方案评审、功能评审和发版评审 u 监控和管理产品需求和设计方案，参与变更控制过程。 1.3.7 软件开发工程师 软件开发工程师主要负责与产品相关的软件模块设计、编码实现、单元测试等工作。由公司产品事业部或混合事业部具有软件开发能力的人员担任。 u 参与分析技术备选方案 u 参与详细需求分析、架构设计 u 进行软件规模和工作量、难易度等的估算，辅助项目经理完成项目管理及进度计划 u 进行模块设计 u 编码实现 u 代码审查 u 单元测试 u 修改缺陷 u 参与各阶段技术评审，包括需求评审、总体方案评审、设计评审、功能评审、发版评审 1.3.8 美术设计师 美术设计师是研发项目中的软件界面美化设计和美术制作的人员。负责把美学及人性因素的设计事项考虑到产品的界面设计和图形中去。美术设计师在系统设计完成后配合软件工程师和测试工程师进行软件界面和产品资料的图形设计及实现等工作，并要负责保持整体产品形象的统一。 u 收集项目图形设计的需求，沟通并了解客户对视觉及人机交互的需求并提供反馈和建议； u 负责提供图形设计方案以供项目组选择； u 制定产品图形设计的计划并与整个项目进度计划配合； u 进行图形设计以支持完整的产品形象； u 与软件工程师和测试工程师一起从易用性、人机交互、图形用户界面、产品资料等方面进行测试和设计 1.3.9 测试工程师 测试工程师主要负责研发项目的测试工作。测试工程师通常由具有软件测试相关知识和经验并有相当测试能力的人担任。测试工程师在研发项目中参与制定项目总体计划，负责制定测试相关的计划并加以执行，收集整理并提交项目中关于测试方面的度量数据，分析质量状况并提交测试报告。 u 参与产品项目实施过程中的各项评审活动 u 明确可测试性需求，明确产品项目对测试的要求 u 协助制定项目管理、进度计划，负责制定测试部分的计划 u 执行各类具体的测试工作（单元/集成/系统/性能以及各类专项测试） u 收集整理确认各类产品缺陷提交到缺陷管理系统（JIRA），跟踪产品缺陷处理状况 u 整理分析并提交测试方面的度量数据（工作量/缺陷/进度等等） u 分析产品质量状况，提交测试报告 u 协助各方执行测试相关的工作 1.3.10 实施工程师 负责或者参与研发产品对应的实施项目的整体实施，完成实施项目的需求调研分析，参与项目的各项评审工作，作为验证方对研发项目的目标达成情况进行验证。 u 参与项目需求收集 u 参与项目的各项评审 u 负责将客户的需求及问题反馈给研发项目组 u 系统程序的测试和客户的数据准备整理 u 协调负责服务器的部署、调试 u 进行项目的培训文档编写，为客户进行培训 1.3.11 配置管理工程师 配置管理工程师是负责研发项目配置管理相关工作的人员，一般由产品事业部或混合事业部的部门助理兼任。配置管理工程师主要负责配置库的建立和管理、版本控制、基线建立，配置项变更的执行以及产品发版工作。 u 制定配置管理计划 u 创建配置管理环境 u 创建配置库 u 建立并公布项目研发过程的各类基线 u 配合项目组完成配置项变更控制工作 u 产品发行管理，包括产品的构建和发放 u 对相关人员进行相关配置管理培训 1.3.12 品质保证工程师 品质保证工程师是依据公司《研发项目管理流程》中既定的标准来检查项目过程和交付件是否符合规范，并辅助项目经理进行研发项目管理工作。QA由具有项目管理经验的人承担，致力于监控和提高所在项目的过程质量，以最终实现整个研发项目的质量目标。 制定项目质量计划和质量目标； u 辅助项目经理进行项目立项、成本估算 u 制定品质保证计划并实施 u 监督项目各项评审 u 监控质量活动，对项目的过程和交付件进行审计，提交质量报告，并在发现问题时和项目经理进行协商，必要时上报公司高层 u 汇总并分析项目度量数据 u 对项目组进行流程、质量体系方面的培训 u 配合项目经理对本项目的流程进行适当的裁剪 u 根据各研发项目的执行情况，对研发项目的流程进行优化和改进 2. 研发项目过程说明 2 2.1 项目立项 2.1.1 工作描述 在开展项目立项调查、可行性研究并确认项目需要立项后，由相关负责人填写《项目立项申请》和《项目基本信息表》，并向公司技术与产品管理委员会、项目管理委员会、高层经理、品质保证工程师、配置管理工程师发送项目立项申请邮件。 品质保证工程师对项目立项材料进行预审后，将预审结果反馈给立项负责人，待立项材料完善后发送公司技术与产品管理委员会、项目管理委员会、高层经理再次评审。相关领导评审后邮件回复立项意见，各方同意项目立项后才能召开立项启动会。 立项负责人应在立项会前组织相关成员编写《项目立项启动会PPT》，并提前向与会人员发送会议通知。 立项会结束后，由品质保证工程师建立成本对象并发送立项通知；配置管理工程师建立配置库；缺陷管理系统管理员在JIRA中建立项目相关信息。 项目立项以品质保证工程师发布的立项通知为结束标志。 详细立项流程及文档模板可参考《研发项目管理流程》\01项目立项中的《项目立项流程》及相关模板。 2.1.2 相关工作产品 u 《技术研究报告》（可选） u 《可研论证报告》（可选） u 《项目立项申请》（必须） u 《项目基本信息表》（必须） u 《项目立项申请邮件》（必须） u 《项目立项启动会PPT》（可选） u 《立项通知》（必须） 1 2 2.1 2.1.1 2.1.2 2.1.3 文档编写指南 （1） 《项目立项申请》 至少需包括：项目名称、项目属性、项目分类、项目来源、应用客户、需求概述、市场前景、项目目标、项目意义、技术可行性分析等。项目目标中必须包含功能目标、性能目标和应用目标。对于没有应用目标的特殊产品开发型项目需要由技术与产品管理委员会和项目管理委员会审批通过后方可立项。 项目属性主要分为产品开发型、普通、维护型、专题研究型。新产品研发和产品增强型开发项目填产品开发型项目，定制开发类项目填普通项目。 项目类型主要分为新产品开发项目、产品增强型开发项目、普通项目、维护型项目、实施型项目、专题研究型项目。 （2） 《项目基本信息表》 将《项目立项申请》中内容对应填入《项目基本信息表》； “项目级别”，一般都选普通成熟度； “所属产品系”，公司目前产品系主要分为：报表、BI、GMS、GSI、GMC、DNA及其他。请根据项目实际情况填写，如出现两者、两者以上结合或不好定位的，可以选择其他； “项目负责人”指项目经理； “项目联络人”指项目的市场负责人，如没有，可以不填； “实施负责人”，项目对应的实施相关项目的负责人，结项时需要对项目进行验证的重要方，必须填写。 与配置管理工程师协商，建立项目配置库，并将配置库地址写入《项目基本信息表》中，目前公司使用SVN配置管理工作，所有研发项目配置库需建立在SVN上。 “项目主要里程碑”，填写项目的各阶段的完成时间，此处对里程碑的定义可以根据项目的实际情况进行修改。对于瀑布型项目至少应该包括，启动、需求分析、设计与开发、测试与发版、结项5个里程碑。对于迭代型项目，除项目启动、结项，每个迭代过程至少要包括需求、发版两个里程碑。对于升级类且按需求、功能点开发的项目定义项目里程碑时应提前与品质保证工程师进行沟通，确定项目里程碑定义方式。定制开发类项目应包含上线/试运行完成、项目终验时间。 “项目主要提交物”，根据项目实际情况，对照研发项目管理流程中《项目标准化流程工作产品简表》进行裁剪，最终得到项目主要提交物清单。 （3） 《项目立项申请邮件》 根据研发项目管理流程中相应的模板来编写立项申请邮件，邮件至少需要发送给技术与产品管理委员会、项目管理委员会、高层经理、品质保证工程师、配置管理工程师。技术与产品管理委员会包含欧阳曜、孙建卫；项目管理委员会包含朱晓钧、曾祥逸；高层经理包含事业部总经理、项目立项负责人直接领导、测试中心负责人、信息资产管理部负责人。抄送品质保证、配置管理工程师及项目组其他成员。 《项目立项申请》、《项目基本信息表》应作为附件随邮件一起发送。 （4） 《项目立项启动会PPT》 建议内容项：项目背景、项目目标、主要工作内容、项目主要里程碑时间、项目投入人员、项目风险以及启动会上需要明确的其他事项。 （5） 《立项通知》 由品质保证工程师统一发送，至少要包括项目编号、项目名称、项目分类、所属产品系、项目级别、立项申请人、立项部门、应用客户、项目负责人、项目组成员、项目的配置库物理位置、成本对象及项目立项材料。 2.1.4 经验分享 u 应在立项前确定未来系统将要采用的主要技术路线进行研究和初步验证，尽可能的降低产品采用不合适的技术路线而带来的风险，完成《技术研究报告》。 u 为保证项目成功且有意义，建议立项前期多开展市场调查和可行性分析，并编写《可行性研究报告》。 u 项目立项前，立项负责人应尽量熟悉研发项目管理流程，并尽早与品质保证工程师进行沟通立项事宜。 u 项目立项启动会主要是确认团队的建立、让项目的相关方了解项目的背景和目标，并了解自己在项目中所负的职责，鼓舞团队士气。为减少资源浪费，启动会时间应避免太长。如项目工期紧张，可以裁剪立项启动会议，启动会相应的工作产品也可以进行裁剪。 u 品质保证工程师预审立项材料的重点为：项目编号是否符合公司规范；立项材料是否完整；项目目标是否包含了功能目标、性能目标和应用目标，而且目标必须是量化和可验证的；项目里程碑是否定义清晰、主要提交物有误疏漏等。 2.1.5 自检要素 ² 是否使用公司统一立项申请、基本信息表等模板 ² 是否具备项目的应用客户 ² 是否具有可验证、可量化的项目目标，包含功能、性能和应用目标 ² 是否已定义项目主要里程碑 ² 是否给高层经理、技术与产品管理委员会、项目管理委员会、QA发送立项申请邮件 ² 立项申请邮件是否通过高层经理、技术与产品管理委员会、项目管理委员会的审批 2.2 项目计划与成本估算 2.2.1 工作描述 1 2 2.1 2.2 2.2.1 2.2.1.1 项目计划 项目经理根据项目实际情况，按照项目管理计划模板，制定出项目管理计划。主要包括：项目目标、项目环境资源需求、项目过程定义、主要里程碑、项目人力资源计划、干系人介入计划、项目组培训计划、评审计划、度量数据收集与分析计划、可交付成果清单、方法与工具等。 根据项目管理计划中的里程碑时间点制定项目详细进度计划。进度计划中应进行任务细分，将每个阶段的工作细化，并规定完成时间以及负责人。可使用Project或Xls编写进度计划。 项目经理需要识别项目潜在风险，并使用《项目风险/重大跟踪表》记录和跟踪风险状态。 配置管理员与项目变更控制委员会（CCB）确认项目的访问控制、基线和版本策略、分支版本策略、构建发布策略、变更控制策略等，建立配置管理计划。 由品质保证工程师根据项目开发计划中的时间进度，制定针对其具体过程和产品的品质保证计划。计划中需要根据项目的特征确定检查哪些过程和工作成果，还需要计划检查的时间和人员。 测试负责人根据项目管理计划和需求规格说明书对项目的测试进度、测试资源的投入、测试的整体思路和测试重点等进行计划，完成项目测试计划。 项目管理计划及附属计划评审，使用评审报告记录和跟踪评审发现问题。如项目工期紧张，该项评审工作可采用邮件评审方式。 需求范围明确后，需要对项目管理计划中的里程碑时间点、人员安排等做调整，各附属计划也进行相应调整。 2.2.1.2 成本估算 项目立项且需求基本确定后，由项目经理根据项目的实际情况，会同分管领导意见，提出项目奖金申请，申请过程通过编报《项目详细进度计划》、《项目成本估算、奖金核定表（研发）》、并将完成的相关材料通过邮件发送给运营监管中心项目监管部并抄送主管领导，进行审批。 2.2.2 交付工作产品 u 《项目管理计划》（必须） u 《项目详细进度计划》（必须） u 《风险/重大问题跟踪表》（必须） u 《配置管理计划》（必须） u 《品质保证计划及路线图》（必须） u 《测试计划》（必须） u 《项目成本估算、奖金核定表（研发）》（如申请奖励，必须提交） 所有项目经理使用的文档模板存放在《研发项目管理流程》\00项目管理中的相关模板。配置管理模板存放在《研发项目管理流程》\00配置管理中；品质保证模板存放在《研发项目管理流程》\00品质保证中；测试相关模板存放在《研发项目管理流程》\03系统稳定。 2.2.3 文档编写指南 （1） 《项目管理计划》 项目经理在制定项目管理计划时，至少要明确，项目目标与内容、项目所需资源及环境要求、项目过程定义、项目主要里程碑、人力资源计划、干系人介入计划、项目度量计划、项目评审计划、提交的工作产品清单、方法与工具等。 项目过程定义主要是根据项目实际情况按照《项目标准化流程工作简表》对项目过程进行裁剪；项目干系人介入计划主要明确项目相关干系人何时、如何介入项目；项目度量计划和评审计划目前模板中已经有固定的数据了，项目经理可以根据项目情况进行裁剪。需求、开发规模的度量，计划、需求、功能评审都是必须要做的。 （2） 《项目详细进度计划》 根据项目管理计划使用xls或MS Project 编写项目详细计划，项目详细计划中的工作包颗粒度要细，每个工作包需要投入的资源及资源投入百分比都需要填写。项目进度计划制定后，应定期进行跟踪、更新、细化，至少1-2周一次。 （3） 《风险/重大问题跟踪表》 制定项目计划的同时，对项目潜在风险进行识别，并记录在风险/重大问题跟踪表的上半部分，如果风险发生，转变为问题后，应该更新风险的状态，并将问题记录在风险/重大问题跟踪表的下半部分进行跟踪。对风险和问题的跟踪也应是定期的，至少1-2周一次。 （4） 《配置管理计划》 该计划主要由配置管理员完成，主要包含命名规范的定义、配置管理环境的说明、配置项识别、基线定义等，按照公司的统一模板来编写。 （5） 《品质保证计划及路线图》 由品质保证工程师完成，主要明确品质保证工程师在那些点介入项目，进行审计和检查。 （6） 《测试计划》 由测试负责人完成，对测试环境、测试目标、测试资源、测试里程碑进行定义。 （7） 《项目成本估算、奖金核定表（研发）》 如果项目申请研发奖励，在完成详细进度计划后，将每个阶段的资源、工作量等信息填入成本估算、奖金核定表中。 2.2.4 经验分享 项目管理计划及附属计划完成后需进行评审，评审可采取邮件或会议形式，为节约资源，一般都建议采取邮件评审方式。项目计划出现变更时，相关附属计划都需要随之进行变更。 项目管理计划中，比较容易忽略的资源环境、干系人介入计划一定要按实际情况填写，评审计划、度量数据收集计划、项目使用的方法与工具应按照项目实际情况进行填写。提交的工作产品清单应尽量详细，命名也要规范，要与项目过程定义时确认需要提交的工作产品保持一致。 制定项目计划阶段要重视风险识别，最好所有干系人都参与风险识别，可以参考类似项目，必要时向专家请教。需求、设计阶段要持续进行风险识别。可以从功能、质量、性能角度识别技术风险，从人力资源状况识别管理风险。 《项目管理计划》评审通过后，有关人员即可撰写下属计划如《配置管理计划》、《质量保证计划》、《测试计划》等。 制定项目计划时，选用合适的软件工具，尽量减少项目计划的工作量。 2.2.5 方法与工具 在进行进度和成本估算时可使用以下方法： （1） 专家判断法 即请本领域的专家来判断执行项目各工作所需时间的长短。工作持续时间的估计常常是相当困难的，它要涉及到众多的因素，一般很难找到一个通用的计算方法，这个时候专家的历史经验和记录就显得尤为重要，尽管这种方法的结果也具有一定的不确定性和风险，但仍然不失为一种行之有效的方法。 （2） 三时估算法 一般地还可以通过估计完成工作的最乐观时间、最悲观时间及最可能时间按下式来估算工作持续时间：工作持续时间 =（乐观的时间＋4×最有可能的时间＋最悲观的时间）/6 （3） 经验估算法 进行估计的人应有专门知识和丰富的经验，据此提出一个近似的数字。这种方法是一种最原始的方法，还称不上估算，只是一种近似的猜测。它仅适合于要求很快拿出一个大概数字的项目。 （4） 自上而下估算法 此方法一般要求有类似完成项目的经验的情况下使用。其主要内容是：收集上、中层管理人员的经验和判断，以及相关历史数据，然后上、中层管理人员估计整个项目的费用和各个分项目的费用，将此结果传送给下一层管理人员，责成其对组成项目和子项目的任务和子任务的费用进行估算，并继续向下传送其结果，直到项目组的最基层。 这种过程和层级计划制定的过程类似，费用如同项目一样，按照WBS过程，从最高层到最底层进行逐层分解。 这种方法的缺点是特别需要建立好上下管理层畅通的沟通渠道。因为上层管理人员根据经验得出的费用估算结果可能不能满足下层管理人员认为完成任务的需要。此时若不能适当地沟通，费用分配方案失去原有的作用而变成完成项目任务的阻碍，从而导致项目的失败。 使用此方法的好处是中、上层管理人员能够比较准确地掌握项目整体费用分配，从而使项目的费用能够合理地控制在一个水平上，一定程度上避免了项目的费用风险。 （5） 自下而上估算法 该方法是指参与项目工作的每一机构和基层单位都估算自己的费用，将估算结果加起来的总和，得到该项目的整个估算费用。具体地可按照WBS体系，从下而上估算各个工作的费用，得到项目的直接费用估计，项目经理再在此基础上加上合理的间接费用，估算出项目的总费用。 根据软件程序模块的标识和定义，估计代码的行数，可近似确定开发和测试软件的费用。 这种方法的缺点在于要保证所有的工作和任务都被考虑到，而且对每个工作单元有过高估算的倾向，往往导致最后的费用估算无法接受。 它的优点在于比起高层管理人员来，底层直接参与项目工作的人员更清楚项目工作所需资源的种类和数量，费用估算更为精确。而且费用估算出自他们自己的估计，可以避免以后费用预算过程中的一些冲突和不满。 （6） 类比估算法 即比照以前的经验，或比较以往类似项目的档案资料，根据以前的类似的实际项目的工作时间来推测估计当前项目各工作时间的。如果当前的项目与类比的项目很类似时，类比估计是一种最有效的方法。 类比估算中的不确定性归根结底是由技术人员和费用估算人员所作的主观评价引起的。在多数情况下，可以进行实际的技术比较。问题是在技术差异的基础上建立费用关系，甚至当技术人员做出的所有决策都可以定量客观评价时，费用估算人员还需要确定有关技术发现的费用影响。在很多情况下，这些费用影响是非常主观的，因而，这种估算还是具有较大的不确定性。类比估算适用于项目早期，此时还没有系统的实际费用数据，也没有相似系统的大型数据库，只有此种方法的估算较为准确。 2.2.6 自检要素 ² 相关文档的命名是否符合公司相关规范，是否以项目编号+项目名称+文档名称的方式命名 ² 项目管理计划里程碑时间点是否是具体的日期，并且有标志性提交物 ² 项目管理计划最终提交工作产品清单是否全部包含了项目裁剪后生命周期模型所要求的工作产品 ² 是否制定了项目组必须的培训计划（包含对内培训和对外培训） ² 是否对项目的风险进行了识别，制定了风险管理措施 ² 是否识别了相关干系人，并对干系人介入的活动进行了定义 ² 项目进度计划中，工作任务的工期、工时、起止时间、资源是否否已明确定义 ² 项目的沟通计划是否清晰明确 ² 项目的评审、度量计划是否已制定 ² 项目管理计划及其附属计划是否经过正式评审（邮件或会议），并保留了评审记录 ² 进行成本估算时，项目的主要需求是否已确定 2.3 需求分析 2.3.1 工作描述 如需要进行需求调研，项目组应制定需求调研计划，充分了解调研对象的基本情况、需求范围及规模等；明确需求分析过程的进度和人员等计划安排；确保项目组按可执行的需求分析计划进行需求调研，引导客户届时提供相关资源，最终形成《调研报告》。 根据获取用户的需求信息，经过需求整理和分析后确定《需求说明书》 定义产品功能、性能等需求，细化《需求说明书》，逐步形成《需求规格说明书》。 对需求阶段工作产品进行评审，使用《评审报告》记录和跟踪评审发现问题。 对各项需求的变更进行控制，防止需求发生混乱。 2.3.2 交付工作产品 u 《调研计划》（可选） u 《调研报告》（可选） u 《需求说明书》（可选） u 《需求规格说明书》（必须，或者用需求说明书+原型的方式代替） u 《相关评审报告》（必须） 2.3.3 文档编写指南 （1） 《调研计划》 调研计划应尽量简单明了，主要明确调研对象及调研的日程安排，以及需要被调研部门配合的相关事项。 （2） 《调研报告》 调研报告中主要记录调研的结果（访谈的重点记录）、通过调研已确认的事项以及下一步需要明确的要点和遗留问题。 （3） 《需求说明书》 描述项目的总体需求、主要包含业务和非业务需求两大块。需求说明书中还需介绍项目的背景、目标等。 （4） 《需求规格说明书》 需求说明书的深化版，重点介绍每一个模块的功能要求、非功能要求。非功能要求也属于软件的重要组成部门，一定不能忽略。每个功能点都应该有唯一的编号。 部分定制开发类项目的需求说明书+原型可以代替需求规格说明书，具体要与QA进行确认。 （5） 《相关评审报告》 主要记录项目每次需求评审的评审规模、工作量等，评审发现问题以及对问题解决情况的验证。 2.3.4 经验分享 如果需求调研任务较重且大的，建议调研前先做个调研提纲，避免调研时沟通不顺畅。 做需求时应该从用户角度出发，直接与客户进行沟通，挖掘出客户内在的需求和问题，避免二次、三次传递的信息失真。 比较理想的做法，需要将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求说明书－需求规格说明书－设计文档－代码－测试用例”之间的一致性，确保产品依据需求文档进行开发，使得需求能定期进行跟踪。对需求的跟踪还是比较重要的。 每个产品，无论是新产品开发还增强型开发，都应该有一个项目总体的需求定义文档，而不单单是分散的、每个功能模块的需求文档。 非业务需求，需要引起项目组的重视，每个需求文档汇总都应包括非业务需求。 需求评审建议采用会议评审方式进行，如单个的评审报告不好对问题进行跟踪，建议可以使用jira或评审问题跟踪表代替评审报告跟踪和验证评审发现问题。 为节省需求评审时间，建议将待评审的工作产品事先发给相关干系人进行预审。 2.3.5 方法与工具 最常用的需求捕获方法： （1） 用户访谈 用户访谈是最基本的一种需求捕获手段。其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行；非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的还是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。用户访谈前应准备问题并注意访谈时的技巧。 （2） 用户调查 用户访谈时最大的难处在于很多关键的人员时间有限，不容易安排过多的时间；而且客户面经常比较广，不可能一一访谈。因此，就需要借助“客户调查”，通过精心设计要问的问题，然后下发到相关人员的手里，让他们填写。 （3） 现场观摩 百闻不如一见，对于许多较为复杂的流程和系统而言，是比较难以用语言表发清楚的，而且这样做也会显得很低效。针对类似问题可以采用现场观摩的方法来获取需求。 （4） 文档查阅 对于一些数据流程比较复杂的，工作表单较多的项目，有时是难以通过说，或者通过观察来了解需求细节的。这时可能需要对历史存在的一些文档进行研究，需要从已有的数据文件、文档、表单中获得所需的信息。 （5） 讨论会 讨论会是我们常用的且成本较高的需求获取方法，但是也是十分有效的一种。它通过联合各个关键客户代表、分析人员、开发团队代表一起，通过有组织的会议来讨论需求。 在整个需求过程，需求捕获、需求分析、需求规格化、需求验证四个阶段不是瀑布式的发展，而是应该采用迭代式的演化过程。在需求捕获时，不要期望一次就把需求收集完，而是应该捕获到一些信息后，进行相应的需求分析，并针对分析中发现的疑问和不足，带着问题再进行有针对性的需求捕获工作。 2.3.6 自检要素 ² 需求是否存在二义性 ² 需求文档的上下文是否有矛盾 ² 需求是否完备 ² 需求是否都是必要的 ² 需求是否都是可实现的 ² 需求是否都是可验证的 ² 是否确定了需求的优先级 ² 是否定义了非业务需求 ² 是否对需求项进行唯一标识 ² 是否有《需求跟踪矩阵》 ² 是否所有的需求项都能与设计、测试用例等进行对应 ² 需求是否进行了评审，并对评审发现问题进行了修改和验证 ² 需求基线建立后,所有对《需求规格说明书》的变更是否进行跟踪，需求的变更是否走了正式的变更流程 2.4 设计与开发 2.4.1 工作描述 分析与设计软件的体系结构，产生《概要技术方案说明书》。 对系统数据进行设计，定义各数据实体的存储结构，确定结构、约束、索引、关系等，产生《数据库设计说明书》 设计关键用户界面，设计软件模块的主要接口、类、数据结构、算法，产生《模块设计说明书》 完成代码的编写，并通过单元测试，完成集成测试所需要的产品 2.4.2 交付工作产品 u 《技术研究报告》（可选） u 《概要技术方案说明书》（可选） u 《数据库设计说明书》（可选） u 《模块设计说明书》（可选） u 《相关评审报告》（必须） 2.4.3 文档编写指南 （1） 《技术研究报告》 需要明确项目的技术路线，描述集中可能用到的技术路线，并加以对比分析，最终确认可行的技术路线。 （2） 《概要技术方案说明书》 确定项目的总体框架、关键技术。 （3） 《数据库设计说明书》 主要描述项目总体ER图及各模块的ER图，项目各表之前的关系及表结构。 （4） 《模块设计说明书》 主要对各模块的类图、调用关系、接口等进行设计。 （5） 《相关评审报告》 如项目有设计工作，设计工作产品应及时进行评审，每个项目都必须做功能评审。 2.4.4 经验分享 目前公司多数产品都是基于D&A平台进行开发的，一般都是做完需求规格后直接就进行开发，项目的设计工作可以根据项目具体情况进行裁剪，单元测试、功能评审一定要做。 系统设计可分为两个部分进行，首先是总体设计，其任务是系统的总体结构进行设计 ，在此基础上进行第二阶段——详细设计，它的任务是在系统总体设计的指导下，对系统各组成部分进行细致、具体的物理设计，使系统总体设计阶段所作的各种决定具体化 。 对开发人员进行“代码审查、测试、改错”等方面的培训，提高他们的工作效率。 开发小组根据产品的特征，可以适当地修改本规范的各种文档模板。 代码设计的基本原则：具备唯一确定性；标准化与通用性 ；可扩充且易修改；短小精悍即选择最小值代码；具有规律性、便于编码和识别。 2.4.5 方法与工具 （1） 结构化设计方法 结构化设计方法的基本思想是将系统设计成由多个相对独立，功能单一的模块组成的结构。由于模块之间相对独立，每个模块就可以单独地被理解、编写、测试和修改，从而防止错误在模块间蔓延，提高了系统的质量。它的特点主要有：相对独立，功能单一的模块结构；“块内联系大，块间联系小”的模块性能标准。目前公司的产品大多采用此方法。 一个模块应具有以下四个要素： 1）输入和输出 数据的来源和去向； 2）处理功能 把输入数据转换为输出数据所做的工作； 3）内部数据 仅供该模块本身引用的数据； 4）程序代码 用来实现模块功能的程序； （2） IPO图 IPO图是对每个模块进行详细设计的工具。在系统的模块结构图形成过程中，产生大量模块，在详细设计时，开发者为每一个模块写一份说明。用来说明每个模块的输入、输出数据和数据加工。它的主体是算法说明部分，该部分可采用结