Обсуждение статьи "Как составить Техническое задание при заказе индикатора"

Трейдеры ищут закономерности в поведении рынка, указывающие на благоприятные моменты для совершения торговых сделок. Чаще всего первым шагом при разработке торговой системы является создание технического индикатора, который помогает увидеть на графике цен нужную ему информацию. Статья поможет вам составить Техническое задание для заказа индикатора во Фрилансе.

Каждый индикатор отражает какую-то идею. Поэтому сначала необходимо описать идею — словами и картинками, если это возможно. Без объяснения идеи понять, чего именно хочет Заказчик, будет намного сложнее.

Теперь можно приступать к описанию самого алгоритма работы/вычисления/отображения индикатора. Описывайте в виде последовательных операций, в виде алгоритма. Ведь только при наличии алгоритма Разработчик сможет написать код по нему. Если в описании идеи или алгоритма есть термины — четко опишите их, чтобы быть уверенными в том, что обе стороны одинаково понимают их значение.

По возможности четко нумеруйте и выстраивайте этапы алгоритма в той последовательности, как это будет потом работать. Не перескакивайте с одной части Технического задания на другую, не описав цельный законченный блок/модуль/этап Технического задания.

Для описания терминов лучше использовать списки, например:

1. дневной диапазон — расстояние между максимальной и минимальной ценой в течение дня;
2. средний диапазон — среднее значение дневного диапазона за N дней;
3. проторговка — диапазон цен в течение дня, где проходили наибольшие объемы сделок;
4. .

Для обозначения этапов можно использовать цифры, списки и жирный шрифт.

Постарайтесь выстроить описание Технического задания в виде ряда действий, проистекающих последовательно одно за другим — в том же порядке, в котором будет исполняться программа, реализующая ваш индикатор. Ниже даны несколько примеров Технического задания.

По результатам обсуждений в нескольких ветках начал писать для Заказчиков статью, которая была бы неким опросником при заказе робота или индикатора. Прошел только часть про заказ индикатора, оказалось уже больше 7 страниц. Поэтому решено вместо одной большой статьи сделать две поменьше - одна про заказ индикаторов и вторая про заказ робота.

Прошу всех заинтересованных высказывать здесь предложения/пожелания/критику текущей версии. На мой взгляд статья уже на 95-99% готова, но вполне допускаю, что какие-то моменты забыл, а какие-то искуственно притянул.

Не закончен последний пункт - Приемка и проверка индикатора - пока особых мыслей на этот счет нет. После обсуждения статья будет опубликована штатным образом, чтобы ею могли пользоваться Заказчики и Разработчики торговых приложений. Это еще не конструктор по составлению ТЗ, но уже попытка сделать простую понятную для Заказчика Инструкцию.

наверно толковей и лиричнее чем https://www.mql5.com/ru/articles/235 еще не видел

Тут в первом посте чет не очень план и суть просматривается

• 2011.03.30
• Andrey Khatimlianskii
• www.mql5.com

Странная структура статьи - никогда не было проблем (в заказах разумеется) со стилями индикаторов, цветами и пр. оформлением, с выводом нужных настроек, со стилями оформления скринов в ТЗ, перерисовками (если логика того что заказывают подразумевает перерисовки то ясное дело заказчик должен быть вкурсе), вычислениями на каждом тике (и зачем это знать юзеру?) - и так понятно что если можно сократить вычисления, то нужно именно так и делать.

Самое частое что путают - нумерация баров, что такое буфферы и чем они отличаются от граф.объектов, почему не нужно делать на граф.объектах (если это возможно, конечно), в какую папку ложить полученный файл, чем отличается исходник от исполняющего файла, хорошо бы чтоб еще примеры панели что нужна рисовали где-то в пейнте, а то в основном звучит "мне нужны три кнопки чтоб открывало, закрывало и чет еще".

При возникновении ошибки необходимо понять причину её появления. А значит, нужно попытаться получить все детали для расследования. В этом случае нужно не только показать ситуацию с помощью скриншотов или видео, но и предоставить разработчику логи программы и самого терминала. Поэтому вы должны не только знать, где находятся Журналы платформы, но и заранее в Техническом задании определить что именно должна выводить программа и в каком формате должны быть сообщения о её работе.

Не, для начала бы писали "что ожидалось. почему именно это ожидалось" и "вот что получилось - на каком-то баре какое-то значение не так" + на скриншоте дата и символ еще часто затертые + сет бы к этому всему. Но главное первые две вещи, а потом можно и попросить заказчика прислать еще лог и сет и т.д., иногда этого не нужно. А если еще заказывали несколько недель назад и только увидели что-то не так - ссылку на заказ. Часто вообще в сообщениях один скриншот вылазит и догадайся что не так и что за заказ вообще.