Описание алгоритма для разработчика, Что и как правильно требовать разработчику от алгоритмиста? Опции

[novartis]

Суть вопроса: Что и как правильно требовать разработчику от алгоритмиста?

По работе занимаюсь реализацией ЦОС алгоритмов на ПЛИСах.
Процесс разработки внутри отдела протекает следующим образом.
Имеется сектор алгоритмистов, которые на основе ТЗ на НИР, ОКР придумывают алгоритмы.
Чаще всего они обкатывают эти алгоритмы на моделях в Матлаб.
В результате своей работы они приносят в наш сектор разработчиков-программистов документ под названием "Описание алгоритма ...".
Этот документ обычно выглядит как то так:

Введение:
космические корабли бороздят просторы вселенной...

Входные данные:
А - массив на 1000 элементов (что за элементы, какого типа, какой разрядности?)
K - переменная для цикла (очень полезная информация)
с - скорость света
и т. д.

Основная часть:
переписывают листинг программы на матлабе на русский язык

Выходные данные:
В - массив на 1000 элементов (что за элементы, какого типа, какой разрядности?)


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

Но в конце концов точно такой же алгоритм даже без тех самых уточнений приносят на подпись.
Начальство умоляет подписать, так как срочно (ну как всегда) требуется хоть чем то отсчитаться.
И все вокруг уверяют, что это только первая версия, предварительная, и потом выйдет настоящий полный алгоритм.
А потом про это все забывают, кроме реализатора, то есть меня.

Что-то много букав написал. Суть вопроса вот в чем.
Нашел я ГОСТ 24.211-82 Требования к содержанию документа "Описание алгоритма".
Пролистал, проникся, зародилась у меня идея, каждый раз, когда приносят мне на ознакомление очередной алгоритм, требовать от его автора соблюдения этого стандарта. Одно смущает, ГОСТ старенький (я не в теме, этот советский гост все еще действителен у нас в современной России?) и относится он к АСУ (лучше бы конечно что-то обобщенное).
Может кто подскажет, что посвежее или потематичнее.

Может так же кто поделится своим опытом взаимодействия с коллегами внутри предприятия.

[yes]

в такой годный тред хочется немного набросить

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

но нужно добавить, что такие алгоритмисты (не идиоты же они) имеют опыт реализации алгоритмов и понимают сколько ресурсов ПЛИС и/или процессора потребует задача, если же что-то новое, то могут правильно сформулировать вопросы для оценки ресурсов

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

[SM]

это я к тому, что мне кажется, что работа по адаптации алгоритмов - ну там разрядности данных, разворачивание "программ" на ПЛИС и т.п. в сфере деятельности "программиста", а нагружать этим алгоритмиста - это ...

Если руководствоваться такими принципами - то разные реализации одного и того же алгоритма (ну, допустим, g.729, или h.264, ну и т.п.) окажутся совершенно несовместимы друг с другом, и одинаковые входные потоки начнут генерировать совершенно разные выходные Это будет бардак и анархия

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

[yes]

Если руководствоваться такими принципами - то разные реализации одного и того же алгоритма (ну, допустим, g.729, или h.264, ну и т.п.) окажутся совершенно несовместимы друг с другом, и одинаковые входные потоки начнут генерировать совершенно разные выходные Это будет бардак и анархия

знакомые сильно работали в области IEEE 802.11 (в 90-е делали азики в США), так там все точно так и было, несмотря на толстенную кучу бумаг от ieee
по слухам и с блютусом то же самое было поначалу - между собой могло общаться только оборудование одного производителя

естественно, я не спорю, что методология должна быть и тестовые вектора и интерфейсы/протоколы/методологии

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

то есть понимает как работает система, предположительно, сложная система

----

Ну если Вы реализовали (а значит и разобрались!) хотя бы один раз новый алгоритм, то больше алгоритмист и не нужен. Патентный поверенный нужен, системный и прикладной программисты ошибки исправлять нужны, заведующий производством нужен, тестировщик нужен, продажник толковый нужен. А вот алгоритмист - нет: "До свиданья, с Вами было приятно сотрудничать. Не забывайте, пожалуйста, про соглашение о неразглошении. Выход там - Вас проводят". И это реальные отношения в коммерческом секторе.

это вроде как и непротиворечит высокой оплате труда алгоритмиста?

а так, после запуска производства, нужен отдел продаж и, возможно, саппорт.

но если контора как-то пытается держаться на плаву - то есть производить новые и новые приборы и применять новые принципы/алгоритмы, то нужно новые методы/приборы разрабатывать, опережать конкурентов - это вроде как объясняет почему алгоритмист в состоянии загрузить кучу "программистов" работой

--------

на всякий случай - я то "программист", то есть могу имплементировать задачи если мне объяснят - преимущество, отсутствие узкой специализации, то есть с трудоустройством проще, чем у алгоритмиста, но некая зависть к ним все-таки имеется