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

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

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

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

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

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


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

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

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

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

Когда-то это все было обязательным, потому и спутники падали реже.

http://ru.wikipedia.org/wiki/%D0%95%D0%B4%...%86%D0%B8%D0%B8

http://www.standards.ru/collection.aspx?co...r&id=868075

Мой опыт говорит следующее. Если Вас не устраивает то, как происходит работа сейчас, то смело меняйте правила игры. Даже не оглядываясь на ГОСТ.
Делается так.
Берете пару старых заданий и на их примере делаете формализацию требований так, как именно Вам удобно.
Скажем, делаете несколько таблиц, и названия для нужных разделов. В примерах показываете, как надо заполнять задание...
Потом объясняете своему руководству, что если делать "не так", то есть большие потери времени...
После того, как начальство утвердит проект, как "методику составления ТЗ", будете требовать от алгоритмистов правильной для Вас работы...
В этом ничего сложного нет... Главное, сделайте официальный документ и заручитесь подписью руководства.
Будут вопросы, могу объяснить по скайпу... А буквами - долго...

добавлю к словам iosifk
здесь только договариваться с программистами-алгоритмистами, в свое время я так и поступил...
Объяснил алгоритмисту, что работаю на ПЛИС и что ПЛИС сильно отличается от интел микропроцессора
Да, я убил много времени на объяснение, зато потом мне начало приходить вменяемое ТЗ и где-то помощь в плане реализации (блок-схема - видение программиста, данные для тестбенчей и т.д.)
Через начальство можно и нужно, но прежде необходимо подробно объяснить программистам-алгоритмистам, что ПЛИС сильно отличается от интел микропроцессора и так чтобы они поняли эту разницу. Например, еще можно рассказать про
- Применение типов float и fixed point в алгоритмах и про их реализацию в ПЛИС.
- что цикл в ПЛИС представляется FSM (плюсы и минусы применения)
- как в ПЛИС делается реалтайм обработка и за счет чего достигается
- чем больше расскажите потом же Вам лучше будет....
Возможно, это очевидные вещи, но лучше про них все же упоминуть... и добиться понимания целевого применения алгоритма в "железе", т.е. в ПЛИС
Иначе на мой взгляд ничего не получите - Вы их сегодня "прижмете", а они Вас завтра - лучше попытаться решить этот вопрос "полюбовно"...

novartis
Видимо, дело тут в том, что Ваши алгоритмисты не совсем точно трактуют понятие "алгоритм".
Алгоритм — это набор инструкций, описывающих порядок действий исполнителя для достижения результата решения задачи за конечное число действий.
То есть все эти космические корабли, входные и выходные массивы - это не алгоритм.
Алгоритм неотделим от инструкций (аппаратной платформы). Для разных вычислительных устройств будут разные алгоритмы реализации одной и той же функции.
Соответственно, в круг Ваших обязанностей должна входить и разработка алгоритмов: что-то удобнее реалиазовать на процессоре, что-то на FPGA.
Поэтому следует ввести этап анализа Вами набора реализуемых функций и выдачу ограничений на их реализацию алгоритмистам.
Это отдельная оплачиваемая работа (а главное дополнительное время Вам на обдумывание).
Результатом работы алгоритмистов,в этом случае, должна стать потактовая модель.
Попробуйте выйти с таким предложением на руководство.
Фактически, Вам придётся становиться соархитектором системы (заместителем ГКР). Что Вам и предложили уважаемые iosifk и Maverick.
Ну а конвейеризация RTL и упаковка - это уже Ваше, родное.
Тогда есть шанс сделать всё успешно и вовремя.
Иначе будут только бесконечные дрязги: ГОСТ, к сожалению, не регламентирует полноту (подробность, степень детализации) документов, он описывает только формальные требования.
Полноту определяет ГКР.
Р.S. Столкнувшись однажды с описываемой Вами ситуацией набил много шишек, пытаясь опираться на формальные ГОСТы. Ничего не вышло - пришлось поучаствовать в проектировании архитектуры.
Удачи.

Что-то не стыкуется.
В Mаtlab-е не может быть переменных с неизвестным типом.
Алгоритмы на языке matlab-а это вообще стандарт де-факто.
Зачем их еще на что-то переписывать?

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

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

В Матлабе по умолчанию переменные имеют тип double (64-разряда).
До недавних пор алгоритмисты об этом даже не знали и не задумывались.
Абстрактный пример. Приносят алгоритм, в котором упоминается массив на 1000 элементов. Спрашиваю, что за элементы? Это углы поворота антенны. А какой диапазон углов? Ну, как какой, от 50 до 50. Сколько знаков после запятой? Не знаю. Так сколько? Ну пусть будет 5. В результате делаю пометку в алгоритме. Через n-человека-часов их алгоритм реализуется, приношу результаты расчета там-чего-то и слышу, что то как то плохо, у нас на модели точнее получалось, ты наверно ошибку какую допустил.
После разбора нескольких таких ситуаций все таки вынудили их прописывать тип переменных, диапазон возможных значений.
Но! Они прописать то это прописывают, но в модели это никак не учитывают. Как считалось на дабле, так и считается.
Разговор о том, что алгоритмисты должны учитывать погрешность вычислений на различных платформах, рассчитывать доверительные интервалы для контрольных результатов, ведется уже давно. И тут видимо опять, пока я сам за это не возьмусь, пока сам не разработаю методику, не натыкаю носом докторов наук в эту методику (спорить с доктором тех. наук очень сложно, у него железный аргумент: он доктор, а я - нет), дело с места не сдвинется.


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

Ну вот так яснее.
Опять спор кто умнее.
В Matlab есть любые целочисленные типы с плавающей и фиксированной запятой.
Я все таки склоняюсь, что алгоритмисты умнее. Уж извините, но ваш пост сильно провоцирует.
Если они применили double, значит алгоритм очень медленный и они при желании смогли бы сами сгенерировать исходники в Matlab для какого нибудь дешевого ARM-а.
А если кодер сломя голову бросается это сразу делать на FPGA поскольку ничего кроме них не знает, то это уже его личная проблема.

Простой контрольный вопрос: почему сами не взяли модель в matlab и сами не верифицировали свой алгоритм в режиме Hardware-in-the-loop?

Позвольте я отвечу на этот вопрос.
Все дело в разделении труда и в величине фирмы...
Вот например, когда я работал в ЛОНИИС, там было 3 сектора математиков и 1 программистов. Ну и разработчики железа...
Так зачем же мне было заниматься еще и алгоритмами? А алгоритмы связаны с протоколами связи. Так значит надо и их изучать? А для этого был и соответствующий секор и там тоже требуются совершенно разные знания. Вот потому алгоритмисты отдельно, "железячники" - отдельно...
И не "умнее" алгоритмисты, увы... Просто здесь не рассмотрен еще один аспект. Чтобы хорошо делать свой кусок работы, надо понимать заказчика и уметь говорить с ним на его языке. Когда делали управление для газоперекачивающей аппаратуры для полигона в 80-е, то до тех пор, пока наши программисты не научились понимать химиков-технологов, то дело и не шло.
Так и здесь. Ну скажем, есть алгоритм. Но его же по разному можно реализовать. И для этого надо либо заставить это сделать заказчика, либо уметь это делать самому...
Да, в мелкой фирме, где один и швец и жнец и разработчик, то и говорить нечего...

Из каких моих слов вы взяли, что я кому то приписываю низкий интеллект?


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



Зачем вы это написали? Вы считаете меня именно таким кодером? Хотите дать мне понять, что мне не стоит задавать вопросы на форуме - месте, где люди обмениваются опытом, знаниями?



Последнее мое взаимодействие с алгоритмистами сводилось к задаче поиска собственных чисел и собственных векторов.
Знаете какая модель у них была?
[V0,D0] = eig(A0)

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


У меня так же будет простой контрольный вопрос: вы мой пост читали?

А вы пишите:

Если солнце всходит и заходит, значит солнце вращается вокруг земли.

Novartis Вы пытались разговаривать с алгоритмистами? Обсуждали проблемы с которыми Вы сталкиваетесь? Рассказывали алгоритмистам свои "пожелания" при предоставлении Вам алгоритмов?
просто совет попробуйте решить вопрос дипломатически не прибегая к помощи руководства....
Не получиться - примените "грубую силу" - решение проблему через руководство...


мое мнение 100% работающую методику создать очень сложно...


PS Почему? - ответил выше...

Novartis без обид, но с сообщением AlexandrY:


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



Все стало понятно - да прибудет с Вами сила...
Тогда понятно доктор просто не хочет ничего понимать - алгоритм сделан, полученная погрешность в пределах допустимой (матлаб - это показал) и дальше ему "все равно" или/и просто отказывается понимать целевое применение алгоритма в "железе"... Формально ж работа сделана и тут скорее всего проблема в финансах (зарплате профессора)...
PS Пока руководство с ним не договорится Вы ничего не измените... Мой опыт это показал...

Обид нет, одно негодование Надеюсь, на меня тоже никто не обиделся.


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




Спасибо, iosifk, все так, как вы и расписали.

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