Your SlideShare is downloading. ×
0
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
04病理学第2章
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

04病理学第2章

538

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
538
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ソフトウェア病理学第2章:共通のソフトウェアリスク 森 龍二 1
  • 2. 導入部• リスク認識と実証データを集めるため に監査やアセスメントを実施• 数百のプロジェクトから百超のリスク 要因を分析• この本では約60個のリスクについて 扱う 2
  • 3. 訴訟リスク• 従業員の不当解雇• 著作権違反• 契約上の義務の不履行• 不当に抜かれた代金の返還 日本でも活発化• 従業員の服務契約違反• 企業秘密の不正流用• 役員に対する信認義務違反• ソフトウェア瑕疵による損害賠償• 契約した仕事の責任範囲を巡る係争 3
  • 4. 6つのドメイン(1)経営情報システム(MIS)(2)システムソフトウェア(3)市販ソフトウェア(4)軍用ソフト(5)請負契約またはアウトソースのプロジェクト(6)エンドユーザによるソフトウェア 4
  • 5. (1)経営情報システム(MIS) 5
  • 6. 経営情報システムとは• 経営情報システム(MIS;Management Information Systems)とは組織内で使われ るコンピュータベースの情報システム Wikipediaより• 60∼70年代に流行• 保険のクレーム処理、経理、受注処理 など 6
  • 7. 経営情報システム(MIS)のリスク 該当プロジェクトの割合 要件の拡大 85% 納期のプレッシャー 65% 低品質 60% 赤字 55% 構成管理の失敗 50% 0% 25% 50% 75% 100% 7
  • 8. MISリスク詳細• 「要件の拡大」:月に1%以上の変更量• 「納期遅れ」:通常より2割以上短い• 「低品質」:1FPごとに0.5個以上のバグ(年間) • 目安:1FP≒40∼100LOC(Java)※ • バグの除去と予防ができていない• 「赤字」:平均で15%の予算超過• 「構成管理の失敗」:設計書、ソースコードの管理ミス ※「ソフトウェア見積もり」(スティーブ・マコネル) 8
  • 9. (2)システムソフトウェア 9
  • 10. システムソフトウェアとは• 物理デバイスを制御するためのソフト • コンピュータのOS • 電話交換機のソフトスイッチ • 自動車の燃料噴射制御の車載ソフト• 高品質・高信頼性が要求される 10
  • 11. システムソフトウェアのリスク 該当プロジェクトの割合 長い開発期間 70% コスト見積もり失敗 65% 過度な文書作成作業 60% バグの偏り 50% プロジェクトの中断 35% 0% 25% 50% 75% 100% 11
  • 12. システムソフトウェアリスク詳細 • 「長い開発期間」:>3年 • 「コスト見積もり失敗」:見積もりツールの未使用 • 「過度な文書作成作業」:3つの条件 1. ドキュメントの種類が50以上 2. 事務作業のコストがプロジェクト全体の5割以上 3. 1FPあたり2000ワード以上のドキュメント • 「バグの偏り」:IBM OS/360では4%のモジュールに38%のバグが集中 • 「プロジェクトの中断」: 1. 1年以上の遅れ、50%以上の予算超過 2. パフォーマンスと品質の基準をクリアできなかった 12
  • 13. (3)商用ソフトウェア 13
  • 14. 商用ソフトウェアのリスク 該当プロジェクトの割合ユーザドキュメントの不備 70% 不満なユーザ 55% 投入時期が遅い 50% 競争相手からの危害 45% 高額な訴訟費用 30% 0% 25% 50% 75% 100% 14
  • 15. 商用ソフトウェアリスク詳細(1/2) • 「ユーザドキュメントの不備」:原因 1. 新しいソフトの最初のリリースは難しい 2. 優秀なライターやイラストレータを雇う金がない 3. 最先端のソフトは未熟で変わりやすい • 「ユーザの不満」 1. 低品質 2. 欲しい機能がない 3. コマンドが難しい 4. 学習曲線が緩やか 5. インストールがやっかい 6. カスタマーサポートが貧弱 7. やたらとディスクやハードを食う 15
  • 16. 商用ソフトウェアリスク詳細(2/2) • 「投入時期が遅い」:開発に3年以上かかると市況が変化する • 例:OS/2とWindows • 「競争相手からの危害」: 1. c ネガティブキャンペーン MacとWindows 2. ウソの宣伝文句 3. あからさまな著作権違反 4. ルック&フィールの模倣 アップルとサムスン 5. 特許・商標権違反 6. 食い合いの価格競争 Officeの低価格化 • 「高額な訴訟費用」:訴訟確率が50%を超える(99年までに) 16
  • 17. (4)軍用ソフトウェア 17
  • 18. 軍用ソフト?• 日本じゃ関係ないイメージ →No!• DoD-STD-2167A:米国国 防総省の開発標準 • 2167:ウォータフォール DoD-STD-2167Aのプロセス図 (+インクリメンタル) • 2167A:がちがちのウォ ーターフォール 18
  • 19. 軍用ソフトウェアのリスク 該当プロジェクトの割合 過度の文書作成作業 90% 低生産性 85% 長い開発期間 75% 要件の拡大 70% 未使用・使用不可 45% 0% 25% 50% 75% 100% 19
  • 20. 軍用ソフトウェアリスク詳細• 「過度の文書作成作業」 • 文書タイプ:∼100種類 • 6ページ/FP(400語/Adaプログラム1行) • 全体工数の約52%(実装は25%以下)• 「低生産性」:米国平均は5FP/人月、軍用は3FP/人月• 「長い開発期間」:5年を超えたら危険• 「要件の拡大」:機能の50%∼60%が変更されたもの• 「未使用・使用不可」:開発期間の長さが主な原因 20
  • 21. (5)請負契約またはアウトソース 21
  • 22. 請負契約・アウトソースのリスク 該当プロジェクトの割合 高い維持管理費 60% 請負会社と顧客の摩擦 50% 要件の拡大 45% 不測の受け入れ基準 30% 成果物の法的所有権 20% 0% 25% 50% 75% 100% 22
  • 23. 請負・アウトソースのリスク詳細 • 「高い維持管理費」 • 米国平均:$125/FP、請負:$200/FP • 一人が維持管理可能なFP:500∼1500 • 高い原因は実装の詳細を知らないこと スルガ銀行 • 「請負会社と顧客の摩擦」:法的争いに発展しがち とIBM • 「要件の拡大」:追加費用でもめがち • 「不測の受け入れ基準」 • 最初の契約になかった受け入れ条件を後から入れられること • 「成果物の法的な所有権」:契約時に必ず確認すること 23
  • 24. (6)エンドユーザによ るソフトウェア 24
  • 25. エンドユーザソフトのリスク 該当プロジェクトの割合 引き継げないアプリ 80% 隠れたエラー 65% 維持管理不能 60% 冗長なアプリ 50% 成果物の法的所有権 20% 0% 25% 50% 75% 100% 25
  • 26. エンドユーザソフトのリスク詳細 • 「引き継げないアプリ」 • 作者本人しかわからないUI、ドキュメント不在 • 「隠れたエラー」:レビュー、品証活動なし • 「維持管理不能」:担当者が退職すると終わり • 「冗長なアプリ」 • 同時並行:同じ仕事をする従業員が同時に同じアプリを開発 • 時系列:任期のある職場で、その期間内で同じアプリを開発 • 「成果物の法的所有権」:退職時に所有権を主張するケースなど 26
  • 27. 共通のソフトウェアリスクを防ぐには 27
  • 28. 要求の拡大• 実証済みの方法論を使う • プロトタイピング、Joint Application Design(JAD) • Information Engineering • Funtion Point• FPベースの契約にする• 自動化 • 要件定義でFP数算出→見積もりツール→CASEツール• 要件の再利用 28
  • 29. スケジュールに関するもの• スケジュールリスクを減らす技術 1. スケジュールの評価・計画を改善する 2. スケジュール遅延を減らす• 納期予測ツールが正確でも顧客や経営層の意向に沿わない と簡単に無視される• スケジュール遅延を減らす方法 A 再利用(設計・コード・その他成果物) B オブジェクト指向分析・設計・実装 C CASEツール D Information Engineering, Rapid Application Development E 構造化分析・設計(大規模向け) F レビュー、インスペクション、品質制御 29
  • 30. 赤字• 赤字防止に必要な3つの技術 1. コスト見積もりを正確にする技術 2. 実際に開発コストを減らす技術 3. コストを正確に測る技術• Function PointまたはFeature Pointを使え • Line Of Codeでは曖昧で矛盾を含んでおりダメ• 海外アウトソース(現実には難しいようですが...) 30
  • 31. 低品質(1/2)• 品質を制御する4つの技術 • 品質評価ツールの数は少な いが成長分野(93年時点) 1. 品質と信頼性の評価ツ ール • 欠陥防止法 A 構造化分析・設計技法 2. 欠陥防止法 B プロトタイピング C 高級言語、オブジェクト指向言語 3. 欠陥除去法 D 手続き型言語で構造化実装法の厳格な適用 E 品質機能展開(QFD) 4. 品質計測プログラム F TQM法 G 品質保証部(SQA) H クリーンルーム法 31
  • 32. 低品質(2/2)• 欠陥除去法 • デザインレビュー • 構造化ウォークスルー • フォーマルインスペクション→最も欠陥除去効率がよい! • 形式手法 • あらゆるテスティング• 品質計測プログラム:特に記述なし• ファンクションポイントは1991年適用開始• ISO 9000-9004品質標準 • 標準のクリアと成果物の品質には特に関連なし • 標準の遵守に時間を浪費する傾向あり→これは今も変わらず 32
  • 33. 高い維持管理費(1/2)• 「維持管理」は拡張と欠陥除去の両方を指す• リスク低減法 • 構造的複雑度の分析ツール • 再構築ツール(COBOL, C) • リバースエンジニアリングツール • リエンジニアリングツール→保守支援ツール • エラー傾向モジュールの分析と除去 33
  • 34. 高い維持管理費(2/2)• ハートフォード生命の例 • 同業他社の年間予算の50%は維持管理 • ハートフォードは19%以下で低下傾向 • 10年前から複雑度分析、リストラクチャリング、リバ ースエンジニアリング、リエンジニアリングを実施• 維持管理費に苦しむ人(予算の50%以上を浪費)でシステム の「老人介護」を行っているのはそのうちの5%• 維持管理費が25%以下の人のうち65%は対策を行っている 34
  • 35. 制御が困難なリスク 要因 35
  • 36. 過度の文書作成作業• 軍関係など、標準に厳格なプロジェクトで は軽減は難しい• 誰も最適な文書量を知らない• 昔は紙の方が経済的だった• 今は光学ディスクの方が安い(93年ですから) • →今だとUSB, SD, MicroSD, ...etc. 36
  • 37. 不適切なユーザドキュメント• 明確にドキュメントを書ける人は比較的 少ない• ただし大企業で技術文書作成、編集、イ ラスト化の専門部署を持つところを除く• マルチメディアの発展がこの状況を変え るかも(93年なので...) 37
  • 38. ユーザの不満• 全部が難しいわけではないが解決は易し くない• GUIへの移行は一つの解決策• サポート、ヘルプ、ドキュメントの改善• ユーザの満足度調査は増えてきているが、 長い期間行うのがおすすめ 38
  • 39. お客様と契約者との摩擦• 人間の本質からしかたのないこと• すぐに状況を改善する秘策はない• ソフトウェアだけではなく昔からある こと 39
  • 40. 法的問題と訴訟費用• 時間の経過とともに大きくなってきた問題• 商用ソフトでは大きな問題• 米国は高価な訴訟のリーダー• 米国はソフトウェア製品に対するリーダーシップ を失い、取引のバランスを欠く恐れ• 技術専門家がフルタイムでQCDを監視し、訴訟の 証人となるケースもある 40
  • 41. まとめ 41
  • 42. まとめ• リスク管理やプロジェクトアセスは”ソフトウェ アエンジニアリング”への近道• すべてのリスク要因が制御可能ではない• リスク分析とアセス法は大事な問題点を見つけ るのに有効• 問題点さえはっきりすれば何らかの解決法はあ る 42

×