ソフトウェアライフサイクル

# ソフトウェアライフサイクル ## 定義ソフトウェアシステムの誕生から廃棄までの一連の活動・フェーズを指す枠組み。Boehm(1976)が示したライフサイクルは以下のフェーズで構成される: 1. システム要件 + 検証(VALIDATION) 2. ソフトウェア要件 + 検証 3. 予備設計(Preliminary Design) + 検証 4. 詳細設計(Detailed Design) + 検証 5. コード/デバッグ(Code and Debug) 6. 開発テスト(Development Test) 7. 受入テスト前テスト(Test and Preoperations) + 検証テスト 8. 運用・保守・再検証(Operations and Maintenance / Revalidation) 各フェーズに検証(Validation)が付随する点が特徴的で、欠陥を早期発見することの重要性を構造的に示している(Source: [[@1976__IEEE-TC__Software Engineering]])。 ## フェーズ間コスト比の原則ソフトウェアライフサイクルで最も重要な経験則の一つ: **欠陥の発見が遅れるほど修正コストは指数的に増大する**。 Boehm(1976)が IBM・GTE・TRW のデータから示した相対コスト: - 要件フェーズ: 0.1–0.2 - 設計フェーズ: 0.5 - コーディングフェーズ: 1.0(基準) - 開発テスト: 2–5 - 受入テスト: 15–20 - 運用: 15–100 (Source: [[@1976__IEEE-TC__Software Engineering]], Fig. 3) ## ISO/IEC 12207 によるプロセス分類 [[ISO IEC 12207|ISO/IEC 12207]](Software Life Cycle Processes)は、ソフトウェアのライフサイクルを Primary(主)・Supporting(支援)・Organizational(組織)という3つのプロセス類に分けて記述する国際標準である。SWEBOK Straw Man 版(1998)は、一般的なソフトウェア工学教科書24冊の目次を分析した結果、教科書間で共通のライフサイクルモデルが存在しないことが判明したため、この ISO/IEC 12207 を知識領域(Knowledge Area)分類の基盤・語彙として採用した。採用理由として、二大標準化団体(ISO/IEC JTC1 SC7 と IEEE Computer Society Software Engineering Standards Committee)双方への採用実績、特定の開発方法・ライフサイクルモデルへの非依存性、構想(concept)から廃棄(retirement)までの全ライフサイクルの網羅、取得者(acquirer)・供給者(supplier)・開発者(developer)・保守者(maintainer)・運用者(operator)という役割の提供が挙げられている。著者らは、ISO/IEC TR-15504 が定義する追加プロセス(Primary: 要件抽出プロセス、Support: 測定プロセス・再利用プロセス、Organizational: 品質マネジメント・リスクマネジメントプロセス・組織整合プロセス)が 12207 には含まれていないことも認識しており、この Primary/Support/Organizational という3分類の枠組み自体は 12207 と TR-15504 に共通する構造として扱われている。(Source: [[@1998__IEEECS__SWEBOK Straw Man - Chapter 4 Development Methodology for Identifying Knowledge Areas and Related Disciplines]], p.20-21) ## 横断的知見 - **Boehm(1976)の8フェーズモデルが「時間軸に沿った段階(要件→設計→コード→テスト→運用)」としてライフサイクルを記述するのに対し、SWEBOK Straw Man 版が採用した ISO/IEC 12207 は「誰が何をするプロセスか」という役割・活動の類型(Primary/Supporting/Organizational)としてライフサイクルを記述しており、同じ「ソフトウェアライフサイクル」という語を時間軸と役割・プロセス類型軸という異なる次元で切り取っている**: Boehm のモデルは各フェーズに検証(Validation)を伴わせ、フェーズ間の欠陥修正コスト比(要件0.1-0.2倍〜運用15-100倍)という定量的な経済モデルを提供する時間順序の枠組みである。一方 ISO/IEC 12207 は、取得者・供給者・開発者・保守者・運用者という役割ごとに、主・支援・組織というプロセスの性質でライフサイクル全体を分類する、特定の時間順序に依存しない枠組みである。SWEBOK Straw Man 版の著者ら自身が、教科書間で共通の(Boehm 的な)フェーズ順序モデルが見出せなかったことを ISO/IEC 12207 採用の理由として明記しており、フェーズ順序という切り口の限界が、役割・プロセス類型という別の切り口への移行を促した経緯が読み取れる。(Source: [[@1976__IEEE-TC__Software Engineering]], [[@1998__IEEECS__SWEBOK Straw Man - Chapter 4 Development Methodology for Identifying Knowledge Areas and Related Disciplines]], p.20-21) - 保守フェーズがライフサイクルコストの大半(~70%)を占めることは 1976 年のデータでも 2000 年代以降のデータでも一貫している。ライフサイクルモデルの設計時に保守コストを明示的に含めることの重要性は長年にわたって繰り返し強調されている(Source: [[@1976__IEEE-TC__Software Engineering]])。 - **Boehm(1976)の8フェーズモデルが「検証(Validation)」を各フェーズに付随させる欠陥検出中心の構造であるのに対し、『SREの探求』8章の図8-4は同じ「ライフサイクル」という語を、SREという特定職能の関与責任・活動・メリットを段階ごとに割り当てる組織設計の枠組みとして用いており、同じ語で異なる対象を区分している**: Boehm のモデルは要件・予備設計・詳細設計・コード/デバッグ・開発テスト・受入テスト前テスト・運用保守という8段階を欠陥の早期発見という単一の目的軸で構成し、フェーズ間コスト比(要件0.1-0.2倍〜運用15-100倍)という定量的な経済モデルを提供する。8章の図8-4は設計・構築・リリース・リリース後対応という4段階を、エンジニアリング/プロダクトマーケティングとSREという2つの職能それぞれの責任・サンプル活動・メリットという3層で記述し、「SREはライフサイクルに早く関与するほど有効性が高まる」という組織設計上の処方箋を導く。両者を並べると、「ソフトウェアライフサイクル」という同一の語が、(1)欠陥修正コストの経済モデル(Boehm)と、(2)信頼性責任の職能間配分モデル(8章)という、目的も粒度も異なる2つのフレームワークを指しうることが分かる。8章のモデルはBoehmの「検証」フェーズが暗黙に前提する欠陥検出の役割を、SREという専任職能に明示的に割り当てる後継的な発展として読むこともできる——特に「構築」段階の「メトリクス/インスツルメンテーションを正確に収集できる環境の確立」は、Boehmの開発テスト・受入テスト前テストにおける検証コストの高さ(2-20倍)を、計装によって早期に可視化しようとする試みと解釈できる。(Source: [[@1976__IEEE-TC__Software Engineering]], [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]] §8.2.4.4) - **『SREの探求』11章の[[レディネスレビュー]](LRR/HRR)は、8章の図8-4が示す「自己管理→SREへの引き継ぎ」という移行を、具体的な審査ゲートの形に制度化する**: 本ページ既出の知見は、Boehmの8段階モデル(欠陥検出中心の経済モデル)と8章の図8-4(設計・構築・リリース・リリース後対応というSREの職能配分モデル)が、「ソフトウェアライフサイクル」という同じ語で異なる対象を区分すると整理した。11章はこの2つのモデルのさらに先——ライフサイクル上で開発グループの自己管理からGoogleの集中型運用グループ(SRE)への引き継ぎが起きる移行点——に、LRR(ローンチレディネスレビュー)とHRR(引き継ぎレディネスレビュー)という具体的な審査ゲートを配置する。LRR/HRRの6判定項目(欠陥数・アラート・モニタリングカバレッジ・システムアーキテクチャ・デプロイプロセス・プロダクションハイジーン)は、Boehmの「検証(Validation)」フェーズが暗黙に想定する欠陥の早期発見を、8章の図8-4が抽象的に述べる「SREのライフサイクルへの早期関与」と結びつけ、いつ・何を基準に引き継ぎが承認されるかという運用上の意思決定ルールにまで具体化したものである。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] §11.2, [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]] §8.2.4.4) ## 未解決の問い - [[ISO IEC 12207|ISO/IEC 12207]] の Primary/Supporting/Organizational という3分類と、Boehm(1976)の8フェーズモデルとの間に明示的な対応表(どのフェーズがどのプロセス類に相当するか)は存在するか。SWEBOK Straw Man 版第4章の本文だけからはこの対応関係を復元できない。 - フェーズ間コスト比は組込みシステムや AI/ML システムでも同様の傾向を示すか? 要件が反復的に更新されるアジャイル開発では「フェーズ」概念自体が再定義されるが、コスト比の原則は維持されるか? - Boehm が 1976 年に「近い将来」と予測した形式的要件言語・自動プログラミングは実現したか? その後の展開は? - Boehm の「検証」フェーズ(欠陥の早期発見)と、8章の「構築」段階における「メトリクス/インスツルメンテーションを正確に収集できる環境の確立」は、同じ「早期の可視化」という目的を持つと解釈できるが、この対応関係は本 concept の現ソース群では検証されていない。SREによる計装導入は、Boehmのフェーズ間コスト比が示す「テスト以降のコスト急増」をどの程度緩和できるか、定量的な比較事例が必要。 - 11章のLRR/HRRという審査ゲートと、Boehmの各フェーズに付随する「検証(Validation)」は、判定基準(6項目のチェックリスト vs 形式的な検証手法)の厳密さにおいてどう異なるか。LRR/HRRが定性的なチェックリストにとどまるのに対し、Boehmの検証はより形式的な手法を想定しているように見えるが、11章の記述だけでは両者の厳密さの差を定量的に比較できない。 ## 関連 - [[ソフトウェア要件工学]] - [[ソフトウェア保守]] - [[@1976__IEEE-TC__Software Engineering]] - [[@2007__FOSE__Software Reliability Engineering - A Roadmap]](ロードマップ的後継視点) - [[@2021__OReillyJapan__SREの探求 - Chapter 8 大企業におけるSREの導入]](プロダクト開発ライフサイクルへのSRE関与という組織設計視点、図8-4) - [[@2021__OReillyJapan__SREの探求 - Chapter 11 DevOpsの幅広い実践現場で活用されているSREのパターン]] — LRR/HRRという具体的な審査ゲート、[[レディネスレビュー]] - [[SRE組織変革]] / [[SREエンゲージメントモデル]] - [[@1998__IEEECS__SWEBOK Straw Man - Chapter 4 Development Methodology for Identifying Knowledge Areas and Related Disciplines]] — ISO/IEC 12207 をライフサイクル分類の基盤として採用した経緯、[[ISO IEC 12207|ISO/IEC 12207]] ## 出典 - Boehm, B. W. (1976). Software Engineering. *IEEE Transactions on Computers*, Vol. C-25, No. 12, pp. 1226–1241. - Sriram Gollapalli, 「大企業における SRE の導入」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 8 章. - Gene Kim, 「DevOps の幅広い実践現場で活用されている SRE のパターン」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 11 章. - Bourque, P. et al., *Guide to the Software Engineering Body of Knowledge – A Straw Man Version*, IEEE Computer Society, 1998, Chapter 4.