|
|
|
Как тестировать разработанную электронику и встраиваемое ПО?, Делимся опытом |
|
|
|
Apr 9 2015, 17:08
|
Группа: Новичок
Сообщений: 2
Регистрация: 9-04-15
Из: Россия, Омск
Пользователь №: 86 157
|
Спасибо за тему на форуме раскрыл немного свой кругозор в этой теме...
--------------------
|
|
|
|
|
Apr 9 2015, 18:18
|
Местный
Группа: Участник
Сообщений: 273
Регистрация: 3-11-05
Пользователь №: 10 442
|
Цитата(sanych2015 @ Apr 9 2015, 20:08) Спасибо за тему на форуме раскрыл немного свой кругозор в этой теме... Тестирование - это большая часть успешного проекта. И как правило уровень покрытия тестами влияет на конечное качество продукта, а знание технологий тестирования - это сильная сторона успешного коллектива.
|
|
|
|
|
Jan 31 2016, 07:15
|
Участник
Группа: Участник
Сообщений: 70
Регистрация: 4-08-08
Пользователь №: 39 424
|
Мой начальник с чего-то взял, что макетирование электроники - вчерашний день, хочет рабочую схему с первого раза. Хотя в прошлом году всё было нормально. Макетировали, раза с 3-4 получалась рабочая схема, потом думали, как ее уместить в требуемые габариты. Никакие доводы не действуют. Видимо, это с него сверху спрашивают.
Что скажете, господа разработчики? Не пора ли мне искать новую работу?
P.S. Текущий проект - DCDC 200-450V -> 12V 250A, ARM STM32.
Сообщение отредактировал KBH - Jan 31 2016, 07:30
--------------------
Всё в этом мире относительно, как сказал однажды старик Альберт... )
|
|
|
|
|
Jan 31 2016, 08:58
|
Профессионал
Группа: Свой
Сообщений: 1 292
Регистрация: 26-06-07
Пользователь №: 28 718
|
Цитата вчерашний день, хочет рабочую схему с первого раза. он не прав, но тезис Цитата Отчаянные времена требуют отчаянных мер. поддерживаю )) Увеличьте использование симулятора и отладочных наборов. Старые макеты можно модифицировать. Пробуйте не всю схему макетировать, а только некоторые сложные узлы.
|
|
|
|
|
May 25 2017, 04:56
|
Местный
Группа: Участник
Сообщений: 273
Регистрация: 3-11-05
Пользователь №: 10 442
|
Добавлю информации: разработки стараемся делать по всем правилам: 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
|
|
|
|
|
Jul 27 2017, 12:24
|
Местный
Группа: Участник
Сообщений: 273
Регистрация: 3-11-05
Пользователь №: 10 442
|
Ещё добавлю:
Попробовали 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
|
Местный
Группа: Участник
Сообщений: 297
Регистрация: 20-05-17
Пользователь №: 97 202
|
Цитата(KBH @ Jan 31 2016, 10:15) Мой начальник с чего-то взял, что макетирование электроники - вчерашний день, хочет рабочую схему с первого раза. Хотя в прошлом году всё было нормально. Макетировали, раза с 3-4 получалась рабочая схема, потом думали, как ее уместить в требуемые габариты. Никакие доводы не действуют. Видимо, это с него сверху спрашивают.
Что скажете, господа разработчики? Не пора ли мне искать новую работу? Скажу что Ваш начальник ИДИОТ. Даже ГОСТ говорит, что при разработке электронной техники 3 итерации - это норма Цитата(KBH @ Jan 31 2016, 10:15) Видимо, это с него сверху спрашивают. Чем выше начальник тем дальше он от реальной жизни. И тем меньше он понимает как жизнь устроена и как делаются дела Так что не обращайте внимания на придурков
|
|
|
|
|
Jul 27 2017, 17:00
|
Профессионал
Группа: Свой
Сообщений: 1 849
Регистрация: 6-02-05
Пользователь №: 2 451
|
Цитата(KBH @ Jan 31 2016, 01:15) Мой начальник с чего-то взял, что макетирование электроники - вчерашний день, хочет рабочую схему с первого раза. Хотя в прошлом году всё было нормально. Макетировали, раза с 3-4 получалась рабочая схема, потом думали, как ее уместить в требуемые габариты. Никакие доводы не действуют. Видимо, это с него сверху спрашивают. Что скажете, господа разработчики? Не пора ли мне искать новую работу? P.S. Текущий проект - DCDC 200-450V -> 12V 250A, ARM STM32. Никому нмчего не докажете, ничего не поможет, кроме смены начальства или работы. Остановить поиски может только: - Смена руководства / концепции. - Очень хорошее отношение к вам и вашей работе. - Хорошая зарплата+премии. - Комбинация предыдущих пунктов.
|
|
|
|
|
Jul 27 2017, 19:14
|
Знающий
Группа: Участник
Сообщений: 688
Регистрация: 13-05-16
Пользователь №: 91 710
|
Цитата(KBH @ Jan 31 2016, 10:15) Мой начальник с чего-то взял, что макетирование электроники - вчерашний день, хочет рабочую схему с первого раза. Объясните своему начальнику, что количество итераций в процессе разработки изделия определяет только всевышний. Это его исключительная сфера компетенции, и ни чья больше... Мнения различных начальников, предписания ГОСТов и прочие хотелки разных людей он не принимает во внимание.
|
|
|
|
|
Jul 28 2017, 06:28
|
Профессионал
Группа: Свой
Сообщений: 1 817
Регистрация: 14-02-07
Из: наших, которые работают за бугром
Пользователь №: 25 368
|
Цитата Объясните своему начальнику, что количество итераций в процессе разработки изделия определяет только всевышний. Я б разработчика, который мне такое заявил, в шею бы погнал. Точнее объяснил бы, и если до него не дойдет с первого раза, тогда бы погнал. Потому, что как начальник знаю, что количество итераций зависит от сложности изделия, полноты и реализуемости технического задания, четкости и поставленности процесса разработки на предприятии, планирования, четкой оценки рисков, квалификации самого разработчика. Для самого разработчика, конечно, будет казаться, что все это воля всевышнего, но это не так. Поэтому он и не начальник.
|
|
|
|
|
Jul 28 2017, 11:02
|
Знающий
Группа: Участник
Сообщений: 688
Регистрация: 13-05-16
Пользователь №: 91 710
|
Цитата(syoma @ Jul 28 2017, 09:28) Потому, что как начальник знаю, что количество итераций зависит от сложности изделия, полноты и реализуемости технического задания, четкости и поставленности процесса разработки на предприятии, планирования, четкой оценки рисков, квалификации самого разработчика. Угу, зависит, но не определяет... И от фазы Луны еще зависит... Что Вы будете делать, если после трех итераций конечный результат не достигнут? А Вы своим приказом установили, что их должно быть не больше трех? Или не больше одной, как в указанном выше случае? Будете назначать виноватых? Или погоните разработчиков в шею, за то что они "неправильно оценили риски"?. Ну-ну... Успехов Вам в планировании процесса разработки.
|
|
|
|
|
Jul 28 2017, 11:10
|
Гуру
Группа: Свой
Сообщений: 4 869
Регистрация: 28-02-08
Из: СПБ
Пользователь №: 35 463
|
QUOTE (syoma @ Jul 28 2017, 09:28) Я б разработчика, который мне такое заявил, в шею бы погнал. Точнее объяснил бы, и если до него не дойдет с первого раза, тогда бы погнал. Потому, что как начальник знаю, что количество итераций зависит от сложности изделия, полноты и реализуемости технического задания, четкости и поставленности процесса разработки на предприятии, планирования, четкой оценки рисков, квалификации самого разработчика. Для самого разработчика, конечно, будет казаться, что все это воля всевышнего, но это не так. Поэтому он и не начальник. Никакой вы не начальник и менеджером вам не стать с такими рассуждениями. Из написанного вами, занимаетесь только обраубанием мотивации работников. Совдепия и только.
|
|
|
|
|
Jul 28 2017, 13:45
|
Профессионал
Группа: Свой
Сообщений: 1 817
Регистрация: 14-02-07
Из: наших, которые работают за бугром
Пользователь №: 25 368
|
Цитата Угу, зависит, но не определяет... И от фазы Луны еще зависит... Не придирайтесь к словам. Могу перефразировать, если Вам угодно: Количество итераций определяется сложностью изделия, полнотой и реализуемостью технического задания..... Сильно смысл изменился? Цитата Что Вы будете делать, если после трех итераций конечный результат не достигнут? А Вы своим приказом установили, что их должно быть не больше трех? Или не больше одной, как в указанном выше случае? Будете назначать виноватых? Или погоните разработчиков в шею, за то что они "неправильно оценили риски"?. Ну-ну... Мне нравится Ваш тон. Представляю, как сильно Вы ненавидите своего начальника В данном случае важно не назначать виноватых, а определить почему так произошло. В чем причина? Возможно, не хватило экспериментов на этапе предварительно проработки ТЗ, которые не позволили выявить недостатки до того, как начался следующий этап. Возможно были выбраны неправильные инструменты для решения конкретной задачи Возможно, не было проведено Design Review на нужном этапе работ. Возможно, просто недостаток коммуникации между различными разработчиками. Возможно, не тому инженеру дали не ту работу. Возможно сам процесс управления проектом разработки построен неправильно или неоптимально. Например, многие сейчас пробуют отойти от классической каскадной Waterfall модели и применять Agile при разработке железа... В принципе оно позволяет немного ускориться, но по моему опыту количество итераций увеличивается(логично) Возможно неправильно определены риски... И т.д. Все это можно устранить без назначения виноватых и гонения в шею, чтобы в следующий раз получилось лучше. Цитата Никакой вы не начальник и менеджером вам не стать с такими рассуждениями. Из написанного вами, занимаетесь только обраубанием мотивации работников. Совдепия и только. О, интересно. Так расскажите тогда пожалуйста чем должен заниматься современный R&D Менеджер. Послушаю, может чего нового узнаю о моей профессии. Хотя тему ушла в глубокий оффтопик ИМХО.
|
|
|
|
|
Jul 28 2017, 14:08
|
Знающий
Группа: Участник
Сообщений: 688
Регистрация: 13-05-16
Пользователь №: 91 710
|
Цитата(syoma @ Jul 28 2017, 16:45) Не придирайтесь к словам. Могу перефразировать, если Вам угодно: Количество итераций определяется сложностью изделия, полнотой и реализуемостью технического задания..... Сильно смысл изменился? Смысл в том, что вы не можете заранее точно установить (определить, зафиксировать) сколько итераций реально потребуется. Можете только оценить приближенно, с какой-то долей вероятности. Можете и должны стремиться к снижению количества этих итераций. Все доступными методами, которые вы выше перечислили. Но! Точно определить заранее сколько итераций реально будет до по получения результата - вам не дано. И ни кому не дано.
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|