プロジェクトの開発を開始する前に何を計画しますか？[閉まっている]

クライアントからプロジェクトの仕様を受け取ったとします。そして今、プロジェクトの開発を開始します。通常、最初のモジュール（通常はユーザー登録）から始めて、あるモジュールから次のモジュールに進みます。モジュールの動作を開始する直前に頭の中で計画するだけですが、その前に計画はありません。

ただし、仕様を検討し、コーディングする前にシステムがどのように機能するか、たとえば主要なコンポーネントは何か、それらはどのように相互作用するかなどを計画しておいた方が良いと思います。私が何を計画すべきか正確にはわからない。

私が何を求めているのかをよりよく理解するには、どのようにすればよいですか-

a）プロジェクトをコンポーネントに分割し、

b）相互作用を計画します。たとえば、クラス図を作成したり、単体テストを作成したりする必要がありますか？

何か案は？

新しいプロジェクトを開始する特権を持っている場合、空白のキャンバスがあります。これは、同時に刺激的で気が遠くなるようなものです。私は繰り返し作業をしていますが、これが仕事を分割する方法です：

• プロジェクトの目標から始めます。目標は必然的に最もあいまいですが、クライアントまたはユーザーがソフトウェアで何をしようとしているかに集中するのに役立ちます。結局のところ、これらの目標を達成したいのです。たとえそれが本当にクールな機能を落とすことを意味していても。
• 次に、アプリケーションをサブドメインに分割し始めます。これを行うには、おそらく100種類の方法があります。そのため、プロジェクトの目標から始めます。アプリケーションを、これらの目標をサポートするいくつかの関連サブシステムに分割します。これにより、次のタスクに集中できます。
• サブシステムが相互作用する必要がある方法とタイミングを特定します。サブシステムの統合システムがあることを確認するために、詳細を扱うのではなく、高レベルの情報だけを扱っています。プロジェクトの全体的な目標をサポートする詳細を具体化するには、これに関する一般的なアイデアが必要です。
• 現在作業中のサブシステムの詳細のみを提供してください（現在の戦略と同様）。このサブシステムが他のサブシステムとどのようにやり取りする必要があるかは既に知っていますが、いくつかの代替案を作成して、最も意味のあるものにする必要があるかもしれません。各サブシステムはインターフェースによって分離されているため、システム全体を壊すことなく実装を可能な限り調整できます。
• 現在のサブシステムでの実装方法と、他のサブシステムでの実装方法を比較してください。一貫性のないアプローチはすべて、ユーザーが学ぶ必要があるものです。ブランドの新しいコンセプトについて話している場合は問題ありません。使いやすさのために、怠け者であるという理由だけで存在する情報を削除するための5つの異なる方法は必要ありません。同じユーザーインターフェイス要素を再利用することが、アプリケーションをより直感的にするための最も簡単な方法です。20の学習よりも3つの概念を学習する方がはるかに簡単です。

本質的に、プロジェクトを非常に高いレベルからより詳細な設計に段階的に定義するこのアプローチは、私にとって非常に役立ちました。サブシステム間の相互作用も、実際に実装しようとすると洗練されます。よかったです。

スペックを調べたらもっといいと思う

正しい。良いアイデア。

コーディングする前に、システムがどのように機能するかを計画しました。

良い。それをもっとしてください。

主なコンポーネントは何ですか、

優秀な。

彼らがどのように相互作用するか、

正しい。

私は何を計画すべきか正確にはわかりません。

すでにたくさんのものをリストアップしているのに、どうしてわからないのですか？それらがあなたに関係するものであるなら、なぜそれらのものに焦点を合わせないのですか？

4 + 1ビューモデルの詳細：http : //en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Zachmanフレームワークについて読む：http : //en.wikipedia.org/wiki/Zachman_Framework

それはあなたが計画する必要があるものです。

どうすればよいですかa）プロジェクトをコンポーネントに分割し、

他の同様のプロジェクトに広く採用されているデザインパターンを使用します。

疑問がある場合は、J2EEの青写真を読んでアイデアを確認してください。

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

b）相互作用を計画する方法。たとえば、クラス図の作成、単体テストの作成など。

はい。良いアイデア、すべて。

最も重要なこと：仕様を確認し、顧客と対話して、より洗練された仕様を取得します。

要件は間違いなく不完全、曖昧、または不正確です。時間の最大の無駄は、間違ったことをすることです。顧客はプロのソフトウェアエンジン開発者ではないため、適切な一連の要件の作成が得意であるとは期待できません。

そのため、仕様を確認し、顧客にインタビューし、これが本当に必要であり、望んでいるものであり、余裕があるかなどを調べる必要があります。

テスト/ユースケースを開発し、顧客とレビューします。要件がテスト可能でない場合は、破棄します。

設計を開発し、すべての部品が理論上必要な機能を果たすように正しく機能するかどうかを確認します。

機能を無視して、すべてのレイヤーで使用されるすべてのテクノロジーをテストするアーキテクチャプロトタイプを開発します。機能仕様ではなく、アーキテクチャをテストしています。アーキテクチャが間違っていると、すべてを書き直す必要があるため、適切なアーキテクチャを取得することが重要です。速度、効率、セキュリティなどの要件を満たすことができることを確認してください。

コーディングを開始する前に、いくつかのデザインを適切に配置する必要があります。

それができたら、通常、最初のアーキテクチャフェーズを最初に実行して、アプリレイヤーがどのように適合するかを定義することを好みます。これには、セキュリティやロギングなどのバックボーンが含まれます。

次に、1つの機能を上から下に構築して、何かを完全に実装しました。

その後、そこから行きます。

すべて

すべてを計画し、その一部がすでにコーディングされているよりも紙上で変更する方が簡単であり、ドキュメント作成のための優れた基礎と他の多くの利点が得られます。