2023年软件过程管理指南.doc

软件过程管理指南 软件过程管理指南 Software Process Manage Guide 文档标识： 上海易宝软件深圳分公司 修订记录 版本 说明 作者 批准 批准日期 V1.0 第一次发布 曾奋瑞 Marco 2023-03-01 目 录 软件过程管理指南 1 1 序言 8 1.1 简介 8 1.2 目标 8 1.3 适用范围 8 1.4 术语 8 2 文件清单 9 2.1 软件项目筹划PP 9 2.2 软件项目跟踪与监督PTO 9 2.3 需求管理RM 10 2.4 软件生命周期LC 10 2.5 软件质量保证SQA 12 3 项目过程 12 4 组间协作 15 5 关键实践集 15 5.1 项目准备 16 5.2 软件估计 16 5.3 启动会议 16 5.4 迭代开发 17 5.5 设计界面雏形与用例说明 17 5.6 特征跟踪 19 5.7 设计领域模型 19 5.8 详细设计 19 5.9 使用项目工作管理系统 20 5.10 里程碑会议 21 5.11 风险清单 22 5.12 技术评审 22 5.13 建立配置库 24 5.14 变更控制 25 5.15 组件重用 26 5.16 持续集成 27 5.17 单元测试 27 5.18 启动测试流程 28 5.19 缺陷管理 28 5.20 系统发布 31 5.21 实施管理 32 5.21.1 实施型项目月方案 32 5.21.2 实施型项目月报 33 5.21.3 系统发布说明 33 5.22 产品与项目管理 33 5.23 客户问题管理 34 5.24 软件质量保证 34 6 图表索引 37 7 引用的过程及规程文件列表 37 1 序言 1.1 简介 上海易宝软件深圳分公司的各级管理人员和各个开发组都认识到，只有通过不断的过程改良才能使我们人员的能力和先进的技术得到充分的发挥。因此，公司决定采用软件能力成熟度模型〔CMMI3 〕这一标准来提高软件组织的工作效率、产品质量和项目的可预见性。 为了使公司所有项目组都使用统一的过程和文档，得到的文档和实践集合将被所有大小项目组共同使用。这些文档和实践集合同时也是项目执行绩效考核的指标。 1.2 目标 1、 确定软件开发过程中最根本的文档模板和实践 2、 统一项目组的过程管理 3、 项目执行绩效考核的指标 4、 公司顺利推行CMMI3 1.3 适用范围 公司所有项目组的软件产品开发过程管理要求符合本手册的要求。 1.4 术语 PP：Project Plan项目筹划 PTO：Project Tracing and Oversight项目跟踪与监督 RM：Requirement Management需求管理 SQA：Software Quality Assurance软件质量保证 SCM：Software Configuration Management软件配置管理 LC：Life Cycle生命周期 SCCB：Software Change Control Board软件变更控制委员会 NC：NonCompliance不符合问题 2 文件清单 下面列出经过过程裁减后的文件最小集合，文件的使用方法请参见模板。 2.1 软件项目筹划PP 以下文件路径为： ://192.168.0.20 序号 文件名称/文档标识 文档类型 使用频率 备注 1. 软件开发方案/ 软件工作产品 一个 需要正规技术评审 需要上传到项目工作管理系统 2. 项目估算表 软件工作产品 一个 需要正规技术评审 需要上传到项目工作管理系统 3. 软件主进度方案/ 软件工作产品 一个 使用项目工作管理系统，有必要可以导出。需要正规技术评审 需要上传到项目工作管理系统 4. 迭代进度方案/ 软件工作产品 每个迭代周期一个本周期的进度方案 使用项目工作管理系统，有必要可以导出 2.2 软件项目跟踪与监督PTO 以下文件路径为：序号 文件名称/文档标识 文档类型 使用频率 备注 1. 启动会议纪要 软件工作产品 每阶段一个 需要上传到项目工管理系统 2. 周例会纪要/ 软件工作产品 每周一个 需要上传到项目工作管理系统 3. 风险状态跟踪表/ 软件工作产品 一个 初始评估或者风险影响及状态等发生变化时填写 4. 项目工作总结/ 软件工作产品 项目结束时每人一个 需要上传到项目工作管理系统 5. 里程碑工作总结/ 软件工作产品 每个里程碑一个 需要上传到项目工作管理系统 6. 项目管理度量报告 软件工作产品 每个里程碑一个 需要上传到项目工作管理系统 2.3 需求管理RM 以下文件路径为：序号 文件名称/文档标识 文档类型 使用频率 备注 1. 特征状态跟踪表/ 软件工作产品 一个 每迭代周期更新。可以使用CaliberRM导出符合格式的文档 2.4 软件生命周期LC 以下文件路径为：序号 文件名称/文档标识 文档类型 使用频率 备注 1. 工作任务书/ 软件产品 一个 需要正规技术评审 需要上传到项目工作管理系统 2. 需求规格说明书/ 软件产品 一个 需求规格说明书(SRS)包括：需求项与特征、PowerPoint演示文档、界面雏形(只需要增加原产品中没有的局部)、用例说明。其中对界面雏形变更修改不作要求。需要正规技术评审 3. 领域模型文件 软件工作产品 一个 ROSE的mdl文件，术语表文件 需要正规技术评审 产品模式不需要 新开发项目需要 4. 数据库设计文件(cdm文件) 软件工作产品 一个 有选择值的字段必须加上说明。需要正规技术评审 5. 概要设计说明书/ 软件产品 一个 需要正规技术评审 6. 详细设计说明书/ 软件产品 多个 1个模块或几个模块1份。需要走查 7. 用户手册/ 软件产品 一个 在线帮助，使用帮助文档工具编写，例如robohelp。需要走查 8. 部署说明书/ 软件产品 一个 9. 单元测试记录表/ 软件工作产品 一个 10. 系统测试用例/ 软件工作产品 一个 保存在TD中，项目结束时导出到文档放入项目组的配置库。需要走查 11. 系统测试总结报告/ 软件工作产品 每个里程碑一个 12. 系统测试任务单/ 软件工作产品 每次提交到测试组测试时一个 填写纸质文件 13. 技术评审报告/ 软件工作产品 每次评审一个 14. 系统发布操作手册 软件工作产品 一个 包含多个系统的发布操作说明，和单个系统的发布说明，写明重要的检查内容 15. 系统发布说明 软件工作产品 每次向客户发布时一个 填写电子文件，打印纸质签字 2.5 软件质量保证SQA 以下文件路径为：序号 文件名称/文档标识 文档类型 使用频率 备注 1. SQA进度方案/ 软件工作产品 一个 走查 2. SQA报告/ 软件工作产品 每月一个 每周更新 3. 项目阶段质量检查表/ 软件工作产品 每个里程碑一个，项目结束时一个 4. SQA质量报告/ 软件工作产品 每里程碑及项目结束时一个 3 项目过程 文档必须和过程结合在一起，才能发挥作用。我们可以将项目过程及文档分为技术和管理两个局部。以下列图描述在软件工程和项目管理的各个步骤文档的输出。 软件工程的文档输出 项目管理的文档输出 4 组间协作 A.软件项目内各组之间〔如QA组，CM组，测试组，开发组等〕的交流、协调工作由项目经理负责，一般采取项目会议的形式。任何组如果有方案上的变更，需要通过会议、进度报告和内部邮件的方式与各相关组进行约定。 B.需与项目外其它组进行的协作，那么通过PM或高层经理完成，协调工作的进展与结果可通过会议、进度报告和内部邮件的方式与各相关组进行沟通。 C.与客户联络工作由客户交流窗口和项目经理〔可为同一人〕共同负责，必要时，高层经理也会适当参与。如果有方案上的变更，需要通过会议、进度报告和内部邮件的方式与各相关组进行协商。 5 关键实践集 这些关键实践来自于经典软件工程和CMMI的实践方法和经验总结。无论项目组大小，项目采取何种生命周期，项目实施周期长短，熟练运用这些实践可以起到很好的效果，例如缩短原定进度，改善过程可视性，降低项目风险等。因此这些关键实践是每个项目都必须执行的。 5.1 项目准备 项目准备阶段，项目经理与需求分析人员进行初步的需求调研，整理客户需求形成工作任务书，并根据工作任务书制定项目方案(包括软件开发方案、软件主进度方案、软件项目估计)，软件开发方案中必须指明需求规格说明书、概要设计说明书的评审时间。列出初始评估的风险状态跟踪表。工作任务书、项目方案评审通过，配置库和TD库建立之后正式进入第一个迭代周期。 5.2 软件估计 通过功能点估计法可以估算出一个产品的规模。在项目筹划初期，根据需求估计出功能点数，由公司的生产率〔功能点数/人月〕，可以得出完成系统所需的工作量，作为人力资源安排的参考。在需求项有变化时也应更新估计。 理解客户需求最好的方法是站在客户的角度分析软件系统产生的结果，从而来确定客户关心的问题。功能点分析的一个主要的目标就是从用户的角度定义系统的能力。从用户的观点来看，系统是从五个根本方面帮助他们进行工作的： 内部逻辑文件、外部接口文件、外部输入、外部输出、外部查询 除了以上五个方面，功能点分析中还要考虑分布式数据处理、在线更新等14项复杂度的调整。 功能点估计的模板参见配置库：＼软件过程管理指南(适用于公司所有项目)＼pp＼template＼软件项目估计模板(comtop-pp-tmp-est).xls。 5.3 启动会议 启动会议(包括阶段启动会议)的参与人员有：研发中心经理、项目部经理、技术研究部经理、项目经理、软件工程组〔包括分析设计、开发、测试、配置管理工程师〕、质量保证工程师、文档支持组等。 会前的准备工作：确定项目经理，挑选适宜的人员参加软件工程组，确定项目需要的资源和支持，包括人力资源，设备，工具，文档支持，技术研究部的支持，设备采购的支持等。 启动会议的主要内容：介绍项目背景，目标，范围以及项目的风险；正式任命项目经理；确定项目的组织结构和人员的角色职责；采用头脑风暴法进行团队建设活动，为团队命名，口号，行动纲领，队徽。 5.4 迭代开发 经过几十年的开展，软件工程领域出现了很多种软件生命周期模型，有瀑布型，迭代型，增量型等等。瀑布模型来源于建筑行业、制造行业等可预测的生产，本来就无法适应需求不稳定的软件项目。因此许多项目尽管在一开始就规定采用瀑布型，却在实践中慢慢变成了迭代型。迭代是一个能够产生内部版本的袖珍项目－或多或少要经历所有的核心工作流。通过循环反复的活动和原那么使产生的结果越来越接近期望的结果。 迭代型的开发进度方案可以分为两个层次，第一个层次是总体的方案(主进度方案)，可能历时几年或者几个月，为团队的工作指出了方向。在总体进度方案中主要关注里程碑，每个里程碑要完成的目标或者需求项(可以包括特征)。总体方案划分整个项目的工作到各个迭代周期中，并不关注执行细节，时间跨度较大可能会因为需求的变化而修订。总体方案要确定迭代周期多长，一般为2-3周。第二个层次是短期的详细方案，即各个迭代周期的方案，关注执行细节，将具体的任务落实到人，并且由于时间跨度小相对稳定，可以确定本迭代周期完成时的详细交付物。每次迭代，我们只需要制定当前迭代周期的方案即可，到了迭代的后期才能确定什么需要在下个周期内完成的事情。进度方案中必须包含项目管理的工作，如编写文档、评审、代码走查、周例会等。 总体方案中，2-3个迭代周期要定义一个里程碑。 作为迭代周期完成的标志，每个迭代周期完成后要开会总结，评估迭代的交付物，明确下一个迭代周期的任务。 5.5 设计界面雏形与用例说明 对于产品型的项目，产品中已有的局部不需要编写界面雏形，只需要对产品中没有