2006年8月16日水曜日

Empirical Project Monitor

某筋からの調査依頼があって, EASE (Empirical Approach to Software Engineering) プロジェクトの EPM (Empirical Project Monitor) というツールを使ってみた.


うーん, 実に SRA (SRAも絡んでいる) らしいというか, 20 年くらい前も SRA で自分, こんなことをやっていたような気がしないでもないが, まぁ時代は変わる. 今風だ.


基本的には CVS (バージョン管理), GNATS (バグ管理), Mailman (メイリング・リスト) を集めて, そこからいろんなデータをリアルタイムで (つまりプロジェクトの終了後ではなく), 取り出して分析するというもの.


た だ今どきとしては, CVS / GNATSに縛られるのはきつくないですか? Subversion とか Trac とか Bugzilla とかいろいろありますでしょ. どうせ縛られるのならいっそのこと, (例えば) GForge にプラグインするような形にできなかったかなとか, そういうインタフェース (API か SOAPプロトコルか何か) を切るのがまっとうそうな気もしたりする.


それから分析結果もリアルタイム性が売り物なら, Web でページをこそこそめくってみるよりは NASA のコンソールみたいになっていて, まずいことになると全画面が点滅してサイレンが鳴り響くとか.


勝手なこと言ってますが...


coLinux のイメージを使って, Windows でちょっと走らせてみました.

1. colinux を Windowsマシン (うちの場合は Windows 2000 Server SP4)にインストールする



1.1. http://www.colinux.org/ からたどってダウンロード (今回は 0.6.3 を利用)



1.2. coLinux-0.6.3.exe を実行して, インストール



注: 普通は c:¥Program Files¥coLinux にインストールされる



2. EPM をインストールする



2.1. http://empirical.jp/~epm/epm_beta.html からたどって coLinux 用イメージファイル版をダウンロード, 解凍



2.2. c:¥coLinux¥imgs というフォルダを作って, 解凍した中の img/*.img (二つある) をそのフォルダに移動



2.3. 解凍した中の EPM094.colinux.xml を coLinux のインストール・ディレクトリに移動



3. 起動する



3.1. コマンド・プロンプトを起動して, coLinux のインストール・ディレクトリに chdir し, colinux-daemon.exe -c EPM094.colinux.xml する



3.2. Cooperative Linux Console が立ち上がり, boot message が流れる. ログイン・プロンプトが出たら, root/empirical でログインできる



4. 設定する



4.0 は Windows XP の場合には不要. デフォルトの TAP のままでいいはず. 2000 の場合に必要.



4.0.1. Windows2000 の場合には TAP が使えないので, WinPCap をインストール (http://winpcap.mirror.ethereal.com/install/default.htm)



4.0.2. EPM094.colinux.xml を編集して network の行を次のようにする.

<network index="0" name="XXX" type="bridged" ></network>

XXX の部分は「マイ ネットワーク」を開いて普通は「ローカル エリア接続」になっているもの. 日本語でいいとはあまり思えなかったので, それを"LocalAreaNetwork" に変えて, それを指定.



4.1. LAN 内に名前と IP アドレスを用意してもらう (うちでは empirical/192.168.0.213). (ちなみに empirical 以外の名前にするにはあちこちをいじる必要があるので, ここでは empirical という名前にしてください. それから empirical の別名として empirical.localdomain も登録してもらうともっといい)



4.2. coLinux に root でログインしたまま, /etc/networks/interfaces を (vi などで) 編集. 編集するのは, address (上でもらった IP アドレス), netmask (管理者に聞いてください, うちでは 255.255.255.0 のまま), gateway (同様, うちでは 192.168.0.210)



4.3. 続いて /etc/resolv.conf を編集. 編集するのは nameserver (管理者に聞いてください, うちでは 192.168.0.207)



4.4. いったん再起動 (# shutdown -r now)



4.5. ネットワーク内の適当なマシンから http://empirical/ にアクセスして, EPM on coLinux というページが表示されれば OK.



5.0. プロジェクト分析結果を見る



5.1. http://empirical/epmtools/index-j.jsp にアクセス. プロジェクト分析結果を見るほかに表示の時の設定やデータ (コード, バグ・レポート, メイルなど) のバックアップなどの管理もできる.



5.2. デモ的な画面を見たければ, sample_prj というサンプルのプロジェクト・データがあるので, ツール実行 | Analyzer リンク | 左フレーム内ラジオ・ボタンを適当に選択 (特にグラフ選択の部分) | 選択ボタン | 右フレームの表示ボタンで, グラフなどが表示される



5.3. グラフの種類



グラフの種類としては次のようなものがある.



累積・未解決障害件数及び平均障害滞留時間

ソースコードの規模推移

更新時期とチェックアウト数の関連

メール投稿数と更新時期の関連

更新と障害件数

パレート図 (いろいろな関連が指定できる)



6.0. EPM を使う



EPM を使うとは, 要は EPM 用の CVS (バージョン管理), Mailman (メイリング・リスト), GNATS (バグ管理) を使うということだ. で, EPM の本来の仕事はそれらのツールのさまざまなデータを集めて, 見えるようにすること.



とりあえず sample_prj にアクセスできることを確かめてみる.



6.1. CVS



Eclipse を立ち上げて, File | New | Project | CVS | Checkout Projects from CVS | Next | Create a new repository ... | Next

host = empirical

repository path = /var/cvsroot/sample_prj

user = user01

password = empirical

connection type = extssh

Next | Use an existing module | sample_prj を選択 | Finish



6.2. メイリング・リスト



http://empirical/mailman/admin/ がメイリング・リスト管理画面. ここからいろいろなところに飛べる. (失敗したときには URL から.localdomain を外す)



メイルを読み書きするには, empiricalをsmtp, pop サーバとして使えばいいはず.



ユーザとしては user01 ~ user20 (パスワードはどれも empirical) がデフォルトで定義されている.



6.3. バグ管理



http://empirical/cgi-bin/gnatsweb.pl からいろいろなところに飛べる.



アクセス管理はない!? どんなユーザ名でも入れてしまう. View Problem Report # に1, 2, 3のいずれかを入れると見られる. 新規に作ることもできる.



というわけで, とりあえず動いているらしいということは分かった...

2006年8月4日金曜日

オブジェクトの西海岸派

UML VM 絡みであるプレゼンテーション (PowerPoint なので注意) を見ていたら, 「オブジェクトには西海岸派と東海岸派がある」などと書いてある. 東海岸派は「オブジェクトはプログラミングのための便利な道具」と思っている人たちで, クラス中心主義者. 西海岸派は「オブジェクトは考えるための道具」と思っている人たちで, オブジェクト中心主義者.


おお, 面白い, 便利じゃんと思ったけれど, 初めて聞いた. こんな言い方, するんですかね. これを書いている人はノルウェーの人なんだけど.


この区分で行けば, 自分はもちろん西海岸派だけど, 今の圧倒的多数の「オブジェクトでやっている人たち」は東海岸派だろう. C++ (New Jersey) は言わずもがな, Java (California) も東海岸派のものだ. それは構造化の手法であってオブジェクトではない, と敢えて言おう. だから今の「オブジェクトでやっているプロジェクト」のほとんどもそれを「オブジェクトでやっています」なぞと言って自滅するくらいならば, 構造化の手法をきっちり使ってやればいいんじゃないの. どうせその程度でしょ.


オブジェクトの良さはぜんぜん違うところにあるんだから. ま, そういう意味でオントロジ (西海岸派の隠し球ですよ) が少しずつ注目されているのはいいことかもしれない. そのうちまた乗っ取られちゃったりするかもしれないけど...