Здравствуйте!

Перед тем как передать разработанные Embedded software & Hardware заказчику или в серийное производство, мы должны его протестировать.
Конечно много зависит и от проекта и от доступных средств тестирования.

Как делаем мы:
Пример : Разработка ПО на базе STM32F. Использование Continuous integration вкупе с SVN. Отдел QA сделал Python скрипт для выгрузки и сборки ночью проекта (проект на GCC). Загрузка и запуск на целевой плате через JTAG. Целевая плата подключена к управляемому по USB источнику питания и тестируется с помощью FTDI FT4232H. FT4232H эмулирует I2C, SPI и UART и через скрипты Python оформелны протоколы взаимодействия. Стараемся покрывать, насколько можем, тестами через данные интерфейсы. Также проводим нагрузочное тестирование с помощью данного стенда.

Может есть готове комплексы для тестирования? Как вы организовали у себя?
Поделитесь опытом тестирования ваших продуктов.

А у нас на STM32 все пишет один человек. Поэтому ни Continuous integration, ни SVN, ни сборки не нужны.
Поэтому тестирование I2C, SPI и UART не имеет такой актуальности, делается один раз на этапе освоения платформы.

Спасибо за ваше мнение! Правильно я понимаю, выходной контроль делается также этим человеком? Это же касается Linux/MQX/WinCE разработок?

Добрый день.

Вопрос очень широкий, тестирование - отдельная область, средства и методы сильно различаются в зависимости от объёма произвоства.

Кто-то делает что-то в одни руки, тестирует, соответственно, тоже сам, - а кто-то может себе позволить оснастку с щупами и стенды c PXIe и LabView.

Мне кажется, что ваш подход совершенно адекватен мелкой-средней серии.

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

Делать что-то крупнее в нашем случае совершенно нерентабельно.

Спасибо за ответ. Можете пояснить про стенды PXIe? Как их используют для тестирования?

В серийном производстве достаточно надежной электроники - например блоков управления впрыском для двигателей, различных плат для ездящего и летающего, используются стенды с контроллерами. Стенды могут быть сделаны для чего угодно - от тестирования законченного устройства через стандартные разъемы, до индивидуальных плат с игольчатыми щупами.
PXI - это всего лишь шина, на которой построены контроллеры от National Instruments. Можно взять и другие, но у NI в придачу есть среда Labview, которая как раз специально заточена под создание различных тестов и GUI.
Внизу фотки такого стенда - сверху игольчатый адаптер - внизу PXI контроллер и прочая периферия.
Нажмите для просмотра прикрепленного файлаНажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Вопрос в том - сколько вы готовы вложить в такой стенд? Для простенького устройства цены начинаются от 20k€ и выше.

Стандартный тестовый стенд - их тех, что я видел, обычно состоит из стандартного набора компонентов:
- колодки для подключения теструемого устройства или механического адаптера для установки платы.
- Break Out Panel - обычно такая большая панель, на которую выведены все сигналы устройства и которые там-же можно вручную закоротить или разомкнуь - помогает при поиске неисправноестей
- Signal Conditioning Modules - преобразователи цифровых и логических уровней в/из стандартизированные +-10В, 0...5В. Обычно с гальванической развязкой для моделирования I/O сигналов для тестируемого устройства и проверки его реакции.
- Программируемый блок питания с возможностью изоляции питания.
- PXI или другого промышленного контроллера, который собственно и проводит тестирование. Он также загружает прошивки через jtag и проверяет коммуникационные интерфейсы - Ethernet USB и т.д.
- промышленный компьютер с виндой и LAbView, который собственно управляет всем этим делом и показывает результаты.

Все это дело обычно ставится в стойку или шкаф, чтобы было транспортабельно в пределах производства. Для того, чтобы стенд не выкидывлся после того, как вышло новое изделие, он обычно делается модульно - т.е. все эти преобразователи - одноканальные на DIN-рейку, контроллер - тоже модульный - количество I/O может меняться в широких пределах. Ну и софт - с возможностью быстрой перенастройки стенда на другие тесты в предельно сжатые сроки и без специальных знаний - LAbView. Сейчас вроде как и Матлаб начинают применять.

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

Но так как это единичные случаи - смысла в специализированном стенде я не вижу.

Интересная тема. Хотелось-бы уточнить и расширить
1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
3) Как доказать что RTL также соответствует ТЗ?
Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?
----
Ну а после всего этого можно поговорить и о том какой и где "тестер" нужен.
На одном этапе нужно доказать что всё спроектировано безглюков и работает, а на другом - что спаянная плата соответствует Э3...
То как описано у автора топика похоже на последнее....

----
Есть и универсальное решение PXI Platform ... если денег не жалко....

По моему, эти вопросы выходят за рамки данной темы. Тут речь идет о тестовых стендах, а не о качестве и выборе тестов.

Но, конечно, вопрос а какой стенд нужен ТС, остается открытым.

Стенд нужен тот, который указан в ПМ, которые пишутся на основании ТУ, в объёме ПИ\КИ\ПСИ, а ТУ обязанно опираться на ГОСТ, ОСТ на данный тип оборудования.....
Таким образом "стенд" это может быть и барокамера в которую всуното изделие со штатной программой и работающее как в приложении....

Ежели речь о проверке что всё запаяно правильно и есть контакт (на этапе ПСИ), то тогда можно изготовить тест платку со всеми интерфейсами (иногда можно отделаться нульмодемными заглушками) и зашить в устройство отладочную програмку которая дёргает все провода внутри устройства и выдаёт\принимает посылки на\от внешние порты. Это-же можно добится, внедрив JTAG в плату.

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

так-что вопрос "нужен тестовый стенд" - неоднозначный.

"Тестирование может показать наличие ошибок, но не может доказать их отсутствие" © Э. Дейкстра.

А что Э. Дейкстра знал о test coverage?

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

Вопросы очень(!) правильные, более того, по отношению заказчика к тестированию, также можно понять его уровень и возможности.

syoma, если говорить о сериных продуктах, пробовали ли вы прошивать платы с помощью иголок, Test Points (куда выведен JTAG) и прогонять JTAG Boundary Scan тесты? Если да, то можете поделиться информацией какое оборудование использовали и впечатления от использования?

По поводу JTAG сказать ничего не могу - у нас все лилось по USB и Boundary Scan не было. Поэтому мы все проверяли только функциональными тестами.
Могу более по Signal Conditioning или модульным контроллерам.



Ну если предположить, что система управления требованиями у Вас настроена и работает - что сам по себе уже значительное улучшение культуры разработки, то самое интересное по вашим вопросам(кроме п.4), что я в последний раз видел на Embedded World - это система тестирования требований. Т.е. засовываете в нее свои требования и она каким-то образом прогоняет все варианты, чтобы можно было увидеть, где есть пробелы. Причем это еще до начала проектирования устройства. Я так толком и не понял, как это работает, но вроде работает.
По п.4. - климатика и ЕМС в принципе самое простое - есть стандарты - им надо соответствовать. Если уверены в своем изделии, то лучше всего тесты делать на конечном этапе, чтобы протестировать изделие в как можно близком к серийному варианте, чтобы не было вопросов при сертификации. Если не уверены - делаете промежуточные тесты до конца разработки. Мы, например, в первый раз микросекундные импульсы тестировали задолго до конца разработки на I/O и входе блока питания, чтобы не переделывать второй раз.

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

Что касается когда делать тесты...
Количество и объём тестов во время разработки - соответственно фантазии и квалификации разработчика

Дальше следуем стандарту постановки изделий на производство.
"тесты делать на конечном этапе, чтобы протестировать изделие в как можно близком к серийному варианте, чтобы не было вопросов при сертификации." - называется квалификационные испытания (КИ). Это всё что указано в стандартах предявляющим требования к изделию (в т.ч и пожаробезопасность, и транспортопригодность по дорогах класса "Г", и даже те, что розрушают изделие, и что USB это USB и т.д. и .т.п)
На конечном этапе производства проводятся ПСИ, которые гораздо короче КИ и только гарантируют что изготовлено всё как в чертежах.

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

syoma, как я понял, по USB вы заливаете тестовое Firmware и оно проводит функциональный тест, а PXI считывает и сравнивает реакцию i/o? На каких этапах вы проводите такое тестирование?
Torpeda, у вас написано правильно про изделие в целом. А как тестируете, например, софт для микроконтроллеров, SoC, FPGA на промежуточных этапах?

SoC - это есчё хуже чем изделие вцелом

Если исключить этапы производства и всё что тестируется там, то тестирование по ходу разработки (как часть КИ), называется верификация\симуляция (в среде UVM напр.) и есть соответственные методики и формальные показатели качества (code coverage etc.).
При помощи верификации гарантируется соответствие функциональности изделия требованям ТЗ в основном...

Частично можно проверить раблотоспособность изделия (т.е. софт, всё что зашито в FPGA итд.) на натурных испытаниях (например подключив ваш Ethernet Switch в реальную сеть или к специализированному тестеру Ethernet).
При этом правда, качество теста будет не очень хорошее из-за того, что:
- тест кавередж неизвестен
- тест кавередж скорее не более (70-80)% (это из опыта верификации, т.е. вроде тест бенч написан хороший по смыслу, но когда запускаеш подсчёт coverage, то видиш примерно такое покрытие)

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

При проверке серийных изделий. Прошивок, кстати, две - одна чисто для тестирования железа - дергает пинами, пихает пакеты везде. Вторая - уже рабочая, но ее проверяем только поскольку - поскольку - залилась ли в целом, запускается ли система, поднимаются ли интерфейсы. Реально ее полностью проверить в серийных условиях нет - стенд нужен очень серьезный. У нас этакой стенд есть - это RTDS. Мы софт, а именно алгоритмы управления проверяем на нем. Но только на этапе разработки.

Torpeda, дело в том, что моя позиция по отношению к клиенту это Win-Win, иначе не интересно. Повторно сделать клиенту предложение и получить работу проще, чем найти нового клиента. Но это невозможно, если сделать первый проект, после которого заказчик останется недоволен (Как говорила Фаина Раневская "Деньги съедены, а позор остался"). С другой стороны, если заказчик умышленно не хочет тестировать, то тут вы правы - это его желаение. Однако хочется ли работать с таким клиентом - отдельный вопрос.
syoma, RTDS это rtds.com? Я так подозреваю, у вас богатейший опыт тестирования
Напомнило:

Да, rtds.com.
Но еще раз - это только для отладки алгоритмов управления и демонстрации, что они действительно работают в железе, как задумано. Кстати, как раз на вот эти тесты наши заказчики обычно и прилетают посмотреть. Как там железо тестируется - их обычно мало интересует - это наша проблема. Им достаточно подписаных протоколов. Но у нас специфическая сфера - RTDS просто необходима. Для обычных проектов можно намного более простые вещи найти.

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

Получается интересная система и альтернатива PXI - по железу нужны только модули аналогового и цифрового ввода вывода или коммуникационные (RS242,485 Canopen и т.д) модули EtherCAT. Список различных вариантов большой. К компу подключаются через Ethernet порт. В любой момент конфигурацию можно поменять или дополнить.

Самое интересное в софте - он стоит дофига, но если найти крякнутый TwinCAT...
Тогда Windows PC превращается в real-time симулятор с временами отклика в 1мс и меньше - вплоть до 100µs. При этом TwinCAT позволяет в реальном времени выполнять и Си и PLC код, а самоее интересное - модели из Matlab/Simulink. Т.е. можно нарисовать графически свою обвязку, которая будет имитировать объект управления и запустить в реальном времени на симуляторе, чтобы подопытный контроллер думал, что управляет реальным объектом.
Мало того - можно часть сигналов вывести опять же на те же EtherCAT клеммы, чтобы подключить к той части, для которой есть физический макет, но нет возможности симитировать полностью все нужные сигналы.

Лучше расскажите что вы собственно разрабатываете, а то непонятно как тут прикрутить PC и проч PXI.
Вы представляете что значит написать модель объекта управления?
Это работы на порядки больше чем собственно работы по программированию тестируемого контроллера.

Изобразите-ка модель мотор-редуктора в механической системе с переменными нагрузками, десятками датчиков, управлением по облачным протоколам и системой автономного питания.
А это, кстати, будут обычные ворота.

Кому такое тестирование надо?
И кто будет тестировать тесты?

Железо для тестов это вопрос весьма вторичный.
Главное софт.

с чем именно у вас возникли сложности в моделировании такой системы?

Не знаю, понимаете ли, как предсказать обороты в зависимости от инициализации FlexTimer Module.

syoma, правильно ли я понимаю, что выпускаемые вами изделия достаточно дороги и поэтому вложения в такой тестовый комплекс оправданы?


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


Такое бывает. Особенно если это касается критических систем.

Критические системы потому названы критическими что человек мало о них что знает и боится.
Потому критические системы никак не могут тестироваться на моделях, для них нет адекватных моделей.

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

Вот вам как раз пример такой системы. Тут без тестирования на модели не обойтись, так как на практике один такой тест может полностью лишить света городок средних размеров. А тест нужно сделать обязятельно, так как система как раз и расчитана на такой случай. Иначе что делать? Молиться, что в нужный момент сработает?

Таких проектов всего штук 10 в год будет.

другом случае - это скажем так система управления немного посложней гаражной, но с двумя-четырьмя двигателям, иногда с частотниками на пару десятков датчиков и выключателей и 20-ю различными релюшками. Это производится серийно в количестве до 1000 в год. Кстати сделана на STM32F.

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

Ну покажите уже наконец эти модели в симулинке. Хотел бы я посмотреть.

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

Всем спасибо за ответы.
Интересно, вот например, как тестирует свои контроллеры Овен? А софт для них?
Или РТСофт своё ПО на Embedded Linux/Windows?

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

Спасибо за тему на форуме раскрыл немного свой кругозор в этой теме...

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

Мой начальник с чего-то взял, что макетирование электроники - вчерашний день, хочет рабочую схему с первого раза.
Хотя в прошлом году всё было нормально. Макетировали, раза с 3-4 получалась рабочая схема, потом думали, как ее уместить в требуемые габариты. Никакие доводы не действуют. Видимо, это с него сверху спрашивают.

Что скажете, господа разработчики? Не пора ли мне искать новую работу?

P.S. Текущий проект - DCDC 200-450V -> 12V 250A, ARM STM32.

Хоть рассказали бы предметную область. А то если это МК (ПЛИС) с интерфейсной обвязкой, то, действительно, непонятно, что там макетировать три-четыре раза. А с учётом экономической ситуации, радуйтесь, что начальство решило экономить на макетах, а не на разработчиках.

UPD: А, таки силовая электроника. Мой совет: максимально используйте уже имеющиеся наработки и сократите число итераций до двух. Отчаянные времена требуют отчаянных мер.

он не прав, но тезис

поддерживаю ))

Увеличьте использование симулятора и отладочных наборов. Старые макеты можно модифицировать.
Пробуйте не всю схему макетировать, а только некоторые сложные узлы.

Добавлю информации: разработки стараемся делать по всем правилам: Software design request от клиента, потом пишем: software architecture doc, software development plan, software validation concept, software integration concept, dFMEA, sofware test plan. Для железа: system requirement secification. MTTF - анализ.
Используем инструменты:
1C заинтегрирована со складом плат и радиодеталей. Прошивки для железа тоже с уникальным номером из 1С.
Автоматический анализ кода (ночью, после работы Jenkins) - LDRA tool. Автоматические тесты - Labview + набор простых инструментов, таких как usb-ftdi-uart/i2c/spi, usb-relay.
Дополнительные билд скрипты для git/svn.

Ещё добавлю:

Попробовали Vector HIL (Hardware-in-the-Loop) - замечательная вещь. Взяли в аренду - прогнали тесты - повылазили глюки, которые не должны были.
Заметили, что Static Analysis влияет также и на результат теста с HIL.

По требованию от клиента - делали тестирование в климатической камере, а также механические испытания (1 млн раз нажимали пневматикой на кнопки, чтобы посмотреть как они будут вести себя ).


По поводу убеждения заказчиков:
1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?
--->Как правило с первого раза в ТЗ не укажешь всех нюансов которые вылезут в процессе разработки. Конечно желательно, чтобы заказчик доверял исполнителю и трезво понимал риски. А риски нужно обозначить сразу и предложить варианты решения в случае чего.
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
--->Заказчик делает входной контроль сам. Как минимум- можно предложить репорты из Static Analysis tool, unit test tools
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?
--->Это определяется стандартами которые необходимо поддерживать. Открываем ГОСТ/IEC/ISO и знакомимся. Оттуда берём ссылки на другие стандарты и тд.
Надо приложить усилия, конечно, чтобы распутать все это и сделать то что нужно, с достаточными требованиями.

Скажу что Ваш начальник ИДИОТ.
Даже ГОСТ говорит, что при разработке электронной техники 3 итерации - это норма


Чем выше начальник тем дальше он от реальной жизни. И тем меньше он понимает как жизнь устроена и как делаются дела
Так что не обращайте внимания на придурков

Никому нмчего не докажете, ничего не поможет, кроме смены начальства или работы. Остановить поиски может только:
- Смена руководства / концепции.
- Очень хорошее отношение к вам и вашей работе.
- Хорошая зарплата+премии.
- Комбинация предыдущих пунктов.

Объясните своему начальнику, что количество итераций в процессе разработки изделия определяет только всевышний.
Это его исключительная сфера компетенции, и ни чья больше... Мнения различных начальников, предписания ГОСТов и
прочие хотелки разных людей он не принимает во внимание.

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

Угу, зависит, но не определяет... И от фазы Луны еще зависит...
Что Вы будете делать, если после трех итераций конечный результат не достигнут? А Вы своим приказом установили, что их должно быть не больше трех? Или не больше одной, как в указанном выше случае? Будете назначать виноватых? Или погоните разработчиков в шею, за то что они "неправильно оценили риски"?. Ну-ну...
Успехов Вам в планировании процесса разработки.

Никакой вы не начальник и менеджером вам не стать с такими рассуждениями. Из написанного вами, занимаетесь только обраубанием мотивации работников. Совдепия и только.

Не придирайтесь к словам. Могу перефразировать, если Вам угодно: Количество итераций определяется сложностью изделия, полнотой и реализуемостью технического задания..... Сильно смысл изменился?

Мне нравится Ваш тон. Представляю, как сильно Вы ненавидите своего начальника
В данном случае важно не назначать виноватых, а определить почему так произошло. В чем причина?
Возможно, не хватило экспериментов на этапе предварительно проработки ТЗ, которые не позволили выявить недостатки до того, как начался следующий этап.
Возможно были выбраны неправильные инструменты для решения конкретной задачи
Возможно, не было проведено Design Review на нужном этапе работ.
Возможно, просто недостаток коммуникации между различными разработчиками.
Возможно, не тому инженеру дали не ту работу.
Возможно сам процесс управления проектом разработки построен неправильно или неоптимально. Например, многие сейчас пробуют отойти от классической каскадной Waterfall модели и применять Agile при разработке железа... В принципе оно позволяет немного ускориться, но по моему опыту количество итераций увеличивается(логично)
Возможно неправильно определены риски...
И т.д.

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


О, интересно. Так расскажите тогда пожалуйста чем должен заниматься современный R&D Менеджер. Послушаю, может чего нового узнаю о моей профессии.
Хотя тему ушла в глубокий оффтопик ИМХО.

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

есть такая книга: Роберт И. Саттон - Не работайте с мудаками
Или вот это видео пособие: https://www.youtube.com/watch?v=N-GCWx5tTJs

Господа, вопрос - увязывали ли вы ваши системы тестирования (End-of-line) с JIRA/SVN? Например, чтобы автоматически генерировать отчёты? Или складывать бинарники готовые к прошивке?
Вопрос также с бухгалтерией: Привязка к 1С? (Индекс изделия к прошивке, автоматическая генерация прошивки с проверенного Tag SVN, например )?

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

И это грубая неправда. Разработчику может и казаться, что количество итераций определяется именно господом-богом. Разработчику, в принципе, вообще наплевать - чем больше итераций, тем больше работы, тем слаще жизнь.
Но на самом деле, как я написал выше, на количество итераций в итоге влияет немало факторов, в том числе и подконтрольных человеку. И при правильном подходе к R&D можно получить достаточно высокую вероятность завершения проекта за одну итерацию, а при неправильном сделать так, что и за 10 ничего не выйдет. Естественно, все это относится к конкретному проекту. Для каких-то проектов и 10 итераций будет хорошим результатом, но в этом случае худший вариант может быть сотни и тысячи.

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

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

Ну и как (и кто это будет делать) оБЪЕКТИВНО оценить "реализуемость", "посставленность", "чёткость", "сложность", "риски", "квалификацию"?

А потом. Можно испугавшись начальства сделать и с одной итерации. Но впоследствие "недоведенность/недовылизанность" девайса приведет к таким последствиям (причем, ЧТО САМОЕ СТРАШНОЕ, не сразу, а спустя какое-то время. Такая вот мина замедленного действия), что "мама роди меня обратно".

Хотя, конечно, делать несколько итераций для девайсов уровня "два транзистора три резистора" - маразм. Но я думаю с топикстартера рабовладелец требует "делать за 1 итерацию" не такие "изделия"

Разработчику и/или его начальнику может казаться все, что угодно. Но, в конечном счете, дело обстоит именно так. Нравится Вам или нет.


Это не разработчик. Вот таких надо гнать в шею без всяких итераций.