Apa yang setara dengan perangkat lunak dari urutan perubahan teknik?

Kami memiliki perangkat yang kami pertimbangkan untuk melakukan pembaruan perangkat lunak pada mikrokontroler bare metal. Gambar baru akan diprogram pada semua produk masa depan.

Jika saya mengubah komponen pada perangkat, saya harus mengisi urutan perubahan teknik.

Apakah ada prosedur industri yang setara saat mengganti perangkat lunak?

Saya masih menyebutnya sebagai ECO.

Jika firmware diprogram ke dalam mikro di pabrik, maka firmware dan versi spesifiknya harus menjadi item baris pada BOM.
Mengubah firmware berarti mengubah BOM.
Mengubah BOM membutuhkan ECO.

Setelah itu, pembaruan bidang firmware harus mengikuti proses serupa dengan yang akan diikuti jika mod ke perangkat keras diperlukan untuk unit di lapangan.
Jadi jika Anda menyebutnya ECO, maka ini juga ECO.

Biasanya perubahan perangkat lunak disebut Patch atau (Pembaruan Perangkat Lunak). Dan sejauh yang saya tahu (tergantung pada perusahaan) prosedurnya disebut Patch atau Prosedur Pembaruan Perangkat Lunak.

Namun, dalam kebanyakan kasus, pembaruan perangkat lunak tidak lebih dari menjalankan aplikasi khusus yang menangani instalasi dan semua konversi yang diperlukan, dll. Adalah bagian dari tambalan.

Jadi tidak seperti pertukaran bagian elektronik, tidak ada perangkat lunak yang ada saat ini yang biasanya harus dihapus atau diubah, karena itu adalah bagian dari perangkat lunak tambalan itu sendiri.

Juga, jika ada batasan atau ketentuan kapan pembaruan tambalan / perangkat lunak dapat atau tidak dapat diinstal, itu akan diperiksa dalam tambalan itu sendiri dan hanya akan menginstal ketika valid untuk menginstal (atau setidaknya, itu harus bekerja seperti itu ).

Jadi pada prinsipnya pembaruan tambalan / perangkat lunak melakukan banyak hal, seperti (mungkin tidak lengkap):

• Periksa apakah pembaruan tambalan / perangkat lunak dapat diinstal (misalnya versi sistem operasi, versi saat ini diinstal, dll.)
• Jika tidak, pesan akan ditampilkan dan tambalan / pembaruan berhenti.
• Jika dapat diinstal, file yang perlu dikonversi akan dilakukan (ini kadang-kadang merupakan bagian dari aplikasi utama yang akan ditambal / diperbarui).
• File baru diperbarui atau ditambahkan ke aplikasi untuk diperbarui / ditambal.
• Catatan rilis ditampilkan (secara opsional).
• Aplikasi dimulai (opsional).

Istilah yang biasanya saya gunakan adalah Ubah Permintaan untuk hal-hal yang perlu diubah karena persyaratan yang dimodifikasi, dan Laporan Masalah untuk hal-hal yang perlu diubah karena kesalahan.

Ini dikumpulkan, dan kemudian dijadwalkan untuk siklus pembaruan tertentu. Jika sebuah siklus hanya internal, itu disebut Milestone , jika itu digunakan untuk pelanggan, itu disebut Rilis .

Garis waktu tipikal memiliki beberapa tonggak sebelum rilis, disebut Rilis Calon yang menjalani pengujian ekstensif, dan setiap kesalahan yang ditemukan di sana menghasilkan Laporan Masalah lebih lanjut yang lagi dijadwalkan untuk tonggak berikutnya jika mereka cukup penting, atau rilis kemudian jika tidak.

Dimungkinkan juga untuk membuat Cabang yang hanya menangani PR tertentu dalam menanggapi keluhan pelanggan, dengan rilis terpisah yang tidak memiliki perubahan lebih lanjut, dengan harapan lebih sedikit kesalahan yang diperkenalkan di sini. Ini biasanya hanya dilakukan jika upaya pembaruan cukup rendah (misalnya karena pembaruan dapat diinstal hanya dengan mencolokkan stik USB dengan file dengan nama tertentu di atasnya).

Jawaban singkat: Ini dibangun ke dalam sistem versi perangkat lunak.

Jawaban panjang:

Perangkat lunak cenderung berubah jauh lebih cepat daripada perangkat keras. Biasanya perangkat lunak menggunakan semacam sistem kontrol versi (VCS), seperti Git yang populer. Sebagian besar perusahaan perangkat lunak tempat saya bekerja menggunakan VCS untuk melacak perubahan pada perangkat lunak, dengan masing-masing komit menjelaskan alasan di balik perubahan tersebut. Beberapa juga menggunakan pelacak masalah, yang melacak bug yang diketahui, peningkatan, dan semacamnya. Biasanya ada proses di tempat pengembangan terjadi pada satu cabang, maka pengembangan itu diuji sebelum digabung menjadi cabang "utama" (rilis). Ini cenderung jauh lebih efisien untuk frekuensi tinggi perubahan dalam pengembangan perangkat lunak vs tempo yang lebih lambat dalam perangkat keras. Implementasi dan proses spesifik ini bervariasi dari perusahaan ke perusahaan, dan sering dipengaruhi oleh standar untuk tujuan QA (ISO9001, AS9100D, dll.).

Sebuah contoh:

1. Anda memutuskan untuk melakukan perubahan.

2. Anda membuat masalah di pelacak masalah.

3. Anda membuat cabang untuk mengatasi masalah ini.
4. Anda membuat beberapa perubahan perangkat lunak.
5. Anda meminta perubahan rekan sejawat Anda per kebijakan perusahaan
6. Anda mengeluarkan permintaan tarik dan bergabung kembali ke cabang dev.
7. Anda menutup masalah.

Dalam pengaturan industri yang dijalankan dengan benar, firmware yang akan di-flash ke mikro itu sendiri adalah bagian dan memiliki nomor bagian untuk itu yang dapat dieksekusi spesifik (file hex atau apa pun). Jika Anda ingin mengubah firmware, itu adalah perubahan ke BOM (bill of material). Dan itu membutuhkan ECO dengan cara yang sama seperti jika Anda ingin mengganti sebuah chip.

Ini sangat sederhana.

Ada konsekuensi wajar untuk ini. Jika firmware Anda tidak memiliki nomor bagian dan tidak terdaftar dalam BOM dan karenanya tidak terkontrol, maka proses kualitas Anda mungkin perlu ditingkatkan. Jika Anda seharusnya memenuhi ISO-9001 atau yang serupa, ini adalah celah yang pasti dalam proses Anda yang perlu diperbaiki.

Pembaruan perangkat lunak disebut tambalan atau mereka adalah "pembaruan perangkat lunak". Saya selalu bertanya kepada insinyur perangkat lunak apakah unit diperbarui "ke versi terbaru".

Idealnya versi "ditandatangani" oleh para pemangku kepentingan dan diuji sebelum dirilis ke dalam produksi, tetapi lebih sering daripada tidak di sebagian besar tempat praktik ini hanya terjadi sebagian besar waktu.