全體のデザインと詳細(xì)なドキュメントの作成方法

総設(shè)定と詳細(xì)設(shè)定の両方に含まれるべき部分：

（1）需要：一般的に製品の言語(yǔ)で説明していますが、これは製品をコピーすることができます。

におけるstory list部分。

（2）名詞解釈（オプション）：関連分野でない學(xué)生は文書を見(jiàn)て事前に知っておく必要があるいくつかの概念的性質(zhì)のものを見(jiàn)なければなりません。

（3）

：機(jī)能目標(biāo)と性能目標(biāo)に分けられ、機(jī)能目標(biāo)は一般的に製品のニーズに関する技術(shù)記述であり、性能目標(biāo)は製品から與えられたデータに基づいて性能を評(píng)価する。

一般的に、新しいサービスは性能目標(biāo)が必要です。性能目標(biāo)は設(shè)計(jì)案に影響を與えるかもしれません。

全部含まれるべき部分を除いて、全體的なデザインは一般的に含まれています。

（1）システムアーキテクチャ：一般的には簡(jiǎn)単なアーキテクチャ図があり、テキストでアーキテクチャを簡(jiǎn)単に説明するために配置される。

（2）モジュール概要：アーキテクチャ図に多くのモジュールがある場(chǎng)合、各モジュールの機(jī)能を簡(jiǎn)単に紹介する必要がある。

（3）設(shè)計(jì)と折衷：設(shè)計(jì)と折衷は全體設(shè)計(jì)の中で最も重要な部分である。

(4)潛在リスク(オプション)

全體設(shè)計(jì)を出力する時(shí)、多くの方案はまだ確定していないので、設(shè)計(jì)審査會(huì)議で確認(rèn)する必要があります。

全體の設(shè)計(jì)の重點(diǎn)は「方案折衷」で、全體の設(shè)計(jì)審査が終わった後、すべての方案が確認(rèn)されたはずです。各モジュールの詳細(xì)設(shè)計(jì)を出力する必要があります。

詳細(xì)設(shè)計(jì)のポイントは「詳細(xì)」です。

（1）全體設(shè)計(jì)の結(jié)論まとめ（オプション）：全體設(shè)計(jì)で合意した結(jié)論には簡(jiǎn)単な概要があり、詳細(xì)設(shè)定はこれらの結(jié)論の実現(xiàn)であることを説明する。

（2）インタラクションの流れ：簡(jiǎn)潔なインタラクションは文字で説明でき、複雑なインタラクションの提案はフローチャート、インタラクション図または他の図形を使って説明することができる。

（3）データベース設(shè)計(jì)：これは総設(shè)計(jì)に置くべきですか？それとも詳細(xì)設(shè)定に置くべきですか？

（4）インターフェース形式：データベース＋インターフェース＋プロセスがあり、他の學(xué)生が詳細(xì)設(shè)定文書を入手すれば、ほぼ解決できます。

（5）その他の詳細(xì)：例えば數(shù)式など。

理論的に詳細(xì)設(shè)計(jì)を出力した後、誰(shuí)がこの詳細(xì)設(shè)定文書を入手しても、このプロジェクトを完成させることができます。

実踐共有:

一、大図

（1）大システムや複雑な流れは、そのフレームの構(gòu)図やフローチャートが非常に大きく、常にA 4用紙やwordのページよりも大きいので、wordに直接図形を貼るのはよくないです。貼ってもよく見(jiàn)えません。図をwikiに置くと、ドキュメントに直接リンクすることを勧めます。

（2）visoまたは他の図形のソースファイルを必ず保存してください。そうでないと、今後変更したら描き直します。価格は予想できます。

二、設(shè)計(jì)と折衷

（1）設(shè)計(jì)と折衷は総設(shè)計(jì)の中で一番重要な內(nèi)容で、総設(shè)計(jì)審査中、主にこれらの折衷の優(yōu)劣を討論します。

（2）審査後、メールで結(jié)論を周知するだけでなく、全體の設(shè)営の中で更新し、最終的にどの方案を使用したのかを説明します。なぜこの方案を使用したのですか？自分の経験によって、他人のモジュール、プロジェクトを引き継いで、コードとドキュメントを入手して、設(shè)計(jì)案は私にとって完全に謎です。

（3）時(shí)には期限を決める或いはその他の原因のため、最適な設(shè)計(jì)方案を採(cǎi)用したとは限らなくて、この時(shí)は更に総括的な設(shè)定の中で方策決定の過(guò)程と原因を記録すべきです。

（4）最後に、設(shè)計(jì)折衷はとてもいい自己弁護(hù)の機(jī)會(huì)です。プロジェクトの進(jìn)捗狀況や歴史的な問(wèn)題が殘っているため、このような設(shè)計(jì)を取らざるを得なくなりました。

三、性能目標(biāo)

性能目標(biāo)は新

必要不可欠な一部であり、多くの項(xiàng)目が性能に大きな影響を與える場(chǎng)合、性能目標(biāo)も書かなければなりません。性能には主に以下の部分が含まれています。

（1）日平均要求：一般的に製品人員からの評(píng)価；

（2）平均QPS：日平均要求は4 w秒で割ったもので、なぜ4 w秒なのか、24時(shí)間が86400秒になり、ユーザの活動(dòng)時(shí)間を晝として計(jì)算すると、2を除いて4 w秒になる。

（3）ピークQPS：通常はQPSの2～4倍で計(jì)算できます。

インターネット會(huì)社では、製品の反復(fù)ブロックは、プロジェクトのサイクルが長(zhǎng)いので、「ドキュメント」という言葉はほとんどないですが、実際には文書を作成して、システムとプロジェクトの將來(lái)のメンテナンスに非常に役立ちます。