UI駆動開発のアイデアはまったく理にかなっていますか? ほとんどのクライアントは、要件を画面の形で伝えることを好みます。たとえば、これとあれを行う画面が必要です。場合によっては、画面のレイアウトを自分で決定することさえあります (これは、今日のクライアントがほとんどのタスクで既にソフトウェア アプリケーションを使用しているためかもしれません)。
また、この要件収集の方法は、データと関連する動作の両方を自動的に伝達するようです。
皆さんはどう思いますか？
3874 次
5 に答える
6
実際、この点に関しては理にかなっています。ここでのユースケースは、同じ方法では使用できないという点で異なります。ユースケースは、要件を抽出して形式化するのに役立ちます。
私はしばらく前に UI ラボで働いていて、この概念をいじっていましたが、そのようには呼んでいませんでした。ここでの基本的な考え方は、開発にアジャイルな反復アプローチを使用し、ユーザビリティ テストを使用して目的のソリューションに収束させるというものです。
典型的なサイクルは次のとおりです。
- いくつかの要件とユース ケースの草案を作成します。
- この機能に関するデータを収集できるテスト プロトコルを作成します (ユーザビリティ、使いやすさ、受け入れ、パフォーマンスなど)。
- アプリケーションを作成または拡張して、この機能を含めます
- ユーザビリティ テストのアジャイル アダプテーションを使用して、数人のユーザーにアプリケーションをテストしてもらいます ( Ruben のユーザビリティ テストのハンドブックを参照)。
- テストから有用なデータを抽出して、将来の反復に挿入します。
この方法は、ユーザーが何を望んでいるのか正確にわからない場合や、私たちに伝えることができない場合に特に役立ちました。したがって、ユーザーにとってのソフトウェアの実際の有用性に関する客観的なデータを収集するテストを考案し、その結果として次の反復を調整する必要があります。（私たちが「顧客」と呼んでもよい場合、その多くは重度の障害を持ち、話すことができなかったので、創造的でなければなりませんでした）。
この作業方法により、ソフトウェアの開発ライフの非常に早い段階でクライアントが GUI を使用できるようにする必要がありました。これは、テストを指示する中心点であったため、収束の原動力はユーザーであったため、GUI 主導の設計であると言えます。システムとの相互作用。
この手法は主に非常に特殊なケース向けに開発されましたが、通常のソフトウェアで通常のユーザーを対象にいくつかのテストを行い、非常に肯定的な結果が得られました。設計は、ユーザーのニーズに合わせて非常に迅速に収束します。また、彼らがこの設計アプローチに参加したという事実は、ターゲット コミュニティでの製品の受け入れにも非常に良い影響を与えました。
残念ながら、結果を発表してこの研究分野を拡大する前に、内紛により研究室が解体されてしまいました。本当に残念です。
したがって、UIDD (頭字語が悪いことをお許しください) は、反復がユーザー インタラクションに依存するソフトウェア開発へのアプローチの TDD ファミリのメンバーになります。
この件に関する追加の読み物：
http://www.codinghorror.com/blog/archives/001091.html
http://cakebaker.42dh.com/2007/07/07/usability-driven-development/
http://www.springerlink.com/content/l413k76812896gnt/
http://www.agilemodeling.com/essays/agileUsability.htm
http://www.uxbooth.com/blog/how-test-driven-development-increases-overall-usability/
于 2009-04-02T09:37:04.790 に答える
2
what kind of development are you doing? When i develop web apps (flex or php) I work with drawings (wireframes) so I can get the client to know the flow/look of the app without writing any code.
There is no "right way to develop" for everyone , you just need to find the way that works the best for you. cheers!
于 2009-04-02T09:50:21.950 に答える
1
これは要件を収集する合理的な方法だと思います。実際に画面を構築してから、その直接的な機能を開発することに注意します。コードの再利用率が低く、見栄えの良いアプリが遅いか、正しく動作しないことがわかります。要件がどれほど複雑で、データのボトルネックやキャッシュの問題などの問題をどの程度予測できるかに応じて、一部のプロジェクトでは機能し、他のプロジェクトでは機能しません。
ビヘイビア駆動開発、ワイヤーフレーム、ユーザー ストーリーに似ているように思えます。
于 2009-04-02T09:20:50.743 に答える
0
ストーリー テスト駆動開発は、自動化の部分を真剣に考えている限り、非常に良いアイデアだと思います。テストを自動化できない場合は、問題が発生します。ここで論文をチェックしてください: http://www.industriallogic.com/papers/storytest.pdf クライアントが自動化された UI テストを提供しているようには思えませんが、それが最善の方法だと思います。
于 2009-04-02T09:20:22.850 に答える
0
ここで実際に話しているのはユース ケースだと思います 。紹介については、この記事を参照してください。
于 2009-04-02T09:18:53.523 に答える