« 2010年2月 | トップページ | 2010年4月 »

2010年3月

2010/03/31

Redmine のsubtaskingを使った画面part2

Redmine本家にsubtaskingの説明があった。
更に、Redmine本家のデモサイトで、subtaskingを使ってチケットを利用できる!
気付いた事をメモ。

【元ネタ1】
Redmine - What's new in trunk: Subtasking - Redmine

Test CMS - Feature #16630: Create Pages Contoller - Redmine Demo

subtasking を使うには「Manage subtasks」のユーザ権限が必要らしい。
そして、子チケットの優先度、開始・終了日、進捗率、予定工数、実績工数を自動的にロールアップして親チケットへ反映してくれる。
つまり、子チケットの属性のUnionを自動計算した値を親チケットへ反映する。
この機能によって、ストーリーカードとタスクカードの関係を容易に表現できるようになる。

subtaskingの機能が素晴らしいのは、RailsらしくAjaxをフルに使ってユーザフレンドリーなUIになっている点。
例えば、ガントチャートはチケットの親子関係を階層構造で表示し、更に、MS Projectのガントチャートっぽのようなデザインで表示している。これなら、従来のマネージャにも違和感は無いだろう。

又、Redmine 本家のデモサイトにあるsubtaskingを使ったチケットは、Test CMS - Feature #16630: Create Pages Contoller - Redmine Demoにある。
この親チケットの画面を見ると、子チケットのトラッカーや進捗率、ステータスの属性も一覧表示してくれている。つまり、ストーリーカードに紐づくタスクカードの一覧を最新表示してくれるわけだから非常に便利。
更に素晴らしい点は、Subtasks 欄にある子チケットにフォーカスして右クリックすると、コンテキストメニューが表示されて、子チケットの属性変更や移動を選択できること。
この機能のおかげで、突発的な仕様変更や作業者の病欠などに対し、すぐに期間や担当者を変更できる。
MSProjectやExcelでは、突発的な要求に対してタスクの一括変更がやりにくかったから、非常に便利になる。

MSProject やExcelを使い込んだ場合、進捗管理システムをMSProjectやExcelで作りこんでいる気分になる。
肥大化した MSProjectやExcelほど扱いづらいものはない。

【元ネタ2】
Haru's blog: Redmine Code Review Plugin 0.3.0 リリース

Redmine Code Review Pluginに、プロジェクトメンバにレビューをアサインする機能が追加されている。
つまり、これは、レビューイがソースレビューを依頼したい時に、レビューアを指定する機能になる。
従って、コードレビューのワークフローをRedmineのチケットで一括管理できる。

コードレビューはReviewBoardのようなコードレビューに特化したWebシステムを使った方がいいかもと思っていたが、Redmine Code Review Pluginで十分な気がしてきた。

Redmineでソフトウェア開発の作業情報を一括管理すれば、いつでも好きなレポートを取得できる。
それによって、より速くより正確な意思決定が可能になる。

Redmineは、最終的にはソフトウェア開発のERP、PMBOKの言うPMIS(プロジェクトマネジメント情報システム)を目指しているのだ。

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

Redmineのsubtaskingを使った画面

HudsonプラグインなどRedmineプラグインを活発に開発されているHaru IidaさんのBlogで、Redmineのsubtasking機能について説明があったのでメモ。

【元ネタ】
Haru's blog: Redmine のsubtaskingを試す

Haru's blog: Redmineのsubtaskingを試す その2

(前略)
* 親の進捗は子で決まる
subtaskを持つ親チケットは編集画面を開いても期間や予定工数、進捗、優先度の入力ができなくなります。これらは子チケットの各値をマージしたものが表示されます。
* 状態は親子で連動しない
* ガントチャートにも親子関係が反映される
* チケット一覧にも親子関係が表示される
(後略)

上記の記事では、subtaskingの画面を紹介してくれているので分かりやすい。

subtasking機能は、チケットに親子関係を導入する。
この機能によって、ストーリーカードとタスクカードの関係をRedmineチケットに運用可能になる。

その場合、ストーリーカードにタスクカードの期間・工数・進捗・ステータスなどのチケットの属性が引き継がれるだろうと考えていたが、ステータスのみ反映していないらしい。
確かに、タスクカードのステータスの共通集合がストーリーカードのステータスであるという制約は、ステータスがトラッカーに依存するため、実装しにくいのだろう。

Redmineによるチケット駆動開発がアジャイル開発、そしてソフトウェア開発をどれだけ効率化してくれるか、色々試してみようと思う。

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

2010/03/30

バージョン管理ツールを使うとやる気が出る

「バージョン管理ツールを使うとやる気が出る」という文章に激しく同感。

【元ネタ】
論文を書くときにTeXを使う個人的な理由 - より良い環境を求めて

(前略)
それからバージョン管理ツールを使うとやる気が出る。
これはgitwebを使い出した効果で、履歴一覧で前回の変更からの経過時間が「1 hours」とか出る。
これが「5 hours」とかになってくるとやばいという気になってきて、とりあえず何でもいいからコミットする。そうすると、やる気はやり始めてから出るの法則で少しずつ進む。
「3 days ago」とかになってきたらもう「。」を「.」に変えるだけとか「である.」を消すとかそういう些細なことでも何かコミットしなきゃという気になってきて、そこから書き始めることができる。
(後略)

ソースだけでなくExcelやWordに書いた設計書もバージョン管理すべき。
更新履歴を見るだけで、更新しなきゃ!と思う。
又、自分のコミット履歴を見ると、ここまでやってきたんだ、と充実感を感じてモチベーションもアップする。

tortoiseSVN やTortoiseHgを使えば、ExcelやWordも差分表示できるので便利。
前回のリビジョンから何を変更したのか、どのように成長しているのか、を見るだけでも、品質向上につながる。

更に、 SVNにRedmineなどのITSを連携したい。
コミット時に「refs #12」のようにチケットNoも合わせてコミット。
そうすれば、チケットに書かれた作業に基づいてソースや設計書を修正した履歴が残る。

このやり方を応用すれば、チケットを要件一覧の要件や課題一覧の課題に見立てれば、どの要件に基づいてソースを直すのか、意識して修正できる。
この作業を積み重ねていけば、成果物にどんどん要件が反映されていくので、品質をアップできるはず。

Redmineのロードマップを見れば、何をまずしないといけないのか、が分かるから、いつもゴールや納期を意識できる。
Redmineの更新履歴画面を見ると、どれだけの要望を反映してきたのか、が分かるから、充実感を感じる。

入門Mercurial Linux/Windows対応」のあとがきにも「あ!構成管理って楽しいんだ!」というフレーズがある。
「問題の本質は、構成管理が面倒であることではなく、面倒なツールで構成管理をしていたことだったのです」と。

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

2010/03/27

Redmineのロゴ

Redmineのロゴが公開されていたのでメモ。

【元ネタ】
Redmine - Logo - Redmine

Redmine - Redmine Logo? - Redmine

http://github.com/edavis10/redmine_logo

「Redmineの公式ロゴはあるか?」という質問から102個ものメッセージがやり取りされて、有志がたくさんの種類のロゴを作ったみたい。
Wikiには、赤レンガの洞穴のようなアイコンが公式ロゴとして掲載されている。

今度から使ってみたらどうだろう?

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

TestLinkのアンチパターン

TestLinkでテスト管理をしてみた経験、他の人から聞いた話から、TestLinkを運用したけど使いこなせない症状にパターンがあるような気がした。
それらをアンチパターンとしてまとめてみた。

【元ネタ】
TestLinkがExcelのテスト仕様書よりも素晴らしい点

TestLinkを運用して気付いたことpart4~TestLinkの概念を再考

TestLinkを運用して気付いたことpart5~TestLinkのテストケースの概念

TestLinkを運用して気付いたことpart6~テスト工程のプロジェクト管理

TestLinkを運用して気付いたことpart7~要件カバレッジは難しい

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

TestLinkを運用して気付いたことpart9~後追いテスト

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

TiDDを実践して気づいたことpart4~TestLinkによるテスト戦略

TestLinkを受入テストで運用する方法

TestLinkのFAQ: プログラマの思索

TestLinkのベストプラクティス集: プログラマの思索

【1】乱発されたバグ

テストすればするほどバグが出る状況。
大量のテストケースをとにかく全部通そうと強引にテストを進めると、似たようなバグがどんどん出てくる。
納期が迫っていて、プレッシャーがあるとよく起こる。

TestLinkを使う場合、ブロックを上手に使うことが重要だ。
テストに失敗した場合、依存するテストケースにも同様のバグが紛れ込んでいるので、NGになる可能性が非常に高い。
バグを直さなければ、いくらテストしても工数の無駄だ。
だから、NGになったらブロックを使って、依存するテストケースは一旦テスト保留として飛ばす。
あるいは、テストしなくてもこれは同じブロッキングバグのせいでNGになると分かれば、みなしNGにしておく。
そして、ブロッキングバグを区別して、同種バグを判断し、みなしバグはテストしない方針でやるべき。

失敗したテストケースに依存するテストケースをテストしないようにすれば、バグが乱発されることはないし、着実にテストを進めることができるはず。

【2】放置されたバグ

バグが多発して放置された状況。
テストするほどバグが出て、ブロッキングバグは一つずつ検証して潰すものの、同種バグを検証し切れていない状況が多いだろう。

ブロッキングバグの原因は他のバグと関係している時が非常に多い。
つまり同種バグの分析ができていないのだ。

ブロッキングバグが出た場合、必ずバグの原因分析を行い、他の機能にも同様のバグが無いか、他のバグと同じ原因ではないか、根本的に分析すべきだ。
そうすれば、バグの真の原因は絞りきれて、一つのバグを潰せば複数のバグも直るというケースで同種バグを潰すことができる。

【3】モグラ叩きのバグ

発見したバグを潰したのに、同じような原因のバグが出たり、他のバグが出たりする状況。
いわゆるデグレも同様。
この状況が多発すると、いくらバグを直しても不安になるため、テスターも開発者もモチベーションが落ちる危険な状況。

原因はブロックを使っていないこと、同種バグを潰しきれていないこと、TestLinkのビルドで回帰テストを管理していないことにある。
ブロッキングバグを潰したら、ブロッキングバグに依存するブロックされたテストケースやみなしNGのテストケースのみ再検証する運用にすれば、検証範囲を絞りきれるので、確実にテストで潰せる。
あるいは、ブロッキングバグを潰したとしても、同種バグがないか、他の機能に影響がないか、バグの原因分析をきちんと行えば、確実にバグは減るはず。
あるいは、回帰テストのテスト結果をTestLinkのビルドで別管理にすれば、どのモジュールでバグが出たのか分かるから、どのソースの修正でバグを入れ込んだのか探りやすくなる。

結局、テストやバグ検証というワークフローがきちんと管理されていない点に根本的な問題があると思う。

【4】テストが終わらない

納期が迫っているのに、テストケースが多すぎて、リリース予定日までにテストが終わらない状況。
テスト戦略、テスト計画がきちんと考慮されていないと陥りやすい。
つまり、テストケース数と工数がアンマッチなのだ。

そもそもテスト工程は、実際に動くモジュールがなければテストできないから、どうしてもテスト開始日は遅れがちになりやすい。
又、単体テストだけでなく、結合テスト、システムテスト、受入テスト、負荷テスト、探索テストなどいろんな種類のテストをしなければ、品質を保証できたとは到底言えない。
すると、たった1個のシステムをリリースするために数千~数万ケースも消化しないといけないから、テスト戦略がなければ、未テストのままリリースしてしまう危険もある。

対策としては、優先順位の低いテストケースは後回しとし、機能単位に確実にテストでバグを潰していく戦略が基本だろうと思う。
つまり、今回の開発に無関係の機能のテストはみなしOKとしてテストはしないとか、プロダクトリスクの低いテストケースは製品ベータ版が出た後に後追いテストを使ったりして、テストケースそのものを間引く。
あるいは、五月雨テストを使って、仕様変更を開発できたらすぐにテストチームへ回し、検証してもらい、順次開発とテストを繰り返していく。

テスト計画を立ててテスト仕様書を作った時点で、テストケース数とテスターの人数から、どれくらいの期間がかかるのか、は見積ができるはず。
だから、限られた工数の中でどんな観点でテストするのか、どのテストを優先するか、どのように品質を高めていくか、というテスト戦略が重要になる。

【5】巨大なテスト計画

TestLinkのテスト計画が1個しかない状況。
TestLinkのテスト計画に全てのテストケースを放り込んだ場合に相当する。
すると、テスト計画に含まれるテストケース数は数千~数万になるため、1個のテスト計画を終わらせるのに数カ月もかかってしまうだろう。
そうすれば、結局未テストのままリリースする危険がある。

TestLinkはある意味Scrumのバックログ管理に似たような機能があるから、それを意識して使えば良い。
つまり、テスト仕様にテストケースをバックログのように貯めておき、テスト計画をスプリントと見なして、テスト仕様からテストケースをテスト計画へアサインし、順次テストしていくのがリスクが低いと考える。
つまり、プロダクトバックログから、次スプリントでリリースするストーリーカードを取捨選択して、1ヶ月間のサイクルで開発していくやり方と同じだ。

従って、テスト計画をせいぜい数百ケースに分割し、アジャイル開発のように順次テストしていく戦略が最も良いと思う。

【6】バージョンのないテスト

テスト結果が1パターンしか残していないので、どのビルドモジュール・納品モジュールでテストしたか、区別していない状況。
だから、テストでOkだったのに後でテストしたらNGだった、というように、デグレが起きる場合もある。

TestLinkの使い方が分からない、という人に多いと思う。

TestLinkではビルドという概念で、同一のテストケースに対するテスト結果を区別して管理できる。
従って、納品されたモジュール単位でビルドを変えてテスト結果を残せば、どのバージョンで発見したバグが次のバージョンで直されたのか、を区別できるから、デグレが起きにくくなる。

バグ修正の時にバグを入れ込んでしまう危険性が高い、という事実はソフトウェアテストの観点ではよく知られている。
だから、テスト結果をきちんと区別して管理するのは非常に重要なのだ。

【7】一塊のテストケース

テスト仕様書のフォーマットがシンプルすぎて、テストケースに事前条件や事後条件の区別がなく、テストケースとテスト結果欄しかない状況。
あるいは、テストケースが機能やテスト目的の単位で区別されていない状況。
すると、テスターがテストケースを理解しにくいので、テストの品質が落ちやすい。

テスト工程では大量のテスターが投入される場合が多いので、システムの仕様を知らないテスターが多い。
すると、テストケースの品質が悪ければ、本来存在するバグを見つけられなかったり、デグレが起きたりしやすい。

テストケースはユースケースのように、事前条件・ステップ・期待値の3つで分けて書くべき。
特に、ブロックを使いたい場合、事前条件を明確に詳しく書いておかないと、テスターはブロックしてよいのかどうか判断しにくい。
だから、TestLinkのテストケースの書式に合うようにテストケースを作りこめばいい。

又、TestLinkでは、テストスイートを使ってテストケースを分類するのも重要だ。
サブシステム、大中小の機能、テストの目的などのテストケースの属性は、テストスイートを使って階層化すれば、テスターはテスト範囲を理解しやすいし、ブロックする範囲に気づきやすい。

似たようなアンチパターンとしては「バージョンがテストスイートにある」「結合テストやシステムテストなどの工程がテストケースにある」などがある。
これらのアンチパターンは、バージョンや工程という概念とテストケースの対応付けができていない場合によく見られる。
バージョンや工程という概念が何を意味しているのか、を考えれば、TestLinkに落とせるはず。

まず、結合テストやシステムテストなどの工程は、TestLinkのテスト計画にアサインすべきだ。
理由は、各工程に属するテストケースの観点こそがテスト計画でありテスト戦略だからだ。
従って、結合テスト、システムテスト、負荷テスト、探索テスト、受入テストなどのようにテスト計画を順次実施していくやり方が最もスムーズに進むだろう。
ここで、例えば、結合テストに含まれるテストケース数が1千ケースを超えるぐらい多いならば、サブシステム単位の結合テストに分割して、「結合テストPh1」などのように結合テスト工程そのものを分割すると良いだろう。
そうすれば、テスト計画をイテレーションのようにアジャイルにテストできる。

次に、バージョンはある時点のビルドモジュールのスナップショット。
バージョンはTestLinkのテスト計画に対応付ける場合と、TestLinkのビルドに対応付ける場合の2パターンがある。
前者はバージョンをテスト計画に対応付けた場合、五月雨テスト、つまり、アジャイル開発そのものになる。
例えば、Ver1.0はショッピングシステムの会員機能、Ver2.0はショッピングシステムの商品機能、Ver3.0はショッピングシステムの注文機能などのように、バージョンアップするたびにテスト計画を実施するようにすればいい。

後者はバージョンをビルドに対応付けた場合、受入テストのスタイルになる。
例えば、発注者がSIから納品されたモジュールを納品バージョン単位にテスト結果を残す時に、一つのテスト計画に対し、テスト結果をビルドで管理すれば、前回発見したバグが今回のバージョンで直されているか、一つずつチェックすることができる。
つまり、バージョンは納品モジュールのビルド番号に対応付けることができる。

TestLinkのテスト計画、ビルド、テストスイートの構造にテスト仕様書を合わせれば、TestLinkのベストプラクティスを使えるから、テストがより効率的になるはず。

【8】テスト漏れ
全てのテストケースを通したのに、レビューでテスト漏れが発覚したり、リリース後にテスト漏れが原因で障害が発生した状況。
テスト漏れの原因は色々あるが、要件カバレッジの観点がないこと、TDDだけに頼っていてテスト戦略そのものがないことが多いのではなかろうか?

前者は、元々の要件や仕様を全てテストできていなかったことにある。
実際にテストケースと要件を紐付けながらテスト仕様書を作ってみると、要件をテストで全て網羅するのは非常に難しい。
何故なら、要件や仕様とテストケースの関係はN対Nになるため、複雑で、整合性を取るだけでも大変だからだ。

又、XPが生み出したテスト駆動開発は確かに優れたプラクティスだが、テストはそれだけではない。仕様を満たすためのテストだけでなく、ユーザの観点での受入テスト、バグを探す探索テスト、性能要件をチェックする負荷テストなど、テストにもいろんな種類がある。
それぞれの観点でテストして品質を高めていくには、どのテストを優先して、いつどの順番でテストしていくか、などのテスト戦略が重要になってくる。

【Excelの仕様書の弱点】

TestLinkのアンチパターンをまとめてみると、Excelの仕様書では限界があることに改めて気づく。
Excelのテスト仕様書の弱点は以下があげられると思う。

・イテレーションの概念がない。
・バージョンの概念がない。テスト結果の欄が一つだけだから。
・バグIDを記述する欄がない。
・ブロックする運用がない。
・要件管理IDを記述する欄がない。
・テストケースの依存関係を記述する欄がない。

これら弱点をカバーするために、テストケースの横に項目を追加していくと、テスト仕様書はどんどん複雑になっていく。
結局、Excelでテスト管理システムを作りこんでいるようなものだ。
肥大化したExcelファイルほど使い辛いものはない。

【まとめ】

TestLinkのアンチパターンから、テストにはプログラミングと違う構造があるのに気づく。
一つ目は、テストは回帰テストが多いことだ。
例えば、システムがバージョンアップする度に、過去のバージョンのテストケースを使い回したりする。
あるいは、仕様変更で対応したものの品質に不安な機能は、過去のテストケースを使い回して余分に回帰テストでデグレしていないことを検証してみる。

つまり、過去に作ったテストケースはその後の運用保守でも使う場合が多い。
又、本番稼動しているシステムの仕様をリバースエンジニアリングする場合に、過去に使用済みのテストケースがあれば、非常に役立つ。

だから、Scrumのバックログ管理のように、TestLinkのテスト仕様でテストケースをどんどん貯蔵して、必要な時にテスト計画へ割り当てる手法が編み出されたのだろう。
更に、XPの継続的インテグレーションのように、回帰テストを自動化できる機構があるとなお良いのだろう。

二つ目は、バグの原因分析が重要なこと
バグは魚の目のように、根元から直さないと、いつまで経ってもバグは残る。
更に厄介なのは、バグ修正する時に、別のバグを埋め込んでしまう危険性も高い点もある。
だから、バグが発生した原因を突き詰めて、バグの周辺にある他のバグ、あるいは同じ原因のバグを徹底的に潰すのが品質保証の要諦ではないか。

つまり、ブロッキングバグを見つけたら、その同種バグを徹底的にあぶり出すのが非常に重要なのだ。

TestLinkを使い倒すと、テスト管理や品質管理の色んなノウハウがあることに気づくだろう。

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

2010/03/24

TortoiseHgでSVNを使う方法

TortoiseHgでSVNを使う方法が公開されていたのでメモ。

【元ネタ1】
TortoiseHgでSVNリポジトリをチェックアウトできちゃった件 | endflow.net blog

TortoiseHg 1.0 - イントレ。

TortoiseHg 1.0 + hgsubversion で簡単にTortoiseHgからSVNを認識できるみたい。
この機能を使えば、SVNを意識せずにクローンしたり、PullやPushが簡単にできる。
git-svnと同じ感覚で使える。

他にhg-gitもある。

【元ネタ2】
Kiln が Git (や他の SCM)ではなく Mercurial をサポートする理由 - tcha.org

構成管理手段が作業手順を定義している ? tune web

入門Git ? tune web

分散バージョン管理の本質は何にあるのだろうか?
分散バージョン管理はSW開発に何をもたらして、どんな技術革新を行ったのか?

アジャイル開発、派生開発、ソフトウェア製品ファミリー開発のいずれも、高度な構成管理技術を要求する。
高度な構成管理のインフラがなければ、いくらアジャイルを唱えた所で、絵に描いた餅に過ぎない。
高度な構成管理のインフラがなければ、オリジナルの製品から移植したり、大幅な機能を追加したり、複数の似たような製品を短期間に作り出したりするのは、規模が大きくなるほどいずれ困難になる。

そして、MercurialやGitを導入すると、従来までのソフトウェア開発プロセスも大きく変わる。

ツールがプロセスを改善する。
ツールがソフトウェア開発のレベルを1段上に持ち上げてくれるのだ。

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

2010/03/21

JoelもMercurialを使っている

Joelは分散バージョン管理(DVCS)にMercurialを使っているらしい。

【元ネタ】
分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project

Subversion, Git, Redmine, Hudson -- 結局こうなった ? tune web

(前略)
分散バージョン管理で実際のところ一番重要なのは、「分散」という部分ではないのだ。
重要なのは、このシステムが「バージョン」ではなく「変更」で物事を捉えているということだ。
(中略)
Subversionユーザからこんな話を聞かされたことが何度あったかわからない。「コードをブランチしようと思って、それはうまくいったんだけど、マージする段になったら、もうまったくの悪夢で、すべての変更を1つひとつ手で再び当て直さなきゃならなかった。こんなこと2度とやるものかと誓って、ブランチの代わりにif文を使う新しい手法を開発したんだ」
時には彼らが自分の開発したトランク1つのやり方を誇りに思っていることさえある。自分の使っているバージョン管理ツールが本来果たすべき役割を果たさない問題を回避したのが美徳でもあるかのように。
分散バージョン管理では、マージは簡単で、うまく機能する。だから安定版ブランチと開発版ブランチを作ったり、あるいはデプロイ前にQA チームがテストするための長期間存続するブランチを作ったり、ちょっと新しいアイデアを試して具合を見るための短期的なブランチを作ったりすることができる。
これは見落としてしまうにはあまりに重要だ。私がここで文章を書くようになってからの10年間に起きた、ソフトウェア開発技術における最大の進歩かもしれない。
(後略)

CVSはバージョン管理の概念をもたらした。
Subversionはチェンジセットという概念をもたらした。
MercurialやGitは、自動マージのおかげで気軽にブランチを作ってパッチを当てたり、実験したり、安定版と開発版を使い分けるのが可能になった。
つまり、タスクブランチ、トピックブランチを楽に運用できるようになった。
これがどれだけの威力を持っているか、可能性を持っているか、まだ本当に分かってない。

|

パッケージから学ぶ4大分野の業務知識

ERPを勉強するために「パッケージから学ぶ4大分野の業務知識 (開発の現場セレクション)」を読んでみた。
感想をメモ。

【1】業務の裏に会計あり~ERPは会計帳票を出力するためにある

いわゆる基幹システムと呼ばれる大規模業務システムは、日々の業務データは最終的には会計システムへデータが送られる。
販売、製造、経費精算などの業務は、仕訳データを日次または月次でバッチ処理で作り、夜間バッチで会計システムへ送る。そして、月次ないし四半期次で会計帳票を出力する。
だから、業務システムをマスターするなら最終的には簿記の知識が必要になる。
業務が発生したら、必ず取引として記録されて、仕訳が発生し、それらは損益決算書や貸借対照表などの会計帳票の元ネタになる。

パッケージから学ぶ4大分野の業務知識 (開発の現場セレクション)」にあるフォースの教えには、「業務の裏に会計あり」というフォースとしてまとめられている。

【2】One Fact in One Palce

ERPは90年代のBPR(ビジネス・プロセス・リエンジニアリング)が発端になって、日々の業務をIT化して効率化する観点から生まれた。

ERPの本質は統合DBにある。
つまり、業務で使われるマスタを一つのDBに統一し、他のサブシステムと連携するような仕組みにする。
例えば、ユーザマスタ、権限マスタ、支社マスタなどは、販売システムや会計システムで別個に存在すると、データが分散してしまい、どれが最新のデータか分からなくなる。

「One Fact in One Palce」がフォースの教え。つまり、DOAが主張する「一つの事実は唯一つのDBに入れる」発想と同じなのだ。

【3】事件の裏に女性あり、業務の裏に帳票あり

業務システムの最終的なアウトプットは紙の帳票だ。
出力された帳票は、その業務データの証拠として残すためだったり、作業者へ指図したり管理するために作られる。
特に日本の会社は、帳票の細かなレイアウトやフォントまで指定してとてもうるさいので有名だが。

特に会計や個人情報に関する帳票は、保存期間やセキュリティが法律で定められているから注意した方がいい。
業務システムの変な仕様は、実は法律が発端だったりする。

「業務の裏に帳票あり」もフォースの教え。

【4】プッシュ型とプル型の業務連携

ERPのもう一つの特徴は、販売管理システムや製造管理システム、会計システムなど各種システムを連携して、必要な情報を連携できること。
連携方法にはプッシュ型、プル型の2種類がある。

プッシュ型は、連携元から連携先へ情報を展開すること。例えば、受注一覧画面にある受注明細のリンクを押下して、商品の詳細情報にリンクする機能があげられる。
プル型は逆に、連携先から連携元へデータを引っ張ってくること。例えば、発注画面から受注可能な伝票の一覧を表示する機能などがある。

プッシュ型は、ヘッダ+明細の形式でよく見られるので分かりやすい。
プル型は、本来のデータは何なのか、などを探る時に使われるだろう。

似たような機能として、ドリルダウンやロールアップもある。
大分類や大勘定科目のデータを詳細に展開していくのがドリルダウン。
明細データや小勘定科目のデータをまとめて導出していくのがロールアップ。

ERPではこの種の機能が使い勝手のよいUIに直結する。
しかし、機能は理解できても実際に実装するのは、検索処理の性能も絡むので難しい状況が多い。
ERPの開発では特に注意した方がいい。

【5】人事管理システムは人材管理を支援するシステム

パッケージから学ぶ4大分野の業務知識 (開発の現場セレクション)」で面白かったのは、人事管理システムの業務内容が書かれていたこと。
人事管理システムの目的は、社内の人材を資産として活用するのを支援すること、そして、個人情報保護法などの観点で個人情報を厳密に管理することだ。
前者は、特にIT企業のように人が資産になる業界では、とても重要な仕組みであり、それは営業支援システムに似たような仕組みになるという指摘が面白かった。

後者は、個人情報保護法のために、社員の家族構成や病歴などの個人データをどこまで管理すべきなのか、そして、退職した人が情報漏えいがないか確認するための監査証跡の仕組みが面白かった。
昨今の法律改正が業務システムの仕様に直結しているのだ。

パッケージから学ぶ4大分野の業務知識 (開発の現場セレクション)」はERPを理解するための観点で幅広く書かれていて、しかも昨今の事情も説明してくれているので分かりやすかった。

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

2010/03/20

派生開発を成功させるプロセス改善の技術と極意

清水吉男さんの「「派生開発」を成功させるプロセス改善の技術と極意」を読んだ。
気付いたことをメモ。

【1】是正保守と改良保守の違い
ソフトウェア保守 - Wikipediaの定義がJISに公開されている。

是正保守は普通の障害修正に近い。
改良保守は、既存の製品に新機能を追加していくこと。例えば、ケータイにカメラやワンセグ、お財布携帯を追加していくこと。

後者はどう考えても保守ではない。清水さんはこの保守を意識して区別している。
おそらく世の中のSW開発の殆どは派生開発である、という指摘は、組み込み製品だけではなく、大規模な業務システムほど同様だ。
だから、継ぎ接ぎだらけで、たくさんの人のパッチが入った複雑なシステムになりがち。
リファクタリングそのものも危険になるから保守性も下がるし、品質も下がる。

そしてこれら保守の特徴は、開発期間が短く見積もり工数が小さいことだ。
2週間とか1ヶ月で終わらせて、一人で担当することも少なくない。
だから、仕様を部分理解したに過ぎないのに、ソースを弄って、リリース後に品質の悪さが露呈する場合も多い。

派生開発は、このような問題に対し、ソフトウェア保守に特化した開発スタイル。
この開発スタイルはXDDPと言われる。

【2】要求の表現に注力する

清水さんの派生開発の手法で面白い点は、変更要求の表現に注力すること。
萩本さんが提唱する要求開発が、見えない要求を見出していく点に力を入れているのと対照的だ。

XDDPでは、変更要求に要求が発生した理由も添えて、要求を階層化する。
その階層では、変更要求が親階層、変更仕様が子階層に書かれる。
理由は、要求の本来の意図を探り出して、他の要求や仕様への影響を調べたいからだ。

変更要求は「before/after」で書く。
派生開発だから、既存の要求が何に変わるのか、を明確に書くためだ。
これによって、本来の意図がはっきりし、仕様を正確に書きやすくなる。
レビューアも指摘しやすい。

要求仕様書と機能仕様書は書き方が違う、という指摘も参考になる。
機能仕様書は「~の動作をする」「~の操作ができる」のように機能が主語。IT技術者にとって馴染み深い。
しかし、要求仕様書は「~の動作(操作)ができて欲しい」のようにアクターが主語。慣れないと書きづらい。

「派生開発」を成功させるプロセス改善の技術と極意」には特に書かれていないが、構成管理で重要な点は、機能仕様書はVerUpするが、要求仕様書はプロジェクト1回限りのものであること。
機能仕様書はプロジェクトが生きている間、システムが修正される度に更新されて版管理されるが、要求仕様書は修正が反映されたら、リリースされた要求としてお蔵入りとなる。
つまり、機能仕様書もソースと同じく構成管理の管理下におくべき成果物の一つなのだ。

【3】保守性や移植性などの品質要求も変更要求の一つ

機能仕様書と要求仕様書の違いの一つに、品質要求が要求仕様書に含まれる点がある。
「10年間のバージョンアップに耐えれるようにして欲しい」という保守性の要求や、「今後の新製品ファミリーへ展開できるようにモジュール化して欲しい」という移植性の要求も含まれる。

特に派生開発では、保守性や移植性は重要な品質要求になる。
実際の派生開発では、新機能を追加していくために、既存のソースをリファクタリングしないと機能追加できない時が多い。だから、保守性という品質が良くないと、たった2人日の修正工数を見積もったのに、実は1人月もかかってしまった時もよくある。

又、派生開発では、既存のモジュールを新製品ファミリーへ移植する時も多い。
その時、普通は、移植元のソースコードを取り出し、移植先のシステムに合うように手を加えてカスタマイズする時が多い。何故なら、移植先にそのまま組み込めばいい場合は稀で、インターフェイスを若干修正する必要があるからだ。
すると、移植元のモジュールがバージョンアップすると、移植先にも影響を及ぼす点に注意する必要がある。

「派生開発」を成功させるプロセス改善の技術と極意」には特に書かれていないが、構成管理の観点では、移植性を実現するには「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」に書かれているベンダブランチを使えばいいと思う。
つまり、移植元のソースをベンダブランチとして別管理し、trunkに組み込む時にベンダブランチをカスタマイズして取り込む手法を取れば、移植元のバージョンアップに対してもシステマティックに対応できると思う。

XDDPでは、これらの品質要求も開発に取り入れることができるのが強みの一つ。

【4】トレーサビリティマトリクス(TM)で漏れをチェックする

トレーサビリティマトリクスは、縦に変更要求や変更仕様、横に機能を描いたマトリクス。
修正する箇所をマトリクスの交差点にポイントし、その交差点に変更設計書をリンクさせる。
変更設計書はソースの実際の修正方法。
変更設計書は、実際のソースコードをリバースエンジニアリングして作る。
清水さんの方法では、C言語が多いようなので、PADや構造図が多いらしい。
この作業をスペックアウトと呼んでいるようだ。

TMの利点は、変更要求や仕様がどの機能に影響しているか、を特定しやすい点にある。
SW開発の要件定義や設計のような上流工程で重要なポイントは、漏れが無いこと。
漏れが発生すれば、後工程でそれを見つけるのは難しいからだ。

個人的には、TMは、TestLinkの要件カバレッジやテストケース同士の依存関係でも表現して欲しいと思う。
要件がどのテストケースに紐づいているのか、一覧することができれば、テスト仕様書のレビューにも使えるからだ。

【5】変更要求仕様書、トレーサビリティマトリクス、変更設計書の3点セットがあるからデザインレビューもやりやすい

XDDPでは、3点セットを成果物として必ず作る。
このおかげで、これら成果物がデザインレビューのための資料になりうる。
既存製品の開発を経験した人がレビューアになれば、これら成果物を見れば、修正作業の影響範囲やその方法、工数見積もできる。

「派生開発」を成功させるプロセス改善の技術と極意」で興味深い点は、その生産性だ。
XDDPでは100行/時間のペースでソース修正できるらしい。
但しこの計測方法にはからくりがあり、実際にソースに触ってから修正完了するまでの期間を指している。

XDDPによらない手法では、最初にソースに触って、デバッグしながら修正していくから、短い修正行数に対して、長い期間をかけて修正していることになる。
だから、1ヶ月でわずか100行しか修正していないというケースもありうる。

XDDPでは、いきなりソースに手を付けず、ソースからリバースエンジニアリングして設計する工程に時間をかけて、ソース修正する時は一気に行う。
つまり、設計工程で影響範囲を十分に見極めてから短時間にソースを修正するから、品質も良いのだろう。

構成管理の観点で重要な点は、派生開発は、trunkとは別のブランチで作業することで対応できることだ。
XDDPでは、ソースや機能仕様書を設計中にいじくることはしない。
しかし、やはりソースを触って実験したい時もある。
そんな場合は、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」にあるタスクブランチやトピックブランチのように、trunkからブランチを切って、そのブランチ上で派生開発の作業を行えば良いと思う。
そうすれば、trunkで開発中のソースや機能仕様書に影響を及ぼす危険はない。

【6】ソフトウェアプロダクトラインのような製品ファミリー開発も派生開発の一種

XDDPの応用の一つに、製品ファミリーへ展開するという五月雨開発の例がある。
例えば、既存の製品から複数の派生機種を作り出す場合だ。
iPodファミリーやMS Office製品のように、組み込み製品やパッケージ製品でよく見られる開発スタイルだ。
これはソフトウェアプロダクトラインと原理的に同じだ。

XDDPの特徴は、変更要求仕様書、トレーサビリティマトリクス、変更設計書の3点セットを作ってからソースを修正する点なので、共通部分の改修チームはまずそれらの設計書を書き起こす。
だから、後続の派生機種の開発チームは、改修チームが作った3点セットの設計書を見ながら、影響を受ける機能を洗い出して設計する作業を先行してできる。
そうでなければ、共通部分のソースが完成しないと派生機種の開発ができないから、その分納期がずれ込んでしまう。

つまり、この手法は移植する作業を含めた派生開発に相当する。
だから、構成管理の観点では、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」に書かれているベンダブランチを派生先の製品開発チームが使うと良いだろうと思う。

ソフトウェアプロダクトラインにXDDPの手法も取り入れれば、製品ファミリーの開発の生産性も向上するのではないかと思う。

【7】インクリメンタルなアジャイル開発も実は派生開発になっている

XDDPのもう一つの応用例が、インクリメンタル開発に派生開発のアイデアを持ち込む点。
この点は僕も理解できている。
というのも、アジャイル開発は実は並行開発の構造を持っているからだ。

実際、短期間にリリースしながら小刻みに機能拡張していく開発スタイルだから、イテレーションで実装したモジュールをリリースしたら、そのモジュールを保守しながら機能追加しなければならない。
だから、バグ修正と仕様変更を織り交ぜて開発していくから、きちんとしたプロセスを持っていなければ品質が劣化しやすい弱点がある。

しかし、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」にあるメインラインモデルという構成管理手法でリリースブランチとtrunkを使い分ける戦略を取れば、この問題は解決できると思っている。
理由は、リリースして本番環境で動くシステムはリリースブランチ、ガンガン機能改善していくソースはtrunkと使い分ければ、障害修正はリリースブランチ、機能追加はtrunkと作業を使い分けることができる。
これによって、システム改修の影響を分離でき、システムの品質を安定させることができるはず。

「派生開発」を成功させるプロセス改善の技術と極意」は多少くどいけれど、現場で鍛えられたノウハウだから、ツボにはまると非常に分かりやすいし役立つ。
個人的には、派生開発と構成管理の手法を絡めれば、もっとブラッシュアップできると考えている。

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

2010/03/18

ソフトウェアプロダクトラインと構成管理、ソフトウェアパターンの関係

ソフトウェアプロダクトライン(SPL)を分かりやすく解説された記事があった。
考えたことをメモ。

【元ネタ】
ZACKY's Software Engineering Laboratory: プロダクトラインとは(1)

ZACKY's Software Engineering Laboratory: 共通性と可変性,スコーピング

ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(1)

ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(2)

ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(3)

研究室|株式会社エクスモーション 組込みシステム開発を現場から支援する「実践型トータルコンサルティング」

Untitled - eXmotion 株式会社エクスモーション|組込みシステム開発を ...

SPLC 2008 概要紹介

【1】SPLC 2008 概要紹介で面白かったのは、SPLとAgileの関係。
SPLはドメイン(コア資産)開発、Agileはアプリケーション資産開発に向いている、という議論になったらしい。
これは理解しやすい。

SPLはコア資産をベースに製品ファミリーを次々に開発していくスタイルだから、ベースとなるドメイン開発が一番重要。
ドメイン開発はウォーターフォール型開発よりも反復型(イテレーティブ)開発の方が向いているだろう。
システム全体を薄く作りながら、品質やアーキテクチャを作りこんでいく。
製品の骨格となるフレームワークを作り込む開発スタイル。

逆にAgileは、スクラッチ・アンド・ビルドが得意。
例えば、RailsやSeasarのような優れたフレームワークをベースに、UIのように顧客の要求の変更が多い箇所をアプリケーション層に押し込めて作る。
Agile開発の基本は漸進型(インクリメンタル)開発。
小規模リリースをベースに、2~4週間の短いサイクルで、サブシステム単位あるいは機能単位に機能拡張していく。
フレームワーク層はいじらす、アプリケーション層をひたすか改造する開発スタイル。

反復型開発と漸進型開発を意識して使い分けてもいいかもしれない。

【2】SPLは構成管理と密接に関係する。
成功した一つの製品をベースに、複数の製品ファミリーを展開していくには、コア資産と製品特有の機能を区別してソース管理する必要がある。
実際、複数のコードラインを管理しなくてはならないし、コア資産の一つの変更は他の製品にも影響するからマージ作業も発生する。
つまり、高度な構成管理が必要になる。

SPLでは、フィーチャという機能あるいはコンポーネント単位に製品をばらし、フィーチャを組み合わせて製品ファミリーを増やす戦略を取る。
そして、それらのフィーチャを組み合わせて、製品ごとのビルドスクリプトによって、別々にビルドされる。

SPLの構成管理では、trunkがフィーチャの数だけ存在し、ビルドスクリプトによって、製品に必要なフィーチャをチェックアウトしてビルドすることになるだろう。
例えば、ビルド処理はHudsonのジョブを使い分ければいいだろう。

又、コア資産は「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」にあるベンダブランチで管理すればいいかもしれない。
製品ごとにコア資産であるフレームワークに手をいじる場合もあるから、厳格な構成管理手法を選択しておかないと、すぐに品質が劣化するだろうから。

【3】SPLはソフトウェアパターンとも密接に関係する。
ここで言うソフトウェアパターンは、デザインパターンよりも、コンポーネント間の依存関係のパターンを指している。
例えば、「リリース再利用等価原則」「共通閉鎖原則」「共通再利用原則」「非循環依存関係原則」「安定依存関係原則」「安定抽象原則」などだ。

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技」や「プログラマのためのJava設計ベストプラクティス」に詳しく書かれている。
これらのパターンを意識すれば、ソースコードや関数のもう一つ上の層であるコンポーネントを疎結合に作ることができるので、再利用しやすくなる。

又、SPLでは戦略的再利用という発想も生まれる。
コア資産とアプリケーション資産を分離する観点は、マーケットやビジネスモデルから決まる割合が大きいのだ。

これらの観点を見直すと、SPLはこれまでのソフトウェア工学の知識をすべて網羅した体系であるとも言える。
だから、中身はとても当たり前な部分も多いし、とても膨大になりやすいから、分かりにくい点もある。

SPLについては、開発プロセスではなく、構成管理やソフトウェアパターンの観点から追いかけてみようと思う。

|

2010/03/17

ソフトウェアプロダクトラインが組込み企業の技術力を左右する

チケット駆動開発でアジャイル開発を運用すると必ず並行開発が現れる。
並行開発、ソフトウェアプロダクトラインの関係について連想した事をメモ。

【元ネタ】
ソフトウェアプロダクトラインを考えるセミナーに参加 - Basic

CACM の特集記事:ソフトウェアプロダクトライン工学(1) - IT、アイスホッケーそしてヒップホップのある日常

衛星標準プロセス展開支援 成果報告

【1】Redmineでチケット駆動開発をアジャイル開発っぽく運用すると、必ず2個のコードラインを保守するようになり、自然に並行開発になる。
つまり、リリースした本番システムはリリースブランチ、裏で機能改善中のシステムはtrunkの2本を常時保守しなくてはならない。
特にアジャイル開発を実践すると、2~4週間のサイクルで小刻みにリリースしていく為、リリースしたコードラインと次のイテレーションのコードラインの2本を並行で作業しなくてはならない。
だから、イテレーション期間中に、リリースしたソースの障害修正と開発中のソースの機能追加の2つを常に同時並行せざるを得なくなる。
アジャイル開発の運用が難しい理由の一つが、この認識漏れにあると思う。

並行開発の難点は、2つのコードラインのタスク管理やマージ作業が大変な点にある。
チケット駆動開発では、それぞれのコードラインのタスクをチケットで別々に管理してリンクさせる事で、複雑な構成管理の作業漏れをなくすようにできる利点がある。
更に、MercruialやGitのような分散バージョン管理を使えば、マージ作業そのものをpull/pushで自動化できるため、手作業による漏れや失敗を無くせる。

従って、並行開発を成功させるには、チケット駆動開発と言う変更に強いタスク管理のインフラと、複雑な構成管理を楽にしてくれる分散バージョン管理が必須だと思う。

【2】この並行開発の考えをビジネスモデルへ更に発展させるとソフトウェアプロダクトライン(ソフトウェア製品系列:SPL)の概念へ行き着く。
SPLでは、コア資産をベースに次々に亜種となる製品を作り出していくのが特徴であり、利点でもある。
しかし、SPLはSW工学の範疇ではあるが、実際はビジネスモデルに密接に関係するため、そう簡単に導入するのは難しい。

SPLを並行開発の観点で見ると、コア資産というコードラインから次々にアプリケーション資産というブランチを分岐ないし派生させていく事になる。
派生開発の観点で見ると、一つの製品を常時保守しながら、コア資産をベースに、携帯にお財布ケータイやデジカメ機能を追加するなどの改良保守も含まれる。

【3】SPLの具体例はパッケージ製品や組込み製品があげられる。
例えば、MSのOffice製品、AppleのiPod/iPhone/iPadが成功例としてあげられるだろう。
Officeには、Personal/Professionalなどの製品ファミリーがあるし、AppleはMacOSXという優れたUnixOSを元に各モバイル製品のコアOSを作り出し、次々に売り出している。

他にノキアなど、北欧の企業にもSPLに強い会社が多い。

SPLに強いということは、コア資産であるOSなどのプラットフォームを自社で持っており、そのプラットフォームの品質やブランドが大きいことでもある。
だから、MSやAppleのように、自社で優れたOSを持っていると、SPLの利点を生かしやすい。

又、パッケージ製品やASPのように自社の製品やサービスを販売しているソフトウェア企業は、SPLを運用できれば、違う顧客にスピーディに亜種となる製品やサービスを提供できるようになる。

【4】SPLのもうひとつの特徴は、アーキテクチャを重視している点だ。
コア資産を抽出するためにアーキテクチャと言う観点を入れて、アーキテクチャも含めた機能を再利用できるようにする。

実践ソフトウェアアーキテクチャ」では、北欧の軍需企業が、空母のシステムから防空システムをプロダクトライン開発した例が載っている。
この例は、SPLを持つ組織はアーキテクチャを習得しているおかげで、新製品ファミリーを派生させて作れる仕組みを持っていることを示唆している。
アーキテクチャを重視すると、最終的にはSPLにたどりつく気がする。

アーキテクチャは製品ファミリーやビジネスモデルと密接に関係するのだ。

【5】ここでもう一つ注意すべき点は、韓国がSPLに熱心である点。
韓国の姜教哲という大学の先生がSPLの世界的権威の一人であるらしい。
最近の韓国の組込み企業が日本を押しのけて強いのは、この点も関係するのかもしれない。

逆に最近の日本の組込み企業が弱くなっているのは、製品系列とソフトウェアのプラットフォームの関係を整理できていないため、常に一から作りこむしかなく、時間もかかり品質も良くない点にあるのでないだろうか?

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

2010/03/15

TestLinkCnvMacroを活用しよう

テスト管理ツールTestLinkの補助ツールTestLinkCnvMacroの使い方の記事をメモ。

【元ネタ】
[Testlink]TestLinkCnvMacro を活用しよう! | バシャログ。

(引用開始)
実際の作業の流れ

まず、reqSpecシートにて、要件の落し込みを行いました。ユースケース一覧と画面遷移図から仕様を洗い出し、ガンガンとデータ行を作成。

次に、作成したreqSpecシートのデータをマクロでXMLエクスポート。生成されたXMLファイルをTestLinkでインポート。

インポートされた要件からテストケースを一括生成できますので、その機能を使って、テストケース生成。

生成したテストケースを、XMLエクスポート。caseToSheetを使って再度Excel側にインポートして、テストケースの編集。

テストケースが編集できたら、XMLエクスポート→Textlinkへインポートし、テスト計画へアサイン!

以上が今やっている作業の大まかな流れになります。まだまだ基本的な機能しか利用できていませんが、Testlinkの画面での入力とは比べ物にならない効率の良さです。
ぜひTestlinkの導入とセットでこのマクロをお試しください。
(引用終了)

基本的に上記のような使い方でいいと思う。
やはりテストケースの作り込みは、Excelでやった方が簡単。

但し、「要件からテストケースを生成する」点にちょっと引っ掛かかった。

TestLink では、要件からテストケースを1対1で作成してくれる。
しかし、実際のテスト仕様書では、要件とテストケースはN対Nになるのが普通だ。
何故なら、単体テスト、画面遷移の観点、データのデシジョンマトリックスの観点、探索的テストなど色んな観点でテストするからだ。

だから、実際のテスト仕様書ではテストケースに備考欄が「備考1」から「備考5」まであるので、そこに要件IDを振る運用が多いと思う。
これはTestLinkではテストケースの属性にあるキーワードに要件IDを振ることになる。

TestLinkCnvMacroでは、テストケースのキーワードに要件IDを振れば、TestLinkの要件に自動的に紐づけてくれるし、テストケースのキーワード属性にあるからテスト結果でキーワード別つまり要件別にテスト網羅性を集計してくれる。
また、TestLinkCnvMacroへテスト結果を取り込めば、要件ごとにテスト網羅性を一覧表示してくれるし、グラフ化もしてくれる。

RedmineやTestLinkで上記のような使い方をしてくると、プロジェクト管理とは、WBSやテストケースのように膨大な作業データをマスタとして作りこんで保守するのが仕事なのだと言う気がしてくる。
実際、チケットもテストケースも、開発規模によるが、あっという間に数千オーダーになるからだ。
だから、インプットとなるマスタデータはExcelなどローカルPCで作りこんでインポート後、Web上で作業しながらデータを更新して保守していくことになる。

TestLinkもVer1.9betaが出ているので、興味ある人はどんどん使って、コミュニティへフィードバックして欲しいと思う。

|

ついにRedmineのtrunkにSubtasking がコミットされた!

ついにRedmineのtrunkにSubtasking がコミットされたのでメモ。

【元ネタ】
Twitter / yusuke-kokubo: #redmine ついにtrunkにSubtaking がコミットされた!

Twitter / yusuke-kokubo: #redmine 1.0ではチケットの親子関係がサポートされます。

Redmine - Feature #443: Subtasking - Redmine

Redmine - リビジョン 3573 - Redmine

(下記引用開始)
Adds subtasking (#443) including:
* priority, start/due dates, progress, estimate, spent time roll-up to parent issues
* descendant issues tree displayed on the issue view with context menu support
* issue tree display on the gantt chart
* issue tree copy on project copy
* unlimited nesting
Defining subtasks requires the new permission 'Manage subtasks'.
Subtasks can not belong to a different project than the parent task.
Implementation is based on scoped nested sets for fast reads and updates.
(引用終了)

上記チケットのログを見ると、親チケットに紐づく子チケット全ての開始日・終了日・進捗率・見積工数・実績工数を親チケットへロールアップしてくれるようだ。
しかも、子チケットの階層は無限なので、いくらでも階層を深くすることができる。
プロジェクト階層の無制限、バージョンの継承と合わせて、Redmineに足りない機能はもうなくなったように思う。

従って、チケットの親子関係を通じて、ストーリーカードとタスクカードの関係の下記の制約を実現してくれることになる。

制約1・ストーリーカードの開始・終了日は、タスクカードの開始・終了日のUnionである
制約2・ストーリーカードのステータスは、タスクカードのステータスの共通集合である
制約3・ストーリーカードの工数は、タスクカードの工数の合計である

チケットの親子関係の機能は、バックログの管理ですごく重要だ。
この機能を使えば、改善要望などの要求をストーリーカード、その要求を実装する作業をタスクカードにアサインして別々に管理できるようになる。
更に、ストーリーカードとタスクカードのワークフローを変えて、別々のトラッカーで管理するといいだろう。

そうすれば、ストーリーカードは管理者や設計者、顧客を交えた課題管理会議(CCB、CAB)で方針を決定ないし承認するというワークフローで制御できる。
そして、タスクカードは従来のように、チケットの担当者とテスターが交互にペアプロのように作業すればいい。

又、上記の機能で素晴らしい点は、「ロールアップ」という機能だ。
情報処理技術者試験でも出るように多次元データベースの操作の一つであり、詳細に展開された属性を集約する操作を表す。
逆に、「ドリルダウン」は属性を詳細に展開する操作を表す。

つまり、子階層のチケットの属性である開始日・終了日・進捗率・見積工数・実績工数を上階層のチケットへ集約して表示するのがロールアップ。
逆に、上階層チケットの属性である開始日・終了日・進捗率・見積工数・実績工数を子階層のチケットへ展開して表示するのがドリルダウン。

普通の業務システムでは、特に売り上げ報告、損益計算書、貸借対照表などのようなビューに対し、大分類や大勘定科目をドリルダウンして、何故こんなに数値が大きいのか、その原因を探ることができる。
あるいは子分類や子勘定科目をロールアップして、プロジェクト単位や部門単位で集計した値を見て、売上を比較することもできる。

従来のシステム開発では、ドリルダウンやロールアップのロジックは検索ロジックが複雑なため、キー操作に処理が追いつかず、使い辛い弱点があった。
しかし、昨今のクライアントアプリの発展によって、ドリルダウンやロールアップのようなUIも軽快に操作できるようになった。
例えば、Ajaxでは、サーバーからクライアントのビュー用データをJSONで保持して、ローカル上で軽く操作できるロジックを実装できる。
そのような技術革新の状況を考えると、プロジェクト管理システムでも同様のUIを実装した方が使いやすいはず。

Redmineの上記の機能はまだ使っていないが、Ver1.0が楽しみになってきた。

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

2010/03/13

経産省が推進する日本版クラウドサービスJ-SaaS

あまり知られていない(?)と思うが、経産省が推進する日本版クラウドサービスJ-SaaSのチラシが何と新聞に入っていたのでメモ。

【元ネタ】
J-SaaS(ジェイ・サース)|トップページ

J-SaaSは、国が音頭を取って始めたクラウド上のSaaS。
主に中小企業向けの業務支援をSaaSとして展開している。
SaaSの機能には、財務会計・給与計算・社会保険・販売管理・プロジェクト管理など多種多様。
SaaS提供企業とタイアップしているようだ。

クラウドで提供するSaaSが難しいのは、従来の技術と異なるだけでなく、ビジネスモデルとしても違うからだと思う。
大企業がクラウドを使う場合、資金が豊富だからプライベートクラウドになるだろう。
しかし、SaaSの本来の良さは、中小企業のように自社でサーバーを持ち運用保守するほどの資金がないマーケットで威力を発揮するはず。
つまり、ニッチなマーケットになりやすい。
従って、きちんとしたビジネスモデルを築かなければ、いつまで経っても赤字のままになりやすいと思う。

とはいえ、中小SIにとって、クラウドを使って自分たちのビジネスモデルを確立する手法もある。
例えば、サーバー運用保守はクラウドのサービスを使って外注し、自分たちは優れたプログラミング力を看板に、生産性の高い受託開発を目指す手法もあると思う。
つまり、SIはデータセンターも含めたトータルソリューションではなく、本来のソフトウェア開発の技術力で勝負するビジネススタイル。

クラウドを巡る状況は、技術だけでなくビジネスモデルについても追いかけてみたい。

|

2010/03/09

ステートマシン図の注意点

ステートマシン図について良い記事があったのでメモ。

【元ネタ】
誤解しがちなモデリングの技:第3回:ステートマシン図(I) | 豆蔵ソフト工学ラボ

誤解しがちなモデリングの技:第4回:ステートマシン図 (II) | 豆蔵ソフト工学ラボ

上記の記事では、UML2.0になって色々拡張された機能について、使い方や良くない例をあげて説明しているので分かりやすい。

ステートマシン図は、UMLの各種の記法の中でも、システムに最も近い設計手法の一つだと思う。
ステートマシン図が書けたという事は、システムの動作を漏れなく矛盾無く整合性を取りながら遷移していることを意味している。
設計漏れやテスト漏れは、ステートマシン図を書いてみれば、すぐに分かるものだ。

特にテスト設計では、ステートマシン図の品質が直結する。
例えば、自動販売機システムの機能をテストする場合、「つり銭切れはどうなる?」というケースを思いつくだけでなく、「缶の取り出し口に、誰かが意地悪して不要な缶を置いているとどうなる?」などのイレギュラーなケースも思いつく。

UMLの各種記法は色んな状況で使い分ければいいだろう。

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

Redmineプラグイン開発

Redmineプラグイン開発の記事が公開されていたのでメモ。

【元ネタ】
Ruby Freaks Lounge:第34回 Redmineプラグイン開発(1)|gihyo.jp … 技術評論社

Redmineは最近急速に機能改善されて使いやすくなっている。
何よりもRailsなので、プラグインの開発も簡単。
この記事では、Redmineのプラグインの作成方法を解説してくれている。

メトリクスの概念の根底には「測定できなければ制御できない」という思想がある。
レコーディングダイエットと同じく、日々の作業を測定すれば、プロセス改善のヒントが生まれるはず。

チケット駆動開発を実践していれば、プロジェクト管理に必要な情報は全てDBにあるから、目的に応じて好きなSQLやロジックで集計すればいい。
開発者が進捗報告しなくても自動収集できる機能を生かせば、チケット駆動開発は強力な開発プロセスとして運用できる。
是非、プラグインがどんどん公開されればいいと思う。

|

2010/03/06

TortoiseHg1.0がついにリリース

TortoiseHg1.0がついにリリースされた。

【元ネタ】
TortoiseHg

Mercurial 1.5 が昨日リリースされたのがきっかけだが、TortoiseHgもついにメジャーバージョンアップされた。
TortoiseHgはUIも機能もどんどん良くなっている。
テキスト、ソースだけでなく、WordやExcel、PowerPointもTortoiseHgでバージョン管理している僕にとって、頻繁なバージョンアップは嬉しいけれど、ちょっと面倒かな(笑)

又、SubversionをMercurialクライアントでアクセスするツールhgsubversionも公開されている。
TorotiseHgでSVNリポジトリを扱えたらすごく楽だろうな、と思っているので、試してみたい。

hgsubversion Debian パッケージ - mercurial-ja | Google グループ

yuja / hgsubversion-deb / wiki / Home ― bitbucket.org

tortoisehg / stable / source — bitbucket.org

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

2010/03/05

astah* professional 6.1の要求図

astah* professional 6.1がリリースされた。
リリース内容で最も注目する機能が「要求図」。
アイデアをメモ。

【元ネタ】
astah* professional 6.1 リリースノート

チェンジビジョン、設計支援ツール「astah*」の新版をリリース--新たに要求図を追加 - builder by ZDNet Japan

要求追跡(要求工学:第9回)

モデリング言語 SysMLを概観する(1/2) - @IT MONOist


詳細は知らないが、要求図は、UMLを拡張したモデル技法SysMLの一部の機能らしい。
astah* professionalでは、Ver6.0の頃から、「要求」と「テストケース」のインスタンスを作ることができたが「要求図」はリリースされていなかった。
だから、「要求」と「テストケース」をどのように使うのか不明だった。

しかし、今回リリースされた機能である「要求図」によって、要求をダイアグラムで可視化できる。
そして、「要求」を「テストケース」や「ユースケース」「クラス」などに紐付ければ、要求からモデルやテストケースへトレーサビリティを実現できる。
すると、要件からモデル、そしてモデルから吐き出されたソース、更にはビルドされたモジュールまでのトレーサビリティを実現できるはず。

Redmine+Hudson+TestLinkを組み合わせたチケット駆動開発では、下記のトレーサビリティが実現出来ている。

TestLink要件
→TestLinkテストケース
→【Redmineチケット】
→SVNリビジョン
→Hudsonビルドモジュール

この時、TestLinkの要件やテストケースをCSV化し、astah* professional の「要求」や「テストケース」にインポートできれば、ユースケース図やクラス図などと紐付けることができるから、上流工程の設計モデルにもトレーサビリティを付与できる。
これは上流工程の成果物の品質向上に役立つはず。

何故なら、顧客の要求が設計モデルのどこに反映されているか、をチェックするのに、要求のトレーサビリティが使えるからだ。
実際の上流工程では、問題点←→要件←→仕様のトレーサビリティを実現するのは、N対Nで複雑な関係でとても面倒なため、要件漏れや設計漏れが頻発しやすいからだ。
つまり、設計モデルでの設計漏れに対し、要件カバレッジ機能を使って、漏れをチェックしたいのだ。

astah* professional以外のモデリングツールでは、UMLのダイアグラムを書くだけ、ER図が書けるだけで、要求管理や要求のトレーサビリティの概念を実現できていなかった。
だから、astah* professionalにはすごく可能性を感じている。

僕の興味としては、実装レベルに近いクラス図やシーケンス図よりも、RFPによるシステム提案や要件定義のような超上流工程で、astah* professionalの要求機能を使いたい。
イメージとしては、下記の使い方をやってみたい。

顧客からヒヤリングした要求を要件定義書としてまとめる

要件定義書の要件をastah* professionalの「要求」として一括インポート

astah* professional 上で、クラス図やユースケース図などのラフな概念モデルを書く。
それらの概念モデルに「要求」を紐づけて、要件漏れをチェックする

ファンクションポイント法を使って、システムの規模を概算で見積もり、工数見積に使う

作った概念モデルと要件定義書から、仕様へ詳細化していき、実装していく。
この過程でも、要件カバレッジ、仕様カバレッジを使って、要件漏れや仕様漏れをなくす。


チケット駆動開発によって、下流工程の成果物の品質は向上できている。
最後の課題である要件定義や設計などの上流工程の成果物の品質向上に、要求のトレーサビリティの概念を導入できないか、試してみたい。

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

« 2010年2月 | トップページ | 2010年4月 »