2010年7月に某所で講演した際の資料です。イベント名などを削除して公開版としました。歴史の話なので内容的には「古く」はなっていないです(^^)

1. (C) K. Tatsumi, 20101
ソフトウェア品質技術の
歴史を振り返る
～ ソフトウェア品質測定を中心に ～
辰巳 敬三
2010年7月6日

2. (C) K. Tatsumi, 20102
本日お話しすること
 コンピュータとソフトウェア技術の歴史
 ソフトウェア・マネジメントの観点の変遷
 ソフトウェア工学の進化過程
 ソフトウェア品質測定の歴史
 品質特性、品質モデル
 ソフトウェア信頼性モデル
 プログラム複雑度
 ソフトウェアメトリクスの歴史
 まとめ

3. (C) K. Tatsumi, 20103
2010.07.03 辰巳
▲ ▲ ▲ ▲
EDSAC(最初のﾉｲﾏﾝ型ｺﾝﾋﾟｭｰﾀ) IBM System/360 IBM System/370 Cray-1(スパコン)
▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲
UNIVAC1(世界初の商用ｺﾝﾋﾟｭｰﾀ) DEC PDP-1 DEC PDP-8 Apple PC IBM PC ▲ Apple Macintosh iPhone iPad
▲ ▲ ▲ Sun-1 ▲ ▲
IBM 701 IBM 704 Intel 4004MPU ● ● Sun SPARC Intel Pentium Pro
(科学演算用) (Apple社設立) (Sun Microsystems社設立)
▲ ▲ ▲ ▲ ▲ ▲ ▲
OS/360 UNIX CP/M MS-DOS UNIX System V Linux Windows NT
(4004MPU用OS) Netware ▲ ▲ ▲
▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ Windows 3.1 ▲ J2EE .NET ▲
SpeedCode FORTRAN FORTRAN COBOL LISP PL/I C言語 ▲ C++ ▲ Java ▲ Ajax
開発開始 ▲ ALGOL Smalltalk-72 ● Smalltalk-80 Eiffel ▲ ▲ ▲IE ▲ ▲ Ruby on Rails
FLOW-MATIC (Microsoft社設立) HTML/HTTP/WWW Netscape XML ●(Apache) SOAP ●(Eclipse)
▲SAGE(防空管制システム) ▲ ● ● ▲ ▲
▲SABRE(航空座席予約システム) CompuServe America Online Amazon.com ● ● Amazon Web Services Amazon EC2
▲マーキュリー計画 (商用オンラインサービス) Yahoo! Google Google Docs & Spreadsheets
▲ジェミニ計画 ● ● ☆
▲アポロ計画発表 ▲アポロ11号 有人月面着陸 eBay Salesforce.com クラウド・コンピューティング
▲ ▲ ▲ ▲ ▲ ▲ ▲
ETL Mark I<電気試験所> FUJIC<富士写真フイルム> NEAC2200 DIPS-1<電電公社> PC-8001 PC-9001 UNIXサーバ
(日本初のディジタル式自動計算機) (日本初の電子計算機)[真空管式] FACOM230 ▲ ▲ <日本電気> <日本電気> <日立,日本電気,富士通,三菱,沖>
[リレー式] ▲ HITAC8000 国産メーカ・3グループ化 計算機完成 ▲ ▲
▲ ETL MarkⅢ<電気試験所>[トランジスタ式] Mシリーズ<富士通・日立> FM-8<富士通> PCサーバ
FACOM100 ▲MUSASINO-1<電電公社>(日本初のパラメトロン計算機) ACOSシリーズ<日本電気・東芝> <三菱,富士通,日立> ▲
[リレー式] ▲HIPAC MK-1[パラメトロン式] COSMOシリーズ<三菱・沖電気> ▲ Express5800<日本電気>
▲NEAC-1101[パラメトロン式] 日本語ワープロJW-1<東芝> (WinNT3.5搭載PCサーバ)
▲ ▲ ▲
NEAC-1101用ローダなど NEAC2200用の最初のOS DIPS-103-10OS
HIPAC-101用記号入力ルーチン HITAC-5020用モニタ (タイムシェアリングシステム用OS)
▲ ▲ ▲
自動プログラム(FORTRAN)など(HIPAC 103用) FACOM 230-20/30用モニタ MCPII OSIV<富士通>、OS<日立>
▲ (マルチプログラミング処理) ACOS<日本電気・東芝>
FORTRAN/アセンブラ/IOCS/SORT(FACOM 222A) UTS<三菱電機>
▲ ▲ ▲ ▲ ▲ ▲ ▲
日本最初の商用コンピュータ稼働 国鉄座席予約システム 国鉄オンライン座席予約システムMARS101 JUNET PC-VAN Yahoo! JAPAN アマゾン・ジャパン
UNIVAC120(真空管式) ▲ MARS1 JAL国内線座席予約システム ▲ ▲ ▲
東京証券取引所、野村證券 気象庁予報部 東京オリンピック・リアルタイム記録管理システム NIFTY 楽天市場 iモード
▲ ▲ ▲ ▲
三和銀行 三井銀行オンラインバンキング 全銀システム ▲ ▲ ジャパンネット銀行
(初の銀行への導入) 第一次金融オンラインシステム 第二次金融オンラインシステム 第三次金融オンラインシステム (日本初のネット銀行)
▲ ▲ ▲ ▲1st ICSE
NATO Software Engineering Conference Symposium on Computer Software Reliability
▲ ▲ ▲ ▲ ▲ ▲
構造化定理 段階的詳細化 構造化設計 Booch法 UML UML 2.0
▲ ▲トップダウンプログラミング ▲ CASE ▲ ▲
構造化プログラミング ▲ ▲ データフロー図 (Computer aided オブジェクトモデル化技法 テスト駆動開発(TDD)
▲ 抽象モジュール 抽象データ型 software engineering) ▲
形式手法 ▲ERモデル オブジェクト指向ソフトウェア工学 ▲ ▲
▲ワーニエ法 ▲ジャクソン法 Software Architecture アジャイル宣言(Agile Manifesto)
▲ ▲ ▲ ▲ ▲
Royce Waterfall Model DoD-2167 ▲ DoD-2167A MIL-498 ▲ XP ▲
Spiral Model ISO/IEC 12207 ISO/IEC 14598
▲ ▲ (ｿﾌﾄｳｪｱﾗｲﾌｻｲｸﾙﾌﾟﾛｾｽ) ▲ (ｼｽﾃﾑﾗｲﾌｻｲｸﾙﾌﾟﾛｾｽ)
ISO 9000 CMM CMMI
▲ ▲ ▲ △ ▲ ▲ ▲
プログラム品質特性(Ruben) 品質特性(Boehm) 品質モデル(McCall) ▲ ISO9126標準化開始 ISO/IEC 9126 ISO/IEC 14598 ISO/IEC 14598
・・・・・・△ ▲ ▲ ▲ GQM(Basili) (ｿﾌﾄｳｪｱ製品の品質) (ｿﾌﾄｳｪｱ製品の評価)(ｿﾌﾄｳｪｱ測定ﾌﾟﾛｾｽ)
Lines of Code(LOC) Token count(Halstead) Function Point(Albrecht) COCOMO(Boehm) ▲
Putnamモデル IEEE Std 1061
▲ ▲信頼度成長(Coutinho) ▲ (Software Quality Metrics Methodology)
信頼性モデル(Jelinski&Moranda) 非同次ポアソン過程(Goel&Okumoto)
▲ ▲
サイクロマチック複雑度(McCabe) ソフトウェアサイエンス(Halstead)
●
Software Metrics(Gilb)
▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲
(デシジョンテーブル考案) デシジョンテーブルテスト ▲ 原因結果グラフ 状態遷移カバレッジ 同値分割/限界値分析 直交表 直交表 Pairwise ▲
▲ 同値分割/限界値分析的な考え方 ▲ ▲ ▲ ▲ (富士通) (AT&T) Component-based Software Testing
パス解析 カバレッジ(TER)カバレッジ(Cx) ドメインテスト データフローテスト ▲
▲ Architecture-based Testing
インスペクション(Fagan)
20102000 20051975 1980 1985 1990 19951965 19701950 1955 1960
ハードウェア
ソフトウェア
開発技法/開発方法論
マネジメント/プロセス
コンピュータの歴史とソフトウェア技術の歴史
コンピュータ時代の幕開け
「計算機」パラダイムの時代
「日の丸コンピュータ」
の開発促進期
分散処理ネットワーク
の普及期
IBMを中心とする
市場開拓期
ミニコンと汎用機ソフト
市場の成長期
ﾊﾟｿｺﾝ, ﾜｰｸｽﾃｰｼｮﾝ
の誕生・普及期
オープンシステムへの
転換期
「情報処理」パラダイムの時代
インターネットの
急成長期
社会インフラとしての
IT浸透期
「ネットワーク」パラダイムの時代
ソフトウェア
ハードウェア
世界
(米国)
日本
稼働システム
稼働システム
ITパラダイム
の変遷 (*1)
コ
ン
ピ
ュ
ー
タ
の
歴
史
ソ
フ
ト
ウ
ェ
ア
技
術
の
歴
史
品質モデル、品質測定
テスト、レビュー技術
会議・シンポジウム
品質特性・品質モデル
プログラム規模
コスト見積もり
ソフトウェア信頼性モデル
プログラムの複雑度
クラウド・コンピューティン
グの時代？？
ソフトウェア・マネジメントの観点(*2)
ソフトウェア・エンジニアリングの進化 (*3)
品質の時代機能の時代 スケジュールの時代 コストの時代
<反> 並行プロセス 対 順次プロセス<反> ソフトウェア工芸(Crafting) <合と反> 形式化とウォータフォールプロセス <合> 生産性と拡張性<正> ハードウェア工学的なソフトウェア工学 <反、部分的に合> 俊敏性と価値
コンピュータとソフトウェア技術の歴史

4. (C) K. Tatsumi, 20104
ソフトウェア・マネジメントの観点の変遷 (1/2)
Basili, Musa, “The Future Engineering of Software: A Management
Perspective,“ 1991 より
 1960年代: 機能の時代
 ITが社会に入り始めた
 社会的ニーズに応えられる機能の開発が主要課題
 1970年代: スケジュールの時代
 ソフトウェア危機(NATO会議,1968年)
 計画期間内にソフトウェア開発を完了させることが主要課題
 工程を明確化したライフサイクルモデルが紹介され始めた
ex. Royce waterfall model、品質モデル
1950 1980 19901960 1970 2000 2010
機能の時代 スケジュールの時代 コストの時代 品質の時代

5. (C) K. Tatsumi, 20105
ソフトウェア・マネジメントの観点の変遷 (2/2)
 1980年代: コストの時代
 ハードウェアコストの継続的低減、パソコンの出現
 ソフトウェアの価格の高さに目が向き始め、コスト/生産性が
主要課題
 各種のコストモデルが提案され、適用され始めた
ex. Function Point、Putnamモデル、COCOMO
 1990年代: 品質の時代
 ソフトウェアに対する社会の依存度の増大
 マスマーケットでの利用者が増え、ソフトウェアの故障や使
いにくさが深刻な事態を招くことが広く認識されはじめる
1950 1980 19901960 1970 2000 2010
機能の時代 スケジュールの時代 コストの時代 品質の時代

6. (C) K. Tatsumi, 20106
ソフトウェア工学の進化過程
 Boehmのヘーゲル的進化ビュー
 ソフトウェア工学の歴史を弁証法で捉える
テーゼ(正) 対 アンチテーゼ(反) → ジンテーゼ(合)
自律;
バイオ・
コンピュー
ティング
1990年代 2010年代2000年代1970年代 1980年代1960年代1950年代
COTS
工芸品
としての
ソフトウェア
テーゼ
(正)
ジン
テーゼ
(合)
アンチ
テーゼ
(反)
形式化;
ウォータ
フォール
生産性;
再利用;
オブジェクト;
ピープルウェア
計画駆動の
ソフトウェア
成熟度
モデル
アジャイル
メソッド
ハードウェア
のような
ソフトウェア
の扱い
リスクベース・
アジャイルと
計画駆動の
ハイブリッド;
モデル駆動開発
ソフトウェア
工学と
システム工学
の統合
バリューベース法;
コラボレーション;
グローバル開発;
エンタープライズ・
アーキテクチャ
ソフトウェアと
ハードウェアの違い,
技術者の不足
多くの欠陥
スケーラビリティ,
リスクマネジメント
プロトタイピング
Time to Market,
迅速な変化
スケーラビリティ
ドメイン工学
リスクマネジメント
準拠
プロセス・オーバヘッド
ソフトウェアの
付加価値
ソフトウェア－
システム工学
グローバルな
Systems
of
Systems
[出典] A View of 20th and 21st Century Software Engineering (Boehm), 28th ICSE, 2006のプレゼンテーションスライドから引用

7. (C) K. Tatsumi, 20107
ソフトウェア品質測定の歴史
 品質特性、品質モデル
 ソフトウェア信頼性モデル
 プログラム複雑度

8. (C) K. Tatsumi, 20108
品質特性、品質モデル
ソフトウェア品質は，ユーザのニーズを満たすために様々な
視点の品質特性から評価されなければならない
 品質モデル
 品質要求及び品質評価の基礎を与えるような特性の集合及び特性間
の関係(JIS X0133)
 主な歴史
 Rubey & Hartwick(1968年)
• プログラムの品質の評価方法に関する最初の論文
• プログラムコードの「属性」と「メトリクス」を定義
 Boehmらの品質モデル(1973年)
• 品質を評価するための観点を初めて階層化して表現
 McCallらの品質モデル(1977年)
• 過去の論文で提案された品質要因を集約、整理して体系化
• 品質をファクタ，クライテリア，およびメトリクスの三階層構造で表現
 ISO/IEC 9126(1991年)
• 品質モデルの国際標準化

9. (C) K. Tatsumi, 20109
Boehmのモデル
移植性
信頼性
効率
操作性
ﾃｽﾄ容易性
理解性
更新性
装置独立性
自己包含性
正確性
堅固性・
ｲﾝﾃｸﾞﾘﾃｨ
無矛盾性
計測性
装置効率
ｱｸｾｽ可能性
伝達性
自己記述性
構造性
簡潔性
明瞭性
拡張性
初期運用
(As-is Utility)
保守性
運用全体
(General Utility)
完全性
 1973年に米国標準局(NBS)の委託研究
でTRW社のBoehmらが品質特性を階層
構造化するとともにメトリクスを定義
[出典] Boehm, et al., "Characteristics of Software Quality," TRW-SS-73-09, 1973

10. (C) K. Tatsumi, 201010
McCallのモデル
正当性
信頼性
効率
ｲﾝﾃｸﾞﾘﾃｨ
ﾃｽﾄ容易性
再利用可能性
相互互換性
アクセス監査
訓練
意志伝達性
単純性
簡潔性
計測性
装置独立性
発展性
一般性
モジュラリティ
ｿﾌﾄｳｪｱ・
ｼｽﾃﾑ独立
自己記述性
伝達共通性
データ共通性
製
品
運
用
製
品
移
行
運用性
利用容易性
保守性
柔軟性
移植性
製
品
改
訂
アクセス制御
記憶効率
実行効率
正確性
エラー容認性
一貫性
完全性
追跡可能性
Factor Criteria Metric
 1977年に米国空軍の委託を
受けGE社のMcCallらが体系化
 1977年以前に発表された論文
で提案されている品質特性を
抽出し、集約整理している
 利用者視点(ファクタ)，開発者
視点(クライテリア)，および測
定可能なレベル(メトリクス)を
結び付けた最初のソフトウェア
品質モデルとして評価が高い
メトリクス
メトリクス
メトリクス
[出典] McCall et al., “Factors in Software Quality,“ RADC-TR-77-369, 1977

11. (C) K. Tatsumi, 201011
ISO/IEC 9126
外部及び内部
品質
機能性 信頼性 使用性 効率性 保守性 移植性
合目的性
正確性
相互運用性
セキュリティ
機能性標準適合性
成熟性
障害許容性
回復性
信頼性標準適合性
理解性
習得性
運用性
魅力性
使用性標準適合性
時間効率性
資源効率性
効率性標準適合性
解析性
変更性
安定性
試験性
保守性標準適合性
環境適応性
設置性
共存性
置換性
移植性標準適合性
利用時の品質
有効性 生産性 安全性 満足性
 1985年から作業が開始され1991年に国際標準として出版(翻訳版はJIS
X0129として発行)
 「内部品質及び外部品質」、「利用時の品質」の二つのモデルを規定
品質副特性
品質特性
品質特性
[出典] JIS X 0129-1:2003 ソフトウェア製品の品質 － 第1部：品質モデル

12. (C) K. Tatsumi, 201012
ソフトウェア信頼性モデル
ソフトウェアの信頼性を定量的に評価するための数理モデル。
潜在障害数，障害率，平均故障間隔などの信頼性評価尺度を
推定する。動的モデルと静的モデルがある
 ソフトウェア信頼度成長モデル(動的モデル)
 ソフトウェアを実行して、障害の検出と修正の繰り返しによる信頼度の
経時変化をモデル化し、テストや運用段階の実測データからソフトウェ
アの信頼度を推定する
 主な歴史
 1960年代後半からさまざまな取り組みが開始。ハードウェアの信頼性
理論の応用を試みるも成功せず
 Jelinski & Moranda(1972年)
• ソフトウェアの信頼性評価に関して理論的考察を行った最初の論文
• 潜在エラーの総数と稼働時間の関係(ハザードレート)から説明するモデル
 Goel & Okumoto(1979年)
• 単位時間当たりの発見エラー数は、その時刻の残存エラー数に比例
• 時刻tで観測する累積エラー数を非同次ポアソン過程としてモデル化

13. (C) K. Tatsumi, 201013
プログラム複雑度
 複雑度のメトリクス
 ソフトウェアの開発，理解，保守が，どの程度困難かを数値
で示し，ソフトウェアの品質、スケジュール、投入工数などの
予測にもちいる
 主な歴史
 サイクロマチック複雑度 (McCabe,1976年)
 ソフトウェアサイエンス (Halstead,1977年)
 その他のメトリクス
• データ構造メトリクス(データ種類別出現数、データの活
性区間、データの参照区間)
• 制御構造メトリクス(最大交差数、ノット数、ネストの深さ)

14. (C) K. Tatsumi, 201014
サイクロマチック複雑度
 プログラムの制御フローをグラフ化し、以下の式で求
められる数で複雑度を表現
サイクロマチック数 ＝ 辺の数 － 頂点の数 ＋ ２
 1関数内のサイクロマチック数
 10以内が望ましい
 20以上は避けるべき
 パステストで実施すべき
テストケース数の上限も表す
パス1 : a → b → e → f
パス2 : a → b → e → a → b → e → f
パス3 : a → b → e → b → e → f
パス4 : a → c → f
パス5 : a → d → c → f
a
b c d
e
f
入口
出口
サイクロマチック数=9-6+2=5
[出典] T. J. McCabe, "A Complexity Measure," IEEE Transactions on Software Engineering,1976

15. (C) K. Tatsumi, 201015
ソフトウェアサイエンス
 ソフトウェアサイエンス理論
 プログラミング作業とは、いくつかのプログラムトークン(演算子やオペ
ランド)を選択したり組み合わせること
 複雑性や生産性は、これらの基本要素の出現回数の関数で表せる
 基本測定量
n1 = プログラム中の演算子の種類数 (算術演算子、比較演算子、関数名 など)
n2 = プログラム中のオペランドの種類数 (変数、定数、ラベル など)
N1 = 演算子の出現数
N2 = オペランドの出現数
 評価尺度の導出
プログラムの大きさ(ビット数) V = (N1 + N2) log2(n1 + n2)
プログラムの水準(推定値) L = 2n2 / n1N2
プログラミングの困難さ(推定値) D = 1 / L = n1N2 / 2n2
プログラミング労力(推定値) E = V / L = n1N2 (N1 + N2) log2(n1 + n2) / 2n2
など
[出典] 山田,高橋, ソフトウェアマネジメントモデル入門, 共立出版,1993

16. (C) K. Tatsumi, 201016
1950 1980 19901960 1970 2000 2010
混乱期 胎動期 成熟期活動期 反抗期
山浦恒央, “日本語版によせて－10分で分かるメトリクス” より
「初めて学ぶソフトウェアメトリクス」(パトナム、マイヤーズ),日経BP,2005
 1968年～1977年：混乱期
 1968年にNATOの会議で初めて「ソフトウェアエンジニアリング」という言
葉が使われた
 プログラミングは職人芸
 ソフトウェア開発プロジェクトでは工程、品質、コストが制御できず
 1978年～1982年：胎動期
 「計測できなければ、制御できない」(ケルビン卿)を「計測すれば、制御
できる」と変形し、何かを計測して、工程、品質、コストを制御できないか
と考えるようになった
 ソースコード行数、バグ数の計測以外に、サイクロマチック数、ソフトウェ
アサイエンスなど、いろいろなメトリクスが提案された
ソフトウェアメトリクスの歴史 (1/3)

17. (C) K. Tatsumi, 201017
ソフトウェアメトリクスの歴史 (2/3)
1950 1980 19901960 1970 2000 2010
混乱期 胎動期 成熟期活動期 反抗期
 1983年～1987年：活動期
 サイクロマチック数とソフトウェアサイエンスを中心に、メトリクスが実地
で適用され、それらの相関関係の研究が盛んになった
 適用への「慎重派」が、メトリクスの意味を見直し始めた
３大論争：科学的根拠は？ 何を計測？ いつ計測？
 1988年～1992年：反抗期
 計測に予想以上に時間と金がかかるが、その割には効果が出ない
 メトリクス同士が負の相関関係を示すといった研究結果が発表され、ソ
フトウェアサイエンスへの幻想が消える
 メトリクスに対する現実的な考えが広がり、品質そのものを計測しようと
するが、話が急速に大掛かりになり、結局は空中分解する
 昔ながらのソースコード行数と発生バグ数の計測に回帰する

18. (C) K. Tatsumi, 201018
ソフトウェアメトリクスの歴史 (3/3)
1950 1980 19901960 1970 2000 2010
混乱期 胎動期 成熟期活動期 反抗期
 1993年～：成熟期
 元の「混乱期」に戻ったが、一部ではメトリクスが定着し、効果を上げた
 ソースコード行数と発生バグ数を軸に、各開発組織で独自のメトリクスを
開拓し、メトリクスの目的、意味、意義を自覚し始めた
 メトリクスを効果的、実践的に使うための条件が分かってきた
• 計測に時間、労力がかからない
• 安く計測できる
• 客観性がある
• 計測値がソフトウェア開発の作業、要素と強い相関関係がある
• 個人の査定目的で使わない

19. (C) K. Tatsumi, 201019
まとめ
 歴史を振り返ってみて、何か気付きが得られた
でしょうか?
 技術の流れや出現背景を知ることで、より技術へ
の理解が深まるのではないでしょうか。
 世界のメトリクスの歴史は、あなたの部門で品質測
定を根付かせる過程と同じかもしれません。
 深く知りたいことがあればSQuBOKガイドを参
照してみてください。参考文献リストがあります。