「ソフトウェア品質工学の尺度とモデル」を買う

ソフトウェア品質工学の尺度とモデル
どうにもソフトウェアの尺度、すなわち計測というものがわからない。
LOC(行数カウント)は比較的わかりやすいが、高度に抽象化されたライブラリを駆使するオブジェクト指向ベースの言語ではLOCが役に立たないことは明らか。たとえ一人で開発していたとしてもスキルアップにより、よりコンパクトにかけるようになるだろうし、お手製ライブラリがたまってゆくと再利用性が高まり、これまたLOC削減に寄与する。つまり、LOCは無理。
ファンクションポイントが今のところ、もっともソフトウェアの複雑性を計測する尺度としては良いように思う。これは実装の詳細から離れて論理モデルから計測できるわけだから、見積もりとして使うにもよい。しかし、これは技術的に枯れた範囲を扱う『規模だけ』が大きなソフトウェアの見積もりには使えるだろうが、新しい技術を駆使するような、技術に依存するプロジェクトでは、これもアーキテクチャの複雑さを評価することはできず適さない。
また、然るに、システムエンジニアの生産性は人により700%から-300%(足手まとい)まで非常にバラツキがあり、しかも標準偏差のきれいなグラフではなく、圧倒的に右側が薄く、左側がゴミ溜め(掃き溜め)と化しているグラフになるという。
これを考慮してソフトウェアの工数を見積もるなんてことが可能なのだろうか。
しかし、まずは計測からだよな。
デミング博士もきっと『計測なくして品質なし』とかいってるだろう。
…でも、この本は難解です。

「ソフトウェア構造化技法」を買う。

ソフトウェア構造化技法―ダイアグラム法による
1986年初版、2004年初版第11刷。
今となっては絶滅した感もあるダイアグラムがいっぱい出ている本。
注意すべきことは「構造化ソフトウェア技法」ではない、ということだ。
現在でもUMLの一部として生き残る(しかし表記法はずいぶん変わった)ステートチャートや、それを制約として一目で把握できるようにするフェンス図、なんかは、もっと使われていてもよさそうに思うし、エンティティリレーションにはUMLではなく、やはりER図のほうが適していると思うし、DFDに属するダイアグラムも、クラス図ばかりでは見えてこないから、ドメイン解析レベルでは、結局UMLには含まれていない「ロバストネス図」と双璧になるぐらい、こちらも重要なダイアグライムではないか、とか思ったりする。
使う、使わない、はともかくとして自分のツールとして知っておくには良いと思わせる。
この本は良書だろう。
UMLだけではダメってことですね。コンポーネントやMDAを表現するにはUMLでは力不足だし、結局、スリーアミーゴの内輪もめを解決するための最大公約数的なダイアグラムでしかないのだな、と改めて思ったりするわけで。