私の会社では、100 以上のユースケース (UC) として書かれた詳細な仕様書からリッチな GUI を開発しています。これらの詳細な UC が開発を推進します。それらは、俳優と説明の列を持つテーブルとして書き込まれます。私たち (私と他の人々) は、アプリケーションのインタラクティブな性質をサポートするために、実際の UC 散文スタイルを台無しにしました。
また、仕様を使用して (手動で) テスト仕様を生成するため、(私にとっては) 詳細が重要に思えます。このテスト仕様は、サインオフを取得するための検証で使用されます。
注: 製品には GUI 以外にも多くのコンポーネントがあります。GUI チームは 6 ～ 10 人で、プロジェクト全体では約 60 人です。
最近まで、私は各パネルと仕様に関連する相互作用を詳述する「ストーリーボード」ドキュメントを作成していました。以前は、GUI アーキテクチャと、主要なサブコンポーネントの設計もありました。痛い！これにより、開発時間が非常に遅くなり、コードベースが貧弱になり (ha!)、チームのモチベーションが低下しました。
このアプリはどちらかというと IDE に近く、ユーザーはドラッグ アンド ドロップのフローチャート イディオムを使用して独自のテスト ケース (携帯電話のテスト用) を作成できます。これは非常に複雑で成熟しており (7 年以上)、多くの機能を提供します。次に、テスト ケースが実行され、結果が分析されます。このように無料のツールであるため (ユーザーはツールを介してほぼ無限の数のパスをたどることができます)、連続したユースケースはナンセンスに思えます。「O」はオプションを意味し、「R」は反復可能、ネスト、およびその他の多くの「拡張機能」を意味します。基本的に、UC は IDE の相互作用の設計には適していません。このアプリは、ユーザーが任意の順序で何でもできる空白の作業面 (ワード プロセッサやスプレッドシートなど) を提供するものと考えてください。これが UC の肥大化につながっています。
現在、仕様を 100 以上の UC から基本的な UC に単純化したいという要望があります: 「テスト ケースの開発」、「テスト ケースの実行」、「結果の分析」 (または類似のもの)。
私たちの UC が (ビジネス価値に焦点を当てた) 「真の」 UC ではないことは理解していますが、GUI のチーム リーダーであり開発者でもある私の懸念は、詳細な情報がなければ、部下が何を開発すればよいのかよくわからないということです。3 つの UC は抽象的すぎるように思えます。
私たちは統一プロセスの形式に従い、仕様を事前に作成します。おそらく、開発者自身がインタラクションの設計を行う、よりアジャイルなプロセスに変更する必要があります。
