Що таке програмний еквівалент замовлення на інженерні зміни?

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

Якби я міняв компонент на пристрої, мені потрібно було б заповнити інженерний порядок зміни.

Чи існує еквівалентна галузева процедура при зміні програмного забезпечення?

Я б все-таки називав це ЕКО.

Якщо прошивка запрограмована на мікрофоні на заводі, то ця прошивка та її конкретна версія повинні бути позицією на BOM.
Зміна прошивки означає зміну BOM.
Для зміни BOM потрібен ECO.

Виходячи з цього, оновлення прошивки на місцях має слідувати аналогічному процесу, який би виконувався, якби для модуля в цьому полі потрібен модуль на апаратне забезпечення.
Отже, якщо ви називаєте це ЕКО, то це теж ЕКО.

Зазвичай зміна програмного забезпечення називається Патч або (Оновлення програмного забезпечення). І наскільки я знаю (залежно від компанії) процедури називаються процедурою Patch або Software Update.

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

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

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

Тому в принципі оновлення програмного забезпечення та програмного забезпечення робить багато речей, як-от (можливо, не повне):

• Перевірте, чи можна встановити патч / оновлення програмного забезпечення (наприклад, версії операційної системи, встановлена ​​поточна версія тощо)
• Якщо ні, з'явиться повідомлення, і виправлення / оновлення припиняється.
• Якщо його можна встановити, будуть зроблені файли, які потрібно конвертувати (це іноді є частиною основної програми, яку потрібно виправити / оновити).
• Нові файли оновлюються або додаються до програми для оновлення / виправлення.
• Примітки до випуску показані (необов'язково).
• Запуск програми (за бажанням).

Терміни, які я зазвичай використовую, - це Запит на зміну речей, які потрібно змінити через змінені вимоги, і Звіт про проблеми , які потрібно змінити через помилки.

Вони збираються, а потім плануються для певних циклів оновлення. Якщо цикл є лише внутрішнім, він називається віхою , якщо він розгортається для клієнтів, він називається випуском .

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

Можна також створити відділення, яке розглядає лише конкретні PR-адреси у відповідь на скарги клієнтів, з окремим випуском, який не має додаткових змін, сподіваючись, що тут буде внесено менше помилок. Зазвичай це робиться лише в тому випадку, якщо зусилля для оновлення є досить низькими (наприклад, через те, що оновлення можна встановити просто, підключивши USB-накопичувач із файлом із певним іменем).

Коротка відповідь: Він вбудований у систему версій програмного забезпечення.

Довга відповідь:

Програмне забезпечення, як правило, змінюється набагато швидше, ніж апаратне. Зазвичай програмне забезпечення використовує якусь систему управління версіями (VCS), як популярна Git. Більшість програмних компаній, з якими я працював, використовують VCS для відстеження змін у програмному забезпеченні, при цьому кожен комітет пояснює міркування за зміною. Деякі також використовують трекер випуску, який відстежує відомі помилки, удосконалення тощо. Зазвичай існує процес, коли розвиток відбувається на одній гілці, тоді ця розробка тестується до об'єднання у "головну" (випускну) гілку. Це, як правило, набагато ефективніше для високої частоти змін у розробці програмного забезпечення порівняно з повільнішим темпом обладнання. Конкретна реалізація та процес цього варіюється від компанії до компанії, і на нього часто впливає стандарт для забезпечення якості (ISO9001, AS9100D тощо).

Приклад:

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

2. Ви створюєте проблему в трекері випусків.

3. Ви створюєте відділення для вирішення проблеми.
4. Ви вносите деякі зміни програмного забезпечення.
5. Ви перевіряли свої зміни відповідно до політики компанії
6. Ви надсилаєте запит на витяг та знову зливаєтесь у відділення розробників.
7. Ви закриваєте питання.

У правильному запусках галузевих програм, мікропрограмне забезпечення, яке прошивається в мікросхему, є самою частиною і має номер деталі для цього конкретного виконуваного файлу (шістнадцятковий файл чи інше). Якщо ви хочете змінити прошивку, це зміна на BOM (рахунок матеріалів). І для цього потрібен ECO так само, як якщо б ви хотіли замінити чіп.

Це дійсно так просто.

Це є наслідком цього. Якщо ваша прошивка не має номера деталі і не вказана в BOM і, отже, не контролюється, то ваш процес якості, ймовірно, потребує покращення. Якщо вам належить відповісти на ISO-9001 або щось подібне, це певний розрив у вашому процесі, який потребує виправлення.

Оновлення програмного забезпечення називають виправленнями або вони є тими, що є "оновленнями програмного забезпечення". Я завжди запитую у інженерів програмного забезпечення, чи пристрій оновлюється "до останньої версії".

В ідеалі версію "підписують" зацікавлені сторони та перевіряють до випуску у виробництво, але частіше за все у більшості випадків ця практика відбувається лише більшу частину часу.