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

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


Конечно, но этому есть причина - тот кто сделает за 2 итерации просто вылетит с рынка, так как не влезет ни по срокам, ни по стоимости, и никакому заказчику на его объекте эксперименты ни к чему.Но если разбивать такую разработку на несколько этапов, то на отдельных из них будут итерации, как ни крути. Например при пуско-наладке часто надо внести изменения в код или перенастроить параметры и провести тесты. Это итерации, количество которых можно уменьшить, например, путем отладки на макете, моделирования/симуляции, или HIL или на основании опыта.

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


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

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

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

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

Хотя по хорошему нужно было бы попробовать разные решения на разных компнентах

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

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

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

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


Так вот этого и хочет избежать тот начальник, который хочет сделать "за одну итерацию"

Тогда я начальника полностью понимаю. Надо быть конкретно криворуким чтобы не сделать работающий AC/DC ( о нем вроде шла речь) с первого раза.
Тонны референс дизайнов,
Готовых блоков море.
Буквально у меня сейчас на столе такой на 100 A, с возможностью включения в параллель. Т.е. хоть 500 А могу изобразить.
Нарисуй на плате несколько вариантов если сомневаешься, предусмотри установку разных вариантов силовых элементов, поставь нормальный микроконтроллер с диагностикой и телеметрией и дело в шляпе.
Чего рассусоливать про итерации?

Вот видите, а тут народ про плохих начальников и волю всевышнего рассуждает.

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

По деньгам "Несколько вариантов" и "несколько итераций" с точки зрения начальства "те же яйца, только вид сбоку"

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

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

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

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


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

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

Какая бы "тяжелая" дискуссия не была - для себя много интересного прочел.


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



Я встречал клиентов, которые планируют бюджет на 1..3 года. И там закладывают суммы на проект достаточно большие и им безболезненно делать по 6-8 итераций. Главный результат после 1-3 лет проектирования - стабильный серийный продукт.
И была реальная история:
Инженер из Испании 8 раз переделывал схему платы. Спросите - а почему? А я отвечу - всё просто: он ленив. Он берёт референс и срисовывает 1 к 1 (бывает с ошибками), без моделирования в LTSpice и согласования с программистами. Разводят ему плату, производят, она приходит - а там косяк или софт не может реализовать его "хотелки". И так по циклу.
Уволить не просто - ибо до пенсии осталось 3 года, а он и рад растягивать проект.

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

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

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

Здесь я с вами не соглашусь. Это просто другая логика работы фирмы, другая стратегия и поведение на рынке. На мой взгляд, более присущая крупным, раскрученным фирмам. Она может не хуже, и не лучше. Но не единственно возможная...

Быстро выйти на рынок, чтобы снять сливки, а дальше действовать по ситуации - это одна стратегия, а создать конкурентоспособное серийное изделие, которое, возможно, потом будет "кормить" вас годами - совсем другая. Просто, прежде чем ввязаться в такой проект, люди обычно крепко думают. До того как, а не в процессе и не после. Оценивают свои силы и возможности. Потянут или нет. Смогут ли преодолеть многочисленные трудности, многие из которых еще даже не известны до конца. А когда решение принято и процесс запущен, то обратного хода, как правило, нет - либо достижение результата (уже даже не столь важно, какой ценой), либо убытки.

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

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

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


Вы рассказываете про идеальных инноваторских бизнесменов. Я из таких только Маска знаю. Но у него есть парашют. :-) Многим не так повезло по жизни ни с талантами, ни с везением, ни с думаньем, ни с силами. Так что им, лучше и не начинать что-ли?

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

https://electronix.ru/forum/index.php?showt...=141482&hl=

На первой итерации выявляются ляпы, не оптимальности и то, что не учли при проектировании.

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

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

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

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

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

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

Может я отстал от жизни, и теперь принято не перепаивать ручками даже резистры, а сразу новую "итерацию" изготавливать,
как тут привели в пример "испанца"))) Если это так, то понятно почему "шеф" потребовал сократить число итераций до 1.

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

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

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

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

Этом не просто хороший, это отличный вопрос, в нём содержится 100% ответа.

Я скорее имел ввиду - возможно кто-то знает техники, как это сделать малой кровью.

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

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

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


+100
Поддерживаю данного оратора

Спасибо!
Про голову, это конечно замечательно
Но я хочу спросить за конкретику. Может кто-то знает хорошие техники из опыта?
Я понимаю, что нужно соблюдать баланс между стоимостью решения для тестирования/отладки без железа и производства реальных образцов. Однако время простоя тоже денег стоит.

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

Я ему уже сказал
"Волшебство в программировании мало распространено"

Использую gmock+gtest, но как правило тестирую не всю прошивку, а отдельные модули.