ソフトウェアの見積もりに客観的な視点を取り入れたくて、コード行数を計測していこうと考えています。
基本的な所ですが、LOCについて紹介します。
LOC(lines of code)とは
LOCは、lines of codeの略です。
ソースコードの行数を表していますが、よりソースコードと明確にするために、
SLOC(source lines of code)とも呼ばれています。
ソフトウェアの規模を表す指標の一つとして利用されており、LOCを計測することで、
「生産性」や「品質の分析」に利用することができます。
例えば、
生産性として、［SLOC/人時]を算出し、SLOC生産性を把握したり、
品質分析として、[バグ件数／KSLOC]を算出し、バグ密度を把握したり、
ソフトウェアの状態を知るためのきっかけにできます。
LOCの計測方法を理解する
LOCには、以下の２つの考え方があります。
物理LOC
テキストファイルとしての行数。
コメント、空白行なども含むソースコードの行数となります。
定義が明確です。
論理LOC
コメントや空白行を除いたソースコードの行数。
さらに、
- 2つの命令が書かれた行は、2行と数える
- 括弧だけの行を除く
など、定義は様々です。
計測するルールを統一すること
計測方法にルールはない
IPAでも、以下にある通り、明確な定義は各社に任せていると記載されています。
物理行数、論理行数、言語による定義の違い等ありますが、どのように定義するかは各社で取り方が異なります。統一はできないため、各社の方針に任せております。しかし、大体は物理行になっているようです。
なお、空行やコメント行の率は5％刻みですので、結果それほど精緻な表現になっていません。
出典：IPA 「ソフトウェア開発データ白書」シリーズに関するよくある質問と回答
定義がないなら、どうすればよいか。
「空白を含むべきか」「コメントは含むべきか」
「可読性のために”{“だけの行があるが含むべきか」
「テストコードは？」「サードパーティライブラリのコードは？」
など、含む含まないでＬＯＣの値は大きく変わってくるかもしれません。
では、どうすればよいか？
一貫性を保つ
プロジェクトでルールを統一しておく。
つまり、一貫性を保っていれば問題ありません。
ルールが異なると他プロジェクトの比較はできませんが、自プロジェクトでの利用としては定義が決まっていれば有効となります。
ソフトウェア見積もりの話ではありますが、ソフトウェア規模を計測する際のコンテクストであるため、参考になる意見です。
この問題につちえ業界標準はなく、これらの質問にどう答えるかはたいした問題ではない。重要なのは、これらの質問に対する答えがプロジェクト間で一貫したものであり、収集したデータに盛り込まれた前提がどんなものであれ、それが見積もりの中に意図的に投影されるということだ。
ソフトウェア見積もり 人月の暗黙知を解き明かす 8.2.1 規模の測定に関する問題
ルールを決める、あるいは、ツールを使うなど、プロジェクトで一貫性のある方法でデータを収集しましょう。
まとめ
ソフトウェアの状態を知るための指標として、LOCを紹介しました。
プロジェクトでどういう前提での数値なのかを共有し、
「生産性」や「品質の分析」、あるいは「見積もり」の参考にしてみてはいかがでしょうか。
今回、紹介した書籍
