簡介ISO/IEC/IEEE 24748-3:2020是面向系統(tǒng)與軟件工程領域的重要國際標準專為應用ISO/IEC/IEEE 12207軟件生命周期過程提供系統(tǒng)化指南。這份75頁英文電子版適合軟件工程師、項目經(jīng)理、質(zhì)量與風險管理及系統(tǒng)工程相關從業(yè)者可幫助解決生命周期流程落地、過程改進與合規(guī)實施等實際問題。壓縮包內(nèi)含1個PDF文件共2.13MB便于離線查閱與學習。已有174人瀏覽學習。標準內(nèi)容涵蓋范圍、規(guī)范性引用文件、術語與縮略語、軟件系統(tǒng)概念、過程與生命周期概念并給出應用指南、實施建議、質(zhì)量與風險管理及組織人員職責等模塊。通過遵循其中框架組織可對標國際最佳實踐提升軟件產(chǎn)品質(zhì)量與項目可控性。這份PDF為完整電子版頁碼齊全適合作為標準研讀、內(nèi)部培訓或項目管理參考。1. ISO/IEC/IEEE 24748-3它不是又一本過程手冊而是12207真正能跑起來的使用說明ISO/IEC/IEEE 24748-3:2020 的完整名字很長長到讓人以為是又一本過程手冊。但真正做過程改進的人拿到這份75頁的英文電子版會發(fā)現(xiàn)它回答的是另一個問題ISO/IEC/IEEE 12207 已經(jīng)把軟件生命周期過程定義到了任務級為什么項目組照抄下來還是跑不動24748-3 的價值就在這——它是軟件生命周期過程標準的使用說明書。它不新增過程而是告訴你如何選過程、如何裁剪、如何把標準里的活動映射到實際項目的階段、產(chǎn)物和角色上。對過程改進工程師、軟件質(zhì)量經(jīng)理和正在給團隊補過程短板的項目經(jīng)理這份指南解決的就是從標準文本到項目計劃之間最后那段路。2. 先看懂12207的粒度過程、活動、任務三層結(jié)構(gòu)與四類過程組2.1 從software life cycle processes出發(fā)過程和流程不是一回事ISO/IEC/IEEE 24748-3 標題里的 System and software engineering 不是隨便掛的名頭它和 12207 一樣同時覆蓋系統(tǒng)與軟件兩個視角。想用好這份指南第一件事是糾正一個普遍誤讀12207 定義的是過程process不是流程flow。流程強調(diào)順序輸入輸出串成一條線上個環(huán)節(jié)不完成下個環(huán)節(jié)就不開始。過程強調(diào)的是能力是一組為達成特定結(jié)果而協(xié)同的活動集合活動之間可以有并行、有迭代、有先后但最終目的是產(chǎn)出某個確定的結(jié)果。12207 把每個過程的用途、預期結(jié)果、活動和任務都做了標準化描述這套描述換到哪個行業(yè)、哪個規(guī)模的項目都能講通。24748-3 開篇就在糾正這個誤讀應用 12207 第一步不是去找模板流程圖而是識別你的項目需要哪些過程的能力。判斷一個項目是否真的在用 12207也不是看文檔里有沒有階段評審這些詞匯而是看過程的目的和結(jié)果是否達成。2.2 四類過程組的劃分與用途12207 把三十多個軟件生命周期過程分成四類這四類劃分直接決定了 24748-3 后面所有應用指南的組織方式。過程組典型過程在項目中的角色協(xié)議過程獲取、供應界定甲方乙方權(quán)利邊界管理采購與外包組織項目使能過程生命周期模型管理、基礎設施管理、組合管理、人力資源管理、質(zhì)量管理項目背后的組織常備能力不隨項目結(jié)束而消失技術管理過程項目計劃、評估與控制、決策管理、風險管理、配置管理、信息管理、測量、質(zhì)量保證項目的控制面管資源、基線、風險與質(zhì)量證據(jù)技術過程業(yè)務或任務分析、利益相關方需求定義、軟件需求定義、架構(gòu)定義、設計定義、實現(xiàn)、集成、驗證、確認、運行、維護、處置直接產(chǎn)出軟件產(chǎn)品的鏈路這張表是我做過程改進時最常用的起點。實際項目中協(xié)議過程先回答項目邊界在哪技術過程回答產(chǎn)品怎么造出來技術管理過程回答怎么保證造出來的東西不失控使能過程回答組織給了什么基礎設施。一個項目計劃如果連這四類過程都對應不上后面所有活動安排都會飄。2.3 活動和任務過程真正被執(zhí)行的粒度12207 每個過程都有一個固定的描述模板目的purpose、結(jié)果outcomes、活動activities活動再拆到任務tasks。24748-3 的使用建議很直接——先看目的和結(jié)果再倒推需要哪些活動和任務而不是反過來逐條執(zhí)行。拿配置管理舉例。它的目的是建立并維護產(chǎn)品和工作產(chǎn)品的完整性。結(jié)果有四條配置項有唯一標識、變更受控、配置狀態(tài)可查詢、定期的配置審計能發(fā)現(xiàn)偏差。落到項目里這些結(jié)果對應的事就是配置標識、配置控制、配置狀態(tài)記錄和配置審計。一個小團隊做配置管理可以簡化到版本庫里的分支策略和發(fā)布標簽但標識-控制-狀態(tài)記錄-審計四個結(jié)果一個都不能少。沒有這四樣線上事故發(fā)生時找不到對應版本和源碼就是過程缺失不是工具問題。這個例子我常用來說明任務可以裁剪結(jié)果不能被裁剪。2.4 為什么24748-3反復強調(diào)組織層與項目層的對接12207 的過程天然分兩層使能過程通常在組織層定義項目層過來借用技術過程和技術管理過程在項目層執(zhí)行。24748-3 針對這個接口給出了大量具體建議。最常見的做法是項目計劃里不再重復寫基礎設施、人力資源這些使能過程怎么做而是寫引用組織已發(fā)布的過程資產(chǎn)并標注版本。這樣能省掉大量重復文檔。反過來說組織層如果沒有沉淀這些資產(chǎn)每個項目都自建一套那過程改進永遠只能是項目級而不是組織級換一個項目經(jīng)理就推倒重來一次。Life cycle management 在這個語境里講的不是做資產(chǎn)臺賬而是把項目從立項到退役的每一個階段管住狀態(tài)、管住基線、管住評審結(jié)論。這一層想清楚了后面做裁剪聲明時才不會把組織能力和項目活動混成一鍋粥。3. 用24748-3把12207落到項目計劃階段、門禁與責任映射3.1 先建生命周期模型階段和門禁怎么設很多團隊拿到 12207 第一反應是我們先把過程清單列出來這是錯的。24748-3 給出的順序是先建生命周期模型再選過程。階段stage是時間軸上的大格子每個階段有明確目的和退出準則exit criteria退出準則通過門禁評審來驗證。軟件項目常見做法是把完整生命周期壓成四到五個階段比如概念、開發(fā)、運行、退役。復雜一點的系統(tǒng)會把開發(fā)再拆成需求、設計、實現(xiàn)、集成與測試。每個階段的退出準則必須是可驗證的客觀條件比如所有需求項已分配到軟件組件且經(jīng)過評審而不是需求工作差不多完成了。階段退出準則示例主要產(chǎn)物概念利益相關方需求已確認并基線化需求基線、初步風險清單開發(fā)產(chǎn)品通過驗收測試可部署可發(fā)布的產(chǎn)品基線、驗證報告運行產(chǎn)品滿足服務等級要求運行記錄、維護記錄退役數(shù)據(jù)遷移完成服務關閉處置報告、歸檔數(shù)據(jù)關于迭代-增量項目24748-3 有專門討論軟件項目很少是單次線性穿越階段集合。很多團隊每個迭代都重新進入開發(fā)階段的一部分活動門禁評審簡化為迭代評審。這不違反標準關鍵是你得在項目計劃里寫清楚哪個增量在哪個時間點進入哪個階段、退出準則是什么。3.2 過程適用性映射哪個過程服務哪個階段生命周期模型搭好之后下一步是把四類過程映射到各個階段上。這張映射表是項目計劃的核心附件之一也是后面審計時對有沒有用 12207最直接的證據(jù)。階段主導技術過程主導技術管理過程關鍵輸出概念業(yè)務或任務分析、利益相關方需求定義項目計劃、風險管理需求基線、項目計劃開發(fā)軟件需求定義、架構(gòu)定義、設計定義、實現(xiàn)、集成、驗證、確認配置管理、測量、質(zhì)量保證可發(fā)布的產(chǎn)品基線運行運行、維護配置管理、信息管理運行記錄、缺陷修復記錄退役處置項目評估與控制處置報告、歸檔包注意這張表里驗證、確認、質(zhì)量保證不是開發(fā)階段的配角它們和技術過程并列出現(xiàn)。我見過不少項目把測試和質(zhì)量工作排在項目計劃末尾一旦進度緊張第一個被砍掉。在 24748-3 的視角里驗證和確認是獨立的技術過程要單獨安排活動和資源不能寄生在開發(fā)活動里。3.3 把過程責任落到角色和產(chǎn)物上過程映射完成后的下一層工作是把每個過程的活動分配到具體角色。常見做法是用類似 RACI 的方式但我會再加一列產(chǎn)物因為過程改進審計時最常問的就是這個活動的產(chǎn)物在哪。過程活動責任角色支撐角色產(chǎn)物配置管理建立配置標識配置管理員架構(gòu)師、開發(fā)負責人配置項清單、命名規(guī)范配置管理執(zhí)行配置審計配置管理員質(zhì)量工程師審計報告、偏差整改記錄驗證執(zhí)行單元與集成測試測試負責人開發(fā)工程師測試報告、缺陷記錄這里有一個反復出現(xiàn)的誤區(qū)把責任角色寫成研發(fā)部測試組。部門不是角色過程失效時沒法追究到部門但能追究到角色。我一般會要求項目計劃里每個過程活動至少有一個具名的個人作為責任角色哪怕這個人同時承擔多個過程。3.4 項目計劃文檔里應該體現(xiàn)什么把 24748-3 指南落到項目計劃最終文檔至少要包含四塊內(nèi)容生命周期模型和階段清單、每個階段的退出準則、過程選擇與裁剪聲明、信息項清單。信息項information item在 12207 里指的就是產(chǎn)物文檔和記錄比如項目計劃本身、評審報告、測試記錄、配置基線說明。信息項管理經(jīng)常被忽略但它決定了評審和審計時能不能拿出證據(jù)。項目計劃里需要明確每個信息項的格式、狀態(tài)定義和評審級別。比如測試報告是正式評審還是內(nèi)部確認這直接影響驗收流程。信息管理本身在 12207 里就是技術管理過程之一項目計劃里不寫清楚評審時就只能靠臨時湊材料。4. 裁剪是24748-3的核心決策參數(shù)與裁剪聲明4.1 裁剪為什么是這份指南的重頭戲12207 覆蓋的過程范圍很大任何項目都不可能原樣執(zhí)行全部內(nèi)容。裁剪tailoring就是從標準中選擇適用的過程和活動、調(diào)整其表述、補充組織特有實踐的過程。24748-3 前身是 2011 年的技術報告2020 年升格為正式國際標準裁剪指南從建議變成了規(guī)范這本身就說明裁剪是落地過程中的剛需。裁剪不是自由發(fā)揮。24748-3 反復強調(diào)一個底線過程和活動的目的與結(jié)果必須保留覆蓋。你可以刪掉某個活動但不能刪掉這個活動對應的過程結(jié)果。比如定期配置審計這個活動你可以改成每個里程碑做一次基線審計但不能把配置審計這件事整體刪掉否則配置管理的完整性結(jié)果就不成立了。4.2 三種裁剪動作刪、改、增裁剪動作可以歸納為三類刪除不適用的內(nèi)容、改寫表述適配項目語境、增加組織自身實踐。看起來簡單真正做起來容易出問題的是刪的邊界和增的必要性。裁剪動作含義軟件項目案例刪刪除不適用或冗余的過程、活動、任務一次性定制開發(fā)項目刪除處置過程中物理設備銷毀任務改改寫活動表述以匹配項目語境把獲取過程中的供應商招標活動改為內(nèi)部團隊的服務水平約定增補充組織或項目特有的活動在維護過程中增加線上應急回滾任務增的邊界要小心。增加的活動必須服務于某個過程的結(jié)果而不是組織自己的一套習慣被原樣塞進來。我給項目組做裁剪評審時最常見的爭議就是這個活動是我們部門的傳統(tǒng)做法。這種理由站不住腳要么它能解釋清楚對應哪個過程結(jié)果要么就不應該寫進裁剪聲明。4.3 裁剪決策參數(shù)什么項目該刪什么裁剪不是拍腦袋決策依據(jù)是一組項目特征參數(shù)。24748-3 的指南里這些參數(shù)散落在不同章節(jié)實際應用時我會把它整理成一張決策表。決策參數(shù)參考取值裁剪傾向關鍵等級一般 / 重要 / 安全相關安全相關項目少刪驗證與確認活動項目規(guī)模大型團隊50人以上 / 小型團隊10人以下小型項目合并管理過程的活動密度監(jiān)管約束無監(jiān)管 / 行業(yè)監(jiān)管 / 政府合同監(jiān)管要求的過程不允許裁剪需保留審計證據(jù)技術風險低 / 中 / 高高風險項目增加評審頻次與驗證深度組織成熟度過程資產(chǎn)成熟 / 過程資產(chǎn)稀缺成熟組織復用資產(chǎn)減少新建活動參數(shù)之間的優(yōu)先級也要定清楚。監(jiān)管約束高于一切安全相關需求排在第二規(guī)模和經(jīng)濟性只能在這兩類約束之后起作用。曾經(jīng)有個項目為了趕工期把驗證活動全部裁剪掉結(jié)果在監(jiān)管審計階段被判定為過程不合規(guī)返工成本遠超節(jié)省的工期。這種翻車就是沒把參數(shù)優(yōu)先級排對。4.4 裁剪聲明怎么記錄和批準裁剪聲明tailoring statement是把裁剪決策落到紙面的唯一載體也是過程審計時第一個要看的文件。我習慣用一張表來記錄每一條裁剪決策字段包括過程、活動、裁剪動作、裁剪后表述、理由、批準人。過程活動/任務裁剪動作裁剪后表述理由批準人配置管理定期配置審計改每個里程碑執(zhí)行一次基線審計項目周期短季度審計無法及時發(fā)現(xiàn)問題項目經(jīng)理、質(zhì)量經(jīng)理驗證第三方獨立測試刪不執(zhí)行由開發(fā)組自測加用戶驗收項目為內(nèi)部工具軟件無第三方測試資源項目 sponsor維護疑難問題升級機制增新增線上應急回滾與值班升級流程生產(chǎn)環(huán)境事故響應需求12207 原任務未覆蓋運維負責人裁剪聲明的批準路徑要寫清楚。常見做法是過程負責人起草項目評審會確認質(zhì)量負責人或 PMO 批準最后連同項目計劃一起納入配置管理。評審會上要逐個過理由不能把裁剪聲明當成走過場的附錄。提示裁剪聲明本身是一個配置項。項目中途技術方案、合同范圍或團隊結(jié)構(gòu)變化時裁剪聲明必須同步走變更評審并更新版本這個習慣能省掉大量審計階段的追溯麻煩。5. 避坑把12207和24748-3用起來最常見的5個翻車點5.1 把12207當模板直接抄現(xiàn)象項目計劃把三十多個過程全部列入每個過程抄一段標準原文當作計劃內(nèi)容產(chǎn)出一份誰都不看的重量級文檔實際干活的方式和文檔完全脫節(jié)。原因項目組拿標準當檢查表跳過了裁剪環(huán)節(jié)又沒有人有權(quán)對標準內(nèi)容說這條不適用。解決先按第 3 章方法做生命周期模型和階段劃分再按階段選過程。對于確定不適用的過程在裁剪聲明里顯式寫明不適用和理由。不適用和選用了但被裁剪是兩種不同狀態(tài)記錄方式要分開。5.2 裁剪過度把評審和配置管理裁沒了現(xiàn)象所有評審活動取消配置管理只剩一個版本庫線上出了事故回不去版本驗收時拿不出測試證據(jù)。原因裁剪決策只看成本不看風險把能省時間的活動和不應該省的活動混在一起處理。常見說辭是我們團隊成熟不需要評審。解決設裁剪紅線。關鍵等級高或受監(jiān)管約束的項目驗證、確認、配置管理、質(zhì)量保證四個過程不允許整體刪除只能調(diào)整活動頻度。裁掉一個活動時先問自己一句這個活動對應的過程結(jié)果還在嗎提示裁剪動作是改不是刪的場景一定要保留原過程和原活動編號方便審計對照。否則一年后沒人說得清當前做法是從標準哪里改出來的。5.3 把過程組直接映射到部門職責現(xiàn)象技術過程歸研發(fā)部技術管理過程歸 PMO使能過程歸行政各部門只管自己名下那一塊跨過程的結(jié)果無人負責。原因過程是按能力組織的不是按組織架構(gòu)劃分的。部門墻天然存在但過程跨部門是常態(tài)把過程當部門職責等于默認部門邊界就是過程邊界。解決每個過程指定一個具名的過程負責人跨部門組成過程改進小組。落到項目計劃里責任角色必須是個人而非部門。質(zhì)量部門在這個過程中作用很大——它不擁有任何技術過程但有權(quán)審計所有過程的結(jié)果。5.4 標準和敏捷對立兩者本來就不是二選一現(xiàn)象敏捷團隊說我們是 scrum不寫標準文檔過程改進人員說敏捷沒有過程紀律兩邊吵得不可開交。原因雙方都沒看 24748-3 關于迭代-增量模型的討論。12207 并不強制瀑布式穿越階段它允許階段重復進入、活動交叉執(zhí)行敏捷的迭代天然符合這套邏輯。解決把每個 Sprint 視為一次迷你開發(fā)階段Sprint 評審視為門禁評審的輕量版產(chǎn)品待辦列表的細化對應需求過程的活動。裁減聲明改這一欄里明明白白記錄這種映射審計時就能解釋清楚為什么沒有傳統(tǒng)意義上的階段文檔。5.5 裁剪聲明不及時更新現(xiàn)象項目中途換了技術方案項目計劃改了兩版裁剪聲明還是初版審計時對不上。原因裁剪聲明沒有納入配置管理也沒有變更觸發(fā)條件。項目組把它當成啟動階段的一頁紙寫完就不管了。解決在變更管理規(guī)則里寫明裁剪聲明的更新觸發(fā)條件——技術方案變更、合同范圍變化、團隊結(jié)構(gòu)重大調(diào)整都必須同步更新裁剪聲明并走評審。把裁剪聲明和項目計劃放在同一個基線里面發(fā)布版本不一致的問題立刻暴露出來。6. 進階技巧把24748-3變成一張可執(zhí)行的審計檢查清單6.1 一張可以帶進評審會的檢查清單裁剪聲明做完、項目跑起來之后24748-3 的下一個用途是當審計工具。我習慣把它整理成一張檢查清單每個評審會前花二十分鐘掃一遍。檢查的不是文檔存在不存在而是過程的結(jié)果達成沒達成。檢查項通過標準協(xié)議接口是否明確甲方乙方有書面接口協(xié)議或 SLA且有變更通道生命周期階段是否完整項目計劃中有階段清單和每個階段的退出準則裁剪聲明是否受控裁剪聲明納入配置管理版本與當前項目計劃一致裁剪理由是否成立每條裁剪決策有書面理由和批準人簽字高風險項是否閉環(huán)每個高風險有緩解措施且有定期再評估記錄基線是否可追溯每個發(fā)布版本都有配置項標識和對應源碼驗證是否獨立驗收測試由非開發(fā)負責人執(zhí)行或確認評審問題是否閉環(huán)上次評審遺留問題有責任人、有解決狀態(tài)運行交接是否落地運行手冊或維護手冊在部署前已移交運維質(zhì)量證據(jù)是否齊全測試記錄、審計報告、評審結(jié)論按信息項清單歸檔這張表不需要引入新工具用現(xiàn)有的項目管理系統(tǒng)、版本庫和文檔目錄就能回答。審計的目的不是抓問題而是確認項目當前的過程執(zhí)行和裁剪聲明的偏差有多大。偏差小說明過程在真實運轉(zhuǎn)偏差大說明計劃歸計劃、執(zhí)行歸執(zhí)行這是過程改進最需要處理的問題。6.2 從小范圍試點開始如果你所在的組織還沒有用過這套方法論不要一上來就全面鋪開。選一個正在啟動的中等復雜度項目團隊最好對新過程有開放態(tài)度。先幫他們把生命周期模型和裁剪聲明做出來運行一個階段后用上面的清單做一次對照審計。這樣做的價值是讓全組織看到過程文檔不是負擔裁剪聲明不厚檢查清單能回答真實問題。我自己的習慣是每次評審會前先掃一遍檢查清單不是拿它去卡別人而是先確認自己有沒有漏掉該看的證據(jù)。做過程改進這些年最深的感受是標準里那些條目從來不是用來證明誰錯了而是用來提醒我們還有哪個結(jié)果沒有守住。希望幫到你。本文還有配套的精品資源點擊獲取