Skip to main content

Critical Systems (Sistem Penting) Menurut Ian Sommerville

Gagalnya perangkat lunak merupakan hal yang sering terjadi. Biasanya, kegagalan ini hanya menyebabkan ketidaknyamanan tanpa adanya kerusakan yang berkelanjutan. Namun, dalam beberapa situasi, kegagalan sistem dapat mengakibatkan dampak ekonomi yang besar, kerusakan fisik, atau bahkan ancaman terhadap nyawa manusia. Sistem yang memiliki risiko seperti ini disebut sebagai sistem kritis. Sistem kritis ini merupakan sistem yang menjadi pilar penting bagi individu atau bisnis. Jika sistem ini tidak mampu memberikan layanan sesuai harapan, maka dapat timbul masalah serius dan kerugian yang signifikan.

Terdapat tiga klasifikasi utama dari sistem yang termasuk dalam kategori kritis:

  1. Safety-critical systems Sebuah sistem yang apabila mengalami kegagalan dapat menyebabkan cedera, kehilangan nyawa, atau kerusakan lingkungan yang parah. Sebagai contoh, sistem kontrol untuk pabrik pembuatan bahan kimia termasuk dalam kategori sistem yang sangat penting untuk keselamatan (safety-critical).
  2. Mission-critical systems Sebuah sistem yang jika mengalami kegagalan dapat menyebabkan kegagalan beberapa kegiatan yang bertujuan. Sebagai contohnya, sistem navigasi untuk pesawat ruang angkasa termasuk dalam kategori sistem yang sangat penting untuk mencapai misi (mission-critical).
  3. Business-critical systems Sebuah sistem yang jika mengalami kegagalan dapat menimbulkan biaya yang sangat tinggi bagi bisnis yang mengandalkan sistem tersebut. Sebagai contohnya, sistem akuntansi pelanggan di bank termasuk dalam kategori sistem yang kritis untuk bisnis.

Sifat emergensi yang paling krusial dari sistem kritis adalah ketergantungannya. Istilah "ketergantungan" diperkenalkan oleh Laprie (Laprie 1995) untuk mencakup atribut-atribut sistem yang terkait dengan ketersediaan, keandalan, keselamatan, dan keamanan. Seperti yang telah saya bahas pada bagian sebelumnya, sifat-sifat ini memiliki hubungan yang erat, sehingga memiliki satu istilah yang mencakup semuanya adalah logis.

Terdapat beberapa faktor yang menjadikan dependabilitas sebagai atribut emergensi yang paling krusial bagi sistem kritis:

  1. Systems that are unreliable, unsafe or insecure are often rejected by their users. Apabila pengguna tidak memiliki kepercayaan terhadap suatu sistem, mereka akan enggan untuk menggunakannya. Selain itu, mereka juga bisa menolak untuk membeli atau menggunakan produk dari perusahaan yang sama dengan sistem yang diragukan keandalannya, karena mereka beranggapan bahwa produk tersebut mungkin juga tidak dapat dipercaya.
  2. System failure costs may be enormous. Dalam beberapa aplikasi, seperti pengendalian reaktor atau navigasi pesawat terbang, kerugian akibat kegagalan sistem jauh melebihi biaya pengoperasian sistem kontrol itu sendiri.
  3. Untrustworthy systems may cause information loss. Proses pengumpulan dan pemeliharaan data sangatlah mahal, bahkan ada situasi di mana nilainya melebihi sistem komputer yang digunakan untuk memprosesnya. Diperlukan upaya dan sumber daya yang signifikan untuk menggandakan data berharga guna mencegah terjadinya kerusakan pada data tersebut.

Karena biaya kegagalan sistem kritis yang tinggi, penting untuk menggunakan metode dan teknik yang dapat diandalkan dalam proses pengembangannya. Akibatnya, sistem kritis umumnya dikembangkan dengan menggunakan teknik yang telah terbukti efektif daripada teknik yang relatif baru dan belum memiliki pengalaman praktis yang luas. Alih-alih mengadopsi teknik dan metode baru, pengembang sistem kritis secara alami lebih konservatif. Mereka cenderung memilih penggunaan teknik lama yang kelebihan dan kekurangannya telah dipahami dengan baik daripada teknik baru yang mungkin terlihat lebih menjanjikan, tetapi memiliki potensi masalah jangka panjang yang belum diketahui dengan pasti.

Kadang-kadang, teknik rekayasa perangkat lunak yang mahal dan tidak hemat biaya yang digunakan untuk sistem non-kritis dapat diterapkan dalam pengembangan sistem kritis. Sebagai contoh, metode matematis formal dalam pengembangan perangkat lunak telah berhasil digunakan dalam konteks keselamatan dan keamanan sistem kritis (Hall, 1996; Hall dan Chapman, 2002). Salah satu alasan mengapa metode formal ini digunakan adalah untuk membantu mengurangi jumlah pengujian yang diperlukan. Dalam kasus sistem kritis, biaya verifikasi dan validasi biasanya sangat tinggi, mencapai lebih dari 50% dari total biaya pengembangan sistem.

Walaupun ada beberapa sistem kontrol yang dapat berjalan sepenuhnya otomatis, sebagian besar sistem kritis merupakan sistem sosio-teknis di mana peran manusia adalah memantau dan mengendalikan operasional sistem berbasis komputer. Biaya kegagalan pada sistem kritis umumnya sangat tinggi, sehingga kita membutuhkan kehadiran orang di dalam sistem yang mampu menghadapi situasi tak terduga dan dapat dengan cepat pulih dari kesulitan ketika terjadi kesalahan.

Memang benar, meskipun operator sistem dapat membantu dalam pemulihan dari masalah, mereka juga dapat menjadi penyebab masalah jika melakukan kesalahan. Terdapat tiga "komponen sistem" di mana kegagalan pada sistem kritis dapat terjadi:

  1. Kegagalan pada perangkat keras sistem dapat terjadi akibat berbagai faktor, seperti kesalahan dalam desainnya, kegagalan komponen karena kesalahan manufaktur, atau karena komponen telah mencapai masa pakai akhirnya.
  2. Gagalnya perangkat lunak sistem dapat disebabkan oleh beberapa faktor, termasuk kesalahan dalam spesifikasi, desain, atau implementasinya.
  3. Kegagalan operator manusia dalam mengoperasikan sistem dengan benar merupakan kemungkinan yang ada. Seiring meningkatnya keandalan perangkat keras dan perangkat lunak, kegagalan operasional kini menjadi penyebab utama dari kegagalan sistem.

Kegagalan dalam sistem dapat memiliki keterkaitan satu sama lain. Misalnya, jika terjadi kegagalan pada komponen perangkat keras, operator sistem akan menghadapi situasi yang tidak terduga dan beban kerja tambahan. Hal ini dapat menyebabkan stres pada mereka, dan orang yang stres sering kali membuat kesalahan. Akibatnya, kegagalan perangkat lunak juga dapat terjadi, yang kemudian memberikan lebih banyak tugas kepada operator, meningkatkan tekanan, dan sejenisnya.

Karenanya, menjadi sangat penting bagi perancang sistem kritis untuk mengadopsi perspektif holistik terhadap sistem secara keseluruhan, daripada hanya berfokus pada satu aspek saja. Jika perangkat keras, perangkat lunak, dan proses operasional dirancang secara terpisah tanpa mempertimbangkan potensi kelemahan di bagian lain sistem, kemungkinan besar akan terjadi kesalahan pada antarmuka antara berbagai bagian sistem tersebut.

Gambar 1



Source: Sommerville, Ian. 2007. Software Engineering Eight Edition. s.l. : Addison-. Wisley, 2007.

Comments

Popular posts from this blog

Proses Perangkat Lunak Menurut Roger S. Pressman

Suatu proses adalah gabungan dari beberapa kegiatan, aksi, dan pekerjaan yang dikerjakan saat akan membuat beberapa produk. Setiap kegiatan memiliki tujuan yang luas (seperti komunikasi dengan pemangku kepentingan) dan diterapkan secara universal, tidak peduli pada domain aplikasi, ukuran proyek, kompleksitas usaha, atau tingkat ketelitian rekayasa perangkat lunak yang digunakan. Aksi (contohnya, desain arsitektur) mencakup rangkaian tugas yang menghasilkan produk utama (sebagai contoh, model desain arsitektural). Sebuah tugas berfokus pada tujuan yang kecil namun terdefinisi dengan baik (seperti melakukan pengujian unit) yang menghasilkan hasil yang konkret. Dalam dunia rekayasa perangkat lunak, suatu proses tidaklah berarti resep yang kaku untuk membuat perangkat lunak. Sebaliknya, proses ini merupakan pendekatan yang dapat disesuaikan yang memungkinkan tim pengembang perangkat lunak untuk memilih dan mengeksekusi serangkaian tindakan dan tugas yang sesuai. Tujuannya adalah untuk sel...

Personal And Team Process Models Menurut Roger S. Pressman

 Menurut penulis, sebuah proses perangkat lunak yang optimal adalah yang dapat disesuaikan dengan kebutuhan tim yang akan melaksanakan pekerjaan tersebut. Meskipun model proses perangkat lunak telah dibuat di tingkat perusahaan atau organisasi, namun untuk efektifitasnya hanya akan tercapai apabila dapat diadaptasi dengan signifikan untuk memenuhi kebutuhan tim proyek yang sebenarnya melaksanakan rekayasa perangkat lunak. Sebaiknya, proses yang dibuat haruslah yang paling cocok dengan kebutuhan tim dan organisasi secara menyeluruh. Atau, tim itu sendiri dapat membuat proses sesuai dengan kebutuhan individu mereka, namun tetap memenuhi kebutuhan organisasi secara keseluruhan. Watts Humphrey berpendapat bahwa membangun "personal software process" maupun "team software process" dapat dilakukan, meskipun memerlukan usaha, pelatihan, dan koordinasi yang sungguh-sungguh. 1.1 Personal Software Process (PSP) Semua pengembang perangkat lunak menggunakan suatu proses, meskipu...

Other Agile Process Models (Model Process Agile Lainnya) Menurut Roger S. Pressman

 Sejarah pengembangan perangkat lunak telah dicatat dengan banyak deskripsi dan metodologi proses yang telah usang, alat-alat, dan teknologi, serta notasi pemodelan. Semua hal tersebut telah mencapai popularitasnya masing-masing sebelum akhirnya digantikan oleh yang baru dan lebih baik. Dalam upaya mencapai penerimaan di komunitas pengembangan perangkat lunak, berbagai agile process model telah diperkenalkan dan bersaing satu sama lain, mengikuti pola yang sama dengan gerakan sebelumnya. Sudah saya sampaikan pada bagian terakhir bahwa Extreme Programming (XP) merupakan agile process models yang paling sering digunakan. Meskipun demikian, terdapat banyak agile process models lain yang telah diusulkan dan diterapkan dalam berbagai industri. Beberapa model yang paling umum meliputi: Adaptive Software Development (ASD) Scrum Dynamic Systems Development Method (DSDM) Crystal Feature Drive Development (FDD) Lean Software Development (LSD) Agile Modeling (AM) Agile Unified Process (AUP) P...