研发中心产品研发总体流程设计（框架）.doc

《研发中心产品研发总体流程设计（框架）.doc》由会员分享，可在线阅读，更多相关《研发中心产品研发总体流程设计（框架）.doc（21页珍藏版）》请在三一办公上搜索。

1、编号：PDT_F_DE 20020523 版本：V1.0 研发中心产品研发总体流程设计 （框架） 内部工作版 作 者：安及/ANJI 日 期：2002.05 北京开思软件有限公司 版权所有 违者必究 目 录 一 目的.4 二 产品研发总体流程设计的技术准则.4 三 产品研发与软件项目的关系.4 四 研发中心产品研发过程阶段划分与里程碑设置.4 1、产品研发过程标准阶段划分.4 2、面向对象的过程裁剪.5 3、过程里程碑规格约束.6 五 研发中心产品研发过程概述.6 1. 产品规划.6 2. 产品规格定义.7 项目立项.7 3. 软件项目计划.8 4. 需求获取与需求分析.9 5. 系统分析OO

2、A.9 6. 系统设计OOD.10 7. 编码实现.10 8. 软件集成与集成测试.10 9. 系统测试.11 文档制作.11 10. 产品版本化发布.12 项目验收.12 11. 产品管理.12 产品研发过程工作产品一览表.13 六 产品研发过程总流程.15 1、产品研发过程总流程.15 2、关于总流程的说明：.15 七 产品研发中的角色与责任.18 1、产品研发的组织模式.18 2、过程角色与职责.19 2.1. 产品总规划师.19 2.2. 产品经理PDM.19 2.3. 项目经理PL.20 2.4. 开发经理SDM.21 2.5. 配置管理员 CC.21 2.6. 质量保证工程师 SQ

3、A.22 2.7. 软件需求分析师SRA.22 2.8 系统分析师 OOA.23 2.9. 系统设计师 OOD.23 2.10. 程序员 OOP.24 2.11. 测试员 OOT.24 2.12. 产品管理经理 PLM.25 八 产品研发过程管理规范体系.25 1、体系构成.25 2、体系的内部结构.26 3、体系内容规划.28 3.1、研发过程总体概述.28 3.2、项目管理.28 3.3、需求管理.28 3.4、配置管理.29 3.5、质量管理.29 3.6、产品（线）管理.30 九 中心产品研发过程与SW_CMM L2各KPA的对照关系.30 - 2-研发中心核心过程分类表 注：该表在后

4、期研发中心标准研发过程（即本文）维护中使用。维护分类遵循软件生存周期模型（ISO/IEC12207）分类，以支持中心后期面向软件过程改进的优化调整和面向SW_CMM/CMMI的实施。 属性 软件生存周期过程 责任职能部门/组 协作职能部门/组备 注 主要生存周期 支持生存周期 组织生存周期 统计 - 3- 一 目的 本规范是研发中心一级业务流程标准，旨在抽象刻划并规范研发中心产品研/开发工作的全生命周期过程。包括建立并规范产品开发工作流程（包含一些特殊业务的流程），划分开发工作标准过程阶段/里程碑，明确各阶段关键活动、参与人员及相互关系，明确各阶段工作的成果要求，明确中心业务部门间工作接口关系

5、等。 二 产品研发总体流程设计的技术准则 1. 中心产品研发流程规范应该从根本上满足软件产品线管理、软件项目管理及软件工程若干管理分支的基本要求（并能从根本上符合SWCMM二级的要求）； 2. 流程规范是结合中心现有开发过程中软件开发各过程管理作用域实际表现的强势与弱势，并有针对性的按组织统一规划的过程改进逐步建立、完善、实施、以期提升产品研发过程管理水平； 3. 流程规范从根本上把产品研发过程中各种关键活动和需求管理、项目计划、项目跟踪和监控、配置管理、质量保证活动的要求紧密结合起来；目标是真正建立起研发中心产品研发全生命周期的稳定过程结构。 4. 规范中的各种要求在流程设计上都应可以体现在

6、计划、项目进度监控和质量监控的文档中，并支持软件过程的度量，积累组织关键数据； 5. 本体系规范应为培训、查询、使用以及推行检查提供支持和方便。 三 产品研发与软件项目的关系 公司产品研发遵从统一规划分步实施的原则。每个待研发的产品对象的具体开发过程都采用软件项目的机制进行组织实施和内部约束。 此外，研发中心接受的其他各种开发任务也以项目形式出现，包括：产品维护（错误修改、功能增强、缺陷完善等），产品客户化开发及维护等。 软件项目全生命周期管理贯穿于每一个分支产品的研发过程。同时整体产品（TEEMS）研发对象的管理在产品管理领域采用软件产品线工程管理。二者理论基础如下： ? 产品管理：软件产品

7、线管理；SW_CMM； ? 项目管理：软件工程；软件项目管理SE_CMM； ? 共用基础：软件配置管理；软件质量管理；软件变更控制；需求管理； 关于项目规模的中心约束： 根据项目规模和难易，中心每个项目的规模控制在60人月以内完成，项目周期控制在6个月以内。超过上述规模约束的软件项目需要拆分成多个小的项目组织实施。 一般的30人月以上的项目称为大项目，10个人月以内的项目称为小项目。 四 研发中心产品研发过程阶段划分与里程碑设置 1、产品研发过程标准阶段划分 研发中心产品研发过程划分为11个标准阶段，同步设立9个技术评审点，2个组织管理环节（研发立项、产品验收）。 11个标准阶段构成研发中心标

8、准软件生命周期过程模型，是研发中心企业一级技术流程约束。 - 4- 产品规划规格软件项目软件设计产品软件需求软件分析计划阶段阶段阶段制定阶段阶段阶段 评估点评估点评估12评估点点4评估点评估点635 编码单元软件集成软件系统产品定版进入产品 测试阶段集成测试测试阶段与发布管理阶段 评估点评估点97评估点8 图1：研发中心产品研发标准过程阶段划分 2、面向对象的过程裁剪 研发中心标准软件过程生存周期模型在具体的某一个项目中可以依据项目的具体属性进行必要的裁剪。以下给出关于中心产品研发标准周期模型中阶段在项目中的适用说明。 1) 原则上研发中心任何一个产品/构件的开发过程都必须经历上述11个技术控

9、制阶段。在实际项目开发组织时可以根据待研发产品的规模、复杂程度、风险要求酌情裁剪开发过程阶段形成面向项目对象的快速开发过程模型（RAD）。 2) 关于生命周期过程模型的裁减执行人：项目经理是实际项目生命周期选择和裁减的执行人。 需要说明两个问题：一是开发过程中充当该项目的质量保证工程师有责任和义务对项目经理过程模型的选择和裁减提供技术支持和必要的评审，过程周期模型的合理性直接关系到软件开发过程的关键路径，是成本基线、质量基线的基础，必须予以充分的重视；此外在当前中心尚未建立独立的SEPG 时过程模型的裁剪需要得到中心技术主管负责人的审核，过程模型是项目战略层次的规划。 3) 关于项目过程模型适

10、用性裁剪的准则。目前尚未建立中心过程模型裁剪的技术控制标准，项目经理和其他人员可以先行参考 软件能力成熟度模型过程裁减指南 。 4) 裁剪的原则约束：无论项目对象、项目属性，在面向适用对象的裁剪时不可裁减的两个关键阶段是：需求、设计。中心组织性原则约束，需求必须进行评审并建立基线化管理，以确保需求在项目全周期的变更受到有效的控制和管理；设计必须评审，以确保在实际软件建立（OOP）的过程中所潜在遵循的设计模型不存在关键设计质量差异。 - 5-3、过程里程碑规格约束 序号 阶段名称 阶段属性 是否包含里程碑/里程碑规格 1 产品规划阶段 产品（线）? 里程碑：产品规划评审 管理过程 ? 规格约束：

11、 暂不定义。 2 产品规格定义阶段 ? 里程碑：产品规格定义评审 ? 规格约束： 暂不定义。 3 软件需求阶段 ? 里程碑：需求评审 ? 规格约束： 暂不定义。 4 软件项目计划阶段 ? 里程碑：项目计划评审 ? 规格约束： 暂不定义。 5 软件分析阶段 ? 里程碑：OOA评审 ? 规格约束： 暂不定义。 6 软件设计阶段 ? 里程碑：OOD评审 项目管理? 规格约束： 过程 暂不定义。 7 编码与单元测试阶段 无 8 集成测试阶段 ? 里程碑：软件集成与集成测试评审 ? 规格约束： 暂不定义。 9 系统测试阶段 ? 里程碑：系统测试评审 ? 规格约束： 暂不定义。 10 产品发布阶段 ? 里

12、程碑：验收评审 ? 规格约束： 暂不定义。 11 产品管理阶段 产品线 无 说明：里程碑的规格暂不能详细刻划，后期补充该工作。 五 研发中心产品研发过程概述 1. 产品规划 是产品战略级规划：主要包括产品的商业目标规划；产品的应用构成（功能族）结构规划；技术研究方向规划等。 关键活动包括： ? 目标市场规划：确定产品的目标市场；结合本产品规划对目标市场的未来进行预测与分析（一般要求基于行业调研的统计报告和分析报告）； ? 功能规划：定义产品的功能范围；全面规划产品的功能方向（满足业务需求的功能领域）；产品的功能结构构成；划分产品和子产品的功能边界；产品功 - 6-能结构的优化； ? 产品竞争性

13、规划：同业产品的查新；相似产品的比较研究；规划产品的竞争特性分析与比较分析等； ? 产品满足企业商业目标的规划：产品在组织内可实施性的分析。要求做产品整体级研发估计（核心是费用、资源与进度）；产品产出效益分析/回报分析等可参考商业计划书过程； ? 产品的技术指标要求：产品性能规划；初步定义产品验收标准。 ? 产品规划的组织约束：定义产品实施过程中的各类别组织约束（进度的、成本的、资源的、质量的、特性的等）。 ? 规划优化活动（包括开发对象优先级分析） 工作产品：（请参见模板/样例） 序号 工作产品名称 工作产品形态 责任人 1 产品规划总体规划设计报告技术报告Word 文件 产品总规划/设计师

14、 2 产品结构规划树 不限 产品总规划/设计师 3 产品可实施分析报告 不限 产品总规划/设计师 等 2. 产品?娓穸?依据产品总体规划（或总体规划下的某分支产品规划）的应用功能方向进行该产品功能的详细定义。要求刻划出该产品的功能层次和每个层次下的功能项构成并详细表述每个功能项要实现或满足的功能要求的范围和深度。 产品规格定义的工作结果是一棵产品功能结构树。功能树的树结构是初步的产品应用构成结构（后期需要多次迭代）；功能树的每个叶子属性是功能项的详细刻划，包括功能范围；功能逻辑；功能深度等。 工作产品：（请参见模板/样例） 序号 工作产品名称 工作产品形态 责任人 1 产品功能规格定义书Wor

15、d 文件 产品经理 2 产品功能树 Xls文件/或其他。 产品经理 要求树结构清晰并支持通过WBS码能实现在不同工具间树的转换。 3 产品验收标准 Word文件 产品经理/产品总设计师 4 同类产品功能比较资料/横向调研资料 文件包 产品管理部 注： 产品规格定义是依据产品规划的指导进行的，目的是细化产品规划到可以实施需求获取与分析的状态，是产品研发的正式起点。产品规划是宏观的、战略的、复杂而高风险的，产品规划带有很强的预研性质，在中心研发流程中把它独立出来进行组织。产品规格定义是产品经理的核心工作，规格刻划与规格优化在这个过程中需要形成阶段内自身的迭代。 项目立项 项目立项不是产品研发过程的

16、技术控制环节，它是一个中心组织过程，属于项目支持性流程环节，按立项审批管理流程处理。 研发项目的所有者的对产品研发进行立项，立项活动由产品经理负责组织实施。 - 7- 立项的依据是产品研发项目立项书。立项书的本质是一种通过对项目的预估计获取项目整体性信息的几个参数，组织评估这些参数确定可行性。 项目立项书必须包括的项目整体信息（定义为3个类别）： ? 项目总规模/工作量；项目工期和物理时间阶段；进度规划 ? 项目资源需求计划清单 ? 项目成本费用估算 立项的准入条件： ? 产品规格定义技术审核通过； ? 产品立项书完成； 说明： 根据公司实际研发的组织情况和公司的管理约束，在项目立项过程中不必

17、再进行技术审核，如需求审核等。但所有立项对象涉及的相关技术审核应该在产品整体规划和产品功能定义阶段组织实施。 立项通过的项目，由产品经理导入中心项目部进行研发项目的开发过程。 批注 anji1: 以内部合同/立项通过的项目才能进入正式的开发工作。 和约或者其他什么约束传工作产品：（请参见模板/样例） 递？其实这个过程相当于序号 工作产品名称 工作产品形态 责任人 项目分包。 1 产品研发项目立项书Word 文件 产品经理 2 项目建议书 Word文件 项目管理部 3 项目估计清单 文件包 项目管理部 3. 软件项目计划 批注 anji2: 当前研发中产品研发项目立项通过后进入项目过程，从立项通

18、过到项目计划这个阶段是产品心软件项目计划的编制阶经理与项目经理的工作阶段性过渡，项目管理部生成项目卡是这个过渡阶段结束的标段是在软件需求完成后进志，表明产品研发项目正式启动。 行的。项目计划不包括需求软件项目启动的第一步工作是编制项目计划。按研发中心软件项目计划规范进行。 阶段的工作；后期项目计划软件项目计划不是单纯的时间安排，而是进度、质量、资源（人和物）、过程配置前置到软件需求前，软件需等相互之间妥协优化的产物。一个理想的软件项目计划应该是项目过程各个管理域所求纳入计划管理。建议这个涉及的若干全局变量统筹安排后的最优结果。 过渡首先经历一两个中心软件项目计划的核心难点是软件估计与软件度量。

19、前者是计划前期的核心工作，项目过程数据的积累。 后者是项目过程跟踪与监控的核心工作，并且后者提供组织过程参数支持前者估计的精确性。 研发中心软件项目计划在软件估计的基础上通过定义路标计划、建立PERT网络、基于WBS的任务拆分、GANTT进度进化完成。项目计划必须把自上而下制定与自下而上的修改反馈结合起来，并把分级评审贯彻始终，保证软件项目计划的完备性、合理性，任务的覆盖性，同时项目计划本身形成计划制定的闭环机制。 研发中心软件项目计划由项目经理负责编制，开发经理负责计划编写的技术支持。 研发中心组织约束： 对于项目计划阶段的组织约束包括： 1.在编制软件项目计划的同时必须考虑并指定软件项目的

20、支持计划，其中质量计划 - 8-（SQAP）和配置管理计划（SCMP）是不可裁剪的核心支持计划。 2.软件项目计划是一个动态的对象，必须在项目进展的不同阶段进行必要的迭代。参考软件项目计划指导书。 3.软件项目计划完成后必须进行软件项目跟踪与监控计划的编制。最低约束是标识该软件项目过程中必须的跟踪路径与关键检查点。 软件项目计划过程是一个复杂的管理过程，是项目成功的根本保证。请参考项目管理过程技术?娣叮骸度砑钅考苹傅际椤?项目计划SPP （请参见模板/样例） 序号 工作产品名称 工作产品形态 责任人 1 软件项目计划 SPP 不限/参考模板 项目经理 2 软件项目跟踪与监控计划 SPTO 不限

21、/参考模板 项目经理 3 软件估计 不限/参考模板 项目经理 4 任务单 不限/参考模板 项目经理 5 进度计划 不限/参考模板 项目经理 注： 项目计划的辅助工具有很多，但适合软件项目计划属性的项目计划辅助工具迄今没有。 主要表现为：现有计划工具普遍是基于物理时间进度或定义的任务科目管理为核心，缺少软件项目计划中对质量管理、配置管理、跟踪与监控、变更管理等必须环节的支持性，尤其是对开发过程数据的收集、度量和管理根本没有支持。所有这些工具充其量可以作为中心软件项目计划时间进度编制或任务分配过程的辅助工具，中心最终软件项目计划的形态必须以中心模板为准！ 4. 需求获取与需求分析 需求获取指按产品

22、功能定义的约束进行产品实际需求的一系列调研活动以获取该产品在实际领域内的真实业务需求。需求获取的目的有两层含义：一是在实际业务应用环境中检查和检验产品功能定义刻划的正确性和准确性，更关键的是按产品的功能定义的指导通过在实际领域业务需求获取而建立需求模型。 需求分析是根据项目需求报告界定的工作范围，深入细化应用业务的详细需求，描述每项业务是如何做的，业务流程、相关理论、运算公式、原理、业务数据、单据报表格式等。 工作产品：（请参见模板/样例） 序号 工作产品名称 工作产品形态 责任人 1 软件需求规格说明书（SRS）Word 文件 需求分析员 2 软件需求树 Xls文件/或其他 需求分析员 3

23、确认测试/系统测试计划书 Word 文件 测试经理/需求分析员 4 业务单据格式和单据数据项说明 不限 需求分析员 5. 系统分析OOA 根据项目需求规格说明书（SRS），对将要建立的满足用户需求的软件系统进行分析。 在系统分析过程中采用面向对象分析技术（OOA）划分需求的问题域，对每一个问题域进行分析和抽象，对其中的事物和它们之间的关系产生正确的认识，找出描述问题域及其系统责任所需的类及对象，定义这些类和对象的属性与服务，以及它们之间所形成的结构、静态联系和动态联系。最终产生一个符合用户需求，并能够直接反映 - 9-问题域和系统责任的面向对象的分析模型。 系统分析OOA的核心任务包括： ?

24、划分问题域（场景脚本） ? 抽象标识类、对象（抽象并定义的过程） ? 刻划类层次 ? 分析表示对象连接 ? 建模对象行为 工作产品：（请参见开发规范中的模板/样例） 序号 工作产品名称 工作产品形态 责任人 1 系统分析OOA文档WORD文档 系统分析员 2 界面的草图文档 WORD文档 系统分析员 3 系统分析Rose文档Rose文档 系统分析员 注： 如果采用原型法，最迟在此要建立第一个PROTOTYPE。 6. 系统设计OOD 根据项目需求分析和系统分析，针对软件系统具体实现中的人机界面、数据存储、任务管理等内容，运用面向对象设计技术（OOD）进行系统设计。 主要包括UI设计、对象设计和

25、数据库表设计。 工作产品：（请参见开发规范中的模板/样例） 序号 工作产品名称 工作产品形态 责任人 1 系统设计OOD文档WORD文档 系统设计员 2 系统设计分析文档 Rose文档 系统设计员 3 CRC文档WORD文档 系统设计员 4 界面的UI设计文档 WORD文档 系统设计员 5 数据库设计文档WORD文档 系统设计员 注： 如果采用原型法，此处要增补第一个PROTOTYPE（继承型或抛弃型）。 7. 编码实现 根据系统设计的结果，运用面向对象的方法进行程序编码（OOP）以实现系统设计的内容。 编码过程就是用具体的数据结构来定义对象的属性，用具体的语言来实现服务流程图所表示的算法。在

26、对象设计阶段形成的对象类和关系最后被转换成特殊的程序设计语言、数据库或者硬件的实现。 工作产品：（请参见开发规范中的模板/样例） 序号 工作产品名称 工作产品形态 责任人 1 源代码 .class文档 编码人员 2 数据库脚本SQL文档 编码人员 3 程序结构及有关说明文档 Java.Doc文档 编码人员 Word文档 8. 软件集成与集成测试 软件集成： 通过单元测试的代码对象（物理文件）按软件设计中指定的软件集成路径进行软 - 10-件集成，该工作一般要求在集成环境或配置管理工具环境中实现，是一个阶段性的Release活动。软件集成的产物是 版产品。 集成测试： 集成测试从根本上是在需求基

27、线和设计基线指导下，对软件功能模块或子系统进行集成的测试，目的是验证软件设计、实现与需求是否一致的过程。 本质上集成测试是对设计进行验证。从中心产品规划到功能定义直至OOD有明确的层次性，同样的集成测试也有明确的层次性。OOD设计时是如何细化下去的，集成时就怎么合回来，设计是怎么个粗略程度，集成时也该这么个粗略程度。 软件集成测试参考中心集成测试标准规范。 工作产品：（请参见模板/样例） 序号 工作产品名称 工作产品形态 责任人 1 集成测试报告 WORD文档 测试经理 2 软件集成测试方案WORD文档 测试经理 3 软件集成测试计划 不限 测试经理 4 软件集成测试用例 不限 测试经理 9.

28、 系统测试 系统测试是在需求基线及设计基线指导下，针对软件产品系统进行的测试，其目的是验证软件设计实现与需求是否一致。系统测试总体包含功能测试和性能测试两部分。功能测试 是验证软件系统功能是否实现软件系统的需求规格的测试过程；性能测试 在验证是否实现软件系统规格的基础上，进一步验证测试系统的容错性，稳定性，异常处理能力，高强度输入处理能力等软件系统性能方面的测试过程。 中心系统测试由独立测试中心负责组织实施并由测试经理负责提交测试报告。 工作产品：（请参见模板/样例） 序号 工作产品名称 工作产品形态 责任人 1 系统测试报告 WORD文档 测试经理 2 系统测试方案WORD文档 测试经理 3

29、 软件集成测试计划 不限 测试经理 4 软件集成测试用例 不限 测试经理 文档制作 文档制作是伴随软件开发全过程的一个支持过程，按项目文档计划在各个阶段与开发同步实施。 伴随项目开发过程应产生的文档主要包括三类： （1）开发过程文档：工程文档（分析、设计、编码、测试等文档）、管理文档（项目计划、项目估计、项目跟踪与监控、软件度量等文档）、支持文档（配置管理、质量管理等） （2）用户文档：在线帮助，安装指南，使用手册，技术手册，培训教材等； （3）宣传资料：产品介绍资料，产品白皮书，产品宣传PPT，演示光盘等； 开发过程文档是伴随开发过程产生的，不需要特别安排编制工作；用户文档和宣传文档由服务中

30、心负责编写。 项目中具体的文档编制要求和分布参考项目支持计划之一文档编制计划。 工作产品：（请参见模板/样例） - 11-序号 工作产品名称 工作产品形态 责任人 1 在线帮助 Html文档 产品管理组/开发人员 2 使用手册Word文档 产品管理组/开发人员 3 产品介绍Word文档 产品管理组/开发人员 4 产品白皮书 Word文档 产品管理组 5 安装指南Word文档 产品管理组/开发人员 10. 产品版本化发布 对验收通过的项目进行版本控制，整理项目版本包含的内容并版本化，发布产品发布通告。 工作产品：（请参见模板/样例） 序号 工作产品名称 工作产品形态 责任人 1 版本清单 Word文档 开发经理 2 产品包 所有阶段交付成果 开发经理 3 产品集成清单/集成路径清单 不限 开发经理 项目验收 项目验收不是产品研发过程的技术控制环节，它是一个中心组