ソフトウェア工学における「設計」とはどういう意味ですか？
さまざまなソフトウェア手法について読んでいます。どの方法にも、ある程度、ある程度の設計段階があります。
私たちがデザインによって何を意味するのかははっきりしません。これは、機能をどのようにコーディングするかについて思考プロセスを書くことを意味しますか？または、何をコーディングしたか、または何をコーディングするかを言う方法です。
私が最も混乱しているのは現実の世界であり、それはあなたの考えを文書に入れてそれがうまくいくと言うこととは異なります。コーディングの詳細は変更される可能性があるため、コーディングの前にデザインを作成する意味がわかりません。
まず、デザインは、私の意見では、プロジェクト/ソフトウェア/アプリケーションを準備/検討するプロセスなので、一貫性があり、目標を達成し、要件を満たす。設計は、ソフトウェアの生産プロセスをより効率的にするのにも役立ちます（プロジェクトの非常に基本的なもの、それらがどのように機能するかなど）。
ウィキペディアは言う：
ソフトウェア設計は、ソフトウェアソリューションの問題解決と計画のプロセスです。ソフトウェアの目的と仕様が決定したら、ソフトウェア開発者は設計者を設計または採用して、ソリューションの計画を作成します。 低レベルのコンポーネントとアルゴリズムの実装の問題とアーキテクチャのビューが含まれています。
つまり、構造（この場合はソフトウェア）を構築する前に計画を立てます。
そして、多くのことが変わったとしても、なぜ最初に設計し、次に実装するのですか？次の図（ソース： http://www.agilemodeling.com/essays/costOfChange.htm ）を参照して、これを最も明確にしてください（少なくとも私はそう思います）。
ソフトウェア設計の意図は、安く失敗し、早期に失敗することです。実装を設計するときは、早い段階で物事を考える必要があります。設計段階でミスを犯したことを発見することは、設計の欠陥のために、設計なしで実施した作業の80％をリファクタリングする必要があることを認識するよりも常に安上がりです。
経験が豊富な他のユーザーも、ソリューションの実装に時間をかける前に設計を確認し、システム内の高レベルのエラーを指摘する機会があります。
また、将来あなたの靴に足を踏み入れる人にも、コードを理解しようとするのではなく、文書化された何かを読むことができるようになります。
もちろん、設計の細かさによっては、いくつかの点が変わる可能性がありますが、全体的なアーキテクチャはほぼ90％の確率で同じです（十分な経験がある場合）。
良い質問！ （プログラマにとってはより適切ですが、stackexchange）
私もこの点をよく考えていました。コーディングする前にプログラムをどのように設計できますか？結局何を書こうとしているのかわからない！
まあ、私にとっては、私たちの業界の多くの偉大な職人が反響していることを簡単に言うと、
優れたプログラマーは「私はこの問題を解決できる」と言って、100行のコードを書きます。優れたプログラマーは、「以前にこの問題を見たことがある」と言って、前回書いたコードを再利用しています。
プログラムの設計は、問題領域のさまざまな問題について考え、その問題をどのように解決するか、または以前にどのように解決したかについて、一般的な方法で解決します（さらに、最近発見しました）。重要なものとそうでないものを決定するタイミング。
私が運転しているのは、デザインは全体的に全体像を視覚化することだと思います。しかし、少なくとも一度はそこに行くまではそうするのは難しいです。
比喩を使うために、どんなプログラマーでも小麦粉と水を混ぜるプログラムを書くことができます。しかし、ケーキを焼くシステムを作るには、さらに理解が必要です。
わかりました、悪いメタファーですが、私が運転しているものを見てほしいと思います。
ソフトウェア設計は、ソフトウェアの方法論の段階であり、実行すると、当面の問題を最も適切に解決する方法が明確になります。設計は、完成するまでさまざまな反復に入る場合があります。設計は、ソリューションアーキテクチャ、アプリケーション構造、データベース設計、統合技術など、システムのさまざまな側面をカバーする場合があります。設計の入力は、計画と分析の成果物です。ソフトウェア設計は、システム全体に適用されるだけでなく、システムの個々のコンポーネントにも適用されます。ソフトウェア設計は、プログラムのコーディングを進める一歩であるべきです。異なる方法では、設計アクティビティを異なるフェーズに配置し、それらを異なる名前で呼びます。
ソフトウェア設計の1つの意味は、（他の多くの）にあります http://en.wikipedia.org/wiki/Software_design
http://c2.com/cgi/wiki?WhatIsSoftwareDesign
私はこの漫画をとても素敵だと思います： http://www.cs.utexas.edu/users/dsb/CS378/
ソフトウェア標準のIEEE用語集（IEEE Std 610.12-1990）は、ソフトウェア設計を「システムまたはコンポーネントのアーキテクチャ、コンポーネント、インターフェース、およびその他の特性を定義するプロセス」および「プロセスの結果」として定義しています。 。本質的に、それは、あなたが構築しようとしているもののある種の記述を生成するための要件の分析です。設計アクティビティの最終結果は、建物を構築するための青写真に相当します。
設計は通常、さまざまなコンポーネントを識別するシステムの高レベル（またはトップレベル）の説明と、コンポーネントが相互にどのように相互作用するか、およびコンポーネントの構築を可能にする各コンポーネントの詳細な説明に分けられます。
任意のレベルで設計について話すとき、配布（どのコンポーネントがどのタスクを実行し、それらのコンポーネントがどこに配置されるか）、並行性とタスク処理、データとイベント、エラー処理とフォールトトレランスなどの概念を考え始めます。 、データの永続性、相互作用、プレゼンテーション。また、システムとそのコンポーネントの品質属性（保守性、テスト容易性、移植性、堅牢性など）も考慮します。
どのように設計に取り組むかは、システムの構築に使用しているプロセス方法論によって異なります。たとえば、シーケンシャルライフサイクルでは、通常、「大規模設計」（BDUF）を実行します。ここでは、要件を取り、高レベルの設計を作成し、それを（ほとんどの場合）完成させ、それを使用して詳細設計し、その設計を実装します。より反復的で段階的な方法論では、すべての既知の要件を考慮する必要がありますが、それらの機能のサブセットをいつでも設計（および実装）することに注力し、追加機能として製品とその設計を進化させます。
システムの設計に使用する特定のアプローチと手法も、システムが何であるかによって異なります。たとえば、地元のリトルリーグチーム用のWebサイトの設計、Amazon向けのWebアプリケーションの設計、航空機を制御するソフトウェアの設計は、形式と文書化する必要のある点ですべて非常に異なります。入力、アクティビティ、および出力の詳細は、設計アクティビティの一部であり、プロジェクト計画ドキュメントで指定する必要があります（これも、プロジェクトの種類によって、口頭での合意から大規模な仕様まで、形式が異なる場合があります）。
デザインとは
人々がデザインの見出しの下に含めるものには、ある程度のばらつきがあります。ほとんどの場合、システム構造とコード構造が含まれていると思います。
システム構造は、完全なソリューションがどのようになるかを示す巨視的な画像です。あなたは解決策を熟考し、あなたが必要とすることを知っているもののリストを作ります。たとえば、一般的なニーズはデータストアです。その後、具体的なデータストアの種類を決定する必要がありますか？データベースである必要はありますか？永続的なデータ構造、フラットファイルなどはどうでしょうか。プロジェクトのニーズと各実装の利点を比較検討して、ニーズに最も適合するものを選択します。
コード構造もデザインの一部です。全体的なアーキテクチャ、そしておそらく、どのような抽象化から遠ざけるか、または使用しないかの提案さえも。 1つのまとまりのあるシステムとして構成する必要があります。一緒に動作する必要がある独立したコンポーネントに分割する必要があります。コード構造はマルチプロセス環境でどのように実行されますか？代わりにマルチスレッド化されますか、それとも異なるサーバーに作業負荷を分散することを心配する必要がありますか？これらは、あなたが最初に行う種類の質問です。
なぜコーディングの前に来るのですか？
それは常にコーディングの前に来るとは限りませんし、少なくとも最終的なデザインはそうではありません。設計が機能するかどうかを判断するために、プロトタイプを作成する必要がある場合があります。プロトタイピングとは、設計段階で分析を実行できない、または実行できないために機能すると思われる設計を選択することです。すべての質問に前もって回答する必要があるという意味ではありません。コードを書くのと同じくらい、デザインは反復的なプロセスになる可能性があります。ただし、特定の決定はより広範な影響を及ぼし、後で変更しようとすると非常に費用がかかることを理解する必要があります。モノリシックプログラムをコンポーネントまたはSOA=）に移動すると、非常に費用がかかります。言語を変更するかどうかを決定することは、非常に費用がかかる決定です。後の行で。
ほとんどの方法論では、ソフトウェアのライフサイクルにさまざまな段階があります。それはすべて、選択した方法論に依存します。しかし、それらのほとんどの要点は、計画、設計、コーディング、実装/展開、そして保守です。しかし、それぞれの価値を調べるために、それぞれを確認する必要があります。
設計とは、プロジェクトをどのように構造化するかを考えることです。サブシステム、コンポーネント、モジュールだけでなく、それを構成するクラス、関数、変数も考えます。コードを書き始める前に、頭の中で関数やクラスのレベルで、場合によっては非常に薄い形で何らかのデザインを行いますが、デザインを頭に入れずに何かを書くことはできません。
設計フェーズで行われる設計は通常、システムレベルで行われます。そこでは、製品を構成するサブシステムの種類（たとえば、Web +データベースサーバー）または主要コンポーネント（ユーザー管理、オーディオなど）を決定します処理、データベース抽象化など）。これらの高レベルの抽象化は、責任を分割し、プロジェクトのスケジュールを立て、記述されるコードの主要な構造を提供するのに役立ちます。
しかし、デザインは必ずしも特定のフェーズではなく、抽象化のさまざまなレベルで何度も何度も行われるものです。そして指摘したように、コーディングの際に多くのことを学び、デザインの一部を変更する必要があるかもしれません。また、前述の設計フェーズで定義された主要な抽象化は、一般に、コードレベルの問題の影響を受けないように十分に高い抽象化に基づいています。
私の経験では、デザインはソフトウェア開発の最も重要なフェーズの1つであり、特に大きなプロジェクトの場合はそうです。
ウィキペディアはソフトウェア設計を次のように定義しています。
ソフトウェア設計は、ソフトウェアソリューションの問題解決と計画のプロセスです。ソフトウェアの目的と仕様が決定したら、ソフトウェア開発者は設計者を設計または採用して、ソリューションの計画を作成します。低レベルのコンポーネントとアルゴリズムの実装の問題、およびアーキテクチャのビューが含まれています。
最初はパスが単純明快であるように見えても、多くの問題に遭遇しました。設計に時間を費やすことで、開発中に発生する可能性のある問題を予測できるため、時間を節約できます。
還元主義者であり、できるだけ簡単で実用的であるようにするには、analysis、design、およびimplementationを、行動。
分析とは、特定のプラットフォームについて考えることなく、プロジェクトの全体的な側面について考えるときです。たとえば、Webサービスを使用するかどうか。ユーザー名の代わりにメールを使用するようユーザーに強制しますか？試用期間はどのくらいですか？どの支払いゲートウェイをサポートする必要がありますか？これらは分析の質問ですこれはプラットフォームやプログラミング言語とは関係ありません。
決定したら、次のステップは設計する、またはプログラミング言語、プラットフォーム（Linux、Windows、iOS）を選択する、設計パターンを選択する、設計の全体的なアーキテクチャを考えるプロジェクト（データアクセス層の作成など）。 デザインはプラットフォームから抽象的ではありません。
次に、設計ドキュメントを開発者に渡し、開発者はそれらのドキュメントを実際のコードに変換する必要があります。