Diskussion zum Artikel "Wie man eine Anforderungsspezifikation bei der Bestellung eines Indikators erstellt"
Basierend auf den Ergebnissen der Diskussionen in mehreren Threads habe ich begonnen, einen Artikel für Kunden zu schreiben, der eine Art Fragebogen für die Bestellung eines Roboters oder Indikators sein soll. Ich bin nur den Teil über die Bestellung eines Indikators durchgegangen, es stellte sich heraus, dass es mehr als 7 Seiten sind. Deshalb habe ich mich entschlossen, statt eines großen Artikels zwei kleinere Artikel zu schreiben - einen über die Bestellung von Indikatoren und den zweiten über die Bestellung eines Roboters.
Ich bitte alle Interessierten, hier Anregungen/Wünsche/Kritik an der aktuellen Version zu äußern. Meiner Meinung nach ist der Artikel bereits zu 95-99% fertig, aber ich habe vielleicht einige Punkte vergessen und einige künstlich hinzugefügt.
Der letzte Punkt ist noch nicht fertig - Abnahme und Testen des Indikators - dazu gibt es noch keine speziellen Gedanken. Nach der Diskussion wird der Artikel in einer Standardform veröffentlicht, so dass er von Kunden und Entwicklern von Handelsapplikationen verwendet werden kann. Dies ist noch kein TOR-Konstruktor, aber es ist schon ein Versuch, eine einfache Anleitung für den Kunden verständlich zu machen.
Ich habe wahrscheinlich noch nie eine vernünftigere und lyrischere https://www.mql5.com/de/articles/235 gesehen .
Der erste Beitrag zeigt nicht wirklich den Plan oder das Wesentliche davon.
- 2011.03.30
- Andrey Khatimlianskii
- www.mql5.com
Seltsame Struktur des Artikels - es gab nie Probleme (in Aufträgen, natürlich) mit Indikatorstilen, Farben, etc. Design, mit der Ausgabe von notwendigen Einstellungen, mit Stilen von Bildschirmen in der TOR, Redraws (wenn die Logik dessen, was bestellt wird, impliziert Redraws, dann natürlich der Kunde sollte sich dessen bewusst sein), Berechnungen auf jedem Tick (und warum muss der Benutzer es wissen?) - es ist klar, dass, wenn Sie Berechnungen zu reduzieren, sollten Sie es auf diese Weise tun.
Die häufigste Verwirrung ist die Nummerierung der Balken, was sind Puffer und wie unterscheiden sie sich von grafischen Objekten, warum es nicht notwendig ist, auf grafischen Objekten zu tun (wenn es möglich ist, natürlich), in welchem Ordner die resultierende Datei zu setzen, was ist der Unterschied zwischen der Quelle und ausführbare Datei, wäre es gut, dass Beispiele für das Panel, das Sie brauchen, um irgendwo in Farbe zu zeichnen, weil es klingt meist "Ich brauche drei Tasten zum Öffnen, Schließen und etwas anderes".
Wenn ein Fehler auftritt, ist es notwendig, die Ursache für sein Auftreten zu verstehen. Das bedeutet, dass Sie versuchen sollten, alle Details für die Untersuchung zu erhalten. In diesem Fall sollten Sie die Situation nicht nur mit Screenshots oder Videos zeigen, sondern dem Entwickler auch die Protokolle des Programms und des Terminals selbst zur Verfügung stellen. Sie sollten also nicht nur wissen, wo sich die Plattformprotokolle befinden, sondern auch vorab in der Aufgabenstellung festlegen, was genau das Programm ausgeben soll und in welchem Format die Meldungen über seinen Betrieb sein sollen.
Nein, am Anfang würden Sie schreiben "was erwartet wurde. warum dies erwartet wurde" und "hier ist, was passiert ist - auf irgendeinem Balken ist irgendein Wert falsch" + auf dem Screenshot sind das Datum und das Symbol noch oft verblasst + netto zu all dem.... Aber die Hauptsache ist, die ersten beiden Dinge, und dann können Sie den Kunden bitten, mehr Log und Set, etc. zu senden, manchmal ist es nicht notwendig. Und wenn Sie vor ein paar Wochen bestellt und sah nur etwas falsch - einen Link zu der Bestellung. Oft im Allgemeinen in Nachrichten ein Screenshot erscheint und erraten, was falsch ist und was die Reihenfolge im Allgemeinen.
Und wo "zu kleine Zeichnungen" - ich würde sagen, wenn ich in der ToR sah, "warum diese Zeichnungen?", aber in keiner Weise, die ich nicht mit ihrem Design stören. Oft passiert es in der TOR wie diese und gezeichneten Spitzen, Mulden, etc. und Kunden hoffen, dass irgendwie magisch der Programmierer alle klar definiert, wie in ihrem Kopf, gibt es keine Definitionen, wie man es zu suchen.
Ich meine, dass die TOR sollte nicht abstrakte Konzepte, die auf zwei Arten interpretiert werden können - das ist die Hauptsache, und dass es etwas klein - überhaupt nicht stören
Wahrscheinlich die cleverste und lyrischste https://www.mql5.com/de/articles/235, die ich je gesehen habe.
Hier im ersten Beitrag ist nicht sehr viel Plan und Essenz sichtbar
Man braucht keine Lyrik - man braucht einen ziemlich trockenen Text, der vom Kunden gelesen werden kann .
Ich habe versucht, mich kurz zu fassen, habe aber trotzdem eine ganze Menge bekommen.
Sie brauchen keine Texte - Sie brauchen einen ziemlich trockenen Text, den der Kunde zu Ende lesen kann .
Ich habe versucht, mich kurz zu fassen, aber ich habe trotzdem eine ganze Menge.
wenn dieser Artikel ein Versuch ist, für den zukünftigen"mql5 master" die TOR zu systematisieren, dann ist es notwendig, zu entfernen und zu entfernen
wenn es darum geht, dem Kunden zu verdeutlichen, was benötigt wird, dann hinzufügen und hinzufügen.
Jetzt aus dem Text ist nicht klar, das ultimative Ziel. Die Ansicht ist so, wie Stücke aus den Bildschirmen der "Master" bekam, angedeutet Stil.
Und für einen expositorischen Artikel ist er überhaupt nicht geeignet
Seltsame Struktur des Artikels - ich hatte nie Probleme (natürlich in Aufträgen) mit der Gestaltung von Indikatoren, Farben usw., mit der Ausgabe der notwendigen Einstellungen, mit der Gestaltung von Bildschirmen im TOR, Redraws (wenn die Logik dessen, was bestellt wird, Redraws impliziert, dann sollte der Kunde das natürlich wissen), Berechnungen bei jedem Tick (und warum muss der Benutzer das wissen?) - es ist klar, dass, wenn man die Berechnungen reduzieren kann, man es auf diese Weise tun sollte.
Die Idee war, dass der Kunde kommt und sagt:"Ich möchte einen Indikator, der:
- zwei rote Linien und ein Histogramm zeichnen
- das Histogramm ändert seine Farbe nach einem bestimmten Algorithmus
- der Indikator soll solche Preise und einen solchen Indikator verwenden
- die Berechnungen sollen nur bei der Eröffnung des Balkens durchgeführt werden
- die Zusammensetzung und die Namen der Eingabeparameter sind so und so
- senden Sie mir einen Push, wenn sich die Farbe ändert
- schreiben Sie in das Log dies und das
- die Steuerung erfordert ein Panel mit solchen Parametern
- hier sind Bilder mit Erklärungen".
Ein potenzieller Auftragnehmer wird sich das ansehen, schnell die Arbeitskosten berechnen und die anfänglichen Kosten für die Arbeit angeben, ohne lange den Text der Auftragsbedingungen zu studieren.
Das heißt, dass es dem Auftragnehmer leichter gemacht werden soll, potenzielle Aufträge zu bearbeiten. Stellen Sie sich vor, Sie geben wie bei McDonald's eine Bestellung auf.
Ein potenzieller Auftragnehmer wird sich umsehen, die Arbeitskosten berechnen und die anfänglichen Kosten für die Arbeiten angeben, ohne den Text der Leistungsbeschreibung lange zu studieren.
Das heißt, um es dem Auftragnehmer zu erleichtern, potenzielle Aufträge zu bearbeiten. Stellen Sie sich vor, Sie geben wie bei McDonald's eine Bestellung auf.
Hier sage ich als Ausführender, dass es sinnlos ist, andere Probleme mit Kunden zu haben. Und da kann man sich entscheiden, wie man will.
Was ist die Hauptsache bei einem Indikator? Nicht Linien, Gitogramme, Farben, wie man zählt (das sollte der Programmierer wissen, nicht der Kunde), nicht Alerts oder Fluffs, sondern LOGISCH genau das, was der Kunde in den Indikator zu stecken versucht, was er mit Hilfe des Indikators erreichen will, welche Funktionen der Indikator erfüllen soll. So kann der Kunde es hinreichend erklären, und der Rest kann später vereinbart werden. Nur das Vorhandensein und die Funktionen der Anzeige sollten im Voraus bekannt sein, und wie sie aussehen wird, kann man später erfahren.
Und bei Ihnen ist es genau andersherum, von Logik ist überhaupt nicht die Rede....
Wenn es darum geht, dem Kunden zu erklären, was benötigt wird, dann fügen Sie etwas hinzu und fügen Sie etwas hinzu.
Ich fürchte, niemand wird es am Ende lesen. Die meisten werden es nicht bis zur Ziellinie schaffen.
Was ist die Hauptsache bei einem Indikator? Nicht Linien, Gitogramme, Farben, Zählweise (das sollte der Programmierer wissen, nicht der Kunde), keine Alerts oder Fluffs, sondern LOGIK, genau das, was der Kunde in den Indikator stecken will, was er mit Hilfe des Indikators erreichen will, welche Funktionen der Indikator erfüllen soll.
Und bei Ihnen ist es genau das Gegenteil, Sie sagen überhaupt nichts über Logik....
Logik - es ist schwer, hier eine Vorlage zu finden. Wie kann man sie Ihrer Erfahrung nach formalisieren?
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Neuer Artikel Wie man eine Anforderungsspezifikation bei der Bestellung eines Indikators erstellt :
Händler suchen nach Gesetzmäßigkeiten im Verhalten des Marktes, die auf günstige Gelegenheiten für die Ausführung von Trades hinweisen. Am häufigsten ist der erste Schritt bei der Entwicklung eines Handelssystems die Erstellung eines technischen Indikators, der es erlaubt, benötigte Informationen im Preischart zu sehen. Der Artikel hilft Ihnen, eine Anforderungsspezifikation bei der Bestellung eines Indikators im Freelance zu erarbeiten.
Die erste Phase — das Zeichnen des ZigZag-Indikators:
Autor: MetaQuotes Software Corp.