Sistem jaminan kualitas perangkat lunak untuk sistem keselamatan adalah proses kompleks yang mencakup verifikasi fungsi perangkat lunak, manajemen konfigurasi, integrasi berkelanjutan, dan penilaian keselamatan independen untuk memastikan sistem sesuai dengan persyaratan keselamatannya.

1. System software quality assurance for safety critical systems
WELLY PRATAMA (1534010031)
PARAREL A

2. Pengertian
Sistem jaminan kualitas perangkat lunak untuk sistem keselamatan adalah sesuatu
usaha 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.
Manajemen mutu ditetapkan dengan standar ISO 9000 dan turunannya, yang
terbaru adalah ISO 9001: 2015.

3. Prosedur Verifikasi Fungsi Perangkat Lunak
• Pengembang menguji fungsi baru untuk memastikan bahwa kode tersebut
berperilaku seperti yang diharapkan
• Uji modul
• Uji sub system
• Uji sistem
• Uji integrasi
• Uji penerimaan pabrik
• Independent Safety Assessment (ISA)
• Notified Body (NoBo)

4. Software Quality Assurance meliputi :
• Sistem kontrol tenaga nuklir
• Sistem kontrol industri pengolahan
• Peralatan medis
• Sistem kontrol sinyal kereta api
• Sistem kontrol kedirgantaraan
• Angkatan laut
• Misi luar angkasa

5. Penegasan Terhadap Kualitas Software
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 meliputi :
- Studi perencanaan dan kelayakan
- Spesifikasi persyaratan
- Arsitektur
- Perancangan
- Implementasi

6. model V

7. Metode Yang Digunakan
• 2.1 Coding Rules
• 2.2 Review Source Code
• 2.3 Configuration Management
• 2.4 Continous Integration
• 2.5 Requirement Tracing
• 2.6 Qualitative and quantitative technical safety

8. Aturan Pengkodean
Beberapa kendala yang didapatkan pada bahasa pemrograman sistem
keselamatan adalah: bertipe kuat, mendukung pemrograman defensif dan
terstruktur.
Bahasa pemrograman yang memenuhi batasan ini tidak berarti bahwa bahasa
pemrograman itu aman.
Standar dan konvensi pengkodean digunakan untuk memberlakukan
penggunaan subset dan mencegah insinyur perangkat lunak melakukan
operasi pengkodean yang tidak aman.
Software engineer terkadang membuat keputusan yang salah, oleh karena itu
penerapan peraturan pengkodean harus dilakukan secara otomatis dan
diterapkan selama kompilasi dan pembangunan sistem.

9. Review Source Code
Software engineering dilatih untuk menyimpulkan algoritma ataoun membuat
algoritma itu sendiri
Source code review adalah suatu teknik untuk mejaga kode tetap sederhana dan
mudah dijaga
Pada dasarnya, arsitektur sistem keamanan perangkat lunak haruslah standar dan
memilki kohesi yang tinggi
Source code review yang bagus diterapkan dengan alat berbasis web, jadi pengulas
bisa melakukan review aktivitas sesuai jadwal mereka sendiri

10. Manajemen Konfigurasi
Manajemen konfigurasi adalah bagian intrinsik dari jaminan kualitas perangkat lunak
secara keseluruhan.
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.

11. Integrasi yang berkelanjutan
Pelanggan dapat membuat Change Requests (CR) dengan persyaratan baru, juga
Non-Conformity Report (NCR) dapat diajukan untuk analisis dan implementasi.
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.

12. TUJUAN
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.
Siklus hidup pengembangan produk yang nyata, menerapkan praktik terbaik
tersebut tanpa kompromi akan menghasilkan produk yang aman dan bermutu
tinggi.

13. Perangkat lunak di sisi lain tidak teraba, mereka dibuat dari beberapa algoritma
kompleks dengan beberapa jalur dan hasil eksekusi. 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, Ini berarti memeriksa bahwa proses yang diklaim sesuai dengan
undang-undang dan 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.