软件研发项目工作手册

精品文档精心整理精品文档可编辑的精品文档文件编码文件密级内部公开文件最新发布日期当前版本1.0XX软件股份有限公司研发项目工作手册变更履历版本日期变更位置变更理由/变更内容变更人备注

目录1. 概述 51.1 文档目的 51.2 适用范围 51.3 角色与职责 51.3.1 技术与产品管理委员会 51.3.2 项目管理委员会 51.3.3 项目高层经理 51.3.4 项目变更控制委员会(CCB) 51.3.5 研发项目经理 51.3.6 系统分析/架构师 61.3.7 软件开发工程师 61.3.8 美术设计师 71.3.9 测试工程师 71.3.10 实施工程师 81.3.11 配置管理工程师 81.3.12 品质保证工程师 82. 研发项目过程说明 92.1 项目立项 92.1.1 工作描述 92.1.2 相关工作产品 92.1.3 文档编写指南 102.1.4 经验分享 112.1.5 自检要素 112.2 项目计划与成本估算 122.2.1 工作描述 122.2.2 交付工作产品 132.2.3 文档编写指南 132.2.4 经验分享 142.2.5 方法与工具 142.2.6 自检要素 162.3 需求分析 172.3.1 工作描述 172.3.2 交付工作产品 172.3.3 文档编写指南 172.3.4 经验分享 182.3.5 方法与工具 182.3.6 自检要素 192.4 设计与开发 202.4.1 工作描述 202.4.2 交付工作产品 202.4.3 文档编写指南 202.4.4 经验分享 202.4.5 方法与工具 212.4.6 自检要素 232.5 测试 242.5.1 工作描述 242.5.2 交付工作产品 242.5.3 文档编写指南 242.5.4 经验分享 252.5.5 方法与工具 252.5.6 自检要素 262.6 发版 262.6.1 工作描述 262.6.2 交付工作产品 272.6.3 文档编写指南 272.6.4 经验分享 272.6.5 自检要素 272.7 系统上线/试运行 272.7.1 工作描述 272.7.2 交付工作产品 282.7.3 文档编写指南 282.7.4 经验分享 282.7.5 自检要素 292.8 项目验收 292.8.1 工作描述 292.8.2 交付工作产品 292.8.3 文档编写指南 292.8.4 经验分享 302.8.5 自检要素 302.9 项目结项 302.9.1 工作描述 302.9.2 交付工作产品 312.9.3 文档编写指南 312.9.4 经验分享 322.9.5 自检要素 323. 研发项目例行工作 333.1 项目管理 333.1.1 项目周例会 333.1.2 项目周报 333.1.3 项目里程碑报告 343.1.4 项目评审 343.1.5 风险管理 343.2 配置管理 353.2.1 项目及文档命名规范 353.2.2 项目变更 364. 过程裁剪指南及模板链接 375. 附录FAQ 45

概述文档目的对公司研发项目管理流程进行详细描述，介绍研发项目工作流程、要点、指南和模板，为各研发项目组提供日常工作的指南。在经验总结、项目总结基础上，不断完善规范的有效性，提高项目文档质量，所有项目过程文档都能真正为项目所用；协助项目组解决项目过程中发生的问题，帮助推进项目，保证项目质量，提升研发项目生产效率，确保项目成功。适用范围适合公司所有研发项目，包括以研发为主导，连带实施的定制开发类项目组使用。角色与职责技术与产品管理委员会技术与产品管理委员会是公司技术与产品方向的最高管理机构。委员会组成包括:副总和事业部班子成员。项目管理委员会项目管理委员会是项目管理相关问题的最高管理机构。委员会组成包括：副总和事业部班子成员。项目高层经理项目组高层领导负责总体项目监督工作。从战略层面上监控项目。项目变更控制委员会(CCB)负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。负责审核项目的变更。CCB一般有项目经理、高层经理、实施负责人、测试负责人等组成。研发项目经理研发项目经理负责建立和领导整个研发项目团队。通常项目经理应在一个或多个功能领域有管理层和操作层经验，并有管理过开发项目的经历。项目经理管理项目计划、预算、人员配置、资源、进度，负责创建和维护项目综合文档，评估并管理项目风险，整合项目立项报告和可行性研究报告并提交给技术与产品管理委员会和项目管理委员会进行审批，以做出投资决策和评审。项目经理负责对团队和相关人员进行培训，持续监控和管理项目，在项目结束后组织经验教训总结。主要职责如下：从技术与产品管理委员会、项目管理委员会、高层经理处获得承诺，确保所需资源的及时到位，并创建项目所需环境。对项目的成本、进度、质量负责建立和领导整个项目团队，负责团队建设制定和管理跨部门的项目管理计划和项目进度计划，确保开发、测试、实施和支撑部门紧密相连做出并满足项目交付、预算和时间进度方面的承诺，进行范围、成本、风险、计划、进度、质量、人员、沟通的管理组织和参与各阶段的评审，确保各阶段评审材料和评审报告的有效性跟踪项目过程中的问题，并对无法解决的重大问题进行上报项目各阶段度量分析和经验总结系统分析/架构师系统分析/架构师由具有多年相关产品开发经验、具备多个领域的扎实专业知识和实践经验的人员担任。在一些项目中，可以由一个群体共同来承担系统分析/架构师的角色。系统分析/架构师在平台软件产品项目中承担确定总体规划、总体技术方案，主导需求分析、架构设计、接口设计以及关键技术等工作，并主导各个技术性评审。参与项目总体规划、确定项目总体技术方案提出项目技术备选方案和软件保护策略整合不同种类和来源的需求，确定产品需求对需求进行详细分析，完成《需求规格说明书》对需求进行分解和分配进行架构设计，完成《系统设计说明书》；在拥有开发接口的产品项目中，进行开发接口的设计，完成《接口设计说明书》进行并指导软件开发工程师进行模块设计，主导非正式的模块设计评审参与并主导各个技术评审，包括需求评审、技术方案评审、功能评审和发版评审监控和管理产品需求和设计方案，参与变更控制过程。软件开发工程师软件开发工程师主要负责与产品相关的软件模块设计、编码实现、单元测试等工作。由公司产品事业部或混合事业部具有软件开发能力的人员担任。参与分析技术备选方案参与详细需求分析、架构设计进行软件规模和工作量、难易度等的估算，辅助项目经理完成项目管理及进度计划进行模块设计编码实现代码审查单元测试修改缺陷参与各阶段技术评审，包括需求评审、总体方案评审、设计评审、功能评审、发版评审美术设计师美术设计师是研发项目中的软件界面美化设计和美术制作的人员。负责把美学及人性因素的设计事项考虑到产品的界面设计和图形中去。美术设计师在系统设计完成后配合软件工程师和测试工程师进行软件界面和产品资料的图形设计及实现等工作，并要负责保持整体产品形象的统一。收集项目图形设计的需求，沟通并了解客户对视觉及人机交互的需求并提供反馈和建议；负责提供图形设计方案以供项目组选择；制定产品图形设计的计划并与整个项目进度计划配合；进行图形设计以支持完整的产品形象；与软件工程师和测试工程师一起从易用性、人机交互、图形用户界面、产品资料等方面进行测试和设计测试工程师测试工程师主要负责研发项目的测试工作。测试工程师通常由具有软件测试相关知识和经验并有相当测试能力的人担任。测试工程师在研发项目中参与制定项目总体计划，负责制定测试相关的计划并加以执行，收集整理并提交项目中关于测试方面的度量数据，分析质量状况并提交测试报告。参与产品项目实施过程中的各项评审活动明确可测试性需求，明确产品项目对测试的要求协助制定项目管理、进度计划，负责制定测试部分的计划执行各类具体的测试工作（单元/集成/系统/性能以及各类专项测试）收集整理确认各类产品缺陷提交到缺陷管理系统（JIRA），跟踪产品缺陷处理状况整理分析并提交测试方面的度量数据（工作量/缺陷/进度等等）分析产品质量状况，提交测试报告协助各方执行测试相关的工作实施工程师负责或者参与研发产品对应的实施项目的整体实施，完成实施项目的需求调研分析，参与项目的各项评审工作，作为验证方对研发项目的目标达成情况进行验证。参与项目需求收集参与项目的各项评审负责将客户的需求及问题反馈给研发项目组系统程序的测试和客户的数据准备整理协调负责服务器的部署、调试进行项目的培训文档编写，为客户进行培训配置管理工程师配置管理工程师是负责研发项目配置管理相关工作的人员，一般由产品事业部或混合事业部的部门助理兼任。配置管理工程师主要负责配置库的建立和管理、版本控制、基线建立，配置项变更的执行以及产品发版工作。制定配置管理计划创建配置管理环境创建配置库建立并公布项目研发过程的各类基线配合项目组完成配置项变更控制工作产品发行管理，包括产品的构建和发放对相关人员进行相关配置管理培训品质保证工程师品质保证工程师是依据公司《研发项目管理流程》中既定的标准来检查项目过程和交付件是否符合规范，并辅助项目经理进行研发项目管理工作。QA由具有项目管理经验的人承担，致力于监控和提高所在项目的过程质量，以最终实现整个研发项目的质量目标。制定项目质量计划和质量目标；辅助项目经理进行项目立项、成本估算制定品质保证计划并实施监督项目各项评审监控质量活动，对项目的过程和交付件进行审计，提交质量报告，并在发现问题时和项目经理进行协商，必要时上报公司高层汇总并分析项目度量数据对项目组进行流程、质量体系方面的培训配合项目经理对本项目的流程进行适当的裁剪根据各研发项目的执行情况，对研发项目的流程进行优化和改进研发项目过程说明项目立项工作描述在开展项目立项调查、可行性研究并确认项目需要立项后，由相关负责人填写《项目立项申请》和《项目基本信息表》，并向公司技术与产品管理委员会、项目管理委员会、高层经理、品质保证工程师、配置管理工程师发送项目立项申请邮件。品质保证工程师对项目立项材料进行预审后，将预审结果反馈给立项负责人，待立项材料完善后发送公司技术与产品管理委员会、项目管理委员会、高层经理再次评审。相关领导评审后邮件回复立项意见，各方同意项目立项后才能召开立项启动会。立项负责人应在立项会前组织相关成员编写《项目立项启动会PPT》，并提前向与会人员发送会议通知。立项会结束后，由品质保证工程师建立成本对象并发送立项通知；配置管理工程师建立配置库；缺陷管理系统管理员在JIRA中建立项目相关信息。项目立项以品质保证工程师发布的立项通知为结束标志。详细立项流程及文档模板可参考《研发项目管理流程》\01项目立项中的《项目立项流程》及相关模板。相关工作产品《技术研究报告》（可选）《可研论证报告》（可选）《项目立项申请》（必须）《项目基本信息表》（必须）《项目立项申请邮件》（必须）《项目立项启动会PPT》（可选）《立项通知》（必须）文档编写指南《项目立项申请》至少需包括：项目名称、项目属性、项目分类、项目来源、应用客户、需求概述、市场前景、项目目标、项目意义、技术可行性分析等。项目目标中必须包含功能目标、性能目标和应用目标。对于没有应用目标的特殊产品开发型项目需要由技术与产品管理委员会和项目管理委员会审批通过后方可立项。项目属性主要分为产品开发型、普通、维护型、专题研究型。新产品研发和产品增强型开发项目填产品开发型项目，定制开发类项目填普通项目。项目类型主要分为新产品开发项目、产品增强型开发项目、普通项目、维护型项目、实施型项目、专题研究型项目。《项目基本信息表》将《项目立项申请》中内容对应填入《项目基本信息表》；“项目级别”，一般都选普通成熟度；“所属产品系”，公司目前产品系主要分为：报表、BI、GMS、GSI、GMC、DNA及其他。请根据项目实际情况填写，如出现两者、两者以上结合或不好定位的，可以选择其他；“项目负责人”指项目经理；“项目联络人”指项目的市场负责人，如没有，可以不填；“实施负责人”，项目对应的实施相关项目的负责人，结项时需要对项目进行验证的重要方，必须填写。与配置管理工程师协商，建立项目配置库，并将配置库地址写入《项目基本信息表》中，目前公司使用SVN配置管理工作，所有研发项目配置库需建立在SVN上。“项目主要里程碑”，填写项目的各阶段的完成时间，此处对里程碑的定义可以根据项目的实际情况进行修改。对于瀑布型项目至少应该包括，启动、需求分析、设计与开发、测试与发版、结项5个里程碑。对于迭代型项目，除项目启动、结项，每个迭代过程至少要包括需求、发版两个里程碑。对于升级类且按需求、功能点开发的项目定义项目里程碑时应提前与品质保证工程师进行沟通，确定项目里程碑定义方式。定制开发类项目应包含上线/试运行完成、项目终验时间。“项目主要提交物”，根据项目实际情况，对照研发项目管理流程中《项目标准化流程工作产品简表》进行裁剪，最终得到项目主要提交物清单。《项目立项申请邮件》根据研发项目管理流程中相应的模板来编写立项申请邮件，邮件至少需要发送给技术与产品管理委员会、项目管理委员会、高层经理、品质保证工程师、配置管理工程师。技术与产品管理委员会包含欧阳曜、孙建卫；项目管理委员会包含朱晓钧、曾祥逸；高层经理包含事业部总经理、项目立项负责人直接领导、测试中心负责人、信息资产管理部负责人。抄送品质保证、配置管理工程师及项目组其他成员。《项目立项申请》、《项目基本信息表》应作为附件随邮件一起发送。《项目立项启动会PPT》建议内容项：项目背景、项目目标、主要工作内容、项目主要里程碑时间、项目投入人员、项目风险以及启动会上需要明确的其他事项。《立项通知》由品质保证工程师统一发送，至少要包括项目编号、项目名称、项目分类、所属产品系、项目级别、立项申请人、立项部门、应用客户、项目负责人、项目组成员、项目的配置库物理位置、成本对象及项目立项材料。经验分享应在立项前确定未来系统将要采用的主要技术路线进行研究和初步验证，尽可能的降低产品采用不合适的技术路线而带来的风险，完成《技术研究报告》。为保证项目成功且有意义，建议立项前期多开展市场调查和可行性分析，并编写《可行性研究报告》。项目立项前，立项负责人应尽量熟悉研发项目管理流程，并尽早与品质保证工程师进行沟通立项事宜。项目立项启动会主要是确认团队的建立、让项目的相关方了解项目的背景和目标，并了解自己在项目中所负的职责，鼓舞团队士气。为减少资源浪费，启动会时间应避免太长。如项目工期紧张，可以裁剪立项启动会议，启动会相应的工作产品也可以进行裁剪。品质保证工程师预审立项材料的重点为：项目编号是否符合公司规范；立项材料是否完整；项目目标是否包含了功能目标、性能目标和应用目标，而且目标必须是量化和可验证的；项目里程碑是否定义清晰、主要提交物有误疏漏等。自检要素是否使用公司统一立项申请、基本信息表等模板是否具备项目的应用客户是否具有可验证、可量化的项目目标，包含功能、性能和应用目标是否已定义项目主要里程碑是否给高层经理、技术与产品管理委员会、项目管理委员会、QA发送立项申请邮件立项申请邮件是否通过高层经理、技术与产品管理委员会、项目管理委员会的审批项目计划与成本估算工作描述项目计划项目经理根据项目实际情况，按照项目管理计划模板，制定出项目管理计划。主要包括：项目目标、项目环境资源需求、项目过程定义、主要里程碑、项目人力资源计划、干系人介入计划、项目组培训计划、评审计划、度量数据收集与分析计划、可交付成果清单、方法与工具等。根据项目管理计划中的里程碑时间点制定项目详细进度计划。进度计划中应进行任务细分，将每个阶段的工作细化，并规定完成时间以及负责人。可使用Project或Xls编写进度计划。项目经理需要识别项目潜在风险，并使用《项目风险/重大跟踪表》记录和跟踪风险状态。配置管理员与项目变更控制委员会（CCB）确认项目的访问控制、基线和版本策略、分支版本策略、构建发布策略、变更控制策略等，建立配置管理计划。由品质保证工程师根据项目开发计划中的时间进度，制定针对其具体过程和产品的品质保证计划。计划中需要根据项目的特征确定检查哪些过程和工作成果，还需要计划检查的时间和人员。测试负责人根据项目管理计划和需求规格说明书对项目的测试进度、测试资源的投入、测试的整体思路和测试重点等进行计划，完成项目测试计划。项目管理计划及附属计划评审，使用评审报告记录和跟踪评审发现问题。如项目工期紧张，该项评审工作可采用邮件评审方式。需求范围明确后，需要对项目管理计划中的里程碑时间点、人员安排等做调整，各附属计划也进行相应调整。成本估算项目立项且需求基本确定后，由项目经理根据项目的实际情况，会同分管领导意见，提出项目奖金申请，申请过程通过编报《项目详细进度计划》、《项目成本估算、奖金核定表（研发）》、并将完成的相关材料通过邮件发送给运营监管中心项目监管部并抄送主管领导，进行审批。交付工作产品《项目管理计划》（必须）《项目详细进度计划》（必须）《风险/重大问题跟踪表》（必须）《配置管理计划》（必须）《品质保证计划及路线图》（必须）《测试计划》（必须）《项目成本估算、奖金核定表（研发）》（如申请奖励，必须提交）所有项目经理使用的文档模板存放在《研发项目管理流程》\00项目管理中的相关模板。配置管理模板存放在《研发项目管理流程》\00配置管理中；品质保证模板存放在《研发项目管理流程》\00品质保证中；测试相关模板存放在《研发项目管理流程》\03系统稳定。文档编写指南《项目管理计划》项目经理在制定项目管理计划时，至少要明确，项目目标与内容、项目所需资源及环境要求、项目过程定义、项目主要里程碑、人力资源计划、干系人介入计划、项目度量计划、项目评审计划、提交的工作产品清单、方法与工具等。项目过程定义主要是根据项目实际情况按照《项目标准化流程工作简表》对项目过程进行裁剪；项目干系人介入计划主要明确项目相关干系人何时、如何介入项目；项目度量计划和评审计划目前模板中已经有固定的数据了，项目经理可以根据项目情况进行裁剪。需求、开发规模的度量，计划、需求、功能评审都是必须要做的。《项目详细进度计划》根据项目管理计划使用xls或MSProject编写项目详细计划，项目详细计划中的工作包颗粒度要细，每个工作包需要投入的资源及资源投入百分比都需要填写。项目进度计划制定后，应定期进行跟踪、更新、细化，至少1-2周一次。《风险/重大问题跟踪表》制定项目计划的同时，对项目潜在风险进行识别，并记录在风险/重大问题跟踪表的上半部分，如果风险发生，转变为问题后，应该更新风险的状态，并将问题记录在风险/重大问题跟踪表的下半部分进行跟踪。对风险和问题的跟踪也应是定期的，至少1-2周一次。《配置管理计划》该计划主要由配置管理员完成，主要包含命名规范的定义、配置管理环境的说明、配置项识别、基线定义等，按照公司的统一模板来编写。《品质保证计划及路线图》由品质保证工程师完成，主要明确品质保证工程师在那些点介入项目，进行审计和检查。《测试计划》由测试负责人完成，对测试环境、测试目标、测试资源、测试里程碑进行定义。《项目成本估算、奖金核定表（研发）》如果项目申请研发奖励，在完成详细进度计划后，将每个阶段的资源、工作量等信息填入成本估算、奖金核定表中。经验分享项目管理计划及附属计划完成后需进行评审，评审可采取邮件或会议形式，为节约资源，一般都建议采取邮件评审方式。项目计划出现变更时，相关附属计划都需要随之进行变更。项目管理计划中，比较容易忽略的资源环境、干系人介入计划一定要按实际情况填写，评审计划、度量数据收集计划、项目使用的方法与工具应按照项目实际情况进行填写。提交的工作产品清单应尽量详细，命名也要规范，要与项目过程定义时确认需要提交的工作产品保持一致。制定项目计划阶段要重视风险识别，最好所有干系人都参与风险识别，可以参考类似项目，必要时向专家请教。需求、设计阶段要持续进行风险识别。可以从功能、质量、性能角度识别技术风险，从人力资源状况识别管理风险。《项目管理计划》评审通过后，有关人员即可撰写下属计划如《配置管理计划》、《质量保证计划》、《测试计划》等。制定项目计划时，选用合适的软件工具，尽量减少项目计划的工作量。方法与工具在进行进度和成本估算时可使用以下方法：专家判断法即请本领域的专家来判断执行项目各工作所需时间的长短。工作持续时间的估计常常是相当困难的，它要涉及到众多的因素，一般很难找到一个通用的计算方法，这个时候专家的历史经验和记录就显得尤为重要，尽管这种方法的结果也具有一定的不确定性和风险，但仍然不失为一种行之有效的方法。三时估算法一般地还可以通过估计完成工作的最乐观时间、最悲观时间及最可能时间按下式来估算工作持续时间：工作持续时间=（乐观的时间＋4×最有可能的时间＋最悲观的时间）/6经验估算法进行估计的人应有专门知识和丰富的经验，据此提出一个近似的数字。这种方法是一种最原始的方法，还称不上估算，只是一种近似的猜测。它仅适合于要求很快拿出一个大概数字的项目。自上而下估算法此方法一般要求有类似完成项目的经验的情况下使用。其主要内容是：收集上、中层管理人员的经验和判断，以及相关历史数据，然后上、中层管理人员估计整个项目的费用和各个分项目的费用，将此结果传送给下一层管理人员，责成其对组成项目和子项目的任务和子任务的费用进行估算，并继续向下传送其结果，直到项目组的最基层。这种过程和层级计划制定的过程类似，费用如同项目一样，按照WBS过程，从最高层到最底层进行逐层分解。这种方法的缺点是特别需要建立好上下管理层畅通的沟通渠道。因为上层管理人员根据经验得出的费用估算结果可能不能满足下层管理人员认为完成任务的需要。此时若不能适当地沟通，费用分配方案失去原有的作用而变成完成项目任务的阻碍，从而导致项目的失败。使用此方法的好处是中、上层管理人员能够比较准确地掌握项目整体费用分配，从而使项目的费用能够合理地控制在一个水平上，一定程度上避免了项目的费用风险。自下而上估算法该方法是指参与项目工作的每一机构和基层单位都估算自己的费用，将估算结果加起来的总和，得到该项目的整个估算费用。具体地可按照WBS体系，从下而上估算各个工作的费用，得到项目的直接费用估计，项目经理再在此基础上加上合理的间接费用，估算出项目的总费用。根据软件程序模块的标识和定义，估计代码的行数，可近似确定开发和测试软件的费用。这种方法的缺点在于要保证所有的工作和任务都被考虑到，而且对每个工作单元有过高估算的倾向，往往导致最后的费用估算无法接受。它的优点在于比起高层管理人员来，底层直接参与项目工作的人员更清楚项目工作所需资源的种类和数量，费用估算更为精确。而且费用估算出自他们自己的估计，可以避免以后费用预算过程中的一些冲突和不满。类比估算法即比照以前的经验，或比较以往类似项目的档案资料，根据以前的类似的实际项目的工作时间来推测估计当前项目各工作时间的。如果当前的项目与类比的项目很类似时，类比估计是一种最有效的方法。类比估算中的不确定性归根结底是由技术人员和费用估算人员所作的主观评价引起的。在多数情况下，可以进行实际的技术比较。问题是在技术差异的基础上建立费用关系，甚至当技术人员做出的所有决策都可以定量客观评价时，费用估算人员还需要确定有关技术发现的费用影响。在很多情况下，这些费用影响是非常主观的，因而，这种估算还是具有较大的不确定性。类比估算适用于项目早期，此时还没有系统的实际费用数据，也没有相似系统的大型数据库，只有此种方法的估算较为准确。自检要素相关文档的命名是否符合公司相关规范，是否以项目编号+项目名称+文档名称的方式命名项目管理计划里程碑时间点是否是具体的日期，并且有标志性提交物项目管理计划最终提交工作产品清单是否全部包含了项目裁剪后生命周期模型所要求的工作产品是否制定了项目组必须的培训计划（包含对内培训和对外培训）是否对项目的风险进行了识别，制定了风险管理措施是否识别了相关干系人，并对干系人介入的活动进行了定义项目进度计划中，工作任务的工期、工时、起止时间、资源是否否已明确定义项目的沟通计划是否清晰明确项目的评审、度量计划是否已制定项目管理计划及其附属计划是否经过正式评审（邮件或会议），并保留了评审记录进行成本估算时，项目的主要需求是否已确定需求分析工作描述如需要进行需求调研，项目组应制定需求调研计划，充分了解调研对象的基本情况、需求范围及规模等；明确需求分析过程的进度和人员等计划安排；确保项目组按可执行的需求分析计划进行需求调研，引导客户届时提供相关资源，最终形成《调研报告》。根据获取用户的需求信息，经过需求整理和分析后确定《需求说明书》定义产品功能、性能等需求，细化《需求说明书》，逐步形成《需求规格说明书》。对需求阶段工作产品进行评审，使用《评审报告》记录和跟踪评审发现问题。对各项需求的变更进行控制，防止需求发生混乱。交付工作产品《调研计划》（可选）《调研报告》（可选）《需求说明书》（可选）《需求规格说明书》（必须，或者用需求说明书+原型的方式代替）《相关评审报告》（必须）文档编写指南《调研计划》调研计划应尽量简单明了，主要明确调研对象及调研的日程安排，以及需要被调研部门配合的相关事项。《调研报告》调研报告中主要记录调研的结果（访谈的重点记录）、通过调研已确认的事项以及下一步需要明确的要点和遗留问题。《需求说明书》描述项目的总体需求、主要包含业务和非业务需求两大块。需求说明书中还需介绍项目的背景、目标等。《需求规格说明书》需求说明书的深化版，重点介绍每一个模块的功能要求、非功能要求。非功能要求也属于软件的重要组成部门，一定不能忽略。每个功能点都应该有唯一的编号。部分定制开发类项目的需求说明书+原型可以代替需求规格说明书，具体要与QA进行确认。《相关评审报告》主要记录项目每次需求评审的评审规模、工作量等，评审发现问题以及对问题解决情况的验证。经验分享如果需求调研任务较重且大的，建议调研前先做个调研提纲，避免调研时沟通不顺畅。做需求时应该从用户角度出发，直接与客户进行沟通，挖掘出客户内在的需求和问题，避免二次、三次传递的信息失真。比较理想的做法，需要将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求说明书－需求规格说明书－设计文档－代码－测试用例”之间的一致性，确保产品依据需求文档进行开发，使得需求能定期进行跟踪。对需求的跟踪还是比较重要的。每个产品，无论是新产品开发还增强型开发，都应该有一个项目总体的需求定义文档，而不单单是分散的、每个功能模块的需求文档。非业务需求，需要引起项目组的重视，每个需求文档汇总都应包括非业务需求。需求评审建议采用会议评审方式进行，如单个的评审报告不好对问题进行跟踪，建议可以使用jira或评审问题跟踪表代替评审报告跟踪和验证评审发现问题。为节省需求评审时间，建议将待评审的工作产品事先发给相关干系人进行预审。方法与工具最常用的需求捕获方法：用户访谈用户访谈是最基本的一种需求捕获手段。其形式包括结构化和非结构化两种，结构化是指事先准备好一系列问题，有针对地进行；非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。最有效的还是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。用户访谈前应准备问题并注意访谈时的技巧。用户调查用户访谈时最大的难处在于很多关键的人员时间有限，不容易安排过多的时间；而且客户面经常比较广，不可能一一访谈。因此，就需要借助“客户调查”，通过精心设计要问的问题，然后下发到相关人员的手里，让他们填写。现场观摩百闻不如一见，对于许多较为复杂的流程和系统而言，是比较难以用语言表发清楚的，而且这样做也会显得很低效。针对类似问题可以采用现场观摩的方法来获取需求。文档查阅对于一些数据流程比较复杂的，工作表单较多的项目，有时是难以通过说，或者通过观察来了解需求细节的。这时可能需要对历史存在的一些文档进行研究，需要从已有的数据文件、文档、表单中获得所需的信息。讨论会讨论会是我们常用的且成本较高的需求获取方法，但是也是十分有效的一种。它通过联合各个关键客户代表、分析人员、开发团队代表一起，通过有组织的会议来讨论需求。在整个需求过程，需求捕获、需求分析、需求规格化、需求验证四个阶段不是瀑布式的发展，而是应该采用迭代式的演化过程。在需求捕获时，不要期望一次就把需求收集完，而是应该捕获到一些信息后，进行相应的需求分析，并针对分析中发现的疑问和不足，带着问题再进行有针对性的需求捕获工作。自检要素需求是否存在二义性需求文档的上下文是否有矛盾需求是否完备需求是否都是必要的需求是否都是可实现的需求是否都是可验证的是否确定了需求的优先级是否定义了非业务需求是否对需求项进行唯一标识是否有《需求跟踪矩阵》是否所有的需求项都能与设计、测试用例等进行对应需求是否进行了评审，并对评审发现问题进行了修改和验证需求基线建立后,所有对《需求规格说明书》的变更是否进行跟踪，需求的变更是否走了正式的变更流程设计与开发工作描述分析与设计软件的体系结构，产生《概要技术方案说明书》。对系统数据进行设计，定义各数据实体的存储结构，确定结构、约束、索引、关系等，产生《数据库设计说明书》设计关键用户界面，设计软件模块的主要接口、类、数据结构、算法，产生《模块设计说明书》完成代码的编写，并通过单元测试，完成集成测试所需要的产品交付工作产品《技术研究报告》（可选）《概要技术方案说明书》（可选）《数据库设计说明书》（可选）《模块设计说明书》（可选）《相关评审报告》（必须）文档编写指南《技术研究报告》需要明确项目的技术路线，描述集中可能用到的技术路线，并加以对比分析，最终确认可行的技术路线。《概要技术方案说明书》确定项目的总体框架、关键技术。《数据库设计说明书》主要描述项目总体ER图及各模块的ER图，项目各表之前的关系及表结构。《模块设计说明书》主要对各模块的类图、调用关系、接口等进行设计。《相关评审报告》如项目有设计工作，设计工作产品应及时进行评审，每个项目都必须做功能评审。经验分享目前公司多数产品都是基于D&A平台进行开发的，一般都是做完需求规格后直接就进行开发，项目的设计工作可以根据项目具体情况进行裁剪，单元测试、功能评审一定要做。系统设计可分为两个部分进行，首先是总体设计，其任务是系统的总体结构进行设计，在此基础上进行第二阶段——详细设计，它的任务是在系统总体设计的指导下，对系统各组成部分进行细致、具体的物理设计，使系统总体设计阶段所作的各种决定具体化。对开发人员进行“代码审查、测试、改错”等方面的培训，提高他们的工作效率。开发小组根据产品的特征，可以适当地修改本规范的各种文档模板。代码设计的基本原则：具备唯一确定性；标准化与通用性；可扩充且易修改；短小精悍即选择最小值代码；具有规律性、便于编码和识别。方法与工具结构化设计方法结构化设计方法的基本思想是将系统设计成由多个相对独立，功能单一的模块组成的结构。由于模块之间相对独立，每个模块就可以单独地被理解、编写、测试和修改，从而防止错误在模块间蔓延，提高了系统的质量。它的特点主要有：相对独立，功能单一的模块结构；“块内联系大，块间联系小”的模块性能标准。目前公司的产品大多采用此方法。一个模块应具有以下四个要素：1）输入和输出数据的来源和去向；2）处理功能把输入数据转换为输出数据所做的工作；3）内部数据仅供该模块本身引用的数据；4）程序代码用来实现模块功能的程序；IPO图IPO图是对每个模块进行详细设计的工具。在系统的模块结构图形成过程中，产生大量模块，在详细设计时，开发者为每一个模块写一份说明。用来说明每个模块的输入、输出数据和数据加工。它的主体是算法说明部分，该部分可采用结构化语言，判定表，判定树等。程序流程图程序流程图是日常用的最多的一种图示。主要运用图示符号对某一模块或某一过程的操作进行详细的描述。问题分析图问题分析图是一种支持结构化程序设计的图形工具，可以用来取代前面所述的程序流程图。它有逻辑结构清晰、图形标准化等优点，更重要的是它引导设计人员使用结构化程序设计方法，从而提高了程序的质量。同时，通过比较确定的规则可以由问题分析图直接产生程序，为程序设计的自动化开辟了前景。它是一种由左往右展开的二维树型结构.PAD图的控制流程为自上而下,从左到右地执行.以上仅参考相关书籍对设计相关的方法和工具作简要介绍，如研发人员需要深入了解可查阅系统设计方法的相关书籍。自检要素文档每一部分的设计是否都可以追溯到需求分析文档或者其他技术文档概要设计说明书的设计目标描述是否明确清晰是否阐述了设计所依赖的运行环境，并与需求分析文档中规定的运行环境相一致是否描述了各类接口的功能、各接口与其他接口或模块之间的关系，接口的设计是否具有可测试性模块的划分是否合适（如：代码规模是否适中？是否便于协同开发？）、模块与模块之间是否具有一定的独立性（如：模块与模块之间应做到低耦合，模块设计应做到高内聚）是否所有的设计可以追踪到需求是否所有计划的模块都得到了详细描述是否每个单元都可以被测试、证明、分析或检查以确定是否符合需求设计文档是否通过评审，且对评审发现问题进行了跟踪和验证编码是否遵循了公司的相关编码规范是否进行了代码审查是否进行了单元测试并保持了相关测试记录是否严格对照需求、功能列表，对项目进行了详细的功能评审测试工作描述项目需求分析结束后，为执行测试工作做好准备，测试负责人应制定测试计划，主要明确测试的产品，测试的方式、规则和需要的环境，确保测试过程正确执行。测试负责人根据需求工作产品进行项目的测试设计，并对测试设计进行评审。对软件各模块进行单元测试，寻找并改正缺陷，保证产品质量。单元测试一般由开发人员来完成。在单元测试的基础上，将所有模块按照设计要求组装为子系统或系统进行的测试，也称之为集成测试，如接口测试。测试人员对最终软件系统进行全面测试，确保最终软件系统满足产品需求并遵循系统设计。最终形成系统测试报告。对项目的性能、兼容性进行测试，形成相关测试报告。交付工作产品《测试计划》（必须）《测试设计》（必须）《测试报告》（必须）《测试设计评审报告》（必须）《用户手册》（可选）《用户手册评审报告》（如有用户手册，必须评审）文档编写指南《测试计划》详见2.2.3《测试设计》设计每个功能的测试用例，主要通过测试用例来检查项目的质量。测试用例完成后也需要进行评审。《测试报告》对项目的测试结果进行分析、统计。主要统计缺陷分布情况，缺陷产品的人员进行分析，最终得出项目是否通过测试，是否符合起初订的项目目标。经验分享测试期间，开发人员向测试人员提供的测试版需要打上“测试版”标记。测试发现缺陷需要提交到缺陷管理工具中。测试应该更有层次化，先功能测试，然后是场景测试，最后做业务流程测试，要尽量使用或提炼用户的数据来做为测试的数据。方法与工具测试管理工具测试管理工具用于对测试进行管理。一般而言，测试管理工具对测试计划、测试用例、测试实施进行管理，并且，测试管理工具还包括对缺陷的跟踪管理。测试管理工具的代表有IBM公司Rational系列的TestManager、Compureware公司的TrackRecord等软件、MI公司的TestDirector、IBM公司的ClearQuest、开源的Bugzilla、Borland公司的Starteam、久其公司自己研制的RPIMS、澳大利亚Atlassian的JIRA。目前公司使用的是JIRA。黑盒测试工具黑盒测试工具主要用于功能的回归测试。代表有IBM公司Rational系列的TeamTest、Robot、RFT(RationalFunctionalTester)，Compuware公司的QARun，MI公司的WinRunner、QTP（QuickTestPro）。白盒测试工具一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级，根据测试工具原理的不同，又可以分为静态测试工具和动态测试工具。如JUnit性能测试工具主要用于预测系统性能的负载、压力测试工具。它通过模拟实际用户实施并发负载及实时性能监测的方式来确认、查找性能问题主要的代表工具有：Microsoft公司的WebApplicationStress；MI公司的LoadRunner；IBM公司的RationalPerformanceTester等。网络测试工具BandwidthMeter、NetMeter安全测试工具Appscan测试工具的介绍摘录于测试中心2010年新人培训ppt。自检要素是否在项目需求阶段制定了测试计划，测试计划是否通过评审，并对评审发现问题进行了跟踪和验证是否在项目设计与开发阶段制定了测试设计，测试设计是否通过评审，并对评审发现问题进行了跟踪和验证测试设计是否完整、覆盖所有功能点，测试步骤是否符合编写要求，测试数据是否符合设计要求测试接收程序前是否参与了项目功能评审，评审是否已通过测试各个子功能连起来，是否达到预期要求的父功能是否事先评估测试风险：系统设计，数据库设计，响应时间，因测试环境不足可能存在的测试缺陷是否验证接口的功能和性能，满足模块间大数据量的传输正常发版工作描述项目发版测试通过后，测试人员向配置管理员提供“测试报告”，说明哪个版本测试通过可进行发布，只能由配置管理员进行正式版的编译和发布，打上“正式版”标记，提供给用户使用。正式发布的版本，配置库中需要作版本标记，同时发布的版本应在指定的路径下进行程序备份。版本发布后，除在项目管理计划中计划的发版之外（主要指维护期），所有给客户应用的版本（包括临时版）均需由项目经理或配置管理员进行登记，以便于追溯。产品发版版本发布前必须先确定版本名称、版本范围、版本特性以及发版时间，并经过研发、测试、实施三方评审。需要明确需求冻结点，到达需求冻结点原则上不接受新需求。发版期间，需求变更需要经过产品线CCB成员批准。版本发布测试期间，缺陷从一个环节到下一个环节的处理时间不能超过3个工作日。版本发布基本标准：需求完成、没有未关闭严重缺陷、包含的子项目全部测试通过并结项、遗留缺陷不超过发现缺陷的50%并经过确认。版本发布需要由配置管理员给出明确的版本发布清单（保证版本的完整性），并提供版本更新说明。正式版的程序应放在公司ad01上的产品库中。交付工作产品《发版计划》（可选）《发版申请》（可选）《发版说明及邮件》（必须）《相关评审报告》（可选）文档编写指南经验分享产品的发布可以作为一个项目单独立项完成，也可以不立项作为一个发版测试任务完成；发版测试过程，必须包含实际项目的业务测试，未经项目确认，不算测试通过，不能发布正式版本；自检要素版本发布前是否经过了详细的测试，并获得测试负责人的认可所有缺陷是否都已处理，只剩遗留或者关闭状态缺陷，遗留缺陷是否经过讨论与程序一同发布的文档是否完成并经过评审，如用户手册、版本更新说明等是否达到原定版本发布目标，是否有重要需求遗漏，重要修改未测试发布的版本所有相关工件是否已更新到配置库中，包括源代码、各类文档资料发版程序版本是否备份至产品库，存放路径是否正确发版时是否通过正式邮件通知发版程序版本的访问路径邮件收件人是否包含实施人员、市场人员、测试人员、品质保证人员以及公司高层经理系统上线/试运行工作描述项目经理制定《项目上线及试运行方案》，并安排人员进行系统试运行跟踪。项目经理与用户共同确定数据备份方案，做好备份检查工作。解决日常操作问题以及系统功能调整。在试运行过程中如果发现问题，由跟踪人员登记《用户需求及BUG提交表》(问题列表)，并反馈给研发等相关人员进行修改。在试运行结束之前的2周开始《试运行总结报告》，并提交用户。交付工作产品《项目上线及试运行方案》（可选）《用户权限表》（可选）《试运行总结报告》（必须）《用户需求及BUG提交表》（必须，需要提交在jira中）文档编写指南《项目上线及试运行方案》《项目上线及试运行方案》是系统试运行实施工作的细化方案，将环境准备、系统安装、系统初始化等工作分别进行更细致的划分，确定每项具体工作的完成时间点及完成内容。《项目上线及试运行方案》的主要内容要按照实施的顺序编写，如果实施过程中不需要某些步骤，可以略去不写。《用户权限表》《用户权限表》分为VA用户权限设置、CI用户权限设置两部分。VA权限设置需要记录每个用户对各个功能及基础数据的权限，如果系统需要设置基础数据、工作流权限，则需要单独列示。CI权限设置需要将功能资源、数据资源、单位资源、用户资源分别列示出来。《试运行总结报告》详情请参见《项目试运行报告》的范例。《用户需求及BUG提交表》（问题列表）《用户需求及BUG提交表》需要按照模版规范登记在试运行阶段系统出现的问题，及用户提出的新需求。问题需及时提交到JIRA中。经验分享目前多数项目的试运行时间都会因客户对软件、业务不熟悉而被迫延长，导致项目工期被拖延，因此在制定项目计划时，应充分考虑此因素，并在项目启动时就对系统试运行时间达成一致。建议在培训之前或培训期间，事先搭建好服务器，进行试运行。最晚在培训结束后，告知客户，系统进入试运行阶段。自检要素试运行方案是否已获得客户的认可用户权限是否进行了定义试运行用到的程序是否已经过严格的测试是否对客户试运行时用到的数据进行了保密是否了解客户部署环境，并填写部署信息表试运行发现的问题和新需求是否都录入到公司JIRA中项目验收工作描述根据合同规定，在约定的系统终验时间前3周开始进行准备。在需要的时候，同时与用户协商终验事项。项目经理至少在终验到达前1周向用户提交《终验申请》，《终验申请》必须通知事业部领导（或分子公司经理）、项目监管部、市场人员，如果需要相关人员参加，应在此时通知相关方。项目经理准备验收材料，组织召开终验会议，参加人员：客户方代表、事业部领导（或分子公司经理）、项目组成员、市场人员及其他相关人员，由项目经理对项目进行总结；会后提交用户签字的《系统终验报告》。若合同中标明的终验时间在结项后半年以上，应和客户签署《项目实施完成确认单》，明确结项进入免费维护期的时间，待达到系统终验时间时，再签署《系统终验报告》；项目终验后，项目经理应立即准备项目结项材料，项目监管部评审材料后，发出项目结项通知，并将项目的电子文档、纸质文档归档并封存；交付工作产品《终验申请》（必须）《项目实施完成确认单》或《终验报告》（必须）文档编写指南《终验申请》终验申请上的时间点应该和项目整体情况表上的时间一致；如果用户有单独要求，终验申请文档内容以用户要求为准；根据项目情况判断，如果时间点要和合同一致，则注意改为合同时间，不过要和用户沟通确认。《项目实施完成确认单》实施结束确认单作用是向用户说明，系统实施工作已经结束，可以进入系统免费维护阶段；根据合同内容上的签订单位，调整实施结束确认单的单位为久其股份；对于甲方承诺以及乙方建议的细节内容，需要根据项目情况做出调整时，需和部门经理确认；在和用户提交终验申请时，需要提前和市场人员进行沟通，保证其了解文档内容，并达成一致意见。经验分享《项目终验申请书》与《项目终验报告》是两个概念，前者用于项目经理向客户方提出项目终验申请，无须客户签字确认，而后者是用于确认项目终验的书面证明，应保存纸质文档。如果项目经理有把握让客户签署《项目终验报告》，则无须提供《项目终验申请书》。《实施完成确认单》一般用于系统交付使用或免费服务期满X年后支付剩余合同价款时，签订此《实施完成确认单》，可以与客户明确何时进行项目终验，并收回款项。因此项目经理在签署此单后，也应在到达约定的时间点组织客户终验，签订《项目终验报告》。自检要素是否与客户提前进行了相关事项的沟通？（验收方式、提交文档、领导汇报等）相关验收材料中是否包含了客户的信息，如客户名称、LOGO等如召开验收会议，会议议程是否与客户进行沟通并确认过如召开验收会议，现场演示环境是否已搭建好召开验收会时用的会议签到表是否已准备好项目经理是否就验收事宜提前和高层经理、商务人员、分管副总进行了沟通，如需要高管出席验收会应尽量提前通知相关方。对于客户提出的下一步工作计划及新问题是否已记录并执行和解决是否已取得验收报告并提交至项目监管部项目结项工作描述项目测试、发版完成且已实现项目既定的目标后，由项目经理组织项目组成员对项目配置库进行检查，将未入库的工作产品及时入库。项目经理撰写项目总结报告，配置管理员梳理项目提交的工作产品清单。项目组认为项目可以结项后，由项目经理向技术与产品管理委员会、项目管理委员会、项目高层经理、测试负责人、实施负责人发送项目结项申请邮件，项目总结报告和工作产品清单应随邮件一起发送。在收到结项申请邮件后，项目高层经理、测试负责人、实施负责人三方对项目进行验证并回复结项意见。主要评价项目目标的达成情况，是否达到结项要求。信息资产管理部和项目监管部对项目过程检查发现问题的修改情况进行验证，做结项前的工作产品审计和过程审计，对于存在项目管理、配置管理问题的项目应及时纠正，待缺陷修改完成后才能允许项目结项。项目经理组织召开结项会。各方验证通过且提交的工作产品确认无误后，由品质保证工程师发送结项通知，项目正式结项。项目结项后，需要收集客户或内部满意度调查结果，由品质保证工程师组织配置管理、测试相关负责人对项目执行情况进行评价。如申请研发奖励的项目，需要核对项目实际成本，确认项目奖励的实际总盘，填写《项目奖金确认表（研发）》并报相关领导进行审批。交付工作产品《结项申请邮件》（必须）《项目总结报告》（必须）《提交的工作产品清单》（必须）《项目结项总结会PPT》（可选）《项目结项通知》（必须）《项目评价表（研发）》（必须）《项目奖金确认表（研发）》（如申请奖励，必须）文档编写指南《结项申请邮件》邮件需要发给技术与产品管理委员会、项目管理委员会、项目高层经理、测试负责人、实施负责人。邮件申请中必须指定各方的验证代表及验证截止时间。《项目总结报告》主要对项目的投入情况、过程数据（变更、缺陷、工作量等）进行统计。项目经理应该评价一下做整个项目下来的不可量化成果，收集项目经验与教训总结以供其他项目参考。《提交的工作产品清单》分类型统计工作产品，需求定义文档放一类、项目管理文档放一类，规模、数量及存放位置也应该尽可能的详细。《项目结项总结会PPT》主要提取项目总结报告中的数据，对项目进行回顾。如项目时间不够，总结会可以不开。《项目结项通知》由品质保证工程师发送，结项通知应对项目目标达成情况，过程检查发现问题、遗留问题的情况进行描述。结项通知应发送给项目各相关关系人，通知附件中要包含项目总结报告和提交的工作产品清单。《项目评价表（研发）》从项目管理、产品质量、流程执行情况等方面对项目进行评价，该评价由品质保证工程师组织配置管理员、测试负责人、实施一同完成。《项目奖金确认表（研发）》从VA中统计出项目的实际成本，按照奖励管理办法计算出实际奖励总盘并填写在》项目奖金确认表（研发）》中。经验分享项目总结报告是收集项目度量数据的重要来源，在项目开发过程中就应当把各里程碑的工作量、评审情况等数据统计工作放在平时来做，这样不至于结项时写结项报告项目总结会上可以让项目组成员每人都总结一下参与项目过程的收获及建议，这样开结项会才有意义，而不仅仅是为了应付，走个过场，那样很浪费时间和资源。项目结项时，建议可以做一个系统演示，对项目的功能、性能做一个验证。自检要素测试和发版工作是否已完成是否已完成项目总结报告和提交工作产品清单总结报告是否具备人力资源投入情况、总体工作量等进行分析、总结总结报告是否对项目实施进度进行了总结，计划与实际的偏差以及原因分析、预防措施和解决办法总结报告是否对项目的需求变更、计划变更、人员变动等变更情况进行统计和总结总结报告是否对项目风险和重大问题进行分析、总结项目提交工作产品清单是否全部覆盖项目所产生的所有工作成果（即识别出的全部配置项）是否给技术与产品管理委员会、项目管理委员会、高层经理、实施负责人、测试负责人、配置管理员、QA发送了结项申请邮件项目直接领导、测试、实施人员是否对项目进行了验证QA是否对最终工作产品进行了检查配置管理员是否完成基线建立相关文档、并在配置库中建立项目结项/发版基线配置管理员是否按照项目经理或其他人员要求对配置库进行封库操作或做权限调整研发项目例行工作项目管理项目周例会项目周例会主要明确个人一周的工作目标和内容，为下一周的工作提前做好计划。及时解决一周工作中遇到的疑难问题，并将解决方法有效记录。周例会的关键点：1、对于自己在工作中的难点和问题进行汇报，听取项目组成员给予的指导和意见；2、并将自己本周工作中的成功与失败的经验，进行分享和警戒；3、执行会议的决议，并及时反馈执行的情况；4、明确自己下周的工作目标和计划。项目周报正常情况下，项目经理应在每周一下班前边写项目周报并发送邮件（节假日另行通知），周报最晚提交时间为周二上午9:30。如遇突发时间不能提交的，可在周二早晨9：30之前向品质保证工程师说明迟交原因。品质保证工程师整理周报及项目存在问题，并完成《研发项目问题、状态及周报统计简报》，发送给所有研发项目干系人。周报发送对象：“收件人”为：项目组成员、（客户代表，如需要）；“抄送人”为：项目监管小组、公司内部项目干系人，主要是：和本项目直接相关的研发人员以及其主管、实施及销售人员。项目某一里程碑结束后，应在周报的里程碑图中进行更新。周报中的工作量统计、详细工作事项可能的精确，品质保证工程师会定期抽查周报中工作项统计与VA中的日志是否能对应。如遇需项目领导关注问题和遗留问题应该在周报中进行说明。项目组成员应在周五下班或周一上班前将自己本周的工作形成邮件并统计工作量发送给项目经理。项目里程碑报告项目每个里程碑的工作完成后，应编写里程碑报告并在对应的里程碑完成后的一周内提交入库。里程碑报告中需要对整个里程碑的进度进行分析，如进度出现偏差应该分析引起偏差的原因以及纠正偏差的措施。对里程碑的工作量、工作规模，缺陷（含评审发现问题）进行统计。对本里程碑的人员投入、需求变更、风险跟踪、重大问题、培训等活动的情况进行总结。里程碑报告由项目经理完成，项目组成员负责给项目经理提供素材。如果里程碑报告写好了，将来结项的时候写项目总结就比较容易。里程碑报告不需要发送给相关干系人，项目经理完成后经品质保证工程师确认后入库即可。项目评审项目立项材料、项目管理计划及附属计划、需求、系统设计、测试设计、代码、功能、用户手册都需要进行评审。为节省时间，项目立项材料、项目管理计划及附属计划、用户手册可以采用邮件评审，其余评审建议采用会议方式进行。为避免评审会时间过长，且效果不好，建议项目经理将待评审的工作产品提前发给大家预审，尽量要求每个评审、与会人员对工作产品提出1-2个问题，评审会上大家可以针对问题进行讨论，节约评审时间，提高评审效率。需评审的规模、预计花费的时间也应该有个估算，避免开会开一整天，开完还没有结论的评审会。各工作产品负责人带评审结束后应立即统计评审的规模、消耗的时间，评审发现的问题等，这些都可以记录在评审报告、评审问题跟踪表和评审数据汇总表中。评审发现的问题如果解决了，应及时在评审报告或评审问题跟踪表中更新问题的状态，并由第三方对问题的解决情况进行验证。为使研发、测试、实施三方目标达成一致，测试和实施人员应尽量多参与项目的评审。比较会忽略的计划、用户手册的评审在今后的项目中一定要关注。风险管理项目经理负责项目总体的风险管理，项目组成员协助项目经理进行风险的处理。项目经理根据“项目风险/重大问题跟踪表”，定期（例如每周一次）识别本项目的风险。项目经理组织相关方评估每个风险的严重性、可能性和风险系数，并按照风险系数从高到低的顺序排列风险。对于风险系数较高的，项目经理应当给出风险减缓措施，并指定责任人。风险系数越高，越先处理。项目经理跟踪风险减缓过程，直到风险已经解决为止。如果风险的性质发生变化，应当及时更新风险减缓措施。如风险已发生，需要将风险转变为问题，并将其放入问题跟踪表的部分进行持续跟踪。配置管理项目及文档命名规范基于产品的研发项目编号规则项目编号规则：产品系代号_项目代号_可选段（客户简称/版本号/期数等）编号说明：产品系代号是产品系列的英文简写，如BI、GMS、GSI、GMC、DNA等。项目代号是项目名称的英文简写，如果已经有约定俗成的简写（如汉语拼音简写），可以使用约定俗成的简写。可选段中的客户简称，是开发或实施的项目所服务的国家部委或省或具体单位的简称。部分客户简称可参见《通用编码中英文缩写简表.xls》中的“国家部委”、“省自治区直辖市”页签。可选段中的期数，对于分期的项目也按版本号处理。如果项目版本升级或分期进行，在项目编号后用半角减号“-”分隔符分隔，后加版本号或期数，格式为：项目编号-版本号/期数，可以忽略。举例如下：CI_Dashboard2.0-CI数字仪表盘2.0CI_GOV_YKT_1.2-政府直补一卡（折）通管理信息系统1.2bPro_Studio1.2-久其商业智能平台建模平台1.2定制研发项目编号规则项目编号规则：JQ_项目代号_可选段（客户简称/版本号/期数等）编号说明：定制开发项目无对应产品系列，因此以JQ开始，其他字段含义参见3.2的说明。举例如下：JQ_SDYSZX-山东省国家税务局预算执行监控系统JQ_DZSW_GS-广晟公司电子商务平台JQ_KSLQS_ZGDX-中国电信跨实例取数文档命名规范所有文档都应该以“项目编号+项目名称+文档产品的命名原则，文档必须符合文档规范，需使用公司最新发布的文档模板（若客户方有特殊要求，需提前说明。新建或修改基线配置项的文档内容时，必须同时填写相应的变更履历。CI_CQDJ3.0产权登记3.0需求规格说明书JQ_VA61.1久其VA6管理系统项目管理计划CDSP定制软件开发平台需求评审报告（20101218）项目变更为了确保重大变更经过评审、确认，保证变更所引起的工作产品能够得到及时、一致的更新并及时入库，保证所有事件性变更有记录，我们需要加强对项目变更的控制。对于严重影响项目进度和成本的需求、设计、人员、计划等的变更必须经过申请、评审、审批方可执行，不允许擅自修改。变更控制的要点变更影响分析：对每个变更所造成的影响（如：技术影响、成本影响、进度影响等）需进行分析。变更审批：对于任何已纳入基线的工作产品的更改必须经过审批、并保留审批记录。变更执行与入库：得到审批的变更及其影响必须得以实施并得到进一步审批方可入库。如何进行变更申请变更当项目计划、需求发生重大变更时，项目经理或其他相关负责人向项目变更控制委员会（CCB）提交变更申请（填写《配置项变更控制报告》的“基本信息”和“申请变更”章节的相关内容），需要重点说明“变更内容”和“变更原因”及其“该配置项变更对项目造成的影响”。典型的变更请求有：项目目标发生改变、增加或减少重大功能需求、技术攻关出现难题、资源调整、进度调整等。填写完《配置项变更控制报告》中的基本信息、申请变更章节后，需要给CCB成员发送变更申请邮件并抄送品质保证工程师。邮件模板在《研发项目管理流程》中有，可以参考一下。评审变更申请CCB评审该申请，重点分析此变更对项目造成的影响并回复变更意见。安排变更任务CCB同意变更后，项目经理指定变更执行人，对需变更的配置项（受其影响的变更项）执行变更任务，项目经理需要和变更执行人就变更内容达成共识。执行变更任务配置管理员从基线库中检出需要修改的配置项，发给相关的变更执行人；变更执行人根据项目经理安排的任务，修改配置项；要求文档类的变更必须详细填写变更记录或者变更履历（在每个文档的目录之前），详细到变更内容、变更人、变更时间和变更版本。同时配置管理工具检入时也需要详细输入变更注释；CCB监督变更任务的执行，如检查变更内容是否正确、是否按时完成工作等；对于事件性基线变更没有检入检出操作，但需要变更执行人在相关文档中详细填写变更记录，以备后期的变更检查。注意事项:修改处于“草稿”状态的配置项不算是“变更”，当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据申请执行变更的规则执行。发生变更时，项目经理必须及时通知配置管理员，延缓时间不能超过3天。配置管理员要跟踪变更执行进度，及时接收、入库变更产生或修改的配置项。对配置项的变更操作应以评审定稿为准、不仅仅以基线为准。即：配置项评审定稿入库后、未建立基线前如对该配置项进行修改，需按照变更流程执行。过程裁剪指南及模板链接在项目管理计划中对项目过程进行定义时，可以根据下面的表格对项目过程进行裁剪，可直接将下表复制入项目管理计划的过程定义相关章节对项目过程进行裁剪。表格中各项工作的提交物那为“可选”的是表示该工作产品可以进行裁剪。提交物为“必须“的是表示不能裁剪的。说明：下表中上线及试运行阶段仅适用于定制开发类项目，产品研发型项目可以直接裁剪该阶段。产品包装化阶段仅适用于产品研发型项目，定制开发类项目可以直接裁剪该阶段。阶段活动工作产品是否提交工作产品模板存放地址立项阶段可行性研究可研论证报告可选jqcm/rules/项目管理/01研发项目管理流程\01项目立项\02模板建立项目愿景项目愿景说明书可选jqcm/rules/项目管理/01研发项目管理流程\01项目立项\02模板项目立项申请及准备项目立项申请必须jqcm/rules/项目管理/01研发项目管理流程\01项目立项\02模板项目基本信息表必须jqcm/rules/项目管理/01研发项目管理流程\01项目立项\02模板项目立项申请邮件必须jqcm/rules/项目管理/01研发项目管理流程\01项目立项\02模板召开项目启动会（可选）项目启动会PPT可选jqcm/rules/项目管理/01研发项目管理流程\01项目立项\02模板项目启动会议邀请邮件可选可参考outlook会议邀请立项收尾项目立项通知邮件必须由品质保证工程师统一发送项目管理项目管理计划必须jqcm/rules/项目管理/01研发项目管理流程\00项目管理\02模板项目进度计划必须jqcm/rules/项目管理/01研发项目管理流程\00项目管理\02模板识别项目风险及问题风险/重大问题跟踪表必须jqcm/rules/项目管理/01研发项目管理流程\00项目管理\02模板建立产品配置管理架构配置管理计划必须jqcm/rules/项目管理/01研发项目管理流程\00项目管理\02模板制订品质保证计划品质保证计划必须jqcm/rules/项目管理/01研发项目管理流程\00项目管理\02模板项目管理计划及附属计划评审评审报告/评审会议纪要必须jqcm/rules/项目管理/01研发项目管理流程\00项目管理\02模板需求定义阶段概要技术方案设计概要技术方案说明书可选jqcm/rules/项目管理/01研发项目管理流程\03设计开发\02模板开发产品业务需求模型需求说明书/产品原型/故事板可选jqcm/rules/项目管理/01研发项目管理流程\02需求定义\02模板产品需求模型评审评审报告/评审会议纪要承前必须jqcm/rules/项目管理/01研发项目管理流程\00项目管理\02模板产品技术验证技术研究报告可选jqcm/rules/项目管理/01研发项目管理流程\03设计开发\02模板开发需求规格说明书需求规格说明书（定制开发类项目可使用需求说明书+原型代替需求规格）必须jqcm/rules/项目管理/01研发项目管理流程\02需求定义\02模板需求规格说明书评审评审报告/评审会议纪要必须jqcm/rules/项目管理/01研发项目管理流程\00项目管理\02模板制定测试计划测试计划必须jqcm/rules/项目管理/01研发项目管理流程\04系统稳定\02模板测试计划评审评审报告/评审会议