项目开发管理规范

目的描述公司产品研发的管理流程与工作内容。通过本规范的实行，保证研发方向对的，阶段目的清楚，项目过程可控，从而保证按照预期计划完毕产品研发和上市销售。研发管理整体流程研发管理流程图图STYLEREF1\s2SEQ图\*ARABIC\s11研发管理流程模型研发项目的组织结构研发项目的组织结构模型如REF_Ref\h图22所示，共分为4个层次，决策领导（总经理、研发中心总监/产品中心总监）；项目经理、项目成员；营销生产质检运营等相关支持部门；项目管理委员会（由项目管理部根据项目情况组织相关成员组成）。图STYLEREF1\s2SEQ图\*ARABIC\s12研发项目组织结构决策领导涉及总经理、研究院主任、研发中心总监/产品中心总监、技术负责人。总经理拥有最终决策权，决策领导逐级下达任务给项目经理，项目经理向直接决策领导报告工作，再分级上报。项目经理是研发项目的管理者，他带领所有项目成员共同完毕决策领导下达的任务。项目成员是指在项目中执行具体任务的人员，例如分析员、设计师、程序员、测试员等。项目经理下达任务给项目成员，项目成员们向项目经理报告各自的工作。项目成员并非固定在一个项目中工作，他们也许会为多个项目提供服务。假如组织内没有相对独立的测试组，那么测试人员的直接领导就是项目经理。假如机构内有测试组，那么测试人员的直接领导是测试经理，当测试人员接受了某个项目的测试任务，那么他要向测试经理或项目经理报告工作。研发项目的角色在研发项目中，每个人可以拥有多个角色，视项目情况而定。角色职责如REF_Ref\h表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）协助营销人员宣传、销售该产品，及时获取客户的反馈，改善产品。制造、采购、质检、运营相关支持部门采购负责样机制作过程中的外购、外协联络；制造部门负责产品小批量试制；质检部门负责试制过程中产品的功能、性能验证；运营部门负责反馈现场运营情况。表STYLEREF1\s2SEQ表\*ARABIC\s11研发项目中的角色职责流程中的过程域、重要活动和重要工作成果过程域重要活动重要工作成果营销

过程产品构思和调研产品构思，产品调研产品需求说明书，产品调研报告，技术可行性分析报告产品体验和宣传销售产品体验，宣传销售产品宣传材料协议项目销售接触客户，可行性分析，投标答辩，签订协议投标书，协议，项目需求说明书客户服务和协议验收产品维护，评审成果，控制变更，项目验收项目验收报告项目管理过程立项管理立项申请，立项评审，项目筹备立项申请书，立项评审报告结项管理结项申请，结项评估，关闭项目结项申请书，结项评估报告项目规划与监控制定项目计划，人员管理，任务进度管理，项目成本管理，设备管理项目计划，日记，周报风险跟踪和变更控制辨认风险，解决风险，关闭风险

变更申请，变更审批，执行风险跟踪表，变更控制报告项目开发过程需求开发与管理需求调研，需求分析，需求定义，评审确认，细化跟踪，变更控制产品（项目）需求说明书系统设计系统方案设计、硬件结构设计，软件架构设计，用户界面设计，数据库设计，模块设计系统集成方案，系统概要设计说明书，系统具体设计说明书。模块开发与集成模块需求细化，模块设计，模块实现和集成，工艺设计，试制样品模块需求说明书，模块设计说明书，软件代码，硬件及机械结构设计图，产品图纸、工艺卡片、工装设计图等测试与改错准备测试，执行测试，消除缺陷测试用例，测试报告软硬件系统集成系统集成，选择设备供应商，设备采购和验收，设备安装调试设备具体清单小批量试制及改善选择物料供应商，物料采购，试制产品小批量试制报告，改善记录部署试用撰写文档，软件部署，客户培训，客户试用（周期允许交付质检查证测试，否则交付客户现场试运营）部署说明书，安装和使用手册软件维护接受维护请求，分析维护请求，

执行维护（涉及工厂运营测试、现场试运营测试）维护记录支持

过程配置管理软件代码管理，硬件电路图管理，文档管理软件代码库，硬件电路图库，文档库质量管理技术评审，测试管理，发布管理，质量保证，缺陷（问题）跟踪技术评审报告，发布记录，缺陷报告采购及外包产品试制过程中的外购外协外购外协申请单、供方协议评审、合格供方清单。客户服务管理客户信息管理，客户问题受理（涉及工厂安装调试运营问题、现场测试运营问题）客户信息库，客户问题记录，安装调试运营记录表STYLEREF1\s2SEQ表\*ARABIC\s12研发项目流程中的过程域、重要活动和重要工作成果立项管理立项管理的流程如REF_Ref\h图31所示，关键活动是“协议项目立项申请”、“自主产品立项申请”、“立项评审”和“项目筹备”。该流程的重要工作成果和负责人见REF_Ref\h表31。注：在立项申请阶段，决策领导根据项目特性和开发部门的情况，即任命合适的项目经理，共同进行产品需求调研、可行性分析等，共同筹备立项申请。图STYLEREF1\s3SEQ图\*ARABIC\s11立项管理的流程关键活动重要工作成果重要负责人自主产品立项申请立项申请书，

产品需求说明书，产品调研报告，技术可行性分析报告相关决策领导、项目经理协议项目立项申请立项申请书，

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