garyoさんから、ソースの複雑度と単体テストケース数について有益なアドバイスを示唆してもらったので、メモしておく。 ◆SourceMonitor Version 2.4 SourceMonitorはフリーで、以下の言語のソースのソフトウェア複雑度（McCabeのサイクロマチック数）を測定できる。 例：C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML ◆McCabe's cyclomatic complexity SourceMonitorで求められる複雑度（McCabeのサイクロマチック数）は、モジュール内の分岐の数（＋ループの数）で計算される。 複雑度の数値は、下記の意味を持つらしい。 10 以下であればよい構造 30 を越える場合，構造に疑問 50 を越える場合，テストが不可能 75 を越える場合，いかなる変更も

「継続的インテグレーション入門」を読んでみて、もっと早く読んでおけば良かったと後悔した。 内容がとても素晴らしかったので、理解できたことをラフなメモ書き。 【元ネタ】 Togetter - 「SIerは自動化する対象が違っているのでは？」 Continuous Deliveryをポチッた - watawata日記 Continuous Delivery - haru01のめも アジャイルなインフラのつくり方とデータマネジメント - メソッド屋の日記 インフラやデータ移行の自動化～アジャイル開発の最後の問題: プログラマの思索 Continuous Delivery～TDDとCIの次に現れた自動化の概念: プログラマの思索 【1】「はじめに」に、キーボードに「Integrate」というボタンが貼られていて「こんなに簡単ならいいのに」という雑誌の広告から始まる。 この挿話は、ビルド＆デプロイの

XPのプラクティスの一つが常時統合(CI・Continuous Integration)。 別名、デイリービルドと言われる。 第2世代CIツールと言われるHudsonを使って運用して、常時統合の概念について改めて書く。 #Hudsonの全機能はまだ使いこなせてないので念のため。 【1】バージョン管理(SCM)＋常時統合(CI)＋テスト駆動開発(TDD)で、初めてアジャイル開発が可能になる 【元ネタ】 バージョン管理と常時結合 豆蔵：継続的インテグレーション（CI）をしましょう Subversionでbranches/tags/trunkでソース管理したら、次に行うべき環境構築はビルド環境。 Javaなら、Ant/Mavenでワンクリックでビルドできるようにスクリプトを作る。 今でもビルドする時に、Eclipseから手作業でビルドしているプロジェクトもままある。 ローカルマシンで手作業でビル

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所で書ききれなかったテスト手法の概念についてメモ。 【元ネタ】 脱Excel！ TestLinkでアジャイルにテストをする － ＠IT自分戦略研究所 TestLinkを運用して気付いたことpart8～みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索 TestLinkを運用して気付いたことpart9～後追いテスト: プログラマの思索 下記の資料にまとめてみた。 ちなみに下記のテスト用語(方言？)はTEF関西のNakaさんから教わった。 【1】ブロック、ブロッキングバグ、みなしバグ、みなしOK、周辺テストの概念 上記1枚目で、Ver2.0のカート削除1のテストケースでテストに「失敗」したとしよう。 その場合、カート削除2のテストは、カート削除1のバグに依存して必ず失敗するから、

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

先週、TestLinkのメーリングリストで、コミッタの川西さんとTestLinkのUI改善や運用方法について熱く議論した。 その議論で考えたことについて書いてみる。 【参考】 TestLinkJP - TEF有志によるテスト管理システムTestLink日本語化プロジェクト TEF有志によるTestLink日本語化プロジェクト - TestLink日本語版で始めるテスト管理システム(簡易マニュアル) 僕はTestLinkを3ヶ月運用してみて、Redmineと同様にTestLinkは僕のプロジェクト運営に欠かせないツールになった。 僕のチームでさえも、単体～システムテストのケース数は数千オーダー。 もはやExcelのテスト仕様書で管理するのは非現実的。 しかし、テスト工程をExcelで管理しているプロジェクトが殆どで、どのプロジェクトも結合テスト以降の開発に苦労している。 特に、テストでNGと

TestLinkを運用する時の設定メモ。 TestLinkはRedmine以上に癖が多く、デフォルト機能のままではすごく使い辛い。 大人数でテストケースを厳格に管理しようとして、逆に使い辛くなっているから、基本は制限を緩めた方が使いやすいと思う。 #八朔さんへの援護射撃になるかな？ 【環境】 TestLink 1.7.4 【1】RedmineとTestLinkの連係 TestLinkテストケースが失敗になったら、バグ登録する。 この時、BTSと連携する重要な機能。 Mantis、Bugzilla、Trac、Redmineが連携可能だ。 BTSのURLを設定するだけでOK。 この機能を使うと、テスト実行画面で「失敗」ケースのバグアイコンからバグ管理IDを登録すれば、BTSのチケットへリンクできる。 更に、テスト結果画面にある「失敗したテストケース一覧」リンクから、NGケースとRedmineの

昨日、ＸＰ祭り関西２０１０が無事に終了した。 多分150人近い参加者だったと思うので、大成功だった。 東京から長瀬さん、AgileJapanのebackyさんやミルズさん、日経BPの井上さん、XPJUGの倉貫さん、岡山からてつさん、福井から岡島さん。 東京や名古屋など遠方から結構な数の人が来てくれた。 関西はアジャイル開発のマーケットが十分にある手応えを感じた。 チケット駆動開発セッションも、懇親会で感想を聞くと評判が良かったみたい。 TiDDの事例や試行錯誤を聞けて興味深かったらしい。 実際にBTSを使っている人もいれば、今から試そうとしている人もいて、色んな観点で聞いていたようだ。 僕はWeb系開発でRedmine、さかばさんはパッケージ製品開発でTrac、小枝さんは組込製品開発でManitsを使って、TiDDを実践した事例を三者三様で話した。 僕も、二人の話は既に聞いていたけど、改め

パッケージ製品開発でTracをシステムテストで使った時に、TiDDを導入した話で非常に参考になる。 興味深い点は2つ。 一つは、TiDDを適用した工程をシステムテストに限定したこと。 懇親会でも質問を受けたけれど、プロジェクトでいきなり全ての作業をチケットで管理する運用は難しい場合もある。 その場合は、まず障害管理の一つのツールとして導入して、テスト工程をコントロールするのに注力すればいいと思う。 昨今の開発でBTS無しでバグを管理するのは非常に難しいからだ。 また、バグ管理の運用にメンバーが慣れれば、開発の作業や問合せもチケットで管理したくなってくるだろう。 もう一つは、TiDDを導入したら、開発チームの風通しが良くなり、メンバーが自発的になってきたこと。 バグや技術ノウハウの情報がBTSに一元化されるので、コミュニケーションの材料になる。 更に、チケットをToDo管理のように扱えば、忘

業務システムの要件を定義して設計する手法は、プログラミング手法とは大きく異なる。 プログラミングはオブジェクト指向がベストプラクティスだが、要件定義や設計の手法は日本独自のDOA(データモデリング)の方がやりやすいような気がしている。 特にRailsという優れたWebフレームワークが出現して、データモデリングの重要性が増してきたように思う。 理由は、テーブル設計さえできれば、マイグレーション機能によってDBスキーマを一発で生成できるし、scafold機能によってテーブルのCRUD画面はあっという間に実装できるからだ。 つまり、テーブルさえ作れれば、業務システムをWeb上で動かして簡単に理解できるようになってきた現状があるからだ。 僕が今まで読んできた本の中で、自分が役に立ったと思う本を列挙しておく。 【1】グラス片手にデータベース設計編 グラス片手にデータベース設計~販売管理システム編 (

TestLinkでテストケースを作りこんで、テストしていくと、色んなことに気付く。 TestLinkでテストしていきながら感じたことをメモ。 【1】ウォーターフォール型開発では、下流工程にテストが来る。 単体テスト、結合テスト、システムテスト(総合テスト)、受入テストの違いをきちんと使い分けているだろうか？ テストは基本的に、V字モデルの左側の工程の検証作業になる。 単体テストは開発工程の検証だが、結合テストの違いは何だろうか？ 単体テストは、最低限動作することを保証すること。 Exceptionが発生するようでは話にならない。 ホワイトボックステストで、最低限、分岐網羅(C1)を検証する。 だから、コードカバレッジが非常に重要になる。 結合テストは、複数のモジュール同士を結合して動作するのを検証する。 普通のプロジェクトでは、結合テストで火を噴くことが多い。 理由は、結合テストになって初

ETWest2009の講演資料「TestLinkでアジャイルにテストする」を公開します。 CC Attribution ライセンスとします。 上記の講演で、TestLinkを半年間運用してみて、経験したこと、理解できたこと、そして確信したことは全て書いた。 一番言いたい事は、TestLinkがアジャイル開発の弱点の一つである受入テストを補強してくれることだ。 テスト駆動開発や継続的インテグレーションのプラクティスで単体テストの品質は保証できるが、結合～受入テストの品質を確保するのは、ウォーターフォール型開発だけでなくアジャイル開発でも難しい。 その問題の本質は、二つある。 一つは、受入テストの自動化は難しいこと。 もう一つは、手動の受入テストの生産性が悪いこと。 TestLinkの導入によって、手動の受入テストを効率化できると確信している。 だが最終的な目標である受入テストの自動化は、Te

TestLinkはオープンソースのWebのテスト管理ツール。 TestLinkがExcelのテスト仕様書よりも素晴らしい点を書く。 【0】インストールが超簡単 XAMP＋TestLinkが一体化されたパッケージがある。 解凍して起動するだけ。 USBメモリに入れて持ち歩くことさえできる。 【1】テストケースを再利用しやすい シナリオベースのテストケースは、運用保守や2次開発でも頻繁に使う。 実際は、1次開発で使ったテストケースを複製して、仕様変更や追加機能を反映させる。 この時、Excelのテスト仕様書から該当のテストケースを抽出したり、変更するのに手間がかかる。 また、テストケースは書く人によって、粒度や書式が大きく異なる時が多い。 後の保守で再利用できなかったりする。 TestLinkの場合、テストケースはDBにあるから複製が簡単。 また、TestLinkの入力フォーマットが固定されて

昔、XPlannerというXPのアイデアを実現したWebアプリがあった。 そのソフトは、XPのタスクカード単位で進捗管理できるのがウリだった。 でも、正直使い勝手は良くなかった。 そして、最近、Redmineを触って初めて、XPを実現できそうなプロジェクト管理ツールだと直感した。 Redmineによるチケット駆動開発のアイデアをまとめてみる。 【1】Redmineの特徴は、プロジェクトの進捗の可視化 Redmineの最大の特徴は、ガントチャート。 チケットに作業内容と開始日、終了日を入れると、すぐにガントチャートが出来上がる。 これを初めて見た時は感動した。 プロジェクトリーダーは、ガントチャートを作って保守するために、殆どの時間を費やしている。 WBSさえ作って入力すれば、ガントチャートを自動生成してくれるのだ！ 他に、カレンダーもある。 開発時だけでなく、運用保守時にリリースする日やD

ソース管理について良い記事があったのでメモ。 Subversionベストプラクティス 複数のアジャイルチームでのバージョン管理 「複数のアジャイルチームでのバージョン管理」の指摘は非常に重要なので、まとめておく。 【1】バージョン管理の目的 1-1. Fail First コードのコンフリクトや統合の問題を早期に解決する。 1-2. 常にリリース可能 どんなに悪いイテレーションでも、その成果物はリリース可能にならねばならない。 1-3. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が

「成功する要求仕様 失敗する要求仕様」ではトリアージの概念が説明されている。 つまり、システムを実現する要求は、納期やコスト、リソースの観点から優先順位付けして、高い優先順位から要求をまとめていくというもの。 ヨードンの「デスマーチ」でも、デスマーチプロジェクトから脱出する唯一の方法はトリアージを行うことだ、と書かれていた。 そもそもトリアージとは、救急医療の用語。 災害医療等において、有限のリソース(医師や医薬品など)を最大限に活用して、より多くの傷病者を治療するために、治療の優先順位を決定することを意味する。 Wikipediaによると、下記4個の色のついた診断書を傷病者の右手首に取り付ける。 ここでは、治療の優先順位は、赤→黄→緑→黒　の順番になる。 【黒 (Black Tag)】 死亡、もしくは救命に現況以上の救命資機材・人員を必要とし救命不可能なもの。 【赤 (Red Tag)