Kami memberi tahu apa esensi hukum itu, bagaimana ia memanifestasikan dirinya dan apa yang terjadi ketika hukum ini tidak diperhitungkan dalam desain dan pengembangan sistem TI.
Foto - Spencer - UnsplashDalam buku “To Yourself an MBA. Pendidikan mandiri adalah 100% ", ditulis oleh Josh Kaufman (Josh Kaufman), hukum Gall
diberikan dalam kata-kata berikut:
“Setiap sistem kompleks kerja dikembangkan berdasarkan sistem sederhana yang berfungsi. Sistem kompleks yang diciptakan dari awal tidak akan pernah berfungsi di dunia nyata, karena selama proses pengembangan mereka tidak dipengaruhi oleh faktor seleksi yang melekat di lingkungan. "
Ini berarti bahwa pendekatan sistematis harus diterapkan pada pengembangan proyek apa pun - untuk beralih dari yang sederhana ke yang kompleks. Dengan kata lain, Anda harus mulai dengan penciptaan sistem sederhana dan secara bertahap bergerak menuju kompleksitasnya, memperluas fungsionalitas dan kemampuan.
Sistem sederhana biasanya berarti sistem yang terdiri dari sejumlah kecil elemen dan tidak memiliki hierarki. Sistem yang kompleks, sebaliknya, memiliki struktur bercabang dan sejumlah besar komponen yang saling berhubungan.
Risalah sejarah
Penulis hukum, John Gall, adalah seorang dokter anak berdasarkan profesi, tetapi menghabiskan waktu luangnya meneliti teori sistem. Pada tahun 1977, ia menerbitkan buku
Sistematisasi: Bagaimana Sistem Bekerja dan Bagaimana Mereka Hancur . Di dalamnya, ia mengatakan bahwa untuk mengendalikan sistem apa pun, perlu dipahami bagaimana faktor lingkungan memengaruhi fungsinya. Di buku inilah
hukum Gall dirumuskan .
Hukum memperoleh ketenarannya berkat disebutkan dalam buku "
Structured Terms of Reference ", yang ditulis oleh pengembang sistem Ken Orr (
Ken Orr ) pada tahun 1981. Karyanya telah mendapatkan popularitas yang luas, dan penulis literatur modern tentang analisis sistem
masih merujuknya .
Beberapa waktu setelah penerbitan buku Ken Orr, aturan Gall "dipersenjatai" dengan Grady Booch ketika ia menciptakan
UML . Bahasa ini juga melacak konsep "dari sederhana ke rumit": untuk membangun model abstrak dari sistem, kelas individu, jenis dan antarmuka digunakan.
Foto - Isaac Smith - UnsplashUndang-undang ini juga tercermin dalam pendekatan fleksibel untuk pengembangan perangkat lunak. Secara khusus, aturan ini berlaku dalam pemrograman ekstrim (
XP ). Salah satu konsep utama metodologi ini adalah
kemudahan desain . Ini menyatakan bahwa produk baru tidak boleh dirancang terlebih dahulu dan secara keseluruhan. Perencanaan harus dilakukan secara iteratif, dengan mempertimbangkan persyaratan yang terus berubah (pelanggan dan pasar).
Kapan harus mengikuti Hukum Gall
Contoh paling mencolok untuk menggambarkan hukum Gall adalah
World Wide Web . Ini berasal sebagai proyek CERN lokal - organisasi mengembangkan alat untuk menghubungkan dokumen melalui tautan hypertext. Namun seiring waktu, jaringan berhasil diperluas ke skala global - kemampuannya diperluas, struktur menjadi lebih kompleks dan "tumbuh" dengan protokol baru (misalnya, HTTPS, yang menjadi pengembangan HTTP).
Memulai pengembangan dengan
MVP (produk minimum yang layak) memungkinkan untuk menguji ide dengan cepat dan, jika perlu, mengubah fungsionalitas. Misalnya, versi pertama layanan Uber hanya
berisi dua fungsi sederhana: memanggil pengemudi dan membayar biaya perjalanan dengan kartu kredit. Dengan bantuan mereka, tim menguji konsepnya, menarik basis pengguna dan terus mengembangkan produk. Saat ini, fungsi-fungsi dasar ini menjadi lebih rumit: sekarang mungkin untuk membagi tagihan antara beberapa orang, melacak driver di peta dan melakukan pembayaran otomatis.
Hukum Gall membantu membuat UI lebih mudah bagi pengguna. Misalnya, versi pertama aplikasi Dropbox memiliki antarmuka yang sangat sederhana - itu
adalah folder file biasa. Menurut para pengembang, fitur khusus ini memungkinkan untuk menarik sejumlah besar pengguna baru - dalam beberapa hari daftar aplikasi untuk pengujian beta Dropbox diisi ulang oleh 70 ribu. Fungsi tambahan dan kotak dialog - seperti file penyuntingan bersama - mulai muncul kemudian.
Apa yang terjadi ketika pola ini tidak diperhitungkan
Sebagai contoh proyek, ketika membuat pengembang mana yang harus tahu tentang hukum Gall dan memperhitungkannya, standar teknologi
CORBA biasanya diberikan. Spesifikasinya awalnya sangat banyak dan berisi banyak instruksi. Karena kompleksitas yang berlebihan, pengembangan standar dilakukan untuk waktu yang lama, sementara banyak fitur-fiturnya tidak pernah diimplementasikan dalam praktik. Akibatnya, CORBA tidak banyak digunakan.
Contoh implementasi produk perangkat lunak yang gagal adalah Digital Media Initiative (DMI), proyek BBC 2008. Tujuannya adalah untuk menciptakan platform skala besar dengan alat internal untuk mengedit video dan penyimpanan konten. Basis DMI segera meletakkan sejumlah besar spesifikasi, yang tidak diterapkan dalam praktik. Pembangunan berlangsung lima tahun, tetapi tidak pernah selesai. Pertama, kontraktor itu ditinggalkan oleh perusahaan - Siemens - dan kemudian BBC sendiri. Secara total, DMI menghabiskan 100 juta pound.
Contoh implementasi antarmuka yang gagal adalah layanan
Google Wave . Itu seharusnya menggabungkan fungsi forum online, jejaring sosial, kurir instan dan sistem kontrol versi. Pembuat platform berasumsi bahwa itu akan menjadi cara komunikasi universal. Tetapi dalam upaya untuk menggantikan "sekaligus," tim pengembangan membebani aplikasi dengan berbagai fungsi. Akibatnya, pengguna harus berurusan dengan fitur antarmuka untuk waktu yang lama. Kesulitan muncul bahkan dengan bilah pencarian layanan - untuk bekerja dengannya, Anda harus tahu tag khusus. Proyek ini dikembangkan dari 2009 hingga 2010 - sistem tidak memenuhi harapan pengembang dan pengguna dan proyek dibatalkan.
Bacaan terkait:
Kami di
ITGLOBAL.COM menyediakan cloud pribadi dan hybrid dan menawarkan layanan yang bertujuan untuk mengembangkan infrastruktur TI pelanggan. Kami harap materi ini bermanfaat bagi Anda. Apa yang dapat Anda baca tentang kami, dan apa yang kami tulis tentang diri kami di blog perusahaan: