Inovasi dengan Sistem Life-critical

Setiap perusahaan memiliki infrastruktur "kritis". Secara umum, ini berarti bahwa jika sistem offline, sebagian (atau semua) bisnis akan terhenti hingga teknisi dapat menjalankannya kembali. Ini sering terjadi ketika perangkat lunak, perangkat keras, atau peningkatan jaringan yang besar diperlukan: sistem yang baru digunakan mengandung bug tak terduga yang menyebabkan kegagalan sistem, atau pengguna membuat kesalahan dengan sistem baru karena mereka tidak terbiasa dengannya, dan produktivitas berhenti hingga teknisi dapat bekerja melalui bug penyebaran atau melatih pengguna. Untuk sebagian besar, periode waktu henti atau penurunan produktivitas adalah risiko yang dapat diterima sebagai imbalan atas janji peningkatan kinerja dan efisiensi teknologi baru, tetapi itu tidak universal. Sebagian besar bisnis dapat membayar sejumlah waktu henti tanpa mempertaruhkan banyak pendapatan atau memusuhi klien mereka.

Tetapi apa yang terjadi ketika sistem yang perlu Anda modifikasi adalah sistem yang sangat penting bagi kehidupan, di mana keselamatan jiwa bergantung pada kemampuan untuk menggunakan sistem dengan andal?

Artikel ini melangkah menjauh dari pengembangan perangkat lunak yang lebih tradisional di mana kita menghabiskan sebagian besar waktu kita dan, sebagai gantinya, melihat elemen manusia dalam sistem yang sangat penting bagi kehidupan. Pemikiran saya tentang topik ini berasal dari pengalaman saya sebagai Direktur Teknologi Informasi untuk layanan ambulans 911, sebagai spesialis teknologi untuk organisasi tanggap bencana kemanusiaan internasional, dan dengan gelar Ph.D. dalam Integrasi Sistem Manusia diselesaikan di Massachusetts Institute of Technology.

Sebelum kita mulai, saya ingin menjelaskan mengapa ini mungkin relevan bagi Anda. Meskipun mungkin tidak jelas bahwa proyek Anda benar-benar melibatkan sistem yang sangat penting bagi kehidupan, kemungkinannya jauh lebih besar daripada yang Anda kira. Semua hal berikut memenuhi syarat, serta topik lainnya yang tak terhitung jumlahnya:

• Otomotif. Bekerja pada sebuah proyek dengan produsen kendaraan, atau pemasok mereka? Direkrut keluar dari universitas oleh startup mobil self-driving? Pengereman otomatis, kontrol jelajah, kontrol jalur, visi komputer, pengenalan hambatan, modul kontrol mesin elektronik, dll. Semua ini adalah sistem yang sangat penting, di mana kegagalan bisa berakibat fatal.
• Penerbangan. Saat Anda berada 30.000 'di udara, hampir semua kegagalan sistem dapat menjadi kritis bagi kehidupan. Mengingat kejadian baru-baru ini dengan Boeing 737 MAX, ada sistem autopilot dan kontrol penerbangan terkomputerisasi yang sangat penting, tetapi ada juga banyak hal yang mungkin tidak Anda pikirkan. Di rumah, jika kipas di sistem HVAC Anda gagal dan menghasilkan sedikit asap, Anda membuka jendela atau keluar untuk mencari udara segar. Pernahkah Anda mencoba membuka jendela dan melangkah keluar selama penerbangan trans-Atlantik? Bahkan sistem yang paling dasar, mulai dari stopkontak di dapur hingga rem di roda gerobak minuman, bisa sangat penting bagi kehidupan di pesawat.
• Komunikasi. Sebagian besar pengembang atau insinyur akan, pada titik tertentu dalam karier mereka, mengerjakan proyek sistem komunikasi dalam satu kapasitas atau lainnya. Bagi banyak orang, telekomunikasi pada awalnya tidak tampak penting bagi kehidupan; lagi pula, peradaban bernasib baik sebelum telepon dan internet. Sebagai seseorang yang telah ditempatkan di zona bencana di mana infrastruktur telekomunikasi telah hancur, izinkan saya memberi tahu Anda apa yang sebenarnya terjadi: orang-orang menjadi sangat sakit atau terluka dan tidak dapat menelepon 911; penduduk lanjut usia tidak dapat menelepon anak-anak mereka untuk meminta mereka mengambil resep mereka dari apotek; responden darurat tidak dapat berkomunikasi dengan petugas operator mereka atau satu sama lain; dan orang-orang yang tidak dapat menghubungi anggota keluarga mereka menjadi khawatir dan menempatkan diri mereka dalam situasi yang sangat berbahaya untuk mencoba menemukan mereka. Sistem komunikasi sangat penting bagi kehidupan.

Di dunia yang sangat bergantung pada teknologi saat ini, proyek yang tidak pernah Anda anggap semi-penting dapat berakhir menjadi komponen vital dari sistem yang sangat penting bagi kehidupan.

Tapi Jika Tidak Rusak, Jangan Perbaiki

Pernahkah Anda mendengar atau menggunakan kata “warisan” dalam kaitannya dengan sistem teknologi? Ini adalah kata yang kuat, membangkitkan pemikiran tentang tradisi lama, garis keturunan, dan masa-masa sulit di masa lalu. Di dunia teknik, ini digunakan untuk menunjukkan desain yang telah ada sejak lama dan telah terbukti bekerja dengan andal dan sering dilihat sebagai sifat yang diinginkan untuk mengurangi risiko. Pada kenyataannya, ini adalah eufemisme untuk teknologi kuno yang tidak pernah diperbarui karena penghindaran risiko, dan itu meresap dalam industri di mana kegagalan sistem dapat menyebabkan konsekuensi yang mengerikan.

Ada alasan bagus di balik ketertarikan ini terhadap perangkat lunak dan perangkat keras warisan. Ini diketahui berfungsi, tidak mungkin bug yang tidak diketahui akan muncul, dan biayanya stabil dan dapat diprediksi. Contoh yang sangat baik adalah industri penerbangan luar angkasa: pesawat ruang angkasa Soyuz Rusia telah meluncurkan astronot ke luar angkasa selama lebih dari 50 tahun dengan hanya sedikit revisi selama waktu itu, dan terus digunakan karena dapat diandalkan dan aman. Sayangnya, ini berarti juga sangat tidak efisien dibandingkan dengan desain modern: sementara Soyuz menghabiskan biaya NASA $81 juta USD per kursi untuk menerbangkan astronot ke stasiun luar angkasa menggunakan perangkat keras warisannya, SpaceX dan Boeing diharapkan menawarkan kursi masing-masing seharga $58 juta USD. menggunakan desain roket modern mereka.

Dapat dimengerti bahwa hanya sedikit orang yang ingin memutakhirkan sistem lama yang masih berfungsi; eksekutif tidak ingin risiko, teknisi tidak ingin berurusan dengan server misterius di lemari dengan uptime 12 tahun, dan klien tidak ingin harus mempelajari desain baru. Sayangnya, ada titik kritis antara minimalisasi risiko dan penghematan biaya: desain warisan pada akhirnya perlu ditingkatkan, bahkan di lingkungan berisiko tinggi .

Sisa artikel ini mencakup beberapa langkah yang lebih penting dalam proses melakukannya ketika sistem Anda sangat penting, seperti yang digunakan oleh responden pertama, unit militer, atau pesawat terbang.

Meyakinkan Kuningan

Dalam pengalaman saya, mungkin langkah tersulit dari proses ini adalah meyakinkan pembuat keputusan dan pemangku kepentingan bahwa peningkatan diperlukan. Sistem yang beroperasi di lingkungan kritis kehidupan sering diatur oleh peraturan hukum dan kebijakan organisasi yang ekstensif, yang berarti bahwa Anda harus meyakinkan mereka bahwa mereka tidak hanya harus mengambil risiko dan membelanjakan uang, tetapi mereka juga harus terlibat dalam apa yang dapat dengan mudah dilakukan. bertahun-tahun pemotongan pita birokrasi. Oposisi terkuat yang akan Anda hadapi kemungkinan besar berasal dari tim hukum, yang akan menjelaskan secara rinci potensi tanggung jawab yang akan Anda hadapi dengan memperkenalkan teknologi baru. Mereka benar: tanggung jawab adalah masalah besar , dan jika sesuatu rusak dan seseorang terluka atau meninggal, itu bisa menjadi beban etika, reputasi, dan keuangan yang besar.

Terlepas dari apakah Anda bekerja dengan perusahaan Fortune 500 atau dengan pemadam kebakaran sukarelawan lokal Anda, selalu bermuara pada hal yang sama: uang. Perusahaan tidak ingin kehilangannya, dan organisasi nirlaba tidak memiliki banyak hal untuk dikerjakan. Satu-satunya cara yang dapat diandalkan yang saya temukan untuk meyakinkan kepemimpinan organisasi untuk mengambil risiko mengubah sistem kehidupan yang kritis adalah dengan menunjukkan bahwa, secara probabilistik, mereka lebih mungkin menghasilkan/menghemat uang daripada kehilangannya, atau bahwa mereka dapat mengurangi tanggung jawab mereka dengan memodernisasi teknologi mereka dan meningkatkan keselamatan.

Artinya, Anda perlu melakukan perhitungan. Seberapa besar kemungkinan bahwa akan ada waktu henti yang diperpanjang atau gangguan di masa mendatang karena bug (berdasarkan penerapan sebelumnya di organisasi Anda, atau data dari organisasi lain)? Apa dampak yang diharapkan jika gagal, dan berapa biayanya? Sebaliknya, apa keuntungan kinerja atau keandalan yang diharapkan, dan berapa nilainya? Jika Anda dapat menunjukkan bahwa ada kemungkinan besar Anda akan unggul, ada kemungkinan besar Anda akan mendapatkan lampu hijau.

Ini Bukan Tentangmu

Anda mungkin akrab dengan ungkapan "oleh insinyur, untuk insinyur," sebuah ungkapan yang menunjukkan bahwa insinyur membangun sesuatu untuk digunakan oleh orang-orang dengan kualifikasi yang mirip dengan mereka. Ini adalah kejadian yang sangat umum dan merupakan salah satu faktor pencetus utama munculnya studi kegunaan komputer di awal 1990-an. Sebagai insinyur, kita sering memiliki model mental yang berbeda tentang cara kerja sistem teknologi daripada rata-rata pengguna akhir, yang mengarah pada kecenderungan untuk merancang sistem dengan asumsi bahwa pengguna akhir sudah mengetahui cara kerjanya. Dalam sistem konvensional, ini mengarah pada kesalahan dan klien yang tidak bahagia; dalam sistem kehidupan-kritis, itu dapat menyebabkan kematian.

Pertimbangkan kasus Air France Penerbangan 447. Pada 1 Juni 2009, Airbus A330 berada di atas Samudra Atlantik dalam perjalanan dari Rio de Janeiro ke Paris. Kristal es menghalangi tabung pitot, menyebabkan inkonsistensi dalam pengukuran kecepatan udara. Komputer penerbangan melepaskan autopilot, menyadari bahwa ia tidak dapat menerbangkan pesawat itu sendiri dengan data kecepatan udara yang salah. Itu kemudian menempatkan dirinya ke dalam mode "perpanjangan amplop penerbangan" , yang memungkinkan pilot melakukan manuver yang biasanya tidak diizinkan oleh komputer. Anda dapat membayangkan para insinyur yang membangun sistem berpikir “jika autopilot melepaskan diri, itu mungkin karena ada situasi di mana pilot mungkin memerlukan kontrol ekstra! ”

Ini adalah pemikiran alami bagi para insinyur, yang memahami hal-hal seperti apa yang dapat menyebabkan autopilot tidak aktif. Untuk pilot, itu tidak terjadi. Mereka memaksa pesawat untuk mendaki ke atas yang curam, mengabaikan peringatan "STALL", sampai kehilangan semua kecepatan udara dan jatuh ke laut. Semua 228 penumpang dan awak tewas. Meskipun ada banyak ide tentang motivasi yang tepat untuk tindakan mereka, teori yang berlaku adalah bahwa pilot mengasumsikan komputer penerbangan akan mencegah input kontrol yang akan menghentikan pesawat (yang berlaku untuk amplop penerbangan normal), dan tidak menyadari bahwa itu telah beralih ke mode amplop diperpanjang karena mereka tidak berbagi model mental para insinyur dari logika yang mendorong keputusan komputer.

Meskipun sedikit berbelit-belit, ini membawa kita ke poin utama saya: tindakan yang Anda ingin pengguna lakukan dalam kondisi tertentu harus merupakan tindakan yang terasa alami bagi pengguna .

Pengguna dapat diinstruksikan untuk mengikuti prosedur tertentu, tetapi mereka tidak selalu mengingat hal yang benar untuk dilakukan atau memahami apa yang terjadi dalam kondisi stres tinggi. Anda bertanggung jawab untuk merancang perangkat lunak, kontrol, dan antarmuka dengan cara yang intuitif yang membuat pengguna secara inheren ingin melakukan hal-hal yang seharusnya mereka lakukan.

Artinya, sangat penting bagi pengguna akhir untuk terlibat dalam setiap tahap proses desain dan pengembangan. Tidak ada asumsi yang dibuat tentang apa yang mungkin akan dilakukan pengguna; itu semua harus berbasis bukti. Saat Anda mendesain antarmuka, Anda harus melakukan studi untuk menentukan pola pikir yang ditimbulkannya pada pengguna dan menyesuaikan seperlunya. Saat Anda menguji sistem baru Anda, Anda harus mengujinya dengan pengguna nyata di lingkungan nyata dalam kondisi realistis. Dan sayangnya, ketika Anda mengubah desain Anda, Anda harus melakukan langkah-langkah ini lagi.

Meskipun setiap sistem yang kompleks itu unik, saya ingin menyebutkan tiga pertimbangan desain, khususnya, yang harus diterapkan secara universal:

• Kontrol harus mewakili tindakan yang mereka lakukan. Untungnya, yang satu ini cukup umum, umumnya terlihat dalam bentuk pemilihan ikon yang relevan untuk tombol GUI atau bentuk yang relevan untuk kontrol fisik. Tombol "File Baru" menggunakan selembar ikon kertas kosong, dan tuas roda pendarat di pesawat memiliki kenop berbentuk roda. Namun, mudah untuk menjadi puas diri. Mengapa kita masih melihat ikon floppy disk 3,5” untuk tombol “Simpan”? Adakah yang lebih muda dari 25 yang tahu apa itu floppy disk? Kami terus menggunakannya karena kami pikir itu representatif, tetapi sebenarnya tidak lagi. Ini membutuhkan upaya terus-menerus untuk memastikan bahwa representasi kontrol bermakna bagi pengguna, tetapi juga perlu dan sulit untuk menyeimbangkannya dengan kontinuitas.
• Jika sistem peringatan rusak, itu harus dapat dideteksi. Kita sering menggunakan lampu peringatan yang aktif ketika ada masalah, seperti indikator merah berkedip. Ini bagus untuk mendapatkan perhatian pengguna, tetapi apa yang terjadi jika lampu padam? Pesawat ruang angkasa yang digunakan dalam misi bulan Apollo memiliki lusinan lampu peringatan untuk semua jenis sistem, tetapi tidak berfungsi secara konvensional. Alih-alih menerangi ketika ada masalah, mereka tetap menyala ketika semuanya baik-baik saja dan dimatikan ketika ada masalah. Ini memastikan bahwa lampu peringatan yang terbakar tidak akan menyebabkan para astronot melewatkan kesalahan sistem yang berpotensi fatal. Saya tidak mengatakan bahwa Anda harus menggunakan desain ini, karena bola lampu telah berkembang jauh dalam keandalan sejak tahun 1960-an, tetapi ini memberikan gambaran tentang seberapa mendalam beberapa perencanaan Anda. Berapa kali sistem mogok tetapi Anda tidak mengetahuinya, karena pencatatan atau pemberitahuan tidak berfungsi dengan baik?
• Transisi mode harus jelas bagi pengguna. Apa yang terjadi jika Airbus A330 bertransisi dari mode kontrol normal ke mode kontrol lanjutan tanpa sepengetahuan pengguna, dan tiba-tiba pesawat melakukan hal-hal yang menurut pengguna tidak dapat dilakukan? Apa yang terjadi jika mobil self-driving melepaskan autopilotnya, membuat pengguna secara tak terduga memegang kendali penuh? Apa yang terjadi ketika ada transisi besar dalam mode atau fungsionalitas yang memerlukan perubahan segera dalam tindakan pengguna, tetapi pengguna memerlukan satu atau dua menit untuk mengetahui apa yang baru saja terjadi? Sementara berbagai mode operasi mungkin diperlukan dalam sistem yang kompleks, mode tidak dapat bertransisi tanpa pemberitahuan, penjelasan, dan interaksi yang memadai dengan pengguna dalam melakukannya.

Meluncurkan Sistem Life-Critical Keluar dari Toko

Sejalan dengan praktik terbaik industri, fase beta sangat penting untuk penerapan sistem baru yang sangat penting bagi kehidupan. Pengujian teknologi baru Anda mungkin telah membantu Anda memperbaiki sebagian besar bug dan masalah kegunaan, tetapi bahaya tersembunyi mungkin muncul ketika harus digunakan bersama dengan sistem lain di lingkungan dunia nyata. Dalam disiplin rekayasa sistem, ini dikenal sebagai "kemunculan." Properti yang muncul adalah "perilaku tak terduga yang berasal dari interaksi antara komponen aplikasi dan lingkungannya", dan pada dasarnya tidak mungkin dideteksi dalam pengaturan lab. Dengan mengundang sekelompok perwakilan pengguna akhir untuk menguji coba sistem baru Anda di bawah pengawasan yang cermat, banyak dari properti ini dapat dideteksi dan dievaluasi untuk konsekuensi negatif yang mungkin muncul dalam penerapan skala penuh.

Topik lain yang sering muncul dalam diskusi arsitektur dengan klien saya adalah peluncuran bertahap. Ini adalah pilihan antara secara bertahap mengganti elemen dari sistem yang sudah ada sebelumnya dengan elemen yang baru sampai akhirnya semuanya diganti vs. mengubah semuanya sekaligus. Ada pro dan kontra untuk masing-masing: peluncuran bertahap memungkinkan pengguna secara bertahap menyesuaikan diri dengan desain baru, memastikan bahwa perubahan datang dalam jumlah yang dapat diatur dan pengguna tidak kewalahan; di sisi lain, itu dapat menyeret proses keluar selama periode yang lama dan menghasilkan keadaan transisi yang konstan. Peluncuran segera bermanfaat karena mereka "merobek bantuan pita" dan mempercepat, tetapi perubahan drastis yang tiba-tiba dapat membuat pengguna kewalahan.

Untuk sistem yang sangat penting bagi kehidupan, saya menemukan bahwa peluncuran bertahap umumnya lebih aman, karena memungkinkan evaluasi bertahap komponen individu dalam lingkungan produksi dan memungkinkan pengembalian yang lebih kecil jika ada sesuatu yang perlu dibatalkan. Ini adalah sesuatu yang perlu dievaluasi berdasarkan kasus per kasus.

Normalisasi Penyimpangan

Oke, jadi pengujian pengguna Anda membantu Anda mendesain sistem yang intuitif, fase beta Anda mengidentifikasi masalah yang muncul, peluncuran bertahap Anda memungkinkan pengguna merasa nyaman dengan desainnya, dan semuanya berjalan lancar. Anda sudah selesai, kan? Sayangnya tidak.

Masalah dengan sistem Anda pasti akan muncul, tidak ada jalan keluarnya. Ketika pengguna menemukan masalah ini, mereka akan sering mengembangkan solusi alih-alih melaporkan masalah tersebut ke tim teknologi. Solusinya akan menjadi praktik standar, dibagikan sebagai "tips" dari veteran hingga pemula. Sosiolog Diane Vaughan menciptakan ungkapan untuk menggambarkan fenomena ini: "normalisasi penyimpangan." Pengguna menjadi begitu terbiasa dengan perilaku menyimpang sehingga mereka gagal mengingat bahwa itu sebenarnya menyimpang.

Contoh klasiknya adalah Space Shuttle Challenger: sebuah komponen dalam pendorong roket padat secara teratur diamati terkikis selama peluncuran, dan meskipun semua orang tahu bahwa mengikis komponen roket adalah hal yang buruk, hal itu sering terjadi sehingga keringanan dikeluarkan secara teratur dan dianggap normal. Pada tanggal 28 Januari 1986, masalah yang awalnya diketahui semua orang tidak boleh dibiarkan, tetapi telah dinormalisasi, mengakibatkan ledakan Challenger dan kematian tujuh astronot.

Sebagai administrator sistem yang sangat penting bagi kehidupan, terserah Anda untuk mencegah kejadian seperti itu terjadi. Pelajari bagaimana pengguna Anda berinteraksi dengan sistem. Bayangan mereka selama beberapa hari dan lihat apakah mereka menggunakan solusi yang tidak terduga. Kirimkan survei secara berkala untuk meminta saran perubahan dan peningkatan. Dedikasikan waktu dan upaya untuk meningkatkan sistem Anda sebelum pengguna Anda menemukan cara untuk mengatasi masalah tanpa Anda.

Pelatihan untuk Performa Di Bawah Tekanan

Sering terjadi kegagalan dalam sistem kritis kehidupan terjadi ketika pengguna menderita stres, lonjakan adrenalin, dan visi terowongan. Itu terjadi pada pilot di Air France 447, terjadi pada paramedis yang tidak dapat mengingat cara mengoperasikan monitor jantung mereka pada pasien serangan jantung pertama mereka, dan terjadi pada tentara yang tidak dapat mengoperasikan radio mereka dengan benar saat berada di bawah tembakan.

Beberapa dari risiko ini diperbaiki dengan menggunakan desain intuitif seperti yang dibahas sebelumnya, tetapi itu saja tidak cukup. Khususnya di lingkungan di mana skenario stres tinggi memang terjadi tetapi jarang terjadi, penting untuk melatih pengguna Anda tidak hanya cara mengoperasikan sistem Anda, tetapi juga cara berpikir jernih dalam kondisi seperti itu. Jika pengguna mengingat tindakan yang berkaitan dengan pengoperasian peralatan, mereka tidak dapat menangani kegagalan tak terduga karena tindakan yang mereka pelajari mungkin tidak lagi sesuai; jika mereka berlatih untuk berpikir logis dan jernih di bawah tekanan, mereka dapat merespons keadaan yang berubah dan membantu sistem Anda tetap hidup ketika ada sesuatu yang rusak.

Kesimpulan

Jelas, mengembangkan, menyebarkan, dan memelihara perangkat lunak yang sangat penting bagi kehidupan adalah jauh lebih kompleks daripada yang dapat dirinci dalam satu artikel. Namun, area pertimbangan ini dapat membantu memberi Anda gambaran yang lebih baik tentang apa yang diharapkan ketika Anda berpikir untuk mengerjakan proyek semacam itu. Singkatnya:

• Inovasi diperlukan, bahkan ketika semuanya berjalan lancar
• Sulit untuk meyakinkan eksekutif bahwa risikonya berharga, tetapi angka tidak berbohong
• Pengguna akhir harus terlibat dalam setiap langkah proses
• Uji dan uji ulang dengan pengguna nyata di lingkungan nyata dalam kondisi realistis
• Jangan berasumsi bahwa Anda melakukannya dengan benar pada kali pertama; meskipun berfungsi, mungkin ada masalah yang tidak terdeteksi yang tidak diberitahukan oleh pengguna Anda.
• Latih pengguna Anda bukan hanya tentang cara menggunakan sistem, tetapi juga cara berpikir jernih dan beradaptasi di bawah tekanan.

Sebagai penutup, saya ingin mencatat bahwa dalam sistem kritis keselamatan yang kompleks, hal-hal akan salah di beberapa titik tidak peduli berapa banyak perencanaan, pengujian, dan pemeliharaan yang Anda lakukan. Ketika sistem tersebut sangat penting bagi kehidupan, sangat mungkin bahwa kegagalan dapat menyebabkan hilangnya nyawa atau anggota tubuh.

Jika tragedi seperti itu benar-benar terjadi dengan sesuatu yang menjadi tanggung jawab Anda, itu akan menjadi beban berat pada hati nurani Anda dan Anda mungkin akan berpikir bahwa Anda dapat mencegahnya jika Anda lebih memperhatikan atau bekerja lebih keras. Mungkin itu benar, mungkin juga tidak, tetapi tidak mungkin untuk meramalkan setiap kemungkinan yang terjadi.

Bekerjalah dengan cermat, jangan sombong, dan Anda akan membuat dunia menjadi tempat yang lebih baik.