病理学13章 過酷なスケジュール
- 2. 目次
1. 症状
2. 重症度
3. 感染率
4. 発症
5. 感受性
6. 病原
7. 合併症
8. 経済的影響
9. 予防法
10. 治療法
11. 支援プロダクト
12. コンサルティング
13. 教育
14. 関連書籍
15. 関連雑誌
16. 規格
17. 専門機関
18. 治療効果
19. 治療費
20. 将来展望
21. 感想
ソフトウェア病理学 読書会 第13章 過酷なスケジュール 2
- 4. 2. 重症度
ソフトウェア病理学 読書会 第13章 過酷なスケジュール
4
重症度 発生事象
5 プロジェクト
の中止
技術者の退職
4 士気の低下
3 品質の低下 過度の残業
スケジュール
遅延
2
残業
1
平均重症度
- 5. 3. 感染率
• 規模が1,000 FPを超えるプロジェクト
⇒ 約75 %
• 規模が5,000 FPを超えるプロジェクト
⇒ 90 %に達する
※ この傾向は、MIS,受託開発,市販,システム,軍需の
各プロジェクトでほとんど差はない
ソフトウェア病理学 読書会 第13章 過酷なスケジュール 5
規模が大きいほど、感染しやすい
- 6. 4. 発症
• ソフトウェア産業に常にみられる
• ソフトウェア開発が熟練者の労力に頼る労働
集約型の職業であるかぎり、おそらくなくな
らないであろう
• 情報システムソフトウェア、軍需ソフトウェ
ア、システムソフトウェアはすべて同じよう
に過酷なスケジュールの問題が起こりやすい。
ソフトウェア病理学 読書会 第13章 過酷なスケジュール 6
- 7. 7
5. 感受性
どのようなプロジェクト? 感受性しやすさ
独断的で非合理な方法でスケジュールを決定 最も感染しやすい
要求定義が定まる以前にスケジュールを決定 かなり感染しやすい
徐々に増大するユーザ要求を管理していない、
適切に管理できていない
1,000 FPを超え、人手による見積技術しか用いていない
見積ツール、計画作成ツール、
あるいはそのいずれも用いていない
機能的尺度を用いて、徐々に増大するユーザ要求を測定 比較的感染しにくい
自動見積ツールと自動計画作成ツールを用いて
開発スケジュールを作成
顧客、管理者、技術者間で共同してスケジュールを作成
100 FP以下 ほとんど感染しない
ソフトウェア病理学 読書会 第13章 過酷なスケジュール
プロジェクトの規模が大きくなるとともに、感染しやすさ/重症度は増大
- 8. 6. 病原
① 最初のスケジュールの決め方に起因する要因
② 長すぎる開発スケジュールに起因する要因
病原
• プロジェクトの技術的内容が明らかになるずっと以前に、
独断的な方法でスケジュールを非合理に決定(主病原)
• 見積、計画作成にツールを使わずに巨大で複雑なプロジェク
トのスケジュールを作成
• 提案に楽観的なスケジュールが組まれていなければ、受託者
が仕事をもらえない可能性が高い。
ソフトウェア病理学 読書会 第13章 過酷なスケジュール
8
- 12. 9. 予防法
① 市販のソフトウェアプロジェクト見積ツールの使用
② 市販のプロジェクト計画作成ツールの使用
③ ユーザ要求の増大を定量化し制御するための機能的尺度の使用
④ 将来のプロジェクトにおいて、より合理的なスケジュールが
立てられるようなプロジェクトのスケジュールに関する
正確な蓄積データの収集と測定
⑤ ソフトウェアアプリケーションの開発労力を
最小にする再利用可能なものの活用
⇒システム構成、プログラム、データ、設計、文書、見積、
ヒューマンインタフェース、計画、テスト資料
の9種類の再利用が可能
ソフトウェア病理学 読書会 第13章 過酷なスケジュール 12
- 14. 11. 支援ツール
• 見積ツール
⇒スケジューリング機能を持っている_
ASSET-R, Bridge, CHECKPOINT®, COCOMO, ESTIMACS, PCOC,
REVIC, SEER, SLIM, SOFTCOST, SPQR/20
• 汎用のプロジェクト計画作成ツール
⇒もともとスケジュールに関する問題を取り扱うことができる
Artemis, Harvard Project Manager,
Project Manager's Workbench, Microsoft Project,
Superproject、Timeline
ソフトウェア病理学 読書会 第13章 過酷なスケジュール
14
- 17. 14. 関連書籍
• Church Mode : Building Effective Systems on a Tight Schedule
(John Boddie)
(邦訳:短期決戦型ソフトウェア開発)
• Software Engineering Risk Analysis and Management
(Robert Charette)
• Application Strategies for Risk Analysis (Robert Charette)
• Software Risk Management (Dr.Barry Boehm)
• The Mythical Man-Month (Fred Brooks)
(邦訳:人月の神話)
• Peopleware (DeMarco,Lister)
(邦訳:ピープルウェア)
ソフトウェア病理学 読書会 第13章 過酷なスケジュール 17
- 18. 14. 関連書籍
• Applied Software Measurement(Capers Jones)
(邦訳:ソフトウェア開発の定量化手法 第3版)
• Critical Problems in Software Measurement(Capers Jones)
• Software Engineering: A Practitioner's Approach
(Dr.Roger Pressman)
(邦訳:ソフトウェア・エンジニアリング序説)
• Measures for Excellence (Dr.Larry Putnam)
• Software Project Management Tarik (Abdel-Hamid, S.E.Madnick)
ソフトウェア病理学 読書会 第13章 過酷なスケジュール 18
- 20. 16. 規格
ANSI, DoD, IEE, IEEE, ISOによる規格で、以下のものはない
• ソフトウェアプロジェクトの規模別に出荷までの標準的なスケ
ジュールを定めたもの
• 過酷なスケジュールとはどのようなものであるかを定義してい
るもの
ソフトウェア病理学 読書会 第13章 過酷なスケジュール 20
- 21. 17. 専門機関
• ほとんどの専門機関ではこの病気を扱っていない。
• 大抵のプログラマが組合に所属しているヨーロッパとカナダでは、
組合の政策が過酷なスケジュールに影響を与えているようである
• 専門機関のなかにはスケジュールの測定と予測を取り扱っているも
のもある
• ISPAとIFPUGはともに、ほとんどすべての会合と会議でソフトウェ
ア開発のスケジュールを議論している
• SCEAすなわちSociety of Software Software Estimating and Cost
Analysisでは、この病気を時折扱っているようである。
• 有名なSEIのソフトウェアリスクに関する会議ではこの病気の危険
性に関して論文や発表を行っているようである。
ソフトウェア病理学 読書会 第13章 過酷なスケジュール 21
- 25. 21. 感想
• 昔より、より短納期開発が求められていて、20年前から状況
は変化していない
• ツールの活用は、やはり重要!
• 計画の見直しも、機能を減らすこともせず、プロジェクトの
終わりを変えようとしないプロジェクトは、いまだに多いの
では?
• 忙しさをモティベーションにしている人をどう変えるか?は
問題だと思う(上長や管理者にいると最悪!)
• アジャイルやXDDPといった開発スタイルの変更で、「徐々に
増大するユーザ要求」に対応していく必要があるのでは?
ソフトウェア病理学 読書会 第13章 過酷なスケジュール 25