项目开发管理规范

项目开发管理规范11.28(总22

页)

--本页仅作为文档封面，使用时请直接删除即可-- --内页可以根据需求调整合适字体及大小--

1. 目的

描述公司产品研发的管理流程与工作内容。通过本规范的实施，确保研发方向正确，阶段目标清晰，项目过程可控，从而确保按照预期计划完成产品研发和上市销售。

2

2. 研发管理整体流程

2.1. 研发管理流程图

立项阶段营销过程自主产品构思调研合同项目销售TR设计开发阶段验收阶段产品体验与宣传销售结项维护阶段客户服务与产品验收TR人员角色管理结项管理项目管理立项管理项目规划进度监控｜技术评审｜风险跟踪｜变更控制｜成本管理需求评审需求开发与管理需求细化和演进 产品构思调研设计评审 项目验收交付、验收、试用维护系统设计项目研发模块开发与集成增量开发模式测试与缺陷跟踪小批量试产、软件稳定性运行支持过程配置管理｜文档管理｜采购与外包｜会议评审等人员绩效评估｜知识产权管理等 图2-1研发管理流程模型 2.2. 研发项目的组织结构 研发项目的组织结构模型如错误!未找到引用源。所示，共分为4个层次，决策领导（总经理、研发中心总监/产品中心总监）；项目经理、项目成员；营销生产质检运营等相关支持部门；项目管理委员会（由项目管理部根据项目情况组织相关成员组成）。

3

决策领导项目管理委员会项目组内部结构项目经理营销生产质检运营部门协作项目成员：需求分析师、系统设计师、程序员、测试员等 图 2-2 研发项目组织结构 决策领导包括总经理、研究院主任、研发中心总监/产品中心总监、技术负责人。总经理拥有最终决策权，决策领导逐级下达任务给项目经理，项目经理向直接决策领导汇报工作，再分级上报。 项目经理是研发项目的管理者，他带领所有项目成员共同完成决策领导下达的任务。

项目成员是指在项目中执行具体任务的人员，例如分析员、设计师、程序员、测试员等。项目经理下达任务给项目成员，项目成员们向项目经理汇报各自的工作。

项目成员并非固定在一个项目中工作，他们可能会为多个项目提供服务。 如果组织内没有相对的测试组，那么测试人员的直接领导就是项目经理。如果机构内有测试组，那么测试人员的直接领导是测试经理，当测试人员接受了某个项目的测试任务，那么他要向测试经理或项目经理汇报工作。

4

2.3. 研发项目的角色

在研发项目中，每个人可以拥有多个角色，视项目情况而定。角色职责如错误!未找到引用源。 所示。后续章节的流程规范将详述“角色在什么时候，以什么步骤做什么事情，产生什么样的成果”。

角色 决策领导 （项目决策者） 该角色在研发流程中的主要职责 （1）参与立项评审，为项目提供人力资源。 （2）及时了解所有项目的人力资源、进度、质量情况，协商处理问题。 （3）在项目结束时，对项目进行综合评估。 项目管理委员会一般由部门经理以上职位的人员以及项目综合管理员组成，主要职责是参与“合同项目”和“自主产品”的立项评审、项目开发各阶段评审、项目验收评审等。 （1）跟踪每个项目的开发过程，重点检查需求文档、设计文档、变更记录、用户文档是否符合规范。 （2）参加需求评审和设计评审。 （3）如果发现项目问题，先和责任人沟通，如果难以解决，则由上级领导协调。 （4）技术部项目综合管理员由技术中心助理负责 项目经理是项目主要责任人，主要职责是带领团队在预定的时间和成本之内，开发并交付质量合格的项目（产品）。项目经理对本项目的需求、进度、质量、交付负主要责任。 （1）负责本项目的任务进度管理、变更管理，以及可能存在的跨项目、跨部门协调。 （2）如果本项目没有专门的需求分析员、系统设计师，那么项目经理承担需求分析、系统架构设计工作。如果本项目缺乏足够的开发工程师，那么项目经理应当承担某些模块开发。（3）在项目结束时，总结知识财富和经验教训，完善文档。对项目成员的业绩进行评估。 （1）负责本项目需求调研、分析、定义，撰写详细的需求文档。 （2）将需求准确地传达给相关人员（如开发、测试、客户等），随着项目进展，及时完善需求文档。 （1）根据需求开展总体设计，包括硬件结构设计、软件构架设计、数据库设计等。 （2）撰写设计文档，并将设计成果准确地传达给其他项目成员。 （1）按照项目经理分配的任务执行开发设计，包括美工、界面设计，并清楚地交付给测试人员（准备测试）。如果测试人员报告缺陷，应及时消除缺陷。对自己工作成果的质量负最大责任。 （2）参与项目讨论，主动发现项目中的问题、消除问题。 （3）对自己的源代码进行配置管理，及时完善文档。 （4）如果本项目没有专门的工艺技术员，那么开发工程师承担工艺设计工作。 （1）了解项目需求，了解项目开发进度，和项目经理商议测试计划，设计测试用例。 （2）根据计划执行测试，找出尽可能多的缺陷。使用缺陷跟踪工具，及时将测试信息反馈给相关责任人。 （3）向项目经理汇报项目内的质量问题，向决策领导汇报共性的质量问题。 （1）对产品生产工艺进行分析、设计，编制工艺卡片 （2）设计必不可少的工装模具 （3）参加需求评审和设计评审。 （4）发现问题，及时与责任人沟通，如果难以解决，则由上级领导协调。 项目管理委员会 项目综合管理员 项目经理 （项目管理者） 需求分析员 系统设计师 开发工程师 测试工程师 工艺技术员 5

配置管理员 （1）为所有项目创建配置库，为用户分配合适的权限，负责信息安全和备份。 （2）指导开发人员使用配置管理软件和研发管理软件。 （3）配置管理工作由项目经理承担。 （1）负责安排售前、生产、售后跟踪产品开发过程，及时提出需求建议，及时试用产品，纠正偏差，给出优化建议，使产品更加适合目标客户的需求。 （3）协助营销人员宣传、销售该产品，及时获取客户的反馈，改进产品。 采购负责样机制作过程中的外购、外协联络；制造部门负责产品小批量试制；质检部门负责试制过程中产品的功能、性能验证；运营部门负责反馈现场运行情况。 表 2-1研发项目中的角色职责

技术支持主管 制造、采购、质检、运营相关支持部门 2.4. 流程中的过程域、主要活动和主要工作成果

过程域 产品构思和调研 产品体验和宣传销售 合同项目销售 客户服务和合同验收 立项管理 结项管理 项目规划与监控 风险跟踪和变更控制 需求开发与管理 主要活动 产品构思，产品调研 产品体验，宣传销售 接触客户，可行性分析，投标答辩，签订合同 产品维护，评审成果，控制变更，项目验收 立项申请，立项评审，项目筹备 结项申请，结项评估，关闭项目 制定项目计划，人员管理，任务进度管理，项目成本管理，设备管理 识别风险，处理风险，关闭风险 变更申请，变更审批，执行 需求调研，需求分析，需求定义，评审确认，细化跟踪，变更控制 系统方案设计、硬件结构设计，软件架构设计，用户界面设计，数据库设计，模块设计 模块需求细化，模块设计，模块实现和集成，工艺设计，试制样品 准备测试，执行测试，消除缺陷 系统集成，选择设备供应商，设备采购和验收，设备安装调试 选择物料供应商，物料采购，试制产品 撰写文档，软件部署，客户培训，客户试用（周期允许交付质检验证测试，否则交付客户现场试运行） 主要工作成果 产品需求说明书，产品调研报告，技术可行性分析报告 产品宣传材料 投标书，合同，项目需求说明书 项目验收报告 立项申请书，立项评审报告 结项申请书，结项评估报告 项目计划，日志，周报 风险跟踪表，变更控制报告 产品（项目）需求说明书 系统集成方案，系统概要设计说明书，系统详细设计说明书。 模块需求说明书，模块设计说明书，软件代码，硬件及机械结构设计图，产品图纸、工艺卡片、工装设计图等 测试用例，测试报告 设备详细清单 小批量试制报告，改进记录 营销 过程 项目管理过程 系统设计 模块开发与集成 项目开发过程 测试与改错 软硬件系统集成 小批量试制及改进 部署试用 部署说明书，安装和使用手册 6

软件维护 配置管理 质量管理 支持 过程 采购及外包 客户服务管理 接受维护请求，分析维护请求， 执行维护（包括工厂运行测试、现场试运行测试） 软件代码管理，硬件电路图管理，文档管理 技术评审，测试管理，发布管理，质量保证，缺陷（问题）跟踪 产品试制过程中的外购外协 客户信息管理，客户问题受理（包括工厂安装调试运行问题、现场测试运行问题） 维护记录 软件代码库，硬件电路图库，文档库 技术评审报告，发布记录，缺陷报告 外购外协申请单、供方合同评审、合格供方清单。 客户信息库，客户问题记录，安装调试运行记录 表 2-2研发项目流程中的过程域、主要活动和主要工作成果

3. 立项管理

立项管理的流程如错误!未找到引用源。所示，关键活动是“合同项目立项申请”、“自主产品立项申请”、“立项评审”和“项目筹备”。该流程的主要工作成果和责任人见错误!未找到引用源。。 研究院主任/产品总监自主产品立项申请，任命项目经理合同项目立项申请项目销售人员立项评审委员会项目筹备1.明确项目经理责决策领导任2.分配资源 3.制定项目计划4.项目启动会项目经理立项评审 注：在立项申请阶段，决策领导根据项目特征和开发部门的情况，即任命合适的项目经理，共同进行产品需求调研、可行性分析等，共同筹备立项申请。 图 3-1立项管理的流程

关键活动 自主产品立项申请 主要工作成果 立项申请书， 产品需求说明书，产品调研报告，技术可行性分析报告 立项申请书， 项目需求说明书，相关合同文本 主要责任人 相关决策领导、项目经理 合同项目立项申请 合同项目的销售专员 7

立项评审 项目筹备 立项评审报告 项目总体计划 项目管理委员会 相关决策领导，项目经理 表 3-1立项管理主要工作成果和责任人

3.1. 自主产品立项申请

项目经理撰写《立项申请书》，将《立项申请书》、《产品需求说明书》、《产品调研报告》、《立项可行性分析报告》提交给项目管理委员会负责人审阅。如发现文件内容不合流程要求或者质量不合格，则退还给申请人重新改进，直到文件合格为止。

3.2. 合同项目立项申请

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

也有一些例外，由于某些原因导致合同尚未签订，但是客户有一些口头承诺，要求开发方先做项目，后签订合同。如果开发方不同意，则可能失去机会。如果开发方同意先开发，但是存在比较大的风险，要在立项评审会议做出决定。

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

3.3. 立项评审

第1步 评审准备

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

8

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

第2步 举行评审会议

立项申请人陈述《立项申请书》和相关文件的主要内容。评审委员提出疑问，立项申请人解答。双方应当对有争议的内容得出处理意见。

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

第3步 项目终审

项目管理委员会负责人将《立项评审报告》递交给总经理。总经理在《立项评审报告》中签注最终审批意见。

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

3.4. 项目筹备

第1步 再次明确项目经理责任

再次明确项目经理权责，项目经理对立项之后的项目进度和质量负最大责任。

第2步 确立项目组，项目成员 第3步 项目启动会

项目经理召开项目启动会，让所有项目成员了解项目的目标和工作内容。

4. 项目计划

项目计划的流程如错误!未找到引用源。 错误!未找到引用源。所示，关键活动是“项目估计”、“制定项目计划”、“审批项目计划”和“项目计划变更控制”。该流程的主要工作成果和责任人见错误!未找到引用源。。

9

项目计划变更控制项目估计制定项目计划审批项目计划按计划执行研发与管理工作 图 4-1项目计划的流程 关键活动 项目估计 项目估计表 主要工作成果 项目经理 主要责任人 制定项目计划 审批项目计划 项目计划变更控制 项目计划 按评审意见修正后的项目计划 项目计划变更控制报告 新的项目计划 项目经理 相关决策领导，项目经理 相关决策领导，项目经理 表 4-1项目计划主要工作成果和责任人

4.1. 项目估计

项目经理组织项目成员进行项目功能、模块分解，从而估计产品的规

模，估计工作量；估计成本和预算。

产品规模的主要度量单位有： 代码行

类（对象）个数

功能电路块数，机械结构难易程度，机械结构图纸数量 电路原理复杂程度 文档页数

成本包括人力成本、软硬件资源成本等；预算除上述成本外还包括项目知识产权管理、项目验收等费用。

10

4.2. 制定项目计划

第1步 确定目标与范围

首先确定本项目的目标与工作范围。目标必须是“可实现的”和“可验证的”。工作范围包括“做什么”和“不做什么”。

第2步 制定人力资源计划

项目经理制定本项目的角色职责表，并为项目成员分配角色（一个人可以兼多个角色）。

第3步 制定软硬件资源计划

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

资源级别（分为“关键”、“普通”两种） 详细配置

获取方式（如“已经存在”、“可以借用”或“需要购买”等）与获取时间 用途（如“谁”在“什么”时候使用）

第4步 制定财务计划

制定财务计划。

开支类别 主要用途 金额 时间

第5步 分配任务并制定进度表

项目经理结合项目评估结果，以及项目成员数量分解任务并制定详细进度表，建议采用Microsoft Project制作Gantt 图，附在《项目计划》中。

11

4.3. 审批项目计划

第1步 申请审批

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

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

第2步 审批与修正

决策领导根据“项目计划检查表”认真审批《项目计划》。

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

第3步 批准生效

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

4.4. 项目计划变更控制

第1步 变更申请

项目经理向决策领导申请变更《项目计划》。变更申请书中应当说明：

变更原因 变更的内容

此变更对项目造成的影响

补充说明：如果是合同项目，可能还要向客户提出变更申请，视具体情况而定。

第2步 审批变更申请

机构领导审批变更申请：

如果不同意变更，则退回变更请求，项目按照原计划执行。 如果同意变更，转向 第3步。

12

第3步 修改项目计划

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

第4步 审批新的项目计划

决策领导审批新的《项目计划》

补充说明：如果项目计划对整个项目完成周期有影响时，该项目计划需提交总经理审批。

5. 项目监控

项目监控流程如错误!未找到引用源。所示，关键活动是“项目计划跟踪”、“偏差控制”和“项目进展总结”。该流程的主要工作成果和责任人见错误!未找到引用源。。

周期性地开展项目计划跟踪偏差控制项目进展总结 图 5-1项目监控的流程 关键活动 项目计划跟踪 项目进展报告 项目经理 主要工作成果 主要责任人 偏差控制 项目进展总结 表 5-1项目控制主要工作成果和责任人

5.1. 项目计划跟踪

项目经理周期性地（如每周一次）跟踪每个重要的任务，项目费用使用情况，软硬件资源配置情况，形成记录。

13

5.2. 偏差控制

第1步 找出显着偏差

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

第2步 分析原因

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

第3步 给出纠正偏差的措施

项目经理给出纠正显着偏差的措施：

如果偏差主要是由于《项目计划》不合理导致的，则要变更项目计划。

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

第4步 跟踪纠正偏差的过程

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

5.3. 项目进展总结

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

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

14

6. 需求开发与管理

项目需求开发和管理的流程如错误!未找到引用源。错误!未找到引用源。所示，关键活动是“需求开发”、“需求确认”、“需求跟踪”和“需求变更”。该流程的主要工作成果和责任人见错误!未找到引用源。。

需求管理需求确认需求开发需求跟踪需求变更图 6-1需求开发与管理的流程 关键活动 需求开发 需求确认 需求变更 主要工作成果 产品需求说明书 需求评审 需求变更申请 需求分析员 项目经理/上级决策领导/项目管理委员会 需求分析员 主要责任人 表 6-1需求开发与管理主要工作成果和责任人

6.1. 需求开发

第1步 细化并分析用户需求

需求分析员对《用户需求说明书》进行细化，以便产生详细的产品需求。

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

第2步 撰写产品需求规格说明书

15

需求分析员按照指定的文档模板撰写《产品需求规格说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当分别撰写《软件需求规格说明书》和《硬件需求规格说明书》。

《产品需求规格说明书》的主要内容包括：

产品介绍；

描述用户群体的特征； 定义产品的范围；

阐述产品应当遵循的标准或规范； 定义产品中的角色； 定义产品的功能性需求；

定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求

6.2. 需求确认

第1步 非正式需求评审

项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。

第2步 正式需求评审

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

第3步 获取需求承诺

当需求文档通过正式的评审之后，项目经理和决策领导、客户（合同项

目）对需求文档作书面承诺。

16

6.3. 需求变更

第1步 需求变更申请

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

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

第2步 审批需求变更申请

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

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

第3步 更改需求文档

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

第4步 重新进行需求确认

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

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

17

7. 系统设计

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

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

7.1. 软件/硬件系统设计

第1步 设计准备

阅读需求文档，分解系统设计任务。

18

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

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

需求约束。系统设计人员从需求文档中提取需求约束，例如：

本系统应当遵循的标准或规范

软件、硬件环境（包括运行环境和开发环境）的约束 接口/协议的约束 用户界面的约束

产品外观、内部布局、零部件加工工艺、装配工艺等的约束 软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。 硬件质量的约束，如可靠性、稳定性、精确度、功耗、安全性、可扩展性、抗震性等等

隐含约束。有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，设计人员应当尽可能地在此处说明。例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。

第3步 系统分解与设计

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

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

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

第4步 撰写系统结构设计文档

19

系统设计人员根据指定的模板撰写《概要设计说明书》、《详细设计说明书》《硬件结构设计方案》，主要内容包括：

系统概述

影响设计的约束因素 设计策略 系统总体结构

子系统的结构与模块功能

开发、测试、运行所需的软硬件环境

第5步 系统设计评审

系统设计评审主要评审要素包括：

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

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

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

7.2. 用户界面设计

第1步 设计准备

界面设计人员阅读需求文档和系统设计文档，明确界面设计任务。 界面设计人员与用户交流，了解用户的工作习惯和他们对界面的看法。 界面设计人员准备相关的设计工具和资料，收集或创作基本的界面资源如图像、图标以及通用的组件。

20

界面设计人员确定本软件的用户界面设计规则，主要包括：

软件主界面（如主窗口、主页面）的设计规则； 软件子界面（如子窗口、子页面）的设计规则； 标准控件的使用规则；

第2步 用户界面设计

用户界面设计一般要经历“原型创作—>原型评估－>细化”等步骤，通常迭代进行。

1) 原型创作

界面设计人员创作界面原型：

先徒手画，或者用Visio 等工具绘制界面的视图； 再用软件开发工具实现可以运行的原型。 2) 原型评估

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

第3步 撰写用户界面设计文档

用户界面定型之后，界面设计人员根据指定的模板撰写《用户界面设计报告》，主要内容包括： 应当遵循的界面设计规范； 界面的关系图和工作流程图；

主界面的视图、功能说明、操作方式； 子界面的视图、功能说明、操作方式；

第4步 用户界面设计评审

21

界面设计人员可提议项目经理对定型后的界面组织进行正式技术评审，尽最大努力使界面变得更加美观、易用。 用户界面的主要评审要素包括：

简洁易用 一致性 美观 动态反馈

功能屏蔽和出错处理 用户控制 兼容性和可移植性 适应性（针对各种用户）

第5步 界面设计及测试

按照评审结果开始进行界面设计，并自行测试，记录测试结果，不断完善改进，直至缺陷、故障消除。

7.3. 数据库设计

第1步 设计准备

数据库设计人员阅读需求文档和系统设计文档，明确数据库设计任务。 数据库设计人员准备相关的设计工具和资料。

数据库设计人员确定本软件的数据库设计规则，主要包括：

数据库命名规则 逻辑设计规则 物理设计规则 安全性设计规则

22

优化规则

数据库管理与维护规则

第2步 数据库设计

数据库设计一般要经历“逻辑设计—>物理设计－>安全性设计－>优化”

等步骤，通常要迭代进行。

1) 逻辑设计

数据库设计人员根据需求文档，创建与数据库相关的那部分实体关系图（ERD）。如果采用面向对象方法（OOAD），这里实体相当于类（class）。 2) 物理设计

设计表结构。一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。逻辑设计中的实体大部分可以转换成物理设计中的表，但是它们并不一定是一一对应的。 3) 安全性设计

提高软件系统的安全性应当从“管理”和“设计”两方面着手。这里仅考虑数据库的安全性设计。

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

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

确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限，不多也不少。在应用

23

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

第3步 撰写数据库设计文档

数据库设计人员根据指定的模板撰写《数据库设计说明书》，主要内容包括：

数据库环境说明 数据库的命名规则 逻辑设计 物理设计 安全性设计 优化

数据库管理与维护说明

第4步 数据库设计评审

数据库设计人员可提议项目经理组织进行数据库技术评审。 数据库的主要评审要素包括：

正确性、完整性、一致性 安全性

第5步 数据库实现及测试

按照评审结果开始进行数据库代码编写，并自行测试，记录测试结果，不断完善改进，直至缺陷、故障消除。

7.4. 软件模块设计

第1步 设计准备

模块设计人员阅读需求文档和系统设计文档，明确模块设计任务。 模块设计人员准备相关的设计工具和资料。

24

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

第2步 模块设计

模块设计一般要经历“接口与属性设计—>数据结构与算法设计”等步骤，

并且通常需要反复迭代。

1) 接口与属性设计

模块设计人员设计每个模块的主要接口与属性。如果采用面向对象方法，相当于设计类的函数和成员变量。 2) 数据结构与算法设计

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

第3步 撰写模块设计文档

模块设计人员根据指定的模板撰写《模块设计报告》，主要内容包括：

模块汇总

每个模块的主要接口与属性

每个模块的数据结构与算法（如果存在的话）

第4步 模块设计评审

模块设计人员可提议项目经理组织进行对模块设计文档技术评审。

第5步 模块实现

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

7.5. 硬件模块设计

第1步 设计准备

模块设计人员阅读需求文档和系统设计文档，明确模块设计任务。 模块设计人员准备相关的设计工具和资料。

25

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

第2步 模块设计

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

第3步 撰写设计文档

模块设计人员根据指定的模板撰写《模块设计报告》，主要内容包括：

模块汇总

每个模块的主要接口与连接件选型 每个模块内部部件选型和资源分配

第4步 模块设计评审

模块设计人员可提议项目经理组织进行对模块设计文档技术评审。

第5步 模块实现及测试

按照评审结果开始进行各模块单元电路及结构设计，并测试验证，记录测试结果，不断

完善改进，直至缺陷、故障消除。

7.6. 工艺设计

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

8. 系统测试

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

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

26

系统测试的流程如错误!未找到引用源。所示，关键活动是“制定系统测试计划”、“设计测试用例”、“执行系统测试”和“缺陷管理与改错”。该流程的主要工作成果和责任人见错误!未找到引用源。。

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

8.1.1. 制定系统测试计划

测试人员测试前起草《系统测试计划》。该计划主要包括：

测试范围（内容） 测试方法

测试环境与辅助工具 测试完成准则 人员与任务表

补充说明：项目经理审批《系统测试计划》。

8.1.2. 设计系统测试用例

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

27

补充说明：项目经理审批《系统测试用例》，必要条件下可对该测试用例组织技术评审。待开发人员交付后开始执行系统测试。

8.1.3. 执行系统测试

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

8.1.4. 缺陷管理与改错

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

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

9. 配置管理

配置管理即通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。该活动贯穿于整个设计开发过程。

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

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

每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了产品的演化过程。

28

基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。

配置管理的流程如错误!未找到引用源。 所示，关键活动是“制定配置管理计划”、“配置库管理”、“版本控制”和“变更控制”。该流程的主要工作成果和责任人见错误!未找到引用源。 。 制定配置管理计划配置库管理配置审核变更控制版本控制 图 9-1配置管理的流程 关键活动 制定配置管理计划 配置库管理 版本控制 变更控制 配置管理计划 配置库管理报告 配置项变更控制报告 主要工作成果 配置管理员 配置管理员 项目组成员 项目经理 主要责任人 表 9-1配置管理主要工作成果和责任人 9.1. 制定配置管理计划、进行配置库管理 第1步 确定配置管理的软硬件资源 29

配置管理员根据项目的规模以及财力，确定配置管理软件以及计算机资源（考虑内存、外存、CPU等）。

第2步 制定配置项计划

配置管理员识别项目的主要配置项。每个配置项都有唯一的标识符，标识符的参考格式为Project-Type…Type-Number。

可以在Project（或Product）前面加上公司的标识符。 Type…Type表示配置项类型，可以采用多级缩写。

Number为3为数字，范围从001到999，表示一个配置项有若干个文件。若配置项只有一个文件，则该项可以省略。

第3步 制定基线计划

配置管理员确定每个基线的名称（标识符）及其主要配置项，估计每个基线建立的时间。

第4步 制定配置库备份计划

配置管理员制定配置库备份计划，指明“何人”在“何时”（频度）将配置库备份到“何处”。

第5步 审批《配置管理计划》

如项目经理承担配置管理员工作，则由技术负责人审批《配置管理计划》。否则，项目经理审批，技术负责人签字认可。

第6步 配置库管理

配置管理员创建配置库，并且至少创建配置库的所有第一级目录。 配置管理员为每个项目成员分配操作权限。一般地，项目成员拥有Add, Checkin/Checkout, Download等权限，但是不能拥有“删除”权限。配置管理员的权限最高。具体操作视所采用的配置管理软件而定。

30

项目成员根据自己的权限操作配置库，例如Add, Checkin/Checkout, Download等。

配置管理员根据“基线计划”创建与维护基线，“冻结”配置项，控制变更。 配置管理员定期清除配置库里的垃圾文件。 配置管理员定期备份配置库。

9.2. 版本控制

9.2.1. 配置项状态变迁规则

配置项的状态有三种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”（Changing）。

配置项状态变迁如错误!未找到引用源。 所示。配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。

否决自由修改草稿评审或审批变更控制通过正式发布正在修改 图 9-2配置项状态变迁图 9.2.2. 配置项版本号规则

配置项的版本号与配置项的状态紧密相关： 1) 处于“草稿”状态的配置项的版本号格式为：

YZ数字范围为01-99。

31

随着草稿的不断完善，“YZ”的取值应递增。“YZ”的初值和增幅由用户自己把握。

2) 处于“正式发布”状态的配置项的版本号格式为：

X为主版本号，取值范围为1-9。Y为次版本号，取值范围为1-9。 配置项第一次“正式发布”时，版本号为。

如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。

3) 处于“正在修改”状态的配置项的版本号格式为：

配置项正在修改时，一般只增大Z值，值保持不变。

当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加值。参见规则（2）。

9.2.3. 配置项版本控制流程

第1步 创建配置项

项目成员依据《配置管理计划》，在配置库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”，其版本号格式为。

第2步 修改处于“草稿”状态的配置项

项目成员使用配置管理软件的Checkout/Checkin功能，可以自由修改处于“草稿”状态的配置项（不受变更控制规程约束），版本号格式为。

第3步 技术评审或领导审批

如果配置项是技术文档，则需要接受技术评审。如果配置项是“计划”这类文件，则需要项目经理的审批。

若配置项通过了技术评审或领导审批，则转向第4步，否则转向第2步。

第4步 正式发布

32

配置项通过技术评审或领导审批之后，则配置项的状态从“草稿”变迁为“正式发布”，版本号格式为。

第5步 变更

修改处于“正式发布”状态的配置项，需按如下步骤进行：

如果项目经理同意变更，则配置项状态从“正式发布”变迁为“正在修改”。

项目成员使用Checkout/Checkin功能，可以修改处于“正在修改”状态的配置项，版本号格式为。

修改完毕后，该配置项要重新接受技术评审或领导审批，转向第3步。

9.3. 变更控制

第1步 变更申请

变更申请人向项目经理提交变更申请，重点说明“变更内容”和“变更原因”。

第2步 审批变更申请

项目经理审批该申请，分析此变更对项目造成的影响。如果同意变更，则转向第3步，否则终止本规程。

第3步 安排变更任务

项目经理指定变更执行人，安排他们的任务。项目经理需要和变更执行人就变更内容达成共识。

第4步 执行变更任务

变更执行人根据项目经理安排的任务，修改配置项。

项目经理监督变更任务的执行，如检查变更内容是否正确、是否按时完成工作等。

33

第5步 对更改后的配置项重新进行技术评审（或审批）

如果配置项是技术文档，则需要接受技术评审。如果配置项是“计划”这类文件，则需要项目经理（或上级领导）的审批。

若配置项通过了技术评审或领导审批，则转向第6步，否则转向第4步（即重新修改）。

第6步 结束变更

当所有变更后的配置项都通过了技术评审或领导审批，这些配置项的状态从“正在修改”变迁为“正式发布”。项目经理、技术负责人在《配置项变更控制报告》中签字，结束变更。

10. 结项管理

结项管理是指在项目开发工作结束后，对项目进行综合评估；总结经验教训等。

项目结束有两种状况：一是正常结束，二是异常结束。前者是指项目按预定计划结束。后者原因有多种，归根结底都是由于该项目不再符合机构的最大利益。例如有些项目因不适应市场而被中途淘汰，有些项目在执行过程中大大因偏离计划（如进度延误、费用超支）而被取消。

结项管理的流程如错误!未找到引用源。错误!未找到引用源。所示，关键活动是“结项申请”、“领导审批”和“结项评审”。该流程的主要工作成果和责任人见错误!未找到引用源。。

34

结项评审资产检查结项申请机构领导审批综合评估经验总结 图 10-1结项管理的流程 关键活动 结项申请 领导审批 结项评审 结项申请书 结项申请的审批意见 结项评审报告 主要工作成果 项目经理 决策领导 项目管理委员会 主要责任人 表 10-1结项管理主要工作成果和责任人

批注：对于那些不再符合公司最大利益的项目而言，决策领导应当明确指示项目经理，确定何时结束项目。

10.1. 结项申请

项目经测试无误后，项目经理撰写《结项申请书》，并递交给技术负责人，经研发总监\\产品总监审批。报项目管理委员会，提议组织项目评审。《结项申请书》主要内容包括：

项目介绍

计划与实际情况对比 主要工作成果 专利与版权情况 项目主要资产及处理意见

35

10.2. 结项评审

项目管理委员会组织对该项目进行综合评估，主要内容包括：

项目完成情况 项目质量 投入产出分析 项目的市场价值

项目管理委员会编写《结项评审报告》，并交付总经理。 总经理签注最终意见，项目正式结束。 36