仕事で新しいプロジェクトの初期開発をおこなっているのですが、「試作品」を表現する単語がいくつかあり混乱したのでまとめてみました。
達人プログラマーに登場する例えです。 曳光弾をそもそも知らなかったのでWikipediaで調べてみます。
曳光弾（えいこうだん、英: Tracer ammunition）は、発光体を内蔵した特殊な弾丸。射撃後、飛んでいく間に発光することで軌跡がわかるようになっている。トレーサーや曳痕弾とも呼ばれる。 射手に弾道を示し、軌跡を知ることで射撃中に方向を修正することができるため、対空射撃、または航空機からの射撃で各種の合図のために使用される。欠点は発射元の位置も推測されてしまうことと、弾道が普通弾と異なることである。 （「Wikipedia 曳光弾」より引用）
曳光弾とはソフトウェア開発においては開発中に作成するもので、最終的なソフトウェアの一部機能のみを実装したものです。 （実在するかわかりませんが）操縦席だけの車みたいなものです。
一部機能を開発依頼者に実際に触ってもらうことで「開発依頼者がイメージしているソフトウェア」と、「我々開発者がイメージしているソフトウェア」がずれていないかを確認します。 コストの低い曳光弾によって方向性が正しいかを確認し、コストの高い実弾（＝完成したソフトウェア）によって依頼者の願いを叶えるというわけです。
曳光弾はどんどん肉付けしていって最終的な成果物になる（＝曳光弾は成果物の一部になる）というのがポイントです。 アジャイル開発的な側面もあります。
曳光弾と似たものにプロトタイプがあります。 これは開発前の要件定義段階で使用するもので、要件が固まりきっていないときに仕様を固めていくための試作品です。 段ボールで作った車みたいなものです。
試作ですので、要件定義が完了したら捨てることになります。 プロトタイプを曳光弾のように作り込んでしまうことはよくあるミスです。気をつけましょう（自戒）。
Proof Of Concept、概念検証と言われたりします。 これもプロトタイプと同じく要件定義段階で使用するもので、以下のような疑問を解消するために行います。
これは最終的なソフトウェアとは全く関係がなく、技術的に可能かどうかをチェックするだけのプログラムを組むことになります。 フィジビリティスタディと呼ぶ人もいます。（フィジビリティ＝実現可能性）
外側だけ作ったソフトウェアのこと。 要件が固まった後に画面やAPI、クラスや関数の外側だけ作っておいて中身は適当な値が入っているだけみたいな状態です。
デザインについてデザイナーと相談するためや、外部からAPIや関数を呼ばれるときエラーが出ないように形だけ作っておきます。 曳光弾と違って機能的には全く意味がないもので、実装が進むとともに置き換えられていきます。
「試作品」的なワードについてまとめました。
正直企業文化によって微妙に変わってくるとも思うので、これらの単語を使われたらどういう意味合いで使っているのかきちんと尋ねておくと不幸にならずに済むかもしれません。