Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Как тестировать разработанную электронику и встраиваемое ПО?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Управление проектами
Страницы: 1, 2
Николай Семёнович
Цитата(Aner @ Jul 28 2017, 14:10) *
Никакой вы не начальник и менеджером вам не стать с такими рассуждениями. Из написанного вами, занимаетесь только обраубанием мотивации работников. Совдепия и только.

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

Причем здесь "умный дом"? Кстати насчет "итераций" там - да там их поле непаханное, особенно когда читаешь истории про попадалово: один начал на ардуино, все сгорело от молнии, выкинул, купил ПЛК. Другой начал на одном контроллере, думал, что хватит возможностей, не хватило ног - начал все сначала с новым контроллером, так как старый уже не выпускают. Третий начал пять лет назад, закончил, сейчас забыл, что делал, так как документации нет. Четвертый мучался с LCD дисплеем полгода, потом понял, что тач-скрин обойдется дешевле...Хохма в общем. Чем вам не итерации?

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

Конечно, но этому есть причина - тот кто сделает за 2 итерации просто вылетит с рынка, так как не влезет ни по срокам, ни по стоимости, и никакому заказчику на его объекте эксперименты ни к чему.Но если разбивать такую разработку на несколько этапов, то на отдельных из них будут итерации, как ни крути. Например при пуско-наладке часто надо внести изменения в код или перенастроить параметры и провести тесты. Это итерации, количество которых можно уменьшить, например, путем отладки на макете, моделирования/симуляции, или HIL или на основании опыта.
Николай Семёнович
Цитата(syoma @ Jul 28 2017, 19:27) *
Конечно, но этому есть причина - тот кто сделает за 2 итерации просто вылетит с рынка, так как не влезет ни по срокам, ни по стоимости, и никакому заказчику на его объекте эксперименты ни к чему.

Чушь. Вы видимо просто не в теме
Мы регулярно пользуемся услугами "гастарбайтеров" для разработки наших АСУТП.
И они делают их лет по 5-10. Переделывая все раз по 8. И все равно системы оказываются до конца не доведенными

Цитата(syoma @ Jul 28 2017, 19:27) *
моделирования/симуляции

Как правило, использование "моделирования/симуляции" говорит о низкой квалификации разработчика.
Опытный разраб и без "симуляции" и прочего шаманства представляет себе как всё будет работать.
А неопытный и с "симуляцией" лажу делает.

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

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

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

Хотя по хорошему нужно было бы попробовать разные решения на разных компнентах
AlexandrY
Цитата(syoma @ Jul 28 2017, 19:27) *
Это итерации, количество которых можно уменьшить, например, путем отладки на макете, моделирования/симуляции, или HIL или на основании опыта.

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

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

psL
Цитата(AlexandrY @ Jul 28 2017, 21:48) *
А если что-то переделывают с новой схемной структурой то это не итерация, а полный облом за который надо увольнять.

для ПО есть мажорные, минорные релизы и патчи. По вашему, итерация для изделия - это только патчи?
с точки зрения DCDC может измениться контроллер преобразователя или материалы накопителя, тогда придется переделывать многое или вообще все. Т.е. получится мажорный релиз. Почему за это следует увольнять?
syoma
Цитата
Скажем если взять пример того же источника питания с которого все началось я бы понял итерации в том смысле,
что сначала делают первую рабочую версию, но там допустимы ошибки исправляемые монтажниками.
Следующие бы версии исправляли бы обнаруженные ошибки и дополняли функциональность.
Но первая же версия должна быть рабочей, которую можно продать. А не монстр на макетке, сделанный на коленке с соплями и прочими артефактами.

Я думаю применительно к теме DC/DC преобразователя под одной итерацией понимается расчет схемы, элементов, разработка и изготовление печатной платы(необходимо, так как трассировка имеет влияние), распайка и тестирование. От начала и до конца. Наверное около месяца на все про все.
И по словам автора выясняется, что после всех этих действий DC/DC не работает с первого раза или сгорает. То есть плату в топку, компоненты в топку, и начинаем следующую итерацию с чистого листа с новой схемой.
Вот так и получается 3-4 итерации и это только на этапе макетирования.

Цитата(AlexandrY @ Jul 28 2017, 20:48) *
А если что-то переделывают с новой схемной структурой то это не итерация, а полный облом за который надо увольнять.

Так вот этого и хочет избежать тот начальник, который хочет сделать "за одну итерацию"
AlexandrY
Цитата(syoma @ Jul 28 2017, 22:44) *
Так вот этого и хочет избежать тот начальник, который хочет сделать "за одну итерацию"

Тогда я начальника полностью понимаю. Надо быть конкретно криворуким чтобы не сделать работающий AC/DC ( о нем вроде шла речь) с первого раза.
Тонны референс дизайнов,
Готовых блоков море.
Буквально у меня сейчас на столе такой на 100 A, с возможностью включения в параллель. Т.е. хоть 500 А могу изобразить.
Нарисуй на плате несколько вариантов если сомневаешься, предусмотри установку разных вариантов силовых элементов, поставь нормальный микроконтроллер с диагностикой и телеметрией и дело в шляпе.
Чего рассусоливать про итерации?
syoma
Вот видите, а тут народ про плохих начальников и волю всевышнего рассуждает.
Николай Семёнович
Цитата(AlexandrY @ Jul 28 2017, 23:51) *
Нарисуй на плате несколько вариантов если сомневаешься

Тут на один вариант макета на ЭРЭ денег не дают, а ты говоришь "несколько вариантов".
Да если я такое скажу начальнику - меня сразу же уволят.

По деньгам "Несколько вариантов" и "несколько итераций" с точки зрения начальства "те же яйца, только вид сбоку"
@Ark
Когда делается заказная разработка, под конкретного заказчика, может возникнуть естественное желание сэкономить на итерациях в процессе разработки. В этом случае, оно вполне оправдано. Себестоимость проекта существенно зависит от стоимости, собственно, самого процесса разработки - затраченного времени и количества итераций, в том числе. Стоимость изготовления в производстве единичного заказного экземпляра (или совсем небольшой партии) не столь критична для проекта. Как правило, задача жесткой минимизации себестоимости его изготовления не актуальна.

Когда делается серийная разработка, для продажи на рынке, себестоимость изготовления изделия в производстве выходит на первый план. А стоимость самого процесса разработки отходит на второй. Она уже не столь критична, поскольку дает не сопоставимо меньший вклад в себестоимость единичного экземпляра серийного изделия, в отличие от заказной разработки. Но требования к себестоимости в производстве серийного экземпляра резко возрастают. Необходимо обеспечить минимальную (конкурентоспособную) себестоимость, при достижении заданных технических характеристик. Пока необходимое соотношение цена/качество не достигнуто - считайте, что результата нет. В этом случае, жестко экономить на самом процессе разработки, в том числе на итерациях, не просто бессмысленно - вредно. Что толку от такой экономии, если в результате получилось неконкурентоспособное изделие, которое никто не купит. В итоге, в лучшем случае, сэкономите выброшенные на ветер деньги.
AlexandrY
Цитата(@Ark @ Jul 29 2017, 10:13) *
Что толку от такой экономии, если в результате получилось неконкурентоспособное изделие, которое никто не купит. В итоге, в лучшем случае, сэкономите выброшенные на ветер деньги.

Откуда этот постулат, что итерации повышают конкурентоспособность?
Это в наши то дни, когда конкуренты синхронизируют релизы буквально по дням друг с другом чтобы выгоднее поделить волны спроса. С курсами валют работают на микросекундных интервалах.
Переходите уже на метафоры волн и полей притяжения.
Разработка нынче либо сейчас, либо вообще не нужна.
Какие еще итерации?
@Ark
Цитата(AlexandrY @ Jul 29 2017, 10:35) *
Откуда этот постулат, что итерации повышают конкурентоспособность?

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

Цитата(AlexandrY @ Jul 29 2017, 10:35) *
Разработка нынче либо сейчас, либо вообще не нужна.

А этот "постулат" откуда? sm.gif

syoma
Обычно после первой итерации разработки - после того, как разработано и испытано первое изделие и оно выполняет все технические требования, делается вторая - она называется "Redesign to cost" - у нее основная цель - понижение себестоимости без ущерба техническим характеристикам. Прежде чем это делать, производится определение на сколько надо снизить себестоимость изделия, какие компоненты имеют какой вклад в себестоимость, где находится наибольший потенциал снижения себестоимости и сколько будет стоить одна итерация для каждого из решений. Стоимость итерации может быть разной для разных компонентов, особенно, если придется повторно проходить испытания. После этого считается ROI - за сколько изделий или лет окупится такой Redesign to cost и принимается решение. Часто это решение вида "To make or to buy"
Без этого лучше не начинать - я видел, как люди пытались годами оптимизировать различные DC/DC преобразователи, вместо того, чтобы купить готовый, в изделиях выпускаемых в единицах штук, и где стоимость такого преобразователя была несколько процентов от общей себестоимости.
SimpleSoft
Какая бы "тяжелая" дискуссия не была - для себя много интересного прочел.

Цитата(AlexandrY @ Jul 28 2017, 18:01) *
Предлагаю остановить этот поток сознания, и дать ваше определение понятия "итерация".
Поскольку как мне кажется никто не понимает о чем вы. Про умный дом?
Так там что ни сделаешь всё пойдет, "итерации" теряют смысл ибо они и есть цель.

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

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

Цитата(AlexandrY @ Jul 29 2017, 09:35) *
Откуда этот постулат, что итерации повышают конкурентоспособность?
Это в наши то дни, когда конкуренты синхронизируют релизы буквально по дням друг с другом чтобы выгоднее поделить волны спроса. С курсами валют работают на микросекундных интервалах.
Переходите уже на метафоры волн и полей притяжения.
Разработка нынче либо сейчас, либо вообще не нужна.
Какие еще итерации?


Я встречал клиентов, которые планируют бюджет на 1..3 года. И там закладывают суммы на проект достаточно большие и им безболезненно делать по 6-8 итераций. Главный результат после 1-3 лет проектирования - стабильный серийный продукт.
И была реальная история:
Инженер из Испании 8 раз переделывал схему платы. Спросите - а почему? А я отвечу - всё просто: он ленив. Он берёт референс и срисовывает 1 к 1 (бывает с ошибками), без моделирования в LTSpice и согласования с программистами. Разводят ему плату, производят, она приходит - а там косяк или софт не может реализовать его "хотелки". И так по циклу.
Уволить не просто - ибо до пенсии осталось 3 года, а он и рад растягивать проект.
@Ark
Цитата(syoma @ Jul 29 2017, 18:16) *
Обычно после первой итерации разработки - после того, как разработано и испытано первое изделие и оно выполняет все технические требования, делается вторая - она называется "Redesign to cost" - у нее основная цель - понижение себестоимости без ущерба техническим характеристикам. Прежде чем это делать, производится определение на сколько надо снизить себестоимость изделия, какие компоненты имеют какой вклад в себестоимость, где находится наибольший потенциал снижения себестоимости и сколько будет стоить одна итерация для каждого из решений...

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

syoma
Цитата
То, что Вы изложили - это логика крупных фирм.

Я считаю, что это больше логика успешных фирм, неважно, большие они или маленькие. "Redesign to Cost" - это сам по себе приличный по объему работ проект, который, как я уже написал, затрагивает не только разработчиков, а всю цепочку - от снабженцев(например выход на прямых поставщиков) до производства(переход на smd, контрактное производство, оптимизация тестирования и т.д), так как большие оптимизации могут быть и там. Если это попытаться сделать с первой итерации, то вероятность неоправданно затянуть проект или вообще не довести изделие до ума сильно возрастает. А в сегодняшнем рынке очень важно быстро выйти с рабочим продуктом, чтобы снять сливки, а не через год быть в догоняющих.
И второе - R&D надо финансировать постоянно, так как разработчиков увольнять нельзя и зарплату им не понизишь(ну по крайней мере я их считаю за людей). Это особенно актуально для маленьких фирм, потому что там обычно всего пара человек в R&D и если их потерять, то вообще можно выключать свет. Поэтому чем раньше пойдет хоть какой-то кэш от продаж, тем лучше. Даже если прибыли не будет и придется отдавать по себестоимости - это уже лучше, чем не продавать вообще, так как во втором случае у вас провал по финансам будет гораздо сильнее и если денег будет больше взять негде, то риск накрыться вообще многократно возрастает.

Мы, например, в первых серийных изделиях платы вообще делали методом ЛУТ, так как была куча неизвестностей, а кэш нужен был здесь и сейчас. И так их и продавали. Только через пару лет, когда раскрутились, мы всем первым клиентам платы бесплатно поменяли на промышленные - это были для нас уже копейки.
@Ark
Цитата(syoma @ Jul 31 2017, 10:18) *
Я считаю, что это больше логика успешных фирм, неважно, большие они или маленькие.
Здесь я с вами не соглашусь. Это просто другая логика работы фирмы, другая стратегия и поведение на рынке. На мой взгляд, более присущая крупным, раскрученным фирмам. Она может не хуже, и не лучше. Но не единственно возможная...

Цитата(syoma @ Jul 31 2017, 10:18) *
"Redesign to Cost" - это сам по себе приличный по объему работ проект, который, как я уже написал, затрагивает не только разработчиков, а всю цепочку ... большие оптимизации могут быть и там. Если это попытаться сделать с первой итерации, то вероятность неоправданно затянуть проект или вообще не довести изделие до ума сильно возрастает. А в сегодняшнем рынке очень важно быстро выйти с рабочим продуктом, чтобы снять сливки, а не через год быть в догоняющих.
Быстро выйти на рынок, чтобы снять сливки, а дальше действовать по ситуации - это одна стратегия, а создать конкурентоспособное серийное изделие, которое, возможно, потом будет "кормить" вас годами - совсем другая. Просто, прежде чем ввязаться в такой проект, люди обычно крепко думают. До того как, а не в процессе и не после. Оценивают свои силы и возможности. Потянут или нет. Смогут ли преодолеть многочисленные трудности, многие из которых еще даже не известны до конца. А когда решение принято и процесс запущен, то обратного хода, как правило, нет - либо достижение результата (уже даже не столь важно, какой ценой), либо убытки.

Цитата(syoma @ Jul 31 2017, 10:18) *
И второе - R&D надо финансировать постоянно, так как разработчиков увольнять нельзя и зарплату им не понизишь(ну по крайней мере я их считаю за людей). Это особенно актуально для маленьких фирм, потому что там обычно всего пара человек в R&D и если их потерять, то вообще можно выключать свет.
Придумывать разработчикам работу, чтобы не простаивали - это нонсенс. При правильной организации работы - это не актуально. Количество проектов, которые надо сделать, надо бы переделать, сделать срочно, сделать не очень срочно - иногда просто зашкаливает. Руководство только расставляет приоритеты, исходя из текущей ситуации и потребностей/возможностей.

Цитата(syoma @ Jul 31 2017, 10:18) *
Поэтому чем раньше пойдет хоть какой-то кэш от продаж, тем лучше. Даже если прибыли не будет и придется отдавать по себестоимости - это уже лучше, чем не продавать вообще, так как во втором случае у вас провал по финансам будет гораздо сильнее и если денег будет больше взять негде, то риск накрыться вообще многократно возрастает...
Вот видите, Вы предполагаете, что продажи будут в любом случае. Хотя бы по себестоимости. А дальше - по ситуации... Только это не факт. Продаж может не быть вообще, или они настолько мизерные, что вся затея теряет смысл. И этот кэш вам никакой погоды не сделает...

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

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

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

Вы рассказываете про идеальных инноваторских бизнесменов. Я из таких только Маска знаю. Но у него есть парашют. :-) Многим не так повезло по жизни ни с талантами, ни с везением, ни с думаньем, ни с силами. Так что им, лучше и не начинать что-ли?
@Ark
Цитата(syoma @ Jul 31 2017, 18:56) *
... я говорю о деньгах. Где взять зарплату разработчикам в маленькой, нераскрученной фирме, когда денег уже потрачено и немало, а продукта все еще нету?

Маленькая нераскрученная фирма должна жить по средствам, за счет текущих заказов. До создания собственных продуктов ей еще надо дорасти. Когда накопится достаточно ресурсов, опыта и денег - тогда и будете ими рисковать. Только не забудьте все расчетные затраты на проект (время, деньги, ресурсы) сразу умножить минимум на три. wink.gif

a123-flex
Цитата(SimpleSoft @ Mar 18 2015, 00:22) *
если говорить о сериных продуктах, пробовали ли вы прошивать платы с помощью иголок, Test Points (куда выведен JTAG) и прогонять JTAG Boundary Scan тесты? Если да, то можете поделиться информацией какое оборудование использовали и впечатления от использования?

https://electronix.ru/forum/index.php?showt...=141482&hl=
Николай Семёнович
На первой итерации выявляются ляпы, не оптимальности и то, что не учли при проектировании.

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

А если устройство крупносерийное. То добавляются ещё итерации для увеличения технологичности и уменьшения издержек при производстве.

Литеры в штампе документации для пометки документов не просто так придумали

novikovfb
Цитата(Николай Семёнович @ Aug 25 2017, 00:22) *
Люди не Боги, чтобы сделать так, чтобы с первой же итерации было сделано идеально и без ошибок

Ева - вторая итерация, первая была Лилит, но ее все признали неудачной. Кроме этого, был "Великий потоп", т.е. утилизация неудачных экземпляров. Так что, и Бог не сразу делал идеально.
AlexandrY
Цитата(novikovfb @ Aug 25 2017, 07:34) *
Ева - вторая итерация, первая была Лилит, но ее все признали неудачной. Кроме этого, был "Великий потоп", т.е. утилизация неудачных экземпляров. Так что, и Бог не сразу делал идеально.

Устаревшая концепция.
Наша вселенная - это симуляция. Поскольку всё дискретно, все квантуется, и время и пространство. Т.е. все исчислимо. В нашей вселенной нет бесконечности.
Поэтому бог оперирует с нами как с ПО, а не как с железом.
Нет итераций, есть версии.
И эти версии принято апгрейдить уже на этапе эксплуатации.
Разработчику только нужно постараться расширить возможности апгрейда.
Тестирование и поиск багов в современных системах на макетах и каких-то итерациях - пустая трата времени.
Поиск багов не должен прекращаться никогда в течении жизни изделия.
А кто исповедует практику - протестировал и забыл, тот просто отстал от жизни.
Kibi
Если говорить о разработке устройства, то следовало бы начать с НИРа, а потом уже НИОКРа, тут я говорю о том,
что какая либо предварительная исследовательская работа должна быть, неважно, это может быть и простое гугленье))
Выпустить быстро устройство не всегда полезно, тут причиной может быть неудачное исполнение, но которое
даст возможность конкурентам учесть ошибки, а от вас отвернуться клиентам, хотя тут все зависит от вашей
скорости исправления ошибок, но не забывайте, что с выпуском продукта, часть ресурсов будет идти уже не
на разработку, а на выпуск и поддержку, да и возможна ситуация, когда сама изначальная концепция была неверной.

Может я отстал от жизни, и теперь принято не перепаивать ручками даже резистры, а сразу новую "итерацию" изготавливать,
как тут привели в пример "испанца"))) Если это так, то понятно почему "шеф" потребовал сократить число итераций до 1.
a123-flex
Цитата(AlexandrY @ Aug 25 2017, 10:57) *
Устаревшая концепция.
Наша вселенная - это симуляция. Поскольку всё дискретно, все квантуется, и время и пространство. Т.е. все исчислимо. В нашей вселенной нет бесконечности.

А как же единство и взаимопереход противоположностей, теория относительности, электрон - волна - частица ?

Цитата(novikovfb @ Aug 25 2017, 07:34) *
Ева - вторая итерация, первая была Лилит, но ее все признали неудачной. Кроме этого, был "Великий потоп", т.е. утилизация неудачных экземпляров. Так что, и Бог не сразу делал идеально.

yeah.gif beer.gif a14.gif
SimpleSoft
С Новым, уже 2018 годом. Всех благ!
Добавлю еще от себя.

Мы попробовали двинуться дальше в области качества ПО.
Приобрели LDRA пакет вместе с TBManager, TBrun, LDRAcover, LDRAunit.
Данный пакет умеет увязывать требования написанные в Word или из JIRA/Polarion с кодом. А также запускать тесты прямо на железе используя JTAG.
Более подробно - презентация.

Возник попутно вопрос - а что вы используете для отладки кода, когда ещё железо не готово?
Отладки спаянные воедино? Может есть софтовые эмуляторы? (как например QEMU) или что-то иное? (Особенно если 60% кода копируется из проекта-в-проект, меняется только приложение)
К примеру: есть проект на FreeRTOS который конвертирует аналоговые входы используя алгоритмы в цифру и гонит по Ethernet по спец протоколам. Нужно сделать ещё пару приложений, которые основу имеют туже, но кол-во аналоговых входов другое, уровни другие, выхлодной протокол другой - но железо не готово. Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово?
Какие при этом риски?
SSerge
Цитата(SimpleSoft @ Jan 3 2018, 20:02) *
Как разрабатывать софт параллельно максимально абстрагируя софт от железа пока оно не готово?

Этом не просто хороший, это отличный вопрос, в нём содержится 100% ответа.
SimpleSoft
Цитата(SSerge @ Jan 3 2018, 16:03) *
Этом не просто хороший, это отличный вопрос, в нём содержится 100% ответа.


Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью.
mantech
Цитата(SimpleSoft @ Jan 3 2018, 19:27) *
Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью.


Если малой кровью, то "включайте голову", ибо это самый лучший эмулятор, плюс макеты, которые никто не отменял. rolleyes.gif

Или еще так, пока железо не готово, беру стандартные модули от прошлых разработок, делаю на них основу программы, а когда подъезжает новое железо уже окончательно правлю под него. И время экономится и без дела не сижу..
Студент заборстроительного
Цитата(SimpleSoft @ Jan 3 2018, 19:27) *
Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью.

Волшебство в программировании мало распространено

Цитата(mantech @ Jan 3 2018, 19:57) *
"включайте голову", ибо это самый лучший эмулятор

+100
Поддерживаю данного оратора beer.gif
SimpleSoft
Спасибо!
Про голову, это конечно замечательноsm.gif
Но я хочу спросить за конкретику. Может кто-то знает хорошие техники из опыта?
Я понимаю, что нужно соблюдать баланс между стоимостью решения для тестирования/отладки без железа и производства реальных образцов. Однако время простоя тоже денег стоит.
mantech
Цитата(SimpleSoft @ Jan 7 2018, 14:18) *
Спасибо!
Про голову, это конечно замечательноsm.gif
Но я хочу спросить за конкретику. Может кто-то знает хорошие техники из опыта?
Я понимаю, что нужно соблюдать баланс между стоимостью решения для тестирования/отладки без железа и производства реальных образцов. Однако время простоя тоже денег стоит.


Да никто не скажет про конкретную методику, ибо ее нет таковой, чтоб конкретной. Одно дело тестировать железяку для узкого применения, например привод двигателя или контроллер передачи данных, тут тестирование просто сводится к тому, чтоб устройство работало под полной нагрузкой и не глючило или выходило из строя. Другое дело - устройства, предназначенные для работы с клиентами, например вендинговое оборудование, тут проверить его самому разработчику крайне сложно, даже работникам предприятия, в котором создается сей аппарат, ибо люди уже интуитивно знают, куда "тыкать" можно, а куда нет, поэтому тестирование такой техники возможно только "на клиентах", т.е. на торговой точке. Единственное, что должен сделать разработчик в этом случае - это грамотная система логов при сбоях.
Студент заборстроительного
Цитата(mantech @ Jan 7 2018, 16:42) *
Да никто не скажет про конкретную методику, ибо ее нет таковой, чтоб конкретной.

Я ему уже сказал
"Волшебство в программировании мало распространено"
Kabdim
Использую gmock+gtest, но как правило тестирую не всю прошивку, а отдельные модули.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.