Entropi Perangkat Lunak Dijelaskan: Penyebab, Efek, dan Solusi

Artikel ini ditujukan untuk pengembang perangkat lunak atau manajer proyek yang ingin tahu apa itu entropi perangkat lunak, efek praktis pada pekerjaan mereka, dan faktor-faktor mendasar yang berkontribusi pada pertumbuhannya.

Tujuan utama adalah untuk menciptakan kesadaran entropi perangkat lunak karena merupakan faktor dalam semua bentuk pengembangan perangkat lunak. Selanjutnya, kami mengeksplorasi cara entropi perangkat lunak dapat diberikan nilai konkret. Hanya dengan mengukur entropi perangkat lunak dan mengamati pertumbuhannya selama rilis berturut-turut, kami dapat benar-benar memahami risiko yang ditimbulkannya terhadap tujuan kami saat ini dan rencana masa depan.

Apa itu Entropi Perangkat Lunak?

Entropi perangkat lunak mendapatkan namanya dari karakteristik utama entropi di dunia nyata: Ini adalah ukuran kekacauan yang tetap sama atau meningkat seiring waktu . Dengan kata lain, ini adalah ukuran ketidakstabilan yang melekat yang dibangun ke dalam sistem perangkat lunak sehubungan dengan mengubahnya.

Sayangnya, entropi perangkat lunak jarang dianggap penting.

Tidak ada pertimbangan saat menarik seseorang dari tim pengembangan, memulai siklus pengembangan sebelum waktunya, atau menerapkan "perbaikan cepat"—saat-saat ketika, pada kenyataannya, kemungkinan besar akan tumbuh.

Pengembangan perangkat lunak adalah seni dan perdagangan yang blok bangunan intinya tidak jelas. Sementara pembangun bekerja dengan semen dan paku, pengembang perangkat lunak bekerja dengan pernyataan logis dan serangkaian asumsi. Ini tidak dapat dipegang dengan tangan dan diperiksa, juga tidak dapat dipesan dengan seperdelapan inci. Meskipun pengamat biasa mungkin tergoda untuk membandingkan pengembangan perangkat lunak dengan konstruksi, di luar beberapa kesamaan dangkal itu kontraproduktif untuk melakukannya.

Terlepas dari kesulitan ini, kami tetap dapat menyusun pedoman yang memungkinkan kami memahami sumber entropi perangkat lunak, mengukur tingkat risiko yang ditimbulkannya terhadap tujuan kami, dan (jika perlu) langkah apa yang dapat diambil untuk membatasi pertumbuhannya.

Definisi yang diusulkan dari entropi perangkat lunak adalah sebagai berikut:

di mana I diturunkan dari jumlah masalah tak terduga yang muncul selama iterasi pengembangan terakhir, C adalah probabilitas yang dirasakan bahwa penerapan perubahan pada sistem sekarang menghasilkan I > 0, dan S adalah cakupan iterasi pengembangan berikutnya. Secara umum, nilai E di bawah 0,1 dianggap baik. E 0,5 dianggap tinggi, dan nilai di atas 1,0 luar biasa.

Konsep iterasi pengembangan merupakan bagian integral dari pemahaman kita tentang entropi perangkat lunak. Ini adalah siklus aktivitas yang mengarah dari satu perilaku sistem ke perilaku lainnya. Tujuan yang kita tetapkan untuk diri kita sendiri selama iterasi perangkat lunak disebut ruang lingkupnya . Dalam pengembangan perangkat lunak, siklus tersebut melibatkan modifikasi atau perluasan kode dasar perangkat lunak.

Semua modifikasi kode terjadi dalam iterasi pengembangan bahkan jika mereka yang melakukannya tidak menganggapnya seperti itu. Artinya, organisasi kecil yang bangga membangun sistem mereka menggunakan metodologi "cepat dan kotor"—dengan sedikit atau tanpa pengumpulan persyaratan atau analisis—masih menggunakan iterasi pengembangan untuk mencapai tujuan mereka. Mereka hanya tidak merencanakannya. Demikian pula, bahkan jika perilaku sistem yang dimodifikasi menyimpang dalam beberapa cara dari niat kami, itu masih dapat dicapai melalui iterasi pengembangan.

Faktanya, risiko bahwa ini akan terjadi adalah persis apa yang dimaksudkan untuk dijelaskan oleh kesadaran kita tentang entropi perangkat lunak dan keinginan kita untuk mengukurnya dimaksudkan untuk membatasi. Dalam istilah praktis, kemudian, kita dapat mendefinisikan entropi perangkat lunak sebagai berikut.

Setiap sistem yang diberikan memiliki serangkaian masalah terbuka yang diketahui dan terbatas I ₀ . Pada akhir iterasi pengembangan berikutnya, akan ada satu set terbatas masalah terbuka yang diketahui I ₁ . Entropi inheren sistem menentukan seberapa besar ekspektasi kita terhadap I ₁ kemungkinan akan berbeda dari nilai sebenarnya dan seberapa besar perbedaan tersebut akan tumbuh pada iterasi berikutnya.

Efek Entropi Perangkat Lunak

Pengalaman praktis kami tentang efek entropi perangkat lunak bergantung pada bagaimana kami berinteraksi dengan sistem yang bersangkutan.

Pengguna memiliki pandangan statis perangkat lunak; mereka peduli dengan bagaimana perilakunya sekarang dan tidak peduli dengan internal sistem. Dengan melakukan tindakan yang telah ditentukan, pengguna berasumsi bahwa perangkat lunak akan merespons dengan perilaku yang telah ditentukan sebelumnya. Namun, pengguna adalah yang paling tidak siap untuk menyimpulkan tingkat entropi dalam perangkat lunak yang mereka gunakan.

Entropi perangkat lunak terkait dengan gagasan perubahan dan tidak memiliki arti dalam sistem statis. Jika tidak ada niat untuk mengubah sistem, kita tidak dapat berbicara tentang entropinya. Demikian juga, sistem yang belum ada (yaitu, iterasi berikutnya sebenarnya yang pertama dari keberadaannya) tidak memiliki entropi.

Perangkat lunak dapat dianggap sebagai "kereta" dari sudut pandang pengguna, tetapi jika selama iterasi berikutnya pengembang dan manajer perangkat lunak memenuhi tujuan mereka seperti yang direncanakan, kita harus menyimpulkan bahwa entropi dalam sistem sebenarnya cukup rendah! Oleh karena itu, pengalaman pengguna memberi tahu kami sangat sedikit, jika ada, tentang entropi perangkat lunak:

• Pengembang perangkat lunak memiliki pandangan yang lancar tentang perangkat lunak. Mereka prihatin dengan bagaimana sistem saat ini berfungsi hanya sejauh itu harus diubah, dan mereka prihatin dengan rincian cara kerjanya untuk merancang strategi yang tepat.

• Manajer mungkin memiliki pandangan yang paling rumit tentang perangkat lunak, baik statis maupun lancar. Mereka harus menyeimbangkan urgensi jangka pendek dengan tuntutan rencana bisnis yang meluas lebih jauh ke masa depan.

Orang-orang di kedua peran ini memiliki harapan. Entropi perangkat lunak memanifestasikan dirinya setiap kali harapan itu dimanjakan. Artinya, pengembang dan manajer perangkat lunak melakukan yang terbaik untuk menilai risiko dan merencanakannya, tetapi—tidak termasuk gangguan eksternal—jika harapan mereka tetap dikecewakan, barulah kita dapat berbicara tentang entropi perangkat lunak. Ini adalah tangan tak terlihat yang merusak interaksi komponen yang tidak ada dalam cakupan, menyebabkan server produksi mogok secara tidak dapat dijelaskan, dan menahan perbaikan terbaru yang tepat waktu dan hemat biaya.

Banyak sistem dengan tingkat entropi tinggi bergantung pada individu tertentu, terutama jika ada anggota junior dari tim pengembangan. Orang ini memiliki pengetahuan sehingga orang lain tidak dapat melakukan tugas mereka tanpa masukan "berharga" darinya. Itu tidak dapat ditangkap dalam diagram UML standar atau spesifikasi teknis karena terdiri dari campuran pengecualian, firasat, dan tip. Pengetahuan ini tidak bergantung pada kerangka kerja yang konsisten secara logis dan oleh karena itu sulit—jika bukan tidak mungkin—untuk ditransfer ke orang lain.

Mari kita asumsikan bahwa dengan tekad dan usaha yang besar, organisasi seperti itu mampu mengubah dirinya sendiri dan menstabilkan departemen TI-nya. Situasi tampaknya telah membaik karena, ketika pengembangan perangkat lunak terhenti, kemajuan apa pun yang menggembirakan. Namun, pada kenyataannya, harapan yang terpenuhi rendah dan pencapaiannya tidak menarik dibandingkan dengan tujuan mulia yang dapat dicapai sementara entropi masih rendah.

Ketika entropi perangkat lunak membanjiri sebuah proyek, proyek tersebut membeku.

Tidak ada lagi iterasi pengembangan. Untungnya, situasi ini tidak muncul secara instan. Pawai lambat tapi terjal menuju tepi tebing adalah sesuatu yang dialami setiap sistem. Tidak peduli seberapa baik dan efisiennya versi pertama, selama pengembangan berturut-turut, entropi entropinya—dan oleh karena itu risiko bahwa segala sesuatunya akan salah secara tak terduga—akan tumbuh kecuali jika langkah-langkah spesifik diambil untuk mencegahnya.

Entropi perangkat lunak tidak dapat dikurangi. Sama seperti entropi di dunia nyata, ia hanya tumbuh atau tetap sama. Pada awalnya, efeknya dapat diabaikan. Ketika mereka mulai bermanifestasi, gejalanya ringan dan dapat disembunyikan atau diabaikan. Tetapi jika sebuah organisasi hanya mencoba untuk memerangi entropi perangkat lunak setelah menjadi risiko dominan dalam sebuah proyek, sayangnya akan menemukan bahwa usahanya sia-sia. Oleh karena itu, kesadaran entropi perangkat lunak paling berguna ketika jangkauannya rendah dan efek sampingnya minimal.

Ini tidak berarti bahwa setiap organisasi harus mencurahkan sumber daya untuk membatasi pertumbuhan entropi dalam produknya. Sebagian besar perangkat lunak yang dikembangkan saat ini—khususnya perangkat lunak berorientasi konsumen—memiliki masa pakai yang diharapkan relatif singkat, mungkin beberapa tahun. Dalam hal ini, para pemangku kepentingannya tidak perlu mempertimbangkan efek entropi perangkat lunak, karena jarang menjadi kendala serius sebelum seluruh sistem dibuang. Namun, ada alasan yang kurang jelas untuk mempertimbangkan efek entropi perangkat lunak.

Pertimbangkan perangkat lunak yang menjalankan infrastruktur perutean internet atau mentransfer uang dari satu rekening bank ke rekening bank lainnya. Pada waktu tertentu, ada satu atau lebih versi perangkat lunak ini dalam produksi, dan perilaku kolektifnya dapat didokumentasikan dengan akurasi yang cukup tinggi.

Toleransi risiko suatu sistem adalah ukuran seberapa banyak dan jenis perilaku tak terduga apa yang dapat kita izinkan dengan nyaman dari satu iterasi pengembangan ke iterasi berikutnya. Untuk jenis sistem yang baru saja disebutkan, toleransi risiko jauh lebih rendah daripada, katakanlah, perangkat lunak yang merutekan panggilan telepon. Perangkat lunak ini, pada gilirannya, memiliki toleransi risiko yang lebih rendah daripada perangkat lunak yang mendorong keranjang belanja dari banyak situs web komersial.

Toleransi risiko dan entropi perangkat lunak terkait dalam entropi perangkat lunak harus minimal untuk memastikan bahwa kita akan tetap berada dalam toleransi risiko sistem selama iterasi pengembangan berikutnya.

Sumber Entropi Perangkat Lunak

Entropi perangkat lunak muncul dari kurangnya pengetahuan . Ini hasil dari perbedaan antara asumsi komunal kita dan perilaku aktual dari sistem yang ada. Fakta ini menjelaskan mengapa entropi perangkat lunak hanya memiliki arti dalam konteks memodifikasi sistem yang ada; ini adalah satu-satunya saat kurangnya pemahaman kita akan memiliki efek praktis. Entropi perangkat lunak menemukan lahan paling subur dalam sistem yang detailnya tidak dapat dipahami oleh satu orang tetapi malah tersebar di sekitar tim pengembangan. Waktu juga merupakan penghapus pengetahuan yang ampuh.

Kode adalah ekspresi dari serangkaian pernyataan logis. Ketika perilaku perangkat lunak (dan karena itu kodenya) tidak sesuai dengan logika yang dimaksudkan untuk diungkapkan, kita dapat berbicara tentang entropi bawaannya. Situasi ini dapat muncul dalam tiga cara: Logika diketahui dengan baik dan menyimpang dari ekspresinya, ada banyak pemahaman tentang logika yang dimaksudkan untuk diungkapkan oleh kode, atau logika tidak diketahui dengan baik.

• Situasi pertama —logikanya sudah dikenal luas dan menyimpang dari ekspresinya saat ini—adalah yang paling mudah untuk ditangani tetapi juga yang paling tidak umum. Hanya sistem yang sangat kecil yang mungkin dikelola oleh dua peserta, seorang pengembang dan seseorang yang bertanggung jawab atas rencana bisnis, yang akan termasuk dalam kategori ini.

• Situasi kedua —logikanya tidak diketahui dengan baik— jarang terjadi. Untuk semua maksud dan tujuan, iterasi pengembangan bahkan tidak dapat dimulai. Jika pada titik tertentu semua pemangku kepentingan bisa setuju, mereka kemungkinan besar akan menghadapi situasi pertama.

Pikiran manusia menafsirkan pengalamannya, secara efektif menyaring dan memodifikasinya dalam upaya untuk menyesuaikannya ke dalam kerangka pribadi. Dengan tidak adanya kebiasaan pengembangan yang efektif—berdasarkan pertukaran ide yang bebas, saling menghormati, dan harapan yang jelas—mungkin ada banyak interpretasi tentang bagaimana sistem saat ini berfungsi seperti halnya anggota tim. Tujuan tim untuk iterasi pengembangan saat ini mungkin dalam sengketa.

Banyak pengembang melindungi diri mereka sendiri dari situasi ini dengan memperkuat pemahaman unik mereka sendiri tentang apa yang diperlukan dari mereka dan bagaimana sistem “seharusnya” diatur. Manajer dan pemangku kepentingan lainnya, di sisi lain, mungkin tanpa disadari berusaha mengubah asumsi anggota tim lain dalam upaya salah arah untuk membuat hidup mereka sendiri lebih mudah.

Sekarang kita telah sampai pada sumber entropi perangkat lunak yang paling umum: Ada banyak interpretasi yang tidak lengkap dari logika yang ingin diungkapkan oleh sistem. Karena hanya ada satu manifestasi dari logika ini, situasinya secara definisi bermasalah.

Bagaimana kurangnya pengetahuan ini muncul? Ketidakmampuan adalah salah satu cara. Dan seperti yang telah kita lihat, kurangnya kesepakatan tentang tujuan iterasi pengembangan berikutnya adalah hal lain. Tetapi ada faktor lain yang perlu dipertimbangkan. Sebuah organisasi mungkin bermaksud menggunakan metodologi pengembangan tetapi kemudian dengan sembarangan mengabaikan beberapa atau semua aspeknya di lantai. Pengembang perangkat lunak kemudian ditugaskan untuk menyelesaikan tugas yang tidak jelas, seringkali terbuka untuk interpretasi. Organisasi yang menerapkan perubahan pada metodologi pengembangan mereka sangat rentan terhadap fenomena ini, meskipun mereka bukan satu-satunya. Konflik pribadi yang tidak disadari atau tidak dapat diselesaikan oleh manajemen juga dapat menyebabkan perbedaan yang berbahaya antara harapan dan hasil.

Ada cara kedua yang lebih penting kita kehilangan pengetahuan teknis tentang suatu produk: dalam transfer. Menangkap pengetahuan teknis di atas kertas merupakan tantangan bahkan bagi penulis yang paling mahir sekalipun. Alasannya adalah bahwa apa yang akan ditranskripsikan sama pentingnya dengan bagaimana . Tanpa disiplin yang tepat, seorang penulis teknis dapat merekam terlalu banyak informasi. Atau, mereka mungkin membuat asumsi yang menyebabkan mereka menghilangkan poin-poin penting. Setelah diproduksi, dokumentasi teknis kemudian harus dijaga agar tetap mutakhir, sebuah proposisi yang sulit bagi banyak organisasi yang kehilangan jejak dokumen segera setelah ditulis. Karena kesulitan-kesulitan ini, pengetahuan teknis jarang ditransfer dalam dokumen saja, tetapi juga dalam pasangan atau bentuk lain dari interaksi manusia-ke-manusia yang dekat.

Entropi perangkat lunak berkembang pesat setiap kali peserta aktif meninggalkan tim pengembangan. Mereka membawa sepotong pengetahuan yang berharga. Mereplikasi pengetahuan itu tidak mungkin, dan mendekatinya membutuhkan banyak usaha. Namun, dengan perhatian dan sumber daya yang cukup, pengetahuan yang cukup dapat dipertahankan sehingga pertumbuhan entropi sistem dapat diminimalkan.

Ada sumber lain untuk entropi, tetapi ini relatif kecil. Misalnya, pembusukan perangkat lunak adalah proses di mana suatu sistem secara tak terduga dipengaruhi oleh perubahan lingkungannya. Kita dapat memikirkan perangkat lunak pihak ketiga yang menjadi sandarannya (seperti perpustakaan), tetapi ada penyebab lain yang lebih berbahaya dari pembusukan perangkat lunak, biasanya akibat perubahan asumsi yang menjadi dasar sistem. Misalnya, jika sebuah sistem dirancang dengan asumsi tertentu tentang ketersediaan memori, sistem itu mungkin mulai tidak berfungsi pada saat-saat yang tidak terduga jika memori yang tersedia untuknya berkurang.

Cara Menghitung Entropi: Menetapkan Nilai ke C, S, dan I

I adalah jumlah masalah perilaku yang belum terselesaikan dalam sistem perangkat lunak, termasuk tidak adanya fitur yang dijanjikan. Ini adalah kuantitas yang diketahui yang sering dilacak dalam sistem seperti JIRA. Nilai I diturunkan langsung darinya. I adalah jumlah “unit kerja” yang ditinggalkan atau dibiarkan tidak lengkap selama iterasi pengembangan terakhir di samping jumlah unit kerja yang dihasilkan dari masalah perilaku yang baru diperkenalkan dan tidak terduga. Karena I dihitung sebagai jumlah unit kerja, maka dapat kita kaitkan dengan nilai S yang merupakan lingkup iterasi pengembangan selanjutnya pada unit kerja yang sama. Apa sebenarnya yang membentuk “unit kerja” tergantung pada metodologi pengembangan.

C adalah probabilitas yang dipersepsikan bahwa, ketika unit kerja dalam ruang lingkup telah diimplementasikan, jumlah masalah terbuka aktual I1 pada iterasi berikutnya akan lebih besar dari estimasinya sekarang. Nilai ini tinggal di domain 0 <= C <= 1.

Orang mungkin berpendapat bahwa probabilitas C adalah persis apa yang dimaksudkan untuk diukur oleh entropi perangkat lunak. Namun, ada perbedaan mendasar antara nilai ini dan ukuran entropi perangkat lunak kami. Probabilitas yang dirasakan bahwa ada sesuatu yang salah adalah persis seperti itu: Ini bukan nilai sebenarnya. Namun, ini berguna karena perasaan orang-orang yang berpartisipasi dalam suatu proyek merupakan sumber informasi yang berharga tentang seberapa stabilnya proyek tersebut.

Cakupan S memperhitungkan besarnya perubahan yang diusulkan dan harus dinyatakan dalam satuan yang sama dengan I. Nilai S yang lebih besar menurunkan entropi karena kita meningkatkan cakupan perubahan yang diusulkan. Meskipun ini mungkin terdengar berlawanan dengan intuisi, kita harus ingat bahwa entropi adalah ukuran bagaimana pengembangan sistem mungkin tidak memenuhi harapan kita. Tidaklah cukup untuk mengatakan bahwa entropi adalah ukuran peluang munculnya masalah. Kami secara alami mencoba dan mengantisipasi risiko dan memperhitungkannya dalam perencanaan kami (dan karenanya dalam estimasi kami I1, yang mungkin meningkat lebih dari ₀ ). Jelas, semakin yakin kita tentang mengambil ruang lingkup perubahan besar, entropi kurang dapat dikatakan dalam sistem-kecuali mereka yang merencanakan perubahan dan/atau melaksanakannya tidak kompeten. Kemungkinan ini, bagaimanapun, mungkin tercermin dalam nilai saat ini dari I .

Perhatikan bahwa kita tidak perlu mencoba untuk menentukan besarnya perbedaan antara nilai aktual I ₁ dan nilai yang diharapkan. Jika kita berasumsi bahwa rencana kita benar ketika kita membuatnya, juga tidak masuk akal untuk berasumsi bahwa kita dapat memprediksi sejauh mana hasilnya tidak akan memenuhi harapan kita; kita hanya dapat menentukan peluang yang dirasakan C bahwa itu tidak akan terjadi. Namun, sejauh mana nilai aktual I ₁ berbeda dari nilai yang diharapkan merupakan masukan penting dalam perhitungan entropi pada iterasi berikutnya dalam bentuk nilai turunan I .

Secara teoritis, adalah mungkin bagi saya untuk memiliki nilai negatif. Namun dalam praktiknya, situasi ini tidak akan pernah terjadi; kami biasanya tidak memecahkan masalah secara tidak sengaja. Nilai negatif untuk I bukanlah tanda yang menenangkan. Mereka menyiratkan bahwa cara entropi sedang dihitung cacat. Pertumbuhan entropi perangkat lunak, tentu saja, dapat dikurangi dengan mengambil langkah-langkah khusus, seperti yang dijelaskan di bawah ini. Namun, dalam kasus seperti itu, saya tidak boleh berasumsi nilai negatif, karena kami selalu memasukkan harapan kami ke dalam desain kami.

C adalah nilai subjektif. Itu ada di benak peserta iterasi pengembangan dan dapat disimpulkan dengan polling mereka dan rata-rata hasilnya. Pertanyaan harus diajukan dengan cara yang positif. Misalnya: “Pada skala 0 hingga 10 dengan 10 kemungkinan besar, bagaimana Anda memperkirakan peluang tim untuk mencapai semua tujuannya pada iterasi pengembangan ini?”

Perhatikan bahwa pertanyaan diajukan tentang tujuan tim secara keseluruhan, bukan sebagian. Respons 10 akan menunjukkan nilai 0 untuk C, sedangkan respons 7 akan menunjukkan nilai 0,3. Dalam tim yang lebih besar, setiap respons mungkin diberi bobot tergantung pada faktor-faktor yang relevan, seperti berapa lama seorang individu telah terlibat dalam proyek dan berapa banyak waktu yang mereka habiskan untuk itu. Kompetensi, bagaimanapun, seharusnya tidak menjadi faktor dalam pembobotan tanggapan. Tak lama, bahkan anggota junior tim akan merasakan seberapa efektifnya dalam mencapai tujuannya. Tim yang cukup besar mungkin ingin membuang nilai tertinggi dan terendah yang dilaporkan sebelum merata-ratakan sisanya.

Menanyakan kepada para profesional seberapa besar kemungkinan tim mereka gagal adalah proposisi yang sensitif dan provokatif. Namun, inilah pertanyaan yang harus ditanyakan oleh organisasi mana pun yang ingin mengukur entropi. Untuk memastikan jawaban yang jujur, peserta harus memberikan estimasi C mereka secara anonim dan tanpa rasa takut akan akibat, bahkan jika mereka melaporkan nilai yang sangat tinggi.

S harus diberi nilai dalam "unit kerja" yang sama dengan I dan karena itu sangat bergantung pada metodologi pengembangan. Untuk tim yang menggunakan aspek metodologi Agile, cerita tampaknya merupakan "unit kerja" yang paling jelas untuk S dan I. Dalam hal ini, tingkat iterasi pengembangan mencakup setiap rilis yang dijadwalkan secara teratur ke dalam produksi, baik minor atau mayor. Saya harus dihitung sebagai jumlah dari jumlah cerita yang tidak berhasil diselesaikan selama setiap sprint menjelang rilis dan jumlah cerita yang dihasilkan untuk dimasukkan dalam sprint mendatang sebagai akibat dari masalah tak terduga yang muncul setelah rilis.

Perhatikan bahwa kami tidak menganggap hotfix atau rilis tidak terjadwal lainnya untuk produksi sebagai menentukan tingkat iterasi pengembangan, kami juga tidak boleh mengurangi cerita terkait dari I .

Kesulitan dengan pendekatan ini adalah bahwa periode penemuan dan analisis harus terjadi sebelum bug selanjutnya dapat dipecah menjadi cerita. Oleh karena itu, nilai sebenarnya dari I hanya dapat ditentukan setelah penundaan. Selain itu, polling untuk C secara alami terjadi pada awal setiap sprint. Oleh karena itu, hasil yang diperoleh harus sekali lagi dirata-ratakan selama rentang seluruh rilis. Terlepas dari kesulitan ini, tim mana pun yang menggunakan aspek metodologi Agile cenderung menemukan bahwa cerita adalah unit yang paling akurat untuk mengukur S (dan karena itu saya ).

Ada metodologi pengembangan lain yang digunakan saat ini. Apapun metodologi yang digunakan, prinsip-prinsip untuk mengukur entropi perangkat lunak tetap sama: Entropi perangkat lunak harus diukur antara rilis ke produksi, S dan I harus diukur dalam "unit kerja" yang sama, dan perkiraan C harus diambil dari peserta langsung dalam cara yang tidak mengancam dan sebaiknya anonim.

Mengurangi Pertumbuhan E

Setelah pengetahuan tentang suatu sistem hilang, itu tidak akan pernah bisa diperoleh kembali. Untuk alasan ini, entropi perangkat lunak tidak dapat dikurangi. Yang bisa kita harapkan hanyalah menahan pertumbuhannya.

Pertumbuhan entropi dapat dibatasi dengan mengadopsi langkah-langkah yang tepat selama pengembangan perangkat lunak. Aspek pemrograman berpasangan dari pengembangan Agile sangat berguna dalam hal ini. Karena lebih dari satu pengembang terlibat pada saat kode ditulis, pengetahuan tentang detail penting didistribusikan dan efek dari anggota tim yang keluar dikurangi.

Praktik lain yang bermanfaat adalah produksi dokumentasi yang terstruktur dengan baik dan mudah digunakan, terutama dalam organisasi yang menggunakan metodologi waterfall. Dokumentasi tersebut harus didukung oleh prinsip-prinsip yang ketat dan jelas dipahami oleh semua orang. Organisasi yang mengandalkan dokumentasi sebagai sarana utama komunikasi dan menjaga pengetahuan teknis sangat cocok untuk pendekatan ini. Hanya ketika tidak ada pedoman atau pelatihan tentang cara menulis dan menggunakan dokumen yang ditulis secara internal—seperti yang sering terjadi di organisasi yang lebih muda yang menggunakan metodologi RAD atau Agile—nilai mereka menjadi mencurigakan.

Ada dua cara untuk mengurangi pertumbuhan entropi dalam suatu sistem: Jalankan perubahan yang dimaksudkan untuk mengurangi I atau jalankan perubahan yang dimaksudkan untuk mengurangi C.

Yang pertama melibatkan refactoring. Tindakan yang dimaksudkan untuk mengurangi I cenderung bersifat teknis dan mungkin sudah tidak asing lagi bagi pembaca. Iterasi pengembangan harus terjadi. Bagian dari iterasi ini yang dimaksudkan untuk mengurangi pertumbuhan entropi tidak akan memberikan manfaat bisnis yang nyata sementara akan menghabiskan waktu dan sumber daya. Fakta ini sering membuat pengurangan pertumbuhan entropi menjadi penjualan yang sulit dalam organisasi mana pun.

Mengurangi nilai C adalah strategi yang lebih ampuh karena efeknya berjangka lebih panjang. Selain itu, C bertindak sebagai pemeriksaan penting pada pertumbuhan rasio I terhadap S. Tindakan untuk mengurangi C cenderung terfokus pada perilaku dan pemikiran manusia. Meskipun tindakan ini mungkin tidak memerlukan iterasi pengembangan semata, tindakan ini akan memperlambat iterasi berikutnya karena peserta menerima dan menyesuaikan dengan prosedur baru. Tindakan yang tampaknya sederhana untuk menyetujui perbaikan apa yang harus dilakukan adalah jalan yang penuh dengan bahayanya sendiri, karena tujuan yang berbeda dari peserta proyek dan pemangku kepentingan tiba-tiba terungkap.

Membungkus

Entropi perangkat lunak adalah risiko bahwa mengubah perangkat lunak yang ada akan mengakibatkan masalah yang tidak terduga, tujuan yang tidak tercapai, atau keduanya.

Meskipun diabaikan ketika perangkat lunak pertama kali dibuat, entropi perangkat lunak tumbuh dengan setiap iterasi pengembangan. Jika dibiarkan melanjutkan tanpa dicentang, entropi perangkat lunak pada akhirnya akan menghentikan pengembangan lebih lanjut.

Namun, tidak setiap proyek harus memperhitungkan efek entropi perangkat lunak. Banyak sistem akan dikeluarkan dari produksi sebelum entropi dapat memberikan efek yang nyata dan merusak. Bagi mereka yang masa hidupnya cukup lama sehingga entropi menimbulkan risiko yang kredibel, menciptakan kesadaran untuk itu dan mengukur luasnya, sementara masih rendah, menyediakan sarana untuk memastikan bahwa pembangunan tidak terputus sebelum waktunya.

Setelah sistem benar-benar kewalahan oleh efek entropi perangkat lunak, tidak ada lagi perubahan yang dapat dilakukan dan pengembangan pada dasarnya telah berakhir.