« 2009年9月 | トップページ | 2009年11月 »

2009年10月

2009/10/31

レビュープロセスを効率化するには?

ReviewBoardとコードレビューに関するメモ。

【元ネタ1】オンラインコードレビュー支援ツール「Review Boad」

これまで自分がやっていたソースコードのレビューは紙に印刷して、赤ペンでガリガリ書いていくというスタイルだったので、ちょっと目から鱗でした。そんな感じでコードレビューをやっていくと手間がかかる割には、使い終わった後はゴミ箱に捨てられていたりしたわけですが、これを使うとレビュー結果が蓄積されていくので便利ですよね。
そう考えると初等プログラミング教育用としても使うのも面白いのかなと思っています。先生をやっていて、その辺りが一番やりきれない部分だったので。。。。

昔も今もコードレビューする場合、大量の紙を印刷して、赤ペンでガリガリチェックするのが普通だろう。
パソコン上で差分表示しながらレビューしてもいいが、レビューコメントを残したりするのが面倒だから。
モニタでは目が疲れる理由もある。

コードレビューやデザインレビューは、20年前の机上デバッグの頃と何ら進歩していない状況と言えるのではなかろうか?
だからこそ、ReviewBoardでコードレビューをWeb化する利点がある。

【元ネタ2】ReviewBoard: 雲の亀日記

雲は、ソフトウエアの開発では情報の共有が最も重要だと思っています。
ここで言う情報とは、仕様書とか機能のことではなくて、どちらかといえば、暗黙の知識・経験といったことを意図しています。その一つとして、開発者個人が持っている暗黙知の共有としてのコードレビューに高い意義があると個人的には感じています。ただ、現状のコードレビューにはその効果が全く無い(←極論)と思っていて何とかならないものかと、つねづね考えていました。
で、忙しいくせについついそういうことを検索していると、ReviewBord というものに行き当たりました。これは、素晴らしい。これを使うと、コメントとソースコードがリンクしてくれるので、後から見直すのも楽だし、修正方法も明確に理解できる。こういうシステムを導入することで、生産性は飛躍的に向上しそうな感じがします。
生産性向上には、プロセス以外のファクターの要素も絡んでいることが多くのマネージャーにもっと理解されるようになると良いですね。

ソフトウェア開発では、暗黙知の共有が重要とよく言われる。
その理由は、仕様や設計、アーキテクチャなどの情報はExcelや紙などの媒体だけでは、メンバーに伝わらないから。

何故そんな汚いパッチが付けられたのか?
何故そんな修正が発生したのか?

コードレビューは単なる欠陥探し、あら探しではなく、メンバー同士で暗黙知を共有し合う場でもある。
コードレビューはXPのペアプロの代替手段なのだ。

【元ネタ3】「ピアレビュー」を読みました ― ありえるえりあ

3章に「インスペクション」、「レビュー」、「ウォークスルー」の比較表があります。
誰が定義したんだ、と言いたくなる比較表で、この定義に従う必要性は感じませんが、この3つの用語、日常の中であまりに曖昧すぎて何を指しているのか分からないのも事実です。
比較表を見る限り、モデレータ、作成者、読み手の役割の部分が明らかな相違です。


* インスペクション: モデレータ、作成者、読み手を、それぞれ別の人が行う。
* レビュー: インスペクションとウォークスルーの中間形態(モデレータと読み手が一致する場合など)。
* ウォークスルー: 作成者がモデレータかつ読み手を兼ねる。

コードインスペクションをしていて思うのが、本当は、デバッガで動的にコードを追いながらコードを見る方が効率的だろうな、という思いです。
デバッガを使わず、頭の中だけでコードを動かしてバグを見つけられる自分のスキルを誇らしく思う気持ちは、正直に告白すれば、あります。
しかし、自分のささやかなプライドを満たすことがコードインスペクションの目的ではありません。

レビュープロセスは、プログラミングやテストとはプロセスが異なる点に注意すべき。
最も厳格なプロセスがインスペクション、中間がレビュー、プライベートっぽいプロセスがウォークスルー。

ウォークスルーは、IT勉強会でよく行われている形式だろう。

レビューで必要な役割は、プログラミングやテストの場合と異なる。
レビューでは、モデレータ・作成者・読み手・記録者の4つの役割がある。

普通は、レビューの形式が多いだろう。
つまり、レビューアがモデレータ、レビューイが作成者・読み手・記録者を兼ねる。

このプロセスの欠点は、レビューアやレビューイの負担が大きい。
レビューイは、レビューで指摘された内容を記録し、理解し、修正したのを再チェックするプロセスが曖昧になりがち。
レビューアは、たくさんのレビューイからレビューが寄せられて、開発プロセスのボトルネックになる。

しかし、インスペクションをいつも開催するのは工数がかかりすぎる。
普通は、インスペクションは優先順位の高い成果物に絞って行ったり、レビューの進捗管理に注意を払ったりする。

BTSを導入してタスク管理や進捗管理を効率化できたり、TestLinkを導入してテストの進捗管理を効率化できたように、レビューもツールを導入して効率化できないのだろうか?

【元ネタ4】Karl E. Wiegers著『ピアレビュー』日経BPソフトプレス、2004.3.1、2900円(税別)、<高品質ソフトウエア開発のために同僚同士で行うレビュー>

・ピアレビューはすべて、「計画、作業成果物の準備、レビューミーティング、エ
ラーの修正、修正の検証」の5つのアクティビティの何らかの組み合わせです。
--------------------------------
ピアレビューの種類   計画  準備  ミーティング  修正  検証
--------------------------------
インスペクション     ○    ○    ○        ○    ○
チームレビュー      ○    ○    ○        ○    ×
ウォークスルー      ○    ×    ○       ○    ×
ペアプログラミング    ○    ×    継続的     ○    ○
ピアデスクチェック、   ×    ○   可能       ○    ×
パスアランド
アドホックレビュー    ×   ×    ○        ○    ×
--------------------------------

レビューにも色んな種類がある。
最も効果があると言われるインスペクションを行う為に必要なノウハウを書いている本が『ピアレビュー』。

レビュープロセスは、おそらく20年前から何も進化していない。
レビューがシステムの品質改善に有用であると誰もが理解しているのに、徹底できない理由は、プロセスの運用に壁があり、プロセスを効率化できていないからだ。
何とかならないのだろうか??

ここ5年間で、開発環境だけでなくプロジェクト管理を巡る環境が急激に変化している。
RailsやPHPで簡単にWebシステムを作れるようになってから、タスク管理・進捗管理・テスト管理・バージョン管理が急激に進化している。
チケット駆動開発もこの流れの上にのっている。

レビュープロセスもこの流れの延長線上で、運用のハードルを下げるべきだ。

|

2009/10/28

プランニングポーカーのカードが欲しい

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」第2版が出版されたのを記念に、プランニングポーカーのカードが付属して売られている。
初版は持っているけれど、欲しくなってきた。。

【元ネタ】
Toshiyuki Kawanishi Blog : プランニングポーカーのカードが届く by Toshiyuki Kawanishi

プランニングポーカーの説明は、「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」のp.97に出てくる。
各人が担当する機能を見積もる時、フィボナッチ数列に基づくカード(プランニングポーカー)を出し合って、見積もりを決めること。
ゲーム感覚でやるのがいい。

開発者の性として、見積もりは慎重になりがちで、無駄なバッファを取りがち。
全ての見積もりを合計すると納期をオーバーしてしまうだけでなく、開発したら必ずバッファを食い潰してしまう。
だからクリティカルチェーンのような発想が出てくるのだろう。

プランニングポーカーが開発の現場で使えるかどうか試してみたい。

| | コメント (0) | トラックバック (0)

IT資産管理システムi-doIT

IT資産管理システムi-doITについてメモ。

【元ネタ】
MOONGIFT: 社内のIT資産を一元管理する「i-doIT」:オープンソースを毎日紹介

Main Page - i-doit documentation

奄美沖縄関係情報収集サイト - i-doitインストール - suamaさんの日記

i-doITはPHPで作られたIT資産管理システム。
主にPC・サーバーなどの機器を管理するために使う。
昨今、IT企業でもサーバーは原価ではなく資産になっているから、ハードウェア機器をきちんと管理するのは、会計上、非常に重要。
きちんと管理しないと、サーバーを持っているだけで資産にカウントされてしまい、売上げは赤字なのに税金をたくさん取られてしまう場合も出てくる。

ITILの構成管理プロセスでは、構成管理データベース(CMDB)はそもそもIT資産を管理するためにあると言っていい。
CMDBの要素であるCI(構成アイテム)は、例えば社員のPCだったりする。
この時、PCと付属しているマウス・キーボード・ケーブルなどをセットで管理するか、別々に管理するか、で管理コストは大きく変わる。
普通は、PCとマウス・キーボード・ケーブルなどをセットで資産管理番号を振り、Excelの帳簿で管理しているだろう。
そうしなければ、数百人~数千人の社員が使うコンピュータの管理が煩雑になってしまうから。

普通のIT企業では、サーバーやPCなどの資産はどのように管理しているのだろうか??

| | コメント (2) | トラックバック (0)

TestLinkCnvMacroメモ

TestLinkCnvMacroの使い方が書かれていたBlogをメモ。

TESTLINKマクロのススメ - 台湾サラリーマン日記

TESTLINK エクセル変換マクロでデシジョンテーブルを取り込む。 - 台湾サラリーマン日記

TestLinkを中国語で使っている例としても興味深い。

| | コメント (0) | トラックバック (0)

2009/10/27

オープンソースへの貢献は福利厚生

Googleの開発プロセスで面白い記事があったのでメモ。

【元ネタ】
ソースコードから見るグーグル気質、規律を持つ気さくな開発者集団 1頁:ITpro

ソースコードから見るグーグル気質、規律を持つ気さくな開発者集団 5頁:ITpro

【開発プロセス】
・グーグルの開発スタイルでは、デザインドキュメント+コードレビュー+単体テストが必須
・コードレビューや単体テストは、高品質なソフトウエアを開発するプロセスとして、近年その重要性への認識が高まっている

 自動テストだけでなく、コードレビューを開発プロセスに組み込んでいる点に注目すべき!
 コードレビューは欠陥探しだけでなく、より良い機能への提案や良いプログラムへの賞賛も含まれる。
 コードレビューは開発者同士の信頼関係を高める作用がある。
 コードレビューをそのように扱えば、チームワークの強化にもつながるだろう。

【オープンソースへの対処】
・オープンソース界出身のプログラマにとって、自分の書いたコードを社外の人々にも見せたいし、議論して磨き上げたい欲求は自然
・良いプログラマを集め、プログラマのモチベーションを高めることが、自社のプログラムやサービスを改善させる最良の手段

 オープンソースに優しい環境は、自社開発のリソース削減に役立つだけでなく、プログラマのモチベーションを高めているという指摘。

 Googleだけでなく、オープンソースという仕組みは、技術者にとって非常に重要だと思う。
 その理由と影響度合いはもう少し考えてみる。

| | コメント (0) | トラックバック (0)

2009/10/25

Rietveld のインストール方法

ReviewBoardとは別のコードレビューWebシステムRietveld をインストールしてみたら、すごくあっさりインストールできた。

Rietveld はGoogleのコードレビューシステムMondorianを作った人が開発しているらしい。
Rietveld のインストール方法についてメモ。

【元ネタ】
Google謹製 ソースコードレビューシステム rietveld(オープンソース版 Mondrian)を動かしてみましょう - ふにゃるん

オープン ソース アプリケーション: Rietveld コード レビュー ツール - Google App Engine - Google Code

ARMで動くかどうか試してみる - kinneko@転職先募集中の日記

Django での App Engine アプリケーションの実行 - Google App Engine - Google Code

【Rietveld のインストール方法】
まず、GAE for Pythonを取得する。

wget http://googleappengine.googlecode.com/files/google_appengine_1.2.7.zip

rietveldの最新ソースを取得する。
rietveldのディレクトリは、GAEのルートフォルダに置く。

cd /usr/local/google_appengine
svn co http://rietveld.googlecode.com/svn/trunk/

ノーハングアップでバックグラウンド起動する。

nohup python dev_appserver.py --address=サーバーのIPアドレス --port=8100 ./rietveld &

http://サーバーのIPアドレス:8100 でアクセスできる。


使ってみた感じでは、GoogleCodeのようなUIで、ReviewBoardと似たような方法でコードレビューができる。
つまり、diffファイルをアップロードし、SVNリポジトリのパスを通せば、コードレビューができる。

コードレビューシステムとして、ReviewBoardとRietveld を比較すると、ステータス管理とBTS連携に違いがあるように思う。

ReviewBoardのステータスは「新規」「終了(submitted)」しかないが、Rietveldでは「新規」「担当中」「終了」の3種類がある。
Rietveldの一覧画面で、3種類のステータスごとに分類されて一覧表示されるので便利。
但し、ReviewBoardの一覧画面でも、「自分がレビューアのリクエスト」と「全てのリクエスト(新規・終了)」で表示されるから、どちらもできることは似ている。

また、ReviewBoardのリクエスト画面には「レビューの状態」項目がテキスト入力可能になっていて、この項目を更新していけばいい。
つまり、コードレビューのワークフローを管理することは可能だ。

他方、RietveldにはなくてReviewBoardにある機能として、BTSチケットと連携する機能がある。
TestLinkと同様に、コードレビューが発生した場合、進捗管理はBTSチケットで行い、ReviewBoardでコードレビューの詳細な作業を行うように区別したらやりやすいかもしれない。


色々試してみたいと思う。

| | コメント (0) | トラックバック (0)

テスト手法の概念をTestLinkで説明する

脱Excel! TestLinkでアジャイルにテストをする - @IT自分戦略研究所で書ききれなかったテスト手法の概念についてメモ。

【元ネタ】
脱Excel! TestLinkでアジャイルにテストをする - @IT自分戦略研究所

TestLinkを運用して気付いたことpart8~みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索

TestLinkを運用して気付いたことpart9~後追いテスト: プログラマの思索


下記の資料にまとめてみた。
ちなみに下記のテスト用語(方言?)はTEF関西のNakaさんから教わった。

【1】ブロック、ブロッキングバグ、みなしバグ、みなしOK、周辺テストの概念

上記1枚目で、Ver2.0のカート削除1のテストケースでテストに「失敗」したとしよう。
その場合、カート削除2のテストは、カート削除1のバグに依存して必ず失敗するから、開発者をびびらせる意味も込めて「失敗」にする。
つまり、カート削除2のテストケースは、みなしバグになる。

更に、カート機能でバグが発生していて注文機能のテストを進められない状況の場合、注文機能のテストケースは全てテスト保留にする。
つまり、注文機能のテストケースはブロックになり、カート機能のバグが解消され次第、テストを再開できる。

又、カート削除1のテストケースからRedmineへバグチケットが発行される。
このバグは、みなしバグやブロックしたテストケースなど数多くのテストケースに影響範囲があるから、ブロッキングバグになる。
つまり、ブロッキングバグはテスト進捗を妨げる重大なバグである。

ブロッキングバグの修正が完了し再検証する場合、テスターには、ブロッキングバグの検証だけでなく周辺の関連機能も回帰テストするように管理者は指示しておく。
理由は、ブロッキングバグの修正で、デグレが起きていないか、他機能への考慮漏れが発生していないか、確認して欲しいからだ。
上記の例では、カート投入機能は既に成功しているが、もう一度最初から、カートへ商品を投入してカートから商品を削除するようにテストする。
これを周辺テストと呼ぶ。

Ver2.0のテストを実施していて、今回の機能改修でソースを修正しなかった機能のテストは、既に運用済みで品質が担保されている場合もありうる。
例えば、Ver2.0で念のために実施する必要があるものの、テスト工数や納期の関係で優先順位が低くテストしなくてもいい場合がある。

これらのテストケースをあらかじめ成功にするが、テストを実施して成功にする状態と区別するために、みなしOKというステータスにする。
但し、みなしOKのテストケースでもしバグが発生したら、結局全てのテストケースを再テストする必要がある。

上記をまとめると、テスト実行後のステータスは、未実施・成功・失敗・ブロック・みなしOKの5種類がある。
更に、テスト結果の検証に時間がかかる場合、検証中というステータスも欲しくなるだろう。
例えば、クレジットカードのシステムでリボ払いの計算結果を検証する時、テスト結果を取得するだけで、検証は後日行う場合があるだろう。
この場合では、テスト担当者とテスト検証者は異なる時が多いだろう。
つまり、ステータスは、未実施・成功・失敗・ブロック・みなしOK・検証中の6種類は最低必要ではなかろうか?

TestLinkでは、ステータスが未実施・成功・失敗・ブロックしかなく、GUI上からステータスを増やせない弱点はある。
しかし、Ver1.8以降では、設定ファイルcustom_config.inc.phpに下記の記述があるので、ステータスを増やせるかもしれない。

// $tlCfg->results['status_code'] = array (
// "failed" => 'f',
// "blocked" => 'b',
// "passed" => 'p',
// "not_run" => 'n',
// "not_available" => 'x',
// "unknown" => 'u',
// "all" => 'a'
// );

【2】後追いテスト、五月雨テストの概念

上記2枚目で、Ver1.0のリリースが目前に迫っている時だとしよう。
携帯のような組込み機器、業務システム、パッケージ製品のリリース直前では、1週間前~1ヶ月前からコードがFreezeされて、開発チームは、インストーラを作成したり、本番環境を構築する等のリリース作業に入る。
リリース確定後、出荷前までの期間で、テスト担当者が、みなしOKにしたテストケースをテストしたり、回帰テストを行うテスト手法を後追いテストと呼ぶ。

後追いテストの目的の一つは、空き時間を使って更なる品質チェックを行うことだ。
普通は、この時期では、製品に重大な支障が発生するようなバグは全て潰されているはずだが、表示がちょっとおかしかったり、UIをもう少し改善できるなど、些細な修正点はテストすればするほど出てくるはずだ。
そのようなプロダクトリスクの低いバグを洗い出し、次のVer1.1へマージしてリリースできるようにする。
但し、後追いテストで重大なバグが見つかった場合は、Ver1.0のリリースを延期することもあるだろう。

Webシステム開発では、リリースした本番ブランチ上のシステムに対して、リリース後に後追いテストで優先順位の低いテストを行う時もあるだろう。

一方、開発して単体テストが完了した機能から順次テストしていくテスト手法を五月雨テストと呼ぶ。
例えば、携帯のテストならば、SNSメール登録が先に開発できて、普通の携帯メール機能は開発中の場合、SNSメール登録を先にテストしてバグ出ししていく。
そのテスト結果を開発チームにフィードバックして、普通の携帯メール機能にも取り込んでいく。

アジャイル開発は基本は五月雨テストだと言える。
つまり、開発できた機能から順次テストしていく開発スタイル。
脱Excel! TestLinkでアジャイルにテストをする - @IT自分戦略研究所で紹介した僕のテスト手法は、五月雨テストと同じだ。

僕がTestLinkを運用した時、テスト計画のテストケースが少ない場合、テスト計画をイテレーションに含めた。
逆に、テスト計画のテストケースが多い場合、開発のイテレーションから分離して、テスト計画を更に分割して、複数のイテレーションで順次テストしていった。
例えば、結合テストPh1・Ph2、システムテストPh1・Ph2・Ph3のようにテスト計画を順次実施していくテスト戦略になる。

僕のやり方とは別に、第5回 脱Excel! TestLinkでアジャイルにテストをする - hokorobiの日記にあるhokorobiさんのテスト手法のように、1個のテスト計画で複数のビルドで管理する方法もある。
これは、Excelのテスト仕様書の管理と同じように、1個のテスト仕様書へ結果を追記していくのと同じやり方だ。

僕もこのやり方を試した時はあったが、アジャイル開発に組み込みにくかった。
理由は、イテレーションと言う概念を当てはめにくいから。
テストで一番嫌なのは、テストすればするほどバグが出て、バグ修正&検証がエンドレスになってしまうこと。
イテレーションがあるからこそ、リリースが定期的にあり、プロセスを改善するタイミングが生まれやすい。

また、ビルドの途中でテストを中断して、次のビルドに移るから、テスト実行結果のステータスが曖昧になりがち。
そもそもブロックを使う必要もない。
ブロックや見なしバグなどが必要な理由は再テスト工数を計算したいからだ。
100件のテストを行う場合、10件失敗すれば、テスト工数は110件も膨れ上がる。
プロジェクト管理の基本はクリティカルパスの管理だから、再テスト工数を見積もるのは非常に重要なのだ。

又、テスターが少なすぎたり、テスト期間が短すぎたり、テストケース数が多すぎると、テスト計画を立てた時点でもはや全てテストできなくなる確率は大きい。
特に、デシジョンテーブルや直交表でテストデータのパターンを作りこむシステムテストでは、テスト網羅の観点からテストケース数が爆発しやすく、その危険は高い。
だから、イテレーションにテスト計画を組み込むことで、テスト工程のマネジメントを管理しやすくするのだ。

【3】とある勉強会で、最近のシステム開発の傾向は品質よりも納期を重視しているようだ、という話があった。

ビジネス的背景としては、3ヵ月後の景気すら誰も分からない状況で、数年もかけてシステム開発するのはリスクが非常に高い。
また、MixiアプリやGoogleのサービスのように、先にリリースした者がマーケットを支配する状況が多くなっているからだ。
だから、最低限の品質は担保した上で、小刻みにリリースしていく開発スタイルが多くなっているように思う。

更に、技術的背景としても、後追いテスト、五月雨テストのようなテスト手法がやりやすくなっている。
例えば、携帯電話やiPodのような組込み機器でも、リリース後にSWアップデート機能でアプリケーションだけでなくROMそのものも更新できるようになった。
Webシステムなら、サーバーにデプロイさえすればいいから、リリースしやすい。

つまり、後追いテスト、五月雨テストのようなテスト手法は昨今のSWテストにマッチしやすい特徴があると思う。


TestLinkはまだまだ機能改善の余地があるけれど、上手に使いこなせれば、テストプロセスの品質向上で大きな威力を発揮できると思う。

| | コメント (0) | トラックバック (0)

2009/10/23

【公開】脱Excel! TestLinkでアジャイルにテストをする - @IT自分戦略研究所

下記の記事を公開した。

脱Excel! TestLinkでアジャイルにテストをする - @IT自分戦略研究所

上記の記事で、TestLinkで経験したこと、考えたこと、理解できたことは全て書いた。
記事のポイントは3つある。

一つ目は、TestLinkをアジャイル開発に組み込むための運用サイクルを工夫したこと。
基本は、TestLinkのテスト計画をイテレーションの一部、あるいは、開発とは別のイテレーションに見立てて、小刻みにテストしながらリリースしていく運用にする。
これによって、テストするほどバグが出て、延々とゴールのないシステムテストから解放される。

二つ目は、TestLinkに合わせたテストケースにすること。
結合テストやシステムテストで実際に使うテストケースを例にあげたので、理解してもらえると思う。
他人の話を聞くと、膨大な既存のテストケースをTestLinkにインポートする方法に苦労しているようなので、参考にして欲しい。

三つ目は、TestLinkとBTS(Redmine)と連携して、バグ修正とバグ検証をワークフロー管理すること。
この手法によって、バグ修正(PG)とバグ検証(テスター)がペアプロのように作業できるので、品質向上に役立つ。
更に、テストに失敗して影響範囲が大きい場合、テストケースをブロックする。
このブロックというステータスについても、詳しく説明した。
ブロッキングバグ、みなしバグという概念によって、再テスト工数が計算でき、最終的にはテストのクリティカルパスを導くことができる。
テストケースのステータスは「成功」「失敗」以外にも色々あることを知って欲しいと思う。

感想があれば是非フィードバックして欲しいです。

【追記】
はてなブックマーク - 脱Excel! TestLinkでアジャイルにテストをする − @IT自分戦略研究所

(引用開始)
p260-2001fp TestLinkを使いこなすなら必読の記事。TestLinkCnvMacroによる一括インポートの例あり。
(引用終了)

| | コメント (0) | トラックバック (0)

2009/10/20

KnowledgeTree、Alfrescoをドキュメント管理に使う

オープンソースのコンテンツ管理システム(CMS)であるKnowledgeTree、Alfrescoをドキュメント管理に使うアイデアについてメモ。
#あくまでもメモ書き。

【元ネタ】
文書管理システム - Wikipedia

Alfresco - Wikipedia

[ThinkIT] 第1回:NASAにも導入されたAlfrescoとは? (1/3)

[Think IT] 第2回:AlfrescoがECMとして優れている理由 (1/3)

@IT:明日からできるプロジェクト管理(2)

KnowledgeTree――様々なニッチ市場を射程に捉えるドキュメント管理システム - SourceForge.JP Magazine

【ダウンロード】
BitNami :: Alfresco

BitNami :: KnowledgeTree


KnowledgeTree、Alfrescoの特徴や使い道は下記だと理解している。

1・Web上の共有ファイルサーバーとして使う。
→共有サーバーでファイル管理の欠点は、最新版が分からなくなりどんどんゴミデータが増えていく点。

2・システム監査の一環として、監査証跡の管理に使う。
→ファイルのアクセスログを監査証跡として使い、不正なアクセスや更新がないかチェックする

3・履歴管理や要件管理
→SVNリポジトリのように更新履歴が残る。
 ファイル同士で相互リンクできる性質から、要件の追跡に使ったりできる。
 WordやExcelの差分表示は可能??

4・ワークフロー管理
→文書ごとに修正フローを変える。ユーザ権限によってファイル操作を制御できる。

5・全文検索エンジン
→登録した全ファイル(Word、Excel、PowerPoint)を検索できる。タグ検索も可能?


CMSを使う動機は文書管理システム - Wikipediaに詳しく書かれているが、現場リーダーとしては、共有ファイルサーバーの代替機能としてだ。
つまり、共有サーバーにあるファイルサーバーをWeb上で一括して共有・管理したい。

ドキュメント管理はSVNのような構成管理でもよいかもしれないが、実際のプロジェクトでは、構成管理の配下に置かないファイルはとても多い。
それらは不要かもしれないが、後に必要になるかもしれないが、SVNで管理するほどでもない。
そんなファイルも全てCMSで管理すると楽になるのでは?という発想。

CMSを使ってやりたい事は二つある。

一つは、強力な全文検索エンジンをフルに使う事。
最新版のドキュメントから、欲しい仕様をGoogle検索のように検索したい。

僕のチームでチケット駆動開発を実践した時、ソースもドキュメントもSVNで全て管理したのは良かったけれど、最新の仕様が探しにくいという課題が開発者からあがった。

ソースならEclipse上でGrepすればよいが、ExcelやWordの検索はWindowsのデフォルト機能では遅いし使い勝手も悪い。
CMSの全文検索エンジンが使えれば、プロジェクトの全てのドキュメントから仕様を検索して、リバースエンジニアリングするのが楽になるだろう。

CMSを使わずとも、全文検索システム Hyper Estraierを使う手もあるかもしれない。

もう一つは、設計レビューで使いたい事。
RevireBoardのように、仕様書の差分箇所にレビューコメントを付けて、きちんと修正されたか確認するようにする。
これができれば、気軽にレビューできるし、レビューの指摘が修正されたか、更には修正を検証したか、というワークフロー管理も可能になるだろう。

ソースのレビュー管理は、コードレビューシステムRevireBoardもあれば、RedmineやTracのコードレビュープラグインを使う方法もある。
しかし、ExcelやWordで書かれた設計書のレビュー管理は、そのワークフロー管理が面倒。
CMSに付属しているワークフロー管理を上手に使えばいいかもしれない。

但し、ドキュメントはSVNで管理しているので2重管理になる。
TorotiseSVNの差分機能をレビューに使った方がいいかもしれない。

何よりも、レビューのボトルネックはレビューアの負担が大きいこと。
レビューアの負荷が大きくなり、開発もテストもレビュー工程で進捗が滞りがち。
レビューのワークフロー管理がうまく機能すれば、レビューの優先順位付けも楽になり、レビューの効率が上がるのではないか?
そのために、チケット駆動開発のように、レビューのワークフロー管理をWeb上で管理できるようにしたい。

まだアイデアに過ぎないが、色々試してみたい。

| | コメント (0) | トラックバック (0)

2009/10/19

ソフトウェアテストPRESS Vol.9にあるTestLinkの記事

ソフトウェア・テスト PRESS Vol.9にありえるえりあさんによる TestLinkによるテスト管理記事が載っていたのでメモ。

【元ネタ】

TestLink使用レポート ― ありえるえりあ

TestLinkを検証しました ― ありえるえりあ

SWテストを管理者・開発者・テスト担当者の観点から書かれていて面白かった。
TestLinkの内容は上記のBlogと殆ど同じだった。

興味深かった点を書いておく。

【1】開発チームとは別にテストチームを作った理由が書かれていた。

元々、プログラミングによる開発が一番大事で、そもそもテストチームは必要とは思えなかった。
知っているテスト担当者から愚痴ばかり聞いていたから。
しかし、開発してテストしてリリースする一連の作業で、開発者だけの場合、開発者は実装するよりもテストする作業が半分以上に増えて、肝心の開発作業が滞りがちになった。
だから、開発者がバグ修正に専念できるように、テストチームを作らざるを得なかった、と。

この理由はなるほどと思わせる。
開発チームとテストチームの2つの部隊を作らざるを得ない理由は、マネジメントの問題なのだ。

単純な単体テストレベルならば、開発者もやっているが、システムテストや受入テストのレベルになると、テストの事前条件やテストデータの作りこみに手間がかかる。
更に、テスト結果の検証作業も、システムテストや受入テストでは、とても大変になりがち。
開発の片手間でできる作業ではない。
だから、テストチームの役割は、複雑なテスト作業とその検証作業の専任になる。
特に大規模開発ほど、この傾向は強いだろう。

又、テストチームのコストについて書かれた内容も興味深かった。
いわく、テストチームそのものは開発上のコストになるが、当社はパッケージ製品の開発が主業務なので、実際のテストは回帰テストが多い。
つまり、単純になりがちなので、テスト担当者が専門でテストした方が、開発者は実装の専念しやすい、と。

ハードと違い、ソフトはどんどんバージョンアップしていく。
だから、過去のバージョンの機能がデグレせずに正常動作することを検証する必要がある。
つまり、バージョンアップするに従って、テストケースは単調増加で増えていく。

過去のバージョンのテストは結局、回帰テストになる。
機能テストのレベルならばJUnitでテストを自動化できるが、システムテストや受入テストでは、UI周りのテストを自動化する速度よりも機能追加の速度が早くて追いつかず、結局、コストが合わない時が多い。

この辺りの解決方法の一つとして、TestLinkで手動のテスト作業の管理を効率化する点があるだろう。


【2】リリース判定条件として、信頼度成長曲線を止めて、タイムボックス形式(イテレーション)へ変更した理由が書かれていた。

ハードのように、信頼度成長曲線を書いてバグの歩溜まりになったらリリースする判定条件にしても、実際はリリース後に障害が数多く発生する時は多い。
その理由は、ソフトでは、信頼度成長曲線は人為的に操作しやすいからだ。
例えば、テストするスコープを狭めれば、確かにバグは減っていくだろう。

しかし、実際のソフトウェア開発は、仕様変更が任意に勃発するので、長期間スコープが固定化された状態はありえず、結局、バグはいつまで経っても収束しない時は多い。
だから、オープンソースのようにタイムボックスごとにリリースしていくのが一番現実的だ、と。

このリリース手法は、まさにアジャイル開発そのもの。
タイムボックスをイテレーションと見なせば、イテレーションというサイクルで小刻みに機能追加しながらリリースしていく開発スタイルになる。

アジャイル開発の場合、短い期間だけれどもイテレーションの間はスコープは固定されているので、品質を高めやすい利点がある。

例えば、イテレーション期間中に仕様変更が生じたら、次のイテレーションで対応するとアナウンスすればいい。
まずは目の前のイテレーションの機能を実装してリリースするのを目標とする。

又、品質とは、単に信頼性だけではない。
顧客にとっての価値とは、欲しい時に欲しい機能があることなのだから、納期も重要な制約条件だ。
品質重視でリリース時期が遅れたら、顧客のビジネスにも支障が出やすい。
だから、アジャイル開発では、スコープを制御することで、品質を保持し、納期を守るようにするのだ。

テスト工程のマネジメントは、上流工程のマネジメントよりもはるかに難易度が高い事実を改めて考える必要があると思う。

| | コメント (0) | トラックバック (0)

2009/10/16

ReviewBoardを使うプロセスとは?

コードレビューWebシステムReviewBoardを久しぶりに触ってみて、考えたことをメモ。

【元ネタ】
ReviewBoard 釣られて使ってみた | tsuyuki.makoto

Review Board is good software - O'Reilly Radar

Why We Use ReviewBoard For Code Reviews | Engineering Game Development

Review Board | Documentation | Users Guide

【1】ReviewBoardのリクエストを登録するには、ソースが置かれているSCMリポジトリのディレクトリとパッチ(diff)をアップロードしなくてはならない。
まずこの作業が面倒だと思った。

登録したリクエストには、パッチが差分表示されて、任意の行に指摘事項とそのコメントが自由に書ける。
画面の色も鮮やかで、UIはAjaxがバリバリ使われているので、使いやすい。

更に、リクエストにはBTSチケットNoを書くと、BTSにリンクする機能がある。
つまり、レビューと言うタスクのチケット、あるいは、レビューを受けて修正するタスクのチケットをリンクすればいい。
この機能によって、レビューのステータス管理はBTSで行えばいい。
BTSはURLを入力する形式なので、TracでもRedmineでもOK。

でも、ReviewBoardの機能には下記の不明点がある。
Review Board | Documentation | Users Guideを読むと、色々あるようだが今は分からない。

・検索機能は?
・リクエストをステータス管理できる?
・コードレビューの集計結果を表示する機能は?

【2】「ReviewBoard 釣られて使ってみた | tsuyuki.makoto」にこんな一節がある。

Tracのような感じなのかと思っていたけれど、実は全然違うものでした。
ReviewBoardは、『改変したコードを、Subversionにコミットする前に、レビューを受ける』ためのツールです。


ReviewBoardにリクエスト(パッチのレビューを受けるチケット)を登録して色々触ってみて思ったのが、上記と同じ感想だった。

これらの使い方を考えると、trunkにコミットする前に必ずレビューを受けて修正するプロセスを前提としているのが分かる。
だから、SCMリポジトリのパスとパッチ(diff)が必要なのだ。

この考え方によると、trunkにコミットする前に実装したソース、あるいは、レビューを受けて修正して再レビューを受ける前のソースは、やはりどこかにバックアップしておきたいだろう。
多分、GitやMercurialのような分散バージョン管理で別リポジトリに管理するか、trunkとは別のブランチにコミットして履歴を残すのが普通だろう。

つまり、レビューと言うプロセスはトピックブランチと相性がいいだろうと推測される。

BTSチケットをXPのタスクカードのように扱う発想がチケット駆動開発のアイデアだが、チケット駆動開発ではカバーできないプロセスとして、テスト管理(TestLink)やレビュー管理(ReviewBoard)があるのだ。

僕はTestLinkを使いこなしながら、テスト管理の奥深さを経験した。
ReviewBoardにも同様に、レビューというプロセス特有のコンテキストが隠れているように思う。


【3】GoogleがMondrianというコードレビューツールを使って、ソースの品質や設計情報の共有を図り、大きな効果をあげている現実がある。
コードレビューはとても大切だという認識を誰でも持っているにもかかわらず、実際の現場ではまともなコードレビューを行っていないのではないか?

Review Board is good software - O'Reilly Radar」を機械翻訳させると、下記のような文章になる。

しかし、良いコードレビュー(それらと同じくらい見つけにくい)は すばらしい効果を生むことができます。
あなたのコードを改良する方法を学ぶためにだれかをそれに慎重に目を通させて、1行ずつ提案をするより良いどんな道もありません。
私は慎重なコードレビューを使用するチームが、以下を報告するという結果に感動しました。
その作成は変化して、すべてがかなり清潔であって、アクセスしやすいので、コードでバグを修理するのは比較的簡単です。
かなりのコードレビューで、バグは、より浅くなります。


まだ発展途上のコードレビューツールReviewBoardには、たくさんのアイデアが詰まっているように思う。

| | コメント (3) | トラックバック (0)

2009/10/15

形式手法とHaskellについてメモ

いけがみさんの記事を読みながら、思ったことをメモ。
#まとまっていないので、あくまでも妄想です。

【元ネタ】
Inemuri nezumi diary(2009-02-05)

2009-06-23 - a-sanの日記
不正な状態遷移を見つけるアルゴリズム - a-sanの日記


僕が形式手法に興味を持った理由は、設計工程でモデリング作業の品質を上げることができて、更にテストケースを生成してくれるのではないか、という期待があったから。
でも、形式手法は確かに凄いのかもしれないが、言語もツールもオープンでないので使いづらい。
いけがみさんの言う通り、完璧な仕様を求めようとして、結局無駄な力を注いでいるのかもしれない。

モデリングは結局、事前条件と事後条件をつなげて一貫性と整合性が取れているか、そして状態遷移図が矛盾なく整合性が取れているか、という作業に落ち着くと思う。
関数型言語Haskellでも、形式手法でやりたかったことが同様にできるのではないか?

少なくとも、「不正な状態遷移を見つけるアルゴリズム - a-sanの日記」にあるHaskellのプログラムは、状態遷移図の整合性チェックができることを示しているように思う。

Haskellも僕にとって難しかった。
モナドや遅延評価だけでなく、関数型言語そのものの発想がないから。

でも、プログラムだからいくらでも試せる。
Howを考えるのではなく、Whatを考えるようにHaskellプログラムを書けばいい。
Haskellを書きながら、問題設定を考えながら、仕様を考えているのだ。
できれば、Haskellプログラムからテストケースを生成したい。


現在、考えている荒筋は下記の通りだ。

MSのPairwise法ツールPICTをエンジンに持つテストケース自動生成ツールMTGに状態遷移表を書けば、パラメータの組み合わせを生成してくれる。
その結果をTestLinkCnvMacroに貼り付けて、ちょっとだけフォーマットを整えれば、テストケースを出力できる。
そのテストケースをTestLinkへインポートすれば、TestLink上でテスト作業を一括管理できる。

つまり、質の良いテストケースを出力できれば、後はTestLinkでテスト作業をコントロールすればいい。
そのために、MTG→TestLinkCnvMacroのツールを使う。

MTG プロジェクト トップページ - SourceForge.JP

TestLinkCnvMacro - SourceForge.JP

後は、MTGへ吐き出すためのパラメータや制約条件がHaskellや形式手法、あるいはUMLの状態遷移図から作れればいい。
実際は、その部分が自動化できておらず、手作業になっている。

チケット駆動開発や構成管理に比べると、テスト工程の自動化はとても難しいが、どこまで可能か考えてみたい。

| | コメント (0) | トラックバック (0)

2009/10/12

テストケースの作り方

TestLinkを運用し始めて、改めてテストケースの作り方が重要と思うようになった。
TestLinkのマスタデータであるテストケースの品質がよくないと、TestLinkの効果が出ない。

はじめて学ぶソフトウェアのテスト技法」も「知識ゼロから学ぶ ソフトウェアテスト」もテストケースの作り方について初心者向けに書かれているようなのでメモ。

テストケースは基本は、パラメータの組み合わせだと思う。
パラメータの洗い出しは業務や設計が分かっていないとできないけれど、そこからテストケースを作成するプロセスはツールで自動化できないか探っている。

MicrosoftのPairwaise法(All-pairs法)ツールPICTを利用したテストケース自動生成ツールMTGに着目している理由も、テストケース作成のコストを下げて、品質を保持したいから。


又、テストの本で不思議なのは、ブロックの使い方について説明した本が見当たらないことだ。
TestLinkのブロック機能は、テスト工程のマネジメントを掘り下げる重要な概念だと思う。

Nakaさんにその不満をぶつけた所、「基本から学ぶテストプロセス管理―コンピュータシステムのテストを成功させるために」がいいと勧められたのでメモ。


| | コメント (0) | トラックバック (0)

2009/10/11

TortoiseHg0.8.3がリリースされた

TortoiseHg0.8.3がリリースされたのでメモ。

【ダウンロード先】
tortoisehg / stable / downloads ― bitbucket.org

TortoiseHgがどんどんバージョンアップしてバグFixされていくのは、ユーザとして嬉しい。

又、下記のようにTortoiseHgやMercurialのドキュメントも日本語化されたので、参考にしよう。

TortoiseHg-ja.chm

ヘルプにはTortoiseHgの使い方が説明されているので、非常に参考になる。
コミットや履歴表示、更新、タグはTortoiseSVNと同じ使い方でよいが、pull, push, mergeはちょっと使い勝手が違う。

hgbook-ja.zip

Mercurial本の日本語訳。
英語版は更に更新されているので、日本語訳は多少古い。
やはり分散バージョン管理は、SVNとは違う発想があるから、こういうガイドブックがあるのはありがたい。

TortoiseHgにはMercurial 1.3.1が埋め込まれているので、Windowsユーザにとって敷居は低い。
RedmineはMercuialとも相性がよく、TortoiseHgとWinMergeでWordやExcelの差分表示もできるし、p4Mergeを使えば強力なマージ機能も使える。

TortoiseHgでExcelの差分を見る方法: プログラマの思索

TortoiseHgとたわむれてみる - watawata日記

色々試してみたい。

| | コメント (0) | トラックバック (0)

TiDDとWFとScrumとLeanの違い

開発プロセスの違いについて良い記事があったのでメモ。

【元ネタ】
[Agile]WFとScrumとリーンの違い | Ryuzee.com

WFの弱点は「計画に依存しすぎているので、計画が間違っていたらリスクが高い」「プロジェクトの終了直前のデプロイまで、何の価値も実現できない」点にある。
実際の現場では、結合テストで火を噴いてビッグバン統合に失敗する症状に全てが言い尽くされていると思う。

このWFを繰り返し型開発へ変形した場合、確かにリスクは減るが、最大の弱点は「ボトルネックが発生してしまい、それを制御できない」点にある。
全ての作業の遅れが積もり積もって、バッファを食い潰すのだ。
TOCのクリティカルチェーンの話を思い起こさせる。

Scrumではイテレーション単位に、Plan・Build・Test・Reviewが並行で動き、リリース前にReviewとDeployが行われる。
つまり、実装とテストとペアプロが一緒になっていて、実装した機能は常時統合される。

Leanの絵では、もはやイテレーションの概念が1日の単位に収まってしまう意味だろう。
Leanはアジャイル開発の究極の理想形だが、実際はなかなか実現できないだろう。

では、TiDDはどうか?
下記のようなイメージだと思う。

僕の経験では、Planでイテレーション計画、もっとスパンの長いリリース計画を立てて、イテレーション単位で機能を小刻みにリリースしていく。

当初、イテレーションにアサインされたチケットも、開発中に延期されたり、追加されたり、優先順位が変わったりする時もあるだろう。
だから、実際の作業は、チケットに従って、Plan・Build・Test・Reviewが並行で動く。
このフェーズまでは、RedmineのようなBTSで管理すればいいだろう。

そして、システムテスト、受入テストはイテレーション後半に別途実施する。
理由は、単体テストや結合テストを終えて常時統合できたからといっても、品質に不安はあるからだ。
顧客の観点からテストして、要件が実現されているか、検証するフェーズが必要だ。
そのフェーズは、全ての機能がほぼ動作するレベルが最低条件であり、Plan・Build・Test・Reviewが並行で動く最中で、システムテストや受入テストは実施しづらいからだ。
このフェーズでTestLinkを使うと有効だと考える。

本当はLeanのような開発ができれば、イテレーションのない世界、つまり、バージョンが必要なくなる。
しかし、実際のSW開発は複雑怪奇で、そんな綺麗な開発はありえない。
現実と妥協すると、アジャイル開発はTiDDに落ち着くのではないかと思っている。

| | コメント (0) | トラックバック (0)

2009/10/10

プロジェクト管理インフラのふりかえり

プロジェクト管理インフラを使った履歴が書かれていたBlogがあったのでメモ。

【元ネタ】
僕はこんな開発インフラを使ってきた - watawata日記

以前は、VSS+VisualStudioの環境がいまいち慣れなくて、CVS+EclipseがJavaの開発環境で十分だと思っていた。
全てフリーだし。

そして、TracとSubversionが出た頃から、急激に開発環境が改善されつつあるように思う。
バージョン管理は、SVNからGitやMercurialへ発展している。
SVNでbranchの使い方が分かった。
そして、Mercurialを使いながら、可能性を秘めている分散バージョン管理について色々試している。

BTSは、Mantis、Tracもあるが、僕はRedmineが一番フィットしている。
Redmineで、リリース予定のバージョンを定めて、リリースできる単位でチケットを取捨選択するやり方がとてもアジャイルな感覚だから。
その方法から、クリティカルパスや工数管理などのプロジェクト管理につながる。

ビルドツールは、最初はContinium+Mavenを使っていたが、ビルドはしてくれてもデプロイは手作業なのでイマイチだった。
Mavenも設定が多くて、あまり楽になった印象がない。
Antでビルド&デプロイのスクリプトを自分で書き、Hudsonでビルド&デプロイさせたら、ワンクリックでリリースできるようになった。
しかも、HudsonはRedmine、SVNと相性がいいので、非常に便利。

そして、テスト仕様書もExcelからTestLinkに変えて、テストのマネジメントの奥深さを色々考えている。
テストと品質保証はアジャイル開発の最後の難問だから。

ここ2、3年でプロジェクト管理ツールが急激に改善されている。
マネジメント手法そのものが、従来のExcelや文書でやり取りするやり方からツールでリアルタイムに情報共有するやり方へ改良されて発展している。
それらのツールはまだ発展途上で、ツール同士の連携も未完成だが、ツールが開発プロセスへ与える影響は今後大きくなるだろうと思う。

| | コメント (2) | トラックバック (0)

ITILのプロセス関連図

とある勉強会で、クレーム処理でITILの話が出てきたので、整理するためにメモ。
下記のプロセス関連図でITILは全て説明できる。

ITIL:Information Technology Infrastructure Library - Wikipedia

ITILのプロセスは、PDCAサイクルで覚えればいい。
但し、起点がPlanの変更管理とCheckのインシデント管理の2パターンがある。

RFC(変更要求)が来た場合、変更管理プロセスで、要求を実現するための計画を作る。
つまり、CAB(変更諮問委員会)がステークホルダーを集めて、例えば、実装方法やリリース作業、そしてレビューやテスト方法、評価などの方針を議論して、決定する。

次に、変更管理で作られた計画に従ってリリース管理で、作業者が対応を行う。
実際は、ソースを修正してテストして、リリースする。

他方、顧客からクレームが来た場合、サポートデスクでインシデントとして受け付ける。
サポートデスクは普通は、女性の事務オペレータだったりする。
インシデント管理では、クレームが障害なのか要望なのか単なる質問なのか、を整理する。
障害の場合、暫定対応を連絡する時もある。

次に、障害だと判明したら、問題管理に送られて、BTSへ登録し、根本原因の究明を行う。
問題管理では、原因調査と是正対策を取るのが目的であり、すぐに直すわけではない。

ここでよく出る言葉は、SLA(Service Level Agreement)、いわゆるサービス品質維持契約。
顧客とSIerで、運用するシステムの品質を契約にする。
インシデント管理におけるクレーム情報、問題管理における障害情報から、SLAを満たしているか評価するのに使われる時が多い。

そして、問題管理で作られた是正対策をインプットとして、変更管理で実装計画を立てて、リリース管理で実装・リリースを行う流れになる。

構成管理は、変更管理・リリース管理・インシデント管理・問題管理を支えるインフラであり、CMDB(構成管理データベース)で一括管理されている。
CMDBには、CI(構成アイテム)とCIの作業履歴が登録されている。
SVNリポジトリをもっと汎用化したもののようにとらえればいいだろう。

この流れを詳細化すればITILの用語や説明は分かる。
だからITILはそれほど難しくない。

でも、ITILの発想は、抽象的なPMBOKよりもSW開発の現場で非常に役立つと思う。
チケット駆動開発でも、ITILのプロセスフローを参考にした。
SW開発の現場リーダーは、ITILの考えに触れておくと、RedmineやTestLinkで何ができて何が利点なのか、よく分かるだろうと思う。

昨今、情報処理試験でも情報セキュリティとサービスマネージャ(ITIL)の資格が重視されていると聞いた。
ITILファウンデーションの資格は、このプロセスを詳細化したぐらいで簡単に合格できる。

| | コメント (0) | トラックバック (0)

アジャイル開発の最後の弱点

テスト工程のマネジメントは、ソフトウェア開発の上流工程におけるプロジェクトマネジメントよりもはるかに難易度は高い。
TestLinkを使ってみると、Redmineの運用よりもはるかに難しい。
一つでもバグが出るたびにブロックが発生して、前進できないのだ。

ブロッキングバグをストッピングバグとも呼ぶ事実を今夜初めて知った。
テストでは、ブロッキングバグ修正の優先順位付けがとても重要。
ブロッキングバグが直れば、ブロックした大量のテストケースを再開できるからだ。

そして、テストにもクリティカルパスがある。
プロジェクト管理の基本はクリティカルパスの管理だから、テスト工程のそれを見つけて、意思決定を間違えないように管理するのが凄く大事。

テストと品質保証はアジャイル開発の最後の弱点。
チケット駆動開発によって、SW開発のタスク管理やワークフロー管理はスムーズになる。
しかし、テスト工程では、チケットとテストケースは概念が全く異なるため、チケット駆動開発の効果が出ない。

もう少し考えてみる。

| | コメント (0) | トラックバック (0)

2009/10/07

オープンソースのプロジェクト管理ツールの方が優れている理由

久しぶりにRedmineを使い始めた。
やっぱりTracよりもRedmineの方が楽しい。
バージョンにチケットをアサインして、チケットの取捨選択を考えたり、ソースコミット時にチケットNoを書いてリンクさせたり、チケットを消し込んでバージョンをリリースへ持っていくのが楽しい。

Redmineの方がチケット駆動というよりもバージョン駆動なので、その感覚がアジャイル開発とフィットしていてすごく好き。

TestLinkも最新バージョンを実験的に使い始めた。
テストケースやテスト結果にテスト予定日・実績工数・予定工数を入れると、TestLink上で集計する機能があるようだ。
まだまだ使い勝手は悪いけれど、TestLinkにテストの進捗管理機能ができてガントチャートを表示できるようになれれば、強力になるだろう。

MTGというPairwise法でテストケースを自動生成するExcelマクロを試している。

状態間の往復がある状態遷移のテストケースをPairwise法(All-pairs法)で生成する|多種類テストケース生成ツール MTG (Multi type Test case Generation tool)

上記ツールを使った発表は、SQIP2009でも聞いた。
「Pairwise法と制約表による制御パステストのテストケース自動生成」 講演資料PDF

設計プロセスとテストケース作成をつなげられないか、形式手法など色々探ったけれど、Pairwise法を使ったExcelマクロでテストケースを生成するのが一番簡単な気がしてきた。

MTGを使うと、下記のような使い方ができる。

PictMasterでデシジョンテーブルを作成する !?|多種類テストケース生成ツール MTG (Multi type Test case Generation tool)

PictMasterの結果表を使ってデシジョンテーブルを生成する|多種類テストケース生成ツール MTG (Multi type Test case Generation tool)

PictMasterで「通常」の条件網羅の制御パステストケースを生成する|多種類テストケース生成ツール MTG (Multi type Test case Generation tool)

状態間の往復がある状態遷移のテストケースをPairwise法(All-pairs法)で生成する|多種類テストケース生成ツール MTG (Multi type Test case Generation tool)


僕が興味を惹いたのは、状態遷移図から状態遷移表を起こして、状態遷移のテストケースを自動生成する手法だ。
このやり方を使えば、状態遷移図の整合性を設計プロセスで考えることもできるだろう。

MTGのエンジンには、MSのPairwise法ツールPICTがある。
だから、テストケースの制約条件も考慮できるので、テストケース生成としてはかなり強力だと思う。

MTGが生まれた発端が下記に書かれていた。

なぜオールペア法なのか?|多種類テストケース生成ツール MTG (Multi type Test case Generation tool)

最近思うのは、プロジェクト管理やテスト管理を楽にしてくれるツールやノウハウはどんどん公開して欲しいことだ。
それらのツールもノウハウもネット上には殆どなく、商用ツールだったり、特定の会社や非公開の勉強会でしかノウハウが得られない。
すると、せっかくのツールもノウハウも世間に普及せず、10年前と同じ手法でいつも失敗している。

Redmineも最初は機能もUIも未熟だったけれど、世界中の開発者がポテンシャルを感じて、たくさんのフィードバックをあげるうちに、Tracの開発速度を追い抜いて、優れたBTSになった。
TestLinkも日本語分科会の人達のおかげで、少しずつ普及し始めて、その可能性について色々議論している。

形式手法も優れた手法なのかもしれないが、ネット上で公開されておらず、オープンソースにもなっていないから、結局どう使っていいか分からない。

Googleの検索エンジンのおかげで、世界中の開発者のノウハウがつなげられれば、大衆の知恵のようになる。
今の時代は、一人の天才がツールを作るよりも、世界中の開発者がよってたかって作り上げる方が開発速度も品質も良くなるし、そしてその機能に込められたノウハウがベストプラクティスになる。

MTGにはすごくポテンシャルを感じているので、理解できたことを書いていきたい。

| | コメント (0) | トラックバック (0)

2009/10/06

モデル検査ツールLTSAのメモ

モデル検査ツールLTSAについてのメモ。
LTSAについてのリンク一覧は、garyoさんのはてぶから辿ればいい。

はてなブックマーク - Junk☆Bookmark臥龍 - LTSA

【他の参考資料】
LTSAによる組み込みソフトウエアのモデリングと動作検証
→これが一番分かりやすい。
 LTSAというツールが状態遷移図のモデリングに大変有効である理由と例が説明されている。
 特に組込み機器のように、デッドロックや並行性、セマフォなどを考慮する必要がある時に役立ちそう。

LTSA Tutorial ― Yamamoto Lab. Web Site
→LTSAのツールの使い方が説明されている。分かりやすい。

Concurrency スライド
→LTSAの英語本を大学の講義録として公開されている。読みやすい。

LTSA - Labelled Transition System Analyser
→LTSAの総本山

LTSA Eclipse - Imperial College London
→EclipseのLTSA用プラグイン

LTSA  FrontPage - PukiWiki

UMLモデリング・ツール「Enterprise Architect」からモデル検査ツール「LTSA」用のファイルを出力できるらしい。

モデル検査やAUTOSARなどに関連したツールが登場 ――第11回 組込みシステム開発技術展(ESEC)レポート(2)|Embedded and Electronics Engineers Network

eSOL - イーソル株式会社 : リサーチコンサルティング

形式手法(Formal Method)、モデル検査(Model Checking)の目的は、設計工程で仕様をモデル化して、その矛盾をなくす作業に使う。
過去に、野中さん、藤倉さん、佐原さんなどの講演をSEA関西で何度か聞いてきたから、雰囲気は分かるが、率直に言って、あまり役立つとは思っていなかった。
これらの手法は、仕様をモデル化するためにある種のプログラミング言語で実装するが、そのプログラムは動作しないし、実装プログラミング言語と同じぐらいの労力がかかる。
だから役立たないと思っていた。

でも、今の僕の課題として、設計工程の品質アップ、テスト設計の品質アップがある。
形式手法を使って、設計工程で状態遷移図のモデリング作業に使えるかもしれない。
形式手法で書いたモデルからJavaなどのソースを自動生成するよりも、テストケースを自動生成してくれる方が正直ありがたい。

形式手法は色んな種類があるけれど、LTSAはJavaで作られたGUIアプリがあり、状態遷移図を生成してくれるので、他の手法よりも分かりやすい。

システム設計の一番の肝は、状態遷移図だと思う。
業務は知っているがシステム化を知らないSEと、システム化できるSEの差は、状態遷移図でシステムを表現できる能力があるか否かだと思う。
フロー図やクラス図はあくまでもお絵かき。たくさんの漏れがある。
システム化する時に一番大事なのは、状態を見抜き、そのパターンを全て洗い出すことだ。
それが状態遷移図であり、デシジョンテーブルになる。
そしてそれが仕様になり、テストケースになる。


組込みSEならば、例えば、CDプレーヤーの状態遷移図は書けるだろうか?
情報処理試験に受かっているならば、缶ジュースの自動販売機の状態遷移図は書けるだろうか?
状態遷移図に出てくる状態は普通は、Cのグローバル変数として表現されるだろう。
だから、状態を扱うのは慎重でなければならない。

業務系SEならば、状態はDBにあるテーブルのフラグとして表現される。
画面遷移やトランザクションの推移によって、フラグの値が状態遷移図として表現される。

フラグの個数が増えるたびに、フラグの値が増えるたびに、状態遷移図はどんどん複雑になる。
フラグのビジネスルールは条件分岐で表現されるから、プログラムも複雑になっていく。

システム開発が難しいのは、状態遷移図が複雑になりやすく、状態爆発しやすいからだ。
状態が多いほど、テストケースも増えて、開発期間中に全てのフローを検証できないままリリースに至ってしまう。
だが、むしろもっと危険なのは、設計された状態遷移図で実装してみたら、たくさんの穴が見つかったという事態だろう。
特に組込系ならば、並列に走らせて特別なタイミングでデッドロックに至るバグなどは、手書きの状態遷移図では分かりえない。
オブジェクト指向やDOAも確かに役立つけれど、状態遷移図を補完するモデリング手法と捕らえた方が使いやすいと思う。

この10年、RailsやSeasar、Ajax、MapReduce、レコメンドエンジンなど、下流工程では多くの技術革新があった。
しかし、プロジェクト管理やモデリングに関しては、XPを代表とするアジャイル開発が多少あるぐらいで、10年前の技術と何ら変わっていないように思う。
その間、システム開発の大規模化、短納期化が進み、システム開発の難易度は10年前よりもはるかに上がっている。

おそらく今の日本では、人海戦術や組織力でこの流れに対抗しようとしているが、技術力を軽視していないだろうか?
プロジェクト管理やテスト管理を人海戦術による手作業からIT化したり、設計手法にDSLや形式手法を用いてソフトウェアでモデリングしていくなどの発想はないのだろうか?

ソフトウェア開発の諸問題はソフトウェアでしか解決できない範囲が広がっているのではないだろうか?

| | コメント (0) | トラックバック (0)

マインドマップのメモ

マインドマップのツールFreeMindの使い方が下記で公開されている。
キー操作だけで、枝葉を増やしたり消したり、移動できれば十分だろう。

FreeMind使おう会 | FreeMind使おう会参加者の作例集

又、FreeMindでマインドマップを活用する事例として、雑誌の企画、プレゼン資料、原稿執筆に使った話が下記に書かれている。
「脳ミソの中をGoogleで検索できないかな?」という疑問からマインドマップに至る発想が面白い。

FreeMind企画術

僕は、プレゼン資料や1日のタスクの洗い出し、WBSの洗い出し、リスクの洗い出しなどにマインドマップを使っている。
完璧に作るとか詳細に書くとかは気にせず、思いついたことを書き並べて整理すれば、荒筋が見えてくる。

又、マインドマップを手書きで書く時も多い。
DFDや状態遷移図、配置図、ライフサイクルをラフに書きたい時があるから。
また、講演やセミナーを聞くときは、ノートにマインドマップでラフに書くことも多い。
後で読み返すと、色々気付きがある。

マインドマップは、間違いを気にせずにとにかく書きまくること。
自然にコツが分かってくる。
僕は「人生に奇跡を起こすノート術―マインド・マップ放射思考」でマスターした。

他の人のマインドマップも参考になる。
今ではインターネット上にたくさん例があるから参考にすればいいと思う。

| | コメント (0) | トラックバック (0)

2009/10/04

FreeMind Ver0.9が使いやすくなっている

かどぐちさんから、FreeMind Ver0.9が使いやすくなっていると聞いたのでメモ。

【元ネタ】
Browse FreeMind Files on SourceForge.net

FreeMind Ver0.9.0beta12を試してみた! - ライフハックブログ Ko's Style

こたつストレッチ: FreeMind

下記の特徴があるようだ。

・UIが使いやすくなっている
・デザインが良くなった
・Flashで出力できる。Webサーバーへアップして簡単に公開可能。

Latexプラグインで数式も表示できるみたい。

FreeMind使おう会 | 日本人のためのFreeMindの使い方

上記には、日本語を使う日本人と英語を使う英米人の発想方法の違いが書かれていて面白い。
ロジックツリーで階層化・詳細化しながら発想を展開していくロジカルシンキングは、英米人の方が自然なのかもしれない。

| | コメント (2) | トラックバック (0)

TortoiseSVN から Redmineと連携する

TortoiseSVN から Redmineと連携するプラグインがあったのでメモ。

【元ネタ】
TortoiseSVN と Redmine の連携 Plugin - アジャイルプログラマの日常

Redmine - TortoiseSVN plugin to visualise the issue list in Commit windows - Redmine

gurtle - Project Hosting on Google Code

TortoiseSVN Redmine plugin 日本語版 - Redmine Users (japanese) | Google グループ

TortoiseSVNからBTSと連携する: プログラマの思索

Trac Explorerのように、チケット履歴が見れたり、コミットログにチケットNoを設定するだけでRedmineチケットと連携できたりするようだ。

| | コメント (0) | トラックバック (0)

プロジェクト管理ツールの目的はプロセスの透明化

開発抽象化レイヤ - The Joel on Software Translation Projectを読み直して、もう一度考えを書き直す。

【元ネタ】
開発抽象化レイヤ - The Joel on Software Translation Project

開発抽象化レイヤーを担う人: プログラマの思索


RedmineやTracによって、Excelからタスク管理やワークフローをIT化する。
昨今の高機能なBTSによって、ワークフローやプロセス管理を開発者は特に意識せずに開発できる。

TestLinkによって、Excelからテスト管理をIT化する。
管理者やテスト設計者は、膨大なテストケースの管理や複雑なテスト計画・集計作業から解放される。

SVN、Mercurial、Gitによって、ソースだけでなく、WordやExcelのドキュメントもバージョン管理する。更に、BTSと連携してソースやドキュメントをチケットに紐付ける。
開発者も設計者も、ソースやドキュメントの変更理由をチケットから類推できる。

これらのツールが目指すのは、プロセスを透明化することだ。
ジョエルの言う開発抽象化レイヤを狭義に捉えると、開発者がプロジェクト管理を意識しなくてもクリエイティブに開発できるようにすることだ。

作業者がツールを使いこなせば、ツールの機能に隠されたベストプラクティスによって、自然にプロセス管理されている。
プロセス管理でがんじがらめな開発になるのではなく、複雑な連携作業やワークフロー管理はツールに任せて、開発者はクリエイティブに開発できる。
管理者も、マネジメント情報を収集する作業から解放されて、経営者のようにツールから出力されたマネジメント情報を使って、高度な意思決定に注力できる。

ソフトウェア開発において、プロジェクト管理やテスト管理、品質管理の問題が急速に言われ始めたのは、プログラミングを中心とする下流工程でここ10年大幅な技術革新が行われたのに、プロジェクト管理の技術が旧態依然のままで、プログラミングの速度に追いついていないからだろう。

Excelでチマチマと手作業で管理する技術は、RailsやSeasarのようなWebプログラミングの速度にマッチしていない。
わずか10~20人月のプロジェクトでLOCが1万行を超え、テストケース数も1千を超える規模では、ツールでプロジェクト管理を補完しなければ、せっかくのプログラミング技術の生産性も落ちる。

ツールに必要な物は何か?
それは、常に最新の作業情報、成果物、そして仕様。

最新の作業情報を入力データとして、BTSによるチケット駆動開発がプロセスを透明化する。
最新の成果物を入力データとして、バージョン管理ツールが開発プロセスのインフラを提供し、BTSとソース管理が連携して、成果物と作業情報を連携してくれる。

最新の仕様を入力データとして、ツールが仕様と成果物が紐づく。
この部分のツールは、TestLinkの要件管理機能のように、まだ不十分。
でも、昨今のように短期間で開発するには、作業情報と成果物と仕様が密接に連携できるツールを必要としている。

| | コメント (0) | トラックバック (0)

【公開】SQIP2009講演資料「チケット駆動開発- BTSでExtreme Programmingを改善する-」

SQIP2009の講演資料が公開されたのでメモ。

【元ネタ】
日科技連 | ソフトウェア品質 | 第28回 ソフトウェア品質シンポジウム2009 講演資料

[TiDD] チケット駆動開発 - BTSでExtreme Programmingを改善する-: ソフトウェアさかば


「チケット駆動開発- BTSでExtreme Programmingを改善する-」 講演資料PDF は僕とさかばさんの共著の経験論文で、チケット駆動開発でアジャイル開発の諸問題を解決した試みの内容。
Blogで書き散らした内容とほぼ同じ。

他の興味深い講演資料だけ書いておく。

「スモークテスト自動化の効果とテスト自動化戦略」 講演資料PDF は、Seleniumを用いてTestLinkのUIをテスト自動化した発表。
Seleniumを使う場合のノウハウが書かれているので非常に興味深い。
Seleniumによるテスト自動化は、実際は運用がはるかに難しい。
理由は、WebのUIがコロコロ変更される速度にプログラミング速度が追いつかないからだ。
だから、上記の発表では、TestLinkのRCのバージョンがリリースされてUIが殆どFixされた状態から、Seleniumによるテスト自動化を試みている。
つまり、システムの仕様も品質もある程度落ち着いた段階で、回帰テストの自動化のためにSeleniumを使う戦略を採る。
この方法ならば、Seleniumによるテスト自動化の効果も大きいだろう。


「Pairwise法と制約表による制御パステストのテストケース自動生成」 講演資料PDF は、AllPair(Pairwise)法を使ってテストケースの自動生成を試みた発表。
MSのフリーのAllPair法ツールPICTをエンジンに持つExcelマクロを用いて、テストケースを自動生成する。
PICTで自動生成したテストケースは、仕様がある程度落ち着いた状態で、システムテストや受入テストのように、大量のデータパターンで業務フローを検証する時や回帰テストで効果があるように思う。


ハーフディ・チュートリアル1
「派生開発を制覇しなければ明日はない ―派生開発プロセス[XDDP]のすべて」講演資料PDF

清水吉男さんが提唱している派生開発プロセスXDDPを最初から最後まで解説している。
これ1枚あれば、詳細をほぼ把握できるだろう。

「無知見プロジェクトに対するXDDPの適用
- USDM、プロセス設計によるプロセス改善」 講演資料PDF

XDDPを未経験者の多いプロジェクトで試した事例。XDDPの実践例として参考になる。

| | コメント (0) | トラックバック (1)

2009/10/02

要件管理はテストの目的のために存在する

要件管理とテストの関連についてメモ。

【元ネタ】
Software Testing - Columns: VerificationとValidation

テスト管理のベスト・プラクティス

ソフトウェア開発のすべての規律はテストの規律と関連がありますが、その中でもテストと特に重要な関連を持つ規律がいくつか存在します。
* 要件管理
* 変更管理
* 構成管理
「要件管理」は、大部分のテスト作業に先行するもので、極めて多くのテストのモチベーション (動機付け) と検証のニーズを提供します。プロジェクトの個々の要件管理プロセスは、テスト管理のプロセスに大きな影響を及ぼす可能性があります。この関係をリレー競走に例えると、第 1 走者が要件管理で、渡されたバトンを受け取る次の走者がテスト管理です。
(中略)
「変更管理」は、ソフトウェア開発のすべての部分に影響しますが、追跡される変更のなかでテスト作業に最も関連が深いものは「欠陥」です。欠陥はしばしばテスト・チームと開発チームの間の主な意思疎通経路の役割を果たします。また、欠陥から引き出される集計とメトリックスは、多くの場合、品質の指標としても使用されます。
(中略)
テストにはどのビルドをいつテストするかの追跡が不可欠であるため、「構成管理」はテスト管理にとって重要です。構成管理では、ビルドに加えて、テスト管理がテストの実行のために追跡する環境も管理します。
(後略)

テストが変更管理に関係するのは、バグという変更要求が正しく実装されたか検証するプロセスとして必要だから。
テストが構成管理に関係するのは、どのバージョン、どのビルド番号のモジュールでテストしたのか、という観点が必要だから。

テストが要件管理と絡むのは、要件がテストの目的そのものだから。
テストにはV&Vという考え方がある。

Verification(検証)は、正しいプロセスで、仕様通りに動いているか、テストする。
Verificationは普通、コンポーネントとして単体テストや結合テストで行う。

Validation(妥当性)は、製品が意図された要求を達成しているか、テストする。
Validationは普通、システムテストや受入テストで行う。

要件管理が必要なのは、Validationのテストにあると言っていい。
システムに単にバグがなければ、品質がよいわけではない。
製品として魅力的でなければ、システムの価値は下がる。

要件を意識したら、テストの目的が明確になり、テストケースもその観点で詳細化されるだろう。
要件は受入テストのために存在するのだ。

せっかく苦労してシステムを作ったのに、次から次へと改善要望がやって来る場合、製品としてまだ成長途中か、あるいは、ユーザの欲求不満があるのかもしれない。
つまり、要件をきちんと管理できていなかったのが原因の一つなのかもしれない。

| | コメント (0) | トラックバック (0)

2009/10/01

PHPとRubyの開発環境

Windows上では、EclipseでPHPとRubyの開発環境を簡単に作れるのでメモ。
これでTestLinkやRedmineをデバッグして開発できる。

【元ネタ】
Eclipse PDT で TestLink のデバッグ環境を作ってみた - かおるんダイアリー

Rubyに手を出してみるため、Aptanaをインストールしてみる [E] el cuadro

Aptanaなら開発環境とクラウドの連携が超お手軽! (1/4) - @IT

MOONGIFT: ? PHP開発が変わる!PHP実行環境をクラウド提供「Aptana Studio」:オープンソースを毎日紹介

Aptana上で、Rubyのデバッグ・実行、Railsの開発も簡単に行える。
さすがにリファクタリングは難しいが。。

| | コメント (0) | トラックバック (0)

同期安定化プロセスのメモ

クスマノの本「ソフトウエア企業の競争戦略」をもう一度読み直した。
この本には、マイクロソフトの開発プロセスである同期安定化プロセスについて詳しく書かれている。
考えたことをメモ。

【元ネタ1】
Y2’s blog ? Blog Archive ? 本: マイクロソフト・シークレット(上)

次に開発プロセスです。開発プロセスについては、クスマノ氏が「同期安定化プロセス」と読んでいるマイクロソフトの手法についての説明です。
しかし、読み進めていると、実はこれがほぼScrumやXPなどのアジャイル開発プロセスが進めている方法と同一であることがわかります。
この本が出版されたのが1998年、アジャイルマニフェストが公開されたのが2001年とのことで、実はアジャイルマニフェストを作成した人々は同期安定化プロセスを参考にしたのではないかと疑います。

少し具体的にあげると、
・定期的なビルド -- アジャイルやスクラムでのDaily Buildやイテレーション
・開発工程の分割 -- スクラムのイテレーション
・プログラム管理者と開発チーム -- スクラムのスクラムマスターとチーム
・設計書より成果物を優先 -- アジャイルでも同じ
・見積もりは開発者に行わせる -- スクラムでも同じ
などです。


マイクロソフトが編み出した同期安定化プロセスとアジャイル開発の類似性は、知っている人には知られている。
曰く、夕方5時にデイリービルド。
曰く、プログラマはテスト担当者とペアになって作業する。
曰く、開発目標は定めるが、頻繁に変わる設計書よりも動く製品を優先する。

つまり、複数のサブチームの成果物をデイリービルドで「同期」を取り、その度にテストして「安定」を図るのが同期安定化プロセス。

アジャイル開発も同期安定化プロセスも、結合テストを早期に行っていると言うのが最大の特徴ではないか?

SW開発はいつも、多数のモジュールをバラバラに作った後にビッグバン統合を実施し、結合テストを行って、初めて重大な問題に気付く。
単にコンパイルエラーが見つかるだけでない。

インターフェイスが合わなかったのは、設計書に記載が無かったからだ。つまり、設計漏れ。
動かしてみて顧客に見せたら、違っていると言われた。つまり、要件漏れ。
実際にビルドしようとすると、ビルド環境の構築作業が間違っていたり、ライブラリのバージョンに相違があったり、テストデータが足りなかったりしていたからだ。つまり、ビルド作業漏れ。
そういう重大な問題は早期にキャッチしたい。

しかし、実際のSW開発では早期に結合テストを行うことができない。
特にWF型開発ではそうだ。
何故だろう?

| | コメント (0) | トラックバック (0)

« 2009年9月 | トップページ | 2009年11月 »