cles::blog

先日、メトリクスのまとめをちょっとやったので、今日はツールを使って実際にメトリクスを取ってみます。

手っ取り早く自分のプロジェクトに適用するのであれば、Eclipse Metrics Pluginを使ったり、Maven2のプラグイン経由でJDependやJavaNCSSを使うのが楽なのですが、今回はSLoCをメソッド単位で取得する必要があり、しかも大量のプロジェクトをコマンドラインで一括処理したかったのでCCCC (C and C++ Code Counter )というツールを使ってみました。

C and C Code Counter | Get C and C++ Code Counter at SourceForge.net

CCCC is a tool which analyzes C++ and Java files and generates a report on various metrics of the code. Metrics supported include lines of code, McCabe's complexity and metrics proposed by Chidamber&Kemerer and Henry&Kafura.

インストーラーにそってインストールした後、ソースコードのあるディレクトリにcdして、マニュアルにあるとおり、下記のコマンドを打ち込むと解析が開始されます。

解析が完了すると、.ccccというフォルダに結果が格納されます。今回のサンプルには愛用しているサーブレットコンテナのWinstoneのソースコードを使ってみました。研究用のデータを作るには、XMLで出力された結果をパースして一覧を作る必要がありますね。

最近ちょっとメトリクスまわりでゴソゴソやっているので、オブジェクト指向のソースコードを解析する際によく使われる３つのメトリクスについてちょっとまとめてみました。

・McCabeのサイクロマチック数(Cyclomatic Complexity)
・Martinのメトリクス(OO Design Quality Metrics)
・ChidamberとKemererのメトリクス(CK Metrics)

これらは輪講なんかで何度も聞いているものの、いざ自分で使おうと思うと意外と定義を覚えていないものですね。

数日前に見つけた「Coding Horror: Separating Programming Sheep from Non-Programming Goats」を翻訳した、「プログラミングできる人とできない人との間の深い溝」というエントリが興味深いです。

このエントリの元になったpaperはUntitled DocumentのSaeed Dehnadi, "Testing Programming Aptitude"だと思われます。このページには実験につかった問題用紙等も公開されているので、実際にどのような実験が行われたかを確認することもできます。

自分としては共感できる部分が多かったので、自分以外はこの研究に対してどのような感想を持つのかがちょっと気になったので、今日の研究ミーティングで自分が発表するついでに、自分のスーパーバイザの教授陣に少し内容を紹介してディスカッションをしてきました。

プログラミングできる人とできない人との間の深い溝 - 翡翠はコンピュータに卵を生むか

十分なデータ数がないので疑わしいままではあるが，最初のテストにおける3つのグループの違いは「無意味なもの」に対する姿勢の違いのように見える．形式論理的な証明，つまりプログラム（プログラム言語と呼ばれる形式的なシステムで表現されている，特定の計算が可能である形式論理的証明）は，まったく無意味（meaningless）である．あなたはコンピュータプログラムを書くために，あなたがプログラムに意味して欲しいことはなんであれ，これを受け入れる必要がある．機械は盲目的にその無意味なルールに従い，何らかの無意味な結論に至る．

この能力は数学のような抽象的なモデルを理解したり、実際にそれを何かに応用したりするために必要な能力ですよね。現状のプログラミングのトレーニング方法が抽象概念は具体例で学ばないほうがいいという問題を地で行ってしまっている部分があるので、モデルを理解するための支援方法を真剣に考えてみる必要があるのかもしれません。

いちおうソフトウェア工学教育が専門ということになっているので、いろいろとそのあたりの論文はあたっているつもりなのですが、かしこまって論文を読もうとするとどうしても力みが入ってしまっていけないなと思っているのですが、それはさておき、何気なしに見つけたInfoQの下記のレポートがちょっと面白そうです。

InfoQ: 「システム開発」: 新しい教育のための新しい学科

確かに、プロセス、品質、および専門的技術の改善において飛躍的な進歩を遂げましたし、時として私たちは、非常に複雑で信頼性のある使用に適したソフトウェアを提供することができます。それにもかかわらず、業界として私たちは未だに30～40パーセントの「成功」率と、さらにそれより低い「期間内、予算内の成功」率を達成できずに苦心しています。（中略） 主な原因は、私たちが学校で学ぶこと（および学び方）と、私たち専門家自身に必要とされることとのギャップの広がりです。

別の記事に載っているプロジェクトルームの写真を見ると、大きな机を取り囲むように座り、壁にはホワイトボードが張り巡らされ、ポストイットが貼られています。本当にこの状態で実習していたのかというのはありますが、アジャイル開発のオフィスをそのまま大学に再現したようです。逆に会社ではないので、予算があれば、こういう環境を作るのに政治的な抵抗も少ないのである意味やりやすいかもしれませんが。学習内容もバックログで管理していたというのもちょっと気になります。他に論文が出ていないかどうかチェックしてみようと思います。

YourdonのTop Ten SE Conceptsの日本語版がチェンジビジョンの平鍋さんの翻訳でアップされたようです。
ドキュメントのライセンスは原文も日本語訳もGFDLです。

An Agile Way Ed Yourdon の『ソフトウェア工学で大切な１０の考え方』を訳しました。 : ITmedia オルタナティブ・ブログ

新しい世代は、すごいよ、学生はみんなIMで会話して、 Facebookで繋がっている。COBOLプログラマがまだ存在しているなんてことは知らないんだ。でも、ソフトウェア工学の大事なことは、なんども新しい世代が、同じ事実を発見し、過去の重要な論文や書籍にぶち当たる。

内容については僕が論評するまでもないですが、なんと言ってもこの動機の部分が痺れるじゃないですか。業界内にいると、言語が変わったり、プロセスが変わったりするととても大きな変化と錯覚してしまいがちだけれども、ソフトウェア開発の本質的な問題は何も解決されていないってことをYourdonは誰よりも良く分かってる。

ソフトウェア工学ってやればやるほど、なんかどんどん古いところに入っていっちゃうから、こんなの勉強していて大丈夫だろうかって不安になったりとか、退屈な感じがしたりして、先に進むのが不安になることがありますが、自分がやってることが間違っていないよと言ってもらってるみたいで元気が出てきます。ここは一つ、原文をじっくりと読んでおきたいですね。

An Agile Way Ed Yourdon の『ソフトウェア工学で大切な１０の考え方』を訳しました。 : ITmedia オルタナティブ・ブログ

先日、尊敬するエドワード・ヨードン博士が「Top 10 Software Engineering Concept」という文書の公開した、とtwitter でつぶやいていたので、「訳してもいいですか？」と聞いて、5分でOKをもらった。なんというインターネット時代だろう。

Yourdonがtwitterをやってるというのは初耳だったので、検索してみたらあっさり本人を発見。ソフトウェア工学者のはしくれとしてちょっとテンションが上がってしまいました。平鍋さんが訳して良いですか？と聞いたのはこれみたいです。

ちょっとバグの発生件数から信頼度成長曲線を書かないといけない用事ができたので、いろいろ探してみたらExcelでパラメータを推定してグラフが書けるツールを見つけました。

SRATS: Software Reliability Assessment Tool on Spreadsheet Software

SRATS (Software Reliability Assessment Tool on Spreadsheet Software) は，ソフトウェアの品質を高めるために作られたテスト工程管理支援ツールです．

大学で作られているものみたいですが、やっぱりちゃんとこうやって自分で実際に動かしてみることができる^*1ものっていいですね。自分もそういう研究をやっていきたいなと思ったのでした。

• ^*1: 文献に出てくるシステムが自分で動かせることはあまりないので。

CMU^*1のSEI^*2からCMMI v1.2の日本語版が公開されていました。この話自体はもう１ヶ月以上前のことみたいなんですが、全然気づいていませんでした。

SEI，CMMI V1.2の公式日本語翻訳版を公開：ITpro

今回公開されたのはその日本語版。名称は「開発のためのCMMI（CMMI-DEV, V1.2）」で，従来の「システムエンジニアリング，ソフトウェアエンジニアリング，統合成果物プロセス開発，および供給者ソーシングのためのCMMI(CMMI-SE/SW/IPPD/SS, V1.1)」から変更された。V1.2の特徴は，モデルをより簡略化したこと，用語集の説明を拡充したこと，組織の成熟度を5つの段階に分けて表現する「段階表現」とプロセスごとの能力レベルを表現する「連続表現」を1冊で記述したこと(V1.1では2冊になっていた）など。

ダウンロードは「CMMI V1.2 モデル – 公式日本語翻訳版」からできるようです。ソフトウェア工学に関わっているので、早速目を通さないといけませんね。

• ^*1: カーネギーメロン大学
• ^*2: ソフトウェア工学研究所

普通の生活を送っている人にとって学会はあまりなじみがないものだと思いますが、博士課程に通っていれば嫌でも定期的に学会で発表したりとか、論文を投稿したりとかしなければいけないわけで、そういう意味で学会というのは身近な存在です。でも、まだまだ知らない学会というのが存在します。この日本テスト学会もそのひとつ。

日本テスト学会WEBサイト

日本テスト学会は，現時代に即応したテスト技術に関する研究者を育成し，科学的基礎 と教育的理念に裏付けられた新しいテスト法の考え方と評価技術の研究開発・実用 化，産官学を交えた共同のインフラ作りと社会的コンセンサスの構築， 国内外の評価技術関連情報の収集・提供 を目的に2003年5月23日に設立された団体です。

できたのが2003年なので知らなくて当然なんだろうとは思いますが、一般的なテストの基準を考えたりしているみたいです。そういえば私の研究室でもWBTとか研究していたりするんで、そのうちこのあたりのテスト基準を押さえておかないと論文誌投稿の際にツッコミが入ったりするようになるのかもしれませんね。

千葉先生の新刊ということでちょっと買ってみました。なんというか、AOPについて基本的な部分は理解している（と思っている）ので、楽しく読めました。

ぱっと見で、ほとんどが対話形式とソースコード^*1なので、少なくともJavaのプログラムがそれなりにできる人のためのの入門書といった感じなんでしょうか。手順どおりに手取り足取り教えてほしいという人には向かないと思います。

研究のために必要だったので読んでみたのですがなかなか面白かったです。peer reviewだから、読んで字のごとく同等の人同士で行うレビューですね。そういえば、学術論文の査読とかもピアレビューって言いますね。。。。

ただ、欲を言えば全体的にちょっとボリューム不足な感じ。おそらくレビューについてのベストプラクティスについてのまとめを書いたつもりなんでしょうけど、それを導き出すために利用した事例の説明とか、ワークシートの解説なんかが少なすぎて、哲学というか一般論の羅列のようになってしまっているような感じがしました。おそらく、普通の大学生レベルが読んだとしたらそのほとんどがレビューの重要性とか、具体的な進め方なんかに想像力をめぐらすには厳しいと思います。