病理学第3章

24
ソフトウェア病理学 第3章:最も深刻なソフトウェアリスク 森 龍二 1

Transcript of 病理学第3章

Page 1: 病理学第3章

ソフトウェア病理学第3章:最も深刻なソフトウェアリスク

森 龍二

1

Page 2: 病理学第3章

第3章の枕ソフトウェアはあらゆるエンジニアリング活動の中で最

もリスクにさらされやすい

大事なのはリスクの深刻度

本章で扱うのは特に深刻な10のリスク

軍関係のプロジェクトのように厳密なプロセスがあって

もその外にリスクは存在する

一つ二つなら耐えられるが三つ以上だとやばい

2

Page 3: 病理学第3章

6つのプロジェクトクラス(復習)

経営情報システム(MIS)→内製の基幹システム

システムソフトウェア→組み込み系

商用ソフトウェア→OfficeやCADなど

軍用ソフトウェア

請負契約・アウトソース→いわゆるSI

エンドユーザソフトウェア→いわゆるEUC

3

Page 4: 病理学第3章

10大リスク1.不正確なメトリクス

2.不適切な計測

3.過酷なスケジュール

4.管理者の不当行為

5.不正確なコスト見積もり

6.銀の弾丸症候群

7.徐々に増大するユーザ要

8.低品質

9.低生産性

10.プロジェクトの中断

4

Page 5: 病理学第3章

1.不正確なメトリクス(1/3)Line Of Code(LOC)は言語によるばらつきがある

LOCの6つの問題点

単一の言語でも標準化されていない(コメントの数え方?)

400近くあるコンピュータ言語間での変換ルールがない

生産性が低く出るなど、高級言語での矛盾した振る舞い

計画・設計・文書作成など、実装以外の作業が測れない

要件定義・設計など、実装以外の欠陥が測れない

要件定義の段階でソースコードサイズを見積もることが困難5

Page 6: 病理学第3章

1.不正確なメトリクス(2/3)固定費が増大すると生産性は下がり、一個あたりのコストは増大する

同じ機能の実装例

6

要件 設計 文書

Assembler

Ada

1ヶ月

7ヶ月

10000LOC

2000LOC

35FP

35FP3ヶ月

LOC FPASM 10000/10=1000 35/10=3.5

Ada 2000/4=500 35/4=8.75

固定費

(/人月)※一人で実装

実装費

Page 7: 病理学第3章

1.不正確なメトリクス(3/3)LOCを使うと何が問題か

(A)生産性や品質が逆に出てしまうようなメトリクスを使うのはプロとし

てはがっかり

(B)科学的・工学的研究には結果をきちんと測定できることが必要。LOC

は多くの研究者を惑わせた

リスクの低い順ランキング

7

1 MIS 50%近くはFPを使っている2 請負・アウトソース ISSC(US), TATA(India), DRM(Canada)採用3 システムソフト Feature Point, 3D FP(Boeing)など4 軍用ソフト SEIが採用をしぶったが徐々に浸透5 商用ソフト 有名どころのSWベンダーでも関心が薄い6 エンドユーザ 一人でやってるから測るわけがない

90年代だ

から?

Page 8: 病理学第3章

2.不適切な計測(1/2)大きなコスト要因が漏れたり省略されたりする。全く測ってい

ないプロジェクトもある

漏れの平均は35%~50%

コスト追跡システムからの漏れがまずい点

未来のコスト見積もりに過去データが使えなくなる

コスト見積もりの正確性があやふやになる

最も漏れやすいのはユーザ自身のワーク

MISで20%, 軍用で25%を超える8

Page 9: 病理学第3章

2.不適切な計測(2/2)

リスクが少ないランキング

9

1 軍用ソフト 25%以上漏れる場合あり。システム外でタスク化2 請負・アウトソース time & material→正確、fixed price→だだ漏れ3 MIS 大手はルーチンワークとしてユーザコストを記録4 システムソフト 大手(AT&T, IBM)はコスト追跡システムを保有5 商用ソフト 徹夜は当たり前、時間の記録なし6 エンドユーザ アプリ構築にいちいち時間を記録しない

Page 10: 病理学第3章

3.過酷なスケジュール(1/2)不合理なスケジュールを押しつけられるケースは全プロジ

ェクトの65%で発生

2つの大きな原因

スケジュールが法令・要件・その他の政治力によって

あらかじめ決まっている

名目上の要件定義フェーズが終わっても要件の変更が

続いている

10

Page 11: 病理学第3章

3. 過酷なスケジュール(2/2)

リスクが少ない順のランキング

11

1 エンドユーザ 空き時間で作られ、時間の制約はほぼない2 システムソフト 過去の経緯から必要な時間がほぼわかっている3 MIS 残り4つのドメインはほぼ同じ傾向。3 商用ソフト

残り4つのドメインはほぼ同じ傾向。

プロジェクトサイズに比例。3 請負・アウトソース

プロジェクトサイズに比例。

1000FP以上はほぼ経験する。5000FP以上は100%。3 軍用ソフト※ 1000FP以上はほぼ経験する。5000FP以上は100%。

※軍の見積もりツール:ASSET-R, CHECKPOINT, COCOMO, PRICE-S, REVIC, SPQR/20, SLIM

Page 12: 病理学第3章

4.管理者の不当行為(1/2)ソフトウェア業界では最も深刻な問題の一つ

根本原因:大学・企業の双方でプロマネの基礎教育がなって

いない

プロマネがプロジェクトで行う6つのタスク

12

1 sizing 規模の見積もり2 estimating リソースその他の見積もり3 planning プロジェクト計画作成4 tracking 計画と実績の追跡・監視5 measurement 実績の計測6 assessment 計測の結果に対して診断

Page 13: 病理学第3章

4. 管理者の不当行為(2/2)

13

1 エンドユーザ 自分で管理するからほぼノーリスク2 システムソフト 優れた自前の教育コースがある3 軍用ソフト 空軍のBOLD STROKEセミナー4 請負・アウトソース 一部の有能なマネージャの力量に頼っている5 MIS 大きな違いはない。結局は教育に使えるコストが5 商用ソフト

大きな違いはない。結局は教育に使えるコストが

潤沢な企業はよい仕事をしている。

リスクが少ない順ランキング

Page 14: 病理学第3章

5.不正確なコスト見積もり見積もりで50種類、プロジェクト計画で70種類のツールがある(93年)

コスト見積もりツールを使っているプロマネは全体の25%以下

プロジェクト計画ツールは50%以下

軍では複数のツールを比較し、収束点を見つける

14

1 軍用ソフト ASSET-R, CHECKPOINT, COCOMO, GECOMO, PRICE-S, REVIC, SEER, SOFTCOST, SLIM, SPQR/20

2 MIS Bridge, BYL, ESTIMACS, SPQR/20, CHECKPOINT(要カスタマイズ)

CASEツール(FirstCase, Foundation , PACBASE, IEF, LINC)

3 請負・アウトソース FPベースのツールが浸透中。オフショアの話

4 システムソフト CHECKPOINT, SLIM, ASSET−R

5 商用ソフト ツール軽視の傾向。CHECKPOINTにオプションあり

6 エンドユーザソフト 必要なし

Page 15: 病理学第3章

6.銀の弾丸症候群単一の技術(CASE, TQM, OO)を導入することで生産性や品質

が向上すると信じているプロジェクトは全体の65%に及ぶ

複数の技術を同時並行で用いることが肝

15

1 システムソフト 多面的アプローチ(ツール、社会的要因、環境)2 請負・アウトソース 銀の弾丸を無心に信じることがない(ホント?)3 商用ソフト オブジェクト指向を過信しすぎた4 軍用ソフト 自分で調べるものの、DoD標準の過信の傾向あり5 エンドユーザソフト エンドユーザ向けの銀の弾丸そのものが少ない6 MIS 銀の弾丸の宝庫。大半が嘘で実証データに乏しい

リスクが少ない順ランキング

Page 16: 病理学第3章

7.徐々に増大するユーザ要求(1/2)月に1%の変更量が目安(FP換算)

複利で効いてくる→三年経つと 1.01^36=1.43

軍と民間の違い

変更の割合はほぼ同じ

軍はコスト追跡システムによって変更は適宜課金される

(民間は泣き寝入り?)

軍の方が開発期間が若干長い→変更量多い

16

Page 17: 病理学第3章

7. 徐々に増大するユーザ要求(2/3)

17

1 エンドユーザソフト 開発期間は長くても一ヶ月→変更割合は1%2 MIS 予防法:Joint Application Design(JAD), QFD3 請負・アウトソース 一番の予防法=課金(コンティンジェンシー?)4 商用ソフト 真のユーザより経営層の意向が優先される場合も

5 軍用ソフト契約形態:Time & Material→変更大歓迎

Fixed Price→変更大反対6 システムソフト 直接のユーザがいない。開発期間長い

リスクが少ない順ランキング

Page 18: 病理学第3章

7. 徐々に増大するユーザ要求(3/3)軍用ソフトの要件拡大問題への対応

NAVAIRグループ

進んだ自動化(?)により要件から高速でプロトタイピング

要件が早く固まりすんなり実現できた

George Mason大

早い頻度で変わるもの、共通の要件、潜在的に問題のあり

そうな要件を観察

自動サイジングと見積もりの可能性を示す

18

Page 19: 病理学第3章

8.低品質潜在的欠陥数はFPあたり5個(米国平均)

累積的除去率(DRE)は85%以下

(1-0.85)*5=0.75個/FPが市場に流出

19

1 軍用ソフト 潜在個数は6~7個/FPだが、DREが高い(95~99%)1 システムソフト コンピュータ製造、通信系、航空系2 商用ソフト ベータテストで多数のユーザを利用して品質を上げる3 請負・アウトソース 品質が契約に入っていれば高品質4 MIS 人海戦術によるテストに支えられている5 エンドユーザーソフト 品質管理はお粗末。担当者が転職すれば詰む

リスクが少ない順ランキング

Page 20: 病理学第3章

9.低生産性(1/2)生産性の低い4つの要因

1) 書類作成作業

2) 欠陥除去

3) 会議・コミュニケーション

4) コーディング

「プロジェクト中断」と深い関連

納期1年遅れ、100%の予算オーバー

中断の目安:2FP/人月以下

20

軍用ソフト 3

システムソフト 4

情報システム 8

米国平均 5

単位:FP/人月

1 エンドユーザソフト 25~1002 商用ソフト 15~203 請負・アウトソース 10~124 MIS 85 システムソフト 46 軍用ソフト 3

リスクが少ないランキングと生産性

Page 21: 病理学第3章

9.低生産性(2/2)

請負・アウトソースとMISの生産性の違い

A)内製より請負の方が要件変更に対して安定する

B) 請負業者は契約を取るために学習が早い

C) 請負業者はたいてい同じようなプロジェクトをやっているの

で再利用可能な設計やコードが豊富

D) 特に固定価格のプロジェクトの場合、請負業者は契約以上の

残業が多発する

21

Page 22: 病理学第3章

10.プロジェクト中断(1/2)プロジェクトの中断率はシステムの規模に比例する

特に10,000FP(1,000,000ソース行)以上でよく当てはまる

50%を超えることもある

中断プロジェクトの特徴:1年以上の稼働遅れ、100%以上の予算超過

22

1 商用ソフト プロジェクト中断=倒産というケースが多い2 エンドユーザソフト 困難であれば投げ出せばよい3 MIS プロジェクトサイズが意外に小さい4 軍用ソフト 損益の計算をしないので意外と長持ちする5 請負・アウトソース 次ページ参照6 システムソフト 組み込み系では「不適切な性能」などの問題も

リスクが少ない順ランキング

Page 23: 病理学第3章

10.プロジェクト中断(2/2)

請負業者に対する中断の理由

1.スケジュールのひどいずれ

2.ひどい赤字

3.過剰な要件の拡大

4.受け入れ不可能な品質レベル

23

Page 24: 病理学第3章

まとめ

ここで挙げた10のリスクは氷山の一角

プロセス評価やFPの使用など新しい手法を使う

と今まで隠れていたリスクを明らかにできる

リスクマネジメントは「ソフトウェアエンジニ

アリング」の一部になりつつある

24