■

ソフトウェア品質工学の尺度とモデル読んだ。作業時間と欠陥の発見数を比べて、欠陥ががどれくらい残ってるかモデルに当てはめて予測するとか、開発プロセスを評価して改善するとか、そういう話。

ちゃんと導入しようすると大変そうだった。仕様のレビューに何時間かけて、欠陥ががこれくらい見つかりましたとか言って、それがグラフになってて、とかやろうとすると、手間が大きい。

証券取引所とか、ロケットとか、信頼性が必要なものを作ってるなら、積極的にこういうことをして信頼性が上がるならやった方がいいと思う。

ウォーターフォールでやる前提になってるようで、統合のタイミングでこれをやるとか書いてあったけど、普段小さいチームで細々とやってるので、そんなにちゃんとしてなくて、出勤したら自由にインタラクションする感じで、統合のタイミングとかないので、そのまま適用するのは難しそうだった。

全く参考にならないわけでもなくて、小さいプロジェクトでもできることはありそうだった。

ソースコードを解析して複雑度を測るとかは気軽にできそう。目標を決めて、このクラス最近複雑になってるけど大丈夫かとか、リファクタリングすべきところを探して教えてくれるとか。

あと、良かったのは、プロセスを変えて終わりじゃなくて、ちゃんと生産性が上がったり、顧客満足度とか、品質が上がったりするところまでやらないといけない、という姿勢で、確かにと思った。意味あることをしないといけない。CMMのレベル上がらなくてもレベル上げようとする過程でプロセスが改善されたら良いとか。

この本はちょっと古い本で、初版は1995年に出てる。思うに、昔はこういうことをやってたけど、難しいし、そんなに流行らなくて、これからはアジャイルとかスクラムとか言って、ちょっとずつ進めるのが流行って、その方が簡単だから受け入れられたのだと思う。

ソフトウェア品質工学の尺度とモデル