Skip to main content

Emergent System Properties (Properti Sistem Yang Muncul) Menurut Ian Sommerville

 Dalam suatu sistem, hubungan antara komponen-komponen yang kompleks menghasilkan properti yang merupakan properti dari sistem secara keseluruhan. Properti ini (menurut Checkland, 1981) tidak dapat dikaitkan dengan bagian tertentu dari sistem dan hanya muncul setelah komponen sistem terintegrasi. Beberapa sifat muncul tersebut dapat diturunkan langsung dari sifat sub-sistem yang sebanding, tetapi lebih sering dihasilkan dari hubungan timbal balik sub-sistem yang kompleks dan tidak dapat diturunkan dari sifat-sifat komponen sistem individual. Dalam Gambar 1, beberapa contoh sifat-sifat muncul tersebut ditunjukkan.

Gambar 1

Terdapat dua tipe dari karakteristik yang muncul:

  1. Functional emergent properties, Properti ini muncul ketika semua komponen sistem bekerja bersama untuk mencapai tujuan tertentu. Sebagai contoh, setelah dirakit dari komponen-komponennya, sepeda memiliki sifat fungsional sebagai alat transportasi.
  2. Non-functional emergent properties, Properti non-fungsional, di sisi lain, terkait dengan bagaimana suatu sistem berperilaku di lingkungan di mana ia beroperasi. Contohnya termasuk kehandalan, performa, keselamatan, dan keamanan. Properti non-fungsional ini sangat penting bagi sistem berbasis komputer karena kegagalan untuk memenuhi standar minimum untuk setiap properti dapat menyebabkan sistem menjadi tidak berguna. Meskipun beberapa pengguna mungkin tidak memerlukan semua fungsi yang ada pada sistem, namun sistem yang tidak dapat diandalkan atau terlalu lambat akan ditolak oleh seluruh pengguna.

Untuk menggambarkan kompleksitas sifat-sifat yang muncul, perhatikan sifat keandalan sistem. Keandalan adalah konsep yang kompleks dan harus selalu dipertimbangkan pada tingkat sistem daripada pada tingkat komponen individu. Ketergantungan antara komponen dalam sistem dapat membuat kegagalan satu komponen menyebar ke seluruh sistem dan mempengaruhi kinerja komponen lain. Memprediksi konsekuensi kegagalan komponen dan dampaknya pada seluruh sistem seringkali sulit. Oleh karena itu, perkiraan yang akurat tentang keandalan sistem secara keseluruhan tidak dapat dibuat hanya dengan data keandalan komponen individu.

Terdapat tiga faktor yang memengaruhi keandalan sistem secara menyeluruh:

  1. Hardware reliability, Bagaimana kemungkinan terjadinya kegagalan pada komponen perangkat keras dan berapa lama waktu yang dibutuhkan untuk memperbaikinya?
  2. Software reliability, Bagaimana kemungkinan perangkat lunak menghasilkan output yang salah? Kegagalan pada perangkat lunak memiliki karakteristik yang berbeda dengan kegagalan pada perangkat keras, karena perangkat lunak tidak mengalami kerusakan secara fisik. Kegagalan pada perangkat lunak biasanya bersifat sementara sehingga sistem masih dapat beroperasi setelah menghasilkan output yang salah.
  3. Operator reliability, Berapa besar kemungkinan kesalahan dilakukan oleh operator sistem?

Semua aspek ini saling terkait erat. Kegagalan komponen perangkat keras dapat memicu munculnya sinyal-sinyal palsu yang di luar jangkauan input yang diharapkan oleh perangkat lunak. Sebagai akibatnya, perilaku sistem dapat menjadi tidak terduga. Kesalahan operator umumnya terjadi dalam situasi stres, seperti saat terjadi kegagalan sistem, yang dapat memperparah situasi dengan menekan perangkat keras dan menyebabkan lebih banyak kegagalan pada sistem. Oleh karena itu, kegagalan awal yang dapat diperbaiki dengan cepat dapat berkembang menjadi masalah yang serius dan memerlukan shutdown sistem secara keseluruhan.


Gambar 2

Properti sistem seperti kinerja atau kegunaan sulit dinilai secara awal, tetapi dapat diukur setelah sistem berjalan. Namun, sifat lain seperti keselamatan dan keamanan menimbulkan masalah yang berbeda. Dalam hal ini, selain memperhatikan perilaku sistem yang diinginkan, juga perlu memperhatikan perilaku yang tidak diinginkan yang dapat terjadi pada sistem. Sebuah sistem yang aman harus dapat mencegah akses tidak sah ke data, meskipun tidak mungkin untuk memprediksi semua kemungkinan cara untuk mendapatkan akses dan secara eksplisit melarangnya. Oleh karena itu, untuk menilai sifat ini, Anda hanya dapat mengandalkan asumsi bahwa sistem tidak aman sampai terbukti sebaliknya dengan adanya pelanggaran keamanan.



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

Labels:

Comments

Post a Comment

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...
Post a Comment
Read more

Extreme Programming (XP) Menurut Roger S. Pressman

 Untuk memberikan gambaran yang lebih rinci tentang proses agile, saya akan memaparkan Extreme Programming (XP), suatu pendekatan yang banyak digunakan dalam pengembangan perangkat lunak agile. Meskipun ide dan metode yang terkait dengan XP telah muncul pada akhir 1980-an, Kent Beck telah menulis secara ekstensif mengenai topik ini. Baru-baru ini, sebuah varian XP yang disebut Industrial XP (IXP) telah diajukan. IXP telah menyempurnakan XP dan dirancang untuk digunakan khusus dalam organisasi besar dengan proses yang lebih fleksibel. 1.1 XP Values Sebuah seperangkat lima nilai yang menjadi dasar bagi seluruh pekerjaan yang dilakukan dalam XP telah didefinisikan oleh Beck. Nilai-nilai ini mencakup communication, simplicity, feedback, courage, dan respect, dan masing-masing nilai ini digunakan sebagai motivasi dalam aktivitas, tindakan, dan tugas XP yang spesifik. XP menekankan pada kolaborasi yang erat namun tidak formal secara verbal untuk mencapai komunikasi yang efektif anta...
Post a Comment
Read more

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...
Post a Comment
Read more