Версия для печати темы
Нажмите сюда для просмотра этой темы в обычном формате
Форум разработчиков электроники ELECTRONIX.ru _ Управление проектами _ Как тестировать разработанную электронику и встраиваемое ПО?
Автор: SimpleSoft Mar 14 2015, 07:43
Здравствуйте!
Перед тем как передать разработанные Embedded software & Hardware заказчику или в серийное производство, мы должны его протестировать.
Конечно много зависит и от проекта и от доступных средств тестирования.
Как делаем мы:
Пример : Разработка ПО на базе STM32F. Использование Continuous integration вкупе с SVN. Отдел QA сделал Python скрипт для выгрузки и сборки ночью проекта (проект на GCC). Загрузка и запуск на целевой плате через JTAG. Целевая плата подключена к управляемому по USB источнику питания и тестируется с помощью FTDI FT4232H. FT4232H эмулирует I2C, SPI и UART и через скрипты Python оформелны протоколы взаимодействия. Стараемся покрывать, насколько можем, тестами через данные интерфейсы. Также проводим нагрузочное тестирование с помощью данного стенда.
Может есть готове комплексы для тестирования? Как вы организовали у себя?
Поделитесь опытом тестирования ваших продуктов.
Автор: AlexandrY Mar 14 2015, 09:57
А у нас на STM32 все пишет один человек. Поэтому ни Continuous integration, ни SVN, ни сборки не нужны.
Поэтому тестирование I2C, SPI и UART не имеет такой актуальности, делается один раз на этапе освоения платформы.
Автор: SimpleSoft Mar 14 2015, 10:22
Спасибо за ваше мнение! Правильно я понимаю, выходной контроль делается также этим человеком? Это же касается Linux/MQX/WinCE разработок?
Автор: hdl_student Mar 15 2015, 18:04
Поделитесь опытом тестирования ваших продуктов.
Добрый день.
Вопрос очень широкий, тестирование - отдельная область, средства и методы сильно различаются в зависимости от объёма произвоства.
Кто-то делает что-то в одни руки, тестирует, соответственно, тоже сам, - а кто-то может себе позволить оснастку с щупами и стенды c PXIe и LabView.
Мне кажется, что ваш подход совершенно адекватен мелкой-средней серии.
У нас серийность очень мелкая, поэтому обходимся имитаторами интерфейсов средней степени интеграции (как правило, контролируется наличие связи, протокол и обработка ошибок, в общую систему имитаторы, как правило, не завязаны), методика тестирования описана в отдельном документе. Принимает тест ОТК и военные.
Делать что-то крупнее в нашем случае совершенно нерентабельно.
Автор: SimpleSoft Mar 16 2015, 08:24
Спасибо за ответ. Можете пояснить про стенды PXIe? Как их используют для тестирования?
Автор: syoma Mar 16 2015, 21:58
В серийном производстве достаточно надежной электроники - например блоков управления впрыском для двигателей, различных плат для ездящего и летающего, используются стенды с контроллерами. Стенды могут быть сделаны для чего угодно - от тестирования законченного устройства через стандартные разъемы, до индивидуальных плат с игольчатыми щупами.
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. Сейчас вроде как и Матлаб начинают применять.
Автор: syoma Mar 17 2015, 07:14
Вопрос в другом - все эти стенды обычно используются на выходном контроле при серийном производстве. Для контроля при сдаче разработки в производство я особого смысла в таком стенде не вижу.
Нужно просто методически при разработке сразу же разрабатывать и требования и тесты согласно требований. Тогда при сдаче, все это дело будет покрываться.
Но так как это единичные случаи - смысла в специализированном стенде я не вижу.
Автор: Torpeda Mar 17 2015, 10:25
Интересная тема. Хотелось-бы уточнить и расширить
1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
3) Как доказать что RTL также соответствует ТЗ?
Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?
----
Ну а после всего этого можно поговорить и о том какой и где "тестер" нужен.
На одном этапе нужно доказать что всё спроектировано безглюков и работает, а на другом - что спаянная плата соответствует Э3...
То как описано у автора топика похоже на последнее....
----
Есть и универсальное решение http://electronix.ru/redirect.php?http://sine.ni.com/np/app/main/p/ap/global/lang/ru/pg/1/sn/n24:PXI-FSLASH-CompactPCI/ ... если денег не жалко....
Автор: syoma Mar 17 2015, 10:44
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
3) Как доказать что RTL также соответствует ТЗ?
Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?
По моему, эти вопросы выходят за рамки данной темы. Тут речь идет о тестовых стендах, а не о качестве и выборе тестов.
Но, конечно, вопрос а какой стенд нужен ТС, остается открытым.
Автор: Torpeda Mar 17 2015, 11:08
Но, конечно, вопрос а какой стенд нужен ТС, остается открытым.
Стенд нужен тот, который указан в ПМ, которые пишутся на основании ТУ, в объёме ПИ\КИ\ПСИ, а ТУ обязанно опираться на ГОСТ, ОСТ на данный тип оборудования.....
Таким образом "стенд" это может быть и барокамера в которую всуното изделие со штатной программой и работающее как в приложении....
Ежели речь о проверке что всё запаяно правильно и есть контакт (на этапе ПСИ), то тогда можно изготовить тест платку со всеми интерфейсами (иногда можно отделаться нульмодемными заглушками) и зашить в устройство отладочную програмку которая дёргает все провода внутри устройства и выдаёт\принимает посылки на\от внешние порты. Это-же можно добится, внедрив JTAG в плату.
Если это попытка подтвердить правильность проектирования на этапе ПИ - то такой платки совершенно недостаточно, нужно может закупить сертифицированный специальный тестр PCI интерфейса и при этом доказать качество програмного кода по специальной методике (тут аппаратно ничего и не надо).
так-что вопрос "нужен тестовый стенд" - неоднозначный.
Автор: SSerge Mar 17 2015, 11:38
"Тестирование может показать наличие ошибок, но не может доказать их отсутствие" © Э. Дейкстра.
Автор: Torpeda Mar 17 2015, 12:21
А что Э. Дейкстра знал о test coverage?
Автор: SimpleSoft Mar 17 2015, 20:22
syoma, Torpeda, спасибо за ответы.
SSerge, это точно. Но знание какие ошибки в образце уже верный путь к их исправлению. Зачастую задача сделать не идеальный продукт, а продукт который соответствует требованиям.
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
3) Как доказать что RTL также соответствует ТЗ?
Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?
Вопросы очень(!) правильные, более того, по отношению заказчика к тестированию, также можно понять его уровень и возможности.
syoma, если говорить о сериных продуктах, пробовали ли вы прошивать платы с помощью иголок, Test Points (куда выведен JTAG) и прогонять JTAG Boundary Scan тесты? Если да, то можете поделиться информацией какое оборудование использовали и впечатления от использования?
Автор: syoma Mar 18 2015, 06:35
По поводу JTAG сказать ничего не могу - у нас все лилось по USB и Boundary Scan не было. Поэтому мы все проверяли только функциональными тестами.
Могу более по Signal Conditioning или модульным контроллерам.
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
3) Как доказать что RTL также соответствует ТЗ?
Чем формально доказать полноту тестбенчев и функциональное соответствие стандартам?
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?
Ну если предположить, что система управления требованиями у Вас настроена и работает - что сам по себе уже значительное улучшение культуры разработки, то самое интересное по вашим вопросам(кроме п.4), что я в последний раз видел на Embedded World - это система тестирования требований. Т.е. засовываете в нее свои требования и она каким-то образом прогоняет все варианты, чтобы можно было увидеть, где есть пробелы. Причем это еще до начала проектирования устройства. Я так толком и не понял, как это работает, но вроде работает.
По п.4. - климатика и ЕМС в принципе самое простое - есть стандарты - им надо соответствовать. Если уверены в своем изделии, то лучше всего тесты делать на конечном этапе, чтобы протестировать изделие в как можно близком к серийному варианте, чтобы не было вопросов при сертификации. Если не уверены - делаете промежуточные тесты до конца разработки. Мы, например, в первый раз микросекундные импульсы тестировали задолго до конца разработки на I/O и входе блока питания, чтобы не переделывать второй раз.
Автор: Torpeda Mar 18 2015, 07:29
Надо следовать стандартам предявляющим требования к изделию и особенно стандартам, указывающим методику проведения испытаний (а-то есть любители вентилятор в термокамере включать...)
Не забываем про метрологию и правильный подбор приборов по класу точности (чтобы не тратится всюду и везде на дорогущие "цезиевые" эталоны) и совместимости по входу.
Что касается когда делать тесты...
Количество и объём тестов во время разработки - соответственно фантазии и квалификации разработчика
Дальше следуем стандарту постановки изделий на производство.
"тесты делать на конечном этапе, чтобы протестировать изделие в как можно близком к серийному варианте, чтобы не было вопросов при сертификации." - называется квалификационные испытания (КИ). Это всё что указано в стандартах предявляющим требования к изделию (в т.ч и пожаробезопасность, и транспортопригодность по дорогах класса "Г", и даже те, что розрушают изделие, и что USB это USB и т.д. и .т.п)
На конечном этапе производства проводятся ПСИ, которые гораздо короче КИ и только гарантируют что изготовлено всё как в чертежах.
JTAG - это помощь в промежуточных точках контроля техпроцеса (к КИ, ПСИ это не относится), а именно прозвонки после пайки. Ну и других технологических операциях - прошивка флешки напр.
К сожалению встраивается только в большие микросхемы (микропроцессоры, FPGA). Поэтому и подходит больше для модулей где есть только такие микросхемы.
Автор: SimpleSoft Mar 18 2015, 08:23
syoma, как я понял, по USB вы заливаете тестовое Firmware и оно проводит функциональный тест, а PXI считывает и сравнивает реакцию i/o? На каких этапах вы проводите такое тестирование?
Torpeda, у вас написано правильно про изделие в целом. А как тестируете, например, софт для микроконтроллеров, SoC, FPGA на промежуточных этапах?
Автор: Torpeda Mar 18 2015, 09:18
SoC - это есчё хуже чем изделие вцелом
Если исключить этапы производства и всё что тестируется там, то тестирование по ходу разработки (как часть КИ), называется верификация\симуляция (в среде UVM напр.) и есть соответственные методики и формальные показатели качества (code coverage etc.).
При помощи верификации гарантируется соответствие функциональности изделия требованям ТЗ в основном...
Частично можно проверить раблотоспособность изделия (т.е. софт, всё что зашито в FPGA итд.) на натурных испытаниях (например подключив ваш Ethernet Switch в реальную сеть или к специализированному тестеру Ethernet).
При этом правда, качество теста будет не очень хорошее из-за того, что:
- тест кавередж неизвестен
- тест кавередж скорее не более (70-80)% (это из опыта верификации, т.е. вроде тест бенч написан хороший по смыслу, но когда запускаеш подсчёт coverage, то видиш примерно такое покрытие)
----
Хотя... если заказчик лох, и юристы не подписали страшную ответственность...то натурных испытаний в объёме фантазии разработчика мож и хватит....
Кстати, из опыта - полная халтура, работоспособная только на столе (где функционально проверены только основные конфигурации), часто неплохо и долго работает и в приложении... ну может разок сбойнёт
(это потому что крайние случаи наихудшего сочетания очень маловероятные)
Автор: syoma Mar 18 2015, 09:59
При проверке серийных изделий. Прошивок, кстати, две - одна чисто для тестирования железа - дергает пинами, пихает пакеты везде. Вторая - уже рабочая, но ее проверяем только поскольку - поскольку - залилась ли в целом, запускается ли система, поднимаются ли интерфейсы. Реально ее полностью проверить в серийных условиях нет - стенд нужен очень серьезный. У нас этакой стенд есть - это RTDS. Мы софт, а именно алгоритмы управления проверяем на нем. Но только на этапе разработки.
Автор: SimpleSoft Mar 18 2015, 10:14
Torpeda, дело в том, что моя позиция по отношению к клиенту это Win-Win, иначе не интересно. Повторно сделать клиенту предложение и получить работу проще, чем найти нового клиента. Но это невозможно, если сделать первый проект, после которого заказчик останется недоволен (Как говорила Фаина Раневская "Деньги съедены, а позор остался"). С другой стороны, если заказчик умышленно не хочет тестировать, то тут вы правы - это его желаение. Однако хочется ли работать с таким клиентом - отдельный вопрос.
syoma, RTDS это rtds.com? Я так подозреваю, у вас богатейший опыт тестирования
Напомнило:
- Молодой человек, ви шо, не виходите?!
- Выхожу.
С надрывом: - Так шо ж ви молчите?!!
Автор: syoma Mar 18 2015, 11:13
Да, rtds.com.
Но еще раз - это только для отладки алгоритмов управления и демонстрации, что они действительно работают в железе, как задумано. Кстати, как раз на вот эти тесты наши заказчики обычно и прилетают посмотреть. Как там железо тестируется - их обычно мало интересует - это наша проблема. Им достаточно подписаных протоколов. Но у нас специфическая сфера - RTDS просто необходима. Для обычных проектов можно намного более простые вещи найти.
Автор: syoma Mar 19 2015, 11:24
Кстати, если говорить об организации тестового стенда для какого-либо управляющего контроллера (ну там лампочками поморгать, релюшками пощелкать, что-нибудь измерить, без особых коммуникационных изысков - типа сигнализации какой, или блока управления котла, света или еще чего-либо ) за дешево и сердито (относительно) именно для разработченских нужд, то я счас исследую возможность создания такого стенда на базе обычного PC с подключенными EtherCAT модулями.
Получается интересная система и альтернатива PXI - по железу нужны только модули аналогового и цифрового ввода вывода или коммуникационные (RS242,485 Canopen и т.д) модули EtherCAT. Список различных вариантов большой. К компу подключаются через Ethernet порт. В любой момент конфигурацию можно поменять или дополнить.
Самое интересное в софте - он стоит дофига, но если найти крякнутый TwinCAT... 
Тогда Windows PC превращается в real-time симулятор с временами отклика в 1мс и меньше - вплоть до 100µs. При этом TwinCAT позволяет в реальном времени выполнять и Си и PLC код, а самоее интересное - модели из Matlab/Simulink. Т.е. можно нарисовать графически свою обвязку, которая будет имитировать объект управления и запустить в реальном времени на симуляторе, чтобы подопытный контроллер думал, что управляет реальным объектом.
Мало того - можно часть сигналов вывести опять же на те же EtherCAT клеммы, чтобы подключить к той части, для которой есть физический макет, но нет возможности симитировать полностью все нужные сигналы.
Автор: AlexandrY Mar 19 2015, 11:41
Лучше расскажите что вы собственно разрабатываете, а то непонятно как тут прикрутить PC и проч PXI.
Вы представляете что значит написать модель объекта управления?
Это работы на порядки больше чем собственно работы по программированию тестируемого контроллера.
Изобразите-ка модель мотор-редуктора в механической системе с переменными нагрузками, десятками датчиков, управлением по облачным протоколам и системой автономного питания.
А это, кстати, будут обычные ворота.
Кому такое тестирование надо?
И кто будет тестировать тесты?
Железо для тестов это вопрос весьма вторичный.
Главное софт.
Автор: smalcom Mar 19 2015, 12:05
с чем именно у вас возникли сложности в моделировании такой системы?
Автор: AlexandrY Mar 19 2015, 12:21
Не знаю, понимаете ли, как предсказать обороты в зависимости от инициализации FlexTimer Module.
Автор: SimpleSoft Mar 19 2015, 12:52
syoma, правильно ли я понимаю, что выпускаемые вами изделия достаточно дороги и поэтому вложения в такой тестовый комплекс оправданы?
Предположу: возможно это системы сбора данных на подстанциях для высоковольтных линий электропередач.
Это работы на порядки больше чем собственно работы по программированию тестируемого контроллера.
Такое бывает. Особенно если это касается критических систем.
Автор: AlexandrY Mar 19 2015, 13:08
Критические системы потому названы критическими что человек мало о них что знает и боится.
Потому критические системы никак не могут тестироваться на моделях, для них нет адекватных моделей.
Автор: syoma Mar 19 2015, 14:06
Наверное ввел кого-то в заблуждение. На самом деле я работаю над двумя совершенно разными проектами с одним общим - подходом к разработке и тестированию.
В одном случае - это контроллер на базе VPX технологии для управления устройствами для гибких систем передачи переменного тока на сотни мегаватт.
Потому критические системы никак не могут тестироваться на моделях, для них нет адекватных моделей.
Вот вам как раз пример такой системы. Тут без тестирования на модели не обойтись, так как на практике один такой тест может полностью лишить света городок средних размеров. А тест нужно сделать обязятельно, так как система как раз и расчитана на такой случай. Иначе что делать? Молиться, что в нужный момент сработает?
Таких проектов всего штук 10 в год будет.
другом случае - это скажем так система управления немного посложней гаражной, но с двумя-четырьмя двигателям, иногда с частотниками на пару десятков датчиков и выключателей и 20-ю различными релюшками. Это производится серийно в количестве до 1000 в год. Кстати сделана на STM32F.
Реалистичные модели нарисовать в симулинке - не проблема ни для одного, ни для другого проекта, так как матлаб располагает вполне себе достаточными тулбоксами для моделирования и силовой электроники и простых систем с логическими сигналами. Кстати "модель мотор-редуктора в механической системе с переменными нагрузками" я думаю в матлабе изобразить тоже можно - там есть механический тулбокс. Только вот надо ли, если с точки зрения контроллера "ворота" представляют всего лишь десяток выключателей, которые выключаются с различными задержками после выдачи команды на открытие или закрытие. Тут главное - все варианты внештатных комбинация обработать.
Автор: AlexandrY Mar 19 2015, 14:16
Ну покажите уже наконец эти модели в симулинке. Хотел бы я посмотреть.
Если бы вы делали что то в симулинке, то никогда бы не поминали его всуе.
Там один лог. оператор вставить эта работа на порядок сложнее чем написать в с-и на микроконтроллере. (засеките время в секундах)
Я уже не говорю про отладку.
Автор: SimpleSoft Mar 20 2015, 11:42
Всем спасибо за ответы.
Интересно, вот например, как тестирует свои контроллеры Овен? А софт для них?
Или РТСофт своё ПО на Embedded Linux/Windows?
Автор: smalcom Mar 20 2015, 19:29
теперь мне понятно почему у вас не получается модель
Автор: sanych2015 Apr 9 2015, 17:08
Спасибо за тему на форуме раскрыл немного свой кругозор в этой теме...
Автор: SimpleSoft Apr 9 2015, 18:18
Тестирование - это большая часть успешного проекта. И как правило уровень покрытия тестами влияет на конечное качество продукта, а знание технологий тестирования - это сильная сторона успешного коллектива.
Автор: KBH Jan 31 2016, 07:15
Мой начальник с чего-то взял, что макетирование электроники - вчерашний день, хочет рабочую схему с первого раза.
Хотя в прошлом году всё было нормально. Макетировали, раза с 3-4 получалась рабочая схема, потом думали, как ее уместить в требуемые габариты. Никакие доводы не действуют. Видимо, это с него сверху спрашивают.
Что скажете, господа разработчики? Не пора ли мне искать новую работу?
P.S. Текущий проект - DCDC 200-450V -> 12V 250A, ARM STM32.
Автор: Corvus Jan 31 2016, 07:36
Хоть рассказали бы предметную область. А то если это МК (ПЛИС) с интерфейсной обвязкой, то, действительно, непонятно, что там макетировать три-четыре раза. А с учётом экономической ситуации, радуйтесь, что начальство решило экономить на макетах, а не на разработчиках.
UPD: А, таки силовая электроника. Мой совет: максимально используйте уже имеющиеся наработки и сократите число итераций до двух. Отчаянные времена требуют отчаянных мер.
Автор: smalcom Jan 31 2016, 08:58
он не прав, но тезис
поддерживаю ))
Увеличьте использование симулятора и отладочных наборов. Старые макеты можно модифицировать.
Пробуйте не всю схему макетировать, а только некоторые сложные узлы.
Автор: SimpleSoft May 25 2017, 04:56
Добавлю информации: разработки стараемся делать по всем правилам: 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.
Автор: SimpleSoft Jul 27 2017, 12:24
Ещё добавлю:
Попробовали Vector HIL (Hardware-in-the-Loop) - замечательная вещь. Взяли в аренду - прогнали тесты - повылазили глюки, которые не должны были.
Заметили, что Static Analysis влияет также и на результат теста с HIL.
По требованию от клиента - делали тестирование в климатической камере, а также механические испытания (1 млн раз нажимали пневматикой на кнопки, чтобы посмотреть как они будут вести себя ).
По поводу убеждения заказчиков:
1) Как доказать правильность и полноту требований Тех задания (ТЗ), в т.ч. по физическим и функционально-логическим характеристикам?
--->Как правило с первого раза в ТЗ не укажешь всех нюансов которые вылезут в процессе разработки. Конечно желательно, чтобы заказчик доверял исполнителю и трезво понимал риски. А риски нужно обозначить сразу и предложить варианты решения в случае чего.
2) Как доказать что програмное обеспечение 100% соответствует требованиям ТЗ?
Просто на столе просчёлкать варианты - не подходит. Нужно формальное строгое доказательство правильности и полноты тестов.
Нужно доказать что интерфейсы соответствуют стандарту и т.п.
--->Заказчик делает входной контроль сам. Как минимум- можно предложить репорты из Static Analysis tool, unit test tools
4) Какие физические тесты (климатьика и т.д), в каком объёме и на каком этапе прроизводства\приёмки изделия надо проводить?
--->Это определяется стандартами которые необходимо поддерживать. Открываем ГОСТ/IEC/ISO и знакомимся. Оттуда берём ссылки на другие стандарты и тд.
Надо приложить усилия, конечно, чтобы распутать все это и сделать то что нужно, с достаточными требованиями.
Автор: Николай Семёнович Jul 27 2017, 16:52
Хотя в прошлом году всё было нормально. Макетировали, раза с 3-4 получалась рабочая схема, потом думали, как ее уместить в требуемые габариты. Никакие доводы не действуют. Видимо, это с него сверху спрашивают.
Что скажете, господа разработчики? Не пора ли мне искать новую работу?
Скажу что Ваш начальник ИДИОТ.
Даже ГОСТ говорит, что при разработке электронной техники 3 итерации - это норма
Чем выше начальник тем дальше он от реальной жизни. И тем меньше он понимает как жизнь устроена и как делаются дела
Так что не обращайте внимания на придурков
Автор: Myron Jul 27 2017, 17:00
Хотя в прошлом году всё было нормально. Макетировали, раза с 3-4 получалась рабочая схема, потом думали, как ее уместить в требуемые габариты. Никакие доводы не действуют. Видимо, это с него сверху спрашивают.
Что скажете, господа разработчики? Не пора ли мне искать новую работу?
P.S. Текущий проект - DCDC 200-450V -> 12V 250A, ARM STM32.
- Смена руководства / концепции.
- Очень хорошее отношение к вам и вашей работе.
- Хорошая зарплата+премии.
- Комбинация предыдущих пунктов.
Автор: @Ark Jul 27 2017, 19:14
Объясните своему начальнику, что количество итераций в процессе разработки изделия определяет только всевышний.
Это его исключительная сфера компетенции, и ни чья больше... Мнения различных начальников, предписания ГОСТов и
прочие хотелки разных людей он не принимает во внимание.
Автор: syoma Jul 28 2017, 06:28
Я б разработчика, который мне такое заявил, в шею бы погнал. Точнее объяснил бы, и если до него не дойдет с первого раза, тогда бы погнал.
Потому, что как начальник знаю, что количество итераций зависит от сложности изделия, полноты и реализуемости технического задания, четкости и поставленности процесса разработки на предприятии, планирования, четкой оценки рисков, квалификации самого разработчика. Для самого разработчика, конечно, будет казаться, что все это воля всевышнего, но это не так. Поэтому он и не начальник.
Автор: @Ark Jul 28 2017, 11:02
Угу, зависит, но не определяет... И от фазы Луны еще зависит...
Что Вы будете делать, если после трех итераций конечный результат не достигнут? А Вы своим приказом установили, что их должно быть не больше трех? Или не больше одной, как в указанном выше случае? Будете назначать виноватых? Или погоните разработчиков в шею, за то что они "неправильно оценили риски"?. Ну-ну...
Успехов Вам в планировании процесса разработки.
Автор: Aner Jul 28 2017, 11:10
Потому, что как начальник знаю, что количество итераций зависит от сложности изделия, полноты и реализуемости технического задания, четкости и поставленности процесса разработки на предприятии, планирования, четкой оценки рисков, квалификации самого разработчика. Для самого разработчика, конечно, будет казаться, что все это воля всевышнего, но это не так. Поэтому он и не начальник.
Никакой вы не начальник и менеджером вам не стать с такими рассуждениями. Из написанного вами, занимаетесь только обраубанием мотивации работников. Совдепия и только.
Автор: syoma Jul 28 2017, 13:45
Не придирайтесь к словам. Могу перефразировать, если Вам угодно: Количество итераций определяется сложностью изделия, полнотой и реализуемостью технического задания..... Сильно смысл изменился?
Мне нравится Ваш тон. Представляю, как сильно Вы ненавидите своего начальника
В данном случае важно не назначать виноватых, а определить почему так произошло. В чем причина?
Возможно, не хватило экспериментов на этапе предварительно проработки ТЗ, которые не позволили выявить недостатки до того, как начался следующий этап.
Возможно были выбраны неправильные инструменты для решения конкретной задачи
Возможно, не было проведено Design Review на нужном этапе работ.
Возможно, просто недостаток коммуникации между различными разработчиками.
Возможно, не тому инженеру дали не ту работу.
Возможно сам процесс управления проектом разработки построен неправильно или неоптимально. Например, многие сейчас пробуют отойти от классической каскадной Waterfall модели и применять Agile при разработке железа... В принципе оно позволяет немного ускориться, но по моему опыту количество итераций увеличивается(логично)
Возможно неправильно определены риски...
И т.д.
Все это можно устранить без назначения виноватых и гонения в шею, чтобы в следующий раз получилось лучше.
О, интересно. Так расскажите тогда пожалуйста чем должен заниматься современный R&D Менеджер. Послушаю, может чего нового узнаю о моей профессии.
Хотя тему ушла в глубокий оффтопик ИМХО.
Автор: @Ark Jul 28 2017, 14:08
Смысл в том, что вы не можете заранее точно установить (определить, зафиксировать) сколько итераций реально потребуется.
Можете только оценить приближенно, с какой-то долей вероятности. Можете и должны стремиться к снижению количества этих итераций.
Все доступными методами, которые вы выше перечислили.
Но! Точно определить заранее сколько итераций реально будет до по получения результата - вам не дано. И ни кому не дано.
Автор: Dimka78 Jul 28 2017, 14:26
Хотя в прошлом году всё было нормально. Макетировали, раза с 3-4 получалась рабочая схема, потом думали, как ее уместить в требуемые габариты. Никакие доводы не действуют. Видимо, это с него сверху спрашивают.
Что скажете, господа разработчики? Не пора ли мне искать новую работу?
P.S. Текущий проект - DCDC 200-450V -> 12V 250A, ARM STM32.
есть такая книга: Роберт И. Саттон - Не работайте с мудаками
Или вот это видео пособие: http://electronix.ru/redirect.php?https://www.youtube.com/watch?v=N-GCWx5tTJs
Господа, вопрос - увязывали ли вы ваши системы тестирования (End-of-line) с JIRA/SVN? Например, чтобы автоматически генерировать отчёты? Или складывать бинарники готовые к прошивке?
Вопрос также с бухгалтерией: Привязка к 1С? (Индекс изделия к прошивке, автоматическая генерация прошивки с проверенного Tag SVN, например )?
Автор: syoma Jul 28 2017, 15:48
Можете только оценить приближенно, с какой-то долей вероятности. Можете и должны стремиться к снижению количества этих итераций.
Все доступными методами, которые вы выше перечислили.
Но! Точно определить заранее сколько итераций реально будет до по получения результата - вам не дано. И ни кому не дано.
Вы так говорите, как будто я этого не знаю. Я это знаю и прекрасно понимаю.
Только смысл моего посыла был в другом - вы же написали выше:
И это грубая неправда. Разработчику может и казаться, что количество итераций определяется именно господом-богом. Разработчику, в принципе, вообще наплевать - чем больше итераций, тем больше работы, тем слаще жизнь.
Но на самом деле, как я написал выше, на количество итераций в итоге влияет немало факторов, в том числе и подконтрольных человеку. И при правильном подходе к R&D можно получить достаточно высокую вероятность завершения проекта за одну итерацию, а при неправильном сделать так, что и за 10 ничего не выйдет. Естественно, все это относится к конкретному проекту. Для каких-то проектов и 10 итераций будет хорошим результатом, но в этом случае худший вариант может быть сотни и тысячи.
Автор: AlexandrY Jul 28 2017, 16:01
Предлагаю остановить этот поток сознания, и дать ваше определение понятия "итерация".
Поскольку как мне кажется никто не понимает о чем вы. Про умный дом?
Так там что ни сделаешь всё пойдет, "итерации" теряют смысл ибо они и есть цель.
Но есть проекты где какие-то итерации в принципе невозможны, например система управления промышленным объектом.
Автор: Николай Семёнович Jul 28 2017, 16:07
Потому, что как начальник знаю, что количество итераций зависит от сложности изделия, полноты и реализуемости технического задания, четкости и поставленности процесса разработки на предприятии, планирования, четкой оценки рисков, квалификации самого разработчика. Для самого разработчика, конечно, будет казаться, что все это воля всевышнего, но это не так. Поэтому он и не начальник.
Ну и как (и кто это будет делать) оБЪЕКТИВНО оценить "реализуемость", "посставленность", "чёткость", "сложность", "риски", "квалификацию"?
А потом. Можно испугавшись начальства сделать и с одной итерации. Но впоследствие "недоведенность/недовылизанность" девайса приведет к таким последствиям (причем, ЧТО САМОЕ СТРАШНОЕ, не сразу, а спустя какое-то время. Такая вот мина замедленного действия), что "мама роди меня обратно".
Хотя, конечно, делать несколько итераций для девайсов уровня "два транзистора три резистора" - маразм. Но я думаю с топикстартера рабовладелец требует "делать за 1 итерацию" не такие "изделия"
Автор: @Ark Jul 28 2017, 16:08
Разработчику и/или его начальнику может казаться все, что угодно. Но, в конечном счете, дело обстоит именно так. Нравится Вам или нет.
Это не разработчик. Вот таких надо гнать в шею без всяких итераций.
Автор: Николай Семёнович Jul 28 2017, 16:15
Точно.
Некоторые "начальники" думают что достаточно погрозить пальцем и нахмурить лицо и подчиненный сразу решит задачу. "С первой же итерации".
С таким подходом можно управлять траншеи копателями, но не разработчиками сложного хайтека
Автор: syoma Jul 28 2017, 16:27
Поскольку как мне кажется никто не понимает о чем вы. Про умный дом?
Так там что ни сделаешь всё пойдет, "итерации" теряют смысл ибо они и есть цель.
Причем здесь "умный дом"? Кстати насчет "итераций" там - да там их поле непаханное, особенно когда читаешь истории про попадалово: один начал на ардуино, все сгорело от молнии, выкинул, купил ПЛК. Другой начал на одном контроллере, думал, что хватит возможностей, не хватило ног - начал все сначала с новым контроллером, так как старый уже не выпускают. Третий начал пять лет назад, закончил, сейчас забыл, что делал, так как документации нет. Четвертый мучался с LCD дисплеем полгода, потом понял, что тач-скрин обойдется дешевле...Хохма в общем. Чем вам не итерации?
Конечно, но этому есть причина - тот кто сделает за 2 итерации просто вылетит с рынка, так как не влезет ни по срокам, ни по стоимости, и никакому заказчику на его объекте эксперименты ни к чему.Но если разбивать такую разработку на несколько этапов, то на отдельных из них будут итерации, как ни крути. Например при пуско-наладке часто надо внести изменения в код или перенастроить параметры и провести тесты. Это итерации, количество которых можно уменьшить, например, путем отладки на макете, моделирования/симуляции, или HIL или на основании опыта.
Автор: Николай Семёнович Jul 28 2017, 16:49
Чушь. Вы видимо просто не в теме
Мы регулярно пользуемся услугами "гастарбайтеров" для разработки наших АСУТП.
И они делают их лет по 5-10. Переделывая все раз по 8. И все равно системы оказываются до конца не доведенными
Как правило, использование "моделирования/симуляции" говорит о низкой квалификации разработчика.
Опытный разраб и без "симуляции" и прочего шаманства представляет себе как всё будет работать.
А неопытный и с "симуляцией" лажу делает.
Я имею в виду случаи когда начинают симулировать схемы уровня "два транзистора три резистора".
А сложные схемы как не симулируй, все равно что-то не учтёшь.
Поэтому только макет.
Кроме того, макет сделать можно за пару часов, а модель составлять будешь месяц
кроме термина "кол-ва итераций" можно говорить ещё про "кол-во вариантов" решения.
Их, по хорошему, должно быть несколько, на разной элементной базе.
А с нас начальство требует, чтобы сразу был один единственный правильный вариант и бабки дает только на один вариант. Вплоть до последнего резистора все учитывается
Хотя по хорошему нужно было бы попробовать разные решения на разных компнентах
Автор: AlexandrY Jul 28 2017, 18:48
Т.е. практически любая работы у вас может называться итерацией.
А я бы называл итерациями инкрементальные изменения аппаратной части. К программной части даже бы не применял такой термин.
А если что-то переделывают с новой схемной структурой то это не итерация, а полный облом за который надо увольнять.
Скажем если взять пример того же источника питания с которого все началось я бы понял итерации в том смысле,
что сначала делают первую рабочую версию, но там допустимы ошибки исправляемые монтажниками.
Следующие бы версии исправляли бы обнаруженные ошибки и дополняли функциональность.
Но первая же версия должна быть рабочей, которую можно продать. А не монстр на макетке, сделанный на коленке с соплями и прочими артефактами.
Автор: psL Jul 28 2017, 18:57
для ПО есть мажорные, минорные релизы и патчи. По вашему, итерация для изделия - это только патчи?
с точки зрения DCDC может измениться контроллер преобразователя или материалы накопителя, тогда придется переделывать многое или вообще все. Т.е. получится мажорный релиз. Почему за это следует увольнять?
Автор: syoma Jul 28 2017, 19:44
что сначала делают первую рабочую версию, но там допустимы ошибки исправляемые монтажниками.
Следующие бы версии исправляли бы обнаруженные ошибки и дополняли функциональность.
Но первая же версия должна быть рабочей, которую можно продать. А не монстр на макетке, сделанный на коленке с соплями и прочими артефактами.
Я думаю применительно к теме DC/DC преобразователя под одной итерацией понимается расчет схемы, элементов, разработка и изготовление печатной платы(необходимо, так как трассировка имеет влияние), распайка и тестирование. От начала и до конца. Наверное около месяца на все про все.
И по словам автора выясняется, что после всех этих действий DC/DC не работает с первого раза или сгорает. То есть плату в топку, компоненты в топку, и начинаем следующую итерацию с чистого листа с новой схемой.
Вот так и получается 3-4 итерации и это только на этапе макетирования.
Так вот этого и хочет избежать тот начальник, который хочет сделать "за одну итерацию"
Автор: AlexandrY Jul 28 2017, 20:51
Тогда я начальника полностью понимаю. Надо быть конкретно криворуким чтобы не сделать работающий AC/DC ( о нем вроде шла речь) с первого раза.
Тонны референс дизайнов,
Готовых блоков море.
Буквально у меня сейчас на столе такой на 100 A, с возможностью включения в параллель. Т.е. хоть 500 А могу изобразить.
Нарисуй на плате несколько вариантов если сомневаешься, предусмотри установку разных вариантов силовых элементов, поставь нормальный микроконтроллер с диагностикой и телеметрией и дело в шляпе.
Чего рассусоливать про итерации?
Автор: syoma Jul 28 2017, 22:10
Вот видите, а тут народ про плохих начальников и волю всевышнего рассуждает.
Автор: Николай Семёнович Jul 29 2017, 06:32
Тут на один вариант макета на ЭРЭ денег не дают, а ты говоришь "несколько вариантов".
Да если я такое скажу начальнику - меня сразу же уволят.
По деньгам "Несколько вариантов" и "несколько итераций" с точки зрения начальства "те же яйца, только вид сбоку"
Автор: @Ark Jul 29 2017, 07:13
Когда делается заказная разработка, под конкретного заказчика, может возникнуть естественное желание сэкономить на итерациях в процессе разработки. В этом случае, оно вполне оправдано. Себестоимость проекта существенно зависит от стоимости, собственно, самого процесса разработки - затраченного времени и количества итераций, в том числе. Стоимость изготовления в производстве единичного заказного экземпляра (или совсем небольшой партии) не столь критична для проекта. Как правило, задача жесткой минимизации себестоимости его изготовления не актуальна.
Когда делается серийная разработка, для продажи на рынке, себестоимость изготовления изделия в производстве выходит на первый план. А стоимость самого процесса разработки отходит на второй. Она уже не столь критична, поскольку дает не сопоставимо меньший вклад в себестоимость единичного экземпляра серийного изделия, в отличие от заказной разработки. Но требования к себестоимости в производстве серийного экземпляра резко возрастают. Необходимо обеспечить минимальную (конкурентоспособную) себестоимость, при достижении заданных технических характеристик. Пока необходимое соотношение цена/качество не достигнуто - считайте, что результата нет. В этом случае, жестко экономить на самом процессе разработки, в том числе на итерациях, не просто бессмысленно - вредно. Что толку от такой экономии, если в результате получилось неконкурентоспособное изделие, которое никто не купит. В итоге, в лучшем случае, сэкономите выброшенные на ветер деньги.
Автор: AlexandrY Jul 29 2017, 07:35
Откуда этот постулат, что итерации повышают конкурентоспособность?
Это в наши то дни, когда конкуренты синхронизируют релизы буквально по дням друг с другом чтобы выгоднее поделить волны спроса. С курсами валют работают на микросекундных интервалах.
Переходите уже на метафоры волн и полей притяжения.
Разработка нынче либо сейчас, либо вообще не нужна.
Какие еще итерации?
Автор: @Ark Jul 29 2017, 07:49
Во первых, это не постулат. Сами по себе итерации ничего не повышают.
К необходимости итераций, часто многочисленных, приводит задача тщательной проработки изделия,
с целью получения нужного, конкурентоспособного соотношения цена/качества изделия.
А этот "постулат" откуда?
Автор: syoma Jul 29 2017, 15:16
Обычно после первой итерации разработки - после того, как разработано и испытано первое изделие и оно выполняет все технические требования, делается вторая - она называется "Redesign to cost" - у нее основная цель - понижение себестоимости без ущерба техническим характеристикам. Прежде чем это делать, производится определение на сколько надо снизить себестоимость изделия, какие компоненты имеют какой вклад в себестоимость, где находится наибольший потенциал снижения себестоимости и сколько будет стоить одна итерация для каждого из решений. Стоимость итерации может быть разной для разных компонентов, особенно, если придется повторно проходить испытания. После этого считается ROI - за сколько изделий или лет окупится такой Redesign to cost и принимается решение. Часто это решение вида "To make or to buy"
Без этого лучше не начинать - я видел, как люди пытались годами оптимизировать различные DC/DC преобразователи, вместо того, чтобы купить готовый, в изделиях выпускаемых в единицах штук, и где стоимость такого преобразователя была несколько процентов от общей себестоимости.
Автор: SimpleSoft Jul 29 2017, 15:28
Какая бы "тяжелая" дискуссия не была - для себя много интересного прочел.
Поскольку как мне кажется никто не понимает о чем вы. Про умный дом?
Так там что ни сделаешь всё пойдет, "итерации" теряют смысл ибо они и есть цель.
Но есть проекты где какие-то итерации в принципе невозможны, например система управления промышленным объектом.
А ведь про умный дом - это правда. В теме просто зарыт сундук с деньгами, надо только его найти.
Это в наши то дни, когда конкуренты синхронизируют релизы буквально по дням друг с другом чтобы выгоднее поделить волны спроса. С курсами валют работают на микросекундных интервалах.
Переходите уже на метафоры волн и полей притяжения.
Разработка нынче либо сейчас, либо вообще не нужна.
Какие еще итерации?
Я встречал клиентов, которые планируют бюджет на 1..3 года. И там закладывают суммы на проект достаточно большие и им безболезненно делать по 6-8 итераций. Главный результат после 1-3 лет проектирования - стабильный серийный продукт.
И была реальная история:
Инженер из Испании 8 раз переделывал схему платы. Спросите - а почему? А я отвечу - всё просто: он ленив. Он берёт референс и срисовывает 1 к 1 (бывает с ошибками), без моделирования в LTSpice и согласования с программистами. Разводят ему плату, производят, она приходит - а там косяк или софт не может реализовать его "хотелки". И так по циклу.
Уволить не просто - ибо до пенсии осталось 3 года, а он и рад растягивать проект.
Автор: @Ark Jul 29 2017, 16:16
То, что Вы изложили - это логика крупных фирм. Которые уверены и, надо признать, не без оснований, что все, что они сделают - будет продаваться. Так или иначе, хорошо или не очень - но будет. А дальше, можно подумать об улучшении, посчитать затраты, выгоду, и решить - стоит или не стоит, оценив риски...
У фирм, калибром поменьше, логика совершенно другая - нужно сразу получить конкурентоспособное изделие. Только, не с первой итерации, а в итоге всего процесса разработки. Иначе, тупо не будет продаж, не будет денег. А все потраченные усилия, ресурсы и средства уйдут в пустую. Либо есть результат (продажи), либо его нет, и нет ничего... При такой постановке вопроса, такие мелочи как количество итераций, и даже стоимость разработки (количество уже вложенных средств) отходят на второй план. Либо достигаете цели и, со временем, отбиваете все затраты и начинаете получать прибыль. Либо не получаете ничего, кроме убытков.
Автор: syoma Jul 31 2017, 07:18
Я считаю, что это больше логика успешных фирм, неважно, большие они или маленькие. "Redesign to Cost" - это сам по себе приличный по объему работ проект, который, как я уже написал, затрагивает не только разработчиков, а всю цепочку - от снабженцев(например выход на прямых поставщиков) до производства(переход на smd, контрактное производство, оптимизация тестирования и т.д), так как большие оптимизации могут быть и там. Если это попытаться сделать с первой итерации, то вероятность неоправданно затянуть проект или вообще не довести изделие до ума сильно возрастает. А в сегодняшнем рынке очень важно быстро выйти с рабочим продуктом, чтобы снять сливки, а не через год быть в догоняющих.
И второе - R&D надо финансировать постоянно, так как разработчиков увольнять нельзя и зарплату им не понизишь(ну по крайней мере я их считаю за людей). Это особенно актуально для маленьких фирм, потому что там обычно всего пара человек в R&D и если их потерять, то вообще можно выключать свет. Поэтому чем раньше пойдет хоть какой-то кэш от продаж, тем лучше. Даже если прибыли не будет и придется отдавать по себестоимости - это уже лучше, чем не продавать вообще, так как во втором случае у вас провал по финансам будет гораздо сильнее и если денег будет больше взять негде, то риск накрыться вообще многократно возрастает.
Мы, например, в первых серийных изделиях платы вообще делали методом ЛУТ, так как была куча неизвестностей, а кэш нужен был здесь и сейчас. И так их и продавали. Только через пару лет, когда раскрутились, мы всем первым клиентам платы бесплатно поменяли на промышленные - это были для нас уже копейки.
Автор: @Ark Jul 31 2017, 14:48
Автор: syoma Jul 31 2017, 15:56
Вы меня неправильно поняли. Я не говорю о работе, я говорю о деньгах. Где взять зарплату разработчикам в маленькой, нераскрученной фирме, когда денег уже потрачено и немало, а продукта все еще нету?
Вы рассказываете про идеальных инноваторских бизнесменов. Я из таких только Маска знаю. Но у него есть парашют. :-) Многим не так повезло по жизни ни с талантами, ни с везением, ни с думаньем, ни с силами. Так что им, лучше и не начинать что-ли?
Автор: @Ark Jul 31 2017, 16:18
Маленькая нераскрученная фирма должна жить по средствам, за счет текущих заказов. До создания собственных продуктов ей еще надо дорасти. Когда накопится достаточно ресурсов, опыта и денег - тогда и будете ими рисковать. Только не забудьте все расчетные затраты на проект (время, деньги, ресурсы) сразу умножить минимум на три.
Автор: a123-flex Aug 13 2017, 17:50
http://electronix.ru/redirect.php?https://electronix.ru/forum/index.php?showtopic=141482&hl=
Автор: Николай Семёнович Aug 24 2017, 20:22
На первой итерации выявляются ляпы, не оптимальности и то, что не учли при проектировании.
Так что две итерации как минимум для устройств средней сложности и выше должн быть.
Люди не Боги, чтобы сделать так, чтобы с первой же итерации было сделано идеально и без ошибок
А если устройство крупносерийное. То добавляются ещё итерации для увеличения технологичности и уменьшения издержек при производстве.
Литеры в штампе документации для пометки документов не просто так придумали
Автор: novikovfb Aug 25 2017, 04:34
Ева - вторая итерация, первая была Лилит, но ее все признали неудачной. Кроме этого, был "Великий потоп", т.е. утилизация неудачных экземпляров. Так что, и Бог не сразу делал идеально.
Автор: AlexandrY Aug 25 2017, 07:57
Устаревшая концепция.
Наша вселенная - это симуляция. Поскольку всё дискретно, все квантуется, и время и пространство. Т.е. все исчислимо. В нашей вселенной нет бесконечности.
Поэтому бог оперирует с нами как с ПО, а не как с железом.
Нет итераций, есть версии.
И эти версии принято апгрейдить уже на этапе эксплуатации.
Разработчику только нужно постараться расширить возможности апгрейда.
Тестирование и поиск багов в современных системах на макетах и каких-то итерациях - пустая трата времени.
Поиск багов не должен прекращаться никогда в течении жизни изделия.
А кто исповедует практику - протестировал и забыл, тот просто отстал от жизни.
Автор: Kibi Aug 25 2017, 12:15
Если говорить о разработке устройства, то следовало бы начать с НИРа, а потом уже НИОКРа, тут я говорю о том,
что какая либо предварительная исследовательская работа должна быть, неважно, это может быть и простое гугленье))
Выпустить быстро устройство не всегда полезно, тут причиной может быть неудачное исполнение, но которое
даст возможность конкурентам учесть ошибки, а от вас отвернуться клиентам, хотя тут все зависит от вашей
скорости исправления ошибок, но не забывайте, что с выпуском продукта, часть ресурсов будет идти уже не
на разработку, а на выпуск и поддержку, да и возможна ситуация, когда сама изначальная концепция была неверной.
Может я отстал от жизни, и теперь принято не перепаивать ручками даже резистры, а сразу новую "итерацию" изготавливать,
как тут привели в пример "испанца"))) Если это так, то понятно почему "шеф" потребовал сократить число итераций до 1.
Автор: a123-flex Aug 29 2017, 18:24
Наша вселенная - это симуляция. Поскольку всё дискретно, все квантуется, и время и пространство. Т.е. все исчислимо. В нашей вселенной нет бесконечности.
А как же единство и взаимопереход противоположностей, теория относительности, электрон - волна - частица ?
Автор: SimpleSoft Jan 3 2018, 13:02
С Новым, уже 2018 годом. Всех благ!
Добавлю еще от себя.
Мы попробовали двинуться дальше в области качества ПО.
Приобрели LDRA пакет вместе с TBManager, TBrun, LDRAcover, LDRAunit.
Данный пакет умеет увязывать требования написанные в Word или из JIRA/Polarion с кодом. А также запускать тесты прямо на железе используя JTAG.
Более подробно - http://electronix.ru/redirect.php?http://www.logic.nl/Site_files/Logic/d3/d3e2a000-475b-4985-8e52-15d4aa22a7e3.pdf.
Возник попутно вопрос - а что вы используете для отладки кода, когда ещё железо не готово?
Отладки спаянные воедино? Может есть софтовые эмуляторы? (как например QEMU) или что-то иное? (Особенно если 60% кода копируется из проекта-в-проект, меняется только приложение)
К примеру: есть проект на FreeRTOS который конвертирует аналоговые входы используя алгоритмы в цифру и гонит по Ethernet по спец протоколам. Нужно сделать ещё пару приложений, которые основу имеют туже, но кол-во аналоговых входов другое, уровни другие, выхлодной протокол другой - но железо не готово. Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово?
Какие при этом риски?
Автор: SSerge Jan 3 2018, 14:03
Этом не просто хороший, это отличный вопрос, в нём содержится 100% ответа.
Автор: SimpleSoft Jan 3 2018, 16:27
Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью.
Автор: mantech Jan 3 2018, 16:57
Если малой кровью, то "включайте голову", ибо это самый лучший эмулятор, плюс макеты, которые никто не отменял.
Или еще так, пока железо не готово, беру стандартные модули от прошлых разработок, делаю на них основу программы, а когда подъезжает новое железо уже окончательно правлю под него. И время экономится и без дела не сижу..
Автор: Студент заборстроительного Jan 3 2018, 17:49
Волшебство в программировании мало распространено
+100
Поддерживаю данного оратора
Автор: SimpleSoft Jan 7 2018, 11:18
Спасибо!
Про голову, это конечно замечательно
Но я хочу спросить за конкретику. Может кто-то знает хорошие техники из опыта?
Я понимаю, что нужно соблюдать баланс между стоимостью решения для тестирования/отладки без железа и производства реальных образцов. Однако время простоя тоже денег стоит.
Автор: mantech Jan 7 2018, 13:42
Про голову, это конечно замечательно
Но я хочу спросить за конкретику. Может кто-то знает хорошие техники из опыта?
Я понимаю, что нужно соблюдать баланс между стоимостью решения для тестирования/отладки без железа и производства реальных образцов. Однако время простоя тоже денег стоит.
Да никто не скажет про конкретную методику, ибо ее нет таковой, чтоб конкретной. Одно дело тестировать железяку для узкого применения, например привод двигателя или контроллер передачи данных, тут тестирование просто сводится к тому, чтоб устройство работало под полной нагрузкой и не глючило или выходило из строя. Другое дело - устройства, предназначенные для работы с клиентами, например вендинговое оборудование, тут проверить его самому разработчику крайне сложно, даже работникам предприятия, в котором создается сей аппарат, ибо люди уже интуитивно знают, куда "тыкать" можно, а куда нет, поэтому тестирование такой техники возможно только "на клиентах", т.е. на торговой точке. Единственное, что должен сделать разработчик в этом случае - это грамотная система логов при сбоях.
Автор: Студент заборстроительного Jan 7 2018, 20:08
Я ему уже сказал
"Волшебство в программировании мало распространено"
Автор: Kabdim Jan 8 2018, 16:34
Использую gmock+gtest, но как правило тестирую не всю прошивку, а отдельные модули.
Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)