Dua kali kecelakaan pesawat yang melibatkan Boeing 737 MAX mengejutkan dunia. Itu adalah pukulan telak bagi perusahaan sekaliber Boeing. Namun sementara para penyidik membutuhkan waktu berbulan-bulan untuk menemukan penyebabnya, pakar perangkat lunak Jacob Beningo menawarkan pelajaran penting, agar bisnis kita terhindar dari nasib yang sama dengan Boeing.
Pada 17 September 1908, Orville Wright dan Letnan Thomas Selfridge berangkat dengan sebuah Wright Flyer dari Fort Meyer di Virginia. Tidak lama setelah take-off, Wright Flyer tiba-tiba kehilangan daya angkat, terhempas ke tanah, melukai Wright dan membunuh Selfridge.
Kecelakaan terjadi ketika salah satu baling-baling kayu terbelah dan menarik kawat bracing yang menyebabkan kemudi belakang bergerak dari posisi vertikal ke posisi horizontal. Ini adalah kecelakaan pesawat pertama yang mengakibatkan kematian.
Mari kita majukan waktu 110 tahun ke depan: Pesawat bukan lagi pesawat mekanik sederhana yang diterbangkan oleh Wright bersaudara dan pelopor penerbangan awal, tetapi telah berkembang menjadi sangat canggih. Pesawat saat ini adalah sistem elektronik yang digerakkan oleh jutaan lini perangkat lunak.
Kemajuan selama seabad terakhir telah menjadikan perjalanan udara sebagai moda transportasi yang paling aman.
Namun belum lama ini, laman-laman berita telah didominasi oleh dua tabrakan yang melibatkan pesawat baru 737 MAX milik Boeing dalam kondisi serupa, dalam waktu enam bulan satu sama lain. Dampak dari bencana-bencana ini dimulai dengan pelarangan terbang pesawat sejenis di seluruh dunia, menurunnya produksi 737 MAX, dan penjualan pesawat jenis tersebut pada bulan Maret turun hingga nol unit.
Rusaknya reputasi Boeing sebagai juaranya keselamatan penerbangan kini juga dipertanyakan, ketika penyelidikan dibuka tentang bagaimana sistem di pusat investigasi, MCAS, dikembangkan dan disertifikasi.
Investigasi yang dilakukan atas urutan peristiwa terkait hilangnya pesawat ini dan penyebabnya akan memakan waktu cukup lama untuk sepenuhnya terungkap dan direalisasikan oleh penyelidik kecelakaan. Namun, dengan informasi yang saat ini telah dirilis, perusahaan dan pengembang sistemnya dapat melihat kegagalan yang sedang dialami Boeing.
Mereka saat ini belajar serta diingatkan tentang beberapa prinsip umum yang dapat mereka terapkan pada industri dan produk mereka sendiri. Mari kita telaah, apa saja pelajaran dari dua kali kecelakaan pesawat Boeing ini.
Pelajaran 1: Jangan Kompromikan Produk Anda untuk Keuntungan Sesaat
Ada tekanan normatif pada bisnis dan pengembang saat ini untuk meningkatkan pendapatan, mengurangi biaya dan mengirimkan produk secepat mungkin. Prinsipnya berkualitas. Prinsipnya bukan keamanan. Prinsipnya bukan produk yang ramah pengguna. Prinsipnya adalah pertumbuhan jangka pendek semaksimal mungkin, dengan melakukan apa saja.
Namun saya tidak percaya ini adalah prinsip Boeing, atau bahkan niat mereka. Namun mengingat tekanan dari pelanggan dan pemegang saham untuk mengirimkan sebuah pesawat yang dapat bersaing dengan Airbus A319neo, saya percaya bahwa mereka mungkin sudah mulai menyerah pada tekanan normatif ini.
Hal ini membawa kita ke pelajaran pertama: Jangan ambil risiko membahayakan produk Anda untuk menghemat atau menghasilkan lebih banyak uang. Sangat penting untuk menjadi sukses dalam jangka pendek, tetapi bisnis lebih dari sekedar berapa banyak penjualan dan pendapatan yang dihasilkan kuartal ini dan kuartal berikutnya.
Bahkan ketika ada kompetisi untuk merilis produk yang kompetitif dan klien menekan, penting untuk mengingat narasi jangka panjang dan tidak mengorbankan kualitas, reputasi atau membahayakan bisnis klien.
Pelajaran 2: Identifikasi dan kurangi potensi kegagalan
Dalam sistem tertanam apapun yang sedang dikembangkan, penting untuk memahami mode kegagalan potensial dan apa dampak kegagalan itu terhadap sistem dan bagaimana potensi kegagalan tersebut dapat dikurangi.
Ada banyak cara yang dilakukan tim tentang melakukan ini, termasuk melakukan Design Failure Mode and Effects Analysis (DFMEA) – yang menganalisis fungsi desain, mode kegagalan, dan pengaruhnya terhadap pelanggan atau pengguna. Setelah analisis semacam itu dilakukan, kita dapat menentukan bagaimana kita dapat mengurangi dampak kegagalan.
Dalam sistem yang dapat mempengaruhi keamanan pengguna, merupakan praktik umum untuk menghindari titik kegagalan tunggal seperti sensor yang salah atau input tunggal. Jelas jika satu input tiba-tiba memberikan data sampah, hanya Tuhan yang tahu bagaimana sistem itu akan merespons dan ketika Anda memasukkan hukum Murphy, hasilnya tidak akan positif.
Saya benar-benar terkejut ketika saya membaca bahwa sistem MCAS mengandalkan sensor tunggal untuk pengambilan keputusan. Setelah bekerja pada sistem yang kokoh dan kritis di masa lalu, sangat membingungkan bagi saya bahwa penggunaan input sensor tunggal akan dianggap dapat diterima dan menambahkan input dari sensor kedua yang kemudian akan menonaktifkan sistem jika sensor gagal sepertinya tidak membuat segalanya lebih baik. (tapi hal itu benar-benar tergantung pada filosofi teknik dan budaya).
Pelajaran 3: Jangan Anggap User dapat Mengatasinya
Pelajaran menarik yang dapat diambil banyak insinyur dari kegagalan produk mereka adalah: Kita tidak bisa berasumsi atau mengandalkan pengguna produk kita untuk mengoperasikan perangkat yang kita ciptakan dengan benar, terutama jika perangkat itu dimaksudkan untuk beroperasi secara mandiri.
Itu bukanlah penghinaan, tetapi hanya menegaskan bahwa sistem yang kompleks memerlukan lebih banyak waktu untuk menganalisis dan memecahkan masalah. Tampaknya Boeing berasumsi bahwa jika ada masalah, pengguna memiliki cukup pelatihan dan pengalaman, dan tahu prosedur yang ada cukup baik untuk memberikan kompensasi.
Benar atau salah, sebagai desainer, kita mungkin perlu menggunakan “ekspektasi yang sedikit dikurangi” dan melakukan segala yang kami bisa untuk melindungi pengguna dari dirinya sendiri.
Pelajaran 4: Sistem yang teruji dan bersertifikat pun memiliki cacat
Edsger Dijkstra menulis bahwa “Pengujian program dapat digunakan untuk menunjukkan keberadaan bug, tetapi tidak pernah menunjukkan bahwa mereka (masalah/bug tersebut) tak ada.”
Kita tidak dapat menunjukkan bahwa suatu sistem tidak memiliki bug (masalah) yang berarti kita harus berasumsi bahwa bahkan pengujian yang sangat cermat dan sistem bersertifikat memiliki cacat. Ini harus mengubah cara setiap pengembang berpikir tentang bagaimana mereka merancang perangkat lunak.
Alih-alih mencoba mengekspos cacat secara case by case, kita harus mengembangkan sistem yang mampu mendeteksi dirinya sendiri ketika kinerjanya sedang tidak baik, atau bahwa ada sesuatu yang tidak normal dengan inputnya. Dengan melakukan ini, kita dapat menguji sebanyak mungkin cacat dari sistem kita.
Tetapi ketika ada masalah yang baru muncul di lapangan, mekanisme cacat generik diharapkan dapat mendeteksi bahwa ada sesuatu yang salah, dan mengambil tindakan korektif.
Pelajaran 5: Sensor dan sistem selalu berpotensi gagal
Fakta bahwa sensor dan sistem gagal seharusnya tampak seperti pernyataan yang jelas, tetapi saya melihat beberapa pengembang yang membuat perangkat lunak seolah-olah mikrokontroler mereka tidak akan pernah macet, menghadapi satu peristiwa yang mengecewakan atau rusak memorinya.
Sensor akan mandek, prosesor akan macet, sampah masuk akan menghasilkan sampah keluar. Sebagai pengembang, kita perlu berasumsi bahwa ada yang salah dan menulis kode untuk menangani kasus-kasus itu, karena kita tidak akan selalu memiliki sistem yang bekerja dengan baik di lapangan seperti halnya di laboratorium.
Jika Anda mendesain sistem Anda dengan mempertimbangkan fakta bahwa sistem itu akan gagal, Anda akan berakhir dengan sistem kuat yang harus melakukan banyak kerja keras sebelum akhirnya gagal juga.
Kesimpulan
Akan memakan waktu berbulan-bulan sebelum kita mendapatkan laporan lengkap tentang apa yang terjadi dan menyebabkan kecelakaan 737 MAX dan hasil dari audiensi kongres mengenai bagaimana pesawat disertifikasi dan dikembangkan, kita tidak perlu menunggu hasil-hasil itu untuk mengambil pelajaran dari mereka.
Kita telah memeriksa beberapa pengingat penting yang perlu dipertimbangkan oleh semua bisnis dan pengembang untuk menghindari nasib yang sama dengan Boeing.
Pertanyaan yang sekarang harus Anda tanyakan adalah kompromi apa yang Anda lakukan saat ini, dan tindakan apa yang akan Anda ambil hari ini untuk memastikan hal tersebut tidak membuat Anda gagal besok.
Jacob Beningo adalah konsultan perangkat lunak tertanam yang saat ini bekerja dengan klien di lebih dari selusin negara. Dia telah menerbitkan lebih dari 200 artikel tentang teknik pengembangan perangkat lunak tertanam.
