一般的に言って、すべての機能部分を作成するか、UIを最初に動作させるのが良いのでしょうか？
あなたが大きな何かに取り組んでいると仮定すると、UIの前にすべての機能データ収集ブロブを動作させる、一般的に受け入れられているプラクティス、すべてのUIを一度に1つずつ動作させる、または途中で何かを行うのは一般的ですか？
管理しやすい部分に細分化することは誰もが知っていますが、問題は最終的にはUIが管理可能な部分に含まれるかどうかです。
この例の場合、1つのルートウィンドウを備えたGUIアプリケーションを考えてみましょう。ただし、さまざまなデータコンポーネントを分離するためにさまざまなドックに12個以上のタブがあります。個々のタブには、機能ユニットの観点から、その背後にある比較的複雑な可動部品のセットがあります。
回答:
多くのビジネスユーザーとクライアントの間では、完成したように見えてもほぼ完成しているという一般的な概念があります。ご存知のように、これは真実とは程遠いものです。見栄えは良くなりますが、バックエンドがなく、一部のユーザーは見栄えを良くすることが作業の80％であり、20％（または他の80％）ではないと考えています。
数え切れないほどの開発者がこれについて恐ろしい話をすることができます-他のツールのスクリーンショットを使用してMicrosoft Wordでページのモックアップを取得し、クライアントは「それでほぼ完了しましたか？」
すべての部分が完了したときに完了するように、ペースを調整する必要があります。最初にすべてのバックエンドを実行し、次にすべてのフロントエンドを実行しようとすると、エンドユーザーは何もしていないと考え、何も表示されないのに支払いを受ける理由を尋ねます。一方、最初にフロントエンドを使用すると、エンドユーザーが微妙な変更を行い、すべての時間を消費します。
「一方が最初でもう一方が」という最悪のケースは、他の部分に到達したときに、設計にまったく適合しないことです。
したがって、両方をビルドします。フロントエンドで進行状況を表示し、構築しているものでバックエンドを機能させます。多くの場合、インクリメンタルビルドを提供し、クライアントが望むものを作成していることを確認することをお勧めします（これはアジャイルになります）。「目に見える進歩」なしで長すぎると、クライアントとの関係を損なう可能性があります（これは「すべてが早く行われているように見える」と「最後まで何も行われていない」の両方の場合です-クライアントがフレームワークを書いているのを見たり単体テストまたは進行状況としてのデータのサニタイズ）。
ジョエルはこれについて、「明らかにされた氷山の秘密」に書きました。
重要な結果2。プログラマーでない人に、100％美しいユーザーインターフェイスを持つ画面を表示すると、プログラムはほぼ完了したと思われます。
プログラマーでない人は、画面を見ているだけで、いくつかのピクセルを見ています。そして、ピクセルが何かをするプログラムを構成しているように見える場合、彼らは「ああ、まあ、実際に動作させるのはどれほど難しいでしょうか？」と考えます。
ここでの大きなリスクは、最初にUIをモックアップすると、おそらく顧客との会話ができるようになると、誰もがほぼ完了したと思うようになることです。そして、来年を「隠れて」仕事をするとき、いわば、誰もあなたが何をしているのかを実際に見ることはなく、彼らはそれは何もないと思います。
これは、ブログ投稿で繰り返し説明されていますが、この便利なグラフがあるデモを「完了」にしないでください。
ここで、2つのオプションは一般に「UIを完了」（および、すぐに完了できることを期待しています）と「バックエンドを完了」を反映していることに注意してください（そして、顧客は締め切りに間に合わないことを心配しています）。
「完了」したものがどのように見えるかは、「完了」したものがどのようにあるかと一致する必要があります。
すべてのソフトウェア開発者は、これまでのキャリアの中でこれを何度も経験しています。しかし、デスクトップパブリッシングツールは、技術ライターにとっても同じ頭痛の種になります。完全にフォントとフォーマットが設定されたラフなドラフトを誰かに見せれば、彼らはそれをあなたが望む以上にやり遂げたと見なします。私たちがいる場所と他の人が私たちを認識している場所との一致が必要です。
また、この記事では、さまざまなレベルのユーザーインターフェイスの完成度で得られるフィードバックの種類に関する重要なポイントを取り上げます。完全に見えるものがある場合、「このレイアウトは機能しません-タブが多すぎます」よりも「フォントを変更できますか」についてフィードバックを受け取る可能性が高くなります。
Java Swingの世界でこれと戦っている人のために、UIが（たとえそうであっても）完全に見えないようにするNapkinと呼ばれるルックアンドフィールがあります。
ここで重要なのは、見栄えが良くならないようにすることです。UIが完全に見えることは、多くのビジネスユーザーにとって、アプリケーションが完了したことを示すシグナルです（その背後にあるロジックやインターフェイスビルダーで構築されたものがない静的ページがいくつかある場合でも）。
さらに読む（および記事からのリンク）：
それは次のとおりです。最も重要な機能の周りにタイトなフィードバックループが必要
あなたがやることの核心である、危険で怖い部分が何らかの内部エンジンであるなら、コンソールやユニットテストなどで核心部分を機能させます。たとえば、プロトコルパーサーは、正常に動作しているかどうかを知るためのUIを必要としません。
クールなことにインタラクティブ性が関係している場合（インタラクティブ性は常にトラブルシューティングし、捨てて、再発見する必要があります）、UIファーストのアプローチが重要です。たとえば、人々がデータの視覚化と対話できるようにするアプリを構築したいと思います。私が理解する必要がある最も重要なことは、視覚化が有意義であるかどうかです。そのため、1つに着手する前に半ダースのアプローチを捨てるでしょう。これをすべて実行してから、単一の単体テストを作成します。
コードの最適な相互作用と検証の方法に関する最適な組み合わせを決定するためのあいまいな灰色の領域があります（自動化されたテスト？実験用のUI？）。私は個人的に両極端とその間のすべてを行ってきましたが、そのスペクトル上で適切な場所を決定することは私が決定しなければならない最も難しいものの1つであり、構築しているもののタイプに100％依存しています。
アジャイル環境では、「歩くスケルトン」または「薄い垂直スライス」の議論を聞くかもしれません。作業ソフトウェアはユーザーにとって重要なものであるため、作業用ソフトウェアを少しずつ構築するという考え方です。
前述のサンプルアプリケーションでは、ウィンドウと1つのタブから始めて、すべてのウィンドウを何らかの方法で前面から背面に機能させます。その後、機能を追加し、タブをケースバイケースで追加し、各機能を構築しながら機能させます。これは、頻繁に行われる顧客のデモンストレーションが提供するものの一部です。新しい機能を示し、すぐにフィードバックを得る機会です。
要するに、はい、UIがある場合、UIの作業は機能的な作業の単位の絶対的な一部です。
動作する小さなものから始めて、その機能を繰り返して完全なソフトウェアを提供します。
機能とUIの両方を組み合わせることをお勧めします（できるだけ早くフィードバックまたはテストエクスペリエンスを取得します）。
ところで、ほとんどの大規模なGUIソフトウェアの開発方法ではありませんか？たとえば、Firefoxブラウザーを見てください。あるバージョンから次のバージョンまで、機能とユーザーインターフェイスの両方が進化しています。
私が取り組んでいる大規模な（PHP Webベースの）アプリケーションでは、まずダミーの値を返すクラスとメソッドを取得しようとします。これは、他の開発者がUIを実装するために使用できる擬似契約を確立することです。
この方法の2番目の利点は、すべてのコードが記述されて配信される前であっても、UI要件の変更（および常に変更）に応じてコントラクト/インターフェイスを強化できることです。
私がしがちなのは、くだらないUIから始めることです。画面に変数データをダンプするだけのことです。長い間、フォントも、整列も、実際にグラフィカルなものもありません。「Welcome user x」と「load pic」などと呼ばれるボタンだけです。これについて良いのは、バックエンドで何かが壊れているかどうかを調べることです。
開発が進むにつれて、進むべきものが増えたり減ったりすることがあります。しかし、いくつかの段階で、バックエンドがほぼ完成したと判断します。これで、必要なすべての添付ファイルを含むUIが作成され、すべてのグラフィカルな処理に多くの時間を費やすことができます。
ただし、万全ではありません。特定の問題が発生するのを見るには、少し先見が必要です。たとえば、データを適切な方法で表示するには、UIコンポーネントを調査する必要がある場合があります。
ユーザー/クライアントの視点で考えてください。ソフトウェアシステムは、このユーザー/クライアントに何らかの価値を与える機能の集合です。もちろん、この機能にはそれぞれ、UI、バックエンドなどがあります。
常に機能ごとにシステムを構築し、非常に小さな機能に分割してみてください。この方法では、常に顧客に提供するものが近くなります。ソフトウェア開発は、バージョン1.0をビルドすることではなく、バージョン1.0.1から1.0.2に移行することなどに注意してください。
場合によります。要件はどの程度明確に定義されていますか？UIが直面しているシステムはどれくらいですか？
私の経験から、ほとんどの顧客は彼らの前に何かを見るまで彼らが望むものを知りません。そのため、私は通常、UIの主要な側面のワイヤーフレームを提供するか、UIの大部分を提供します（機能しません）。これにより、データベースの設計とコード構造がまだ設計段階にあるため、顧客はあまり影響を与えずに機能の機能を変更できます。設計の修正は簡単です。プロジェクトの早い段階でデザインを変更し、その後にデザインを変更することは、桁違いに簡単です。
アジャイルは、最も難しいアイテムと最も重要なアイテムに最初に取り組むべきだと述べています。早く失敗します。したがって、顧客がUIを確認したら、完全に機能する小さなコンポーネントを構築することに焦点を当てます。
その後、スプリントを取得し、いつかUIと機能の両方の側面を開発している顧客と絶えずコミュニケーションを取ります。