設計変更命令に相当するソフトウェアとは何ですか？

ベアメタルマイクロコントローラーでソフトウェアの更新を検討しているデバイスがあります。新しいイメージは、将来のすべての製品でプログラムされます。

デバイスのコンポーネントを変更する場合は、技術変更指示を記入する必要があります。

ソフトウェアを変更するときに、同等の業界手順がありますか？

私はまだそれをECOと呼んでいます。

ファームウェアが工場でマイクロにプログラムされている場合、そのファームウェアとその特定のバージョンはBOMの行項目でなければなりません。
ファームウェアの変更とは、BOMの変更を意味します。
BOMを変更するにはECOが必要です。

それに続いて、ファームウェアのフィールド更新は、フィールド内のユニットにハードウェアの変更が必要な場合に実行されるプロセスと同様のプロセスに従う必要があります。
したがって、これをECOと呼ぶと、これもECOです。

通常、ソフトウェアの変更はパッチまたは（ソフトウェアアップデート）と呼ばれます。私の知る限り（会社によって異なります）、この手順はパッチまたはソフトウェア更新手順と呼ばれます。

ただし、ほとんどの場合、ソフトウェアの更新はインストールを処理する特別なアプリケーションを実行するだけであり、必要な変換などはすべてパッチの一部です。

したがって、電子部品交換とは異なり、現在の既存のソフトウェアは、パッチソフトウェア自体の一部であるため、通常、アンインストールまたは変更する必要はありません。

また、パッチ/ソフトウェアの更新をインストールできるかできない場合に制限または条件がある場合、パッチ自体でチェックされ、インストールが有効である場合にのみインストールされます（または、少なくとも、そのように動作するはずです） ）。

そのため、原則として、パッチ/ソフトウェアの更新は次のような多くのことを行います（完全ではない可能性があります）。

• パッチ/ソフトウェアアップデートをインストールできるかどうかを確認します（オペレーティングシステムのバージョン、インストールされている現在のバージョンなど）。
• そうでない場合は、メッセージが表示され、パッチ/アップデートが停止します。
• インストールできる場合は、変換する必要のあるファイルが実行されます（これは、パッチを適用または更新するメインアプリケーションの一部である場合があります）。
• 新しいファイルが更新されるか、アプリケーションに追加されて更新/パッチが適用されます。
• リリースノートが表示されます（オプション）。
• アプリケーションが開始されます（オプション）。

用語私は、通常の使用ではある変更要求変更要件のために変更する必要があるもののために、そして問題報告の必要性がエラーにより変更することをもののために。

これらは収集され、特定の更新サイクルでスケジュールされます。サイクルが内部のみの場合、マイルストーンと呼ばれ、顧客に展開される場合、リリースと呼ばれます。

一般的なタイムラインには、リリース前にいくつかのマイルストーンがあり、リリース候補と呼ばれ、広範なテストが行​​われます。そこで見つかったエラーは、次のマイルストーンが十分に重要な場合は再度スケジュールされ、そうでない場合は後のリリースのいずれかで再びスケジュールされます。

ここでエラーが少なくなることを期待して、顧客の苦情に応じて特定のPRのみに対処するブランチを作成することもできます。これは通常、更新の労力が十分に低い場合にのみ行われます（たとえば、特定の名前のファイルを含むUSBスティックを差し込むだけで更新をインストールできるため）。

簡単な答え：ソフトウェアバージョン管理システムに組み込まれています。

長い答え：

ソフトウェアは、ハードウェアよりもはるかに急速に変化する傾向があります。通常、ソフトウェアは、人気のあるGitのような何らかのバージョン管理システム（VCS）を使用します。私が携わったほとんどのソフトウェア企業は、VCSを使用してソフトウェアの変更を追跡し、各コミットで変更の理由を説明しています。既知のバグ、改善などを追跡する問題追跡ツールも使用します。通常、あるブランチで開発が行われるプロセスがあり、その開発は「メイン」（リリース）ブランチにマージされる前にテストされます。これは、ソフトウェア開発の変更頻度が高い場合と、ハードウェアのテンポが遅い場合のほうがはるかに効率的です。これの具体的な実装とプロセスは会社によって異なり、多くの場合、QAの目的の標準（ISO9001、AS9100Dなど）の影響を受けます。

例：

1. あなたは変更を加えることにしました。

2. 課題トラッカーで課題を作成します。

3. 問題に対処するためにブランチを作成します。
4. ソフトウェアをいくつか変更します。
5. 会社のポリシーごとに変更をピアレビューします
6. プルリクエストを発行し、devブランチにマージします。
7. 問題を閉じます。

適切に実行される業界設定では、マイクロにフラッシュされるファームウェア自体が一部であり、その特定の実行可能ファイル（hexファイルなど）の部品番号があります。ファームウェアを変更したい場合は、BOM（部品表）の変更です。また、チップを交換する場合と同じように、ECOが必要です。

それは本当に簡単です。

これには当然の結果があります。ファームウェアに部品番号がなく、BOMにリストされておらず、したがって制御されていない場合、おそらく品質プロセスを改善する必要があります。ISO-9001または類似のものに適合することになっている場合、これは修正が必要なプロセスの明確なギャップです。

ソフトウェアアップデートはパッチと呼ばれるか、「ソフトウェアアップデート」と呼ばれます。ソフトウェアエンジニアに、ユニットが「最新バージョンに」更新されているかどうかを常に確認します。

理想的には、バージョン管理は利害関係者によって「サインオフ」され、実稼働環境にリリースされる前にテストされますが、ほとんどの場合、このプラクティスはほとんどの場合にのみ発生します。