「tracpath（tracpath）」正式版がリリースしました。
株式会社オープングルーヴは、ソフトウェアエンジニアのためのアジャイルソフトウェア開発を実現する、 クラウド版バグ管理システム・バージョン管理システム「tracpath」をリリースしました。 ソフトウェア開発の現場にとって品質を高め、デスマーチを避けることは、これからのソフトウェア開発に必須のツールです。
tracpathは無料ではじめることができます。ぜひご利用ください。
さらに詳しい説明はこちらをクリック。
sugimotoです。
昨日のエントリでインストールしたTracですが、設定を日本語にしても日本語化されませんでした。。
0.12 からデフォルトでLocalizationに対応してるって聞いたのに。。
わざわざBabelをインストールしたし。
と思いながら、インストールマニュアルを読み直すと、書いていました。。
$ python ./setup.py compile_catalog -f
これですね。。
ちなみに easy_install ではだめみたいですね。
レポジトリからチェックアウトして、setup.py でインストールしなおしです。
> svn co http://svn.edgewall.org/repos/trac/trunk > cd trunk > python setup.py compile_catalog -f > python setup.py install > /etc/init.d/httpd reload
うまく日本語化されました。
様々な設定が煩わしくなってきた方、クラウド型バージョン管理のサイクロンなら登録1分ですぐお使い頂けますよ。
ちなみにサイクロンならこんな感じに見ることが出来ます。
■サイクロンプロジェクト概要ページ
いつまでも無料でお使い頂けるフリープランがあります。是非お試しください。
sugimotoです。
TracをLinuxにインストールする手順です。
今回は以下の構成でセットアップしています。
途中、エラーなど出て半日くらいかかりました。
今すぐ使いたい人は、Cikloneにサインアップして、今すぐ使いましょう。
インストールドキュメントには以下のパッケージが必要だと書いています。
それでは早速インストール
> yum install python
TracはPython 2.4以上で動作可能です。
CentOSでの最新バージョンは2.4.3でした。ちょっと古いがぎりぎりセーフですね。
> yum install sqlite
SQLite 3.3.6がインストールされました。
Python 2.4 の場合、SQLiteでTracを使うにはPySqliteが必要になります。
こちらのサイトからダウンロードします。
そして、PySqliteのページの要領でインストールします。
> wget http://pysqlite.googlecode.com/files/pysqlite-2.6.0.tar.gz > tar xzvf pysqlite-2.6.0.tar.gz > cd pysqlite-2.6.0 > python setup.py build_static install
以下のサイトから egg ファイルをダウンロードします。
> wget http://pypi.python.org/packages/2.4/s/setuptools/setuptools-0.6c11-py2.4.egg#md5=bd639f9b0eac4c42497034dec2ec0c2b
shellのように起動せよ。ということなので、起動すると、インストールできたようです。
> sh setuptools-0.6c11-py2.4.egg Processing setuptools-0.6c11-py2.4.egg creating /usr/lib/python2.4/site-packages/setuptools-0.6c11-py2.4.egg Extracting setuptools-0.6c11-py2.4.egg to /usr/lib/python2.4/site-packages Adding setuptools 0.6c11 to easy-install.pth file Installing easy_install script to /usr/bin Installing easy_install-2.4 script to /usr/bin Installed /usr/lib/python2.4/site-packages/setuptools-0.6c11-py2.4.egg Processing dependencies for setuptools==0.6c11 Finished processing dependencies for setuptools==0.6c11
コマンドが使えることを確認
> easy_install -h
GenshiとBabelはともに eash_install コマンドでインストールできます。
> easy_install Genshi Searching for Genshi Reading http://pypi.python.org/simple/Genshi/ Reading http://genshi.edgewall.org/ Reading http://genshi.edgewall.org/wiki/Download Best match: Genshi 0.6 Downloading http://ftp.edgewall.com/pub/genshi/Genshi-0.6-py2.4.egg Processing Genshi-0.6-py2.4.egg Moving Genshi-0.6-py2.4.egg to /usr/lib/python2.4/site-packages Adding Genshi 0.6 to easy-install.pth file
Genshi 0.6 がインストールできました。簡単です。
Babelも同じようにインストールします。
> easy_install Babel Searching for Babel Reading http://pypi.python.org/simple/Babel/ Reading http://babel.edgewall.org/ Reading http://babel.edgewall.org/wiki/Download Best match: Babel 0.9.5 Downloading http://ftp.edgewall.com/pub/babel/Babel-0.9.5-py2.4.egg Processing Babel-0.9.5-py2.4.egg creating /usr/lib/python2.4/site-packages/Babel-0.9.5-py2.4.egg Extracting Babel-0.9.5-py2.4.egg to /usr/lib/python2.4/site-packages Adding Babel 0.9.5 to easy-install.pth file Installing pybabel script to /usr/bin Installed /usr/lib/python2.4/site-packages/Babel-0.9.5-py2.4.egg Processing dependencies for Babel Finished processing dependencies for Babel
Babel 0.9.5 プロジェクトページからダウンロード出来るのと同じ、最新版です。
Tracには最近はやりのMercurialやGit用のプラグインもありますが、デフォルトのソース管理となるSubverionはインストールしておきましょう。
> yum install subversion
Subversion 1.4.2 がインストールされました。Tracの正式サポートは 1.5, 1.6 みたいですね。。
「1.4 でも動くはずだけどね。」みたいに書いてます。。がんばれ。
さて、いよいよ Trac のインストールです。
今回は最新が使いたいので、0.12 ベータをインストールします。
> easy_install Trac==0.12b1
バージョンは == で指定するんですね。なんとも独特な。
2010/05/14追記: Tracを多言語対応するにはインストール前に言語ファイルのコンパイルが必要です。Tracを日本語化する場合は翌日の日記=>「日本語化したTracをインストールする」の方法でインストールしてください。
Tracがインストールできたので、さっそくプロジェクトを作りましょう。
initenv コマンドを実行するとプロジェクト名など聞かれますので適宜入力します。
> mkdir -p /var/share/trac/projects/sandbox > trac-admin /var/share/trac/projects/sandbox initenv
うまくいったようです。
> ll /var/share/trac/projects/sandbox/ total 36 drwxr-xr-x 2 root root 4096 May 13 18:19 attachments drwxr-xr-x 2 root root 4096 May 13 18:19 conf drwxr-xr-x 2 root root 4096 May 13 18:19 db drwxr-xr-x 2 root root 4096 May 13 18:19 htdocs drwxr-xr-x 2 root root 4096 May 13 18:19 log drwxr-xr-x 2 root root 4096 May 13 18:19 plugins -rw-r--r-- 1 root root 98 May 13 18:19 README drwxr-xr-x 2 root root 4096 May 13 18:19 templates -rw-r--r-- 1 root root 27 May 13 18:19 VERSION
ちゃんとプロジェクトが出来てますね。
デプロイ用のコマンドでCGIなどのファイルを作成しておきます。
> trac-admin /usr/share/trac/projects/sandbox deploy /tmp/deploy > mv /tmp/deploy/* /usr/share/trac/. > rm -fR /tmp/deploy
Apache で使うつもりなので、permissionも変えておきましょう。
> chown -R apache:apache sandbox
インストールマニュアルにはfcgiかmod_wsgiを推奨すると書いてあるので、今回は mod_wsgi でTracを使うことにします。
mod_wsgi はyumではインストール出来ません。
もう少しなんですが、ちょっとめんどくさくなってきましたね。。
> wget http://modwsgi.googlecode.com/files/mod_wsgi-3.2.tar.gz > tar xzvf mod_wsgi-3.2.tar.gz > cd mod_wsgi-3.2 > ./configure checking for apxs2... no checking for apxs... no checking Apache version... ./configure: line 1704: apxs: command not found ./configure: line 1704: apxs: command not found ./configure: line 1705: apxs: command not found ./configure: line 1708: /: is a directory checking for python... /usr/bin/python ./configure: line 1877: apxs: command not found configure: creating ./config.status config.status: error: cannot find input file: Makefile.in
エラーです。httpd-devel のコマンドが必要みたいです。
しょうがないので、インストールしましょう。
> yum install httpd-devel > ./configure > make /usr/sbin/apxs -c -I/usr/include/python2.4 -DNDEBUG -D_GNU_SOURCE mod_wsgi.c -L/usr/lib -L/usr/lib/python2.4/config -lpython2.4 -lpthread -ldl -lutil -lm /usr/lib/apr-1/build/libtool --silent --mode=compile gcc -prefer-pic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -fno-strict-aliasing -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -pthread -I/usr/include/httpd -I/usr/include/apr-1 -I/usr/include/apr-1 -I/usr/include/python2.4 -DNDEBUG -D_GNU_SOURCE -c -o mod_wsgi.lo mod_wsgi.c && touch mod_wsgi.slo mod_wsgi.c:135:20: error: Python.h: No such file or directory mod_wsgi.c:138:2: error: #error Sorry, Python developer package does not appear to be installed. mod_wsgi.c:142:2: error: #error Sorry, mod_wsgi requires at least Python 2.3.0 for Python 2.X. mod_wsgi.c:150:2: error: #error Sorry, mod_wsgi requires that Python supporting thread.
またまたエラーです。
プロジェクトホームページに解説がありました。
通常のLinuxパッケージでインストールしたPythonにはヘッダーファイルが無いので
dev パッケージを入れなさいと言っています。
> yum install python-devel > ./configure > make > make install
今度はうまくいきました。
では Apacheに mod_wsgi をロードして、trac環境を作りましょう。
/etc/httpd/conf.d/trac.conf を以下のように作成します。
LoadModule wsgi_module modules/mod_wsgi.so
WSGIScriptAlias / /usr/share/trac/cgi-bin/trac.wsgi
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
やっとセットアップが終了、かなり大変でした。。
Apacheを起動して、確認します。
> /etc/init.d/httpd start
一応、Tracの画面が表示されました。
でも使う前に、まだやることがあるようです。。。
だんだん面倒になってきたあなたにはクラウド型バージョン管理のサイクロンがあります！サイクロンの画面イメージはこんな感じ。
■ サイクロンダッシュボード画面 
サイクロンにはいつまでも無料 でお使い頂けるフリープランもあります。是非1度お試しください。
ゴキブリを１匹見つけたらその１０倍は家に潜んでいると、誰かから聞いたことがありますが、それは本当なのでしょうか？
ソフトウェアのバグもそんなにあったら嫌だなあと最近つくづくと感じています。
そもそも、システム開発工程でバグを作りこまないようにすればいいのですが、必ずと言っていいほど作りこまれてしまいます。設計書の誤り、誤解や思い込み、錯覚あるいは検討もれなど、原因はたくさんありますが、どうやら人間の行動にはミスがつきまとうものだと理解した方がよさそうです。
設計者ならば、どれくらいバグが潜んでいるのか興味があると思いますが、信頼性予測のモデルによってソフトウェアの信頼性を数理的なモデルで計量化して予測する方法もあります。プログラム開発者が意図的にプログラム中にバグを埋め込んでおき、デバッグにより発見したバグのうち意図的に埋め込んだバグの発見率から全体のバグの数を推定するのです。
次のような式になります。（詳細はこちらを参照のこと）
（発見済み埋め込みバグ数）/（埋め込みバグ数）
＝（発見済み潜在バグ数）/（潜在バグ数）
ソフトウェア開発者の能力によりバグの作りこみ数も変わってくるような気もしますが、バグの収束を願う設計者の気持ちはひしひしと伝わってきます。
バグを見つけるためには効果的なテストが必要ですが、どんなテストをすれば重大なバグが素早く見つかるのでしょうか。一般的なテスト作業では、コンポーネントとして実装したプログラムが要求仕様とおりに動作することを単体テストで確認し、結合テストによりさらに大きなモジュール単位での動作を確認します。当然のことながら、どんなテストツールを使うか、どんな体制でテストチームがテストを進めるかが重要になってきます。テスト工程を管理するテストツールも沢山出ているので、うまく利用すれば自動テストや結果分析も効率化できると思います。
デバッグとは関係ありませんが、2つの似た絵があって右の絵と左の絵でどこが違うのか探すような、間違い探しのクイズを考えてみてください。答えを見れば、何だそんな所か、とわかるのですが、意外なところ、想定外のところに違いがあると案外と見つかりにくいものです。もちろん、得手、不得手はありますが、ちょっと見方を変えることでバグが見つかるということがあります。他の人の見方や意見を参考にするのも、新鮮な視点を持つという点で、効果的です。開発者は、失敗を繰り返しながら、テストの達人に成長していくものなのでしょう。
ある先輩が言っていた言葉を思い出します。
「バグを全部見つけるのは無理だが、事故再発防止により品質向上できる」
類似不良を出さないことが最低限必要なのだと理解しましたが、これはいつの時代も通用することだと思います。
バグ管理システムcikloneでは、チーム開発の進捗、wikiによる情報共有基盤を備えています。そのため、プロジェクトのチームメンバと情報交換をしながら、テストも進められます。バグ管理データベースで過去の類似バグも管理しているので、同じ失敗を繰り返さないようにできます。
無料版での利用が可能なので、皆さまも是非、御検討下さい。
cikloneは、チーム主導によるアジャイルソフトウェア開発を実現できる「ソフトウェアエンジニアのための開発プラットフォームを提供するクラウドサービス」です。この点で、管理者が進捗を管理するだけ、説明のためのWBSを作成するだけの、従来のプロジェクト管理システムとは全く異なっています。
アジャイルって何？という方もいらっしゃると思いますので、念のため、Wikipedeiaによると：
アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。
私達は、ソフトウェア開発に重要なキーワードは次の３つだと考えています。
ソフトウェア開発に重要な3つの要件を実現するために、cikloneは次のソリューションを提供しています。
cikloneを利用する事で、情報共有や課題管理を実現するシステム基盤が60秒であなたのチームに導入できます。そして、システムをあなたのチームに適用するための、ciklone導入・運用サポートが柔軟に対応します。
ciklone導入サポートで解決！
「ciklone導入サポート」を利用することで、これまでバージョン管理システムやバグ管理システム（BTS）を使ったことがないユーザに対してもスムーズに導入し、チームのため、エンドユーザのためのシステム開発が実現できます。
お客様は当サービスにより
さて、チーム主導での開発とは何でしょうか？
あなたのチームに、次の項目があてはまるかどうか、ちょっと考えてみて下さい。
もしも、上記項目のどれかに思いあたる点があれば、チーム開発の進め方、ルール、仕事のやり方に改善の余地があります。あなたのチームでも考えてみてはいかがでしょうか?
私達が理想とするのは、「エンドユーザ、管理者、開発者の情報格差を減少させ、必要な情報を必要な人に伝える」ことです。
正しい情報が伝えられて初めて、正しい答えを見つけることができます。
ciklone blogをご覧の皆さま、こんにちは！ 桜の花も散り始めていますね。
前回は、cikloneを使って、部門レベルにおいて課題、バグ情報の共有を実現したE社様の導入事例を紹介しましたが、「そもそもバグ管理には何が必要なの？」という基本的なことに戻って書いてみます。
Wikipediaによると
バグ管理システム（バグかんりシステム）とはプロジェクトのバグを登録し、修正状況を追跡するシステム。バグトラッキングシステム（Bug Tracking System：BTS）とも呼ぶ。バグ管理システムの多くは、Webサーバ上で動作し、Webブラウザ経由でアクセスできるようになっている。バグ管理システムはソフトウェアを開発する上での必須アイテムになりつつある。
さらに、バグ管理に必要な基本的な機能として、バグのライフサイクルのワークフローによる一元管理（バグの投稿〜完了までのバグ情報の管理）、バグの検索と履歴管理、バグ更新時のメール通知機能などが挙げられます。
私達は、バグ管理に必要な条件は次の5つだと考えました。
そこで、cikloneではバグ管理の条件を満たすバグデータベースに加えて、プロジェクトメンバーのタスク管理やバージョン管理（ソースコード管理）、コミュニケーション環境を備えることによって、Wikipediaによる定義以上の「協調・反復アプローチによるソフトウェア開発」を実現するのです。ここがとても重要なポイントだと思います。
cikloneでバグや課題のデータベースを作成すると、常に、「だれが、いつ、なにをする|しなければいけない」というタスク管理ができ、過去のプロジェクトにおいて発生した障害、ナレッジ情報を検索できます。でも、導入のためのバグデータベースを一から構築するのは大変そうだなあ、という不安をお持ちの皆さんには朗報です！
このようにして、一旦バグデータベースを作ってしまえば、過去のバグも簡単に全文検索できますし、過去のプロジェクト事例、対応事例などのノウハウも活用できるのです。
あともうひとつ重要な点は、cikloneにはプロジェクトの進捗と共にノウハウ・文書化をしていく仕掛けがあることなのです。この点については、後日にでもご紹介いたしましょう。
無料版での利用が可能なので、皆さまも是非、御検討下さい。
今回は、cikloneを使って、部門レベルにおいて課題、バグ情報の共有を実現したE社様の導入事例をご紹介いたします。
ciklone blogをご覧の皆さま、こんにちは！ 折角桜の花が咲き始めたのに、今日は冬のように寒いですね。
さて、ソフトウェア開発では、まずはじめに要求仕様にあったソフトウェアを実現するための設計をおこない、それをコンポーネントに細分化して実装します。階層化、モジュール化した各プログラムが要求仕様とおりに動作するかをテストし、最終的には結合テストを行って、より大きなモジュール単位での動作を確認していきます。システム開発をしているエンジニアの皆さんは、品質の良いソフトウェアをより早くお客様に提供するために、日々努力しているはずです。
私達は、ソフトウェア開発の品質管理をはじめる第一歩はバグ管理であると考え、cikloneで開発工程である、「プログラミング、変更・構成管理、テスト」の効率化を実現するためのサービスを提供しています。今回は、実際にcikloneを使ったソフトウェア開発についてご紹介いたしましょう。
システムテスト担当のＢ君がcikloneにログインすると、B君専用のダッシュボードが表示されます。この画面では、遅延したマイルストーン（期限付の予定）、プロジェクトの進捗状況が一目でわかります。
このような全体としてのプロジェクトの流れを把握し、いつまでに、なにを対応すべきかを把握した上で、Ｂ君は自分のプロジェクト詳細画面を表示し、自身の作業内容を確認します。
今日の作業を確認したB君は、
再試験に着手する前に、過去の同様なバグを探してみることにします。cikloneに標準で実装されている全文検索により「マクロ使用時のロジック誤り」に関するバグの事例を検索した結果、過去のプロジェクトで類似バグの報告があり、その時の対策状況がナレッジ情報として蓄積されていることがわかりました。
予定より３日も遅れているものの、システムテスト再開の前に、各コンポーネントについて、「マクロ使用時のロジック誤り」に加えて類似バグがないかどうかも確認しておくべきだ、とＢ君は判断しました。至急、各モジュールの確認をしてもらったところ、設計担当のD君から、モジュールβに類似のバグが見つかったので修正したという報告メールが届きました。
こんなことができるのも、cikloneがバグの発生から完了までのサイクルを一元管理しているからですね。バグの対応状況も自動で追跡しているので安心です。
いかがでしたでしょうか？
cikloneを使ったバグ管理では、さらに、製品、バージョン、担当者別にレポートを簡単に作成することができます。ソフトウェア開発過程で、バグを記録するだけでなく、再発防止に努める仕掛けがあることが重要なポイントだと考えています。
cikloneは無料版での利用が可能です。皆様も是非、御検討下さい。
ciklone blogをご覧の皆さま、こんにちは！
ホウレンソウという言葉を御存知ですか？ 仕事を円滑に進めていく上で「報告、連絡、相談」をすることが大事だということを部下に教えるために、「報・連・相」という言葉ができたようです。部下の教育のためにもきちんと理由を説明して、ホウレンソウの重要性を説明することが必要です。
ソフトウェアのプロジェクトでチーム開発を円滑に進めるコミュニケーションツールは何がよいのでしょうか?
今回は、cikloneのコミュニケーション環境を中心にご紹介したいと思います。
マニュアル作成担当のAさんがcikloneにログインすると、まず最初に、ダッシュボードが表示されます。この画面では、遅延したマイルストーン（期限付の予定）、プロジェクトの進捗状況が一目でわかります。
例えば、
このような全体としてのプロジェクトの流れを把握した上で、Aさんは自分のプロジェクトを表示し、そのプロジェクトの進捗状況をこんな具合に確認できるのです。
この作業内容を確認しながら、Aさんは、仕様書をもとにテスト計画を作成する、という今日の作業を進めるわけです。
Webブラウザでソフトウェア開発に関連する議事録、備忘録、メモを簡単に共有していますので、今日の作業に必要な仕様書もそこにあります。cikloneはプロジェクトの成果物やドキュメントについても、常に最新版の仕様書がWeb上にあるので、「古い仕様書を見ていて変更があったのに気付かず手戻り作業が発生する」、ということはなくなります。( ファイルのバージョン管理)
ところが、Aさんは、仕様書に重大な誤りを発見しました。現在テスト中のシステムの画面定義が仕様書での規定と異なっていたのです。この場合には、問題点を他のシステムテスト担当に連絡することができます。
これにより、システムテスト担当者にタスク（作業）を割当てることができますので、システムテスト担当者はcikloneにログインしたとき、自分のダッシュボードにタスクが割り当てられた理由と誤りを確認することが出来ます。
これらのコミュニケーションの環境こそ、効率的なソフトウェア開発のために重要だと私達は考えています。
皆さんのチームで是非、cikloneの導入を御検討下さい。
ciklone blogをご覧の皆さま、このところ寒いですね。暖かい春が待ち遠しいです。
さて、「デスマーチ」などと聞くと、死神がゾロゾロ歩いてくる情景が思い浮んできて恐～いですね。
例によって、wikipediaを見ると：
「ソフトウェア産業において、デスマーチとは、長時間の残業や徹夜・休日出勤の常態化といったプロジェクトメンバーに極端な負荷を強い、しかも成功の可能性が低いプロジェクト、そしてこれに参加させられている状況を主に指す。」
デスマーチになる原因として、与えられた開発期間、エンジニア数、予算やリリースなどが本来必要な量の半分以下、あるいは機能や性能などの要求が倍以上という条件が挙がっています。予算や設定納期などプロジェクト内部のメンバー以外の要因が多く絡むので、もはやプロジェクトメンバーだけの努力では対応できるはずがないのです。
私達は、過去の経験からプロジェクトを成功させる５つのルールを提案します。
cikloneのタスク管理で実現できます！
cikloneのバージョン管理で実現できます！
cikloneのタスク管理、バグ管理で実現できます！
cikloneのバグ管理で実現できます！
cikloneのコミュニケーション環境で実現できます！
というわけで、cikloneの機能では、厳しい条件で開発を効率的に行う仕掛けを備えています。
今回はタスク管理について、もう少し詳しくご紹介いたしましょう。
通常、プロジェクトの開始時には、プロジェクト計画を立て、予算とリソースを考えて、タスクという単位で詳細なスケジュールを作ります。cikloneが提供するタスク管理では、タスクごとにステータスを管理し、進捗をグラフィカルに表示できます。これにより、プロジェクト管理者やチームリーダはメンバーの進捗を管理できますし、各メンバーはチーム内での他のメンバーの進捗や作業状況まで把握できるのです。開発メンバーがお互いの状況を知ることで、協力して仕事に取り組むこともできますし、困った時に助けてもらうこともできます。これが、私達が理想とする「関係者全員での協調・反復アプローチによる開発」なのです。
cikloneのタスク管理は、コミュニケーション環境まで含めたツールである点でとても有効だと考えております。
