项目开发管理规范最新版本.doc

1. 目的描述公司产品研发的管理流程与工作内容。通过本规范的实施，确保研发方向正确，阶段目标清晰，项目过程可控，从而确保按照预期计划完成产品研发和上市销售。2. 研发管理整体流程2.1. 研发管理流程图图21研发管理流程模型2.2. 研发项目的组织结构研发项目的组织结构模型如图 22 研发项目组织结构所示，共分为4个层次，决策领导（总经理、研发中心总监/产品中心总监）；项目经理、项目成员；营销生产质检运营等相关支持部门；项目管理委员会（由项目管理部根据项目情况组织相关成员组成）。图 22 研发项目组织结构决策领导包括总经理、研究院主任、研发中心总监/产品中心总监、技术负责人。总经理拥有最终决策权，决策领导逐级下达任务给项目经理，项目经理向直接决策领导汇报工作，再分级上报。项目经理是研发项目的管理者，他带领所有项目成员共同完成决策领导下达的任务。项目成员是指在项目中执行具体任务的人员，例如分析员、设计师、程序员、测试员等。项目经理下达任务给项目成员，项目成员们向项目经理汇报各自的工作。项目成员并非固定在一个项目中工作，他们可能会为多个项目提供服务。如果组织内没有相对独立的测试组，那么测试人员的直接领导就是项目经理。如果机构内有测试组，那么测试人员的直接领导是测试经理，当测试人员接受了某个项目的测试任务，那么他要向测试经理或项目经理汇报工作。2.3. 研发项目的角色在研发项目中，每个人可以拥有多个角色，视项目情况而定。角色职责如表 21研发项目中的角色职责 所示。后续章节的流程规范将详述“角色在什么时候，以什么步骤做什么事情，产生什么样的成果”。角色该角色在研发流程中的主要职责决策领导（项目决策者）（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）发现问题，及时与责任人沟通，如果难以解决，则由上级领导协调。配置管理员（1）为所有项目创建配置库，为用户分配合适的权限，负责信息安全和备份。（2）指导开发人员使用配置管理软件和研发管理软件。（3）配置管理工作由项目经理承担。技术支持主管（1）负责安排售前、生产、售后跟踪产品开发过程，及时提出需求建议，及时试用产品，纠正偏差，给出优化建议，使产品更加适合目标客户的需求。（3）协助营销人员宣传、销售该产品，及时获取客户的反馈，改进产品。制造、采购、质检、运营相关支持部门采购负责样机制作过程中的外购、外协联络；制造部门负责产品小批量试制；质检部门负责试制过程中产品的功能、性能验证；运营部门负责反馈现场运行情况。表 21研发项目中的角色职责2.4. 流程中的过程域、主要活动和主要工作成果过程域主要活动主要工作成果营销过程产品构思和调研产品构思，产品调研产品需求说明书，产品调研报告，技术可行性分析报告产品体验和宣传销售产品体验，宣传销售产品宣传材料合同项目销售接触客户，可行性分析，投标答辩，签订合同投标书，合同，项目需求说明书客户服务和合同验收产品维护，评审成果，控制变更，项目验收项目验收报告项目管理过程立项管理立项申请，立项评审，项目筹备立项申请书，立项评审报告结项管理结项申请，结项评估，关闭项目结项申请书，结项评估报告项目规划与监控制定项目计划，人员管理，任务进度管理，项目成本管理，设备管理项目计划，日志，周报风险跟踪和变更控制识别风险，处理风险，关闭风险变更申请，变更审批，执行风险跟踪表，变更控制报告项目开发过程需求开发与管理需求调研，需求分析，需求定义，评审确认，细化跟踪，变更控制产品（项目）需求说明书系统设计系统方案设计、硬件结构设计，软件架构设计，用户界面设计，数据库设计，模块设计系统集成方案，系统概要设计说明书，系统详细设计说明书。 模块开发与集成模块需求细化，模块设计，模块实现和集成，工艺设计，试制样品模块需求说明书，模块设计说明书，软件代码，硬件及机械结构设计图，产品图纸、工艺卡片、工装设计图等测试与改错准备测试，执行测试，消除缺陷测试用例，测试报告软硬件系统集成系统集成，选择设备供应商，设备采购和验收，设备安装调试设备详细清单小批量试制及改进选择物料供应商，物料采购，试制产品小批量试制报告，改进记录部署试用撰写文档，软件部署，客户培训，客户试用（周期允许交付质检验证测试，否则交付客户现场试运行）部署说明书，安装和使用手册软件维护接受维护请求，分析维护请求，执行维护（包括工厂运行测试、现场试运行测试）维护记录支持过程配置管理软件代码管理，硬件电路图管理，文档管理软件代码库，硬件电路图库，文档库质量管理技术评审，测试管理，发布管理，质量保证，缺陷（问题）跟踪技术评审报告，发布记录，缺陷报告采购及外包产品试制过程中的外购外协外购外协申请单、供方合同评审、合格供方清单。客户服务管理客户信息管理，客户问题受理（包括工厂安装调试运行问题、现场测试运行问题）客户信息库，客户问题记录，安装调试运行记录表 22研发项目流程中的过程域、主要活动和主要工作成果3. 立项管理 立项管理的流程如图 31所示，关键活动是“合同项目立项申请”、“自主产品立项申请”、“立项评审”和“项目筹备”。该流程的主要工作成果和责任人见表 31。注：在立项申请阶段，决策领导根据项目特征和开发部门的情况，即任命合适的项目经理，共同进行产品需求调研、可行性分析等，共同筹备立项申请。图 31立项管理的流程关键活动主要工作成果主要责任人自主产品立项申请立项申请书，产品需求说明书，产品调研报告，技术可行性分析报告相关决策领导、项目经理合同项目立项申请立项申请书，项目需求说明书，相关合同文本合同项目的销售专员立项评审立项评审报告项目管理委员会项目筹备项目总体计划相关决策领导，项目经理表 31立项管理主要工作成果和责任人3.1. 自主产品立项申请项目经理撰写立项申请书，将立项申请书、产品需求说明书、产品调研报告、立项可行性分析报告提交给项目管理委员会负责人审阅。如发现文件内容不合流程要求或者质量不合格，则退还给申请人重新改进，直到文件合格为止。3.2. 合同项目立项申请一般情况下，开发方和客户签订正式合同之后，开发方再在公司内部立项。也有一些例外，由于某些原因导致合同尚未签订，但是客户有一些口头承诺，要求开发方先做项目，后签订合同。如果开发方不同意，则可能失去机会。如果开发方同意先开发，但是存在比较大的风险，要在立项评审会议做出决定。项目销售人员撰写立项申请书，将立项申请书、项目需求说明书以及相关合同文本提交给项目管理委员会负责人审阅，如果发现文件内容不合流程要求或者质量不合格，则退还给申请人重新改进，直到文件合格为止。3.3. 立项评审第1步 评审准备项目管理委员会负责人把立项申请书等相关文件递交给各个评审委员。项目管理委员会负责人确定立项评审会议的时间、地点、设备和参加会议的人员名单。第2步 举行评审会议立项申请人陈述立项申请书和相关文件的主要内容。评审委员提出疑问，立项申请人解答。双方应当对有争议的内容得出处理意见。项目管理委员会负责人汇总所有评审委员的评审意见，填写立项评审报告，以“少数服从多数”决定是否立项，以及给出项目执行建议。第3步 项目终审项目管理委员会负责人将立项评审报告递交给总经理。总经理在立项评审报告中签注最终审批意见。 如果同意立项，那么进入下一步“项目筹备”。否则，项目中断。3.4. 项目筹备第1步 再次明确项目经理责任再次明确项目经理权责，项目经理对立项之后的项目进度和质量负最大责任。第2步 确立项目组，项目成员第3步 项目启动会项目经理召开项目启动会，让所有项目成员了解项目的目标和工作内容。4. 项目计划 项目计划的流程如图 41 图 31所示，关键活动是“项目估计”、“制定项目计划”、“审批项目计划”和“项目计划变更控制”。该流程的主要工作成果和责任人见表 41。图 41项目计划的流程关键活动主要工作成果主要责任人项目估计项目估计表项目经理制定项目计划项目计划项目经理审批项目计划按评审意见修正后的项目计划相关决策领导，项目经理项目计划变更控制项目计划变更控制报告新的项目计划相关决策领导，项目经理表 41项目计划主要工作成果和责任人4.1. 项目估计项目经理组织项目成员进行项目功能、模块分解，从而估计产品的规模，估计工作量；估计成本和预算。l 产品规模的主要度量单位有：代码行类（对象）个数功能电路块数，机械结构难易程度，机械结构图纸数量电路原理复杂程度文档页数l 成本包括人力成本、软硬件资源成本等；预算除上述成本外还包括项目知识产权管理、项目验收等费用。4.2. 制定项目计划第1步 确定目标与范围首先确定本项目的目标与工作范围。目标必须是“可实现的”和“可验证的”。工作范围包括“做什么”和“不做什么”。第2步 制定人力资源计划项目经理制定本项目的角色职责表，并为项目成员分配角色（一个人可以兼多个角色）。第3步 制定软硬件资源计划分析项目开发、测试以及用户使用产品所需的软硬件资源，制定软硬件资源计划。 资源级别（分为“关键”、“普通”两种） 详细配置 获取方式（如“已经存在”、“可以借用”或“需要购买”等）与获取时间 用途（如“谁”在“什么”时候使用）第4步 制定财务计划制定财务计划。 开支类别 主要用途 金额 时间第5步 分配任务并制定进度表项目经理结合4.1项目评估结果，以及项目成员数量分解任务并制定详细进度表，建议采用Microsoft Project制作Gantt 图，附在项目计划中。4.3. 审批项目计划第1步 申请审批项目经理将项目计划提交给决策领导，最终提交总经理审批。补充说明：如果是合同项目，可能还要请客户审批，视具体情况而定。第2步 审批与修正l 决策领导根据“项目计划检查表”认真审批项目计划。l 如果项目计划中进度周期不能满足市场要求时，决策领导和项目经理共同商讨解决办法。第3步 批准生效决策领导签字批准后，该项目计划正式生效，此后项目经理不能随意修改项目计划。4.4. 项目计划变更控制第1步 变更申请项目经理向决策领导申请变更项目计划。变更申请书中应当说明： 变更原因 变更的内容 此变更对项目造成的影响补充说明：如果是合同项目，可能还要向客户提出变更申请，视具体情况而定。第2步 审批变更申请机构领导审批变更申请： 如果不同意变更，则退回变更请求，项目按照原计划执行。 如果同意变更，转向 第3步。第3步 修改项目计划项目经理修改原项目计划，产生新的项目计划。第4步 审批新的项目计划决策领导审批新的项目计划补充说明：如果项目计划对整个项目完成周期有影响时，该项目计划需提交总经理审批。5. 项目监控项目监控划tep2 包括项目研发过程、项目管理过程、机构支撑过程等。控制控制流程如图 51所示，关键活动是“项目计划跟踪”、“偏差控制”和“项目进展总结”。该流程的主要工作成果和责任人见表 51。图 51项目监控的流程关键活动主要工作成果主要责任人项目计划跟踪项目进展报告项目经理偏差控制项目进展总结表 51项目控制主要工作成果和责任人5.1. 项目计划跟踪 项目经理周期性地（如每周一次）跟踪每个重要的任务，项目费用使用情况，软硬件资源配置情况，形成记录。 5.2. 偏差控制第1步 找出显著偏差项目经理根据任务跟踪、费用跟踪、资源跟踪所产生的数据，对比“项目实际进展”与“项目计划”，找出 显著 偏差项（例如进度偏差大于20）。第2步 分析原因项目经理分析产生显著偏差的原因，以便采取正确的纠正措施。第3步 给出纠正偏差的措施l 项目经理给出纠正显著偏差的措施： 如果偏差主要是由于项目计划不合理导致的，则要变更项目计划。 如果项目计划本身是合理的，偏差主要是由于项目成员在执行时产生的，那么要求项目成员弥补偏差，避免原本合理的计划在实施时落空。第4步 跟踪纠正偏差的过程项目经理跟踪纠正偏差的过程，直到该偏差被消除为止。5.3. 项目进展总结项目经理周期性地（或者在里程碑处）召开项目进展会议，探讨问题，总结工作，让所有项目成员清楚地了解项目的实际进展情况。 项目经理撰写项目进展报告，并及时通报给所有项目成员和决策领导。6. 需求开发与管理 项目需求开发和管理的流程如图 61图 51所示，关键活动是“需求开发”、“需求确认”、“需求跟踪”和“需求变更”。该流程的主要工作成果和责任人见表 71。图 61需求开发与管理的流程关键活动主要工作成果主要责任人需求开发产品需求说明书需求分析员需求确认需求评审项目经理/上级决策领导/项目管理委员会需求变更需求变更申请需求分析员表 61需求开发与管理主要工作成果和责任人6.1. 需求开发第1步 细化并分析用户需求l 需求分析员对用户需求说明书进行细化，以便产生详细的产品需求。l 需求分析员对比较复杂的用户需求进行建模分析，以帮助开发人员更好地理解需求。第2步 撰写产品需求规格说明书需求分析员按照指定的文档模板撰写产品需求规格说明书。如果待开发的产品分为软件和硬件两部分的话，则应当分别撰写软件需求规格说明书和硬件需求规格说明书。产品需求规格说明书的主要内容包括： 产品介绍； 描述用户群体的特征； 定义产品的范围； 阐述产品应当遵循的标准或规范； 定义产品中的角色； 定义产品的功能性需求； 定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求6.2. 需求确认第1步 非正式需求评审项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。第2步 正式需求评审项目经理上报上级领导进行审批，必要情况下邀请项目管理委员会组织相关成员和用户（合同项目）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的真实意愿。第3步 获取需求承诺当需求文档通过正式的评审之后，项目经理和决策领导、客户（合同项目）对需求文档作书面承诺。6.3. 需求变更第1步 需求变更申请l 需求变更申请人撰写“需求变更申请书”，递交给项目经理或客户方负责人。l “需求变更申请书”必须阐述：（1）变更原因；（2）变更的内容；（3）此变更对项目造成的影响。第2步 审批需求变更申请l 项目经理和决策领导、客户（合同项目）共同审批“需求变更申请书”：l 如果任何一方不同意变更，则退回变更请求，项目按照“原需求文档”执行。l 如果双方都同意变更，转向第3步。第3步 更改需求文档需求分析员根据第1步 和第2步更改“原需求文档”，产生新的需求文档。第4步 重新进行需求确认l 重新进行需求评审，参见需求确认规程中的第2步。l 重新获取书面的需求承诺，参见需求确认规程中的第3步。补充说明：1、如果项目经理直接承担需求分析员工作，需求评审由上级领导审批，必要情况下邀请项目管理委员会组织相关成员和用户（合同项目）一起评审，视具体情况而定。7. 系统设计系统设计是指设计硬件结构（包括电路、机械等），软件架构、用户界面、数据库、模块等，从而在需求与代码、电路、机械等之间建立桥梁，指导开发人员去实现能满足用户需求的产品。图 71关键活动主要工作成果主要责任人软件架构设计概要设计说明书，详细设计说明书系统设计师硬件结构设计硬件、结构设计方案系统设计师用户界面设计用户界面设计说明书开发人员数据库设计数据库设计说明书开发人员软件模块设计软件模块设计说明书开发人员硬件模块设计硬件模块设计说明书开发人员工艺设计工艺文件工艺技术员表 717.1. 软件/硬件系统设计第1步 设计准备l 阅读需求文档，分解系统设计任务。l 准备相关的设计工具和资料。第2步 确定影响系统设计的约束因素l 需求约束。系统设计人员从需求文档中提取需求约束，例如： 本系统应当遵循的标准或规范 软件、硬件环境（包括运行环境和开发环境）的约束 接口/协议的约束 用户界面的约束 产品外观、内部布局、零部件加工工艺、装配工艺等的约束 软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。 硬件质量的约束，如可靠性、稳定性、精确度、功耗、安全性、可扩展性、抗震性等等 隐含约束。有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，设计人员应当尽可能地在此处说明。例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。第3步 系统分解与设计 将系统分解为若干子系统，确定每个子系统的功能以及子系统之间的关系。 将子系统分解为若干模块，确定每个模块的功能以及模块之间的关系。 确定系统开发、测试、运行所需的软硬件环境。第4步 撰写系统结构设计文档 系统设计人员根据指定的模板撰写概要设计说明书、详细设计说明书硬件结构设计方案，主要内容包括： 系统概述 影响设计的约束因素 设计策略 系统总体结构 子系统的结构与模块功能 开发、测试、运行所需的软硬件环境第5步 系统设计评审 系统设计评审主要评审要素包括： 合适性。考察该结构是否适合于产品需求，是否可在预定计划内实现。 系统的综合能力，例如可扩展性，可管理性（可维护性），可复用性，安全性等等，视产品特征而定。补充说明：1、如果项目经理直接承担系统设计工作，评审由上级领导审批，必要情况下邀请项目管理委员会组织相关成员和用户（合同项目）一起评审，视具体情况而定。7.2. 用户界面设计第1步 设计准备l 界面设计人员阅读需求文档和系统设计文档，明确界面设计任务。l 界面设计人员与用户交流，了解用户的工作习惯和他们对界面的看法。l 界面设计人员准备相关的设计工具和资料，收集或创作基本的界面资源如图像、图标以及通用的组件。l 界面设计人员确定本软件的用户界面设计规则，主要包括： 软件主界面（如主窗口、主页面）的设计规则； 软件子界面（如子窗口、子页面）的设计规则； 标准控件的使用规则；第2步 用户界面设计用户界面设计一般要经历“原型创作原型评估细化”等步骤，通常迭代进行。1) 原型创作界面设计人员创作界面原型： 先徒手画，或者用Visio 等工具绘制界面的视图； 再用软件开发工具实现可以运行的原型。2) 原型评估界面设计人员可提议项目经理进行评估界面的原型，汇集意见，及时改进。3) 细化第3步 撰写用户界面设计文档l 用户界面定型之后，界面设计人员根据指定的模板撰写用户界面设计报告，主要内容包括： 应当遵循的界面设计规范； 界面的关系图和工作流程图； 主界面的视图、功能说明、操作方式； 子界面的视图、功能说明、操作方式；第4步 用户界面设计评审l 界面设计人员可提议项目经理对定型后的界面组织进行正式技术评审，尽最大努力使界面变得更加美观、易用。l 用户界面的主要评审要素包括： 简洁易用 一致性 美观 动态反馈 功能屏蔽和出错处理 用户控制 兼容性和可移植性 适应性（针对各种用户）第5步 界面设计及测试 按照评审结果开始进行界面设计，并自行测试，记录测试结果，不断完善改进，直至缺陷、故障消除。7.3. 数据库设计第1步 设计准备l 数据库设计人员阅读需求文档和系统设计文档，明确数据库设计任务。l 数据库设计人员准备相关的设计工具和资料。l 数据库设计人员确定本软件的数据库设计规则，主要包括： 数据库命名规则 逻辑设计规则 物理设计规则 安全性设计规则 优化规则 数据库管理与维护规则第2步 数据库设计数据库设计一般要经历“逻辑设计物理设计安全性设计优化”等步骤，通常要迭代进行。1) 逻辑设计数据库设计人员根据需求文档，创建与数据库相关的那部分实体关系图（ERD）。如果采用面向对象方法（OOAD），这里实体相当于类（class）。2) 物理设计设计表结构。一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。逻辑设计中的实体大部分可以转换成物理设计中的表，但是它们并不一定是一一对应的。3) 安全性设计提高软件系统的安全性应当从“管理”和“设计”两方面着手。这里仅考虑数据库的安全性设计。 用户只能用帐号登陆到应用软件，通过应用软件访问数据库，而没有其它途径可以操作数据库。 对用户帐号的密码进行加密处理，确保在任何地方都不会出现密码的明文。 确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限，不多也不少。在应用时再为用户分配角色，则每个用户的权限等于他所兼角色的权限之和。第3步 撰写数据库设计文档l 数据库设计人员根据指定的模板撰写数据库设计说明书，主要内容包括： 数据库环境说明 数据库的命名规则 逻辑设计 物理设计 安全性设计 优化 数据库管理与维护说明第4步 数据库设计评审l 数据库设计人员可提议项目经理组织进行数据库技术评审。l 数据库的主要评审要素包括： 正确性、完整性、一致性 安全性第5步 数据库实现及测试 按照评审结果开始进行数据库代码编写，并自行测试，记录测试结果，不断完善改进，直至缺陷、故障消除。7.4. 软件模块设计第1步 设计准备l 模块设计人员阅读需求文档和系统设计文档，明确模块设计任务。l 模块设计人员准备相关的设计工具和资料。l 模块设计人员确定本软件的编程规范，确保模块设计文档的风格与代码的风格保持一致。第2步 模块设计模块设计一般要经历“接口与属性设计数据结构与算法设计”等步骤，并且通常需要反复迭代。1) 接口与属性设计模块设计人员设计每个模块的主要接口与属性。如果采用面向对象方法，相当于设计类的函数和成员变量。2) 数据结构与算法设计模块设计人员设计每个模块的数据结构与算法。第3步 撰写模块设计文档 模块设计人员根据指定的模板撰写模块设计报告，主要内容包括： 模块汇总 每个模块的主要接口与属性 每个模块的数据结构与算法（如果存在的话）第4步 模块设计评审 模块设计人员可提议项目经理组织进行对模块设计文档技术评审。第5步 模块实现 按照评审结果开始进行模块代码编写，并自行测试，记录测试结果，不断完善改进，直至缺陷、故障消除。7.5. 硬件模块设计第1步 设计准备l 模块设计人员阅读需求文档和系统设计文档，明确模块设计任务。l 模块设计人员准备相关的设计工具和资料。l 模块设计人员确定设计规范，确保各单元设计文档、设计图的风格保持一致。第2步 模块设计模块设计一般要经历“接口与连接件选型模块内部部件选型模块内部资源分配”等步骤。第3步 撰写设计文档 模块设计人员根据指定的模板撰写模块设计报告，主要内容包括： 模块汇总 每个模块的主要接口与连接件选型 每个模块内部部件选型和资源分配第4步 模块设计评审 模块设计人员可提议项目经理组织进行对模块设计文档技术评审。第5步 模块实现及测试 按照评审结果开始进行各模块单元电路及结构设计，并测试验证，记录测试结果，不断完善改进，直至缺陷、故障消除。7.6. 工艺设计根据硬件模块的设计，外观要求等，初步进行工艺设计，并在实现中完善。8. 系统测试系统测试的目的是对最终系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。系统测试的流程如图 8所示，关键活动是“制定系统测试计划”、“设计测试用例”、“执行系统测试”和“缺陷管理与改错”。该流程的主要工作成果和责任人见表 81。图 81系统测试的流程关键活动主要工作成果主要责任人制定测试计划系统测试计划测试员设计测试用例系统测试用例测试员执行系统测试系统测试报告测试员缺陷管理与改错缺陷管理报告测试员表 81系统测试的主要工作成果和责任人8.1.1. 制定系统测试计划测试人员测试前起草系统测试计划。该计划主要包括： 测试范围（内容） 测试方法 测试环境与辅助工具 测试完成准则 人员与任务表补充说明：项目经理审批系统测试计划。8.1.2. 设计系统测试用例测试人员依据系统测试计划和指定的模板，设计（撰写）系统测试用例。补充说明：项目经理审批系统测试用例，必要条件下可对该测试用例组织技术评审。待开发人员交付后开始执行系统测试。8.1.3. 执行系统测试l 测试人员依据系统测试计划和系统测试用例执行系统测试。l 将测试结果记录在系统测试报告中，用“缺陷管理工具”来管理所发现的缺陷，并及时通报给开发人员。8.1.4. 缺陷管理与改错l 在整个系统测试过程中，任何人发现软件系统中的缺陷时都及时报给项目经理及开发人员。l 开发人员及时处理，直至所有缺陷全部消除。9. 配置管理配置管理即通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。该活动贯穿于整个设计开发过程。凡是纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：（1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。（2）项目管理过程域产生的文档。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了产品的演化过程。基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。配置管理的流程如图 91配置管理的流程 所示，关键活动是“制定配置管理计划”、“配置库管理”、“版本控制”和“变更控制”。该流程的主要工作成果和责任人见表 101配置管理主要工作成果和责任人 。图 91配置管理的流程关键活动主要工作成果主要责任人制定配置管理计划配置管理计划配置管理员配置库管理配置库管理报告配置管理员版本控制项目组成员变更控制配置项变更控制报告项目经理表 91配置管理主要工作成果和责任人9.1. 制定配置管理计划、进行配置库管理第1步 确定配置管理的软硬件资源配置管理员根据项目的规模以及财力，确定配置管理软件以及计算机资源（考虑内存、外存、CPU等）。第2步 制定配置项计划配置管理员识别项目的主要配置项。每个配置项都有唯一的标识符，标识符的参考格式为Project-TypeType-Number。 可以在Project（或Product）前面加上公司的标识符。 TypeType表示配置项类型，可以采用多级缩写。 Number为3为数字，范围从001到999，表示一个配置项有若干个文件。若配置项只有一个文件，则该项可以省略。第3步 制定基线计划配置管理员确定每个基线的名称（标识符）及其主要配置项，估计每个基线建立的时间。第4步 制定配置库备份计划配置管理员制定配置库备份计划，指明“何人”在“何时”（频度）将配置库备份到“何处”。第5步 审批配置管理计划如项目经理承担配置管理员工作，则由技术负责人审批配置管理计划。否则，项目经理审批，技术负责人签字认可。第6步 配置库管理配置管理员创建配置库，并且至少创建配置库的所有第一级目录。配置管理员为每个项目成员分配操作权限。一般地，项目成员拥有Add, Checkin/Checkout, Download等权限，但是不能拥有“删除”权限。配置管理员的权限最高。具体操作视所采用的配置管理软件而定。项目成员根据自己的权限操作配置库，例如Add, Checkin/Checkout, Download等。配置管理员根据“基线计划”创建与维护基线，“冻结”配置项，控制变更。配置管理员定期清除配置库里的垃圾文件。配置管理员定期备份配置库。9.2. 版本控制9.2.1. 配置项状态变迁规则配置项的状态有三种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”（Changing）。配置项状态变迁如图 92配置项状态变迁图 所示。配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。图 92配置项状态变迁图9.2.2. 配置项版本号规则配置项的版本号与配置项的状态紧密相关：1) 处于“草稿”状态的配置项的版本号格式为：0.YZ YZ数字范围为01-99。 随着草稿的不断完善，“YZ”的取值应递增。“YZ”的初值和增幅由用户自己把握。2) 处于“正式发布”状态的配置项的版本号格式为：X.Y X为主版本号，取值范围为1-9。Y为次版本号，取值范围为1-9。 配置项第一次“正式发布”时，版本号为1.0。 如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。3) 处于“正在修改”状态的配置项的版本号格式为：X.YZ 配置项正在修改时，一般只增大Z值，X.Y值保持不变。 当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。参见规则（2）。9.2.3. 配置项版本控制流程第1步 创建配置项项目成员依据配置管理计划，在配置库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”，其版本号格式为0.YZ。第2步 修改处于“草稿”状态的配置项项目成员使用配置管理软件的Checkout/Checkin功