ソフトウェア病理学Introduction

森　龍二

1

内容• Introductionの枕

• SPR法の起源

• 1960~70年代のIBMにおけるアセスメント

• 1980年代ITTにおけるアセスメント

• SPR評価法

• SPR法の参考文献

• 現在(90年代)のSPR法

• SPR法とSEI法の違い2

Introductionの枕• コンピュータ産業が生まれて50年

• ソフトウェア産業は「中年の危機」

• 新しいから面白いからソフトウェアが飛ぶように売れていた時代は終わり

• 適切な品質、値段、サポートの物しか売れない

• きちんと測って己を知ることがエンジニアリング

• 測ることは健康診断、その結果を見て治療

3

評価期間 治療法決定 治療実行

4

SPR法の起源• SPR:Software Productivity Research

• Capers Jones氏の会社

• 1960年代に米国公衆衛生局のシステムを手がけたことがきっかけ

• 医師の正確な診断に基づく治療法の決定はソフトウェアでも応用できることに気づいた

5

1960～70年代のIBMにおけるアセスメント

• 60年代にプロセス評価の常設専門組織を発足

• Watts Humphrey

• SEI(Software Engineering Institute)創始者

• その他CMM, PSP, TSP→「品質の父」

• Capers Jones

• SPR創始者

• Ron Radice

• SEIのアセスメントリーダー

• Humphrey, Radice=東海岸(SEI)、Jones＝西海岸(SPR)

6

Watts Humphrey

Capers Jones

Ron Radice

IBMラボの成果• IBMはSystem/360の成功等により資金が潤沢

→研究に投資

• この頃生まれたもの

• HIPO, JAD, インスペクション, ウォークスルー, 品質とコストの評価ツール, 形式手法

• SEIレベル(後のCMM, CMMI)の制定

• 巨大なメインフレームアプリの開発にマッチ

HIPO7

System/360

1980年代ITTにおけるアセスメント(1/2)

• ITT:米国の元・国際電話電信会社

• 企業買収による巨大コングロマリット

• 20の開発プラットフォーム、50の言語、25の設計方法、12の開発方法論

• プログラミング技術センターにいたすごい人たち

• Basili(GQM), Boehm(COCOMO), Brooks(人月の神話),

Gilb(Agile Inspection), James Martin(RAD), Roger Pressman, Putnam, Weinberg

8

ITTにおけるアセスメント(2/2)

• 80～90年代：グループウェアやコミュニケーションツール→分散開発のため

• CASEツール

• オンラインヘルプの出る第２画面（当時は紙のマニュアルが主流）

• ハンドヘルド可能(Sony Data Discmanぽい）

9

Sony Data Discman

SEIとSPRの分離• AT&Tの法的売却→研究所の統廃合→SEIとSPRの分離

• SEIのアセス法

• IBMの汎用機の発想

• 巨大だが均質なシステムのためのアセス方法

• SPRのアセス法

• 分散開発環境では言語、ツール、方法論はばらつく

• 医者のように対象を正しい診断し、その結果に基づいて正しく治療していけば単一の治療法は要らない

10

SPR評価法

11

SPR評価法• 評価対象と方法

• SPR評価法のゴール

• 全社に及ぼす戦略的因子

• 特定のプロジェクトに及ぼす戦術的因子

• 顧客満足因子

• SPRプロセスの構造

• 各因子の水準

12

評価対象と方法• 評価対象

• Function Point：300～5,000　従業員数:3～100

• 評価は有料なので優秀な方にバイアスあり

• ５つのやり方

1. SPR自身がコンサルタントを連れて行く

2. SPRのコンソーシアムESP(Enterprise Software Planning)の会員企業がライセンスを受けてSPRコンサルタントの元に実行

3. SPR法と簡単なアンケートがセットになったCHECKPOINTというツールを使う

4. DMR社とHP社は訓練の上ライセンスを受けて外部顧客に対して実施

5. SPR法に関する書籍・論文だけから情報を得て実施13

SPR評価法のゴール• SPR法は医学の診断過程をまねることを意図している

• 因子数は約400

• すべての因子を毎回使う訳ではない

• プロジェクト特性に合わせて

• 新規か派生か、大規模か小規模か

• アンケートの項目は１～２年おきに見直している

14

全社に及ぼす戦略的因子• 全社のプロジェクト・従業員に影響を及ぼす因子

• 例：給与、能力主義、経営方針...

• ビジネスプロセスの「動脈硬化」を明らかにするもの

• 例：以下の事務処理にかかる時間と必要なハンコの数

A. 新部署立ち上げ

B. ツール購入

C. 方法論導入

D. 外部セミナーの受講承認

E. メンバーの新規採用

F. 契約の完了

G. 資本設備の調達15

特定のプロジェクトに及ぼす戦術的因子

• ツール、設計、プログラミング言語• 特別な作業、ドキュメント、体制図

• オフィスの広さ、コミュニケーションの方法• 約200項目

• サービス残業の有無

• 60 square feet ≒ 2m四方→日本じゃ広い？

16

顧客満足因子• ユーザへのインタビュー結果• 組み込み系などユーザが特定できないものもある

• 例：そのソフトウェアは仕事にどれぐらい重要か？

• 最近特に重視されているポイント17

SPRプロセスの構造

1. キックオフ（アセスの目的等）

2. 対象プロジェクト選択

新規・派生、規模の大小、社内向け・外販、リアルタイム・バッチ処理

3. 個々のプロジェクトでデータ収集・解析

4. インタビュー

5. データ集計

6. 報告と改善提案18

各因子の水準• 5段階の順序尺度

1. 非常に良い(上位10%)

2. 良い(上位25%)

3. 平均(中間30%)

4. やや悪い(下位25%)

5. 悪い(下位10%)

• 小数点以下もあり(2.5, 3.25)

19

人材・期間・資源・コストの「ハード」データ

• 「ハード」＝アンケート以外の実測値

• データの例

• 仕様書やドキュメントの量

• ソースコード量

• プロジェクトの総ファンクションポイント数、またはフィーチャポイント数

• 要件定義から納品までの全作業

• 維持管理や派生開発の全作業

• 全ての活動の期間、コスト、リソース

• 雑費（法廷費、翻訳費、海外出張費、資金調達、パッケージ化費）

• ユーザの巻き込みとそのコスト20

品質・欠陥除去のハードデータ• 欠陥の発生箇所

• 要件定義

• 設計

• ソースコード

• ドキュメント

• 間違った修正（欠陥修正時に生み出された二次的欠陥）

• 欠陥防止法（プロトタイプ、JAD、QFD、TQM）

• 欠陥除去法（レビュー、インスペクション、監査、テスト）

21

SPR法の出力• レポートの骨子

• 強みと弱み

• 米国の平均と比較して

• おすすめの治療法

• 上記弱みを解決するための方法（ツール、組織改善）

• 生産性の基準値

• 品質の基準値

• 品質自体が曖昧な概念なため、「品質プロセスモデル」を作ってから基準値を構築する

22

参考文献• 特定分野向け論文

• 本

• Programming Productivity - Issues for the Eighties→不明

• Programming Productivity→「システム開発の生産性」

• Applied Software Measurement→「ソフトウェア開発の定量化手法」

• 論文

→多くが絶版または参照できず。orz23

SPR法の実績

24

すごい会社はどこが違う？(1/2)この3割が圧倒的な品質・生産性の差を

生み出す

7割近くは平均的な企業と同じ

優秀な企業 平均的 平均以下25

すごい会社はどこが違う？(2/2)そもそも開始点が高い改善スピードも速い

そもそも開始点が低く

改善ものろい

縦軸は何を表すか不明26

SPR法とSEI法の違い

27

SPR法とSEI法の違い• アンケートの選択肢の数

• SEI:２択(Yes/No)

• SPR:５択

• SPR法とSEI法の評価基準の対応表SPR効率度 SPR評価 SEI成熟度 SEI評価1.00 - 1.99 Excellent 5 Optimizing

2.00 - 2.49 Good 4 Managed

2.50 - 3.49 Average 3 Defined

3.50 - 3.99 Marginal 2 Repeatable

4.00 - 5.00 Poor 1 Initial

• SEI＝大規模企業・システム向け

• SPR＝中小以上、汎用性高い28

まとめ

29

Introductionまとめ• 機能・品質・価格のバランスが取れたソフトウェアしか売れない時代

• 適切な診断と治療による改善が不可欠• 年単位で評価・改善の実施・確認を行う• 優秀な会社と平凡な会社の違い：改善点は少なくても素早く改善

• SPR法とSEI法の細かい違いはあれど、いずれも同じ目的（改善と治療）を持っている

30