项目开发管理规范

项目开发管理规范11.28(总22
页)
--本页仅作为文档封面，使用时请直接删除即可--
--内页可以根据需求调整合适字体及大小--
1.目的
描述公司产品研发的管理流程与工作内容。

通过本规范的实施，确保研发方向正确，阶段目标清晰，项目过程可控，从而确保按照预期计划完成产品研发和上市销售。

2.研发管理整体流程2.1.研发管理流程图
况组织相关成员组成）。

达的任务。

项目成员是指在项目中执行具体任务的人员，例如分析员、设计师、程序员、测试员等。

项目经理下达任务给项目成员，项目成员们向项目经理汇报各自的工作。

项目成员并非固定在一个项目中工作，他们可能会为多个项目提供服务。

如果组织内没有相对独立的测试组，那么测试人员的直接领导就是项目经理。

如果机构内有测试组，那么测试人员的直接领导是测试经理，当测试人员接受了某个项目的测试任务，那么他要向测试经理或项目经理汇报工作。

2.3.研发项目的角色
在研发项目中，每个人可以拥有多个角色，视项目情况而定。

角色职责如错误!未找到引用源。

所示。

后续章节的流程规范将详述“角色在什么时候，以什么步骤做什么事情，产生什么样的成果”。

表 2-1研发项目中的角色职责
2.4.流程中的过程域、主要活动和主要工作成果
表 2-2研发项目流程中的过程域、主要活动和主要工作成果
3.立项管理
立项管理的流程如错误!未找到引用源。

所示，关键活动是“合同项目立项申请”、“自主产品立项申请”、“立项评审”和“项目筹备”。

该流程的主要工作成果和
图 3-1立项管理的流程
表 3-1立项管理主要工作成果和责任人
3.1.自主产品立项申请
项目经理撰写《立项申请书》，将《立项申请书》、《产品需求说明书》、《产品调研报告》、《立项可行性分析报告》提交给项目管理委员会负责人审阅。

如发现文件内容不合流程要求或者质量不合格，则退还给申请人重新改进，直到文件合格为止。

3.2.合同项目立项申请
一般情况下，开发方和客户签订正式合同之后，开发方再在公司内部立项。

也有一些例外，由于某些原因导致合同尚未签订，但是客户有一些口头承诺，要求开发方先做项目，后签订合同。

如果开发方不同意，则可能失去机会。

如果开发方同意先开发，但是存在比较大的风险，要在立项评审会议做出决定。

项目销售人员撰写《立项申请书》，将《立项申请书》、《项目需求说明书》以及相关合同文本提交给项目管理委员会负责人审阅，如果发现文件内容不合流程要求或者质量不合格，则退还给申请人重新改进，直到文件合格为止。

3.3.立项评审
第1步评审准备
项目管理委员会负责人把《立项申请书》等相关文件递交给各个评审委员。

项目管理委员会负责人确定立项评审会议的时间、地点、设备和参加会议的人员名单。

第2步举行评审会议
立项申请人陈述《立项申请书》和相关文件的主要内容。

评审委员提出疑问，立项申请人解答。

双方应当对有争议的内容得出处理意见。

项目管理委员会负责人汇总所有评审委员的评审意见，填写《立项评审报告》，以“少数服从多数”决定是否立项，以及给出项目执行建议。

第3步项目终审
项目管理委员会负责人将《立项评审报告》递交给总经理。

总经理在《立项评审报告》中签注最终审批意见。

如果同意立项，那么进入下一步“项目筹备”。

否则，项目中断。

3.4.项目筹备
第1步再次明确项目经理责任
再次明确项目经理权责，项目经理对立项之后的项目进度和质量负最大责任。

第2步确立项目组，项目成员
第3步项目启动会
项目经理召开项目启动会，让所有项目成员了解项目的目标和工作内容。

4.项目计划
项目计划的流程如错误!未找到引用源。

错误!未找到引用源。

所示，关键活动是“项目估计”、“制定项目计划”、“审批项目计划”和“项目计划变更控制”。

该流程的主要工作成果和责任人见错误!未找到引用源。

项目估计制定
项目
计划
按计划执行
研发与管理工作
审批项目计划
项目计划变更控制
图 4-1项目计划的流程
关键活动主要工作成果主要责任人项目估计项目估计表项目经理
制定项目计划项目计划项目经理
审批项目计划按评审意见修正后的项目计划相关决策领导，项目经理
项目计划变更控制项目计划变更控制报告
新的项目计划
相关决策领导，项目经理表 4-1项目计划主要工作成果和责任人
4.1.项目估计
项目经理组织项目成员进行项目功能、模块分解，从而估计产品的规模，估计工作量；估计成本和预算。

产品规模的主要度量单位有：
代码行
类（对象）个数
功能电路块数，机械结构难易程度，机械结构图纸数量
电路原理复杂程度
文档页数
成本包括人力成本、软硬件资源成本等；预算除上述成本外还包括项目
知识产权管理、项目验收等费用。

第1步确定目标与范围
首先确定本项目的目标与工作范围。

目标必须是“可实现的”和“可验证的”。

工作范围包括“做什么”和“不做什么”。

第2步制定人力资源计划
项目经理制定本项目的角色职责表，并为项目成员分配角色（一个人可以兼多个角色）。

第3步制定软硬件资源计划
分析项目开发、测试以及用户使用产品所需的软硬件资源，制定软硬件资源计划。

资源级别（分为“关键”、“普通”两种）
详细配置
获取方式（如“已经存在”、“可以借用”或“需要购买”等）与获取时间
用途（如“谁”在“什么”时候使用）
第4步制定财务计划
制定财务计划。

开支类别
主要用途
金额
时间
第5步分配任务并制定进度表
项目经理结合项目评估结果，以及项目成员数量分解任务并制定详细进度表，建议采用Microsoft Project制作Gantt 图，附在《项目计划》中。

第1步申请审批
项目经理将《项目计划》提交给决策领导，最终提交总经理审批。

补充说明：如果是合同项目，可能还要请客户审批，视具体情况而定。

第2步审批与修正
决策领导根据“项目计划检查表”认真审批《项目计划》。

如果《项目计划》中进度周期不能满足市场要求时，决策领导和项目经
理共同商讨解决办法。

第3步批准生效
决策领导签字批准后，该《项目计划》正式生效，此后项目经理不能随意修改《项目计划》。

4.4.项目计划变更控制
第1步变更申请
项目经理向决策领导申请变更《项目计划》。

变更申请书中应当说明：变更原因
变更的内容
此变更对项目造成的影响
补充说明：如果是合同项目，可能还要向客户提出变更申请，视具体情况而定。

第2步审批变更申请
机构领导审批变更申请：
如果不同意变更，则退回变更请求，项目按照原计划执行。

如果同意变更，转向第3步。

第3步修改项目计划
项目经理修改原《项目计划》，产生新的《项目计划》。

第4步审批新的项目计划
决策领导审批新的《项目计划》
补充说明：如果项目计划对整个项目完成周期有影响时，该项目计划需提交总经理审批。

5.项目监控
项目监控流程如错误!未找到引用源。

所示，关键活动是“项目计划跟踪”、“偏差控制”和“项目进展总结”。

该流程的主要工作成果和责任人见错误!未找到引用源。

表 5-1项目控制主要工作成果和责任人
5.1.项目计划跟踪
项目经理周期性地（如每周一次）跟踪每个重要的任务，项目费用使用情况，软硬件资源配置情况，形成记录。

5.2.偏差控制
第1步找出显着偏差
项目经理根据任务跟踪、费用跟踪、资源跟踪所产生的数据，对比“项目实际进展”与“项目计划”，找出显着偏差项（例如进度偏差大于20％）。

第2步分析原因
项目经理分析产生显着偏差的原因，以便采取正确的纠正措施。

第3步给出纠正偏差的措施
项目经理给出纠正显着偏差的措施：
如果偏差主要是由于《项目计划》不合理导致的，则要变更项目计
划。

如果《项目计划》本身是合理的，偏差主要是由于项目成员在执行
时产生的，那么要求项目成员弥补偏差，避免原本合理的计划在实
施时落空。

第4步跟踪纠正偏差的过程
项目经理跟踪纠正偏差的过程，直到该偏差被消除为止。

5.3.项目进展总结
项目经理周期性地（或者在里程碑处）召开项目进展会议，探讨问题，总结工作，让所有项目成员清楚地了解项目的实际进展情况。

项目经理撰写《项目进展报告》，并及时通报给所有项目成员和决策领导。

6.需求开发与管理
项目需求开发和管理的流程如错误!未找到引用源。

错误!未找到引用源。

所示，关键活动是“需求开发”、“需求确认”、“需求跟踪”和“需求变更”。

该流程的主要工作成果和责任人见错误!未找到引用源。

需求开发需求确认需求跟踪需求变更需求管理
图 6-1需求开发与管理的流程
关键活动主要工作成果主要责任人需求开发产品需求说明书需求分析员
需求确认需求评审项目经理/上级决策领导/项目管理委员会
需求变更需求变更申请需求分析员
表 6-1需求开发与管理主要工作成果和责任人
6.1.需求开发
第1步细化并分析用户需求
需求分析员对《用户需求说明书》进行细化，以便产生详细的产品需
求。

需求分析员对比较复杂的用户需求进行建模分析，以帮助开发人员更好
地理解需求。

第2步撰写产品需求规格说明书
需求分析员按照指定的文档模板撰写《产品需求规格说明书》。

如果待开发的产品分为软件和硬件两部分的话，则应当分别撰写《软件需求规格说明书》和《硬件需求规格说明书》。

《产品需求规格说明书》的主要内容包括：
产品介绍；
描述用户群体的特征；
定义产品的范围；
阐述产品应当遵循的标准或规范；
定义产品中的角色；
定义产品的功能性需求；
定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求6.2.需求确认
第1步非正式需求评审
项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。

第2步正式需求评审
项目经理上报上级领导进行审批，必要情况下邀请项目管理委员会组织相关成员和用户（合同项目）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。

第3步获取需求承诺
当需求文档通过正式的评审之后，项目经理和决策领导、客户（合同项目）对需求文档作书面承诺。

6.3.需求变更
第1步需求变更申请
需求变更申请人撰写“需求变更申请书”，递交给项目经理或客户方负责
人。

“需求变更申请书”必须阐述：（1）变更原因；（2）变更的内容；
（3）此变更对项目造成的影响。

第2步审批需求变更申请
项目经理和决策领导、客户（合同项目）共同审批“需求变更申请书”：
如果任何一方不同意变更，则退回变更请求，项目按照“原需求文档”执
行。

如果双方都同意变更，转向第3步。

第3步更改需求文档
需求分析员根据第1步和第2步更改“原需求文档”，产生新的需求文档。

第4步重新进行需求确认
重新进行需求评审，参见需求确认规程中的第2步。

重新获取书面的需求承诺，参见需求确认规程中的第3步。

补充说明：1、如果项目经理直接承担需求分析员工作，需求评审由上级领导审批，必要情况下邀请项目管理委员会组织相关成员和用户（合同项目）一起评审，视具体情况而定。

7.系统设计
系统设计是指设计硬件结构（包括电路、机械等），软件架构、用户界面、数据库、模块等，从而在需求与代码、电路、机械等之间建立桥梁，指导开发人员去实现能满足用户需求的产品。

需求开发
软件架构设计
硬件结构设计
用户界面设计
数据库设计
软件模块设计
硬件/结构模块设计
工艺设计
实现与测试
概要设计阶段详细设计阶段
关键活动主要工作成果主要责任人软件架构设计概要设计说明书，详细设计说明书系统设计师
硬件结构设计硬件、结构设计方案系统设计师
用户界面设计用户界面设计说明书开发人员
数据库设计数据库设计说明书开发人员
软件模块设计软件模块设计说明书开发人员
硬件模块设计硬件模块设计说明书开发人员
工艺设计工艺文件工艺技术员
表 7-1
7.1.软件/硬件系统设计
第1步设计准备
阅读需求文档，分解系统设计任务。

准备相关的设计工具和资料。

第2步确定影响系统设计的约束因素
需求约束。

系统设计人员从需求文档中提取需求约束，例如：
本系统应当遵循的标准或规范
软件、硬件环境（包括运行环境和开发环境）的约束
接口/协议的约束
用户界面的约束
产品外观、内部布局、零部件加工工艺、装配工艺等的约束
软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易
用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。

硬件质量的约束，如可靠性、稳定性、精确度、功耗、安全性、可
扩展性、抗震性等等
隐含约束。

有一些假设或依赖并没有在需求文档中明确指出，但可
能会对系统设计产生影响，设计人员应当尽可能地在此处说明。

例
如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统
的软件硬件的假设或依赖等。

第3步系统分解与设计
将系统分解为若干子系统，确定每个子系统的功能以及子系统之间
的关系。

将子系统分解为若干模块，确定每个模块的功能以及模块之间的关
系。

确定系统开发、测试、运行所需的软硬件环境。

第4步撰写系统结构设计文档
系统设计人员根据指定的模板撰写《概要设计说明书》、《详细设计说明书》《硬件结构设计方案》，主要内容包括：
系统概述
影响设计的约束因素
设计策略
系统总体结构
子系统的结构与模块功能
开发、测试、运行所需的软硬件环境
第5步系统设计评审
系统设计评审主要评审要素包括：
合适性。

考察该结构是否适合于产品需求，是否可在预定计划内实
现。

系统的综合能力，例如可扩展性，可管理性（可维护性），可复用
性，安全性等等，视产品特征而定。

补充说明：1、如果项目经理直接承担系统设计工作，评审由上级领导审批，必要情况下邀请项目管理委员会组织相关成员和用户（合同项目）一起评审，视具体情况而定。

7.2.用户界面设计
第1步设计准备
界面设计人员阅读需求文档和系统设计文档，明确界面设计任务。

界面设计人员与用户交流，了解用户的工作习惯和他们对界面的看法。

界面设计人员准备相关的设计工具和资料，收集或创作基本的界面资源
如图像、图标以及通用的组件。

界面设计人员确定本软件的用户界面设计规则，主要包括：
软件主界面（如主窗口、主页面）的设计规则；
软件子界面（如子窗口、子页面）的设计规则；
标准控件的使用规则；
第2步用户界面设计
用户界面设计一般要经历“原型创作—>原型评估－>细化”等步骤，通常迭代进行。

1)原型创作
界面设计人员创作界面原型：
先徒手画，或者用Visio 等工具绘制界面的视图；
再用软件开发工具实现可以运行的原型。

2)原型评估
界面设计人员可提议项目经理进行评估界面的原型，汇集意见，及时改进。

3)细化
第3步撰写用户界面设计文档
用户界面定型之后，界面设计人员根据指定的模板撰写《用户界面设计
报告》，主要内容包括：
应当遵循的界面设计规范；
界面的关系图和工作流程图；
主界面的视图、功能说明、操作方式；
子界面的视图、功能说明、操作方式；
第4步用户界面设计评审
界面设计人员可提议项目经理对定型后的界面组织进行正式技术评审，
尽最大努力使界面变得更加美观、易用。

用户界面的主要评审要素包括：
简洁易用
一致性
美观
动态反馈
功能屏蔽和出错处理
用户控制
兼容性和可移植性
适应性（针对各种用户）
第5步界面设计及测试
按照评审结果开始进行界面设计，并自行测试，记录测试结果，不断
完善改进，直至缺陷、故障消除。

7.3.数据库设计
第1步设计准备
数据库设计人员阅读需求文档和系统设计文档，明确数据库设计任务。

数据库设计人员准备相关的设计工具和资料。

数据库设计人员确定本软件的数据库设计规则，主要包括：
数据库命名规则
逻辑设计规则
物理设计规则
安全性设计规则
优化规则
数据库管理与维护规则
第2步数据库设计
数据库设计一般要经历“逻辑设计—>物理设计－>安全性设计－>优化”等步骤，通常要迭代进行。

1)逻辑设计
数据库设计人员根据需求文档，创建与数据库相关的那部分实体关系图（ERD）。

如果采用面向对象方法（OOAD），这里实体相当于类
（class）。

2)物理设计
设计表结构。

一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。

逻辑设计中的实体大部分可以转换成物理设计中的表，但是它们并不一定是一一对应的。

3)安全性设计
提高软件系统的安全性应当从“管理”和“设计”两方面着手。

这里仅考虑数据库的安全性设计。

用户只能用帐号登陆到应用软件，通过应用软件访问数据库，而没
有其它途径可以操作数据库。

对用户帐号的密码进行加密处理，确保在任何地方都不会出现密码
的明文。

确定每个角色对数据库表的操作权限，如创建、检索、更新、删除
等。

每个角色拥有刚好能够完成任务的权限，不多也不少。

在应用
时再为用户分配角色，则每个用户的权限等于他所兼角色的权限之
和。

第3步撰写数据库设计文档
数据库设计人员根据指定的模板撰写《数据库设计说明书》，主要内容
包括：
数据库环境说明
数据库的命名规则
逻辑设计
物理设计
安全性设计
优化
数据库管理与维护说明
第4步数据库设计评审
数据库设计人员可提议项目经理组织进行数据库技术评审。

数据库的主要评审要素包括：
正确性、完整性、一致性
安全性
第5步数据库实现及测试
按照评审结果开始进行数据库代码编写，并自行测试，记录测试结果，不断完善改进，直至缺陷、故障消除。

7.4.软件模块设计
第1步设计准备
模块设计人员阅读需求文档和系统设计文档，明确模块设计任务。

模块设计人员准备相关的设计工具和资料。

模块设计人员确定本软件的编程规范，确保模块设计文档的风格与代码
的风格保持一致。

第2步模块设计
模块设计一般要经历“接口与属性设计—>数据结构与算法设计”等步骤，并且通常需要反复迭代。

1)接口与属性设计
模块设计人员设计每个模块的主要接口与属性。

如果采用面向对象方法，相当于设计类的函数和成员变量。

2)数据结构与算法设计
模块设计人员设计每个模块的数据结构与算法。

第3步撰写模块设计文档
模块设计人员根据指定的模板撰写《模块设计报告》，主要内容包括：模块汇总
每个模块的主要接口与属性
每个模块的数据结构与算法（如果存在的话）
第4步模块设计评审
模块设计人员可提议项目经理组织进行对模块设计文档技术评审。

第5步模块实现
按照评审结果开始进行模块代码编写，并自行测试，记录测试结果，不断完善改进，直至缺陷、故障消除。

7.5.硬件模块设计
第1步设计准备
模块设计人员阅读需求文档和系统设计文档，明确模块设计任务。

模块设计人员准备相关的设计工具和资料。

模块设计人员确定设计规范，确保各单元设计文档、设计图的风格保持
一致。

第2步模块设计
模块设计一般要经历“接口与连接件选型—>模块内部部件选型—>模块内部资源分配”等步骤。

第3步撰写设计文档
模块设计人员根据指定的模板撰写《模块设计报告》，主要内容包括：模块汇总
每个模块的主要接口与连接件选型
每个模块内部部件选型和资源分配
第4步模块设计评审
模块设计人员可提议项目经理组织进行对模块设计文档技术评审。

第5步模块实现及测试
按照评审结果开始进行各模块单元电路及结构设计，并测试验证，记录测试结果，不断完善改进，直至缺陷、故障消除。

7.6.工艺设计
根据硬件模块的设计，外观要求等，初步进行工艺设计，并在实现中完善。

8.系统测试
系统测试的目的是对最终系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。

系统测试的流程如错误!未找到引用源。

所示，关键活动是“制定系统测试计划”、“设计测试用例”、“执行系统测试”和“缺陷管理与改错”。

该流程的主要工作成果和责任人见错误!未找到引用源。

制定测试计划
设计测试用例
执行系统测试
缺陷管理与改错
迭代
审批
审批
图 8-1系统测试的流程
关键活动
主要工作成果
主要责任人
制定测试计划 系统测试计划 测试员 设计测试用例 系统测试用例 测试员 执行系统测试 系统测试报告 测试员 缺陷管理与改错
缺陷管理报告
测试员
表 8-1系统测试的主要工作成果和责任人
8.1.1. 制定系统测试计划
测试人员测试前起草《系统测试计划》。

该计划主要包括：
测试范围（内容） 测试方法
测试环境与辅助工具 测试完成准则 人员与任务表
补充说明：项目经理审批《系统测试计划》。

8.1.2. 设计系统测试用例
测试人员依据《系统测试计划》和指定的模板，设计（撰写）《系统测试用例》。

补充说明：项目经理审批《系统测试用例》，必要条件下可对该测试用例组织技术评审。

待开发人员交付后开始执行系统测试。

8.1.3.执行系统测试
测试人员依据《系统测试计划》和《系统测试用例》执行系统测试。

将测试结果记录在《系统测试报告》中，用“缺陷管理工具”来管理所发
现的缺陷，并及时通报给开发人员。

8.1.4.缺陷管理与改错
在整个系统测试过程中，任何人发现软件系统中的缺陷时都及时报给项
目经理及开发人员。

开发人员及时处理，直至所有缺陷全部消除。

9.配置管理
配置管理即通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。

配置管理是对工作成果的一种有效保护。

该活动贯穿于整个设计开发过程。

凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：（1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。

（2）项目管理过程域产生的文档。

每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。

所有配置项都被保存在配置库里，确保不会混淆、丢失。

配置项及其历史记录反映了产品的演化过程。