> [!abstract] 概要(abstract 日本語訳) > 本論文は「ソフトウェアエンジニアリング」という用語の定義と、当該分野の現状および将来動向のサーベイを提供する。サーベイはソフトウェアライフサイクルの各フェーズ——要件工学、設計、コーディング、テスト、保守——ならびにソフトウェア管理と統合的技術管理アプローチの全体領域で利用可能な技術をカバーする。技術の詳細な仕組みよりも適用領域(どこで・いつ機能するか)の議論を主眼とする。詳細については 104 件の文献リストを参照されたい。 ## 論文情報 - **著者**: Barry W. Boehm(TRW Systems and Energy Group, Redondo Beach, CA) - **発表媒体**: IEEE Transactions on Computers, Vol. C-25, No. 12 - **発表年月**: 1976 年 12 月 - **ページ**: pp. 1226–1241 - **文献 PDF**: `[[.raw/papers/boehm-sw-eng-paper.pdf]]` ## 概要 ソフトウェアエンジニアリングの定義とライフサイクル全体の技術・管理手法を 1976 年時点の観点でサーベイした。要件工学・設計・プログラミング・テスト・保守・管理の各フェーズにわたり、現行実践・最前線技術・今後の動向を論じる。結論として、当時のソフトウェアエンジニアリングは「科学的知識の実際的応用」という定義に照らすとハードウェアエンジニアリングと比べ極めて未熟であることを指摘し、特に応用ソフトウェアの要件・設計・テスト・保守の領域(Area 2)に科学的基礎がほぼ存在しないと述べる。 ## 定義 ソフトウェアエンジニアリングの定義(本論文による): > **Software Engineering**: The practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate, and maintain them. この定義における三つの主要ポイント: 1. 「設計」はソフトウェア要件工学という重要活動を包含する広義の解釈が必要である。 2. ソフトウェアライフサイクル全体——再設計・修正(保守)を含む——を対象とする。 3. 「科学的知識」の蓄積はエンジニアリング分野を構築するには非常に小さく、それゆえ挑戦的である。 ## 問題設定 1970 年代中盤の背景: - 米国のソフトウェア年間コスト: 約 200 億ドル - ソフトウェア需要の成長率(1975–1985): 年率 21–23% - ソフトウェア供給の成長率(労働力 × 生産性): 年率 11.5–17% - 需給ギャップが拡大する中でコスト効率と信頼性を両立させる必要がある。 ## ソフトウェアライフサイクルと各フェーズ **Figure 2: Software life cycle(ソフトウェアライフサイクル)** ![[_attachments/boehm-sw-eng-paper/fig02-software-life-cycle.png]] (Figure 2. システム要件 → ソフトウェア要件 → 予備設計 → 詳細設計 → コード/デバッグ → 開発テスト → 受入テスト → 運用・保守・再検証の段階的プロセス。各フェーズに VALIDATION が付随する。Source: Boehm 1976, p.1227.) ## 要件工学 ### 重要性 要件仕様の欠如がもたらす問題: 1. トップダウン設計が不可能(「トップ」が明確でないため) 2. テストが不可能(テスト対象がないため) 3. ユーザーが排除される(何を作るかが不明なため) 4. 管理が効かない(プロジェクトが何を生産するかが不明なため) 欠陥修正コストは発見フェーズが遅れるほど指数的に増大する。IBM・GTE・TRW のデータを統合した以下の図が典型的根拠となっている。 **Figure 3: Software validation: the price of procrastination(後回しのコスト)** ![[_attachments/boehm-sw-eng-paper/fig03-cost-to-fix-error-by-phase.png]] (Figure 3. 縦軸は「誤りを修正する相対コスト」(対数スケール)。要件フェーズで発見・修正すると相対コスト 0.1–0.2、コードフェーズで 1(基準)、運用フェーズでは 15–100。TRW 調査の中央値はおよそ指数的傾向を示す。Source: Boehm 1976, p.1228.) ### 現状技術(1976 年) - **ISDOS**(University of Michigan、Teichroew ら): 問題記述言語 PSL と解析器 PSA。商用採用実績あり。ビジネスシステム向けで、リアルタイム要件・設定管理・トレーサビリティには限界。 - **SREP**(TRW / US Army BMDATC): 要件記述言語 RSL と検証システム REVS。刺激応答ネットワーク(R-Net)によるリアルタイム要件の表現、自動シミュレーション生成、設定管理・トレーサビリティを実装。弾道ミサイル防衛向けで汎用性に課題。 - **自動プログラミング研究**(DARPA 支援): 自然言語処理で要件から仕様を抽出するアプローチ(Balzer, USC-ISI)と、特定領域に絞るアプローチ(Martin, MIT)の二方向。 ## 設計 ### 要件/設計のジレンマ 要件の妥当性検証には設計を行う必要があり、設計を始めるには要件が完全である必要があるというジレンマ。1970 年代には設計の自由度(CPU・周辺装置・プログラミング言語・OS・データ管理システム)が 1950 年代比で急増しており、設計の選択肢爆発が問題となっていた(Table I: 1970 年代の CPU 選択肢は約 200、1950 年代は 5)。 ### 設計エラーの優位性 **Figure 4: Most errors in large software systems are in early stages(エラーは初期フェーズに集中)** ![[_attachments/boehm-sw-eng-paper/fig04-design-vs-coding-errors.png]] (Figure 4. TRW・IBM の複数プロジェクトにわたるエラー分析。設計エラーはコーディングエラーに対して概ね 60:40 を超える比率で多い。TRW C+C の開発・保守、IBM OS の開発・保守いずれも設計バグ優位。Source: Boehm 1976, p.1231.) ### 主要技術 - **トップダウン設計**: 制御構造を最上位から段階的に細分化。抽象化レベル(バーチャルマシン)の観点から設計を明確化。 - **モジュール化**: Structured Design(Stevens, Myers, Constantine)による結合度分類(偶発的→機能的)と Parnas のモジュール化基準。 - **設計表現**: フローチャート(柔軟だが非構造化の恐れ)、HIPO 技法(IBM)、構造チャート、PDL(Caine, Farber, Gordon)——英語テキストで処理を記述する構造化プログラム表現。 ## プログラミング 1976 年時点の潮流として構造化コード(SEQUENCE, IF-THEN-ELSE, CASE, DO WHILE, DO UNTIL の限定制御構造 + 階層的ブロック構造)への移行が進む。Pascal(Wirth)、Concurrent Pascal(Brinch-Hansen)、ALPHARD(Wulf)、CLU(Liskov)などの新言語が台頭。DoD の高水準言語要件定義(Tinman)が将来標準化をけん引する見込み。 ## テストと信頼性 ### 現状 テスト・信頼性活動が開発コストの 40–50% を占めるにもかかわらず、初回実行失敗後に事後対応として行われることが多い。テスト終了基準は「予算切れ」が一般的。 ### 主要技術 - **ソフトウェア信頼性モデル**: ハードウェア由来のモデルを適用したが不適合。入力空間・出力空間のサンプリングモデル(Nelson)が現象論として整合的。 **Figure 5: Input space sampling provides a basis for software reliability measurement** ![[_attachments/boehm-sw-eng-paper/fig05-input-space-sampling.png]] (Figure 5. プログラムを入力空間から出力空間への写像として捉え、N 個のランダムな代表入力を処理して M 個の失敗を観測する最小分散不偏推定量アプローチ。入力空間の規模・修正の反映・入力の代表性確保が実用上の課題。Source: Boehm 1976, p.1236.) - **静的解析**: コンパイラ診断、コード監査プログラム、制御フロー・到達可能性解析、データ使用・特異点解析。 - **テストケース準備・監視**: 構造解析プログラムによるパスカバレッジ、動的型チェック・表明チェック。 - **シンボリック実行**: 変数名を記号として操作し実行パスごとに出力式を生成(EFFIGY, SELECT システム)。プログラム証明とテストの中間的手法。 - **プログラム証明**: 仕様を論理命題として表現し、プログラム実行文を論理変換で等価性を証明。1973 年時点で 100 行を証明するのに約 1 人月の専門家の作業が必要。Fortran・Cobol では利用困難で Pascal など公理的定義を持つ言語でのみ実用的。 - **耐障害ソフトウェア**: Randell の「回復ブロック」概念——独立にプログラムされた代替実行単位で補償するアプローチ。 ## 保守 ### 保守の規模と重要性 ソフトウェア保守はライフサイクルコストのおよそ 70% を占めるにもかかわらず、1976 年時点では非常に軽視されていた。 **Figure 6: Software life-cycle cost breakdown(ライフサイクルコスト内訳)** ![[_attachments/boehm-sw-eng-paper/fig06-lifecycle-cost-breakdown.png]] (Figure 6. 4 組織(GEN. TEL. + ELECT., USAF C+C NO. 1, USAF C+C NO. 2, GENERAL MOTORS)の 10 年ライフサイクルコストに占める保守と開発の割合。すべての組織で保守が 60–80% を占める。Source: Boehm 1976, p.1236.) 実績データ: - General Motors: 保守 75%(Elshoff [80]) - GTE: リアルタイムソフトウェアの 10 年コストの 60%(Daly [5]) - USAF C+C NO. 1: 67%、NO. 2: 72% - ある航空機コンピュータでは開発コスト約 75 ドル/命令 に対して保守コスト最大 4000 ドル/命令 ### 保守の分類 - **ソフトウェア更新(software update)**: 機能仕様の変更を伴う修正 - **ソフトウェア修理(software repair)**: 機能仕様を維持したまま修正 - **修正保守(corrective maintenance)**: 処理・性能・実装の不具合を修正 - **適応保守(adaptive maintenance)**: 処理環境・データ環境の変化への対応 - **完全化保守(perfective maintenance)**: 性能・保守性の向上 保守の三機能: (1) 既存ソフトウェアの理解、(2) 修正、(3) 再検証。 ### Fig. 1: ハードウェア・ソフトウェアコスト動向 **Figure 1: Hardware-software cost trends(コスト動向 1955–1985)** ![[_attachments/boehm-sw-eng-paper/fig01-hardware-software-cost-trends.png]] (Figure 1. 横軸 1955–1985、縦軸はコスト全体に占める割合(%)。ハードウェアのシェアは急落し、ソフトウェア開発とソフトウェア保守のシェアが増大する。保守の急増トレンドはこの論文で新たに追記された。Source: Boehm 1976, p.1227.) ## ソフトウェア管理 ### 管理上の主要問題 - 計画不足: 不必要な作業・アイドル時間・同期不良 - 統制不足: 計画が更新・活用されない - リソース見積もり不足: コスト・スケジュール推定の困難さ - 不適切な管理担当者: 設計者思考で管理する傾向 - 責任構造の拡散 - 不適切な成功基準: 「コーディング進捗率」重視が要件・設計検証・テスト計画を軽視させる - 重要活動の先送り ### 統合的アプローチ - **IBM のトップダウン構造化プログラミング + チーフプログラマチーム**: チーフが設計・コーディング・統合・チーム管理・コードレビューをすべて担当。チーフプログラマの概念は混在した結果。 - **TRW ソフトウェア開発方法論**: 高水準・詳細管理目標の連携体系、自動化支援ツール群(標準遵守チェッカー、テスト充足度チェッカー、プロセス構築補助、コスト・スケジュール報告)、Unit Development Folder による統一的文書管理。 - **SDC Software Factory**: FACE(Factory Access and Control Executive)を中核とした野心的な自動化・統合環境。評価段階につき成否は未確定(1976 年時点)。 - **ARPA National Software Works (NSW)**: ARPANET 上の多様な開発ツールへのアクセスを提供する Works Manager。初期バージョンが稼働中。 ## 結論: Area 1 vs Area 2 本論文の最終結論として、Table II「既存科学的原理の適用可能性」を提示する(Table II: Applicability of Existing Scientific Principles / p.1239)。四次元の評価: | 次元 | ソフトウェアエンジニアリング | ハードウェアエンジニアリング | |---|---|---| | ライフサイクル全体 | コンポーネント構築・詳細設計には原理あり、システム設計・統合にはほぼなし | 多数の原理が適用可能 | | アプリケーション全体 | 「システム」ソフトウェアには一部あり、応用ソフトウェアにはほぼなし | 多数適用可能 | | エンジニアリング経済学 | システム経済に適用できる原理はほぼなし | 多数適用可能 | | 技術者向け訓練 | 技術者向けに定式化された原理はほぼなし | 多数定式化済み | - **Area 1**(専門家による詳細設計・コーディング、経済的独立的文脈): 科学的原理がある程度存在。 - **Area 2**(技術者による要件解析・設計・テスト・保守、経済駆動の文脈): 科学的基礎がほぼ皆無。 最も切迫したソフトウェア開発問題は Area 2 に集中しているにもかかわらず、コンピュータサイエンス分野は自動機械理論・構文解析・計算可能性などの Area 1 的な問題に取り組む傾向がある。Area 2 研究は困難だが、実用的ソフトウェア開発・保守への見返りははるかに大きい。 ## 強み / 弱点・課題 **強み** - 1976 年時点の全技術領域を体系的に整理した先駆的サーベイとして 50 年後も参照価値が高い。 - IBM・GTE・TRW の実証データに基づく定量的主張(修正コスト比率、保守比率)は今日でも引用される。 - Area 1 vs Area 2 の二分類がソフトウェア科学の成熟度議論の重要な枠組みを提供した。 **弱点・課題** - 1976 年の技術水準を反映しており、特定ツール(ISDOS, SREP, SDC Software Factory)はほぼ廃れた。 - プログラム証明・自動プログラミングの「近い将来」という楽観的見通しは実現に至らなかった。 - Area 2 問題への処方箋を提供していない(問題の提示にとどまる)。