Как тестировать разработанную электронику и встраиваемое ПО?, Делимся опытом Опции

[sanych2015]

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

[SimpleSoft]

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

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

[KBH]

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

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

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

Сообщение отредактировал KBH - Jan 31 2016, 07:30

[Corvus]

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

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

[smalcom]

вчерашний день, хочет рабочую схему с первого раза.

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

Отчаянные времена требуют отчаянных мер.

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

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

[SimpleSoft]

Добавлю информации: разработки стараемся делать по всем правилам: 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 - May 25 2017, 04:57

[SimpleSoft]

Ещё добавлю:

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

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


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

[Николай Семёнови...]

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

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

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

Видимо, это с него сверху спрашивают.

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

[Myron]

Мой начальник с чего-то взял, что макетирование электроники - вчерашний день, хочет рабочую схему с первого раза.
Хотя в прошлом году всё было нормально. Макетировали, раза с 3-4 получалась рабочая схема, потом думали, как ее уместить в требуемые габариты. Никакие доводы не действуют. Видимо, это с него сверху спрашивают.
Что скажете, господа разработчики? Не пора ли мне искать новую работу?
P.S. Текущий проект - DCDC 200-450V -> 12V 250A, ARM STM32.

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

[@Ark]

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

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

[syoma]

Объясните своему начальнику, что количество итераций в процессе разработки изделия определяет только всевышний.

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

[@Ark]

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

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

[Aner]

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

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

[syoma]

Угу, зависит, но не определяет... И от фазы Луны еще зависит...

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

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

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

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

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

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

[@Ark]

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

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