EVMSの危険性

　っていっても、Linuxのほうのファイル関係ででてくるEnterprise Volume Management SystemのほうのEVMSの話じゃなくって、アーンド・バリュー・マネジメント・システムのほうのEVMS

---

　EVMSは、まあ、情報処理試験のお勉強とかでやったかもしんないけど、まあ、こんなかんじ。っていうことで、すべての作業を金銭価値に置き換える必要がある。っていうことで、仮にテストなんかで、この考え方を導入しようとすれば、m_pixyさんの「PM見習いの読書日記」のこの記事にあるように

なんでスケジュールを細かい作業の１分刻みで与えないといけないの？

っていうことになる。

（なんで、っていうことに答えておくと、EVMSで管理するには、全部金銭的価値に置き換える必要がある。ここで、金銭に関係するのは、１人月単価になる。もし、あるテスト項目が、だれかさんがやって、それが何分ってわかれば、（１人月単価／６０分＊８時間＊２０日（１ヶ月２０日の場合））＊何分で、そのテストの金銭的価値がもとまり、EVMSで管理できる。だから、分単位で管理する。この時、人によって、作業内容が変わってしまうと、何分という細かな時間もずれる。そこで、かなり細かく、一意になるような作業指示にしないといけなくなる。なになにを押すみたいなかんじで）。

---

　しかし、EVMSは、品質を保証するかというと、これは、疑問である。

　品質保障の内容は、含まれていない。そこで、品質保証の指標として、テスト項目の設定率にしてしまうと、昨日の問題が起こる。つまり、これだと、品質が保障できないから、自主的テストをやんないといけないけど、EVMSでやっている場合、そんなことを認める余裕はない（結局、お金が発生するのが分単位っていうことで、分単位で、管理されるから、そんな余計なことをやる余裕はない）。

---

　つまり、EVMSで管理すればいいっていうもんでもない。
　でも、EVMSが、はやっていたりする。

---

　すみません、今日、テスト容易性設計と、自動生成とか、その辺の話を書こうと思って、まあ、こんなところの話でも、もってこようと思ったんだけど。。。そこに

テスタビリティを考慮するトップダウンの階層設計手法を前提としています。現在では、各設計プロセス間（合成とスキャン挿入間など）で設計のやり取りが必要な従来型の「問題解決型」の手法は適用しにくくなっています。問題解決型の設計手法では、各設計プロセス間の統合で発生する問題に対応しきれないことがあり、結果的に設計のやり直しによるスケジュールの遅延の原因となります。


そーだよね、そーなっちゃうよね。
でも、それをかくとお。。。
ひなんごうごうになっちゃうだろーなー

と思って、やめて違う話題にしたので、今日は、しょーもない話になってしまいました。