简介ISO/IEC/IEEE 24748-3:2020是面向系统与软件工程领域的重要国际标准专为应用ISO/IEC/IEEE 12207软件生命周期过程提供系统化指南。这份75页英文电子版适合软件工程师、项目经理、质量与风险管理及系统工程相关从业者可帮助解决生命周期流程落地、过程改进与合规实施等实际问题。压缩包内含1个PDF文件共2.13MB便于离线查阅与学习。已有174人浏览学习。标准内容涵盖范围、规范性引用文件、术语与缩略语、软件系统概念、过程与生命周期概念并给出应用指南、实施建议、质量与风险管理及组织人员职责等模块。通过遵循其中框架组织可对标国际最佳实践提升软件产品质量与项目可控性。这份PDF为完整电子版页码齐全适合作为标准研读、内部培训或项目管理参考。1. ISO/IEC/IEEE 24748-3它不是又一本过程手册而是12207真正能跑起来的使用说明ISO/IEC/IEEE 24748-3:2020 的完整名字很长长到让人以为是又一本过程手册。但真正做过程改进的人拿到这份75页的英文电子版会发现它回答的是另一个问题ISO/IEC/IEEE 12207 已经把软件生命周期过程定义到了任务级为什么项目组照抄下来还是跑不动24748-3 的价值就在这——它是软件生命周期过程标准的使用说明书。它不新增过程而是告诉你如何选过程、如何裁剪、如何把标准里的活动映射到实际项目的阶段、产物和角色上。对过程改进工程师、软件质量经理和正在给团队补过程短板的项目经理这份指南解决的就是从标准文本到项目计划之间最后那段路。2. 先看懂12207的粒度过程、活动、任务三层结构与四类过程组2.1 从software life cycle processes出发过程和流程不是一回事ISO/IEC/IEEE 24748-3 标题里的 System and software engineering 不是随便挂的名头它和 12207 一样同时覆盖系统与软件两个视角。想用好这份指南第一件事是纠正一个普遍误读12207 定义的是过程process不是流程flow。流程强调顺序输入输出串成一条线上个环节不完成下个环节就不开始。过程强调的是能力是一组为达成特定结果而协同的活动集合活动之间可以有并行、有迭代、有先后但最终目的是产出某个确定的结果。12207 把每个过程的用途、预期结果、活动和任务都做了标准化描述这套描述换到哪个行业、哪个规模的项目都能讲通。24748-3 开篇就在纠正这个误读应用 12207 第一步不是去找模板流程图而是识别你的项目需要哪些过程的能力。判断一个项目是否真的在用 12207也不是看文档里有没有阶段评审这些词汇而是看过程的目的和结果是否达成。2.2 四类过程组的划分与用途12207 把三十多个软件生命周期过程分成四类这四类划分直接决定了 24748-3 后面所有应用指南的组织方式。过程组典型过程在项目中的角色协议过程获取、供应界定甲方乙方权利边界管理采购与外包组织项目使能过程生命周期模型管理、基础设施管理、组合管理、人力资源管理、质量管理项目背后的组织常备能力不随项目结束而消失技术管理过程项目计划、评估与控制、决策管理、风险管理、配置管理、信息管理、测量、质量保证项目的控制面管资源、基线、风险与质量证据技术过程业务或任务分析、利益相关方需求定义、软件需求定义、架构定义、设计定义、实现、集成、验证、确认、运行、维护、处置直接产出软件产品的链路这张表是我做过程改进时最常用的起点。实际项目中协议过程先回答项目边界在哪技术过程回答产品怎么造出来技术管理过程回答怎么保证造出来的东西不失控使能过程回答组织给了什么基础设施。一个项目计划如果连这四类过程都对应不上后面所有活动安排都会飘。2.3 活动和任务过程真正被执行的粒度12207 每个过程都有一个固定的描述模板目的purpose、结果outcomes、活动activities活动再拆到任务tasks。24748-3 的使用建议很直接——先看目的和结果再倒推需要哪些活动和任务而不是反过来逐条执行。拿配置管理举例。它的目的是建立并维护产品和工作产品的完整性。结果有四条配置项有唯一标识、变更受控、配置状态可查询、定期的配置审计能发现偏差。落到项目里这些结果对应的事就是配置标识、配置控制、配置状态记录和配置审计。一个小团队做配置管理可以简化到版本库里的分支策略和发布标签但标识-控制-状态记录-审计四个结果一个都不能少。没有这四样线上事故发生时找不到对应版本和源码就是过程缺失不是工具问题。这个例子我常用来说明任务可以裁剪结果不能被裁剪。2.4 为什么24748-3反复强调组织层与项目层的对接12207 的过程天然分两层使能过程通常在组织层定义项目层过来借用技术过程和技术管理过程在项目层执行。24748-3 针对这个接口给出了大量具体建议。最常见的做法是项目计划里不再重复写基础设施、人力资源这些使能过程怎么做而是写引用组织已发布的过程资产并标注版本。这样能省掉大量重复文档。反过来说组织层如果没有沉淀这些资产每个项目都自建一套那过程改进永远只能是项目级而不是组织级换一个项目经理就推倒重来一次。Life cycle management 在这个语境里讲的不是做资产台账而是把项目从立项到退役的每一个阶段管住状态、管住基线、管住评审结论。这一层想清楚了后面做裁剪声明时才不会把组织能力和项目活动混成一锅粥。3. 用24748-3把12207落到项目计划阶段、门禁与责任映射3.1 先建生命周期模型阶段和门禁怎么设很多团队拿到 12207 第一反应是我们先把过程清单列出来这是错的。24748-3 给出的顺序是先建生命周期模型再选过程。阶段stage是时间轴上的大格子每个阶段有明确目的和退出准则exit criteria退出准则通过门禁评审来验证。软件项目常见做法是把完整生命周期压成四到五个阶段比如概念、开发、运行、退役。复杂一点的系统会把开发再拆成需求、设计、实现、集成与测试。每个阶段的退出准则必须是可验证的客观条件比如所有需求项已分配到软件组件且经过评审而不是需求工作差不多完成了。阶段退出准则示例主要产物概念利益相关方需求已确认并基线化需求基线、初步风险清单开发产品通过验收测试可部署可发布的产品基线、验证报告运行产品满足服务等级要求运行记录、维护记录退役数据迁移完成服务关闭处置报告、归档数据关于迭代-增量项目24748-3 有专门讨论软件项目很少是单次线性穿越阶段集合。很多团队每个迭代都重新进入开发阶段的一部分活动门禁评审简化为迭代评审。这不违反标准关键是你得在项目计划里写清楚哪个增量在哪个时间点进入哪个阶段、退出准则是什么。3.2 过程适用性映射哪个过程服务哪个阶段生命周期模型搭好之后下一步是把四类过程映射到各个阶段上。这张映射表是项目计划的核心附件之一也是后面审计时对有没有用 12207最直接的证据。阶段主导技术过程主导技术管理过程关键输出概念业务或任务分析、利益相关方需求定义项目计划、风险管理需求基线、项目计划开发软件需求定义、架构定义、设计定义、实现、集成、验证、确认配置管理、测量、质量保证可发布的产品基线运行运行、维护配置管理、信息管理运行记录、缺陷修复记录退役处置项目评估与控制处置报告、归档包注意这张表里验证、确认、质量保证不是开发阶段的配角它们和技术过程并列出现。我见过不少项目把测试和质量工作排在项目计划末尾一旦进度紧张第一个被砍掉。在 24748-3 的视角里验证和确认是独立的技术过程要单独安排活动和资源不能寄生在开发活动里。3.3 把过程责任落到角色和产物上过程映射完成后的下一层工作是把每个过程的活动分配到具体角色。常见做法是用类似 RACI 的方式但我会再加一列产物因为过程改进审计时最常问的就是这个活动的产物在哪。过程活动责任角色支撑角色产物配置管理建立配置标识配置管理员架构师、开发负责人配置项清单、命名规范配置管理执行配置审计配置管理员质量工程师审计报告、偏差整改记录验证执行单元与集成测试测试负责人开发工程师测试报告、缺陷记录这里有一个反复出现的误区把责任角色写成研发部测试组。部门不是角色过程失效时没法追究到部门但能追究到角色。我一般会要求项目计划里每个过程活动至少有一个具名的个人作为责任角色哪怕这个人同时承担多个过程。3.4 项目计划文档里应该体现什么把 24748-3 指南落到项目计划最终文档至少要包含四块内容生命周期模型和阶段清单、每个阶段的退出准则、过程选择与裁剪声明、信息项清单。信息项information item在 12207 里指的就是产物文档和记录比如项目计划本身、评审报告、测试记录、配置基线说明。信息项管理经常被忽略但它决定了评审和审计时能不能拿出证据。项目计划里需要明确每个信息项的格式、状态定义和评审级别。比如测试报告是正式评审还是内部确认这直接影响验收流程。信息管理本身在 12207 里就是技术管理过程之一项目计划里不写清楚评审时就只能靠临时凑材料。4. 裁剪是24748-3的核心决策参数与裁剪声明4.1 裁剪为什么是这份指南的重头戏12207 覆盖的过程范围很大任何项目都不可能原样执行全部内容。裁剪tailoring就是从标准中选择适用的过程和活动、调整其表述、补充组织特有实践的过程。24748-3 前身是 2011 年的技术报告2020 年升格为正式国际标准裁剪指南从建议变成了规范这本身就说明裁剪是落地过程中的刚需。裁剪不是自由发挥。24748-3 反复强调一个底线过程和活动的目的与结果必须保留覆盖。你可以删掉某个活动但不能删掉这个活动对应的过程结果。比如定期配置审计这个活动你可以改成每个里程碑做一次基线审计但不能把配置审计这件事整体删掉否则配置管理的完整性结果就不成立了。4.2 三种裁剪动作删、改、增裁剪动作可以归纳为三类删除不适用的内容、改写表述适配项目语境、增加组织自身实践。看起来简单真正做起来容易出问题的是删的边界和增的必要性。裁剪动作含义软件项目案例删删除不适用或冗余的过程、活动、任务一次性定制开发项目删除处置过程中物理设备销毁任务改改写活动表述以匹配项目语境把获取过程中的供应商招标活动改为内部团队的服务水平约定增补充组织或项目特有的活动在维护过程中增加线上应急回滚任务增的边界要小心。增加的活动必须服务于某个过程的结果而不是组织自己的一套习惯被原样塞进来。我给项目组做裁剪评审时最常见的争议就是这个活动是我们部门的传统做法。这种理由站不住脚要么它能解释清楚对应哪个过程结果要么就不应该写进裁剪声明。4.3 裁剪决策参数什么项目该删什么裁剪不是拍脑袋决策依据是一组项目特征参数。24748-3 的指南里这些参数散落在不同章节实际应用时我会把它整理成一张决策表。决策参数参考取值裁剪倾向关键等级一般 / 重要 / 安全相关安全相关项目少删验证与确认活动项目规模大型团队50人以上 / 小型团队10人以下小型项目合并管理过程的活动密度监管约束无监管 / 行业监管 / 政府合同监管要求的过程不允许裁剪需保留审计证据技术风险低 / 中 / 高高风险项目增加评审频次与验证深度组织成熟度过程资产成熟 / 过程资产稀缺成熟组织复用资产减少新建活动参数之间的优先级也要定清楚。监管约束高于一切安全相关需求排在第二规模和经济性只能在这两类约束之后起作用。曾经有个项目为了赶工期把验证活动全部裁剪掉结果在监管审计阶段被判定为过程不合规返工成本远超节省的工期。这种翻车就是没把参数优先级排对。4.4 裁剪声明怎么记录和批准裁剪声明tailoring statement是把裁剪决策落到纸面的唯一载体也是过程审计时第一个要看的文件。我习惯用一张表来记录每一条裁剪决策字段包括过程、活动、裁剪动作、裁剪后表述、理由、批准人。过程活动/任务裁剪动作裁剪后表述理由批准人配置管理定期配置审计改每个里程碑执行一次基线审计项目周期短季度审计无法及时发现问题项目经理、质量经理验证第三方独立测试删不执行由开发组自测加用户验收项目为内部工具软件无第三方测试资源项目 sponsor维护疑难问题升级机制增新增线上应急回滚与值班升级流程生产环境事故响应需求12207 原任务未覆盖运维负责人裁剪声明的批准路径要写清楚。常见做法是过程负责人起草项目评审会确认质量负责人或 PMO 批准最后连同项目计划一起纳入配置管理。评审会上要逐个过理由不能把裁剪声明当成走过场的附录。提示裁剪声明本身是一个配置项。项目中途技术方案、合同范围或团队结构变化时裁剪声明必须同步走变更评审并更新版本这个习惯能省掉大量审计阶段的追溯麻烦。5. 避坑把12207和24748-3用起来最常见的5个翻车点5.1 把12207当模板直接抄现象项目计划把三十多个过程全部列入每个过程抄一段标准原文当作计划内容产出一份谁都不看的重量级文档实际干活的方式和文档完全脱节。原因项目组拿标准当检查表跳过了裁剪环节又没有人有权对标准内容说这条不适用。解决先按第 3 章方法做生命周期模型和阶段划分再按阶段选过程。对于确定不适用的过程在裁剪声明里显式写明不适用和理由。不适用和选用了但被裁剪是两种不同状态记录方式要分开。5.2 裁剪过度把评审和配置管理裁没了现象所有评审活动取消配置管理只剩一个版本库线上出了事故回不去版本验收时拿不出测试证据。原因裁剪决策只看成本不看风险把能省时间的活动和不应该省的活动混在一起处理。常见说辞是我们团队成熟不需要评审。解决设裁剪红线。关键等级高或受监管约束的项目验证、确认、配置管理、质量保证四个过程不允许整体删除只能调整活动频度。裁掉一个活动时先问自己一句这个活动对应的过程结果还在吗提示裁剪动作是改不是删的场景一定要保留原过程和原活动编号方便审计对照。否则一年后没人说得清当前做法是从标准哪里改出来的。5.3 把过程组直接映射到部门职责现象技术过程归研发部技术管理过程归 PMO使能过程归行政各部门只管自己名下那一块跨过程的结果无人负责。原因过程是按能力组织的不是按组织架构划分的。部门墙天然存在但过程跨部门是常态把过程当部门职责等于默认部门边界就是过程边界。解决每个过程指定一个具名的过程负责人跨部门组成过程改进小组。落到项目计划里责任角色必须是个人而非部门。质量部门在这个过程中作用很大——它不拥有任何技术过程但有权审计所有过程的结果。5.4 标准和敏捷对立两者本来就不是二选一现象敏捷团队说我们是 scrum不写标准文档过程改进人员说敏捷没有过程纪律两边吵得不可开交。原因双方都没看 24748-3 关于迭代-增量模型的讨论。12207 并不强制瀑布式穿越阶段它允许阶段重复进入、活动交叉执行敏捷的迭代天然符合这套逻辑。解决把每个 Sprint 视为一次迷你开发阶段Sprint 评审视为门禁评审的轻量版产品待办列表的细化对应需求过程的活动。裁减声明改这一栏里明明白白记录这种映射审计时就能解释清楚为什么没有传统意义上的阶段文档。5.5 裁剪声明不及时更新现象项目中途换了技术方案项目计划改了两版裁剪声明还是初版审计时对不上。原因裁剪声明没有纳入配置管理也没有变更触发条件。项目组把它当成启动阶段的一页纸写完就不管了。解决在变更管理规则里写明裁剪声明的更新触发条件——技术方案变更、合同范围变化、团队结构重大调整都必须同步更新裁剪声明并走评审。把裁剪声明和项目计划放在同一个基线里面发布版本不一致的问题立刻暴露出来。6. 进阶技巧把24748-3变成一张可执行的审计检查清单6.1 一张可以带进评审会的检查清单裁剪声明做完、项目跑起来之后24748-3 的下一个用途是当审计工具。我习惯把它整理成一张检查清单每个评审会前花二十分钟扫一遍。检查的不是文档存在不存在而是过程的结果达成没达成。检查项通过标准协议接口是否明确甲方乙方有书面接口协议或 SLA且有变更通道生命周期阶段是否完整项目计划中有阶段清单和每个阶段的退出准则裁剪声明是否受控裁剪声明纳入配置管理版本与当前项目计划一致裁剪理由是否成立每条裁剪决策有书面理由和批准人签字高风险项是否闭环每个高风险有缓解措施且有定期再评估记录基线是否可追溯每个发布版本都有配置项标识和对应源码验证是否独立验收测试由非开发负责人执行或确认评审问题是否闭环上次评审遗留问题有责任人、有解决状态运行交接是否落地运行手册或维护手册在部署前已移交运维质量证据是否齐全测试记录、审计报告、评审结论按信息项清单归档这张表不需要引入新工具用现有的项目管理系统、版本库和文档目录就能回答。审计的目的不是抓问题而是确认项目当前的过程执行和裁剪声明的偏差有多大。偏差小说明过程在真实运转偏差大说明计划归计划、执行归执行这是过程改进最需要处理的问题。6.2 从小范围试点开始如果你所在的组织还没有用过这套方法论不要一上来就全面铺开。选一个正在启动的中等复杂度项目团队最好对新过程有开放态度。先帮他们把生命周期模型和裁剪声明做出来运行一个阶段后用上面的清单做一次对照审计。这样做的价值是让全组织看到过程文档不是负担裁剪声明不厚检查清单能回答真实问题。我自己的习惯是每次评审会前先扫一遍检查清单不是拿它去卡别人而是先确认自己有没有漏掉该看的证据。做过程改进这些年最深的感受是标准里那些条目从来不是用来证明谁错了而是用来提醒我们还有哪个结果没有守住。希望帮到你。本文还有配套的精品资源点击获取