Sistem jaminan kualitas perangkat lunak untuk sistem keselamatan kritis seperti sistem sinyal kereta api sangat penting karena perangkat lunak akan membuat keputusan pengendalian penting. Namun, prosedur penilaian saat ini masih belum mampu menjamin keamanan sistem secara empiris. Perlu diperbaiki dengan melakukan validasi empiris terhadap keamanan sistem, bukan hanya verifikasi klaim vendor.

1. System software quality assurance for safety critical systems
Logika kontrol keamanan kritis sangat diperlukan dalam peralatan modern yang
memiliki tanggung jawab keselamatan. Ketika sistem ini digunakan dalam operasi, perangkat
lunak yang secara diam-diam membuat sebagian besar keputusan pengendalian, dengan sedikit
masukan data dari operator. Tanggung jawab yang terisi pada perangkat lunak peralatan
kontrol juga meningkat selama bertahun-tahun, membuat logika mereka lebih kompleks. Agar
sistem memenuhi semua persyaratan keamanannya, jaminan kualitas perangkat lunak sistem
yang baik sangat penting. Sistem keamanan kritis disertifikasi hanya jika mereka memenuhi
semua kewajiban hukum dan peraturan. Vendor sistem keamanan kritis dan organisasi yang
bertanggung jawab atas sertifikasi pasti bekerja sangat keras untuk menghasilkan sistem yang
aman. Namun, beberapa prinsip ketidakcukupan dalam jaminan kualitas perangkat lunak sistem
masih berlimpah. Paper ini menyarankan perbaikan jaminan kualitas praktis yang dapat
diterapkan vendor terhadap proses pengembangan perangkat lunak mereka. Dan juga
bagaimana klien, validator, dan penilai dapat lebih terlibat secara proaktif selama siklus hidup
proyek.
Sistem jaminan kualitas perangkat lunak untuk sistem keselamatan kritis adalah
perusahaan yang sangat kompleks karena perangkat lunak bukanlah produk yang nyata. Dalam
pembuatan produk fisik seperti furnitur atau elektronik, pengendalian mutu dapat dilakukan
dengan menggunakan pemeriksaan fisik oleh tenaga ahli terlatih dan menggunakan alat khusus
untuk menguji kualitas produk. Jaminan kualitas dan manajemen mutu sangat vital dalam
organisasi apapun dan bahkan lebih vital lagi dalam pengembangan sistem keselamatan kritis.
Manajemen mutu ditetapkan dengan standar ISO 9000 dan turunannya, yang terbaru adalah
ISO 9001: 2015. Untuk setiap organisasi yang mengembangkan sistem kritis keamanan, jaminan
kualitas perangkat lunak sistem seharusnya tidak menjadi tanggung jawab insinyur perangkat
lunak dan insinyur sistem, namun harus diabadikan secara inheren dalam budaya perusahaan
sebagai bagian dari keseluruhan manajemen mutu. Bagaimanapun, ini adalah perangkat lunak
yang secara diam-diam akan membuat keputusan pengendalian yang penting saat sistem

2. dikerahkan dan ditugaskan. Perangkat lunak yang mengendalikan sistem keselamatan kritis
terkadang mengalami kegagalan meski sistem telah menjalani pengujian ketat di beberapa
tingkatan. Kegagalan perangkat lunak bersifat sistematis, karena tidak selalu memungkinkan
untuk menguji semua permutasi dan kombinasi bagian eksekusi dalam sistem. Perangkat lunak
sistem keselamatan kritis dirancang untuk melakukan tugas kelipatan dan bereaksi terhadap
beberapa rangsangan. Sistem berbasis perangkat keras, di sisi lain, dibatasi untuk melakukan
beberapa tugas, sehingga kegagalan mereka acak dan sebagian besar disebabkan oleh penuaan.
Biasanya prosedur verifikasi fungsi perangkat lunak adalah sebagai berikut; Pengembang
menguji fungsi baru untuk memastikan bahwa kode tersebut berperilaku seperti yang
diharapkan, setelah itu uji modul dilakukan diikuti oleh uji subsistem, uji sistem dan uji
integrasi. Menjelang akhir siklus pengembangan, uji penerimaan pabrik dilakukan, asesmen
keselamatan independen (ISA) dilakukan dan bila ada badan yang diberi notifikasi (NoBo) juga
dilakukan. Dan produk ini disertifikasi sesuai untuk tujuan dan mampu menangani tanggung
jawab keselamatan untuk pengendalian sistem komputerisasi. Sistem keselamatan kritis
mencakup sistem kontrol tenaga nuklir, sistem kontrol industri pengolahan, peralatan medis,
sistem kontrol sinyal kereta api, sistem kontrol kedirgantaraan, dan angkatan laut, dan misi luar
angkasa. Paper ini difokuskan pada jaminan kualitas perangkat lunak sistem untuk sistem sinyal
kereta api.
Di industri perkeretaapian, perangkat lunak untuk system keselamatan kritis biasanya
mengikuti model V seperti yang ditetapkan oleh Komite Eropa untuk Standardisasi Teknik
Elektro (CENELEC), EN-50128 dimana studi perencanaan dan kelayakan, spesifikasi persyaratan,
arsitektur spesifikasi, perancangan, dan implementasi rinci dilakukan. Setiap tahap, laporan
verifikasi yang sesuai untuk sisi benar dihasilkan. Setelah tahap implementasi, proses verifikasi
bottom-up dimulai sampai instalasi dan commissioning dan kemungkinan perawatan dan de
commissioning. Model V bukan merupakan batu sandungan bagi metodologi pengembangan
tangkas seperti Scrum dan Kanban. Masih ada ruang untuk pengembangan berulang dalam
model V jika kegiatan pembangunan direncanakan dengan cermat. Memproduksi sistem yang
dapat diandalkan, aman, dan toleransi kesalahan memerlukan proses, standar dan konvensi
yang mapan yang mudah diterapkan dan diverifikasi.

3. Beberapa kendala yang ditempatkan pada bahasa pemrograman sistem keselamatan
kritis adalah: mendukung pemrograman defensif dan terstruktur. Bahwa bahasa pemrograman
memenuhi batasan ini tidak berarti bahwa semua operasi bahasa pemrograman aman. Untuk
mengatasi kekurangan bahasa pemrograman yang dipilih, sebagian dari bahasa pemrograman
biasanya digunakan dan sisanya dibuang. Standar dan konvensi pengkodean digunakan untuk
memberlakukan penggunaan subset dan mencegah insinyur perangkat lunak melakukan
operasi pengkodean yang tidak aman. Penerapan standar pengkodean wajib untuk
pengembangan produk SIL-4 menurut lampiran 2, tabel A.12 dari EN-50128. Begitu konvensi
pengkodean disepakati, anggota tim harus menegakkan integritasnya. Setiap penyimpangan
dari konvensi pengkodean harus dipertahankan dengan justifikasi atau alasan yang berani.
Insinyur perangkat lunak adalah manusia dan terkadang manusia membuat keputusan yang
salah, oleh karena itu penerapan peraturan pengkodean harus dilakukan secara otomatis dan
diterapkan selama kompilasi dan pembangunan sistem.
Manajemen konfigurasi adalah bagian intrinsik dari jaminan kualitas perangkat lunak
secara keseluruhan. Harus ada aturan yang didefinisikan dengan baik yang mengatur semua
perubahan pada perangkat lunak selama siklus hidup proyek. Idealnya Change Committee
Board (CCB) harus memutuskan perubahan apa yang harus dilakukan dan kapan harus dibuat.
Revisi dan versi semua kode sumber dan dokumen harus dikelola dengan benar menggunakan
database khusus. Change Requests (CRs) dan Non-Conformity Reports (NCRs) didokumentasikan
dan dilacak dalam database dari analisis sampai verifikasi. Rencana pengelolaan dan rencana
pengelolaan konfigurasi keselamatan biasanya harus mencakup sejumlah tahap tinjauan
penjaminan mutu perangkat lunak. Pada tahap ini, proses pengembangan telah divalidasi dan
pelepasan uji perangkat lunak sistem dikirimkan untuk keperluan subsistem, integrasi dan uji
sistem intensif.
Selama siklus hidup proyek, pelanggan dapat membuat Change Requests (CR) dengan
persyaratan baru, juga Non-Conformity Report (NCR) dapat diajukan untuk analisis dan
implementasi. Semua ini dapat menyebabkan modifikasi perangkat lunak dan pengiriman
berikutnya untuk instalasi dan commissionin. Dalam tim pengembang besar dimana individu

4. yang berbeda memodifikasi modul / komponen dan subsistem yang berbeda, mungkin ada
penyimpangan dalam proses pengujian. Salah satu metodologi penjaminan kualitas perangkat
lunak untuk menjaga integritas kode sumber adalah proses integrasi otomatis yang terus
berlanjut. Semua skrip yang gagal harus dilaporkan ke manajer konfigurasi (CM) yang akan
menghubungi semua orang yang telah memodifikasi kode sumber sistem pada hari
sebelumnya. Pengembang individu kemudian akan memutarkan kembali skripnya, melakukan
koreksi terhadap kode sumber, mengirimkan ulasan kode, dan akhirnya berkomitmen ke dalam
repositori. Prosesnya akan berulang pada berikutnya. Proses integrasi terus menerus membuat
kode sumber tetap stabil dan siap untuk penciptaan awal oleh CM bila diperlukan. Tidak ada
artinya bahwa proses integrasi berkesinambungan tidak menggantikan proses pengujian sistem
lengkap yang mencakup uji modul, uji subsistem, uji integrasi, dan uji sistem.
Tujuan dari proses penilaian adalah untuk secara tegas membuktikan bahwa sistem ini
sesuai untuk tujuan dan bahwa sistem sesuai dengan semua persyaratan keselamatannya.
Selain itu, bukti jaminan yang diklaim oleh vendor dalam kasus keamanan sistem dapat
divalidasi. Selanjutnya tujuan asesmen adalah untuk membuktikan bahwa, vendor sistem
keamanan kritis telah melekuk mengikuti semua proses, baik peraturan perundang-undangan
seperti yang dipersyaratkan oleh perangkat lunak Safety Integrity Level (SIL) dimana sistem ini
dibangun.
Dalam dunia ideal siklus hidup pengembangan produk yang nyata, menerapkan praktik
terbaik tersebut tanpa kompromi akan menghasilkan produk yang aman dan bermutu tinggi.
Perangkat lunak di sisi lain tidak teraba, mereka dibuat dari beberapa algoritma kompleks
dengan beberapa jalur dan hasil eksekusi. Selama bertahun-tahun, prosedur asesmen untuk
sistem keselamatan kritis tidak cukup kuat untuk menjamin sistem yang aman dan toleransi
kesalahan. Fakta kebenarannya adalah bahwa sebagian besar prosedur yang diterapkan untuk
penilaian keselamatan independen terhadap perangkat lunak untuk sistem keselamatan kritis
bersifat teoritis dan bukan empiris. Penilai, untuk sebagian besar, hanya memverifikasi klaim
yang dibuat oleh vendor dan pemeriksa, yang berpegang pada proses siklus produk atau
produk. Ini berarti memeriksa bahwa proses yang diklaim sesuai dengan undang-undang dan

5. kewajiban peraturan. Oleh karena itu penilaian bukanlah jaminan bahwa subsistem aman
digunakan untuk pengendalian, perintah dan pensinyalan. Meskipun kurangnya jaminan ini,
administrasi perkeretaapian dan Infrastructure Managers (IMs) menggunakan penilaian sebagai
tanda kepercayaan bahwa sistem ini sesuai untuk tujuannya.