ソフトウェアメトリクス2:ソースコードの規模
Carpenter holding a measure tape on the work bench

ソフトウェアメトリクス2:ソースコードの規模

いまさら Lines-of-code?   ソースコードの規模を測定する際に、最もよく使われるメトリクスはコード行数、いわゆるLines-of-code (LOC) でしょう。古くからあるメトリクスである上に、計測も簡単にできます。Linux 環境であれば、wc -l コマンド一発ですし、エディタで常時表示させることもできます。  ただし、ご存知とおりLOC は取り扱いが難しいメトリクスでもあります。特に、LOC を作業量の見積もりや、開発チームのパフォーマンスの計測に使う場合は、使い方を誤ると批判が生まれます。例えば、2つの異なるチームが「オンラインでの支払いシステム」を開発した時に、同じ期間で1000行のコードで開発したのと、100行のコードで開発したのでは、どちらのチームがパフォーマンスがよいと言えるでしょうか。ほぼ同じ機能であるならば、開発時のコストはもちろん、その後の保守メンテナンスのことも考えれば、より少ない行数で実現できた方がよいことは疑いようがありません。最近のNo Code の流行にもあるように、全くコードを書かずに実現できれば、それが最も効率が良いとも言えます。  LOC の問題点の一つは、単純な変数の代入も、複雑な算術演算ステートメントも、同じ1行でカウントされてしまうことにあります。この問題点を解決する一つのアイディアは、行の複雑度に応じて重み付けをすることですが、「17行目のステートメントが45行目のステートメントよりも2倍の重みを持っている」などと定量的に表現することは容易ではありません。LOC は、その名の通り単位「コードの行数」を数えただけのものであり、開発時間や、生産性や、コストに直接変換できるものではありません。  このように、様々な問題をもつメトリクスではありますが、それでもなおLOC が有用な場面は多数あります。例えば、LOCの絶対量ではなく相対的な変化に注目してチームの開発フェーズの変化を知ることができます。前述の通り、LOCの値そのものはチームの生産性と必ずしも関連性があるとは言えませんが、同じプロジェクト、同じチームにおいて、チームの先週のLOCと今週のLOC を比較することで、増加傾向であれば「設計フェーズから実装フェーズに入った」とか、減少傾向であれば「実装が一段落してテストフェーズに入った」などと類推することができます。  他には、LOC はテストや保守の基準値として使われることもあります。10万行のソフトウェアは、1万行のソフトウェアよりも保守やテストのコストがかかるのは同意できるところだと思います。バグの数をLOC で割ったものを「バグ密度」と定義し、ソフトウェア品質の基準値として使っているチームもあります。  LOCの計測方法にはいくつかの定義があり、チームや組織で採用する場合は同じ定義を一貫して使うことが重要です。単純にテキストファイルとしての行数(Physical LOC)を使うこともありますが、多くの場合、空行とコメント行を除いた行数(Non-comment LOC: NLOC)や、NLOCからさらに、「2つの命令が書かれた行は2行と数える」、「括弧だけの行を除く」などの換算をした行数(Logical LOC: LLOC)を用いることが多いでしょう。コメントの行数をComment lines of…

Continue Reading ソフトウェアメトリクス2:ソースコードの規模

ソフトウェア開発において最も重要なメトリクスは何か?

メトリクス(評価指標) の測定は、ソフトウェア開発チームとマネージャーが製品の品質を高め作業の効率を上げるのに役立ちますが、プロジェクトや組織に合った適切なメトリクスを選択することが重要です。 この記事では、ソフトウェア開発メトリクスが重要である理由、プロジェクトとチームにとって最も効果的なメトリクスを選択する方法、そして広く採用されている代表的なメトリクスについて紹介します。 1. 適切なメトリクスを選択する方法 情報は、定量化することでより便利に使えるようになります。データを集計・測定することで、どのような時間と労力の投資が実際に成果を上げているか、そしてどのようにプロセスを改善するべきかを判断することができます。 ソフトウェア開発チームとそのマネージャーは、メトリクスを基準を用いて作業において何が重要であるかを測定し、その測定結果を基にチームの目標を設定し、メトリクスの時系列変化を観察します。ソフトウェア開発メトリクスを使って、ソフトウェア開発プロジェクトの成功に不可欠な生産性、効率、品質、およびその他のKPI(Key Performance Indicator) を測定することができます。 しかし、情報と測定量は多ければよいとは限りません。ソフトウェア開発プロジェクトによって生成されるデジタルデータの量を考えると、チームにとって情報が多すぎるという問題を抱えないようにすることが重要な課題です。どのソフトウェア開発メトリクスを使うかを慎重に検討し、チームの成功をもらたすメトリクスを選択し測定する必要があります。 また、一部のソフトウェア開発チーム、特にアジャイル方法論や他のリーン・プロセスフレームワークを採用しているチームの中には、メトリクスの使用に抵抗を感じるチームもあるでしょう。データの収集と測定というあまり生産的でない作業に多くの時間を費やしたくないためです。チームがメトリクスのための作業でつまづいたり、「バニティメトリクス(Vanity Metrics: サービス改善につながらない指標、意味のない指標)」に夢中になり時間をかけすぎるような場合、製品の質も士気も低下してしまう可能性があります。 そのため、選択したメトリクスで得た情報を理解し、それによりプロジェクトの状況を決定し、時間リソースの最適化ができるかどうかを常に確認してください。 定期的にメトリクスを見直し、チームにとって引き続き有効かどうかを判断します。もし以前選択したメトリクスが役に立たなくなっていると感じたら使うのをやめ、代わりに新しいメトリクスを試してください。 2. ソフトウェア開発メトリクスの分類 開発中の製品は、順調に完成に向かっていますか? あなたのチームはどれだけうまく仕事を進めていますか? そのような質問に答えるためのソフトウェア開発メトリクスは、大きく分けて2つのカテゴリに分類されます。 デリバリー・メトリクス:スプリントの効率、プロジェクトのデリバリーまでのリードタイム、および、チームが作業を完了するまでの時間を左右するその他の要因を測定します。 これらのメトリクスは顧客満足度に影響を与えます。また、マネージャーはこれらのメトリクスを使用して、製品のリリース時期と内容を決定することができます。 テクニカル・メトリクス:コードベースのソフトウェア開発メトリクスは、技術的な観点からのプロジェクトの堅牢性を測定するもので、製品を内部レベルで分析し、製品のパフォーマンスを把握するのに役立ちます。 バグ、セキュリティなどの要因は、このテクニカル・メトリクスを使用して測定されます。 通常これらのメトリクスは、ツール等を利用して自動的に測定されるようにします。 開発チームのリーダーと協力して、自動計測をどのように実装するのが最善か、検討してみましょう。 上記を踏まえて、どのメトリクスを選択するかはあなた次第です。 さまざまなソフトウェア開発チームのリーダーが、過去の経験則に基づいてメトリクスやその計測システムを選択しています。 選択するメトリクスは、その企業固有の価値観を反映している場合もあれば、チームが現在使用している一般的なフレームワークの一部である場合もあります。…

Continue Reading ソフトウェア開発において最も重要なメトリクスは何か?

ソフトウェアメトリクス1: 循環的複雑度

 ソフトウェアの品質を測定するためのメトリクス(指標)はいろいろありますが、本記事ではソースコードの品質を評価する指標の一つ、循環的複雑度を取り上げたいと思います。1970年代に提唱されたメトリクスであり、現在のソフトウェア開発には合わないという意見もありますが、他の指標と合わせて使うことで依然として有用なメトリクスとなります。 循環的複雑度の定義  循環的複雑度(英: Cyclomatic Complexity) は、その名称から、単にプログラム内のループの個数を数えるものであると誤解されていることも多いですが、実際にはプログラムの構造を「制御フローグラフ(英: Control flow graph)」で表した際のグラフ内部の循環の数に着目してソフトウェアプログラムの複雑性を測定する指標です。1976年にMcCabe によって提案されました。ちなみに制御フローグラフとは、プログラムの実行中にプログラムを通過する可能性のあるすべての経路を有向グラフで表現したもので、Frances E. Allen によって提唱されたものです。  Fig 1 に制御フローグラフの例を示します。ここで、プログラムの開始位置をノード a, 終了位置をノード f とします。プログラム中の反復や条件分岐が開始する位置と終了する位置もそれぞれノードとなり、図の例ではノードb からe となっています。ノード間をつなぐ逐次処理の部分はエッジとなり矢印で表現されます。ちなみに、逐次処理部分は、プログラム行数が何行であっても(0行であっても) 1つのエッジとなります。 Fig 1: 制御フローグラフの例 (McCabe 1976 より転載) 循環的複雑度の定義は以下のとおりですV(G)…

Continue Reading ソフトウェアメトリクス1: 循環的複雑度