ソフトウェア工学と品質保証が結び付くと、お金になるのかも？

ソフトウェア工学で、生産性を上げてもそれほどお金にはならなくなってきた。
　　大規模案件は少なくなってきたし、
　　自分でフレームワークを作れる技術はあるし、
　　一番生産性が低いのは会議(打ち合わせ）だけど、
　　　　　その生産性向上はソフトウェア工学とは関係ない
からだ。

ただ、これと、品質保証が結び付くと、話が違ってくる。
欧米の自動車輸出をする際のISO26262のように、
製品の品質をアシュアランスケースなどを使って
保証しなければならないことが起こってきた。

---

このような品質保証において、

　　テストしました！

といっても、どのくらいテストしたのかわからないので、
これでは、保証されない。
　つまり、開発プロセスを「行った」ことをいくら保証しても、
品質は保証されない。

　そこで、開発プロセスにおいて、終わったらどうなっているかを
明確化して、その上で、「その状態になっている」というのであれば、
そこまでの品質は、保証される。

　プログラム中、すべての命令の実行が、確認されているという状態を
命令網羅として、

　　　命令網羅のテストを行いました！

といった場合は、テストにおいて、すべての命令を実行したかどうかを
確認すればよい。そうすると、命令網羅レベルでの品質は保証される。
　もちろん、そのレベルの品質では問題あるのだが、論点はそこではなく、
問題あるかどうかが判断できるようになったという意義は大きいという
意味である。


共通フレームとＳＥＭＡＴ、保証ケースを関連付けると・・・
http://ameblo.jp/smeokano/entry-11563135092.html


にあるように、たしかに、共通フレームは開発プロセスの共通のものさし
なので、これだけでは保証できないけれど、SEMATなど、他のゴール指向
なり、状態指向なりのモノと結び付くと、品質保証になって、
品質保証になると、はじめの話のように、製品輸出のためにしないといけない
事態もあって、そうなると、お金を生み出すようになるのかもしれない。