記事"インジケーターの開発を依頼するための要件定義を作成する方法"についてのディスカッション

 

新しい記事 インジケーターの開発を依頼するための要件定義を作成する方法 はパブリッシュされました:

最もよくあるトレードシステムの開発の第一歩は、相場行動パターンを識別できるテクニカルインジケーターの作成です。 専門的に開発されたインジケーターを、フリーランスのサービスからオーダーすることができます。 この記事からは、適切な要件定義を作成する方法を学習します。より速く、希望のインジケーターを取得するのに役立ちます.

2番目のステップはジグザグの色です:

  1. 次の条件を満たす3つの連続した HH ポイントを検索します。見つかった各 HH ポイントは、以前のものよりも高くする必要があります。
  2. HH ポイント間で見つかった2つの LL ポイントに対して同じ条件が満たされた場合、2番目の LL が最初のものよりも高い場合は、5つのポイントの間にあるすべてのジグザグの脚を赤で塗ります。
  3. 別の HH および別の LL ポイントが5つのジグザグの頂点の後で見つけられ、前の HH および LL より高い位置にそれぞれ、さらにジグザグの足に青で色を付けます。
  4. 条件が保持される限り継続します。 これは上昇トレンドを示します。
  5. 同様に、pp 1-4 で説明されている LL ポイントとリピート操作の減少を検索します。 これらの足は、下降をマークするために赤で着色する必要があります。


作者: MetaQuotes Software Corp.

 

いくつかのスレッドで議論された結果をもとに、ロボットやインジケーターを注文する際のアンケートのような、顧客向けの記事を書き始めました。インジケーターの注文に関する部分だけで、7ページ以上になってしまいました。そこで、1つの大きな記事ではなく、2つの小さな記事を作ることにしました。1つはインジケーターの注文について、もう1つはロボットの注文についてです。

ご興味のある方は、現在のバージョンに対するご提案、ご要望、ご批判をお寄せください。私の意見では、記事はすでに95-99%できているが、いくつかの点を忘れており、人為的に追加しているかもしれない。

最後の点はまだ完成していません -インジケータの受け入れとテスト - この問題についてはまだ特別な考えはありません。 議論の後、この記事は顧客や取引アプリケーションの開発者が使用できるように、標準的な方法で公開される予定です。 これはまだTORコンストラクタではありませんが、顧客にとって理解しやすい簡単な命令を作るための試みです。

 

これほど理性的で叙情的なhttps://www.mql5.com/ja/articles/235。

最初の投稿では、プランも本質もよくわからない。

Как заказать написание советника и получить желаемый результат
Как заказать написание советника и получить желаемый результат
  • 2011.03.30
  • Andrey Khatimlianskii
  • www.mql5.com
Автоматический трейдинг набирает все новые обороты - выпущен MetaTrader 5 c новым MQL5, успешно прошел Чемпионат по автоматическому трейдингу - Automated Trading Championship 2010, новая версия любимого всеми торгового комплекса активно внедряется брокерами. Да и предшественник "пятерки" - MetaTrader 4 - все еще активно используется сотнями...
 

記事の奇妙な構成 - インジケータのスタイル、色などのデザイン、必要な設定の出力、TORの画面のスタイル、再描画(注文されたロジックが再描画を意味するのであれば、もちろん顧客はそれに気づくべきである)、各ティックでの計算(そして、なぜユーザーはそれを知る必要があるのか?

最も一般的な混乱は、バーの番号付け、バッファとは何か、グラフィカル・オブジェクトとの違い、グラフィカル・オブジェクト上で行う必要がない理由(もちろん可能であれば)、結果のファイルをどのフォルダに置くか、ソースファイルと実行ファイルの違いは何か、ペイントでどこかに描画する必要があるパネルの例があるとよいでしょう。


Rashid Umarov:

エラーが発生した場合、その原因を把握する必要がある。つまり、エラーの原因を究明する必要がある。この場合、スクリーンショットやビデオで状況を示すだけでなく、プログラムや端末自体のログを開発者に提供する必要があります。 したがって、プラットフォームの ログがどこにあるかを知っておくだけでなく、プログラムが具体的に何を出力し、その操作に関するメッセージがどのような形式であるべきかを、あらかじめ利用規約で決めておく必要があります。

いや、まず「何が期待され、なぜこれが期待されたのか」と「何が起こったか-あるバーで、ある値が間違っている」+スクリーンショットでは日付とシンボルがまだ色あせしていることが多い+このすべてに正味......」と書くだろう。しかし、主なものは最初の2つであり、その後、あなたはより多くのログとセットを送信するように顧客に依頼することができます、など、時にはそれは必要ありません。そして、あなたが数週間前に注文し、ちょうど何か間違ったものを見た場合 - 注文へのリンク。多くの場合、メッセージで一般的に1スクリーンショットがポップアップ表示され、何が間違っているとどのような注文を推測する。

 

そして、ここで "小さすぎる図面" - 私はTORで見た場合、私は "なぜこれらの図面?"と言うだろうが、どのような方法で私は彼らの設計に干渉しない。多くの場合、それはこのようなTORで発生し、ピーク、谷などを描画し、顧客は何とか魔法のようにプログラマが自分の頭の中にあるように明確に定義されていることを期待し、それを探す方法の定義はありません。

私はTORが2つの方法で解釈することができる抽象的な概念であってはならないことを意味する - これは主なものであり、小さな何かがあること - 全く干渉しない

 
o_o:

おそらく、私がこれまで見た中で最もクレバーで叙情的なhttps://www.mql5.com/ja/articles/235

最初の投稿には、あまり多くのプランがなく、本質が見えている。

歌詞は必要ない。必要なのは、顧客に読んでもらえる ような、かなりドライな文章だ。

私は簡潔に書こうとしましたが、それでもかなり多くのことを得ました。

 
Rashid Umarov:

歌詞は必要ない。お客さんが最後まで読める ような、かなり乾いた文章が必要だ。

手短に書こうとしたが、それでもかなりの分量になってしまった。

もしこの記事が、将来の"mql5マスター"のためにTORを体系化する試みであるならば、削除と削除が必要である。

それが必要な顧客を明確にすることであれば、追加して追加します。


さて、テキストから最終的な目標は明らかではありません。ビューは、 "マスター "の画面から作品のように、スタイルを示唆し、得たようなものです。

そして、説明的な記事のために、それは全く適していません

 
Galina Bobro:

インジケータのスタイル、色などのデザイン、必要な設定の出力、TORの画面のスタイル、再描画(注文されたロジックが再描画を意味するのであれば、もちろん顧客はそれに気づくべきである)、各ティックでの計算(そして、なぜユーザーはそれを知る必要があるのか?


つまり、計算を減らすことができるのであれば、そうすべきなのは明らかです:

  1. 2本の赤い線と1本のヒストグラムを描く
  2. ヒストグラムは、このようなアルゴリズムに従って色を変える。
  3. インジケータは、このような価格とインジケータを使用する。
  4. 計算はバー・オープンのみで行う。
  5. 入力パラメータの構成と名前はこうでなければならない。
  6. 色が変わったらプッシュを送る
  7. ログにこう書く
  8. コントロールにはこのようなパラメーターのパネルが必要です。
  9. ここに説明付きの写真があります。

請負業者候補はこれを見て、TORの文章を長々と検討することなく、すぐに人件費を計算し、工事の初期費用を提示するだろう。

つまり、請負業者が潜在的な注文を処理しやすくするためだ。例えば、マクドナルドで注文をするとしよう。

 
Rashid Umarov:

請負業者候補は、TORの文章をじっくりと検討することなく、視察し、人件費を計算し、仕事の初期費用を提示するだろう。

それは、請負業者が潜在的な注文を処理しやすくするためである。例えば、マクドナルドが注文をするとしよう。

ここでは、実行者として私はそれが無駄であると言う、顧客との他の問題である。そして、あなたが合うようにそこに。

インジケータの主なものは何ですか?ライン、ギトグラム、色、カウント方法(プログラマーが知るべきで、顧客が知るべきでない)、アラート(警告)やフラッフィングではなく、顧客がインジケーターに何を込めようとしているのか、インジケーターの助けを借りて何を得たいのか、インジケーターはどのような機能を果たすべきなのかを論理的に説明することだ。そうすれば、顧客はそれを十分に説明することができ、残りの部分は後で合意することができる。ただし、パネルの存在と機能については事前に知っておくべきで、そこでどのような外観を持つかは後で学ぶことができる。

そして、あなたはそれをすべて逆に持っている、ロジックはまったく言及されていない......。

 
o_o:

何が必要かを顧客に説明するためであれば、追加、追加。

結局誰も読まないんじゃないかと思う。ほとんどの人はゴールまでたどり着けないだろう

 
Galina Bobro:

インジケーターで重要なことは何でしょうか?線、ギトグラム、色、カウント方法(これは顧客ではなく、プログラマーが知るべきです)、アラート(警告)、フワフワしたものではなく、ロジック(論理)、顧客がインジケーターに何を込めようとしているのか、インジケーターの助けを借りて何を得たいのか、インジケーターはどのような機能を果たすべきなのか、などです。

そして、あなたはロジックについてまったく何も語らない......。

論理 - ここでテンプレートを思いつくのは難しい。あなたの経験では、どのように形式化するのですか?