System Safety and Software Reliability

Kegagalan sistem karena kesalahan eksekusi perangkat lunak yang terjadi pada beberapa kasus seperti roket ariane 5, BMW Airbag Control Unit, Pelayanan ambulans kota London menimbulkan motivasi:

a) Mengapa harus memperhatikan terhadap keselamatan sistem

i) Tidak ada barang atau suatu benda yang mempunyai tingkat kesalahan nol Benda atau suatu objek yang dirancang dan dibuat oleh manusia selalu mempunyai kesalahan (sekecil apapun kesalahannya).

ii) Manusia tidak lepas dari membuat kesalahan. Manusia tidak akan pernah bisa lepas dari kesalahan, hal ini disebabkan oleh keterbatasan manusia dalam masalah kecepatan, ketelitian, kekonsistenan, daya tahan memproses, dan kemampuan mengingat.

iii) Increasingly, software pervasive and embedded; failure is potentially catastrophic Menurut pandangan saya, kegagalan pada software ada yang terjadi setelah program dikompilasi (kesalahan tidak terdeteksi pada saat pengujian). Hal ini mengakibatkan developer mengganggap bahwa software yang dibuat sudah aman dan tidak menyadari bahwa kesalahan yang tidak nampak itu pada suatu kondisi akan mengakibatkan bencana atau kecelakaan. Contohnya pada kasus BMW seri 3, fasilitas airbag tiba-tiba mengembang sendiri pada suatu kondisi tertentu.

b) Kebutuhan untuk memahami derajat resiko

i) Tingkat mutu, pengaturan toleransi target resiko

ii) Tingkat mutu, meminimalkan kejadian dari kegagalan secara (perangkat lunak) secara sistematis.

c) Kebutuhan metoda untuk memaksimalkan keselamatan

i) Kaidah manajemen, Proses dan standar-standar untuk perancangan.( Processes & standards for design, management) Proses dan standar-standar: Kegiatan jaminan kualitas (quality assurance) mendefinisikan kerangka kerja untuk mencapai kualitas perangkat lunak. Proses jaminan kualitas melibatkan definisi atau pemilihan standar yang harus diterapkan pada proses pengembangan perangkat lunak atau produk perangkat lunak. Standar ini dapat dicakup pada prosedur atau proses yang diterapkan pada saat pengembangan. Proses ini dapat didukung oleh alat bantu yang mencakup penegtahuan standar kualitas. Terdapat dua jenis standar yaitu:

• Standar produk. Merupakan standar yang berlaku bagi produk perangkat lunak yang dikembangkan. Standar ini mencakup standar dokumen sperti struktur dokumen persyaratan yang harus dibuat, standar dokumentasi seperti header komentar baku untuk kelas objek dan standar koding yang mendefinisikan bagaimana bahas pemrogrman harus digunakan.

• Standar proses. Merupakan standar yang mendefinisikan proses yang harus diikuti pada saat pengembangan perangkat lunak. Standar ini mencakup definisi spesifikasi, proses perancangan dan validasi, dan deskripsi dokumen yang harus dihasilkan pada proses berjalan. Diharapkan dengan memperhatikan kedua standar di atas, developer akan menghasilkan suatu produk perangkat lunak berkualitas tinggi bagi pelanggan/pengguna.

ii) Kaidah teknik, verifikasi dan validasi(Techniques, for verification & validation) Dalam proses verifikasi dan validasi terdapat dua teknik pemeriksaan dan analisis yang dapat digunakan yaitu:

• Inspeksi perangkat lunak, menganalisis dan memeriksa representasi sistem seperti dokumen persyaratan, diagram rancangan, dan kode sumber program.Inspeksi ini dapat diterapkan pada semua tahap proses. Inspeksi ini dapat dilengkapi dengan beberapa analisis otomatis teks sumber sistem atau dokumen terkait. Pemeriksaan perangkat lunak dan analisis terotomasi merupakan teknik verifikasi dan validasi statis karena tidak menuntut sistem dieksekusi. Pada tahap ini terdapat dua tipe pengujian yang dapat digunakan pada berbagai tahap proses perangkat lunak yaitu:

 Pengujian cacat yang ditujukan untuk menemukan ketakonsistenan antara program dan spesifikasinya.Ketakkonsistenan ini pada umumnya dikarenakan kesalahan atau cacat program.

 Pengujian statistik, dipakai untuk menguji kinerja dan keandalan program dan memeriksa bagaimana kerjanya pada kondisi operasional.

• Pengujian perangkat lunak, melibatkan eksekusi implementasi perangkat lunak dengan data uji dan memeriksa output perangkat lunak dan perilaku kerjanya untuk memeriksa apakah perangkat lunak berlaku seperti yang dibutuhkan. Pengujian perangkat lunak merupakan teknik verifikasi dan validasi dinamis karena bekerja dengan representasi sistem yang dapat dieksekusi. Dari uraian di atas dapat ditarik kesimpulan bahwa teknik verifikasi dan validasi mempunyai dua teknik pemeriksaan dan analisis yaitu teknik verifikasi dan validasi statis dan teknik verifikasi dan validasi dinamis.

Dibandingkan pengembangan perangkat lunak aplikasi biasa, pengembangan saftey-critical software memerlukan lebih banyak aktivitas dan melibatkan banyak peran serta disipilin ilmu/rekayasa. Berikut ini akan dijelaskan secara ringkas aktivitas untuk mengembangkan saftey-critical software, peran anggota tim dan masing-masing tugas utamanya, serta disiplin ilmu yang dilibatkan, yaitu :

a) Aktivitas pengembangan safety-critical software

i) Spesifikasi

(1) Dokumen kebutuhan fungsional Persyaratan akan dokumentasi terhadap layanan yang diberikan oleh sistem. Dengan adanya dokumentasi ini, user akan lebih mengetahui layanan yang diberikan sistem, bagaimana sistem harus bereaksi terhadap input tertentu dan bagaimana sistem berlaku pada kondisi tertentu.

(2) Kebutuhan keselamatan (Safety requirements) Keselamatan sistem merupakan atribut sistem yang merefleksikan kemampuan sistem untuk beroperasi, secara normal atau abnormal, tanpa membahayakan manusia atau lingkungan. Untuk menjamin tidak terjadi kecelakaan, terdapat cara-cara untuk menjamin keselamatan yaitu menghindari bahaya, deteksi dan membuang bahaya, dan membatasi kerusakan.

(3) Analisis bahaya dan resiko (Hazard and risk analysis) Analisis bahaya dan resiko mencakup analisis sistem dan lingkungan operasionalnya.Tujuan analisis ini adalah menemukan bahaya potensial yang mungkin muncul pada lingkungan itu, akar penyebab bahaya dan resiko yang berkaitan.

ii) Desain sistem dan implementasi

(1) Perancangan Arsitektural Perancangan arsitektural adalah proses perancangan awal untuk mengidentifikasi subsistem dan menetapkan kerangaka kerja untuk kontrol dan komunikasinya. Proses Perancangan arsitektural berhubungan dengan penetapan kerangka kerja struktur dasar untuk suatu sistem. Proses ini melibatkan identifikasi komponen-komponen utama sistem dan komunikasi antar komponen utama sistem dan komunikasi antar komponen-komponen tersebut. Menurut Bass et al (1998) terdapat 3 keuntungan perancangan dan dokumentasi arsitektur perangkat lunak yaitu :

• Komunikasi stakeholder. Arsitektur merupakan presentasi tingkat tinggi dari sistem yang dapat digunakan sebagai fokus pembahasan oleh berbagai stakeholder.

• Analisis sistem. Membuat arsitektur sistem yang eksplisit pada tahap dini pengembangan sistem mengandung arti bahwa analisis akan dilakukan. Keputusan perancangan arsitektural memiliki efek yang sangat besar mengenai apakah sistem dapat memenuhi persyaratan kritis seperti kinerja, keandalan, dan kemampuan daapt dipelihara.

• Pemakaian ulang berskala besar. Arsitektur sistem merupakan deskripsi yang kompak dan dapat ditangani mengenai bagaimana sistem diorganisir dan bagaimana komponen-komponen saling mengoperasikan. Arsitektur dapat ditransfer melintasi sistem dengan persyaratan yang sama dan dengan demikian dapat mendukung pemakaian ulang perangkat lunak berskala besar.

(2) Construction, integration, testing Construction : aktivitas yang mengkombinasikan pembangkitan kode dan pengujian yang diperlukan untuk menemukan kesalahan dalam kode program. Integration, testing : proses integrasi antara modul-modul program sehingga menjadi suatu sistem yang lengkap. Testing diperlukan untuk menemukan kesalahan-kesalahan yang ada.

iii) Validasi dan Verifikasi (V&V) Boehm(1979) Validasi: Apakah kita membangun produk yang benar? Verifikasi: Apakah kita membangun produk dengan benar? Dari definisi di atas, didapat bahwa

(1) Verifikasi merupakan proses yang melibatkan pemeriksaan bahwa program sudah sesuai dengan spesifikasi.

(2) Validasi merupakan proses yang melibatkan pemeriksaan bahwa program yang diimplementasikan sudah sesuai dengan harapan pelanggan.

iv) Sertifikasi Verifikasi dan teknik-teknik pengujian yang dilakukan menjadikan komponen perangkat lunak dapat disertifikasi. Dalam konteks pendekatan cleanroom software engineering (suatu metoda formal yang memungkinkan software engineer untuk men-spesifikasikan,develop dan memverifikasi sistem berbasiskan komputer) sertifikasi mengakibatkan reliabilitas(MTTF) dapat dispesifikasikan untuk tiap komponen. Pendekatan Sertifikasi mempunyai lima tahapan :

• Skenario penggunaan harus dibuat

• Pemakaian profil ditetapkan

• Tes kasus digenerate dari profil

• Tes dieksekusi dan kegagalan data direkam dan dianalisis

• Reliabilitas dapat dihitung dan disertifikasi

i) Program manager mempunyai peran untuk membuat perancanaan dan jadwal pembuatan perangkat lunak

ii) System Engineer mempunyai peran untuk memilih tools-tools dalam perencanaan maupun dalam penerapan perangkat lunak dan memiliki teknik yang baik untuk menilai kualitas dari perangkat lunak yang dihasilkan serta mampu mengendalikan, mengkoordinasikan, mengatur pelaksanaan pembuatan perangkat lunak.

iii) Safety engineer mempunyai peran untuk membuat, memperhatikan hal-hal berhubungan dengan faktor-faktor keselamatan yang terdapat pada program. iv) Software engineer mempunyai peran untuk selalu memperhatikan atau memfokuskan perhatiannya pada batasan anggaran dan jadwal pekerjaan.

c) Disiplin ilmu yang dilibatkan

i) Program manajement

ii) Software engineering

iii) Hardware and software design engineering

iv) System safety engineering

v) Other engineering support

3) Penjelasan untuk kebutuhan saftey critical software didefinisikan berdasarkan masukan adalah sbb:

a) Masukan pelanggan Pada tahap ini, kita mengumpulkan kebutuhan pelanggan terhadap perangkat lunaknya.

b) Kebutuhan sistem Kebutuhan sistem merupakan deskripsi yang lebih rinci dari kebutuhan user. Kebutuhan ini dapat berfungsi sebagai dasar kontrak untuk implementasi sistem dan dengan demikian harus merupakan spesifikasi yang lengkap dan konsistenm dari sistem secara keseluruhan. Kebutuhan tersebut digunakan oleh perekayas perangkat lunak sebagai titik awal perancangan sistem.

c) Hardware and environmental constraint Developer perangkat lunak harus mempunyai kemampuan tentang perangkat keras komputer. Dengan pengetahuan yang dimiliki, developer dapat menentukan jenis perangkat keras yang digunakan disesuaikan dengan kebutuhan sistem. Jangan spesifikasi perangkat lebih tinggi dari sistem (sehingga menjadi mubazir) atau terlalu rendah dari sistem (sehingga kerja sistem menjadi lambat).

d) Keselamatan perangkat lunak secara umum(Generic software safety) Menentukan kebutuhan keselamatan perangkat lunak secara umum.

e) Analisis bahaya (Hazzard analysis) dan Resiko (Risk analysis) Analisis bahaya dan resiko mencakup analisis sistem dan lingkungan operasionalnya.Tujuan analisis ini adalah menemukan bahaya potensial yang mungkin muncul pada lingkungan itu, akar penyebab bahaya dan resiko yang berkaitan. Proses iteratif dari analisis bahaya dan resiko adalah sbb: • Identifikasi bahaya. Bahaya potensial yang mungkin muncul diidentifikasi. Hal ini bergantung pada lingkungan di mana sistem akan digunakan.

• Analisis resiko dan klasifikasi bahaya. Bahaya dipertimbangkan secara terpisah. Yang serius secara potensial dan bukan tidak mungkin dipilih untuk analisis lebih lanjut.Pada tahap ini, beberapa bahaya dapat dieliminasi hanya karena bahaya-bahaya tersebut kemungkinan tidak akan muncul( misalnya sambaran petir).

• Penguraian bahaya. Setiap bahaya dianalisis secara individual untuk menemukan penyebab potensial dari bahaya tersebut.

• Penilaian reduksi resiko. Dibuat proposal untuk cara reduksi atau eliminasi risiko yang teridentifikasi. Usul ini dimasukkan ke kegiatan spesifikasi persyaratan keselamatan yang lebih rinci. Untuk sistem yang lebih besar, analisis bahaya dan resiko biasanya terstruktut menjadi sejumlah fase (Leveson,1986). Fase-fase ini mencakup:

• Analisis bahaya awal di mana resiko besar diidentifikasi

• Analisis bahaya sistem dan subsistem yang lebih terinci

• Analisis bahaya perangkat lunak di mana resiko kegagalan perangkat lunak dipertimbangkan

• Analisis bahaya operasional yang berhubungan dengan interface user sistem.

f) Standar-standar

• IEEE/ANSI 830-1984

• IEEE/ANSI 830-1993

• IEEE/EIA 12207.0

About these ads

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: