« 2009年8月 | トップページ | 2009年10月 »

2009年9月

2009/09/29

もう一つのテスト管理ツールRTH

TestLinkに似たもう一つのオープンソースのテスト管理ツールRTHを見つけたのでメモ。

RTH - Requirements and Testing Hub | Get RTH - Requirements and Testing Hub at SourceForge.net

Feature list ? RTH Blog

RTH Demo / Live System ? RTH Blog

RTH - Requirements and Testing Hub

デモサイトでいくつかの画面を触ってみた。
TestLinkよりも機能は少なく、デザインもシンプル。
しかし、テスト管理だけでなく要件管理もデフォルトで付属しているのが目を引いた。

テスト管理ツールもBTSぐらい普及して欲しいと思う。

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

2009/09/28

TestLink・BTS・SVN・Hudsonの関連構造

TestLinkのポテンシャルについて考えたことをメモ。

【元ネタ】
要件とテストを関連付ける「テスト管理ツール」---目次 - 要件とテストを関連付ける「テスト管理ツール」:ITpro

第1回 テスト管理ツール:表計算ソフトの限界超える - 要件とテストを関連付ける「テスト管理ツール」:ITpro

第2回 テスト管理ツール:要件とのひも付けがカギ - 要件とテストを関連付ける「テスト管理ツール」:ITpro

第3回 テスト管理ツール:管理者支援型か開発者支援型か - 要件とテストを関連付ける「テスト管理ツール」:ITpro

第4回 テスト管理ツール:導入時の二つの課題 - 要件とテストを関連付ける「テスト管理ツール」:ITpro

【1】TestLinkを使う人達は主に、発注側や品質保証部門。
TestLinkを使う対象は、結合テスト以降、特に受入テストで使う。

TestLinkはテストの計画・記録・集計の為にある。
テストの自動化に直接役立つわけではない。
TestLinkは、テストケースそのものがプロジェクトの資産になる状況、つまり、結合テスト以降、特に受入テストで大きな威力を発揮する。

だから、TestLinkを使う状況は、発注側が受託したシステムの受入テストだったり、品質保証部門が開発部隊が作ったパッケージ製品の受入テストだったりする。

上記のようなTestLinkの特徴を上手に用いれば、XPのプラクティスであるユーザテストで使って、効率をあげることができる。

【2】TestLinkの要件カバレッジ機能を要件管理に使う。

Software Testing - Columns: テストカバレッジによれば、「仕様書の要件をどれだけテストしたか、という指標は、仕様カバレッジや要件カバレッジと呼ばれます。」

TestLinkの要件解析画面は、要件から紐付けたれたテストケース一覧を出力できる。
従って、この画面では要件カバレッジを見ることができる。

TestLinkCnvMacroを使うと、テストケースのキーワードに要件管理IDを紐付けることで、TestLinkのテスト結果画面で、キーワード別のテストの状態を集計してくれる。
従って、この画面ではテストカバレッジ、つまり、要件が何%までテストで検証されたか、を見ることができる。

たったこれだけの単純な機能だが、凄いポテンシャルを感じている。
その理由は、下記のようなトレーサビリティを実現できるからだ。

現在、BTSチケット・SVNリビジョン・Hudsonビルド番号は、各々のツールで相互リンクが実現されている。
つまり、BTSチケットからビルドモジュール、あるいは逆にビルドモジュールからBTSチケットへ追跡できる。
従って、「このバージョンのモジュールに、あのバグ修正は反映されているか?」という疑問に回答できるインフラが既にある。

更にTestLinkのテストケースを経由して、要件まで遡れれば、「このバージョンのモジュールで実現された要件は何か?」を探すことができる。
あるいは、「ユーザの要望で仕様変更に対応する場合、要件に紐づくテストケースや機能、チケットから、影響範囲は大体これぐらいになる」という作業も機械的にできる。

しかし、TestLinkの要件管理機能は1階層のCSV形式でしか登録できない。
本来は、要件とBTSチケットを相互リンクさせたり、要件と機能のトレーサビリティマトリクスを表示したり、テストケースから紐付けられた要件の一覧(つまりトレーサビリティツリーみたいなもの)を表示したい。

市販の要件管理ツールやテスト管理ツールは多々あるが、ツール同士の関連がない。
現場で欲しいのは、プロジェクト全体の成果物を相互リンクしてトレーサビリティを実現してくれるプロジェクト管理サーバーなのだ。


TestLinkはPHPでオープンソースで作られているから、誰でも手を加えることができる。
誰か大幅に改造してくれないだろうか?

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

PICTで出力したテストケースをTestLinkへ取り込む

組み合わせテストケース自動生成ツールPICTを使って、TestLinkにテストケースを取り込めたのでメモ。


本当は、garyoさんやshimauchiさんが行ったallpair.exeを使おうとしたが、PICTの方が多機能。
PICTでは、制約条件を考慮できるし、以前生成した組合せテスト結果を再利用して他の組合せを追加できる機能もあるから。

AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb - Rubyの魔神 - はてな?Rubyグループ

TestLinkメモ(2) - 科学と非科学の迷宮

TestLinkメモ - 科学と非科学の迷宮


【元ネタ】
オールペア法テストケース作成ツール(PICT)と TestLink の連携 - hokorobiの日記

組み合わせテストをオールペア法でスピーディに!:第2回 PICTの基本的な使い方|gihyo.jp … 技術評論社

pict : tech.kayac.com - KAYAC engineers' blog

TestLinkCnvMacro - TestLinkTools - SourceForge.JP

【手順】
1. PICTのインプットファイルを作る。

参考:組み合わせテストをオールペア法でスピーディに!:第2回 PICTの基本的な使い方|gihyo.jp … 技術評論社

例:input.txt
OS種別: Windows Vista | Windows XP | Windows 2000, Linux, Mac OS X
HD容量: 250GB, 500GB, 750GB
HDインターフェース: USB2.0, IEEE1394, eSATA

2.PICTで生成する。
pict input.txt > output.txt

例:output.txt
OS種別 HD容量 HDインターフェース
Linux 750GB USB2.0
Mac OS X 250GB eSATA
Windows Vista 500GB USB2.0
Mac OS X 750GB IEEE1394
Windows XP 250GB IEEE1394
Linux 500GB eSATA
Mac OS X 250GB USB2.0
Windows 2000 750GB eSATA
Linux 250GB IEEE1394
Mac OS X 500GB IEEE1394

3.TestLinkCnvMacroのSuiteDTへ上記の組合せを貼り付ける。
 期待値、テストスイート等も記載して、テストケースらしく整える。
 最後に、XMLを出力する。

4.TestLinkへXMLをインポートすればOK。

PICTの結果さえできれば、TestLinkへの取り込みはすぐに終わる。

PICTを使う場面は、Webシステムならば、システムテストや受入テストで、本番用データのデータパターンと業務フローに従ってテストする時だ。
あるいは、組込み製品やパッケージ製品ならば、OSやハード、ブラウザ等の複数の環境で最後の受入テストをする時だろう。

本番リリース前のテストでは、ユーザに近いレベルのテストが多く、普通は単体テストで見つかるようなバグは無いのが普通。
だが、実際の本番データを使うと、予期していなかったデータが原因でシステムが正常動作しない時はままある。

そんな時、PICTを使って、データパターンを機械的に生成できるのは工数削減に役立つ。
と言うのも、本番リリース前のテストでは、テストデータを用意して、どのテストケースでどのテストデータを使うか、というテスト設計に一番工数がかかるからだ。
もはや仕様が分からなければ、テストケースもテストデータも作れない。

PICTやTestLink、TestLinkCnvMacroを使い始めて分かった事がある。
それは、テスト工程では、仕様がはっきりと分かっていて、仕様の直交性が保障されていなければ、テストしても工数の無駄ということ。

直交表やAllPair法を使うには、テストするパラメータとそのデシジョンテーブルが必要だ。
そのためには、デシジョンテーブルと同値であるシステムの状態遷移図が作れていなければならない。
しかし、設計が曖昧だと、システムの状態遷移図すら設計者が詰め切れていない場合もある。

ツールによって、単純作業は効率化できる。
しかし、ツールで使う入力データ、仕様というマスタデータの質が悪ければ、PICTやTestLinkをいくら使いこなしても無意味なのだ。


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

2009/09/26

LaTexのセットアップ

10数年ぶりにLatexを書いて、PDF出力できたので、セットアップ方法をメモ。

【元ネタ】
WindowsにLaTeXをインストールしてPDFファイルを作る手順

Der Leiermann | 久し振りのTeX

Latexは科学技術系の論文を書く研究者でよく使われる。
数式や多言語に対応している。
本の出版でも、目次や索引、文献データベースが簡単に作れるのでお勧め。

上記の結城さんのHPであっさりとセットアップできた。
コマンドは、下記2個を実行するだけで、入力物sample.texからsample.pdfが出力される。

platex sample.tex
dvipdfmx sample.dvi

世の中すごく便利になったね。

10数年ぶりに、奥村さんの美文書LaTex入門の本「[改訂第4版] LaTeX2ε美文書作成入門」も買い直した。
奥村さんの美文書LaTex入門の本は、初版は1991年に出てから、タイトルを変えたりしながら20年近くずっと続いている。

すごいね。

|

2009/09/25

プログラミング言語の進化はベストプラクティスをサポートするためにある

yuguiさんのBlogで興味深い一言があったのでメモ。

プログラミング言語の進化の方向 - 世界線航跡蔵

言語の進化はベストプラクティスの取り込みにある、と。
言語の進化はベストプラクティスをサポートするためにあるんじゃなかろうか。

プログラミング言語もツールも、ベストプラクティスの取込の歴史そのもの。
良いプログラミング言語に慣れれば、自然にオブジェクト指向も並列処理も身に付く。
同様に、良いプロジェクト管理ツールに慣れれば、自然にSW開発のマネジメント手法も身に付くはずだ。

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

要求管理プロセスのポイントは要件カバレッジとトレーサビリティマトリクス

要求管理プロセスについて良い記事があったのでメモ。

【元ネタ1】
@IT:みんなが悩む要求管理(8) 最終回 要求管理ツールの賢い使い方

 まず、要求をWordのような文書ソフトで管理すると、要求の属性や履歴の管理が難しく、要求間でトレーサビリティが設定できないという欠点があります。
一方、要求を表計算ソフトで管理すると、要求を文脈の中で表現することが難しく、要求間でトレーサビリティを設定するのが難しいという欠点があります。
いっそのこと、要求を管理するためにデータベースをカスタマイズしたツールを使うケースがありますが、この場合でも、要求を文脈の中で表現することが難しく、ツールの保守にコストがかかります。
ある程度、大規模なシステム開発の場合は、市販の要求管理ツールを用いた方がメリットの出るケースが多いと思います。

IBM Rational RequisiteProを使った要求管理の事例。
興味深いのは、トレーサビリティマトリクス(追跡可能性マトリクス)だ。
これは、清水吉男さんが提唱する派生開発プロセスXDDPにもあるTM(トレーサビリティマトリクス)と同じだ。

TMは、上位要件を行、下位要件を列で表示したマトリクス。
上位要件に下位要件が紐づいている場合、マトリクスのセルに印が付く。
このセルがトレーサビリティを示す。

つまり、TMで印を付ける作業が、上位要件に紐づく下位要件の過不足が無いかを確認する作業に相当する。
これこそが要件カバレッジだ。
この要件カバレッジ機能を意識して設計すれば、要件を詳細化していくプロセスで、要件漏れや設計漏れをなくして、設計プロセスの品質を高めることができる。

【元ネタ2】
テスト管理のベスト・プラクティス 要件ベースのテストを使用する

要件管理では、要件漏れ・テスト漏れがないかという要件カバレッジ、つまりMECEの観点が一番大事だ。
要件カバレッジがあるからこそ、要件からソースコードやテストケースまでのトレーサビリティが実現される。
逆に、バグが発生した場合、バグの影響範囲を要件カバレッジによって即座に見極められるので、ブロッキングバグの修正・検証工数も最終的には計算できる。

特に、後者の機能は、要件カバレッジを利用して、バグから本来の要件に遡って、バグが発生した要件に関係する要件から修正対象ソースへ追跡できるという点で重要だ。
この手法は仕様変更にも使えるからだ。

そして、要件カバレッジの機能は、手作業ではなく、ツールでサポートすべきだ。
理由は、要件が数百、テストケースが数千もある場合、もはや手作業でカバーできないから。
TestLinkの要件管理機能は現在は不十分でも、すごく潜在性を感じる理由でもある。

【元ネタ3】
@IT:みんなが悩む要求管理(7) 第7回 要求管理と変更依頼管理の違いを理解しよう

変更依頼管理プロセスと要求管理プロセスの関係の図が素晴らしい。
変更依頼管理や要求管理は最終的には、ITILの変更管理に落ち着く。

大規模プロジェクトほど、ユーザからやって来る膨大な改善要望や障害修正の要求は、一旦溜め込んで、すぐに判断しない。
要件定義や設計チームの代表者が集まった変更審査委員会(CCB:Change Control Board)が、一旦貯めた要求リストから、次バージョンで実現すべき要件を抽出し、優先順位付けしていく。
開発者は優先順位付けされた要件リストに従って開発し、テスト担当者は検証していく。

つまり、上記の計画プロセスと実装・検証プロセスは、ITILの変更管理とリリース管理にピッタリ当てはまる。
要求管理や変更依頼管理は、ITILの変更管理プロセスできちんと追跡できるように管理すべきなのだ。

また、要求を一旦溜め込んで優先順位付けするプロセスは、Scrumのスプリント計画やXPのイテレーション計画に相当する。
すなわち、プロダクトバックログにまずはユーザの要求を溜め込んでおき、どのスプリントで実装するかは保留にしておく。
スプリント計画を立てる時に、プロダクトバックログからスプリントバックログへ実現すべき要求を移す。
これが本来のマネジメント、あるいは要求管理になる。

そして、このプロセスはツールで実現されるべきだ。
大量の要求の一覧を優先順位付けして、どのバージョンでリリースされたか、追跡できるようにするには、Excelで手作業で行うのはもはや難しい。
ツールのサポート無しでは作業漏れも発生しやすい。

このインフラは、おそらくチケット駆動開発で実装できる。
つまり、BTSと要件管理機能を組み合わせれば、上記のプロセスを実装できるだろう。

ツールで要求管理をサポートする。
要求管理を含むチケット駆動開発こそが、仕様変更に強いアジャイル開発を更にパワーアップしてくれるはずだ。

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

チケット駆動開発の運用例part3

チケット駆動開発の運用例を見つけたのでメモ。

【元ネタ1】
[tech]チケット駆動開発 - Kazumi007の日記

特徴は下記の通り。

・開発環境は、CVS+Jira。
・タスクはチケットを切り、CVSコミット時は必ずチケットNoを入力する。
・Jiraの柔軟なワークフロー管理機能を使って、SW開発全体のタスクを管理する。
・Jiraのチケットのサブタスク機能(1レベル下のサブタスクを登録可能)を使い、親チケットはストーリーカード、子チケットはタスクカードのように運用する。

TiDDで良かった点で、「情報がJIRAに集まるため、ますますJIRAに情報が集まるようになった。」という感想が素晴らしい。
インターネットでは、情報をたくさん出すページに情報がどんどん集まる。
JiraがSW開発の情報収集・出力のハブになっている良い運用例。

「ゴールの見えないチケット」「有効期限切れのチケット」という言葉も素晴らしい。
当初はタスクをチケット登録しても、放置されるチケットも多々ある。
それらのチケットは随時メンテナンスして、クローズするか却下していく。
いわゆるチケット保守という作業は、現場リーダーが担当すべきなのだ。

厳密なワークフローの罠も、なるほどと思わせる。
現場に密着しない上級管理職が定義した厳密なワークフローは、現場では運用しづらい。
すると、誰もチケットを登録したり更新しないようになり、せっかくのチケット駆動開発も生きなくなる。
僕は、リリース後のふりかえりミーティングで、ワークフローの感想をKPTの観点で開発者から聞くのが一番良いと思う。

【元ネタ2】
概要設計工程でRedmine導入してみた事例 - T/O

面白いのは、見積工数と実績工数の入力ルール。

* チケットの進捗率は 0% or 100% で管理。つまり、完了するまではどんだけ時間掛けても0%。
* 少なくとも完了した時点で、経過時間を大雑把に入れるルールとした。
* 全体の進捗率は見積もり時間基準で。「全体の見積もり時間 / 完了分の見積もり時間」
* 経過時間は社内向けの進捗報告に使った。チケットのCSV出力機能で、経過時間を出力するようプチ改造。

チケットの粒度がバラバラなので、チケット数による進捗は無意味。
見積もり時間をベースに、完了チケットの見積工数/全体の見積工数で進捗率を出し、バーンダウンチャートで表示する。
「見積もり「時間」を見積もり「ポイント」に読み替えた」点は面白い。
これなら、進捗の精度は確かに上がる。

「対外的な品質管理報告用として、チケットの属性に「レビュー指摘件数」を追加し、レビューコメントのうち明確な指摘事項のみ件数を数え、記録した」運用もなるほどと思う。
結果は実態と合っていない結論だったようだが、このようなメトリクスも取得できるのは興味深い。
データさえあれば、後でいくらでも分析できるから。


高機能なBTSとバージョン管理ツールがあれば、誰でもチケット駆動開発を実践できるはずだ。


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

2009/09/24

ソフトウェア開発の諸問題はソフトウェアで解決する

要件とソースとテストを関連付けて管理する開発保守環境構築をめざしてBy Suzuki 」というスライドを偶然見つけた。
どうやら2005年頃の発表資料らしい。

課題と今後の目標
* ソースと要件の結びつけはできる
* でも、テストケースとソース、 テストケースと要件の結びつけが できていない
* テストケースのバージョン管理って どうやればいいんだろう?
* ツールは?
* エクセルはもう使いたくない

この回答は僕は持っている。
TiDD+TestLinkがその答えになる、と。


下記の記事を偶然見つけた。

プロジェクト管理は専用ツールを使うのが鉄則 - TechTargetジャパン

(前略)
プロジェクトマネジャーがプロジェクト管理専用のツールを使わない場合、それは彼らがしかるべき教育と訓練を受けていない証拠なのだ。
 WordやExcelを使ってプロジェクト管理を行うと、間違いなくビジネス全体に悪影響がある。例えば、リソースの利用可能量やプロジェクトの状態、プロジェクトポートフォリオ全体の健全性が見えにくくなってしまう。プロジェクトの観点から見ると、プロジェクト管理ツールを使わないことによる大きな弊害は、きちんとしたスケジュールを持たず、個別のタスクを管理するだけになってしまうことだ。プロジェクトの規模が大きい場合や、リソースに制約がある場合、期限が厳しい場合、作業の依存関係が多い場合には、これではリスキーだ。
(後略)

以前のソフトウェア開発では、期間も長く、資金も潤沢にあった。
そして何よりも、コンピュータ資源のコストが高く、誰もが湯水のように使える代物ではなかった。
だから、ツール無しで開発するのが普通だった。
プログラミングも机上デバッグが普通だったし、プロジェクト管理もマネージャ個人の能力に依存していた。

しかし、現在のソフトウェア開発は短納期で低コストで開発せねばならない。
従来と全く異なる条件は、コンピュータ資源のコスト、プログラミングのコストが劇的に安いことだ。
Webサーバーは素人でも1万円以下で構築できるし、Railsのような優れたWebフレームワークのおかげで、技術力さえあれば簡単にWebアプリを作れる。

現在のソフトウェア開発がSubversionやGit、Mercurialのようなバージョン管理無しで開発できないように、プロジェクト管理もRedmineやTracのようなツール無しではマネジメントの品質も落ちる。
更に、テスト工程におけるテスト計画・実施・集計のようなテスト管理も、TestLinkのようなツール無しでは、プロセスの品質を担保できない。

これらのツールには、マネジメントのベストプラクティスが含まれている。
ツールを使いこなせば自然に誰でもマネージャとして意思決定できる。

昨今のわずか20人月のソフトウェア開発でも、LOCは数万行を軽く超えて、テストケースは数千を超える。
これだけ複雑になったソフトウェア開発のプロジェクト管理を、Excel上でチマチマと手作業で管理するのはもはや現実的ではない。

巷にはソフトウェア開発のプロジェクト管理、テスト管理、品質管理、ソフトウェア工学に関する本が溢れている。
でもそれらは殆どが抽象的過ぎて、実際の現場で運用するにはハードルが高い。
特にソフトウェア工学に関する知識は、とても勉強になるが、実際の現場では使いづらい。
ソフトウェア信頼性モデル、要件カバレッジ、テストカバレッジ、障害管理などいずれの概念も、ツール無しでは実現できない。

ソフトウェア開発の諸問題は、過去の経験から得られたノウハウを専用のツールの機能へ実装して、そのツールで解決していくしか方法がないのではないか?

ツールでプロセスを改善する。
ソフトウェアでソフトウェア開発の諸問題を解決していく。

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

2009/09/23

アジャイル開発のFAQ

アジャイル開発のFAQについてメモ。

【1】アジャイル開発のような繰り返し型開発は、作業やリソースの重複が多くて生産性が低いのではないですか?

【回答】最初のイテレーションは試行錯誤しがちですが、イテレーションをこなすたびに慣れていき、生産性は上がっています。

特にSW開発は常に新技術を取り入れているので、開発者の学習曲線を考慮する必要があります。
アジャイル開発では、開発者の成長を意識的に支援するプラクティスが含まれています。

例えば、イテレーション毎にふりかえりMTを開いてプロセス改善する意識を開発者に植え付けますし、ペアプログラミングで開発者と技術や設計思想を共有するプラクティスもあります。

特に、プロジェクトファシリテーションでは、開発者の成長を促進するプラクティスが多々あるので参考にしてみてはいかがでしょうか?


【2】開発を繰り返すから、コストが高いのでは?

【回答】最初のイテレーションはコストは高いですが、トータルのコストはWF型開発よりも減るはずです。

1,2回目のイテレーションでは、実現できる機能も少なく、開発者も開発よりもリリース作業に手間取って、試行錯誤するので、コストはかかります。
しかし、イテレーションをこなすたびに、リリースのリハーサルを何度もしているので、リリース作業よりも開発に専念でき、開発者もシステム設計や業務に慣れていくので、後工程ほど生産性も上がります。

しかし、WF型開発の場合、仕様変更やリスク対処などの手戻り作業に工数を取られて、後工程ほど本来の作業に混乱が生じがちです。
そして、最後の一発リリース作業でいろんな問題が発見されると大きなコストがかかります。
更には、リリース後の不具合修正や改善要望が膨大に来た場合、更にコストは増えます。

アジャイル開発では、イテレーション単位に開発するため、顧客のフィードバックや障害修正を次のイテレーションで解決する方向へ進めるので、リスクを早期に対処する余地があるのです。


【3】アジャイル開発のような短期間の繰り返し型開発は、何でも早くリリースするから、品質が悪いのではないですか?

【回答】アジャイル開発と言っても、品質管理に奇策はありません。
InfoQ: James Shore氏「アジャイルの衰退と凋落」のように、戦略のない単なる繰り返し型開発は、本来のアジャイル開発ではないのです。
リリースする時点で品質を確保できてなければ、リリース後に山のようなクレームがやってきます。

また、アジャイル開発でもXPは、テスト駆動開発や継続的インテグレーションのように、コードラインの品質管理について、従来の開発にはない観点をもたらしています。

【注意】
アジャイル開発での品質管理は、上記の回答では不十分で、まだ弱点があるように思う。
従来の開発スタイルに比べて、その優位性を明示できていないように思う。
そこに、RedmineやTestLink、Mercurialなどのツールでアジャイル開発を補強できる余地がある。

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

要件定義の疑問

要件定義や設計という上流工程について以前から感じていた疑問をメモ。

【1】以前から、オブジェクト指向モデリングやらデータモデリングやらビジネスモデリング等の本を漁ってきたけれど、どれもあまり役立たない気がしている。
何故だろう?

モデリングや要求分析が必要になる場面は、新規顧客の受託開発で、顧客からシステムの要件をヒヤリングしたり、その後の仕様確認の時だ。
つまり、設計しながら要件を詰めていく作業で、モデリング技術が必要になる。

しかし、OOAもDOAもあまりピンと来ない。
RUPは確かに勉強になるが、膨大すぎて現場の実践に向かない。

UMLを使ってモデリングするのは確かに思考の整理に役立つが、それはむしろ実装に近いフェーズだ。
概念モデルのクラス図を書いたとしても、ユースケース記述で業務仕様を書いたとしても、何か物足りない。

むしろ、OOAよりもDOAの方が実践的だと感じる時がある。
テーブル設計をしながら、実際に実装している感覚だ。
特に、RailsやSeasarのように優れたフレームワークがあるおかげで、DBの箱さえ決まれば、RubyやJavaで簡単に作ることができる。

でも、DOAのデータモデルパターンは洋書しかなく和書が存在しない。
良書は、渡辺さんの本や「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」などごく一部だけだ。

OOAの本は抽象的過ぎる。
確かにクラス図を描くスキルは上がるが、実装モデルに程遠い。

OOAは最終的にはMDAがやりたいだけなのだろうと思う。
モデルさえ書ければ、プログラムを自動生成してくれるというMDAの発想。
その発想は理想的過ぎるように思う。

顧客の業務のフローやエンティティを導出するのにOOAは非常に役立つが、むしろ、システム設計ではクラス図よりも状態遷移図の方が重要だという気がしている。
我々SEがシステムエンジニアであるという意味は、業務を知ることよりも、業務をシステムへマッピングすることがSEの役割だからだ。

システム化する上で最も重要なポイントは、業務をシステムとみなした場合、システムの状態を導き出し、その遷移を全て記述することだ。
システムの状態とは、そのシステムで最も重要なエンティティの状態を表し、DBに落としたらフラグとして現れる。
そのフラグのCRUDを表した物がシステムの状態遷移図に当たる。

システムの状態遷移図を緻密に描くほど、システムの整合性を考えやすく、そこから要件漏れや設計漏れに気づく。
状態遷移図があれば、それからテストケースを作ることができる。
そして、普通は、システムが大きいほど状態遷移図は複雑であり、状態爆発を起こす。
テストケースは膨大になり、どこまでテストすれば品質を担保できるか、SEとしての技量を問われる。


【2】要件定義でいつも疑問な点は、システム化する技術力よりも顧客へのヒヤリング能力と言う人間関係構築能力の方を重要視されることだ。
昨今の人間系、特にファシリテーションもその一環と捉えることもできるだろう。

しかし、技術力が軽視されていないか?
ヒヤリング能力が重要と言っても、顧客の業務をロジカルに整理して、要件の一覧をMECEで導き出す技術も必要なはずだ。
ヒヤリング能力、ファシリテーションだけでは、要件定義を解決できない。

その点で、清水吉男さんが提唱する派生開発プロセスXDDPに興味はある。
XDDPでは、要求を発見することよりも、要求を表現することに力点を置く。
要求仕様と機能仕様を厳密に区別し、変更理由も書きながら、要求仕様を機能仕様へ階層化しながら詳細化していく手法。
この手法ならば、機能仕様へ詳細化する時に、仕様に漏れがないか、重複がないか、自然に考えれるようになる。

また、XDDPで面白いと思ったのは、要求には機能要件だけでなく、保守性や信頼性、性能要件のような非機能要件も含めるという点だ。

例えば、保守性の要件では、関数の複雑度は15以下とする、など。
信頼性や性能要件でも、ボタン押下後のレスポンスは1秒以内とする、など。

これらの非機能要件は実際のSW開発では設計漏れしがちなのだが、漏れなく仕様化できるプロセスがXDDPにはある。

普通のSW開発では、顧客はSEでないからシステム化の技術に疎く、顧客の言うがままに作ってしまうと、必ず要件漏れが発生する。
要件定義では、要件を漏れなく全てを洗い出すこと(MECE)が重要だと最近は思う。

【3】アジャイル開発は、要件定義に関して一種の諦めがあるように思う。
アジャイル開発における要件定義の特徴は、仮説検証スタイルであることだ。
つまり、短期間のイテレーションを繰り返して開発しながら、顧客のストーリーを少しずつシステム化しては、顧客に確認してもらい、フィードバックを受けながら、更に修正していく。

この繰り返し型開発スタイルは、全ての要件は最初に決められないという仮定の下で、安定した重要な要件から少しずつ開発していくという発想に基づく。
WF型開発のように、最初に全ての要件を決めていくのは現実のSW開発では無理で、すごくリスクがあるという仮定に基づいている気がする。

また、オンサイト顧客というXPのプラクティスでは、顧客を開発チームの近くに置き、常に要件を確認できる状態にする。
実際の受託開発では、顧客を開発チームの内部に配置できないケースも多い。
その場合、顧客と関係が近く業務が詳しい上級SEが顧客の代わりになるという顧客プロキシという手法もある。

また、Scrumのプロダクトバックログというアイデアもある。
顧客の要求を一旦バックログと言う貯蔵庫に貯めて、リリース計画から、そのスプリントで実現する要求をプロダクトバックログからスプリントバックログへ移す。
つまり、要求をリリース計画や優先度に基づいてふるいにかけるというマネジメントが含まれている。

アジャイル開発では、要件定義や開発スタイルに関しても、従来のWF型開発では明示されない解決方法を提示しているように思う。
まさに「1回のリリースは100回のレビューに勝る(プログラマの思索)」。

【4】要件定義や設計プロセスで重要だと思う点は、要件カバレッジと要件の追跡だ。

顧客が提示した要件は、漏れなく全て、仕様書やプログラム、テストケースに反映されているか?
顧客が提示した要件が、どの設計書に仕様化されて、どのプログラムに実装されて、どこでテストされて、どのバージョンのモジュールに反映したのか?

現場では、上記の作業をプロジェクトリーダーやSEが手作業で確認し合っているようなものだ。
だからすごく非効率で生産性が低く、結果的にシステムの品質も低い。

開発プロセスが整っていないプロジェクトでは、要件や仕様にIDが振られていない時が多い。
すると、今どれだけの要件がテストで検証されたか、どこまで要件を網羅しているか、集計できない。

「要求は数えられたら品質が上がる(プログラマの思索)」のだ。

要件にIDが振られて初めて、要件の追跡が可能になる。
現状のチケット駆動開発では、「BTSチケット→SVNリビジョン→Hudsonのビルド番号」までは相互のトレーサビリティを実現できている。
そして、TestLinkでは「要件→テストケース」の相互のトレーサビリティが実現できている。
だから、BTSとTestLinkの間のトレーサビリティを可能になれば、要件やテストケースがチケット経由でビルドモジュールのビルド番号まで追跡可能になる。

このアイデアを膨らませたものが「プロジェクト管理サーバー」。
そのアイデアは「アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索」に書いた。

つまり、「プロジェクト管理サーバー」の最終ゴールの一つは、要件カバレッジと要件の追跡をリアルタイムに集計して、管理作業を減らし、本来の開発作業に専念できるようにすることだと思っている。


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

2009/09/22

SRATSの使い方

ソフトウェア信頼度評価ツールSRATSの使い方がようやく分かったのでメモ。

【元ネタ】
信頼度成長曲線 - Wikipedia

SRATS:Software Reliability Assessment Tool on Spreadsheet Software

SRATSダウンロード

ソフトウェア信頼性評価 における最近の話題

信頼性評価ソフトウェア

ソフトウェア信頼度評価ツール - 脱・下流エンジニア (仮)

Mantisのバグ情報から信頼度成長曲線作成ツール - Rubyの魔神 - はてな?Rubyグループ


SRATSは、広島大学の岡村さんが作ったソフトウェア信頼度(SRM)を評価するExcelマクロ。
バグ情報をCSV形式で用意さえすれば、信頼度成長曲線(SRM)を自動生成することができる。
garyoさんから、このツールの存在を教えてもらった。

信頼度成長曲線が必要な理由は、システムのリリース判定の参考資料として使いたいからだ。
つまり、システムは納品しても大丈夫な品質なのか、その意思決定をする時に数値資料として扱いたいからだ。

SRATSの最大の特徴は、SRATSマニュアルにもあるように、ソフトウェアのMTBFまで計算できる点にある。

・Total: 対象とするソフトウェアに潜在する総フォールト数
・FFProb: 現時点でフォールトがすべて除去されている確率
・MTBF: 次のフォールトが発見されるまでの時間
・Be X Life: 次のフォールトが発見される確率が0.9となる時間(その時間までに1つ以上のフォールトが発見される確率が9割)

情報処理試験の知識によれば、下記の公式が成り立つ。

MTBF=平均障害故障間隔(人時/件)
故障率=1/MTBF(件/時間)

HDDや組込み機器では、MTBFやMTBR、稼働率が製品情報として含まれている。

稼動実績からハードディスクドライブ(HDD)の環境別MTBFを割り出す ? SawanoBlog.

例えば、HDDの場合、MTBFが100時間ならば、100台のHDDのうち100時間経つと1個で故障が発生していることになる。


以下、MantisやTestLinkからSRMやMTBFを計算してみたので、その使い方をメモしておく。
僕は、信頼度成長曲線の理論的背景の知識は情報処理試験レベルなのでよく知らないので、あくまでも参考程度にして欲しい。

【使い方1~Mantisからバグ情報を作り、SRATSでSRMを出力する】

Mantisの検索一覧からCSV出力後、下記のgaryoさん作成のRubyスクリプトを使って、CSVを加工する。

Mantisのバグ情報から信頼度成長曲線作成ツール - Rubyの魔神 - はてな?Rubyグループ

そのCSVを開き、累積時間と日別バグ数の表を作る。
注意点は、時間(工数)は累積にすること。

そして、SRATSから、累積時間と日別バグ数のセル範囲を選択して、「Normal SRM」を選択後、Reportボタンを実行する。

すると、上記4種類の数値とSRMのグラフがExcelで出力される。

【使い方2~TestLinkからバグ情報を作り、SRATSでSRMを出力する】

TestLinkCnvMacroのstatisticToSheetから、テスト実施日と失敗数を切り抜く。
Mantisの時と同様に、累積時間と失敗数の表を作る。
そのセル範囲を指定して、SRATSから「Normal SRM」を選択して出力する。


【感想】
SRATSのサンプルでは、MTBFの数値が17.8と出力されて、「該当ソフトウェアは十分な信頼度を達成しているので,追加のテストは必要としない」という結論が出ている。
これでは、システムが稼動する1日を8時間と計算した場合、1ヶ月(160時間)にも満たないから、1ヶ月経つとバグが出る可能性がある。

しかし、Fault-Free Prob.(現時点でフォールトがすべて除去されている確率)は80%以上だったので、品質は確保できたと考えられる。
この結論が組み立てられた詳細な理由が分からないが、他の数値も見比べて、SRMの理論から結論付けられたのだろうと思う。


品質保証部門が社内に存在して、きちんと稼動している会社(特に組込系)では、信頼度成長曲線をリリース判定時の品質チェックに使っていると聞く。
その運用ノウハウを知りたいけれど、おそらく守秘義務としてなかなかオープンにされにくいのだろう。
しかし、昨今はMozillaやEclipseのようにオープンソースのプロジェクトで、BTSデータが公開されているので、それを使って、信頼度成長曲線などのソフトウェア工学の研究ができるようになった流れもある。

また、信頼度成長曲線の見方についても昔から異論がある。
信頼度成長曲線 - Wikipediaにも書かれているように、「収束を見る場合に、横軸に日付を使った場合、テストをしていないからバグが出ないのか、テストをしてもバグが出ないのかの区別がつかないという問題がある。」
信頼度成長曲線そのものが信用できないケースもあるからだ。

しかし、実際の現場ーリーダーならば、開発の現状を知り尽くしているはずなので、信頼度成長曲線の数値に信憑性があるかどうか、リーダー個人で判断できるはずだと思う。

SRATSを使って、どこまでシステムの品質チェックができるか試してみたい。

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

2009/09/18

チケット単位に並行開発する事例

分散バージョン管理Git、Mercurialを絡めたチケット駆動開発で、興味深い事例があったのでメモ。

【事例1】
gitだからこそできるチケット駆動開発のやり方 - kunitの日記

今やっている方法は、作業するなら作業用のブランチを切れ!それにはチケット番号を付けろ!という方式にしている。
たとえば会員管理の機能に追加したい場合は以下のような手順になる。
1. 会員管理を拡張したいなぁ
2. じゃRedmineでチケットを切るぞ
3. チケット番号が振られた(たとえば #567 だとする)
4. さぁ、ブランチ切るか(members_567)
5. そのブランチで作業開始!
濱野さんがWEB+DBでも入門Gitでもかかれている「トピックブランチ」というものの良さが本当に現れてくる。

【事例2】
Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - 文殊堂

ticket毎に開発作業用branchを作成する
* 同期branchから作成する
* 同期branchから随時rebaseする
* 必ず、同期branchの最新版からrebaseした状態でテストを行う。
* テストが通ったらticket別branchから同期branchにmergeする。その後、同期branchの内容で中央リポジトリにcommitする。
o 同期branchにmerge後、ticket別branchはinactiveなbranchになる

いずれの事例も、作業する時はチケットを作り、trunkから切ったブランチにチケットNoを紐づけて運用する。
つまり、チケット単位にブランチを作り、そのブランチ上でソースの修正を行い、作業が完了したらtrunkにマージしてチケットが終了する。

分散バージョン管理では、ブランチは中央リポジトリではなく、開発者個人のローカルなリポジトリに作られる。
つまり、SVNやCVSのような中央集権的バージョン管理ではローカルの開発環境で作業していたコードラインを、GitやMercurialのような分散バージョン管理では、明示的に開発者のローカル環境のブランチとして作業できる。
その利点は、trunkとは別個に作業履歴を残せること、そして、分散バージョン管理の優れた自動マージ機能のおかげで、trunkにすぐに反映できることだ。

そして、このブランチをチケットに紐付けて、作業ステータスを管理できるようにする。
このやり方をトピックブランチと呼ぶらしい。

SVNなら管理しづらいブランチも、分散バージョン管理では普通の状況であり、その利点をフルに生かしている。
しかも、チケット駆動開発と絡めれば、トピックブランチの作業状態もBTS上でリアルタイムに把握できる。

このトピックブランチは、プライベートブランチ、タスクブランチの一種とも言えるが、チケット駆動開発とかなり相性がよい。
トピックブランチをチケットブランチと言ってもいいくらいだ。

特に、作業者が複数人の場合、更には大規模プロジェクトで並行開発する場合、あるいは、組込製品やパッケージ製品での並行開発で、このやり方は大きな威力を発揮するのではないか?

アジャイル開発が事実上、並行開発せざるを得ないように、チケット駆動開発はソフトウェア構成管理と密接に関係する。
その理由は、チケット駆動開発と並行開発の相性が良いから。

元々、Redmineでは、1リポジトリ=1プロジェクトの運用思想のため、ブランチ単位にRedmineプロジェクトを作る。
この複数プロジェクト機能を使えば、チケット駆動開発を並行開発のインフラにできる。

普通は、並行する2本のライン(trunk, branch)はプロジェクト単位だが、上記のトピックブランチはチケット単位でブランチを管理する。
つまり、BTSのプロジェクトとチケットで観点を変えて、ブランチを管理すればいい。

分散バージョン管理とチケット駆動開発の組み合わせは、並行開発の管理を劇的に効率化する可能性があると思う。

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

2009/09/17

ブロッキングバグの事例

TestLinkのテスト実行画面には「成功」「失敗」の他に「ブロック」がある。(ソフトウェアテスト標準用語集 日本語版Ver 1.3)
普通は、失敗時に、失敗したテストケースに依存するテストケースをブロックにして、テスト保留にする。

ここで、ブロッキングバグとは、失敗したテストケースの機能のバグのうち、リリースを妨げるような重大なバグを指す。
ブロッカーバグとも言われるらしい。
更に、ブロックしたテストケースの機能は、みなしバグと呼ばれる。

Tracのチケットでは、緊急性が最も高い優先度が「blocker」になっているが、ブロッキングバグはそれに当たると思う。

このブロッキングバグの事例を見つけたのでメモ。

【事例1】
ある会社の新人チームが開発後テスト中にブロッキングバグに遭遇した事例が書かれている。
緊迫した内容がリアルで、とても素晴らしい。

コラム[直し壊しのテストフェーズ]‐株式会社アーツテック[ARTSTECH]

特に、結合テストやシステムテストでは、バグ修正と同時にテストデータの準備や本番環境の構築作業を行わなければならない。
この時に、どの作業を優先して行うか、意思決定が迫られる。

普通は、ブロッキングバグを最優先に直すのが先だ。
理由は、ブロッキングバグが直らないと、未検証の機能はみなしバグの状態になってしまい、テストしても無意味だからだ。
ブロッキングバグはまさにリリース不能にさせるバグ、プロジェクトの動き全体を文字通りブロックしてしまう危険なバグなのだ。

【事例2】
Mozillaが安定していなかった頃のQAメールのやり取り。

もじら組フォーラム [One Topic All View / Re[7]: Mozilla 1.3 for Mac OS X でメールフォルダ名が文字化け / Page: 0]

(前略)
ただですらユーザの少ないMac版のしかも日本語処理のバグなんで声を出さないとなかなか注目を浴びないと思います。
Bugzilla-jpでバグを立てると国内の有志が協力してくれるとしょう。
どちらも内容的にはブロッキングバグになってしかるべきものと思います。
(後略)

もじら組フォーラム [One Topic All View / Re[1]: Mozilla 1.4 リソースリーク? / Page: 0]

(前略)
1.4は1.0.xに変わる安定系という役割なのに、何を焦っているのか、ブロッカーバグをつぶさずリリースしたことが、今回の失態につながっている。
MozillaはともかくNetscape 7.1は大問題だと思う。
これさえなければ、Netscape復活といえる出来なだけに誠に残念。
ショボイOSにも問題はあるが、早急に修正版を出して欲しい。
(後略)

ブロッキングバグを無視してリリースしてしまった為、ユーザから製品に対する信頼を落とした事例として非常に耳が痛い。
ブロッキングバグを残したままリリースした場合、ブロックした機能は未検証のため、品質に疑問符が付いたままになる。

結局、ユーザにブロックしたテストケースを再テストさせているようなものだ。
つまり、みなしバグをユーザがテストして、はっきりとバグと判明させたようなもの。
プロの技術者として恥ずかしいだろう。

テスト管理には、プログラミングとは違った特有の技術があるように思う。

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

2009/09/15

TestLinkの要件管理機能

TestLinkの要件管理機能についてメモ。

【元ネタ】
要件のテスト - watawata日記

TestLinkの可能性: プログラマの思索

要求管理(要件管理)ツール RaQuest

要求管理ツールRaQuest・要求項目の作成

要求管理ツールRaQuest・ツリーと一覧を駆使した要求項目の効率的な管理

要求管理ツールRaQuest・要求の追跡

TestLinkの機能とV字モデルの関係 (Testlinkjp-users) - TestLink日本語化 - SourceForge.JP


テスト管理ツールTestLinkには不十分だが、要件管理機能が付いている。
TestLinkCnvMacroを使えば、TestLink要件をTestLinkキーワードを経由して、TestLinkテストケースとN対Nの関係に持ち込むことができる。

この紐づけによって、要件カバレッジが可能になり、キーワード別にテスト結果を集計できるため、要件が今どこまでテストで検証できたか、を表示することができる。

つまり、TestLinkの要件管理機能を使って、要件定義や設計工程で要件カバレッジを取りながらテスト設計すれば、W字モデルのような開発が可能になる。
すなわち、上流工程でテスト設計の作業ができるので、設計工程の成果物を検証する作業も可能になるだろう。
テスト駆動開発を製造工程だけでなく設計工程など上流工程へ持ち込めるだろう。
特に、要件カバレッジはテストケースの品質に大きな威力を発揮する。

この場合、TestLink要件を顧客の本来の要件と対応させた時、その要件は受入テストのテストケースに対応付けられる。
すると、単体・結合・システムテストのテストケースに相当するTestLink要件は一体何に当たるのか?

そのTestLink要件は、単体・結合・システムテストの上流工程に当たる製造・内部設計・外部設計の仕様に当たるだろう。
各工程の仕様を網羅する観点で、テストケースを作っていけばいい。

すると、各工程の仕様や要件はどのように関連付けられるか?
それは、要件から外部・内部・詳細設計の仕様までの関係、ツリー上に詳細化されていくと考えてよいだろう。
製造工程における仕様は遡れば、要件まで辿りつく。

つまり、要件はツリー構造であるべきだ。
すなわち、TestLink要件は現状のCSV形式の1階層の構造ではなく、TestLinkテストスイートのように階層構造を持つべきだ。
そうすれば、顧客の要件から製造工程の仕様まで追跡可能になる。

更には、TestLink要件の各階層が単体・結合・システム・受入テストのテストケースと対応づけられればよい。
そうすれば、単体~受入テストの各工程で仕様・要件カバレッジが可能になる。

TestLinkの要件管理機能は正直使い勝手が悪く、発展途上の機能。
TestLinkの要件管理機能のあるべき姿は、EnterpriseArchitectの要求管理ツールRaQuestのように、要件の状態管理や履歴管理、要件の追跡機能が実現されることだろう。
そうなれば、要件カバレッジ機能がより簡単に使えて、テストケースの品質アップに大きく貢献するだろう。

オープンソースのテスト管理ツールTestLinkには大きなポテンシャルがあると思う。

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

XDDPの資料リンク

清水吉男さんが提唱されている派生開発プロセスXDDPの資料がネット上にあったのでメモ。

【資料1】
JaSST2009東京・派生開発における母体に由来するバグとその対応・清水 吉男(システムクリエイツ)

JaSST2007東京・要求の品格1:テストの質を上げるための要求仕様書・清水 吉男(システムクリエイツ)

いずれもJaSST東京(SWテストシンポジウム)で、XDDPの開発スタイルの概要が講演資料として公開されている。
XDDPの成果物の3点セット(要求仕様書・変更設計書・トレーサビリティマトリックス(TM))とそのプロセスが分かりやすく説明されている。

XDDPの一番の肝は、トレーサビリティマトリックス(TM)だ。
TMが変更要求仕様(What)と変更設計書(How)を関連付ける資料となる。
TMで変更要求が機能にどれだけ影響しているか一覧できるので、TMを詳細化するプロセスが自然に仕様化プロセスになる。

【資料2】
SQIP2008・6-1.XDDPによるソフト派生開発のQCD向上活動・加藤 由之((株)デンソー)

SQIP2008(SW品質シンポジウム)で、XDDPを現場で実践した運用例が経験論文で公開されている。
XDDP運用2年目のプロセス改善の結果が、SQIP2009でも経験論文として掲載される予定だ。

【ツール例】
日々精進 - スパークスシステムズ ジャパン代表のBlog:プロセスフロー図(PFD) - livedoor Blog(ブログ)

Enterprise Architect・プロセスフロー図(PFD)描画アドインについて

つい最近、Enterprise Architectにも、清水さんが編み出したプロセスフロー図(PFD)を描けるプラグインが提供された。
PFDは成果物とプロセスをつないだDFDのような絵。
PMやPLのように、開発プロセスを設計する人達は使ってもいいかもしれない。

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

2009/09/14

『~ It!』シリーズの本は良書

【元ネタ】
エンジニアがタイトル買い、著者買いすべき本 - {Fight the Future => じゅくのblog}

『~ It!』シリーズの本は確かに良書だ。
『~ It!』シリーズの本は3冊ある。

Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック」は、プログラマが身に着けるべき習慣が書かれている。

Release It! 本番用ソフトウェア製品の設計とデプロイのために」にあるノウハウは、Webシステムの環境構築やリリース作業で非常に役立つだろう。

Manage It! 現場開発者のための達人式プロジェクトマネジメント」は、開発者のためのプロジェクト管理、特にアジャイル開発の導入に関するノウハウが書かれている。

後日、読んだ感想を書いてみる。

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

要件管理はチケット駆動開発で実装できるか?

要件管理をRedmineやTrac上で試しているが、しっくりこない原因をメモ。

【元ネタ】
チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索

RedmineへScrumのアイデアを注入: プログラマの思索

まちゅさんは、「チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)」で下記のようなコメントを残している。

TiDD は開発プロセス全体を網羅するものではない。開発プロセスを補完するもの。
* チケットの粒度が細かいことと、構成管理ツールと密接な関係があることから、アウトプットが明確な領域に適用しやすい。
* 要件定義などの不確定要素が大きいタスクに適用するのは難しいかも。


まちゅさんが言うように、TiDDは構成管理ツールと相性がよいので、成果物の管理とチケットを連携させると効果的。
特に、実装やバグ修正、リリース作業で威力を発揮する。

しかし、要件定義や設計のプロセスでは、TiDDはしっくりこないのが僕の実感。
チケットに要件や仕様を書いても、それで漏れなく十分足りているのか分からない。
要件も仕様も、設計して実装して動かしてみて、初めて間違いや漏れが分かる。
設計工程の品質が悪いのが元々の原因だが、その設計の質をアップするのにチケットが役立っていない。
設計プロセスで重要なのは、設計という作業を通じて、本来の要件を緻密に詳細化することだから。

むしろ、要件定義や設計工程で、要件や仕様の確認などの課題管理にチケットを使うと、上手に回る。
例えば、顧客と要件を質問したり、設計者と開発者で仕様のやり取りをする場合、チケットで作業状態を管理すれば、進捗やリスクを追跡しやすくなる。
つまり、設計そのものではなく、要件定義や設計と言う作業はチケットで管理した方がスムーズに回る。

以前、顧客向けの進捗報告を作るために、ストーリーカードをチケットに落として、進捗や作業状態を集計しやすくする方法を考えて、実践してみた。
実際の運用では、ストーリーカードへタスクカードの状態を手作業で反映するのが面倒で、あまり有り難味が感じられなかった。

チケット駆動開発は進捗報告作りをどのように解決しようとするか?: プログラマの思索


RedmineのScrumプラグインのように、チケットの親子関係をRedmine上で実現してくれれば、その作業は自動化できるだろうと思う。

RedmineへScrumのアイデアを注入: プログラマの思索


ところで、派生開発プロセスXDDPでは、設計プロセスでソースからリバースエンジニアリングして、要求仕様書や変更仕様書を作る。
ここで、要求仕様書は今回限りの要件を洗い出したドキュメントであり、変更仕様書はソースの修正手順まで書いた今回限りのドキュメントである。
システムの外部設計や内部設計を書いている機能仕様書には、派生開発が終わり次第、要求仕様書や変更仕様書から変更箇所がマージされて、最新の仕様が反映される手順になる。

つまり、機能仕様書はVerUpしていく。
機能仕様書は構成管理の管理下に置かれるべきものであるから、チケットで管理できる。

しかし、今回限りの成果物である要求仕様書や変更設計書はVerUpの対象ではない。
これらは仕様化プロセスの一時的な成果物。
もし、これらをチケットで管理した場合、作業は管理できるが、仕様化して詰めていく作業はチケットとは別物だ。

XDDPが示唆することは、要件定義や設計のプロセスは、チケットではなく別の何かで管理すべきと示唆しているように思えてならない。

要件管理や設計という上流工程をいかに制御するか?
まだその実現方法が分からず試行錯誤中。

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

2009/09/13

アジャイル開発が並行開発になる理由

アジャイル開発が並行開発になる理由をメモ。

【元ネタ】
Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - 文殊堂

変更要求に対する選択肢: プログラマの思索

派生開発プロセスXDDPの講演メモ: プログラマの思索

普通の受託案件で、アジャイル開発を実践していて、新規開発中だったと仮定する。
リリース計画としては、最終目的はver1.0をリリースするように作るだろう。
イテレーション計画としては、Ver1.0のイテレーションを作るか、マイルストーン単位に複数のイテレーションを作るだろう。

リリース予定のVer1.0に向けて開発中で、trunk以外にコードラインは存在しないだろう。
開発者は、trunkだけに集中してコミットしていく。

そして、Ver1.0をリリースするタイミングになったと仮定する。
リリース担当者は、trunkからver1.0のtagを切り、ver1.0のリリースブランチを作る。

その後、Ver2.0のイテレーションを作り、開発者は次のバージョンに向けてtrunk上で開発していく。
普通に考えるならば、アジャイル開発もWF型開発も並行開発にはならない。

しかし、実は、リリースしたVer1.0へ障害対応するために、Ver1.1のイテレーションを作り、ver1.0のリリースブランチ上で作業せざるを得ない。
つまり、Ver2.0に向けて機能追加に対応するtrunkと、Ver1.0のバグフィックスに対応するリリースブランチの2本の並行開発が自然に必要になる。

リリースしたバージョンに対するイテレーションは、引き続き保守のためのイテレーションが続いていくのだ。
だから、リリースブランチで本番運用中のソースを保守しながら、裏のtrunkで機能追加のソースをガンガン開発していく並行開発になる。

すなわち、システムはリリースしたら、それで終わりと言うわけではない。
むしろ、システムを育てていく観点が大事だ。

WF型開発は、Ver1.0のシステムをドカーンと一発リリースして、その後、大量のバグ修正や改善要望に忙殺されるのが殆どだ。
WF型開発があまりにも理想的な開発スタイルで現場の運用に馴染まない理由は、Ver1.0だけの開発プロセスに過ぎず、運用保守を含めた全体的なソフトウェアのライフサイクルの観点が漏れていることだと思う。

この並行開発は、組込み製品やパッケージ製品の開発で発生し、その構成管理や開発プロセスが非常に難しくなることは昔から知られていた。

並行開発の難点は二つあると思う。
一つは、1本のコードラインをリリースまで持っていくのも大変なのに複数のコードラインを保守せざるを得ず、品質維持が難しい点。
もう一つは、リリースブランチの障害修正をtrunkへマージする、あるいは、共通ライブラリの修正点を他の製品ラインへマージする作業が発生すること。

この並行開発に対し、SW工学の観点から、SWプロダクトラインが対応しようと試みている。
つまり、共通ドメインのコア資産と各製品特有のドメインをアプリケーション資産に分けて管理する発想。
しかし、並行開発の諸問題を全て解決できたとは聞いていない。

並行開発に関しては、いくつかのアプローチは知られている。
一つは、緊急の機能追加に対応する場合、タスクブランチを活用すること。
やり方は下記に書いた。

変更要求に対する選択肢: プログラマの思索

また、清水吉男さんが提唱する派生開発プロセスXDDPは、追加と変更の2本のタスクブランチを作る。
考え方は下記に書いた。

派生開発プロセスXDDPの講演メモ: プログラマの思索

つまり、いずれも故意に並行開発を選択することで、要求の変更に対応しようとする。
但し、いずれも難易度は高いと思っている。

そして、並行開発が難しいのは、根本的には構成管理の技術に落ち着くと思っている。
ブランチの品質保持とマージ作業の自動化が鍵。
CVSからSubversion、そして、GitやMercurialに至るバージョン管理の技術の流れも、並行開発の観点から整理できると思う。

従来の組込み製品やパッケージ製品だけでなく、昨今はWebシステムやオープンソースでも並行開発が当たり前の状況になったのに、並行開発の諸問題を解決する方法、特に構成管理の技術が意識されていないのは不思議だと思う。

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

2009/09/12

【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較~TiDDに必要な必須機能」

第4.5回Shibuya.trac に参加して発表してきた。
スタッフの皆さん、ありがとうございました。

その発表資料「RedmineとTracの機能比較~TiDDに必要な必須機能」をCC Attribution ライセンスで公開します。
今回の発表は、昨年のKOFで発表したRedmine+TiDDから続く一連のチケット駆動開発のまとめになります。

SQIP2009では、大手SIの経営者や管理職が多いせいか、チケット駆動開発の発表はプロセス改善というよりもツールに依存した運用改善と捉えられがちで、あまり反響がなかった。
でも、第4.5回Shibuya.tracはまるでホームのような雰囲気で、聴衆はTrac使用者がRedmine使用者よりもやや多かったけれど、チケット駆動開発に興味のある人達ばかりだったので、熱く語ることができた。
関西から八朔さんや小枝さんも来てくれて心強かった。

最後のパネルディスカッションでは、5人のパネラーにTiDDをKPTの観点で経験談や苦労話を語ってもらった。
実際の運用事例を5人の経験の観点から話せたから、とても参考になったと思う。

#パネルディスカッションの内容は下記で公開されている。
meeting/04.5/PanelDiscussion - Shibuya.trac Wiki - Shibuya.trac - SourceForge.JP

また、僕のBlogをたくさんの人が読んでくれていた事実も気付かせてもらい、更にフィードバックももらって非常に参考になった。

最近思うのは、ノウハウはどんどん公開した方がいいこと。
僕がRedmineやTestLink、そしてMercurialを使って経験したこと、考えたことは基本的にBlogで公開するようにしている。
最初は、Blogに書きながら僕が考えていることを整理しているだけだった。
でも、Blogにコメントがあったり、コミュニティでBlogの記事に関して質問を受けたりして、思索を深める上でとても参考になった。

KOF2008、XP祭り関西2009、ETWest2009の発表資料を公開した時、クリエイティブ・コモンズ・ライセンスにしている。
このライセンスにした理由は、チケット駆動開発の提唱者であるまちゅさんが自分の資料をそのライセンスで公開していたから。
でも、このライセンスにして良かったと思っている。
このライセンスのおかげで、僕が考えたというクレジットを付けてくれれば、誰もが自由に流用でき配布できる。

僕が色々考えたアイデアは、僕がたくさん汗をかいて経験した後で気付いた結果だが、色んな人の影響も受けている。
チケット駆動開発と言うアイデアは僕一人のものではないし、むしろ、興味ある人達がよってたかって知恵として固めようとしている最中。

勝間和代の本に「情報は通貨である」という文言があったけれど、まさに実感する。
ノウハウはお金と同様に、貯めても意味がない。
貯めたお金は投資して、生産性を上げて富を増やして意味をなす。
ノウハウもどんどん公開して、みんなに使ってもらって、フィードバックを受けて、より良いものへ修正していくほど、価値が上がる。

特に技術者にとって、ノウハウを公開して自分の技術力を知らしめることができれば、自然に営業できる。
Blogに記事を書いたり、SourceForgやGoogleCodeでソースを公開すれば、Googleの検索エンジンが拾って関連付けてくれて、一つのノウハウが色んな人達のノウハウと積み重なって、大衆の知恵のように一つのプラクティス、あるいは思想になる。

オープンソース、あるいはBlogと言うからくりは、技術者にとってすごく重要な仕組みだと思う。

この記事を読んでいる人達、チケット駆動開発を実践している人達には、是非、自分の考えを発信して、色んな人に影響を与えて欲しいと思う。

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

2009/09/11

レビューをTestLink+Redmineで管理できないか?

SQIP2009の森崎さんの講演「レビューの壁を破る」を聞きながら、考えたことをメモ。
#後でまとめる。

SW開発の品質UP、プロセス改善を目指すと、最終的には設計工程でどれだけバグを潰せるか、という点に落ち着く。
上流工程の品質UPが鍵を握る。
そのためには、設計レビューが必要で、きちんとすべきだね、という話にいつも行き着く。

しかし、設計レビューそのものの品質が低いように思う。
僕がいつもレビューで問題と思う点は、二つある。

一つは、レビューのプロセスがあいまいできちんと定義されていないこと。
例えば、レビューする際の観点がレビューアによってまちまちだったりする。
レビューのチェックリストがあるにはあるのだが、形骸化しており、機能していない。

もう一つは、レビューで指摘を受けた内容を反映する作業のチェックがおろそかであること。
例えば、レビュー後修正の品質チェックが個人任せで、他人のチェックができていない。
その原因は、レビューアの人数不足でレビューそのものが遅れがち、などがある。

議論を聞きながら思ったことは、「レビューを設計工程のテスト」を考えられないだろうか?
設計書をレビューのチェックリストに基づいて、ウォークスルー形式で検証しているのではないか?
となると、レビュー後修正は、設計のバグ修正に当たるのではないか?

つまり、レビューを設計のテストと考えると、下記の相関関係が成り立つのではないか?

レビューのチェックリスト=TestLinkのテストケース
レビュー結果=TestLinkのテスト結果
レビューで指摘を受けた内容を修正=Redmjneでバグ修正

すると、TestLinkのビルド、ブロックはレビュー工程でどのように対応するのか?
まだ分からない。

設計工程やレビューでいつも腑に落ちないのは、Excelばかり使っていて、作業状態の把握や集計作業が大変なこと。
チケット駆動開発にレビュープロセスをのせることができれば、プロセスをBTSのワークフローで管理できるし、レビューの漏れがなくなるのではないか?

RedmineやTestLink、Mercurialなど各種ツールを使いこなすと、下流工程のプロセスはツールで制御できるようになる。
しかし、上流工程、つまり要件定義や設計をチケット駆動開発が制御するのは不十分。

色々考えてみたい。

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

2009/09/09

派生開発プロセスXDDPの講演メモ

SQIP2009で清水吉男さんのXDDPの講演を聞く機会があった。
アジャイル開発や並行開発、要求仕様と機能仕様の違いについて、とても勉強になったので、メモを公開しておく。
なお、メモ書きなので、分かりにくい部分は、下記の著書を読んで理解してください。

【講演メモ】
◆派生開発の特徴と問題点
保守開発
 JISで定義されている
 派生開発とは似ているが異なる
  例:携帯電話は、電話以外の機能が次々と追加されている
    保守ではない
→是正保守プロセスで改良保守を行うと問題が発生する

派生開発特有の混乱が生じている
 まずい作業で品質が劣化する

派生開発にはアーキテクチャ設計がなくても開発できる

仕様は設計しないと出てこない
 衝突は仕様レベルで出る

派生開発は新規開発よりも複雑
 追加機能と変更は異なる
 機能追加は、新しい機能の仕様やレビューしかない
  追加と変更の2本立てにしなければならない

ソースも移植に伴い、拒否反応を起こす
 プログラムは、既存のシステムのために作られた
 しかし、他のシステムへ再利用すると、文化が違うので、拒否反応を起こす
  免疫、臓器移植と同じ

変更方法も一つとは限らない
 例では3つ方法がある
 どれもテストOK
 しかし、1年後に問題になる
  何のために要求が来たのか?
  表示欄が足りないのが本来の要件

一つの変更が複数の機能にまたがる
 機能同士の依存関係
  データなど
  気付きやすい
 設計やプログラミングによって影響する
  設計書に変更内容が反映されていない
  
  ネームロンダリング
   引数に渡ったデータパターンが悪さする
  クローンコード
   移植するとアルゴリズムは同じだが変数名が変わるので同一ではないと見てしまう

派生開発は「部分理解」の制約が多い
 やっぱり全体を理解していない、という言葉が反省会でよく出る
 皆が納得して終わっている
  リソースが足りないので全部を調べきれない
  理解のレベルが曖昧
   理解できなかった時の対応方法が考えられていない
→部分理解しかできないのだ、という仮定で進めよう
→どのタイミングでどのようにレビューするか、が非常に重要

派生開発は一人プロジェクトが多い
 一人プロジェクトはやめよう
  部分理解の罠に陥りやすい
   思い込み、勘違い
 擬似一人プロジェクトもある
  大人数チームでも、担当者一人の作業
  各担当者が作ったソースを結合して、初めて不具合が分かる

拙速なソース変更が状況を悪化させる
 開発期間が短いため、プレッシャーが大きい
 ソース修正期間が長いため、ながら作業になっている
  修正方法が異なるやり方で何度もソースをいじって、品質を劣化させる
  1日500行直したとしても、本来の正しいソースは50行だけかもしれない

バグがいつまで経っても収束しない
 バグ修正で新しいバグを埋め込んでしまう
  テスト期間がどんどん延びる
 派生開発では、修正した箇所が問題なのに、ソースコードを弄んだために変更した箇所の手がかりを失った
  バグ修正のプロセスが個人任せ

変更方法に基づくテストが行われていない
 機能追加だけで、変更機能のテストが行われていない

新規開発崩しで公式文書を変更している
 公式文書を削って修正するが、あくまでも作業中
  最終版ではないので、どれが最新の仕様か分からない
  →並行開発や五月雨開発の支障になる

そもそも組織には新規開発のSDSしかない?
 SDS
  ソフトウェア開発スタンダード
  CMMIの用語
 CMMIの認証は新規開発プロジェクトを対象とするケースが多い
  派生開発用のSDSが必要
  →XDDPが売れない理由

要求仕様のFixを要求するのが当然と思っている
 仕様が見えないので、スムーズな合意が形成できない
  後で動くようになってから、必ず仕様変更が発生する
 要求仕様書の構成が邪魔している

作り方の品質要求が入っていない
 機能仕様書で作ろうとしている
  機能の概要であって、作り方は書いていない
 要求仕様書を作るべき
  作り方が入っている
 保守性の観点が漏れている
  ソースを触るほど品質が劣化する
  派生開発で、保守性の品質要求が記述されていない

保守性の意味が最近変化している
 Maintainabilityが基本
 しかし、Supportabilityなどが混じっている

作り直しても何も変わらない
 アーキテクチャを作り直しても、派生開発に追われて新しいアーキテクチャを勉強していなかった

派生開発を意識しないと明日はない
 不適切な派生開発プロセスで対応している
  Faster、Cheaper、Worse!

◆XDDPの解説
XDDP=USDM+PFD
 要求仕様の書き方
  USDM
 プロセスを自由自在に設計する
  PFD

USDMは表現に重点を置いた仕様化の方法
 最近のモデリング
  要求の発見を重視する
  しかし、要求の表現方法はあまり触れていない
 せっかく発見した要求も適切に表現されなければ、仕様が漏れる

USDM
 機能要求は、振る舞いを表現する
  その中に仕様がある
 要求と一緒に理由を表現する
  要求の意図や背景を補足する
  認識のずれを軽減する
 仕様は、要求の中の動詞、目的語にある
  動詞を的確に表現することで必要な仕様を引き出す
  →本には触れられなかった
 要求と仕様を階層で表現する
  要求も2階層で表現したりする

 コミュニケーションの不完全性を相当程度カバーする
  アジャイル開発で頻出する
   「分からないならさっさと作ってリリースした方がいい」という考え方がアジャイル開発

要求仕様書と機能仕様書の違い
 要求仕様書
  今回のプロジェクトで実現して欲しいこと(Requirement)
  作ることの関係者が、実現内容について特定(Specify)できている
   関係者も特定できている
    作る人、依頼する人、確認する人
  今回限りのドキュメント
 機能仕様書
  関係者を特定できないので、表現は均一になる
  VerUpしていく

プロセスと成果物は表裏一体
 プロセスを変えると成果物も変わるはず
 でも、プロセス改善を叫ぶ所では、30年前の設計書を使っている
 
新規開発
 機能仕様書(企画)がInput
 新規に作る時に、機能仕様書に変身する
  完成後に機能仕様書に戻り、VerUpしていく
  要求仕様書は途中で作られる

派生開発
 要求仕様書は2種類必要
  変更、機能追加
  要求仕様書は差分の情報だけ
  2つの要求仕様書に基づいて開発していく
 完成後に、機能仕様書へマージして更新する

追加機能要求仕様書
 追加分+変更分の2個がある!
 変更分は、BeforeとAfterがある

変更要求仕様書
 変更分


XDDPは2種類のプロセスを並行で動かす
 変更分+追加分
 追加機能要求仕様書を作成後、変更要求仕様書を作る

変更プロセス
 Input
  変更箇所の仕様
  ソース調査
  追加要求の仕様
 OutPut
  変更要求仕様書
  TM(トレーサビリティマトリクス)
 更に、変更設計書を作成する
  ソースレベルで変更箇所を特定し、修正方針を作る
 ソースコードを一斉に変更する
  最初のソース調査、変更設計書の作成時、今回の3回もソースを見ているので漏れがない

機能追加プロセス
 機能追加を扱うプロセス
 変更プロセスとの間で、追加機能を受け入れる方法を調整しておく
  終了したら、そのまま設計に取り掛かる
 変更プロセスと関係なく進める

変更プロセスは3点セット
 変更要求仕様書 What
 TM Where
 変更設計書 How

アーキテクチャが存在しているため、TMまで作れる!

仕様→設計する→設計書

設計するためにソース調査の観点
 データ構造
 制御構造
 判定構造

XDDPの特徴
 変更と機能追加のプロセスを分ける
 差分で進めるので並行開発が可能
 テスト終了後に公式文書へ反映する

◆追加機能要求仕様書
 普通の新規開発と同じでよい
 要求と仕様を階層化する
 認定仕様の考え方を受け入れる
  納期を考慮した暫定の仕様

要求の発見
 ユースケース
  最近は、振る舞いの一部の動作しか表現しない傾向が見られる
   動詞が見えづらい
  ロールに要求があるはず
 状態遷移
  イベントから振る舞いを表現する
 操作画面の要素
  画面も一つの状態
  ボタンはイベント発生源

機能要求は振る舞いと範囲で表現する
 範囲
  イベントの始まりと終わり
   バッチ処理ならジョブ実行のみ
 範囲に注目しよう

要求には理由を付ける
 理由は要求の一部
 理由から代替仕様を提案できる

範囲が広いと仕様が漏れやすい
 隠れた動詞が多い
 動詞を探して時系列に分割する

分割は2階層程度で抑える
 階層化で隠れている動詞を全て洗い出す

分割方法は構造化設計の技術で十分
 モジュールの分割基準

設計しないと仕様が出てこない
 設計とは分割すること
 時系列にシナリオを作ること

仕様とは、要求に含まれる具体的な処理や振る舞いを表現したもの
 仕様はテスト可能
  検証可能
 仕様は全てソースコードになる
  実現可能

仕様は階層の中で捉える

認定仕様
 仕様化する必要がない要求
  既に分かっているなら設計しなくてもいい
   工数削減
  □で書いておく
   チェックボックスの代わり
 →要求仕様書だから可能
   機能仕様書はこのような記述は認められない
 →邪道らしいが、現実的
   XPのシンプルと同じ
 
例:要求=70個
   50個=認定仕様
    →仕様化する工数は不要
   20個=きちんと作る
    →1120個の仕様が出てきた

必要なら仕様にも理由を書く

仕様のグループ化
 動詞の単位でグループの下に仕様を引き出す

仕様から要求を作る
 みにくいアヒルの子
  要求と理由があるのに、仕様とマッチしない状態

対応方法:
1・他の要求へ仕様を移動する
2・適切な要求を作り、仕様を移す
3・要求と理由を変更して、範囲を広げる

新しい要求を設定すると、新しい仕様に気付く
 従来の要求仕様書では、このテクニックは使えない

画面配置図の下に仕様化する
 画面仕様書と同じ
 画面操作は1階層で殆ど対応可能

作り方の要求も仕様化する
 保守性などの品質要求も仕様化しないと実現しない
  XDDP特有の開発スタイル
 検証できるように表現する
  仕様だから
  作業者に対する指示書になる
   従来の機能要求書には、保守性は書けない
    保守性は機能ではないから
  保守性も要求である
   従来の本には、保守性の要求を表現する技術が書かれていない

「見なす」という文言がXDDPには出てくる
 要求はこれだけの仕様を満たす
 「見なす」には承認作業が含まれている?

問題は要求漏れ
 仕様漏れが原因ではない
 要求を表現しないから仕様漏れと認識される

Excelでは、行を折り畳む機能がある
 要求だけを一覧表示する
  仕様を隠す
 TMが一番重要
  行は、要求+仕様
  列は、機能
  変更箇所が交差する所

◆変更要求仕様書の書き方
 全ての変更を扱う要求仕様書
  変更要求と変更仕様を階層化する
 実現方法まで特定する(Specify)
  変更仕様はソースコードのレベルで記述する
  →追加機能の場合と異なる

変更要求の範囲と理由を表現する
 範囲を明確に表現することで、要求になる
 Before、Afterを表現する
  追加する、削除するには、Before、Afterの情報が含まれている
 Beforeに影響箇所の情報がたくさん含まれている

変更は要求ではなく、仕様で届く時が多い
 問題
  依頼された箇所を変更するだけでは済まない
   そもそも適切な箇所とは限らない
 対応
  変更仕様から変更要求と理由を探して、改めて変更仕様を探す
  
 →要求と仕様を区別しない状態では、これが問題と思われない

 機能仕様書などの文書から探す
  具体例あり
   変更仕様だけでは仕様漏れが出る
   変更要求と理由を見つけると、新たな仕様が出てくる
 ソースコードを見ながら探す
  具体例有り
   ソースコードを解析する
   発見した変更すべき箇所を変更要求の下に書き出す
    すぐにソースを修正しない!

変更仕様はグループ化すると分かりやすい
 抽出された変更仕様が色んな箇所に散らばる場合、グループ化する
 要求仕様:関数の仕様=1:N
  XDDPは、ソースコードの変更は、仕様変更と捉える
  
 変更要求の要求仕様でよい
  そのままソース修正できる
 要求仕様をさらにばらす
  関数レベルの仕様まで落とす

機能追加は、2種類の要求仕様書で対応
 追加要求仕様書
 変更要求仕様書

移植は2段階の変更が必要
 移植元での変更要求
  移植先の状況に合わせるための調整作業
 移植先での変更要求
  インターフェイスを合わせる

保守性
 機能追加
  保守性の要求仕様を作る
 変更
  劣化を防止するのが目的
  保守性はアップできない

BeforeとAfterの差が見積もりの根拠
 工数が出る

TMを介して変更要求仕様書と変更設計書をつなぐ
 行:変更要求、仕様→What
 列:機能、担当者など
 交差点:変更設計書→How
 →TMでWhereを表現する

変更設計書は変更点だけ
 本当の設計書ではない

正式文書はテスト後にマージする
 公式文書の修正は短期間に行う
  工数は確保されている
 並行開発や五月雨開発が可能になる

ソースコードは一気に変更する
 4ヶ月前に取り掛かった時と、4ヶ月調査して設計した後は状況が異なる
 プログラミングを単純な変換プロセスにする
  生産性が高い

バグの原因解析で3点セットが役立つ
 派生開発では、バグは今回変更した箇所に存在する
  変更箇所は全て、変更設計書に書かれている
  範囲が絞られる

一人プロジェクトの問題を回避できる
 3点セットがあるから、レビューしやすい


XDDPで生産性向上
 ヒントはソースコード変更の生産性にある
 80~130行/時間 も可能
 設計に時間を費やして、プログラミングの作業時間を減らす

XDDPは、要求の発見よりも要求の表現方法に着目する
 仕様漏れや要件漏れは、仕様化プロセスで発生している
 設計プロセスの品質が悪いから

五月雨開発や並行開発が可能
 trunkの閉鎖期間が短い
  一般の開発では、ソースの変更期間が長いために、実現できない
 3点セットによって、変更箇所が公開されている

彼女の表情が優しくなった
 3点セットでレビューしやすくなった

仕様変更率を5%以下を目指す
 仕様にまつわる問題が消える
 要件管理もスムーズになる
→CMMIのアセスメントが可能

2種類の生産性を出す
 今回生成したLOC/全体工数
 今回生成したLOC/実装工程の工数

SDSが派生開発の邪魔をする
 組織標準
  新規開発用
 派生開発にXDDPを入れると、SDSを変更する必要性がある

仕様担当Gがガン
 XDDPでは、仕様担当Gの作業は、最初と最後だけ
  追加/変更要求仕様書を作る
  公式文書へマージする

不当支援を禁止する
 XDDPは早く終わる
 ブブカ方式
  1センチだけ高く飛んで世界新記録
  創造的無能を装う

【感想】
1・XDDPの良い所は、現場で鍛えられた理論であること。
 経験に裏打ちされている。
 CMMIは上からの開発プロセスだから、現場とマッチしない部分がある。
 要求開発も同様で、内容は素晴らしいかもしれないが、現場では使いづらい。
 実際の現場は、新規開発と派生開発の2種類を暗黙的に使い分けているはず。

2・「ドキュメント修正やソース修正はギリギリまで行わない」意味は、trunkに中途半端なコミットはしない、ということ。
 trunkへ中途半端な修正を入れると、品質が劣化するから。
 だから、タスクブランチを上手に使う。
 「テスト終了後、ソースとドキュメントを一気にマージする」意味は、タスクブランチの作業が完了したタイミングで、trunkへマージする、ということ。

3・追加と変更のプロセスは並行開発であること。
 つまり、trunkから2本(機能追加、変更)のタスクブランチを作る。
 既存の開発と混乱しないと言う理由は、trunkとタスクブランチを分けているから。

 XDDPがアジャイル開発のように思えるのは、並行開発だから。
 並行開発なので自然にアジャイル開発っぽくなる。
 但し、イテレーションを意識しないので、厳密にはアジャイル開発とは言えない。

4・変更要求←TM→変更設計書→ソースコード でトレーサビリティを実現している。
 つまり、ソースから変更要求まで探すことができる。
 だから、運用保守に強いプロセスになって入る。

5・一人プロジェクトはペアプロで回避できないか?

6・XDDPは非常に面白いのに分かりにくい部分がある。何故か?
 trunkとbranchの違いが明確にされていない。
 実際の運用は、区別されているはずだ。
 変更と追加の2本のタスクブランチ上で作業しているはず。
 構成管理で整理していないので、分かりにくい部分がある。

 XDDPの特徴は、運用保守に強い並行開発。
 並行開発だから、アジャイル開発と相性がいい。
 上流工程の設計プロセスを凄く重視した開発スタイル。
 すごく勉強になった。

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

2009/09/08

SVNリポジトリの管理方法の追記

SVNリポジトリの管理方法」の記事に関して、良い情報があったのでメモ。

【元ネタ】
ブランチの管理

ベンダブランチの管理方法 - miauの避難所

ベンダブランチ

(前略)
リポジトリがただ一つのプロジェクトを含む場合には しばしば、この三つのディレクトリ(trunk/branches/tag)をリポジトリ最上位に作ります。
リポジトリが複数プロジェクトを含む場合は、プロジェクトごとに レイアウトをインデックス化します。
(後略)

srcとdocフォルダをどのように配置するか?という問題は、一つのリポジトリとして扱うか、別々のリポジトリとして扱うのか、という問題に置き換えられる。
普通の受託開発・パッケージ製品の開発では、ソースコードとドキュメントを納品するタイミングは同じなので、一つのリポジトリとみなした方がいいだろう。

しかし、サードパーティのライブラリのように、ライフサイクルが異なる場合は、別リポジトリとして扱った方がいい。
上記の記事では、「ベンダブランチ」という名前で説明してあり、非常に参考になった。

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

TestLinkの運用例part2

allpair法をTestLinkに使う方法が書かれた記事があったのでメモ。

【元ネタ】
TestLinkメモ - 科学と非科学の迷宮

AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb - Rubyの魔神 - はてな?Rubyグループ

allpair法は、組み合わせテストのテストケース作成技法の一つで、同じ値のペアが最低1回現れるように組み合わせてテストケースを作成する方法。
直交表に比べると、テストケース数を少なくできる。

実際のテストケース作成時は、複数の入力項目の組合せテストが非常に多い。
例えば、組込製品やパッケージ製品ならば、ドライバやOSのバージョンを組み合わせたテストケースを作っているだろう。
業務システムならば、業務のパターンや状態を組み合わせてテストケースを作りこんでいるだろう。

実際の現場では、直交表からテストケースを作ると、ケース数が爆発してしまい、限られた工数ではテストできない時が多い。
その時に、直交表よりもallpair法を使えば、少ないテストケースでたくさんのバグを見つけることができるはず。

TestLinkのテストケースへ出力する方法は、garyoさんが作ったRubyスクリプトを使うのが一番よいだろう。
僕は実際に使ったことがない(使いこなせなかった)が、上記の方は実際に試されているので非常に参考になる。

TestLinkでテスト工程をマネジメントする場合、インプットのデータであるテストケースの品質が一番重要だ。
テストケースの品質が悪く、テストケースの粒度にばらつきがあったり、テストケースそのものに間違いや仕様漏れがあると、TestLinkを使う利点が半減する。
実際、TestLinkの要件カバレッジを使ってみると、テストケースに紐づかない要件がよくあるので、要件漏れが頻繁に発生している時が多い。
すると、テストしていない要件、機能があるため、そこから潜在バグになる危険がある。

結合テスト以降のテスト仕様書は、Excel上で仕様書を見ながらテストケースを増幅して作る時が多く、非常に工数がかかる。

TestLinkを運用するようになって、テストケースはTestLinkのマスタデータなのだ、と思うようになった。
マスタデータが狂っていると、TestLinkでいくらテスト管理を頑張っても効果は半減する。
テスト仕様書は設計書を書いているのと同じレベルなのだ。
だから、テスト仕様書をきちんとレビューしてもらい、間違いや漏れをなくすのが大事だ。

TestLinkが運用しづらい原因の一つは、テストケースと言うマスタデータを作りこむのが大変だという点もあると思う。
テストケース作成技術は、プログラミング技術とは異なる別個の重要な技術なのだ。

| | コメント (2)

2009/09/07

チケット駆動開発のベストプラクティスを収集したい

チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。
理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。

僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。
但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。

1・チケット・ファースト(Ticket First)

【説明】
基本は、プロジェクトの作業はチケットを受け取ってから始める。
チケット無しで作業はしない。
また、SVNコミット時に、チケット無しのコミットも不可。

【効用】
チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。
進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアルタイムに進捗情報を出力できる。

また、ソースや設計書などSVN管理下の成果物はチケットと連携しているので、作業の発生源と成果物のトレーサビリティを保障できる。
これによって、運用保守時にパッチの修正理由を探しやすい。
更に、ソースからリバースエンジニアリングする際に、チケットから仕様や要件を作りやすくなる。

BTSとバージョン管理の連携は、Redmine・Trac・Mantis・Jiraなど殆どのBTSで実現できる。

2・チケットで分割統治(Divide and Conquer)

【説明】
複雑なタスク、工数がかかるタスク、遅延したタスクは、追跡可能なタスクまでチケットの粒度を細分化する。
それらチケットを、リリースするバージョン毎にグループ化してまとめる。

【効用】
プログラミング作法の分割統治の概念をタスク管理にも応用する。
つまり、責務の多いクラスは結合度や凝集度の観点で分割するように、担当者一人に責務が集中して進捗が滞りやすいタスクは、分割統治を行い、チケットへばらす。

細分化されたチケットは、イテレーション計画又は、スパンの長いリリース計画に基づいて、どのバージョンでリリースするかという観点でグループ化する。
バージョンをXPのイテレーションに相当するように運用すれば、自然にアジャイル開発になる。

3・小規模リリース(Small Releases)

【説明】
バージョン毎に小さく作って小刻みにリリースする。
リリース結果は終了チケットの履歴として残る。

【効用】
XPの小規模リリースのプラクティスと同じで、チケット駆動開発はその実装プロセスになる。
リリース予定のバージョンと関連チケットの一覧は、BTSのロードマップ機能として表示できる。

そして、リリースしたバージョン、終了したチケットは、そのままリリース履歴として残る運用になる。
RedmineやMantisには、ロードマップと変更履歴(リリース履歴)が機能として存在しているので、自然に小規模リリースを運用できる。

4・ふりかえり(Retrospect)

【説明】
チケット集計結果からワークフローの運用などを次バージョンで改善する。

【効用】
バージョンをXPのイテレーションのように扱うと、自然にアジャイル開発で運用でき、イテレーションの開発リズムが生まれる。
イテレーションをリリースし終えたら、開発チームでKPTでふりかえりを行ってみよう。

バグが多く出たのは何故か?
特定の作業がやりづらかった理由は、ワークフローが現状と合っていないのではないか?
チケットの属性を、開発の現状に合わせて増やしたり削るべきではないか?

など色んな問題点、そして次のイテレーションで試したい事が出てくるはずだ。
このふりかえりプラクティスは、PDCAサイクルのCheck(評価)とAction(対策)に相当する重要なプロセスだ。
このプラクティスが上手く回れば、自然にプロセス改善できる。

でも、この4個だけで十分なのか、正直、自信は無い。
他人の運用例なども聞きながら、オブジェクト指向のデザインパターンのように、現場で役立つベストプラクティス集を作り上げたい。

【補足】
Shibuya.trac第4.5回勉強会~チケット駆動開発とTestLinkによる開発プロセスの改善~で、Shibuya.trac有志の方のおかげで、「TiDDのふりかえり」というパネルディスカッションを開くことになりました。
内容は、Redmine/Trac/Mantisでチケット駆動開発を実践した経験を、KPTの観点でパネラーがふりかえるものです。

そこで、勉強会の参加者からもパネラーへ質問したい内容を募集しています。
興味ある方は、Shibuya.trac第4.5回勉強会~チケット駆動開発とTestLinkによる開発プロセスの改善~のWikiへ直接書き込んで下さい。

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

2009/09/06

入門Mercurialの感想

Mercurial本「入門Mercurial Linux/Windows対応」の著者フジワラさんから献本して頂いたので感想をメモ。

【元ネタ】
Mercurial の利用

特集:Mercurialではじめる分散構成管理|gihyo.jp … 技術評論社

スィンプロ (sinproject) Windows Vista 環境で TortoiseHG(Mercurial)を利用してバージョン管理とバックアップを行う (3)

ダウンロード - TortoiseHg - SourceForge.JP

入門Mercurial Linux/Windows対応」は分散バージョン管理Mercurialの入門本。
平易に書かれていてとても読みやすい。
また、Mercurialのコマンド一覧が付録にあるので、リファレンスとしても使える。

エピローグに「あ!構成管理って楽しいんだ?!」という節がある。
MercurialはCVSやSubversionと違って、オフラインのノートPCでも共有リポジトリと関係なくバージョン管理できるおかげで、コミットがすごく楽しかった。
ついに自由を獲得できた、と思った。

そして、構成管理にまつわる問題の本質は、「構成管理が面倒」であることではなく「面倒なツールで構成管理をしていたこと」に気付いた。
そのおかげで、構成管理が楽しい!と思うようになった、とのこと。

経験談としてすごく納得できる。
僕も、TortoiseHgを使い始めて、オフラインのノートPCで簡単にバージョン管理でき、外付けHDにバックアップ代わりにミラーリングできるようになった。
更に、Redmine+TortoiseHgでプライベートなタスク管理が簡単にできあがった。
だから、作業がすごく楽しくなった。

優れたツールが開発のあり方まで変えてしまう。
ツールがプロセスを改善する。
優れた技術力こそが、SW開発が抱える諸問題の難易度を下げて、一つずつ解決の方向へ進めさせてくれる。

| | コメント (2)

SVNリポジトリの管理方法

かおるんさんの記事のコメントで、誤った意見を書いてしまったので修正しておく。

【元ネタ】
Subversion のフォルダ構成 - かおるんダイアリー

Subversionのフォルダ構成 | Ryuzee.com

Subversionで簡単・確実にファイルを構成管理 - @IT自分戦略研究所

InfoQ: 複数のアジャイルチームでのバージョン管理

【問題】
SVN直下のディレクトリは、branch/tag/trunkになっている。
ソースやドキュメントはどこに配置すべきか?


【結論】
管理したい一つのまとまり(プロジェクト)単位で、trunk/branch/tag を作った方がブランチを管理しやすいと思っていた。
最初はtrunkの中にソースやら仕様書を配置して、管理方法がよく分からなかった。

でも、さかばさんと議論してみて、ryuzeeさんのやり方が良いと思う。
思い出してみたら、下記の方法で僕も運用していた。

root.
├─branches
│ ├─1.0
│ │ └─src

├─tags
│ ├─1.0
│ │ ├─doc
│ │ ├─src
│ │ └─tools
│ ├─1.1
│ │ └─src
│ ├─2.0
│ │ ├─doc
│ │ ├─src
│ │ └─tools

├─trunk
│ ├─doc
│ ├─src
│ └─tools

基本的な考え方は「InfoQ: 複数のアジャイルチームでのバージョン管理」に従えばいい。

【方針】
1・基本は、trunkにソースやドキュメント、ツールなどのフォルダを作り、それぞれを管理する。
PGやPLは、ソース修正やドキュメント修正は、trunkへコミットして、常に最新の状態にする。

2・新規開発中のtrunkからリリースする場合、trunkからtagを作り、tagにはリリースするバージョン(例:1.0, 2.0)を命名する。
この時、ソースだけでなくドキュメントもtagのバージョンに入れる。

更に、trunkからbranchにリリースバージョン(例:1.0, 2.0)を作り、本番運用中のソースは別管理とする。
ドキュメントは最新版だけあればよいプロジェクトだったから、branchには入れない。

3・本番運用中のbranchからリリースする場合、branchからtagを作り、tagにはリリースするバージョン(例:1.1)を命名する。

【注意点】
一つは、基本は、tagにはtrunkにある全ディレクトリにバージョンを付けること。
理由は、tagのバージョンがtrunkのスナップショットだから。
実際、リリース時はソースだけでなくドキュメントも一括納品しているからだ。

もう一つは、branchには派生開発する対象のディレクトリをtrunkから分岐させること。
このやり方はいわゆるメインラインモデル。
trunkは新規開発、branchは本番運用に分けて管理する手法。
僕の場合、ドキュメントは最新版だけあればよかったからbranchに入れないが、SWプロダクトラインのように製品ファミリー単位でドキュメントも管理する必要がある場合、branchに入れた方がいいかもしれない。

branchを作ると、必ずbranch→trunkへマージ作業が発生する。
ソースというテキストファイルなら作業しやすいが、ExcelやWordは正直作業しづらい。
但し、TortoiseSVNならOfficeの差分比較ができるので、マージ作業の難易度は下がっている。

つまり、trunkに成果物を全て配置するやり方がよいと思う。
その理由は、「Subversionのフォルダ構成 | Ryuzee.com」で詳しく書かれている。

実際、trunk/tag/branchに含まれないフォルダは、最新版なのか古いのか分からないからだ。

Subversionで簡単・確実にファイルを構成管理 - @IT自分戦略研究所」の記事も読み合わせると、ドキュメントもソースと同じライフサイクルで管理した方が良いと思う。
理由は、ドキュメントをリリースするタイミングはソースをリリースするタイミングと同じだからだ。
普通は、システム納品と同時にマニュアルや設計書というドキュメントも納品しているはずだ。
つまり、trunk直下にドキュメントとソースを配置した方がライフサイクルを管理しやすい。

SVNだけでなく他のバージョン管理でも同様の発想をすればいいだろうと思う。

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

2009/09/05

Redmine+Mercurialの設定方法

RedmineとMercurialの連携の設定をメモ。

【元ネタ】
RedmineでMercurialを使う方法 - 床のトルストイ、ゲイとするとのこと

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

All In One Redmineを見つけた: プログラマの思索


Windows+Redmine0.8.4+ToroiseHg0.8.1では2箇所でエラーが発生する。
修正方法は下記の通り。

【修正対象】
lib/redmine/scm/adapters/mercurial_adapter.rb

【修正箇所】
L27
HG_BIN = "C:/Program Files/TortoiseHg/hg.exe"

L40
theversion = "1.3.1"

L27では、元来Unix上のHgのパスをTortoiseHgのパスへ変更する。

L40では、MercuiralのバージョンをTortoiseHgのMercurialのそれに直す。
ソース上では、「hg --version」コマンドを発行してMercurialのバージョンを正規表現で取得しようとするが、TortoiseHgを日本語化した場合、バージョンがヒットしないから。

これによって、Redmine+TortoiseHgで、ローカルPC上の成果物を管理できる。
TortoiseHgなら、ローカルPC上のリポジトリを他マシンのリポジトリへ簡単にミラーリングできる。
つまり、「hg push」「hg pull」によってリポジトリを更新する作業をバックアップ作業代わりに使える。
更にWinMerge+xdocdiff WinMerge Pluginを使えば、ExcelやWord、PowerPointの差分比較も可能だ。

Redmineはデフォルトで、MercurialやGit、Darcsにも対応していて、更にリモートSCMにも対応しているから使いやすい。
SVNと同様に、コミットログにチケットNoを書けば、チケットNoとMercurialリビジョンが相互リンクするから、ローカルPC上でもトレーサビリティを実現できる。

従って、ローカルPC上のRedmine+TortoiseHgによって、テキストだけでなくOfficeのバージョン管理とタスク管理を一括管理できるようになる。

以前に比べると、タスク管理やバージョン管理のツールがお手軽に揃ってきた。
現在、プロジェクト管理の手法が劇的に変わるポテンシャルが出てきているように思う。

| | コメント (0)

2009/09/04

チケット駆動開発とアジャイル開発の密接な関連

平鍋さんのコメントに対して回答してみる。

【平鍋さんのコメント】
アジャイルやPFの具体的かつ実践的な回し方、として期待しています。
PF のプラクティスとの相関を一枚で描いてもらえませんか?
僕のスライドで紹介したいです。

【回答】

上記のように、TiDDとXPの開発サイクルを対比したイメージを強引に書いてみた。

これでイメージが湧くでしょうか??

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

2009/09/03

チケット駆動開発を日本発のアジャイル開発へ発展させるには?


さかばさんの記事を読んで考えたことをメモ。

【元ネタ】
[TiDD] 小規模開発の難しさを考える: ソフトウェアさかば

チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07)

アジャイル開発は元来、小規模で変化の激しいプロジェクトが向いていると言われてきた。
しかし、XPが出現して10年も経つというのに、現場の実践例は非常に少ない。
ネット上でアジャイル開発の情報がこれだけ溢れていて、開発者も興味を持っているのに、事例になかなかお目にかからない。
情報処理試験の勉強でも、プロセス改善のセミナーでも、繰り返し型開発の重要性が叫ばれているのに、事例は非常に少ない。

その原因は、単純にアジャイル開発を実践できる技術力が足りないからだと思っている。
テスト駆動開発を実践するには、JUnitを使いこなさねばならない。
常時統合するには、Hudsonのようなビルド管理ツールが必須だ。
そして、イテレーション単位に頻繁にリリースするには、頻繁に変わるタスク管理を制御しなくてはならない。

アジャイル開発の最大の特徴は、超短期間の繰り返し型開発だ。
頻繁にリリースできる技術力、プロジェクト管理能力があるからこそ、スコープ・コスト・納期の三角形でプロジェクトマネジメントを行えるのだ。
頻繁にリリースしても品質を維持できる技術力がなければ、スコープを制御することは事実上不可能だ。

そして、チケット駆動開発は、まちゅさんがTracのチケット管理をタスク管理に使った所から生まれた。
更に、僕は、アジャイル開発のタスク管理にチケット駆動開発を適用することで、アジャイル開発が非常にスムーズに運用できた経験をした。
それは単に繰り返し型開発ができただけの意味ではない。
イテレーションと言うリズムがあるからこそ、現場リーダーが優先順位付けマシンになり、朝会で各自がタスクを確認し合い、リリース後にKPTでふりかえる雰囲気が開発チームに生まれた。

チケット駆動開発のインフラのおかげで、アジャイル開発がスムーズに運用できて、チーム内に変化が起きて、チームが成長する螺旋構造が生まれた。

そのチケット駆動開発は、BTSという従来のツールを駆使する。
僕の数少ない経験では、RedmineでもTracでもMantisでもチケット駆動開発は運用可能だ。

その中でもRedmineが最もアジャイル開発しやすい理由は、一目で進捗が分かるロードマップ機能と柔軟なワークフロー管理機能の2点にあると思う。

ロードマップこそがXPのイテレーション計画であり、Scrumのスプリントバックログへ適用できるのが一番の肝だ。
そして、リリース後は終了したロードマップはリリース履歴になる。

更に、柔軟なワークフロー管理機能のおかげで、バグ修正だけでなく、インシデント管理や課題管理などSW開発の全てのワークフローをBTS上へのせることができる。
特に、BTSチケットをバグ修正だけでなく仕様変更にも使うことをIssueTrackingと呼ぶ。
これはチケット駆動開発でもすごく重要な機能だ。

このチケット駆動開発を、たくさんの人の事例をプラクティスへ濃縮させて、日本発のアジャイル開発までブラッシュアップしたい。

日本のアジャイラーの第1人者の平鍋さんは、XPから始めて、プロジェクトファシリテーション(PF)を編み出した。
PFのアイデアの影響力はものすごく大きくて、色んな人が知的刺激を受けて、関東や関西、九州でPFPコミュニティが生まれた。
同様に、チケット駆動開発が実際の現場で働く人に刺激を与えて、良い方向に進められればと思う。

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

« 2009年8月 | トップページ | 2009年10月 »