# ソフトウェア保守 ## 定義 「既存の運用ソフトウェアの主要機能を維持したまま修正するプロセス」(Boehm 1976)。 > Software maintenance: "the process of modifying existing operational software while leaving its primary functions intact." (Source: [[@1976__IEEE-TC__Software Engineering]], p.1235) ## 分類(Swanson 1976 による) **ソフトウェア更新(software update)**: 機能仕様を変更する修正 **ソフトウェア修理(software repair)**: 機能仕様を維持したまま修正 - **修正保守(corrective maintenance)**: 処理・性能・実装の不具合の修正 - **適応保守(adaptive maintenance)**: 処理環境・データ環境の変化への対応 - **完全化保守(perfective maintenance)**: 性能・保守性の向上 ## 保守の三機能 1. **既存ソフトウェアの理解**: 良いドキュメント、要件とコード間のトレーサビリティ、構造化・書式化されたコードが前提 2. **修正**: サイドエフェクトを最小化する疎結合のコード・データ構造、更新しやすいドキュメント 3. **再検証**: 選択的再テストを可能にする構造と支援ツール (Source: [[@1976__IEEE-TC__Software Engineering]], §VII.A) ## 規模と経済 1976 年時点の実績データ: - ソフトウェアライフサイクルコストの約 **70%** が保守に費やされる - General Motors: 約 **75%** - GTE(リアルタイムソフトウェアの 10 年コスト): 約 **60%** - USAF C+C システム 2 つ: それぞれ **67%** および **72%** - 硬件比較: ハードウェア・ソフトウェア全体ドル中、1976 年時点でソフトウェア保守は約 **40%**、1985 年には **60%** に達すると予測 (Source: [[@1976__IEEE-TC__Software Engineering]], Fig. 6, p.1236) 開発vs保守単価の極端な例: あるある航空機コンピュータでは開発コスト約 75 ドル/命令に対して保守コスト最大 **4000 ドル/命令**。 ## なぜ軽視されるか - 保守タスクには経験の浅い担当者が配置されがちである - データ処理の慣習は開発コスト・スケジュール最適化に傾きがちで、ドキュメント・テスト・構造化が犠牲になる - ハードウェア効率最適化(アセンブリ言語採用・ハードウェア節約)が保守コスト増に強く相関する ## 横断的知見 - 保守がライフサイクルコストの過半数を占めるという事実は 1976 年に Boehm が示して以来、多くの後続研究でも繰り返し確認されている。比率は変化しつつも「保守 > 開発」という構造は現代のシステムでも基本的に変わらない。(Source: [[@1976__IEEE-TC__Software Engineering]]) - Boehm の三分類(修正・適応・完全化)は ISO/IEC 14764 などの標準にも引き継がれており、50 年後の今も保守の分類語彙として生きている。 - Boehm(1976)は保守の三機能のうち「修正」を、サイドエフェクトを最小化する疎結合のコード・データ構造と更新しやすいドキュメントという**構造上の性質**として記述する(§保守の三機能)。Ousterhout(2018)第 16 章は、この構造上の性質が実際にどう維持・毀損されるかという**開発者の振る舞い**の側から同じ問題に迫る。同章 §16.1 は、開発者がバグ修正や機能追加のたびに「必要なことをする最小の変更は何か」という戦術的な発想を取ると、その一回一回の変更が特殊ケースや依存を持ち込み、システムの進化のたびに設計が悪化すると述べる。逆に変更のたびに「最初からこの変更を見越して設計されていたら持っていたはずの構造」を目指し、必要ならリファクタリングするという戦略的な姿勢を取れば、システム設計は変更のたびに改善されうるとする。すなわち Boehm が保守の望ましい到達状態(疎結合・更新しやすさ)を記述するのに対し、Ousterhout はその到達状態を個々の変更の積み重ねの中でどう保つか、あるいはどう失うかという過程を記述しており、両者は保守という同じ現象を「構造」と「振る舞い」という異なる高さから捉えている。(Source: [[@1976__IEEE-TC__Software Engineering]] §VII.A, [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 16 Modifying Existing Code]] §16.1) - Boehm(1976)は保守が軽視される理由として、保守タスクに経験の浅い担当者が配置されがちであることや、データ処理の慣習が開発コスト・スケジュール最適化に傾きドキュメント・テスト・構造化が犠牲になることを挙げる(§なぜ軽視されるか)。Ousterhout(2018)第 16 章 §16.1 は、投資マインドセットが商用ソフトウェア開発の現実、すなわち締め切りの厳しさと衝突しうることを認め、3 か月のリファクタリングの代わりに 2 時間の場当たり的な修正を選ばざるを得ない場面があると述べる。両者とも、保守・変更の質がスケジュール圧力によって損なわれるという同じ力学を指摘している点で一致するが、Boehm がこれを組織的・経済的な傾向として記述するのに対し、Ousterhout は開発組織が総労力の一部をクリーンアップとリファクタリングに計画的に充てるべきだという個別の対応策を提案する点で異なる。(Source: [[@1976__IEEE-TC__Software Engineering]], [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 16 Modifying Existing Code]] §16.1) ## 未解決の問い - クラウドネイティブ・コンテナ化システムでは「再検証(revalidation)」の単位がどう変わるか? サービスグラフの動的変化に Boehm の三機能モデルはそのまま適用できるか? - 保守コスト削減における AI/ML コード補完・自動リファクタリングの実際の効果は? Boehm が予測した「自動プログラミングによる保守削減」は部分的に実現しているか? - Ousterhout(2018)が説く「変更のたびに戦略的に振る舞う」姿勢は個々の開発者の心構えとして提示されるが、これを Boehm(1976)が言う保守の三機能(理解・修正・再検証)を支える組織的な仕組み(ドキュメント規約、トレーサビリティ、選択的再テストの支援ツールなど)としてどう制度化できるかは、両ソースを合わせても明確でない。 ## 関連 - [[ソフトウェアライフサイクル]] - [[ソフトウェア要件工学]] - [[@1976__IEEE-TC__Software Engineering]] - [[ソフトウェア変更管理]](wiki/concepts/ソフトウェア変更管理.md — 関連概念) - 章: [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 16 Modifying Existing Code]] - 実体: [[wiki/entities/A Philosophy of Software Design|A Philosophy of Software Design]] / [[John Ousterhout]] - 概念: [[戦略的プログラミング]] / [[コメント設計]] ## 出典 - Boehm, B. W. (1976). Software Engineering. *IEEE Transactions on Computers*, C-25(12), 1226–1241. - Swanson, E. B. (1976). The dimensions of maintenance. Proc. IEEE/ACM 2nd Int. Conf. Software Eng. - John Ousterhout, *A Philosophy of Software Design*, Yaknyam Press, 2018, Chapter 16.