モックとスタブの違い
ひとつは状態の検査と、もう一方は振る舞いの検査の違い。
もうひとつは、テストと設計を同時にやるときの哲学の違い。











6-6.	テストケースを実装する手順
テストケースを準備した後は、粛々とテストを実施するだけですから、重要なのはどのようにテストケースを準備するかです。品質の良いソフトウェアを開発するためには、いきなりプログラムの実装を始めてはいけません。最初にきちんと計画と設計を行い、仕様書を記述する必要があります。これはテストを実装するときも同様です。そこで、ソフトウェア開発において記述しなければならない文書を順に紹介しましょう。図6 - 3を見てください。
 
図6 - 3 実行できないドキュメントを、実行(実施)可能な
ドキュメントに変換するプロセス
これは、あるソフトウェアに機能を追加するとき、その仕様を段階的に詳細化しながら実行可能なものに変換していく流れを示しています。実行可能なビルドを手にいれるには、ソースコード (プログラム) だけを記述すればいいように見えるかもしれませんが、そうは問屋が卸しません。インプットが何もなければソースコードを記述できませんし、そのアウトプット (ソースコード) の正しさを検証する仕組みも必要です。この前者の役割を担うのが仕様書であり、後者の役割を担うのがテストケースです。テストケース (マニュアルテストケースとオートメーションコード) も、ソースコードと同じく仕様書をインプットとして書くこと、またソースコードと同じく実行可能なドキュメントであることに注目してください。
みなさんは、電話帳を開いたことがあるはずです。あの分厚い電話帳に含まれる膨大な電話番号データは、なぜ入力ミスがほとんどないのでしょうか。これは、2人の入力オペレータが同じ番号を入力する作業を別々に行っているのだそうです。その後で2人の入力結果を突き合わせれば、数字が違うところを入力ミスとして検出できます。2人のオペレータが、同じ位置の数字を同じように間違える可能性は非常に低いからです。みなさんがインターネットのサービスを使うとき、アカウント作成時にはパスワードを2回入力することが求められますが、それと同じですね。
ビルドとテストケースの関係も、これと非常によく似ています。ビルドとテストケースは、お互いを突き合わせて、その妥当性を検証し合うというわけです。もし開発初期の段階に実施したテストがすべて成功したら、危険信号です。テストに成功したということは、バグを発見することに失敗したということだからです。そんな時期にビルドの品質が良いということは考えられませんから、テストの品質が悪かったとか、テストケースの数が不十分だったことを疑うべきです。
表6 - 3 テスト結果の評価
	最初に疑うべきは	次に疑うべきは
テストにパスした	テストの品質が悪い？	ビルドの品質が良い？
テストにフェイルした	ビルドの品質が悪い？	テストの品質も悪い？

次節から、図6 - 2に示した文書を簡単に説明しましょう。
6-7.	1ページ仕様書の記述
ある機能をソフトウェアに追加するときは、最初にプロジェクトリードもしくは開発者が1ページ仕様書(ワン・ページ・スペック)を書きます。ワン・ページと言っても、実際に1ページで書けることはあまりありませんが、多くても数ページ内に収めます。クイック・スペックということもあります。ソフトウェアは、いきなり実装しようとしてもうまくいかないのと同様に、いきなり設計しようとしてもうまくいきません。まず、その機能がユーザーにどのような価値を提供するのか、あるいはしないのか、機能の範囲(スコープ)を明確にする必要があります。そのために、新機能の仕様の概要を可能な限り短くまとめた仕様書を書きます。機能の規模にもよりますが、およそ数ページにまとめることができるはずです。このように、最初の仕様書には概要だけを記述すれば、その機能を少しずつ詳細化できます。この仕様書の項目としては、機能概要、この機能を追加する正当性 (追加するメリットやしない場合の影響)、設計とテストに対する要件、機能のゴールとノン・ゴールなどが適当です。この段階では、設計はしないことに注意してください。つまり、この機能をコンピュータで実現する手段は、ここでは考えません。ただし、次の段階へのインプットとして、設計に対する要件は書いておくと良いでしょう。例えば、こういう拡張性は考慮する必要はあるがああいう拡張性は考慮しないとか、これだけのパフォーマンスやスケーラビリティを確保する必要がある、などといったことです。この文書のドラフト版を書き終えたら、ほかの上級エンジニアにレビューを依頼します。必要なだけレビューサイクルを回してこの文書をコンプリートし、レビューが通ったら次の段階にすすみます。
ソフトウェアのドメインによっては、これをユーザーに持っていって提案することもあるでしょう。そのときは、ユースケース図を添付するなどして、1ページ仕様書をよりわかりやすく訴求力のあるものにします。また、見積もりについても言及の必要があるかもしれません。
このようなドキュメント書きのタスクも、5章で説明したBTSに登録して管理することがありますが、BTSに仕様書を直接書き込むことはしません。BTSの中にソースコードを直接書くことはしないのと同じです 。
6-8.	機能設計仕様書の記述
1ページ仕様書のレビューが通れば、次にその実装を担当する開発者が機能設計仕様書を書きます。ソフトウェアのドメインによっても記述すべき項目が変わってきますし、少々本書の範囲を超えますので、ここでは機能仕様書に適切と思われる項目の一例を示すにとどめます。機能の概要と詳細、この機能に対する要件や制約、設計のゴールとノン・ゴール、設計の詳細とアーキテクチャ、他の機能との依存関係、実装 (コードコンプリート) に必要な工数の見積もり、考えられるリスクなどがこの項目として適切です。
ただし、ここでは詳細すぎる設計には立ち入らないようにします。これには、設計仕様書を記述する対象の機能について、適切な粒度を選択することが大切です。細かい機能のそれぞれについて設計仕様書を起こすのではなく、関連した機能のグループについて1つの設計仕様書を起こすようにします。また、XPでは、紙上での設計を極端(エクストリーム)に避けており、リファクタリングを継続して行うことで紙上の設計を代替します。リファクタリングは、機能追加やバグの修正と同時には行えないことに注意してください。
機能設計仕様書がレビューにパスすれば、開発者はソースコードの記述を、QAはテスト設計仕様書の記述を開始できます。
6-9.	テスト設計仕様書の記述
テスト設計仕様書は、包括的で網羅的なテストケースを書くためのインプットになる文書です。これには、機能の概要、テストをする範囲としない範囲、テストに必要なリソース、テストの戦略、オートメーションコードの設計、テストケースの実装と実施に必要な工数の見積もりなどの項目を含めます。テストの戦略とは、どのようにテストケースを分類し、網羅性を確保するかということです。テスト設計仕様書のレビューには、機能設計仕様書を書いた開発者にも参加してもらうと良いでしょう。
6-10.	テストケースの記述
さて、ようやくテストケースの記述を開始できるところまでたどりつきました。テスト設計仕様書に基づいて、包括的かつ網羅的なテストケースを準備します。





すべてのマニュアルケースを、すべてのビルドに対して実施することは非現実的です。どのケースをどのビルドで実施していくか、うまく計画を立てましょう。


新規にソフトウェアを開発するときには、最初にソフトウェア開発計画書を書くべきですが、この図では割愛しています。また、ソフトウェアのドメインによっては、各文書の名称や内容が少しずつ違いますが、文書を詳細化する基本的な流れは同じです。

クラスとは
クラスとは、意味のあるデータ構造と、それを操作する手続きをひとまとめにしたもので、オブジェクト指向をサポートするプログラミング言語におけるプログラムの単位です。ひとつのクラスは、ひとつのプログラムファイルで実装することが一般的です。



 convention type covers naming, comments and format conventions. Here are a few examples :

Is there javadoc on public methods ? 
Is the project following Sun naming conventions ? 
Is the code written with a consistent format ? 


The bad practices type consists of well known behaviors that almost systematically lead to difficulties over time. Here are a few examples of bad practices :

Catching an exception without doing anything 
Having dead code 
Too many complex methods 
Direct use of implementations instead of interfaces 
Implementing the hashcode() method without the not equals(Object object) method 


Classes in the UI layer may not directly access the data object layer, or use classes in java.sql 
External systems may not access internal implementation classes (suffixed with ‘Impl’) 
One functional module may access another only through its API 
Only classes implementing interfaces in javax.ejb, and certain framework packages, may use the EJB APIs 



1. テストケースとは
テストケースとテストスクリプトの違いは後述？
テストケースの項目について説明
テストケースの状態遷移について説明



2. 網羅的なテストケース
マイヤーズの三角形
済み

3. テストケースの準備
テスト計画書からテストスクリプトまで


4. テストの実施
単体テストと統合テスト
統合テストはマニュアルテストとオートメーションに分かれる
マニュアルテストについて
テストケースの状態遷移


4. テストケース管理システム



5. 仮想化技術によるテスト環境
昨今は電子書籍リーダーが広がりを見せていますが、残念ながら日本語のコンテンツはまだ少ない状況です。そこで、本を自分でスキャナで取り込んで、コンテンツを自炊する人が増えているそうです。電子化した本をバーチャルな本棚にしまえば、もはや元の(紙の)本は物理的に所有する必要はありません。大量の本を処分すれば、奥さんにも喜ばれます。PCの仮想化技術も、これとよく似ています。つまり、物理的なPCを電子化し、複数の論理的なPC(仮想PC)として、これらをひとつの物理PCに入れて同時に稼動させるのがPCの仮想化技術です。ひと昔前は、デュアルブートとかマルチブートという技術がよく使われました。これはひとつの物理PCに複数のOSをインストールし、その物理PCの電源を入れたときにどのOSで起動するか選択できるようにするものです。しかし、マルチブートでは、ひとつのPCに複数のOSをインストールしても、同時に稼働できるOSはひとつだけです。PCの仮想化技術では、物理PCのリソース(CPUやメモリなど)が許す限り、いくつでも仮想PCを同時に稼働させることができます。また、稼働が不要な仮想PCの電源は切ることができます。物理PCのリソースが空いた分、ほかの仮想PCをセットアップして稼働させることができるのです。さらに、仮想PCの状態のスナップショットを撮ることができます。あるバグが再現できる環境を構築



6. オートメーション
テストハーネス、ドライバ、スタブ

7. ビルド環境との統合
単体テストと統合テストの区別
ビルドマシンでテストがfailしたときの手順


8. バグ報告票データベースとの連携
バグを発見したら起票する、
テストケースに基づかないテストによるバグ報告票を起票したら、逆にテストケースに転記する
などのトピック

9. まとめ
動的テスト以外のテストについて



また、ユーザーから報告されたバグの場合には、このID番号をユーザーに伝えることで、ユーザーに安心してもらえます。このID番号が振られていることは、きちんとバグがハンドルされ、追跡されていることを示すからです。




このIDを使って、このバグ報告票をほかのバグ報告票 (またはその他の文書)から参照できます。



ステアリングコミッティ
steering committee


図5 - 24を見て、課題報告票の総枚数はコントロールできないが、人的リソースの総人数はコントロールできるのではないかと思った読者もいるでしょう。しかし、プロジェクトの途中でプロジェクトメンバーの人数を増減させることはとても困難です。
かし、実際には人的リソースが足りなくなり、開発人数を増やしたくなることが多いものです。しかし、ほとんどの場合、これはうまくいきません。新しいメンバーをトレーニングし、キャッチアップしてもらうコストが必要になるからです。赤ちゃんが産まれるまでには10ヶ月かかるのであって、男の人が何人いても役には立ちません。同様に、開発スケジュールを圧縮するために人員を途中で追加投入しても役に立たないことが多いのです。


特に、コードフリーズが宣言された後、ユーザーリリースの直前にだけ実施するようにします。もし、このテストでバグを発見したら、それは修正しないままリリースすることも視野に入れて検討します。コードを修正しなければ、フルリグレッションテストを実施し直す必要もないからです。この判断については次節で説明します。

フルリグレッションテストを実施した後にコードを修正したら、フルリグレッションテストはもう一度最初からやり直しとなってしまいます。このような不幸を避けるには、フルリグレッションテストは



この項目とは別に、修正完了予定日(見積もり)を記入する項目を用意してもいいのですが、バグ修正の見積もりを正確に設定するのは難しいものです。

コードネームでぱっと思い出すのは、

＜1-2-3系＞
1-2-3 R3 - Godiva
1-2-3 R3J - Glico
1-2-3 Windows 1.0 - Rockport
1-2-3 Windows 1.1 - Spiegel
1-2-3 Windows 4 - Darwin
1-2-3/G Gemini
1-2-3/G2 Walden ※出荷されず
Improv 3 - Kraken ※出荷されず

＜Freelance系＞
Freelance 3 - Warhol
Freelance 3J - DaVinci
Freelance Windows - Remington

カレーはApproach Jでこれは小松さんに聞いたほうがいいですね。
VindalooとJalfreziがありましたが、
バージョンとの対応は覚えていません。

筆者は、[終了] という語には閉じるという意味が含まれないので、[開始]の対義語としては不適切と思いますが、これに代わる良い訳語を見つけられませんでした。Open/Closedを、開店/閉店のように訳せれば良いのですが。閉了や閉終、閉票などという語は手持ちの辞書に見つかりませんでした。もっとも、本書は理解を助けるために邦訳の語を載せましたが、私はBTSの運用でこのような日本語を使ったことはありません。みなさんの多くもそうだろうと思います。


2章
リリース前の最後のマイルストーンビルドで、すべての機能のコードコンプリート (実装完了) を宣言することを勧めます。コードコンプリート後は、最終ビルドをユーザーにリリースするまで新規機能の追加は行わず、バグの修正だけを行います。これは、安心して安定化 (Stabilization) の作業を行える重要な時期となります。

3章
表3 - 7 ブランチポリシーの一例
	開発ブランチ	保守ブランチ
ブランチの安定度	不安定	安定
コミットできる修正	新機能の追加、バグの修正	深刻なバグの修正のみ
ビルドの頻度	1日に何度でも	必要なときのみ
ブランチの所有者	製品開発チーム	製品保守チーム

メインラインを汚さずに、意欲的な実装の可能性を試したいとき
あなたは、大事に育ててきた製品をリポジトリ上に持っています。ここで、その製品のアーキテクチャをアグレッシブに作り変え、より強力にバージョンアップする計画が持ち上がりました。しかし、その変更はあまりにアグレッシブなので、失敗すると大事な製品を死滅においやりかねません。そこで、安定した製品をメインラインに残したまま、開発用のブランチを切ってそちらで試験的に実装します。このようなブランチを実験的ライン (experimental line) といいます。実験的ラインは、新しい実装のfeasibility(実現可能性)を検証するための場であり、その実験が終わればそのまま破棄されます。実験が素晴らしくうまくいけば、このブランチをそのままメインラインにマージしてもいいかもしれませんが、その場合それは実験的ラインではなく、通常の開発ラインだったということでしょう。




5章
表5 - 4に補足します。このビューは、開発作業の実績を表すとともに、ビルド計画も同時に表しています。例えば、先週にテストチームにリリースした最新のビルドの番号が#38であり、ビルド#39とビルド#40はそれぞれ来週と再来週にテストチームにリリースする計画であるとします。すると、表5 - 4の上半分 (build#38以前) は実績であり、下半分 (build#39以降) は計画ということになります。各バグについて、それぞれを担当する開発者がどのビルドで解決 (修正) できそうかの見通しを書き込んでもらえば、このような管理ができます。
そこで、今週リリースした最新のビルドの番号は何番か、来週にリリースするビルドの番号は何番か、それぞれのビルドの状態はどうなっているか、このようなビルド計画をチーム内で共通認識としておくことが重要となります。このため、BTSによっては、ビルドノート (リリースノート) を一緒にBTSに登録して、各ビルドの状態 (開発中やリリース済みなど) を追跡し、これをバグ報告票と関連づけておけるものもあります。ビルドの状態については、★図2-9を参照してください。

アサイン (Assign) とは、割り当てるという意味です。担当者のほか、プログラムでメモリを割り当てるときにもアサインという語を使います。

★★バグの追跡プロセスは、開発プロセスにおいて非常に重要なものです。実際に、バグの追跡プロセスをカスタマイズすることで、開発プロセスを改善できるほどです。このため、社内で使うBTSを自社開発するソフトウェア企業も多いようです。BTSのソースコードを持っていれば、そのBTSを自社の開発プロセスに合わせてカスタマイズできるからです。そのような BTS には、その企業のソフトウェア開発に関する知見やノウハウが詰まっているといえます。正直にいえば、私は業務ではオープンなBTSを使った経験がありません。これまでに私が所属した外資系のソフトウェア企業は、すべてインハウスのBTSを活用していました。しかし、もしみなさんが独自のBTSを持っていなくても、TracやJira, Redmine, Mantisなど、無償で利用できるオープンな BTS がたくさんあります。これらは十分なカスタマイズ機能も備えています。優れたBTSを使うと、ソフトウェア開発に多くの知見やインスピレーションが得られます。これらのBTSを使えば、みなさんの開発プロセスをドラスティックに改善できる可能性があるのです。ぜひ、みなさんの組織に合うものを探してみてください。


手間をかけずに報告票に記入できる工夫が、より必要となる項目です。数百～数千ものバグ報告票に、同じこと(製品名)を手書き(手入力)するのは、大いなる工数の無駄遣いです。気の利いたBTSは、製品名などのよく使う項目値を含むテンプレートを適用することで、それらを自動入力する機能を備えています。


多くのBTSは、バグ報告票の書式をカスタマイズし、項目を増やしたり減らしたりする機能をもっています。

バグを発見するための具体的なテスティングのプロセスは、本書では説明しません。モデリングの技術が開発者の職人技であるのと同じく、テスティングの技術はテスターの職人技に依存するものであって、複数のロールから構成され、属人的なものを排した開発プロセスとは直交するものだからです。もちろん、モデリングがそうであるように、テスティングもソフトウェア開発におけるアクティビティの1つですが、その具体的な匠(たくみ)の技は本書で説明すべきことではなさそうです。これらについて詳しく知りたい方には、テストの技法に関する書籍の一読をお勧めします。

ソフトウェアの中に潜在的に含まれているバグは、これをすべて発見し、文書化してBTSにファイルする必要があります。この文書のことをバグ報告票 (Bug Report)、あるいはより一般に課題報告票 (Issue Report) といいます。最近のオープンなBTSでは、TracやRedmineなどのように、これをチケット (Ticket) と呼ぶものも増えてきました。

多くの BTS は、このような柔軟なアクセス制御機能をもっています。

開発規模が小さければ、Microsoft Excelのようなスプレッドシートを使ってもいいかもしれません。この場合は、一行にひとつのバグの情報を記入して管理するのが便利です。しかし、複数人でより効率よくバグを追跡するには、バグ追跡システム (BTS; Bug Tracking System) あるいはより一般に課題追跡システム (ITS; Issue Tracking System) を使うと、もっと 便利です。共有ファイルサーバに置いたスプレッドシートのファイルは、複数人で同時に編集できませんし、ファイルへの変更をチーム内でリアルタイムに共有することもできないからです。

BTSとは、今風の言葉でいえば「プロジェクト見える化ツール」ともいうべきものです。バグ以外にもソフトウェア開発に関するさまざまな課題をファイルすることができ、それらをさまざまな側面で分類して表示します。複数人で同時に使うことも簡単で、各人に割り当てた作業を優先度順に表示したりできます。



BTS に登録(ファイル)されたバグは、チームメンバ各人に対してタスクリストのように扱うことができ、非常に便利です。これはいろんな点でメリットが多いため、BTS にはバグだけでなく、これから実装すべき新機能のほか、さまざまなタスクなども一緒に登録することが一般的です。本章では、発見したバグを追跡し、これを解決することによって開発プロセスを駆動するアプローチについて説明します。


さて、このように大変便利なBTSですが、一般的にはユーザーには開示しないことがほとんどです。詳細すぎる中間成果物をユーザーが閲覧しても、開発業務に混乱を招いてしまうだけだからです。
しかし、ユーザーからの要求やクレームなどに対応するとき、議事録に書きとめてもうまくいきません。議事録はすぐに過去のメールに埋もれてしまい、最新の状態を追跡できるようにはなっていないからです。そこで、ユーザーからの要求を追跡するためのBTS (ITS) を別に構築することがあります。



6章
改めて、テストケースについて注目しましょう。テストケースとは、操作して検証できるかたちで仕様を詳細に記述したドキュメントのことです。ケースとは、場合とか事例といった意味ですから、テストケースとはテスト対象に対して無数にある操作手順や状態を場合分けしたものであると捉えることができます。テストケースには、テスト手順と期待する結果が含まれます。テスト対象に対してテストケースを実行すると、パス (Pass; テストに合格する) かフェイル (Fail; テストに落ちる、失敗する) のどちらかの結果が得られます。
テストケースは、人間の手で実行するマニュアルテストケースと、コンピュータが直接実行できる自動化されたテスト (テストオートメーション) の2つに分類できます。次を見てください。これは、とても簡単なマニュアルテストケースの例です。
1表6 - 2 マニュアルテストケースの書式 (例)
TC#: 0025
Title: 会議室予約
Subsystem: \Project\Main
Setup:
2010年12月12日の3時から5時まで、X会議室が予約されていない状態にしておく。
Steps:
1.	会議室予約システムにログインする。
2.	X会議室を、2010月12日の3時から5時まで予約する。
Expected:
X会議室が予約されたことを表示する。
Teardown:
X会議室の予約をキャンセルしておく。

5章で説明したバグ報告票の項目と、とても良く似ていることに気がつくでしょう。これは、バグ報告票がテストケースとしての機能をもっているからです。違うのは、バグ報告票の項目数よりもテストケースの項目数が少ないことと、テストケースの項目にはテストの準備 (Setup) とテストの終了処理 (Teardown) が加わっていることだけです。この2つの項目は、山のようにあるテストケースを効率よく、正しく実行できるようにとの配慮によるものです。テストの内容によっては、これらの項目を必ずしもテストケースに記載する必要はありませんし、逆に必要ならバグ報告票にもこれらの項目を記入すべきです。バグ報告票が、完全にテストケースの機能を包含していることが分かるでしょうか。ここにあげたテストケースの項目の説明については、5章のバグ報告票の同名の項目を参照してください。
テストケースのテスト手順とバグ報告票の再現手順の違いがあるとすれば、テストケースの手順は包括的・網羅的な手順を準備することでバグを発見することに興味がありますが、バグ報告票の手順は特有の手順で当該のバグを再現することに関心があることです。テストケースで準備したテスト手順でバグを発見できるかどうかはわかりませんが、バグの再現手順ではバグを再現できることが求められます。







http://www.themoviequotes.com/73/Twelve_Monkeys/page_2
12 monkeys
We're not productive anymore. 
We don't make things anymore. It's all automated. What are we for then?
We're consumers.
人間はもう物を作らない。それは全部自動化されてる。じゃおれたちは何をすれば？
今のおれたちは消費者なんだよ。




TODO
どこかにスパゲッティの話出さなかったかな。
処理の流れがごちゃごちゃに絡んで、保守ができなくなってしまったプログラムをスパゲッティコードといいます。

TODO
1.0に満たないバージョン番号は、未完成品である、もしくは鋭意開発中であるというメッセージを含むことがあります。


TODO
余談ですが、ソフトウェアのリリースによく添付されるreadme.txtのファイル名「私を読んで」は、不思議の国のアリスのdrink me「私を飲んで」に着想を得たものと言われています。さらに蛇足を付け加えると、drink meが小さくなる方で、eat meが大きくなる方です。映画「インナースペース」でも引用がありましたね。




ただし、AntでJavaプログラムをビルドするときには、.javaプログラムファイルと、これをコンパイルした形式の.classファイルとの依存関係を手作業で記述する必要はありません。Javaコンパイラは、依存先の.classファイルのソースである.javaファイルが利用可能なときは、そのタイムスタンプを調べて、必要に応じてそれらも自動的にコンパイルするからです (C/C++コンパイラには、そのような機能はありません)。




ファイルセットタグに★★を指定すると、毎ビルド時にソースファイルのダイジェストを計算して保存します。ダイジェストとは、任意の長さの元データから固有のアルゴリズムで取得した短いデータです。元データをちょっぴり変更しただけでもそのダイジェストが変わる、あるダイジェストが与えられたときにそれと同じダイジェストをもつ元データを恣意的に生成するのは困難、などの性質があります。計算機への負荷低減のため、暗号化や電子署名などにも使われるテクノロジーです。よく使われるダイジェストアルゴリズムにMD5があります。



タスクタグに呼び出された外部ツール自身(javacなど)が、責任をもってファイル間の依存を解決します。あるいは、タスクタグが依存関係を調べて、適切に外部ツールを呼び出します。もしくは、Antのファイルセットにより選択されたファイル一覧を、タスクタグが適切に外部ツールのパラメータに変換して、外部ツールに渡すなどです。








?	sub.cを修正した場合
1.	最終的に生成したいファイルはproduct.exeです。このファイルはproduct.objとlibrary.libに依存しています。
2.	product.objはproduct.cに依存していますが、product.objはproduct.cよりも新しいので、再生成する必要はありません。
3.	library.libはlibrary.objとsub.objに依存しています。
4.	library.objはlibrary.cに依存していますが、library.objはlibrary.cよりも新しいので、再生成する必要はありません。
5.	sub.objはsub.cに依存しています。sub.objはsub.cよりも古いので、sub.cをコンパイルしてsub.objを再生成します。

Apache Ant タスク設計ガイドライン
http://ant.apache.org/ant_task_guidelines.html
http://www.jajakarta.org/ant/ant-1.6.1/docs/ja/ant_task_guidelines.html

指定されなかったディレクトリに含まれる.javaファイルも、必要に応じて自動的にコンパイルします 。


このほか、各一次ファイルのMD5ハッシュ値を使って、変更されたファイルを特定するビルドツールもあります。


実際には、SCMリポジトリから最新のソースファイルを取り出したり、自動テストを実行したり、ビルドの完了を通知したりする処理もビルドに含まれますが、それらについては後述します。


この作業を支援するのがビルドツールです。現在、よく使われるビルドツールにAntがあります。英語でAntといえばアリンコという意味ですが、これをAnother Neat Tool (手際の良い新しい道具) の略とする人もいます。Antについては後述します。
ビルドツールを使わなくても、手作業でコンパイラなどの外部ツールを起動し、ビルドを構築することはできます。しかし、手作業でビルドをすると、厳密にいつも同じ手順に従ってビルドすることが難しいのです。というのは、ソフトウェアの規模によっては一次ファイルの数が数百から数千になることもあり、しかもこれら一次ファイルとその中間ファイルの間には複雑な依存関係があるからです。複数の一次ファイルを正しい順序でコンパイルし、生成された中間ファイルを正しい順序で統合しなければなりません。さらには、できあがったビルドに対して自動テストを実行したり、リリース場所 (ファイルサーバなど) にビルドをコピーしてテストチームにリリースをアナウンスしたりするなど、ビルドには決まりきった手順の作業がたくさん含まれています。
ソフトウェア開発においては何度もくりかえしビルドを作る必要があります。このような繰り返しの処理は、コンピュータが最も得意とするところです。つまり、ビルドの処理はコンピュータで自動化すべきなのです。この自動化を受け持つのが、ビルドツールというソフトウェアです。


ビルド作業のインプット (一次ファイル群) が同じなら、何回ビルドし直しても同じアウトプット (ビルド) が得られなければいけません。これを「再現可能」であるといいます。ビルドを再現可能にするためには、ビルドツールが次のことを知らなくてはなりません。
?	ビルドの入力となる一次ファイル群の名前と場所
?	ビルドの出力となる実行可能ファイルの名前と場所
?	各ファイルの依存関係と統合する順序
?	各ファイルを変換 (コンパイルなどを)する外部ツールの名前
?	各ファイルを変換する条件 (コンパイルオプションやマクロ定義など)





このようなビルドを手作業で行うこともできます。
ビルドツールを使わなくても、手作業でコンパイラなどの外部ツールを起動し、ビルドを構築することはできます。しかし、手作業でビルドをすると、厳密にいつも同じ手順に従ってビルドすることが難しいのです。というのは、ソフトウェアの規模によっては一次ファイルの数が数百から数千になることもあり、しかもこれら一次ファイルとその中間ファイルの間には複雑な依存関係があるからです。複数の一次ファイルを正しい順序でコンパイルし、生成された中間ファイルを正しい順序で統合しなければなりません。さらには、できあがったビルドに対して自動テストを実行したり、リリース場所 (ファイルサーバなど) にビルドをコピーしてテストチームにリリースをアナウンスしたりするなど、ビルドには決まりきった手順の作業がたくさん含まれています。



コラム 動詞としてのビルドの種別
本文中では、名詞としてのビルドの種類を紹介しました。しかし、動詞としての「ビルド」にも、いくつか種類があります。
?	Full build (完全ビルド) ? すべてのファイルをコンパイルして、ビルドします。
?	Clean build (クリーンビルド) - 前回のビルドによる中間生成ファイルをきれいに削除してからビルドします。フルビルドと同じ意味と考えて良いでしょう。
?	Rebuild (再ビルド)  ? もういちど、ビルドをやり直します。
?	Incremental build (インクリメンタルビルド) - 修正したプログラムファイルだけをコンパイルし、前回のビルドから変わっていないプログラムファイルは前回のビルドで生成された中間ファイルを使ってビルドします。これにより、ビルド時間を劇的に短くします。
?	Partial build (部分ビルド) - 部分的にビルドします。
?	Distributed build (分散ビルド) - 複数のマシンを使って並行してビルドを走らせることで、見かけ上のビルド時間を短くします。
完全ビルドとインクリメンタルビルド、分散ビルドについては4章で扱います。




Theistic evolutionists
有神論的進化論者


アトミックなコミットは、タスクレベルコミットをするのに大変便利です。

バグ追跡システム (BTS) のバグ報告票の割り当てにより、バグの修正や機能の追加などの作業を指示された担当者だけが、上記のプロセスを経た上で、修正したコードのコミットを許されます。


このような運用をするときは、メインラインに入った差分 (ほかのL2もしくはL3ブランチ経由で入ってきた差分) も、定期的 にすべてのL2・L3ブランチにFIする必要があります(煩雑になるので、これは図示していません)。L1ブランチが一番安定したラインで、ここから距離的に遠い(レベルの数字が大きい)ブランチほど不安定なブランチですから、FIは無条件で行えますが、RIは慎重に行います。


このほか、タグの変更履歴は追跡しないが、指定したタグの打ち直しや削除を禁止(タグのフリーズ)ができるSCMツールもあります。


ビルドのドロップ
consolidate branch
transition branch



います。コンパイルオプションやファイルの依存関係も専用のダイアログでビジュアルに設定でき、ビルドの構成を変更するのも簡単で


兄弟ブランチ間のポートは、直接ポートすることもあれば、メインラインを経由してバックポートとフォワードポートの2回の操作によりポートすることもあります。どちらを選択すべきかは、各ブランチに入るコミットの種類やコードラインポリシーに依存します。

リリースビークル (release veheicle)

http://msdn.microsoft.com/en-us/library/bb668955.aspx

メンテナビリティ、サステナビリティ


3-8. ビルドマシン
SCMサーバと同じPCをビルドマシンとしても良いでしょう。



3-27. SCM サーバの管理
メールサーバと同じように、SCMサーバのサービスを全社に提供するIT部門を設ける場合があります。




日次ビルドについて脚注
広辞苑第5版によれば、日次には「にちじ」「ひつぎ」「ひなみ」などと複数の読み方があり、どれも「毎日の」という意味です。「ひついで」【日次】と読むと、日の都合とか日柄、日取りのこと、「ひなみき」【日次記】とは日記のことです。


バグ報告票には、ひとつのバグだけを記載すること。(一件一葉)

2章のコラム。。
世間では、デイリースタンドアップミーティングの実施は大変有効であるとされているようですが、私見でいえば、このプラクティスが有効となる状況はそれほど多くありません。ほとんど何も計画できないような困難なプロジェクトであれば、デイリースタンドアップミーティングは役に立つでしょう。しかし、計画とは、事前にどうするのがベストか検討しておくことです。確かに、ソフトウェア開発プロジェクトにおいては、全てを計画しておくことはできないのですが、与えられた環境において、どのような制約を前提として、どのように目標を達成すればいいのか考えることはできるはずです。それがあれば、昨日何をしたとか、今日何をするとか、毎日報告するというのは頻度が多すぎるように思います(プロジェクトを制御できていないような印象があります)。少なくとも、進捗の報告は計画に対して行うべきでしょう。



ドッグフードのコラム
次のような話を聞いたことがあります。あるメールサーバを開発している企業は、以前は自社のインフラに自社製品を使っていました。ところが、時の社長が「メールを携帯電話でも読みたい」と言い出し、その機能を持たなかった自社製品の使用をやめて、他社のメールサーバの導入を決定しました。鶴の一声です。もちろん、開発チームは大反対しましたが、社内のメールサーバは他社製品のものにリプレースされてしまいました。その後、この企業は自社製品のシェアを大きく落としたということです。ソフトウェア開発をしている企業では、その経営者もソフトウェアの性質と開発手法をよく理解しておかねばならないという好例 (悪例?) ですね。

testability テスト可能性
いろいろな定義がある
少ないテストケース数で高いカバレッジのテストができる
テストでバグを見つけられそうなモジュールはテスト可能性が高いといえる
ソフトウェアを修正したとき、必要なテストが少なければテスト可能性が高い
テストのためのドキュメントが揃っていればテスト可能性が高い


必要なテスト
■目的に合ったサンプルを観察するためのテスト
技術課題に関連して、解決策の妥当性確認・検証
要求に関連して、要求の抽出・要求の妥当性確認
要件・設計に関連して、要件・設計の妥当性確認・検証
その他リスクに関連して、
■欠陥識別のためのテスト
リリースに関して、不具合の抽出
■信頼度の達成及び評価のためのテスト
信頼度の達成(不具合の抽出による)
信頼度の評価(ランダムに生成したテストケースを使って、統計的に信頼度を測定)




開発プロセスの最初のフェイズ(製品定義フェイズ)は、次のようなものだ。
This phase is the most important by far. In Product Development, teams
assign resources, establish product requirements, and create
preliminary design solutions.

これまでで一番重要なフェイズである。製品開発では、チームはリソースを配分し、製品の要件を確立する。
予備の設計ソリューションを作成する。





メインラインモデルを維持するには、次の2つのプラクティスに従ってください。
?	サブブランチでした修正で必要なものは、必ずメインラインにバックポートすること。
?	ブランチを切るときは、必ずメインラインからにすること。
この2つのプラクティスの間には、深い関係があります。なぜそうなのか、考えてみてください。ブランチに対する理解が深まるはずです。





濱野さん指摘で青い字は、文章が悪いという意味。

2章 コラム 開発中の催し② デイリースタンドアップミーティング に追記のこと。
デイリースプリントはおすすめできない理由
計画してんだから明日どうするとか考えるのはどうか
事前にどうするのがベストか考えているはず、それを粛々とやるべき。
全部が計画できないのはその通りだが、計画というのは最初によく
考えるということだから、どういう環境があって自分たちのどういう
制約があって、目標を達成するためには何をしていけばいいのか、検討すべき。それなくして今日何するの、明日何するのというのはおかしい。
検討した結果、こうやってすすめるのがベストだよねと考えるのが計画。
そのセンに従って、必要があれば深めてもいいけど、今日何をしたとか
明日何をするとか、ふざけるなと。
アーキテクチャにしても、思いつきで作っているわけはない。
パフォーマンスリスクもあるし、リソースのリスクもある。
それをどう検証してどう固めていくのか計画立てているわけで
それを来週何しよう？って話じゃない。

進捗の報告も、計画に対して行われるべき。
計画に対してどのくらいいったのか？
やらなきゃいけない項目はどれだけつぶれたのか？
レビューで受けた指摘は解決できたのか？
計画に対して見ていかねば。


リビジョン番号について
リビジョンというのは上書き。更新。
バージョン1.1というのと2というのは区別もするし、1.1はそれでないといけない。
誤植だとかあって、細かく直すようなとき、上書きしていくようなもの。A->B->Cとかで、Aなどとっておく必要はない。
最新版の状態しかいらないものがリビジョン。過去の履歴が不要なもの。
バージョンというのは、とっておかないといけない。
通常はマイナー番号の中のマイナー番号というか、ABCみたいなのは取っておく必要はない。
バージョン管理がいらないバージョンがリビジョン。それはSWEBOKに書いてある。
SWEBOKは、世の中の常識を集めてあるもの。

ユースケースでスコープを定義するのはおすすめできない。でかすぎ。
まあ、やってもいいんだけど。
ユースケース番号は、機能#1とかにしておいた方が無難。

おしりを叩くのは、どうにかした方がいい。

BVT は、ビルドマスターの責務であるのが一般的。

確かに、生きているブランチ、死んでいるブランチというのはある。
死んでいるブランチ、構成がしっかりしていないブランチで作業をすると
スモークテストで火を噴く。


デイリービルドをさみだれ式にテストチームに垂れ流していくのは非常に問題がある。
開発側がちゃんと、各開発者個人ができましたっていうのを出さないと。
開発リードは、出していいと自分が保証できないものをなぜ垂れ流しみたいに出すのかと。
そうなると、開発者は自分が品質を保証できないものをとりあえず作ってテスト側に全部任せる。
そうなると繰り返しの手戻りが組織全体でぐるぐる回り続ける。
だから、デイリービルドは意味がない。
だから、ひとつちゃんと今日モノを仕上げましょうという意味はあるだろう。
コンパイルとかビルドしないと意味がわかりませんといったような状況はしょぼしょぼでアマチュア。



変更履歴とリポジトリは違う。
リポジトリは、物理的なもので、SWEBOKなどの一般的な枠組みでいうと論理的にはライブラリという。
ライブラリには公共のライブラリと、ある限定されたライブラリと、個人のライブラリと、いろんな階層がある。
ライブラリの特性にはいろいろあるが、変更履歴ではない。
たとえばセキュリティとかアクセスコントロールなどで特徴づけられるものであって
変更履歴があるからリポジトリ、というわけではない。

リポジトリは、変更履歴以外にもいろいろな側面をもつ。
ツールという意味でいうと、保管庫に伴って、変更履歴も差分が自動的に保存されるという特性もある、という話。
構成管理を実装・実現する手段としてファイルシステムを使ってもいい。
論理的に満たさねばならない特性があって、それをファイルシステムでやるのか構成管理ツールでやるのか
それは実装手段。論理的に満たさないといけない要件はこうですよ、構成管理ツールが出している特性はこう。
その話を分けないとおかしい。

ライブラリが満たすべき要件
セキュリティ、差分管理
差分管理はそれほど必要じゃない、ファイルシステムを使った場合は差分管理はできない。
ファイルシステムを使うのは、不便ではあるが問題はない。
そのレベルの構成管理が適切な場合だってある。
セキュリティはある。誰かに勝手にいじられては困るから、それがまず最低要件。
あと、リポジトリは公共の、オープンになっているところと、フレンズレベル、統合レベルと、用途によって区分けされないといけない。これは公共のところだ、これはみんなで共有するところだ、これはワーキングだ、そう区分けされていないといけない。

スナップショットとは構成のこと。

サンドボックスを切り替えることについて追記が必要。
同じバージョンで、似たようなファイルで、ちょっとだけ違うようなときに、同じサンドボックスを使って作業をすると問題が起きる。
違う構成ごとに、別のサンドボックスを作った方が良い。手間を惜しんで同じサンドボックスを使いまわすのは良くないということ。

コミット前のレビューについて
レビューは、基本的にはF2F。レビューとは、人を成長させる場でもあるし、見ても、いろいろ言わないといけないことがある。だめだとか。なぜこんなふうにしたのかとか。意図とか意思とか、そういうものを確認しなければいけないから、メールでのレビューは不十分ではないか。

1:37
ブランチオーナーは微妙、について
ブランチオーナーの役割が微妙。基本的には誰かがいい、って言ったからOKになるわけではなくて
いろんな側面から検証がかかってOKになるわけ。ブランチオーナーじゃなくて、言わないといけない人はいろいろある
こういう個人所有は問題があるのでは。
ブランチオーナーがOKといったからOKなのか、そうではないだろう。
ブランチオーナーはインテグレーションだとか、ビルドマスターに近い役割。


■■■■■1:43 テストの目的について、から。

「V字が間違っている」という記述は直すべき。
電話帳のくだりも、削除すべきではないか。

テストは、バグを発見するためにするのではない。
現在のソフトウェアの品質を測定するためのもの。
ベースに対して、充足性検証をする。
これが満たされているかどうかを確認するのが第一義。
上流は要求。次はシステム要件。次はコンポーネント仕様。それぞれに対してテストをする。
これがテストベースとか、テストの主目的。
仕様とか設計のとおりにできあがっているのかどうか？
スイートとは、環境。テストスイートといえば、そのテストケースとかテストスクリプトが実行できる環境のこと。
環境に対してテストケースを注入した状態がテストスイートになる。

テストケースの集合は、テストケースのセットといえば良い。

エンドレステストというものがある。連続運転テストとか負荷テストとか。
だから、エンドレスという語は不適切。

あるべき論的にいえば、ふたつが必要。
テスト設計とは、全体品質をどう確保していくか、ということ。
テストを単にやるのではなくて、どのようにテストを構成していくか、大きな構想。その構想に基づいてテストケースが出てくる。
1ページ仕様書の次に、仕様書があって、次に設計書がある。
仕様書ができた段階で、このレベルのブラックボックステストのテスト仕様が出てくる。
この設計で、テスト仕様が出てくる。
このテスト仕様をいきなり書くのは難しいから、まずテストの設計書が出てくる。
このように、テストレベルに分けられる。
V字モデルとは、論理構造である。これと実際のプロセスを混同してはいけない。

昔の言葉でいうと、外部設計という。

仕様書と設計書は、きちんと分けねばいけない。
機能設計書は、機能仕様書ではない。

■■■■■■2:12あたり
設計は、システムレベル、コンポーネントレベル、モジュールレベルと3階層になる。各階層で設計が必要になる。
クラスがモジュールに対応。パッケージ、コンポーネント
テスト仕様書は、テストケースとほぼ同じものと考えて良い。
マニュアルスクリプトという言葉はない。


同値類をどうやって作るかが問題。同値値をどう区分けするのか？


テスト全体計画書

テスト戦略書は、独立した文書になる。
テスト戦略とは、どの段階で何を確認していくか。どんな品質を確保していくか。

品質をどこで確保するのか？
テストをしているのに、なぜまだ安定化フェイズが必要なのか？
なんでそんなコストをかけなきゃいけないのか？
テストとは、品質を検証して、測定するためのもの。
テストフェイズが終わった段階では、作り手側としては、すでに品質が保証できているという状態になっているべきで、そのあとに安定化フェイズを設けるのはおかしい。


テスト計画

テスト仕様書
	オートメーション仕様

テスト設計書




構成管理も、予めストリームを計画して切ることが重要。
計画駆動でないエンジニアリングなんて聞いたことない。




静的検証
レビュー、定義証明、静的解析ツールなど

動的検証
テスト、モデルシミュレーション、アニメーションなど


テストで欠陥を除去するのではない
欠陥があるということがわかったら、その段階で品質の状況がわかる
テストで欠陥を除去するというのは、原始時代のアプローチ。
それに頼りすぎるのは問題がある。

安定化とは、リスクのために取っておく期間。万が一抜けているところがあるかもしれないから、入れる。
この段階でバグが見つかるというのは問題がある。
できあがったソフトウェアを品質評価するために行う。
いちおう検証できているものの、リスクに対応するために安定化という期間を入れる。

構成とは、成果物のワンセットのこと。組み合わせ。
ソースコードがどのバージョンで、要求、仕様がどのバージョンで。

テストケースは、実行可能なドキュメントじゃない
このコンディションでこの操作をするとこんな結果が出ますよ、というもの。
それをステップバイステップで書き下ろしたものがテストスクリプト
テストケースは、そのターゲットを与えるだけのもの。
つまり、詳細じゃなくて、入出力と環境があったら、入力と環境と、そのときに行われる操作と結果。

この表示が赤になっていることを確認しなさい、と書いてあるのがテストスクリプト
テストケースを展開したのがテストシナリオ。
この表示がこの仕様書のこの部分と合致しなさい、と書いてあるのがテストケース。
whatのうち、howがテストスクリプト。



全体を管理・コントロールする人、
こちらが技術的なリーダー・とりまとめ役
QAというのは、品質を保証する部門であって、テストをやる部門でない。
全体のquality assuaranceとか品質管理計画とか品質計画を作る。
定量的品質マネージメントとか。品質管理と品質保証がQAの役割。
クオリティは2つの面がある。ひとつはプロセス品質。もうひとつはプロダクト品質。
テストは、プロダクト品質を検証するひとつの手段。
そこであがってきたデータを解釈し、どこでどんなところにもっていくかをコントロールするのがQA。




最適なアーキテクチャをはじめから構築するのはとても難しいのです。多くの場合、これは洗練を繰り返しながら成長させていく必要があります 。たとえば、これまで絶滅せずに生き残っている動物たちの骨格は、厳しい生存競争に耐え続けた結果、長い時間をかけてそのような骨格に進化しました。いろんな骨格を試した結果、環境に不適だったものは絶滅し、良い骨格をもった生物が生き残ったのです。
さらに、そのアーキテクチャが本当に優れたものであるかを検証するには、ある程度の時間の試練に耐えることも必要です。


ASAP
as soon as possible の略語で、「なるはや」の訳語。

stub - 切り株のような、不完全な、突き出したもの
◇ソフトウェアのデバッグのときに使われる仮のサブルーチン.

driver
◇ソフトウェアのデバッグのときに使われる仮のサブルーチン呼び出しプログラム.




http://www.slideshare.net/Ryuzee/agile-day2-agile
本プレゼンテーションに記載した内容は発表者本人の経験、
見解によるもので、本人が所属する (した) 組織、
団体の意見を代表するものではありません。


ソフトウェアが複雑なのは本質的な特性であり、偶然にそうなったのではない。・・・
ソフトウェア開発で昔から悩まされてきた問題は、この本質的な複雑性と、規模が
大きくなれば複雑性が飛躍的に増大することに起因する。
フレデリック・ブルックス 28




CRISPなビルド
Complete, Repeatable, Informative, Schedulable, Portable
書籍「達人プログラマ」に記述がある。


リポジトリが金庫の話
デジカメ写真のファイルをバックアップするには、両親にDVDを焼いてプレゼント


「医者の不養生」「坊主の不信心」「鍛冶屋の竹火箸」「髪結いの乱れ髪」「大工の掘っ立て」「餅屋は餅食わず」「駕籠舁き駕籠に乗らず」


医者の若死に
出家の地獄



Are you a master builder, or a master butcher?
おまえはビルドの達人か、それともへまをする達人か？
(映画 十戒より 00:35:00ごろ)

If you build it, they will come.
field of dreams


Now we've got a relationship we can build on. 
Lethal Weapon 3


Why son of a building block! its woody! and he's in the psycho's bedroom!
Toy Story

You think they'll build another
Star Trek: First Contact


You have build an oasis out of this wilderness.


15
まえがき

26
1. ソフトウェアの進化と寿命
	ソフトウェア開発中の催し① キックオフミーティング 済み
	ソフトウェア開発のメタファ① 旅行 済み

47
2. ビルドの多様性
	ソフトウェア開発中の催し② デイリースタンドアップミーティング 済み
	TeXのバージョン番号
	ソフトウェア開発のメタファ② 建築 済み
	コラム C/C++言語のプリプロセッサとデバッグビルド
	ドッグフードとは

73
3. 構成管理とサンドボックス
	ソフトウェア開発のメタファ③ 音楽 済み
	アトミックなコミットとは
	プログラムとは
	ソフトウェア開発中の催し③ ブラウンバッグミーティング 済み

42
4. 再現可能なビルド
	ソフトウェア開発のメタファ④ 自動車工場 済み
	ソフトウェア開発中の催し④ ワンオンワンミーティング 済み

71
5. バグの追跡
	ソフトウェアの不具合をバグというのはなぜ？
	ソフトウェア開発のメタファ⑤ 医療 済み
	絶対基準の項目には、その基準を表示すべし
	ソフトウェア開発中の催し⑤ バグバッシュ 済み

30
6. テストケースの実装
	ソフトウェア開発中の催し⑥ ポストモータムミーティング 済み
	ソフトウェア開発のメタファ⑥ 車の運転

28
7. 開発プロセスの構築
	設計と実装を近づける試み
	ソフトウェア開発で使われる用語
	ソフトウェア開発のメタファ⑦ 料理


先ほどは、ソフトウェア製品を構成するのはプログラムであると説明しました。しかし、プログラムファイルだけでは、ソフトウェア製品はビルドできません。複数のプログラムファイルの依存関係を管理し、正しい手順でビルドしなければ、ソフトウェア製品を正しく組み立てることはできないからです。ですから、プログラムだけでなく、そのソフトウェア製品をビルドするためのビルドスクリプトも、その製品を構成する部品のひとつと考えられます 。





Eric S. Raymond著 山形浩生訳
Doxygen 

To: 開発プロジェクトチーム
From: 津田義史
Date: 2010/09/21
Subject: ブラウンバッグしましょう


To: 全社員
From: XXチームテストリード
Date: 2010/09/25
Subject: もうすぐ、製品XXのドッグフード・プログラムが始まります！



イラスト
http://kids.wanpug.com/illust103.html


ウォーターフォールについて
http://www.ogis-ri.co.jp/otc/hiroba/oosquare-ml/Archive/200212.month/3414.html
http://www.ogis-ri.co.jp/otc/hiroba/oosquare-ml/Archive/200212.month/3425.html

http://program.g.hatena.ne.jp/youandi/20100503/p1

5-7.	バーンダウンチャート
横軸に時間を、縦軸に既知のバグを含むタスクの件数をとって折れ線グラフを書くと、一般に次のような形になることが知られています。これをバーンダウンチャート (Burn down chart) といいます。スクラムのようなアジャイルソフトウェア開発手法でよく使われるチャートです。
図

バーンダウン (burn down) とは、文字通り、焼け落ちるという意味です。図のようにタスクを完了させ、バグの数の勢いも衰えて下火になれば、この製品をリリースできるようになります。


モデルとコードをより近づける試み

Experience is a hard teacher because she gives the test first, the lesson afterwards. 
経験とは厳しい教師である。それはまず試練を、次にレッスンを与えるものだからだ。
Vernon Sanders Law (アメリカのプロ野球選手)

You can't choose the ways in which you'll be tested. 
あなたがどのようにテストされるかは、選べない。


I dream, I test my dreams against my beliefs, I dare to take risks, and I execute my vision to make those dreams come true. 
Walt Disney

If someone offers to furnish a sure test, ask what the test was which made the sure test sure. Unknown
3
Truth stands the test of time; lies are soon exposed. 
Proverbs 12:19, The Bible 
真実は時間の試練に依って立つ。嘘はすぐに露見する。

...tests are a gift. And great tests are a great gift. To fail the test is a misfortune. But to refuse the test is to refuse the gift, and something worse, more irrevocable, than misfortune. 





ビルドプロセス、単体テスト、デプロイ、品質の計測などはみな自動化できる。
build process, unit tests, deployment, measurements of quality, and other metrics for project management 



justification
変更した場合のベネフィット
変更が実装されなかった場合のインパクト

FragileからAgileへ
Fragileとは、壊れやすいという意味です。本書では、ソフトウェアが壊れやすいことを前提にして、いかにソフトウェアを壊さずに進化させていくべきかを説明しました。これに対し、Agileとは機敏で柔軟な、という意味です。このアジャイルという言葉には、


bi-directional 双方向マージ、ladderマージ
www.perforce.com/perforce/agile



ウォーターフォールは、開発プロセスの各段階がその直前の段階の完了に依存するものになっている。


しかし、本書に示した開発プロセスはソフトウェア開発プロセスを構築するための重要な基盤であることは変わりありません。これは現在でも広く使われている、有効性が実証された頼れる方法なのです。ソフトウェアの健康を守るという根幹をまったく無視しては、いくら昨今のアジャイルなプラクティスを適用しようともうまくいかないでしょう。読者のみなさんが、本書を入り口として、よりよい開発プロセスを発見されることを心より願っています。

あらためて、開発プロセスとは何か、簡単にまとめます。開発プロセスとは、複数のロール（役割）やアクティビティ（作業）、アーティファクト（成果物）などから構成される、ソフトウェア開発を支援するための工学的な方法論です。ソフトウェア開発には、職人的（エンジニア）な側面と工学的（エンジニアリング）な側面が含まれていますが、開発プロセスはこの工学的な側面を支援するものです。新人プログラマであっても、達人プログラマであっても、本連載に示した作業の実施手順はまったく変わらないことに注目してください。
Build your team, trust, and friendship. Then you’ll have built your software!



この論文は、1956年にHerbert D. Benington氏がProduction of Large Computer Programsという論文で示した9つの段階モデルを


TeXを作ったKnuth先生も、新しい分野のシステムを担当する設計者は、実装にも全面的にかかわるべきで、また最初のユーザーマニュアルも書かねばならないと言っています。
The designer of a new kind of system must participate fully in the implementation.
「the designer of a new system must not only be implementor and the first large-scale user; the designer should also write the first user manual.」


Barry W. Boehm氏は、Royce博士が1970年に説明したモデルをverificationとvalidationの側面で拡張し、さらにフィードバックが欠かせない要素であるとして付け加え、1981年にSoftware Engineering Economicsという書籍で紹介しました。


マイルストーンとは、製品のサイクルが進捗する単位のことです。


bug
n. An unwanted and unintended property of a program or piece of hardware, esp. one that causes it to malfunction. Antonym of feature. Examples: "There's a bug in the editor: it writes things out backwards." "The system crashed because of a hardware bug." "Fred is a winner, but he has a few bugs" (i.e., Fred is a good guy, but he has a few personality problems). Historical note: Admiral Grace Hopper (an early computing pioneer better known for inventing COBOL) liked to tell a story in which a technician solved a glitch in the Harvard Mark II machine by pulling an actual insect out from between the contacts of one of its relays, and she subsequently promulgated bug in its hackish sense as a joke about the incident (though, as she was careful to admit, she was not there when it happened). For many years the logbook associated with the incident and the actual bug in question (a moth) sat in a display case at the Naval Surface Warfare Center (NSWC). The entire story, with a picture of the logbook and the moth taped into it, is recorded in the "Annals of the History of Computing", Vol. 3, No. 3 (July 1981), pp. 285-286. The text of the log entry (from September 9, 1947), reads "1545 Relay #70 Panel F (moth) in relay. First actual case of bug being found". This wording establishes that the term was already in use at the time in its current specific sense -- and Hopper herself reports that the term 'bug' was regularly applied to problems in radar electronics during WWII. Indeed, the use of 'bug' to mean an industrial defect was already established in Thomas Edison's time, and a more specific and rather modern use can be found in an electrical handbook from 1896 ("Hawkin's New Catechism of Electricity", Theo. Audel & Co.) which says: "The term 'bug' is used to a limited extent to designate any fault or trouble in the connections or working of electric apparatus." It further notes that the term is "said to have originated in quadruplex telegraphy and have been transferred to all electric apparatus." The latter observation may explain a common folk etymology of the term; that it came from telephone company usage, in which "bugs in a telephone cable" were blamed for noisy lines. Though this derivation seems to be mistaken, it may well be a distorted memory of a joke first current among telegraph operators more than a century ago! Or perhaps not a joke. Historians of the field inform us that the term "bug" was regularly used in the early days of telegraphy to refer to a variety of semi-automatic telegraphy keyers that would send a string of dots if you held them down. In fact, the Vibroplex keyers (which were among the most common of this type) even had a graphic of a beetle on them (and still do)! While the ability to send repeated dots automatically was very useful for professional morse code operators, these were also significantly trickier to use than the older manual keyers, and it could take some practice to ensure one didn't introduce extraneous dots into the code by holding the key down a fraction too long. In the hands of an inexperienced operator, a Vibroplex "bug" on the line could mean that a lot of garbled Morse would soon be coming your way. Further, the term "bug" has long been used among radio technicians to describe a device that converts electromagnetic field variations into acoustic signals. It is used to trace radio interference and look for dangerous radio emissions. Radio community usage derives from the roach-like shape of the first versions used by 19th century physicists. The first versions consisted of a coil of wire (roach body), with the two wire ends sticking out and bent back to nearly touch forming a spark gap (roach antennae). The bug is to the radio technician what the stethoscope is to the stereotype medical doctor. This sense is almost certainly ancestral to modern use of "bug" for a covert monitoring device, but may also have contributed to the use of "bug" for the effects of radio interference itself. Actually, use of 'bug' in the general sense of a disruptive event goes back to Shakespeare! (Henry VI, part III - Act V, Scene II: King Edward: "So, lie thou there. Die thou; and die our fear; For Warwick was a bug that fear'd us all.") In the first edition of Samuel Johnson's dictionary one meaning of 'bug' is "A frightful object; a walking spectre"; this is traced to 'bugbear', a Welsh term for a variety of mythological monster which (to complete the circle) has recently been reintroduced into the popular lexicon through fantasy role-playing games. In any case, in jargon the word almost never refers to insects. Here is a plausible conversation that never actually happened: "There is a bug in this ant farm!" "What do you mean? I don't see any ants in it." "That's the bug." A careful discussion of the etymological issues can be found in a paper by Fred R. Shapiro, 1987, "Entomology of the Computer Bug: History and Folklore", American Speech 62(4):376-378. [There has been a widespread myth that the original bug was moved to the Smithsonian, and an earlier version of this entry so asserted. A correspondent who thought to check discovered that the bug was not there. While investigating this in late 1990, your editor discovered that the NSWC still had the bug, but had unsuccessfully tried to get the Smithsonian to accept it -- and that the present curator of their History of American Technology Museum didn't know this and agreed that it would make a worthwhile exhibit. It was moved to the Smithsonian in mid-1991, but due to space and money constraints was not actually exhibited for years afterwards. Thus, the process of investigating the original-computer-bug bug fixed it in an entirely unexpected way, by making the myth true! --ESR] [7]


表3 - 5に、よく使われるコードラインポリシーをまとめました。ブランチについてさらに詳しく知りたい方は「Streamed Lines: Branching Patterns for Parallel Software Development」という記事をご覧ください。そこには、基本的なブランチ、ブランチ分けポリシーのパターン、ブランチ生成のパターン、ブランチ構造のパターンの4つのカテゴリについて、それぞれ8つずつのパターンを紹介しています。本書で紹介したブランチの名前も、この記事からの引用です。


大きく開発と保守。細かくいえば、開発は主開発と、品揃え (機能を加えるとか、複数の言語に対応するなど) の開発に分けられる。


商品戦略の段階で戦略をひく、その段階でおおきなストリームは全部切ります。






