I. Kematangan Proses Pengembangan Perangkat Lunak
Landasan kualitas perangkat lunak terletak pada standarisasi proses pengembangan. Tingkat kemampuan SPICE otomotif saat ini menjadi tolok ukur industri untuk kematangan proses perangkat lunak, namun mencapai CL2 atau CL3 hanyalah titik dasar. Apa yang benar-benar menentukan kualitas pengiriman perangkat lunak adalah pengendalian penyimpangan selama pelaksanaan proses. Mengambil manajemen persyaratan sebagai contoh, penyimpangan yang umum adalah setelah perubahan persyaratan, kasus uji terkait tidak diperbarui secara serempak. Dalam satu proyek, fungsi pemutakhiran OTA ditemukan setelah SOP mengalami masalah di mana ketika daya kendaraan berada dalam kondisi daya rendah, tugas pengunduhan OTA akan ditangguhkan tanpa batas waktu tanpa melaporkan kesalahan. Penyebab utamanya adalah dokumen persyaratan telah menambahkan logika perlindungan biaya rendah, namun kasus pengujian terkait masih hanya mencakup verifikasi fungsi pengunduhan tanpa menyertakan skenario interupsi dan pemulihan. Dari pengenalan hingga penemuan, cacat ini mencakup empat versi berulang, dan biaya koreksi hampir empat puluh kali lebih tinggi dibandingkan jika ditemukan lebih awal. Matriks ketertelusuran persyaratan perlu dimasukkan ke dalam jalur integrasi berkelanjutan. Ketika status persyaratan berubah menjadi diubah, tugas peninjauan untuk kasus pengujian terkait harus dipicu secara otomatis, dan kasus pengujian yang belum lolos peninjauan harus ditandai sebagai item pemblokiran. Tinjauan kode juga perlu diukur. Penelitian menunjukkan bahwa modul dengan kurang dari dua komentar ulasan per seribu baris kode memiliki kepadatan cacat-pasca rilis tiga kali lebih tinggi dibandingkan modul dengan lebih dari lima komentar per seribu baris. Namun, jumlah komentar ulasan tidak dapat digunakan sebagai indikator absolut karena ada juga-komentar berkualitas rendah. Pendekatan yang efektif adalah dengan mengklasifikasikan komentar tinjauan ke dalam lima kategori: kesalahan logika, kondisi batas yang hilang, keterbacaan kode, risiko kinerja, dan risiko keselamatan, dengan fokus khusus pada tingkat deteksi dua kategori fatal: kesalahan logika dan risiko keselamatan.
II. Integrasi Berkelanjutan dan Pengujian Berkelanjutan
Percepatan iterasi perangkat lunak memerlukan pergeseran pengujian ke kiri, yang berarti verifikasi kualitas diperkenalkan pada tahap penerapan kode. Pengujian unit adalah garis pertahanan paling kiri, namun dalam proyek sebenarnya, cakupan kode pengujian unit sering kali mengalami peningkatan nilai. Dalam satu proyek pengontrol, laporan pengujian unit menunjukkan cakupan jalur sebesar 92%, namun sejumlah besar kesalahan dasar masih ditemukan selama pengujian integrasi. Analisis retrospektif mengungkapkan bahwa meskipun baris kode yang mengandung kesalahan ini dieksekusi, pernyataan pengujian tidak memeriksa keluaran yang relevan. Cakupan garis hanya menunjukkan bahwa kode telah dieksekusi, bukan keluaran yang telah diverifikasi. Salah satu metode perbaikan adalah dengan memperkenalkan pengujian mutasi, yang secara otomatis menghasilkan kode mutan untuk mengevaluasi efektivitas kasus uji. Jika mutan tidak dibunuh, ini menunjukkan adanya kesenjangan dalam pernyataan pengujian. Masalah lain dalam pipeline integrasi berkelanjutan adalah waktu eksekusi pengujian yang berlebihan. Di salah satu gudang perangkat lunak OEM, rangkaian pengujian regresi lengkap memerlukan waktu lebih dari 20 jam untuk dijalankan, yang berarti pengembang sering kali harus menunggu hingga hari berikutnya untuk menerima masukan setelah mengirimkan kode. Solusinya mencakup pengujian paralel, prioritas kasus pengujian, dan pengujian tambahan. Pengujian paralel membagi rangkaian pengujian ke beberapa node eksekusi, sehingga mengurangi waktu eksekusi menjadi sekitar{12}}sepersepuluh dari waktu eksekusi aslinya. Prioritas kasus uji didasarkan pada distribusi cacat historis, dengan memprioritaskan 20% kasus uji yang paling mungkin mendeteksi cacat baru. Subset ini dapat menangkap sekitar 70% cacat baru. Pengujian tambahan hanya mengeksekusi kasus pengujian yang terkait dengan perubahan kode saat ini, menggunakan analisis statis untuk mengidentifikasi cakupan dampak dari perubahan untuk memfilter cakupan pengujian secara dinamis.
AKU AKU AKU. Pengukuran Cacat Perangkat Lunak dan Analisis Akar Penyebab
Metrik pengukuran untuk cacat perangkat lunak perlu diperlakukan secara berbeda dari cacat perangkat keras. Cacat perangkat keras biasanya berfokus pada kepadatan cacat, seperti jumlah cacat per juta bagian. Namun, distribusi kerusakan perangkat lunak mengikuti prinsip Pareto, dengan sekitar 80% kerusakan parah terkonsentrasi pada 20% modul. Oleh karena itu, metrik yang lebih efektif adalah tren konvergensi-tingkat cacat modul, yang berarti perubahan bersih pada cacat terbuka untuk setiap modul di seluruh iterasi. Jika sebuah modul menunjukkan peningkatan bersih pada cacat terbuka selama tiga iterasi berturut-turut, hal ini menunjukkan adanya masalah arsitektur mendasar yang memerlukan tinjauan pemfaktoran ulang. Kedalaman analisis akar permasalahan cacat menentukan efektivitas tindakan pencegahan. Kerangka klasifikasi yang umum digunakan mengkategorikan akar penyebab cacat perangkat lunak menjadi lima jenis: penyimpangan pemahaman persyaratan, cacat logika desain, kesalahan implementasi pengkodean, kesalahan manajemen konfigurasi, dan perbedaan ketergantungan lingkungan. Kesalahan manajemen konfigurasi adalah kategori unik untuk proyek perangkat lunak. Contoh umum termasuk penggunaan versi perpustakaan middleware yang salah, pengaturan opsi kompiler yang tidak konsisten, dan perbaikan penting yang hilang selama penggabungan cabang. Dalam satu proyek, kesalahan logika kontrol lampu rem ditemukan selama pengujian putaran terakhir sebelum pengiriman. Kesalahan ini ditelusuri kembali ke penggabungan cabang tiga bulan sebelumnya, di mana pengembang salah memilih untuk membuang semua perubahan pada modul kontrol lampu rem saat menggabungkan kode fitur dari cabang utama. Kasus ini menunjukkan bahwa perbandingan perbedaan setelah penggabungan cabang harus menjadi gerbang wajib, dengan personel yang ditunjuk bertanggung jawab untuk meninjau permintaan penggabungan.
IV. Penarikan Perangkat Lunak dan Manajemen OTA
Dengan meluasnya adopsi teknologi OTA, metode perbaikan kerusakan perangkat lunak mengalami perubahan mendasar. Penarikan kembali perangkat lunak tradisional mengharuskan kendaraan mengunjungi pusat layanan untuk melakukan flashing, yang memakan biaya,-waktu, dan rendahnya kepatuhan pengguna. Penarikan kembali OTA dapat diselesaikan secara langsung melalui push jarak jauh, tetapi sesuai dengan persyaratan peraturan