病理学13章過酷なスケジュール

ソフトウェア病理学第13章過酷なスケジュール

ソフトウェア病理学読書会

2013/05/27 担当：Yamada

1出典：ソフトウェア病理学システム開発・保守の手引き

(Capers Jones, 構造計画研究所 1995/08)

目次

1. 症状

2. 重症度

3. 感染率

4. 発症

5. 感受性

6. 病原

7. 合併症

8. 経済的影響

9. 予防法

10. 治療法

11. 支援プロダクト

12. コンサルティング

13. 教育

14. 関連書籍

15. 関連雑誌

16. 規格

17. 専門機関

18. 治療効果

19. 治療費

20. 将来展望

21. 感想ソフトウェア病理学読書会第13章過酷なスケジュール 2

1. 症状

① 顧客が、技術的には不可能な短い期間で、ソフトウェア

アプリケーションを納入するよう強要すること

② 経営者やプロジェクト管理者が、技術的には不可能な短

い期間で、プログラムや設計書やユーザ用文書などを仕

上げるよう強要すること

ソフトウェア病理学読書会第13章過酷なスケジュール 3

見積や計画に問題があり、結果的に上記のような状態に陥っていると考える。開発の終盤で、プロジェクトの終了時期を変えずに無理に対応をさせようとする状況と考える。

2. 重症度


重症度発生事象

5 プロジェクトの中止

技術者の退職

4 士気の低下

3 品質の低下過度の残業スケジュール遅延

2残業

1

平均重症度

3. 感染率

• 規模が1,000 FPを超えるプロジェクト

⇒ 約75 %

• 規模が5,000 FPを超えるプロジェクト

⇒ 90 %に達する

※ この傾向は、MIS,受託開発,市販,システム,軍需の

各プロジェクトでほとんど差はない


規模が大きいほど、感染しやすい

4. 発症

• ソフトウェア産業に常にみられる

• ソフトウェア開発が熟練者の労力に頼る労働

集約型の職業であるかぎり、おそらくなくな

らないであろう

• 情報システムソフトウェア、軍需ソフトウェ

ア、システムソフトウェアはすべて同じよう

に過酷なスケジュールの問題が起こりやすい。


7

5. 感受性

どのようなプロジェクト？感受性しやすさ

独断的で非合理な方法でスケジュールを決定最も感染しやすい

要求定義が定まる以前にスケジュールを決定かなり感染しやすい

徐々に増大するユーザ要求を管理していない、適切に管理できていない

1,000 FPを超え、人手による見積技術しか用いていない

見積ツール、計画作成ツール、あるいはそのいずれも用いていない

機能的尺度を用いて、徐々に増大するユーザ要求を測定比較的感染しにくい

自動見積ツールと自動計画作成ツールを用いて開発スケジュールを作成

顧客、管理者、技術者間で共同してスケジュールを作成

100 FP以下ほとんど感染しない

ソフトウェア病理学読書会第13章過酷なスケジュール

プロジェクトの規模が大きくなるとともに、感染しやすさ/重症度は増大

6. 病原

① 最初のスケジュールの決め方に起因する要因

② 長すぎる開発スケジュールに起因する要因

病原

• プロジェクトの技術的内容が明らかになるずっと以前に、

独断的な方法でスケジュールを非合理に決定(主病原)

• 見積、計画作成にツールを使わずに巨大で複雑なプロジェク

トのスケジュールを作成

• 提案に楽観的なスケジュールが組まれていなければ、受託者

が仕事をもらえない可能性が高い。


9

6. 病原

プロジェクト規模(FP)

予定スケジュール(ヵ月)

実績スケジュール(ヵ月)

差(ヵ月)

10 1 1 0

100 6 6 0

1,000 12 18 6

10,000 36 60 24

ソフトウェア病理学読書会第13章過酷なスケジュール

要求定義から出荷までの開発期間の平均値、予定と実績の差の平均

病原(続き)

• 完了したプロジェクトのスケジュールの観測から得られた、

正確な蓄積データの不足

⇒正確なデータを記録している

プロジェクト：10 %以下, 企業：5 %以下 (1993年時点)

7. 合併症

技術者の士気低下、技術者の高い転職率

• 原因

徐々に増大するユーザ要求不正確な見積

不適切な計測不適切な計画作成

管理者の不当行為

関連する病気

• プロジェクトの中止、コストの超過が発生した

プロジェクトでこの病気の感染がみられる

• この病気は、低品質の主な原因


8. 経済的影響• 直接的なコスト

⇒この病気の副産物として、週30時間を越えることもある

多大なサービス残業があるため、測定が難しい

• 間接的なコスト

⇒品質の低下によるものである

• 最初の1年間の報告バグ数

通常の4倍にものぼることもある

• 最初の1年間の修復コスト

$200/FPを超える場合もある

※ より注意深く開発された場合、$50/FP以下


9. 予防法

① 市販のソフトウェアプロジェクト見積ツールの使用

② 市販のプロジェクト計画作成ツールの使用

③ ユーザ要求の増大を定量化し制御するための機能的尺度の使用

④ 将来のプロジェクトにおいて、より合理的なスケジュールが

立てられるようなプロジェクトのスケジュールに関する

正確な蓄積データの収集と測定

⑤ ソフトウェアアプリケーションの開発労力を

最小にする再利用可能なものの活用

⇒システム構成、プログラム、データ、設計、文書、見積、

ヒューマンインタフェース、計画、テスト資料

の9種類の再利用が可能ソフトウェア病理学読書会第13章過酷なスケジュール 12

10. 治療法

• ソフトウェアの機能を減らし、いくつかの機能の実現を将来

に延期することである

• 技術者を増やすことも、ときには効果的である


この病気が表面化するのは大抵は非常に遅い時期であり、非常に切迫した状態になっているため、上記以外の方法では、もはや治療することは困難である

新しい技術者の教育のためにプロジェクトのスケジュールが返って遅れる結果になることがしばしば起きる。

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


12. コンサルティング

• プロジェクトの監査やプロジェクトのアセスメントを行

うことによって、その原因および推奨すべき治療法を明

らかにすることが可能

⇒この病気に感染していることを認知することとはすこし異なる

SEIのアセスメント法では見積ツールの使用法のような副次的な

テーマも扱っている

• 士気や人間関係を扱っている管理コンサルタントが、最もこ

の病気を発見、コメントしてくれそうに思われる


13. 教育

• 多くの大学の教育機関では、正規のテーマとしては

この病気を取り扱っていない

• プロジェクト管理、計画作成、見積についての民間

のコースでは、時折このテーマを扱っている

Atlantic Systems Guide,Digital Consulting

Computer Power,Quantitative Software Management (QSM)

SPR


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)

(邦訳：ピープルウェア)


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)


15. 関連雑誌

• この病気について明確に扱っているソフトウェアの雑誌は

ない

• ほとんどの一般のソフトウェア雑誌は、スケジュールが異

常に長かったり、短かったりした特定のプロジェクトの記

事を時折掲載するにすぎない


16. 規格

ANSI, DoD, IEE, IEEE, ISOによる規格で、以下のものはない

• ソフトウェアプロジェクトの規模別に出荷までの標準的なスケ

ジュールを定めたもの

• 過酷なスケジュールとはどのようなものであるかを定義してい

るもの


17. 専門機関

• ほとんどの専門機関ではこの病気を扱っていない。

• 大抵のプログラマが組合に所属しているヨーロッパとカナダでは、

組合の政策が過酷なスケジュールに影響を与えているようである

• 専門機関のなかにはスケジュールの測定と予測を取り扱っているも

のもある

• ISPAとIFPUGはともに、ほとんどすべての会合と会議でソフトウェ

ア開発のスケジュールを議論している

• SCEAすなわちSociety of Software Software Estimating and Cost

Analysisでは、この病気を時折扱っているようである。

• 有名なSEIのソフトウェアリスクに関する会議ではこの病気の危険

性に関して論文や発表を行っているようである。


18. 治療効果

• 市販レベルのソフトウェア見積ツールや、汎用のプロ

ジェクト見積ツールでは、スケジュール見積は標準的

な機能となっている。

• ツールによる見積が、顧客、経営者、受託開発企業の

期待より明らかに長いものであったとき、これらの見

積は無視されてしまうことが多い

• 5,000 FP以上のプロジェクトに見積ツールを使わない

ことは、管理者の不当行為の一例であるとみなすこと

ができる


19 治療費

ツールの費用

• コスト見積ツール

1,000ドル以下から、40,000ドル以上

• プロジェクト計画作成ツール

200ドル以下から、10,000ドルくらい


20.将来展望

• 20世紀の間はこの状況が続くであろう

• ソフトウェアの見積と計画作成の技術がこの病気を治療できるほど十分に

精巧なものになってきている

• この病気の撲滅は容易ではない！


21世紀に入っても変わっていない。

短期開発が求められているので、より深刻になっているのでは？

• 提案と契約の面から楽観的なスケジュールを無理に組もうとする市場の圧力は強烈

• この病気を楽しんでいる人がいるという心理的な要因が存在

• 不当行為と企業文化の貧しさの問題も影響

21. 感想

• 昔より、より短納期開発が求められていて、20年前から状況

は変化していない

• ツールの活用は、やはり重要！

• 計画の見直しも、機能を減らすこともせず、プロジェクトの

終わりを変えようとしないプロジェクトは、いまだに多いの

では？

• 忙しさをモティベーションにしている人をどう変えるか？は

問題だと思う(上長や管理者にいると最悪！)

• アジャイルやXDDPといった開発スタイルの変更で、「徐々に

増大するユーザ要求」に対応していく必要があるのでは？


Documents

病理学13章 過酷なスケジュール

病理学13章過酷なスケジュール