Что является программным эквивалентом технического заказа на изменение?

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

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

Существует ли аналогичная отраслевая процедура при смене программного обеспечения?

Я бы все еще назвал это ЭКО.

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

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

Обычно изменение программного обеспечения называется исправлением или обновлением программного обеспечения. И, насколько я знаю (в зависимости от компании), процедуры называются Patch или процедурой обновления программного обеспечения.

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

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

Кроме того, в случае, если существуют ограничения или условия, когда исправление / обновление программного обеспечения может или не может быть установлено, оно будет проверено в самом исправлении и будет установлено только тогда, когда оно действительно для установки (или, по крайней мере, оно должно работать таким образом). ).

В принципе, обновление патча / программного обеспечения делает много вещей, например (возможно, не завершенных):

• Проверьте, можно ли установить исправление / обновление программного обеспечения (например, версии операционной системы, текущая версия установлена ​​и т. Д.)
• Если нет, появится сообщение, и патч / обновление остановится.
• Если он может быть установлен, файлы, которые должны быть преобразованы, будут сделаны (это иногда является частью основного приложения, которое будет исправлено / обновлено).
• Новые файлы обновляются или добавляются в приложение для обновления / исправления.
• Примечания к выпуску показаны (опционально).
• Приложение запускается (опционально).

Обычно я использую термины « Запрос на изменение» для вещей, которые необходимо изменить в связи с измененными требованиями, и « Отчет о проблемах» для вещей, которые необходимо изменить из-за ошибок.

Они собираются, а затем запланированы для определенных циклов обновления. Если цикл является только внутренним, он называется Milestone , а если он развернут для клиентов, он называется Release .

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

Также возможно создать филиал, который рассматривает только определенные PR в ответ на жалобы клиентов, с отдельным выпуском, который не имеет дальнейших изменений, в надежде, что здесь будет меньше ошибок. Обычно это делается только в том случае, если усилия по обновлению достаточно малы (например, поскольку обновления можно установить, просто подключив USB-накопитель с файлом с определенным именем на нем).

Краткий ответ: Он встроен в систему управления версиями программного обеспечения.

Длинный ответ:

Программное обеспечение имеет тенденцию меняться гораздо быстрее, чем аппаратное обеспечение. Обычно программное обеспечение использует какую-то систему контроля версий (VCS), например, популярный Git. Большинство софтверных компаний, с которыми я работал, используют VCS для отслеживания изменений в программном обеспечении, причем каждый коммит объясняет причину изменения. Некоторые также используют систему отслеживания ошибок, которая отслеживает известные ошибки, улучшения и тому подобное. Обычно существует процесс, в котором разработка происходит в одной ветви, затем эта разработка тестируется перед объединением в «основную» (выпускную) ветку. Это имеет тенденцию быть намного более эффективным для высокой частоты изменений в разработке программного обеспечения по сравнению с более медленным темпом в оборудовании. Конкретная реализация и процесс этого варьируются от компании к компании и часто зависят от стандарта для целей обеспечения качества (ISO9001, AS9100D и т. Д.).

Пример:

1. Вы решили внести изменения.

2. Вы создаете проблему в трекере проблем.

3. Вы создаете ветку для решения проблемы.
4. Вы делаете некоторые изменения программного обеспечения.
5. Ваши изменения проверены в соответствии с политикой компании
6. Вы отправляете запрос на удаление и возвращаетесь в ветку dev.
7. Вы закрываете вопрос.

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

Это действительно так просто.

Есть следствие этого. Если ваша микропрограмма не имеет номера детали и не указана в спецификации и, следовательно, не контролируется, вероятно, процесс улучшения качества нуждается в улучшении. Если вы должны соответствовать ISO-9001 или чему-то подобному, это определенный пробел в вашем процессе, который необходимо устранить.

Обновления программного обеспечения называются исправлениями или являются обновлениями программного обеспечения. Я всегда спрашиваю разработчиков программного обеспечения, обновлено ли устройство «до последней версии».

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