BDDとウォーターフォールの違いについて一人で調査を設定するにはどうすればよいですか？
以前、プロジェクトの品質を測定する方法について質問しました。その質問の結果は、プロジェクトの品質を2つの部分に分けることができるということでした。
- 内部品質（コード品質、コード品質メトリクスで測定可能）
- 外部品質（受け入れテスト、ソフトウェアが要件をどの程度満たしているか）
そこで、それに基づいて、いくつかの調査を設定し、プロジェクトの結果を検証したいと思います。問題は、私が自分でこの研究を行うので、一度はBDDスタイルで、もう1つは滝で自分でプロジェクトを実行することはできないということです。また、BDDの時代のために測定できるBDDプロジェクトが十分にないため、BDDプロジェクトとウォーターフォールプロジェクトを大規模に比較することもできません。
だから、私の質問は：誰かがこの問題に直面しましたか？科学的価値があるような方法で実験を実行するにはどうすればよいですか？
開発プロセスを検証するために、研究室で十分な大きさのデータセットを生成することは不可能です。オプションは次のとおりです。
業界との提携。手始めに、プロジェクトの開始時にBDDで彼らを指導する必要があり、彼らはそれを喜んで採用する必要があります-大変な注文です！また、いくつかのプロジェクトで実験を実行するには数年かかるでしょう。また、さまざまな業界にまたがる可能性のある複数の企業で実験を実行することもできます。コントロールウォーターフォールプロジェクトでは、既存のデータに頼ることができます。
学生プロジェクトの使用。このオプションは実用的ですが、プロジェクトの規模を小さくする必要があるほど信頼性は高くありません。ねえ、あなたはあなたがしなければならないことをしなければならない！おそらく、大学院生にアクセスできるのであれば、もっと良いかもしれません。
続行する必要がある場合は、オプション2が唯一の実用的なオプションのようです。しかし、あなたはあなたの研究トピックを再考したいかもしれません！
幸運を！
あなたは自分自身に非常に難しい仕事を設定しました！
各ソフトウェアプロジェクトは基本的に一意であり、さまざまな環境のさまざまな顧客に対してさまざまな要件を実装するさまざまな人々がいます。
さらに、営利団体は、プロジェクトのコスト、労力、さらには成功または失敗に関する内部データを公開しません。実際、ビジネス向けのほぼすべてのプロジェクトは、純粋に「成功」が提供されたものとして再定義されているために成功しています。
一方、政府機関は公の場で活動する必要があり、コスト、リソース、成功/失敗に関する数値が公開されています。少なくともプロジェクトの開始時には、彼らは何をどのように行っているかについて非常にオープンである傾向があるため、プレスリリース、監査レポート、公開されたアカウント（および最後の手段での情報の自由の要求）の間で、分析するのにかなり良いデータの本体。
注意点は、政府のプロジェクト（少なくとも私の税金が支払うプロジェクト）には、長くてひどい失敗の歴史があり、一般に、独特で独特の一貫性のないプロジェクト管理スタイルに従っていることです。
ウォーターフォール は [〜＃〜] alm [〜＃〜] 、 BDD-1 / BDD-2 は継続的な受け入れテストの方法です [〜＃〜] tdd [〜＃〜] は継続的なユニットテストの方法です。
2つは異なる側面をカバーし、not相互に排他的です。
例えば。 BDDの有無にかかわらず、これらのALM {Waterfall、UP、SCRUM}のいずれかを使用できます。
BDDの真の価値は、シナリオが明白ではないトリッキーな状況、つまりプロジェクトの未知の未知のものを発見することです。
すべてのプロジェクトは何か新しいことをすることを伴うので（そうでなければ、すぐに購入するか、オープンソースを使用することができます）、通常、これらの発見のいくつかがあります。それらはプロジェクトに最も時間を費やすものです。 （「プロジェクトにリスクがない場合は、実行しないでください」-Waltzing with Bears）。
したがって、特にBDDを使用してそれらの発見を支援する場合、プロジェクトごとに根本的に異なるため、あるプロジェクトを別のプロジェクトと比較することに絶望しています。プロジェクトをやり直そうとすると、すべてのプロジェクトが見つかります。すでに発見されており、それに応じてバイアスがかけられています。 （ちなみに、これらの発見がウォーターフォールがうまく機能しない理由です。）
代わりに、主要な利害関係者に、1から10のスケールで一連のBDDおよびウォーターフォールプロジェクトから得たソフトウェアの内部および外部の品質にどの程度満足しているかを尋ね、結果を比較します。それはあなたが得ることができる可能性が高いのとほぼ同じくらい客観的であり、複数のプロジェクトにわたって機能するはずです。
私は純粋に私が読んだことを続けています ここ 。 BDDとTDDを比較してみませんか？ 1年目のCS専攻のグループを取り上げ、BDDがある場合とない場合の単体テストを使用する能力を比較します。彼らはプロセスのより良い理解を深めていますか？
アジャイルからウォーターフォールへの方法に関するデータを取得しようとすることにはメリットがありますが、それは卒業論文IMHOを超えています。
Rrufaiの2番目のオプションは追求するのに最適なオプションかもしれないと思います。ただし、少し変更します。
中級から上級レベルのプログラミングクラスをいくつか見つけて、生徒をウォーターフォールとBDDの2つのグループに分けます。クラスの規模によっては、アプローチごとに複数のチームを簡単に作成できます。
次に、GoogleのCodeJamプロジェクトから特定の課題に取り組みます。チャレンジごとに少なくとも1つのウォーターフォールと1つのBDDチームを持つようにチームを割り当てます。ドキュメント、進行状況インジケーター、トレース/ロギングなどの要件を追加して、設計してプロジェクトに組み込む必要のある機能の数を増やします。
Jamを使用する利点は、コードの検証が組み込まれていることです。追加要件の評価基準を決定する必要があります。
理想的には、各チームが割り当てられたスタイルでいくつかの課題に対処するようにします。次に、設計手法を切り替えて、さらにいくつかの課題に対処させることができます。