1、大型软件组织软件产品研发核心管理过程流程设计V10编号：PDT_F_DE 20020523版本：V1.0研发中心核心过程分类表注：该表在后期研发中心标准研发过程（即本文）维护中使用。维护分类遵循软件生存周期模型（ISO/IEC12207）分类，以支持中心后期面向软件过程改进的优化调整和面向SW_CMM的实施。属性软件生存周期过程责任职能部门/组协作职能部门/组备 注主要生存周期支持生存周期组织生存周期统计一目的本规范是研发中心一级业务流程标准，旨在抽象刻划并规范研发中心产品研/开发工作的全生命周期过程。包括建立并规范产品开发工作流程（包含一些特殊业务的流程），划分开发工作标准过程阶段/里程碑，
2、明确各阶段关键活动、参与人员及相互关系，明确各阶段工作的成果要求，明确中心业务部门间工作接口关系等。二产品研发总体流程设计的技术准则1.中心产品研发流程规范应该从根本上满足软件产品线管理、软件项目管理及软件工程若干管理分支的基本要求（并能从根本上符合SWCMM二级的要求）；2.流程规范是结合中心现有开发过程中软件开发各过程管理作用域实际表现的强势与弱势，并有针对性的按组织统一规划的过程改进逐步建立、完善、实施、以期提升产品研发过程管理水平；3.流程规范从根本上把产品研发过程中各种关键活动和需求管理、项目计划、项目跟踪和监控、配置管理、质量保证活动的要求紧密结合起来；目标是真正建立起研发中心产品
3、研发全生命周期的稳定过程结构。4.规范中的各种要求在流程设计上都应可以体现在计划、项目进度监控和质量监控的文档中，并支持软件过程的度量，积累组织关键数据；5.本体系规范应为培训、查询、使用以及推行检查提供支持和方便。三产品研发与软件项目的关系公司产品研发遵从统一规划分步实施的原则。每个待研发的产品对象的具体开发过程都采用软件项目的机制进行组织实施和内部约束。此外，研发中心接受的其他各种开发任务也以项目形式出现，包括：产品维护（错误修改、功能增强、缺陷完善等），产品客户化开发及维护等。软件项目全生命周期管理贯穿于每一个分支产品的研发过程。同时整体产品（TEEMS）研发对象的管理在产品管理领域采用
4、软件产品线工程管理。二者理论基础如下：产品管理：软件产品线管理；SW_CMM；项目管理：软件工程；软件项目管理SE_CMM；共用基础：软件配置管理；软件质量管理；软件变更控制；需求管理；关于项目规模的中心约束：根据项目规模和难易，中心每个项目的规模控制在60人月以内完成，项目周期控制在6个月以内。超过上述规模约束的软件项目需要拆分成多个小的项目组织实施。一般的30人月以上的项目称为大项目，10个人月以内的项目称为小项目。四研发中心产品研发过程阶段划分与里程碑设置1、产品研发过程标准阶段划分研发中心产品研发过程划分为11个标准阶段，同步设立9个技术评审点，2个组织管理环节（研发立项、产品验收）。
5、11个标准阶段构成研发中心标准软件生命周期过程模型，是研发中心企业一级技术流程约束。2、面向对象的过程裁剪研发中心标准软件过程生存周期模型在具体的某一个项目中可以依据项目的具体属性进行必要的裁剪。以下给出关于中心产品研发标准周期模型中阶段在项目中的适用说明。1)原则上研发中心任何一个产品/构件的开发过程都必须经历上述11个技术控制阶段。在实际项目开发组织时可以根据待研发产品的规模、复杂程度、风险要求酌情裁剪开发过程阶段形成面向项目对象的快速开发过程模型（RAD）。2)关于生命周期过程模型的裁减执行人：项目经理是实际项目生命周期选择和裁减的执行人。需要说明两个问题：一是开发过程中充当该项目的质量
6、保证工程师有责任和义务对项目经理过程模型的选择和裁减提供技术支持和必要的评审，过程周期模型的合理性直接关系到软件开发过程的关键路径，是成本基线、质量基线的基础，必须予以充分的重视；此外在当前中心尚未建立独立的SEPG 时过程模型的裁剪需要得到中心技术主管负责人的审核，过程模型是项目战略层次的规划。3)关于项目过程模型适用性裁剪的准则。目前尚未建立中心过程模型裁剪的技术控制标准，项目经理和其他人员可以先行参考 软件能力成熟度模型过程裁减指南 。4)裁剪的原则约束：无论项目对象、项目属性，在面向适用对象的裁剪时不可裁减的两个关键阶段是：需求、设计。中心组织性原则约束，需求必须进行评审并建立基线化管
7、理，以确保需求在项目全周期的变更受到有效的控制和管理；设计必须评审，以确保在实际软件建立（OOP）的过程中所潜在遵循的设计模型不存在关键设计质量差异。3、过程里程碑规格约束序号阶段名称阶段属性是否包含里程碑/里程碑规格1产品规划阶段产品（线）管理过程里程碑：产品规划评审规格约束：暂不定义。2产品规格定义阶段里程碑：产品规格定义评审规格约束： 暂不定义。3软件需求阶段项目管理过程里程碑：需求评审规格约束： 暂不定义。4软件项目计划阶段里程碑：项目计划评审规格约束： 暂不定义。5软件分析阶段里程碑：OOA评审规格约束： 暂不定义。6软件设计阶段里程碑：OOD评审规格约束： 暂不定义。7编码与单元测
8、试阶段无8集成测试阶段里程碑：软件集成与集成测试评审规格约束： 暂不定义。9系统测试阶段里程碑：系统测试评审规格约束： 暂不定义。10产品发布阶段里程碑：验收评审规格约束： 暂不定义。11产品管理阶段产品线无说明：里程碑的规格暂不能详细刻划，后期补充该工作。五研发中心产品研发过程概述1. 产品规划是产品战略级规划：主要包括产品的商业目标规划；产品的应用构成（功能族）结构规划；技术研究方向规划等。关键活动包括：目标市场规划：确定产品的目标市场；结合本产品规划对目标市场的未来进行预测与分析（一般要求基于行业调研的统计报告和分析报告）；功能规划：定义产品的功能范围；全面规划产品的功能方向（满足业务需
9、求的功能领域）；产品的功能结构构成；划分产品和子产品的功能边界；产品功能结构的优化；产品竞争性规划：同业产品的查新；相似产品的比较研究；规划产品的竞争特性分析与比较分析等；产品满足企业商业目标的规划：产品在组织内可实施性的分析。要求做产品整体级研发估计（核心是费用、资源与进度）；产品产出效益分析/回报分析等可参考商业计划书过程；产品的技术指标要求：产品性能规划；初步定义产品验收标准。产品规划的组织约束：定义产品实施过程中的各类别组织约束（进度的、成本的、资源的、质量的、特性的等）。规划优化活动（包括开发对象优先级分析）工作产品：（请参见模板/样例）序号工作产品名称工作产品形态责任人1产品规划总
10、体规划设计报告技术报告Word 文件产品总规划/设计师2产品结构规划树不限产品总规划/设计师3产品可实施分析报告 不限产品总规划/设计师 等2. 产品规格定义依据产品总体规划（或总体规划下的某分支产品规划）的应用功能方向进行该产品功能的详细定义。要求刻划出该产品的功能层次和每个层次下的功能项构成并详细表述每个功能项要实现或满足的功能要求的范围和深度。产品规格定义的工作结果是一棵产品功能结构树。功能树的树结构是初步的产品应用构成结构（后期需要多次迭代）；功能树的每个叶子属性是功能项的详细刻划，包括功能范围；功能逻辑；功能深度等。工作产品：（请参见模板/样例）序号工作产品名称工作产品形态责任人1产
11、品功能规格定义书Word 文件产品经理2产品功能树Xls 文件/或其他。要求树结构清晰并支持通过WBS码能实现在不同工具间树的转换。产品经理3产品验收标准Word 文件产品经理/产品总设计师4同类产品功能比较资料/横向调研资料文件包产品管理部注：产品规格定义是依据产品规划的指导进行的，目的是细化产品规划到可以实施需求获取与分析的状态，是产品研发的正式起点。产品规划是宏观的、战略的、复杂而高风险的，产品规划带有很强的预研性质，在中心研发流程中把它独立出来进行组织。产品规格定义是产品经理的核心工作，规格刻划与规格优化在这个过程中需要形成阶段内自身的迭代。 项目立项项目立项不是产品研发过程的技术控制
12、环节，它是一个中心组织过程，属于项目支持性流程环节，按立项审批管理流程处理。 研发项目的所有者的对产品研发进行立项，立项活动由产品经理负责组织实施。 立项的依据是产品研发项目立项书。立项书的本质是一种通过对项目的预估计获取项目整体性信息的几个参数，组织评估这些参数确定可行性。项目立项书必须包括的项目整体信息（定义为3个类别）：项目总规模/工作量；项目工期和物理时间阶段；进度规划项目资源需求计划清单项目成本费用估算立项的准入条件：产品规格定义技术审核通过；产品立项书完成；说明：根据公司实际研发的组织情况和公司的管理约束，在项目立项过程中不必再进行技术审核，如需求审核等。但所有立项对象涉及的相关技
13、术审核应该在产品整体规划和产品功能定义阶段组织实施。立项通过的项目，由产品经理导入中心项目部进行研发项目的开发过程。立项通过的项目才能进入正式的开发工作。工作产品：（请参见模板/样例）序号工作产品名称工作产品形态责任人1产品研发项目立项书Word 文件产品经理2项目建议书Word 文件项目管理部3项目估计清单文件包项目管理部3. 软件项目计划产品研发项目立项通过后进入项目过程，从立项通过到项目计划这个阶段是产品经理与项目经理的工作阶段性过渡，项目管理部生成项目卡是这个过渡阶段结束的标志，表明产品研发项目正式启动。软件项目启动的第一步工作是编制项目计划。按研发中心软件项目计划规范进行。软件项目计
14、划不是单纯的时间安排，而是进度、质量、资源（人和物）、过程配置等相互之间妥协优化的产物。一个理想的软件项目计划应该是项目过程各个管理域所涉及的若干全局变量统筹安排后的最优结果。软件项目计划的核心难点是软件估计与软件度量。前者是计划前期的核心工作，后者是项目过程跟踪与监控的核心工作，并且后者提供组织过程参数支持前者估计的精确性。研发中心软件项目计划在软件估计的基础上通过定义路标计划、建立PERT网络、基于WBS的任务拆分、GANTT进度进化完成。项目计划必须把自上而下制定与自下而上的修改反馈结合起来，并把分级评审贯彻始终，保证软件项目计划的完备性、合理性，任务的覆盖性，同时项目计划本身形成计划制
15、定的闭环机制。研发中心软件项目计划由项目经理负责编制，开发经理负责计划编写的技术支持。研发中心组织约束：对于项目计划阶段的组织约束包括：1.在编制软件项目计划的同时必须考虑并指定软件项目的支持计划，其中质量计划（SQAP）和配置管理计划（SCMP）是不可裁剪的核心支持计划。2.软件项目计划是一个动态的对象，必须在项目进展的不同阶段进行必要的迭代。参考软件项目计划指导书。3.软件项目计划完成后必须进行软件项目跟踪与监控计划的编制。最低约束是标识该软件项目过程中必须的跟踪路径与关键检查点。软件项目计划过程是一个复杂的管理过程，是项目成功的根本保证。请参考项目管理过程技术规范：软件项目计划指导书项目
16、计划SPP （请参见模板/样例）序号工作产品名称工作产品形态责任人1软件项目计划 SPP不限/参考模板项目经理2软件项目跟踪与监控计划 SPTO不限/参考模板项目经理3软件估计不限/参考模板项目经理4任务单不限/参考模板项目经理5进度计划不限/参考模板项目经理注：项目计划的辅助工具有很多，但适合软件项目计划属性的项目计划辅助工具迄今没有。主要表现为：现有计划工具普遍是基于物理时间进度或定义的任务科目管理为核心，缺少软件项目计划中对质量管理、配置管理、跟踪与监控、变更管理等必须环节的支持性，尤其是对开发过程数据的收集、度量和管理根本没有支持。所有这些工具充其量可以作为中心软件项目计划时间进度编制
17、或任务分配过程的辅助工具，中心最终软件项目计划的形态必须以中心模板为准！4. 需求获取与需求分析需求获取指按产品功能定义的约束进行产品实际需求的一系列调研活动以获取该产品在实际领域内的真实业务需求。需求获取的目的有两层含义：一是在实际业务应用环境中检查和检验产品功能定义刻划的正确性和准确性，更关键的是按产品的功能定义的指导通过在实际领域业务需求获取而建立需求模型。需求分析是根据项目需求报告界定的工作范围，深入细化应用业务的详细需求，描述每项业务是如何做的，业务流程、相关理论、运算公式、原理、业务数据、单据报表格式等。工作产品：（请参见模板/样例）序号工作产品名称工作产品形态责任人1软件需求规格
18、说明书（SRS）Word 文件需求分析员2软件需求树Xls 文件/或其他需求分析员3确认测试/系统测试计划书Word 文件测试经理/需求分析员4业务单据格式和单据数据项说明不限需求分析员5. 系统分析OOA根据项目需求规格说明书（SRS），对将要建立的满足用户需求的软件系统进行分析。在系统分析过程中采用面向对象分析技术（OOA）划分需求的问题域，对每一个问题域进行分析和抽象，对其中的事物和它们之间的关系产生正确的认识，找出描述问题域及其系统责任所需的类及对象，定义这些类和对象的属性与服务，以及它们之间所形成的结构、静态联系和动态联系。最终产生一个符合用户需求，并能够直接反映问题域和系统责任的面
19、向对象的分析模型。系统分析OOA的核心任务包括：划分问题域（场景脚本）抽象标识类、对象（抽象并定义的过程）刻划类层次分析表示对象连接建模对象行为工作产品：（请参见开发规范中的模板/样例）序号工作产品名称工作产品形态责任人1系统分析OOA文档WORD文档系统分析员2界面的草图文档WORD文档系统分析员3系统分析Rose文档Rose文档系统分析员注：如果采用原型法，最迟在此要建立第一个PROTOTYPE。6. 系统设计OOD根据项目需求分析和系统分析，针对软件系统具体实现中的人机界面、数据存储、任务管理等内容，运用面向对象设计技术（OOD）进行系统设计。主要包括UI设计、对象设计和数据库表设计。工
20、作产品：（请参见开发规范中的模板/样例）序号工作产品名称工作产品形态责任人1系统设计OOD文档WORD文档系统设计员2系统设计分析文档Rose文档系统设计员3CRC文档WORD文档系统设计员4界面的UI设计文档WORD文档系统设计员5数据库设计文档WORD文档系统设计员注：如果采用原型法，此处要增补第一个PROTOTYPE（继承型或抛弃型）。7. 编码实现根据系统设计的结果，运用面向对象的方法进行程序编码（OOP）以实现系统设计的内容。编码过程就是用具体的数据结构来定义对象的属性，用具体的语言来实现服务流程图所表示的算法。在对象设计阶段形成的对象类和关系最后被转换成特殊的程序设计语言、数据库或
21、者硬件的实现。工作产品：（请参见开发规范中的模板/样例）序号工作产品名称工作产品形态责任人1源代码.class文档编码人员2数据库脚本SQL 文档编码人员3程序结构及有关说明文档Java.Doc文档Word文档编码人员8. 软件集成与集成测试软件集成：通过单元测试的代码对象（物理文件）按软件设计中指定的软件集成路径进行软件集成，该工作一般要求在集成环境或配置管理工具环境中实现，是一个阶段性的Release活动。软件集成的产物是 版产品。集成测试：集成测试从根本上是在需求基线和设计基线指导下，对软件功能模块或子系统进行集成的测试，目的是验证软件设计、实现与需求是否一致的过程。本质上集成测试是对设
22、计进行验证。从中心产品规划到功能定义直至OOD有明确的层次性，同样的集成测试也有明确的层次性。OOD设计时是如何细化下去的，集成时就怎么合回来，设计是怎么个粗略程度，集成时也该这么个粗略程度。软件集成测试参考中心集成测试标准规范。工作产品：（请参见模板/样例）序号工作产品名称工作产品形态责任人1集成测试报告WORD文档测试经理2软件集成测试方案WORD文档测试经理3软件集成测试计划不限测试经理4软件集成测试用例不限测试经理9. 系统测试系统测试是在需求基线及设计基线指导下，针对软件产品系统进行的测试，其目的是验证软件设计实现与需求是否一致。系统测试总体包含功能测试和性能测试两部分。功能测试 是
23、验证软件系统功能是否实现软件系统的需求规格的测试过程；性能测试 在验证是否实现软件系统规格的基础上，进一步验证测试系统的容错性，稳定性，异常处理能力，高强度输入处理能力等软件系统性能方面的测试过程。中心系统测试由独立测试中心负责组织实施并由测试经理负责提交测试报告。工作产品：（请参见模板/样例）序号工作产品名称工作产品形态责任人1系统测试报告WORD文档测试经理2系统测试方案WORD文档测试经理3软件集成测试计划不限测试经理4软件集成测试用例不限测试经理 文档制作文档制作是伴随软件开发全过程的一个支持过程，按项目文档计划在各个阶段与开发同步实施。伴随项目开发过程应产生的文档主要包括三类：（1）
24、开发过程文档：工程文档（分析、设计、编码、测试等文档）、管理文档（项目计划、项目估计、项目跟踪与监控、软件度量等文档）、支持文档（配置管理、质量管理等）（2）用户文档：在线帮助，安装指南，使用手册，技术手册，培训教材等；（3）宣传资料：产品介绍资料，产品白皮书，产品宣传PPT，演示光盘等；开发过程文档是伴随开发过程产生的，不需要特别安排编制工作；用户文档和宣传文档由服务中心负责编写。项目中具体的文档编制要求和分布参考项目支持计划之一文档编制计划。工作产品：（请参见模板/样例）序号工作产品名称工作产品形态责任人1在线帮助Html文档产品管理组/开发人员2使用手册Word文档产品管理组/开发人员3
25、产品介绍Word文档产品管理组/开发人员4产品白皮书Word文档产品管理组5安装指南Word文档产品管理组/开发人员10. 产品版本化发布对验收通过的项目进行版本控制，整理项目版本包含的内容并版本化，发布产品发布通告。 工作产品：（请参见模板/样例）序号工作产品名称工作产品形态责任人1版本清单Word文档开发经理2产品包所有阶段交付成果开发经理3产品集成清单/集成路径清单不限开发经理 项目验收项目验收不是产品研发过程的技术控制环节，它是一个中心组织过程，按项目验收管理流程处理。项目验收的标准在产品定义阶段已经完成刻划。项目验收是研发中心项目管理与产品管理的过渡环节。标志着项目过程关闭，产品（线
26、）管理再启动。对完工的项目按照验收步骤进行验收。验收过程中对项目的情况给予评价。工作产品：（请参见模板/样例）序号工作产品名称工作产品形态责任人1验收报告Word 文件验收组2产品归档清单Xls项目管理部3产品包（至少包含版产品和产品文档）文件包验收组4测试报告/测试分析报告Word 文件测试经理11. 产品管理项目验收通过标志着产品研发项目过程的结束，回归产品管理阶段。参考产品部业务管理规范。工作产品：（请参见模板/样例）序号工作产品名称工作产品形态责任人1产品功能基线维护表不限产品管理部2产品版本控制表1（内部版本对产品集成）内部集成不限产品管理部3产品版本控制表 2（用户产品配置表）产品
27、部件外部配置不限产品管理部4用户功能基线配置表（存贮在产品配置库用户产品配置目录下；内部控制）不限产品管理部门 产品研发过程工作产品一览表小结：研发中心产品研发过程包括上述11个标准工作控制阶段，此外还包括3个组织支持过程阶段：一个隐含在开发过程的支持过程（项目文档）；两个组织管理环节：立项过程与验收过程。阶段序号工作产品名称工作产品形态责任人产品规划1产品规划总体规划设计报告技术报告Word 文件产品总规划/设计师2产品结构规划树不限产品总规划/设计师3产品可实施分析报告 不限产品总规划/设计师 等产品规格定义1产品功能规格定义书Word 文件产品经理2产品功能树Xls 文件/或其他。要求树
28、结构清晰并支持通过WBS码能实现在不同工具间树的转换。产品经理3产品验收标准Word 文件产品经理/产品总设计师4同类产品功能比较资料/横向调研资料文件包产品管理部项目立项1产品研发项目立项书Word 文件产品经理2项目建议书Word 文件项目管理部3项目估计清单文件包项目管理部软件项目计划1软件项目计划 SPP不限/参考模板项目经理2软件项目跟踪与监控计划 SPTO不限/参考模板项目经理3软件估计不限/参考模板项目经理4任务单不限/参考模板项目经理5进度计划不限/参考模板项目经理6项目卡不限/参考模板项目管理部软件需求1软件需求规格说明书（SRS）Word 文件需求分析员2软件需求树Xls 文件/或其他需求分析员3确认测试/系统测试计划书Word 文件测试经理/需求分析员4业务单据格式和单据数据项说明不限需求分析员软件分析1系统分析OOA文
