Yazılım Entropisi Açıklaması: Nedenler, Etkiler ve Çözümler

Bu makale, yazılım entropisinin ne olduğunu, çalışmaları üzerindeki pratik etkileri ve büyümesine katkıda bulunan temel faktörleri merak eden yazılım geliştiricisi veya proje yöneticisine yöneliktir.

Birincil amaç, yazılım entropisi konusunda bir farkındalık yaratmaktır, çünkü bu, tüm yazılım geliştirme biçimlerinde bir faktördür. Ayrıca, yazılım entropisine somut bir değer atamanın bir yolunu araştırıyoruz. Yalnızca yazılım entropisini ölçerek ve ardışık sürümlerdeki büyümesini gözlemleyerek, mevcut hedeflerimiz ve gelecek planlarımız için oluşturduğu riski gerçekten anlayabiliriz.

Yazılım Entropisi Nedir?

Yazılım entropisi , adını gerçek dünyadaki entropinin başlıca özelliğinden alır: Aynı kalan veya zamanla artan bir kaosun ölçüsüdür . Başka bir deyişle, onu değiştirmeye ilişkin olarak bir yazılım sisteminde yerleşik olan doğal kararsızlığın bir ölçüsüdür.

Ne yazık ki, yazılım entropisine nadiren hak ettiği önem verilir.

Birini geliştirme ekibinden çekerken, bir geliştirme döngüsünü zamanından önce başlatırken veya "hızlı düzeltmeler" uygularken -aslında, büyüme olasılığının en yüksek olduğu anlarda- hiç dikkate alınmaz.

Yazılım geliştirme, temel yapı taşları tam olarak tanımlanmamış bir sanat ve ticarettir. İnşaatçılar çimento ve çivi ile çalışırken, yazılım geliştiricisi mantıksal iddialar ve bir dizi varsayımla çalışır. Bunlar elde tutulamaz ve incelenemez ve bir inçin sekizde biri kadar sipariş verilemez. Sıradan bir gözlemci, yazılım geliştirmeyi inşaat ile karşılaştırmaya cazip gelse de, birkaç yüzeysel benzerliğin ötesinde, bunu yapmak verimsizdir.

Bu zorluklara rağmen, yine de yazılım entropisinin kaynaklarını anlamamıza, hedeflerimiz için oluşturduğu riskin boyutunu ölçmemize ve (gerekirse) büyümesini sınırlamak için hangi adımların atılabileceğine olanak sağlayacak yönergeleri ortaya koyabiliriz.

Yazılım entropisinin önerilen tanımı aşağıdaki gibidir:

son geliştirme yinelemesi sırasında ortaya çıkan beklenmedik sorunların sayısından türetildiği yerde, C, sistemde değişikliklerin uygulanmasının artık yeni bir I > 0 ile sonuçlanmasının algılanan olasılığıdır ve S, bir sonraki geliştirme yinelemesinin kapsamıdır. Genel olarak, 0.1'in altındaki E değerleri iyi olarak kabul edilir. 0,5'lik bir E yüksek olarak kabul edilir ve 1.0'ın üzerindeki değerler ezicidir.

Geliştirme yinelemesi kavramı, yazılım entropisi anlayışımızın ayrılmaz bir parçasıdır. Bunlar, sistemin bir davranışından diğerine giden aktivite döngüleridir. Yazılım yinelemesi sırasında kendimize koyduğumuz hedeflere kapsamı denir. Yazılım geliştirmede, bu tür döngüler, yazılımın temel kodunu değiştirmeyi veya genişletmeyi içerir.

Kodda yapılan tüm değişiklikler, bunları gerçekleştirenler bu şekilde düşünmeseler bile bir geliştirme yinelemesinde gerçekleşir. Yani, "hızlı ve kirli" bir metodoloji kullanarak sistemlerini kurmaktan gurur duyan daha küçük kuruluşlar, çok az veya hiç gereksinim veya analiz toplamadan, hedeflerine ulaşmak için hala geliştirme yinelemelerini kullanırlar. Onları basitçe planlamıyorlar. Benzer şekilde, değiştirilmiş bir sistemin davranışı bir şekilde niyetlerimizden farklı olsa bile, yine de bir geliştirme yinelemesi yoluyla elde edildi.

Aslında, bunun gerçekleşmesi riski, tam olarak yazılım entropisi konusundaki farkındalığımızın açıklamayı amaçladığı ve onu ölçme arzumuzun sınırlamayı amaçladığı şeydir. O halde pratik açıdan yazılım entropisini aşağıdaki gibi tanımlayabiliriz.

Herhangi bir sistem, sonlu bir bilinen, açık sorun kümesine sahiptir I ₀ . Bir sonraki geliştirme yinelemesinin sonunda, sınırlı sayıda bilinen, açık sorun kümesi olacaktır I ₁ . Sistemin doğal entropisi, I ₁ beklentimizin gerçek değerinden ne kadar farklı olabileceğini ve sonraki yinelemelerde farkın ne kadar artacağını belirtir.

Yazılım Entropisinin Etkileri

Yazılım entropisinin etkilerine ilişkin pratik deneyimimiz, söz konusu sistemle nasıl etkileşime girdiğimize bağlıdır.

Kullanıcılar yazılımın statik bir görünümüne sahiptir; onlar sistemin şu anda nasıl davranacağıyla ilgilenirler ve bir sistemin içindekilerle ilgilenmezler. Kullanıcılar, önceden tanımlanmış bir eylemi gerçekleştirerek, yazılımın karşılık gelen önceden tanımlanmış bir davranışla yanıt vereceğini varsayar. Ancak, kullanıcılar, kullandıkları yazılımdaki entropi seviyesini belirlemeye en az hazır olanlardır.

Yazılım entropisi, değişim kavramına bağlıdır ve statik bir sistemde hiçbir anlamı yoktur. Sistemi değiştirme niyeti yoksa, onun entropisinden söz edemeyiz. Benzer şekilde, henüz var olmayan bir sistem (yani, bir sonraki yineleme aslında varlığının ilkidir) entropisi yoktur.

Yazılım, bir kullanıcı açısından "hatalı" olarak algılanabilir, ancak sonraki yinelemeler sırasında yazılım geliştiricileri ve yöneticileri planladıkları gibi hedeflerine ulaşıyorlarsa, sistemdeki entropinin aslında oldukça düşük olduğu sonucuna varmalıyız! Bu nedenle, kullanıcıların deneyimi bize yazılım entropisi hakkında çok az şey söylüyor:

• Yazılım geliştiricileri, yazılımın akıcı bir görünümüne sahiptir. Sadece değiştirilmesi gerektiği sürece bir sistemin halihazırda nasıl işlediğiyle ilgilenirler ve uygun bir strateji tasarlamak için nasıl çalıştığıyla ilgili ayrıntılarla ilgilenirler.

• Yöneticiler, hem statik hem de akışkan olan belki de en karmaşık yazılım görünümüne sahiptir. Kısa vadenin gerekliliklerini geleceğe uzanan bir iş planının talepleri ile dengelemeleri gerekir.

Her iki roldeki insanların da beklentileri vardır. Yazılım entropisi, bu beklentiler bozulduğunda kendini gösterir. Yani, yazılım geliştiriciler ve yöneticiler riskleri değerlendirmek ve onlar için plan yapmak için ellerinden gelenin en iyisini yaparlar, ancak – dış kesintiler hariç – beklentileri yine de hayal kırıklığına uğrarsa, ancak o zaman yazılım entropisinden bahsedebiliriz. Kapsam dahilinde olmayan bileşen etkileşimlerini kesen, üretim sunucularının anlaşılmaz bir şekilde çökmesine neden olan ve zamanında ve uygun maliyetli bir düzeltmeyi engelleyen görünmez eldir.

Yüksek entropi seviyelerine sahip birçok sistem, özellikle geliştirme ekibinin genç üyeleri varsa, belirli bireylere güvenir. Bu kişi, "değerli" girdisi olmadan diğerlerinin görevlerini yerine getiremeyecekleri bir bilgiye sahiptir. İstisnalar, önseziler ve ipuçlarından oluşan bir karışımdan oluştuğu için standart UML diyagramlarında veya teknik özelliklerde ele alınamaz. Bu bilgi mantıksal olarak tutarlı bir çerçeveye bağlı değildir ve bu nedenle başka birine aktarılması imkansız değilse de zordur.

Böyle bir organizasyonun büyük bir kararlılık ve çabayla kendi BT departmanını düzeltebileceğini ve stabilize edebileceğini varsayalım. Durum düzelmiş gibi görünüyor çünkü yazılım geliştirme durma noktasına geldiğinde, herhangi bir ilerleme cesaret verici. Bununla birlikte, gerçekte, entropi hala düşükken ulaşılabilecek yüksek hedeflere kıyasla, karşılanan beklentiler düşüktür ve başarılar ilgi çekici değildir.

Yazılım entropisi bir projeyi alt ettiğinde, proje donar.

Daha fazla geliştirme yinelemesi olamaz. Neyse ki, bu durum bir anda ortaya çıkmaz. Bir uçurumun kenarına doğru yavaş ama sarp yürüyüş, her sistemin maruz kaldığı bir şeydir. İlk versiyon ne kadar iyi organize edilmiş ve verimli olursa olsun, birbirini takip eden geliştirme yinelemelerinde entropisi - ve dolayısıyla işlerin beklenmedik bir şekilde ters gitme riski - bunu önlemek için belirli adımlar atılmazsa artacaktır.

Yazılım entropisi azaltılamaz. Tıpkı gerçek dünyadaki entropi gibi, sadece büyür veya aynı kalır. İlk başta, etkileri ihmal edilebilir. Ortaya çıkmaya başladıklarında semptomlar hafiftir ve maskelenebilir veya göz ardı edilebilir. Ancak bir kuruluş, yalnızca bir projede baskın risk haline geldikten sonra yazılım entropisi ile mücadele etmeye çalışırsa, çabalarının boşuna olduğunu görecektir. Bu nedenle yazılım entropisinin farkındalığı, kapsamı düşük ve olumsuz etkileri minimum olduğunda en faydalıdır.

Her kuruluşun, ürünlerindeki entropinin büyümesini sınırlamaya kaynak ayırması gerektiği sonucu çıkmaz. Bugün geliştirilmekte olan yazılımların çoğu, özellikle de tüketici odaklı yazılımlar, nispeten kısa bir kullanım ömrüne, belki de birkaç yıla sahiptir. Bu durumda, tüm sistem atılmadan önce nadiren ciddi bir engel olacağından, paydaşlarının yazılım entropisinin etkilerini dikkate almasına gerek yoktur. Bununla birlikte, yazılım entropisinin etkilerini düşünmek için daha az belirgin nedenler vardır.

İnternetin yönlendirme altyapısını çalıştıran veya bir banka hesabından diğerine para aktaran yazılımı düşünün. Herhangi bir zamanda, bu yazılımın üretimde bir veya daha fazla sürümü vardır ve bunların toplu davranışları oldukça yüksek bir doğrulukla belgelenebilir.

Bir sistemin risk toleransı , bir geliştirme yinelemesinden diğerine ne kadar ve ne tür beklenmedik davranışlara rahatça izin verebileceğimizin bir ölçüsüdür. Az önce bahsedilen sistem türleri için risk toleransı, örneğin telefon aramalarını yönlendiren yazılımlardan çok daha düşüktür. Bu yazılım, sırayla, birçok ticari web sitesinin alışveriş sepetini yönlendiren yazılımdan daha düşük bir risk toleransına sahiptir.

Risk toleransı ve yazılım entropisi, bir sonraki geliştirme yinelemesi sırasında bir sistemin risk toleransı içinde kalacağımızdan emin olmak için yazılım entropisinin minimum olması gerektiğiyle ilişkilidir.

Yazılım Entropisinin Kaynakları

Yazılım entropisi bilgi eksikliğinden kaynaklanır. Toplumsal varsayımlarımız ile mevcut bir sistemin fiili davranışı arasındaki farklılıktan kaynaklanır. Bu gerçek, yazılım entropisinin neden yalnızca mevcut bir sistemi değiştirme bağlamında anlam ifade ettiğini açıklar; anlayış eksikliğimizin herhangi bir pratik etkisinin olacağı tek zamandır. Yazılım entropisi, ayrıntıları tek bir kişi tarafından anlaşılamayan, bunun yerine bir geliştirme ekibine yayılmış bir sistemde en verimli zemini bulur. Zaman da güçlü bir bilgi silgisidir.

Kod, bir dizi mantıksal iddianın ifadesidir. Yazılımın davranışı (ve dolayısıyla kodu) ifade etmesi amaçlanan mantığa karşılık gelmediğinde, doğal entropisinden bahsedebiliriz. Bu durum üç şekilde ortaya çıkabilir: Mantık iyi bilinir ve ifadesinden uzaklaşır, kodun ifade etmek istediği mantığın birden fazla anlayışı vardır veya mantığın iyi bilinmemesi.

• İlk durum -mantık iyi bilinir ve şu anki ifadesinden farklıdır- ele alınması en kolay ama aynı zamanda en az yaygın olanıdır. Yalnızca bir geliştirici ve iş planından sorumlu biri olmak üzere iki katılımcı tarafından sürdürülen çok küçük sistemler bu kategoriye girecektir.

• İkinci durum - mantık iyi bilinmemektedir - nadirdir. Tüm niyet ve amaçlar için, geliştirme yinelemesi başlatılamaz bile. Bir noktada tüm paydaşlar hemfikir olursa, muhtemelen ilk durumla karşı karşıya kalacaklardır.

İnsan zihni, deneyimlerini yorumlar, onları kişisel bir çerçeveye sığdırmak için etkili bir şekilde filtreler ve değiştirir. Serbest fikir alışverişine, karşılıklı saygıya ve net beklentilere dayanan etkili geliştirme alışkanlıklarının yokluğunda, bir sistemin şu anda nasıl çalıştığına dair ekip üyeleri kadar çok yorum olabilir. Takımın mevcut geliştirme yinelemesi için hedefleri tartışmalı olabilir.

Pek çok geliştirici, kendilerinden neyin gerekli olduğu ve sistemin nasıl "düzenlenmesi" gerektiğine dair kendi benzersiz anlayışlarını güçlendirerek kendilerini bu durumdan korurlar. Öte yandan yöneticiler ve diğer paydaşlar, kendi hayatlarını kolaylaştırmak için yanlış yönlendirilmiş bir girişimde diğer ekip üyelerinin varsayımlarını farkında olmadan değiştirmeye çalışabilirler.

Artık en yaygın yazılım entropisi kaynağına ulaştık: Sistemin ifade etmeyi amaçladığı mantığın birden fazla, eksik yorumu var. Bu mantığın yalnızca tek bir tezahürü olduğundan, durum tanımı gereği sorunludur.

Bu bilgi eksikliği nasıl ortaya çıkıyor? Beceriksizlik bir yoldur. Ve daha önce gördüğümüz gibi, bir sonraki geliştirme yinelemesinin hedefleri konusunda anlaşma eksikliği de başka bir şey. Ama dikkate alınması gereken başka faktörler de var. Bir kuruluş, bir geliştirme metodolojisi kullandığını iddia edebilir, ancak daha sonra, sahadaki bazı veya tüm yönlerini gelişigüzel bir şekilde terk edebilir. Yazılım geliştiricilere daha sonra genellikle yoruma açık olan belirsiz görevleri tamamlama görevi verilir. Geliştirme metodolojilerinde değişiklik uygulayan kuruluşlar, bu fenomene karşı özellikle savunmasızdır, ancak hiçbir şekilde yalnızca onlar değildir. Yönetimin farkında olmadığı veya başka bir şekilde çözemediği kişisel çatışmalar da beklentiler ve sonuçlar arasında tehlikeli bir ayrışmaya yol açabilir.

Bir ürünle ilgili teknik bilgiyi kaybetmemizin ikinci, daha önemli bir yolu var: transferde. Teknik bilgiyi kağıt üzerinde yakalamak, en yetkin yazarlar için bile zorlayıcıdır. Bunun nedeni, neyin kopyalanacağının nasıl olduğu kadar eşit derecede önemli olmasıdır. Uygun disiplin olmadan, teknik bir yazar çok fazla bilgi kaydedebilir. Alternatif olarak, temel noktaları atlamalarına neden olan varsayımlarda bulunabilirler. Teknik belgelerin üretildikten sonra titizlikle güncel tutulması gerekir; bu, belgelerin izini neredeyse yazıldığı anda kaybeden birçok kuruluş için zor bir önermedir. Bu zorluklar nedeniyle, teknik bilgi nadiren tek başına belgelerde değil, aynı zamanda eşleştirme veya diğer yakın, insandan insana etkileşim biçimleriyle de aktarılır.

Aktif bir katılımcı bir geliştirme ekibinden ayrıldığında, yazılım entropisi sıçrama yapar. Yanlarında değerli bir bilgi birikimini götürüyorlar. Bu bilgi birikimini kopyalamak imkansızdır ve ona yaklaşmak büyük çaba gerektirir. Bununla birlikte, yeterli dikkat ve kaynaklarla, sistemin entropisinin büyümesinin en aza indirilebileceği yeterli bilgi korunabilir.

Entropi için başka kaynaklar da vardır, ancak bunlar nispeten küçüktür. Örneğin, yazılım çürümesi, bir sistemin ortamındaki değişikliklerden beklenmedik bir şekilde etkilenme sürecidir. Dayandığı üçüncü taraf yazılımları (kütüphaneler gibi) düşünebiliriz, ancak genellikle sistemin dayandığı varsayımlardaki değişikliklerden kaynaklanan yazılım çürümesinin başka, daha sinsi nedenleri vardır. Örneğin, bir sistem belleğin kullanılabilirliği ile ilgili belirli varsayımlarla tasarlanmışsa, kullanılabilir belleğin azalması durumunda beklenmedik anlarda arıza yapmaya başlayabilir.

Entropi Nasıl Hesaplanır: C, S ve I'e Değer Atama

I, vaat edilen özelliklerin yokluğu da dahil olmak üzere, bir yazılım sistemindeki çözülmemiş davranış problemlerinin sayısıdır. Bu, JIRA gibi bir sistemde sıklıkla izlenen bilinen bir miktardır. I'in değeri doğrudan ondan türetilir. I , yeni tanıtılan ve beklenmeyen davranış sorunlarından kaynaklanan iş birimlerinin sayısına ek olarak, son geliştirme yinelemesinde terk edilen veya tamamlanmayan "iş birimlerinin" sayısıdır. I bir dizi iş birimi olarak sayıldığından, bunu aynı iş birimlerinde bir sonraki geliştirme yinelemesinin kapsamı olan S değeriyle ilişkilendirebiliriz. Bir "iş birimini" tam olarak oluşturan şey, geliştirme metodolojisine bağlıdır.

C, kapsamdaki iş birimleri uygulandığında, bir sonraki yinelemede I1 fiili açık konularının sayısının şimdiki tahmininden daha büyük olacağına dair algılanan olasılıktır. Bu değer 0 <= C <= 1 etki alanında bulunur.

C olasılığının tam olarak yazılım entropisinin ölçmeyi amaçladığı şey olduğu iddia edilebilir. Ancak, bu değer ile yazılım entropisi ölçümümüz arasında temel farklılıklar vardır. Bir şeylerin yanlış gitmesine ilişkin algılanan olasılık tam olarak şudur: Bu gerçek bir değer değildir. Ancak, bir projeye katılan kişilerin duygularının, projenin ne kadar istikrarlı olduğu konusunda değerli bir bilgi kaynağı olmasında fayda vardır.

S kapsamı, önerilen değişikliklerin büyüklüğünü hesaba katar ve I ile aynı birimlerde ifade edilmelidir. Daha büyük bir S değeri, önerilen değişikliklerin kapsamını artırdığımız için entropiyi azaltır. Bu kulağa mantıksız gelse de, entropinin sistemin gelişiminin beklentilerimizi nasıl karşılayamayacağının bir ölçüsü olduğunu aklımızda tutmalıyız. Entropinin sorun yaratma şansının bir ölçüsü olduğunu söylemek yeterli değildir. Doğal olarak riskleri dener ve tahmin ederiz ve planlamamızda (ve dolayısıyla _0'ın üzerinde artabilecek olan I1 tahminimizde) hesaba katarız. Açıkça, büyük bir değişim kapsamını üstlenmekten ne kadar eminsek, sistemde o kadar az entropinin olduğu söylenebilir - değişiklikleri planlayanlar ve/veya bunları uygulayanlar yetersiz değilse. Bununla birlikte, bu olasılık muhtemelen I'in mevcut değerine yansır.

I _1'in gerçek değeri ile beklenen değeri arasındaki farkın büyüklüğünü belirlemeye çalışmamız gerekmediğine dikkat edin. Planlarımızı yaptığımızda doğru olduğunu varsayarsak, sonucun beklentilerimizi ne ölçüde karşılamayacağını tahmin edebileceğimizi varsaymak da mantıklı değildir; sadece, olmayacağına dair algılanan bir C şansını belirtebiliriz. Bununla birlikte, gerçek değer I _1'in beklenen değerinden farklılık derecesi, türetilmiş değer I şeklinde bir sonraki yinelemede entropinin hesaplanmasında önemli bir girdidir.

Teorik olarak, I'in negatif bir değere sahip olması mümkündür. Ancak pratikte bu durum hiçbir zaman oluşmayacaktır; sorunları genellikle tesadüfen çözmeyiz. I için negatif değerler rahatlatıcı bir işaret değildir. Entropinin hesaplandığı araçların kusurlu olduğunu ima ederler. Yazılım entropisinin büyümesi elbette aşağıda açıklandığı gibi belirli önlemler alınarak azaltılabilir. Ancak böyle durumlarda beklentilerimizi her zaman tasarımlarımıza dahil ettiğimiz için olumsuz değerler almamalıyım.

C subjektif bir değerdir. Bir geliştirme yinelemesinin katılımcılarının zihninde bulunur ve onları yoklayarak ve sonuçların ortalaması alınarak çıkarılabilir. Soru olumlu bir şekilde sorulmalıdır. Örneğin: "Büyük olasılıkla 10 olmak üzere 0 ila 10 arasında bir ölçekte, ekibin bu geliştirme yinelemesinde tüm hedeflerine ulaşma şansını nasıl tahmin edersiniz?"

Sorunun bir alt küme olarak değil, bir bütün olarak ekibin hedefleri hakkında sorulduğunu unutmayın. 10 yanıtı C için 0 değerini gösterirken, 7 yanıtı .3 değerini gösterir. Daha büyük ekiplerde, her yanıt, bir kişinin projede ne kadar süredir yer aldığı ve zamanlarının gerçekte ne kadarının harcandığı gibi ilgili faktörlere bağlı olarak ağırlıklandırılabilir. Bununla birlikte, yeterlilik, yanıtların ağırlıklandırılmasında bir faktör olmamalıdır. Çok geçmeden, ekibin genç bir üyesi bile hedeflerine ulaşmada ne kadar etkili olduğunu anlayacaktır. Yeterince büyük takımlar, kalanın ortalamasını almadan önce rapor edilen en yüksek ve en düşük değerleri atmak isteyebilir.

Profesyonellere ekiplerinin başarısız olma ihtimalinin ne olduğunu sormak hassas ve kışkırtıcı bir tekliftir. Ancak, entropiyi ölçmek isteyen herhangi bir organizasyonun sorması gereken soru tam olarak budur. Dürüst yanıtlar vermek için, katılımcılar son derece yüksek bir değer bildirmiş olsalar bile, C tahminlerini isimsiz olarak ve yankı korkusu olmadan vermelidirler.

S'ye, I ile aynı “çalışma birimlerinde” bir değer atanmalıdır ve bu nedenle geliştirme metodolojisine büyük ölçüde bağımlıdır. Çevik metodolojinin özelliklerini kullanan ekipler için hikayeler, hem S hem de I için en bariz “çalışma birimi” gibi görünüyor. Bu durumda, bir geliştirme yinelemesinin kapsamı, küçük veya büyük olmak üzere, düzenli olarak programlanan her bir üretim sürümünü kapsar. Yayınlanmadan önce her bir sprint sırasında başarıyla tamamlanmayan öykülerin sayısı ile yayından sonra ortaya çıkan beklenmedik sorunların bir sonucu olarak gelecekteki sprintlere dahil edilmek üzere oluşturulan öykülerin sayısı olarak ölçülmelidir.

Üretime yönelik düzeltmeleri veya diğer programlanmamış sürümleri bir geliştirme yinelemesinin kapsamını tanımlayan olarak kabul etmediğimizi ve ilişkili öyküleri I öğesinden çıkarmamamız gerektiğini unutmayın.

Bu yaklaşımın zorluğu, hataların daha sonra hikayelere ayrılabilmesi için bir keşif ve analiz döneminin gerçekleşmesi gerektiğidir. Bu nedenle I'nin gerçek değeri ancak bir gecikmeden sonra tanımlanabilir. Ek olarak, C için yoklama, her sprintin başlangıcında doğal olarak gerçekleşir. Bu nedenle elde edilen sonuçların bir kez daha tüm salım süresi boyunca ortalaması alınmalıdır. Bu zorluklara rağmen, bir Çevik metodolojinin özelliklerini kullanan herhangi bir ekip, hikayelerin S (ve dolayısıyla I ) niceliğini ölçmek için en doğru birim olduğunu bulması muhtemeldir.

Günümüzde kullanılan başka geliştirme metodolojileri de vardır. Kullanılan metodoloji ne olursa olsun, yazılım entropisini ölçmek için ilkeler aynı kalır: Yazılım entropisi üretime kadar olan sürümler arasında ölçülmelidir, S ve I aynı “iş birimlerinde” ölçülmelidir ve C tahminleri doğrudan katılımcılardan alınmalıdır. tehdit edici olmayan ve tercihen anonim bir şekilde.

E'nin Büyümesini Azaltmak

Bir sistem hakkındaki bilgi bir kez kaybedildiğinde, bir daha asla geri alınamaz. Bu nedenle yazılım entropisi azaltılamaz. Yapabileceğimiz tek şey büyümesini dizginlemek.

Entropinin büyümesi, yazılım geliştirme sırasında uygun önlemler alınarak sınırlandırılabilir. Çevik geliştirmenin ikili programlama yönü bu açıdan özellikle yararlıdır. Kodun yazıldığı sırada birden fazla geliştirici dahil olduğundan, temel ayrıntılara ilişkin bilgi dağıtılır ve ayrılan ekip üyelerinin etkileri hafifletilir.

Bir başka yararlı uygulama, özellikle şelale metodolojisi kullanan kuruluşlarda, iyi yapılandırılmış ve kolayca tüketilen belgelerin üretilmesidir. Bu tür belgeler, herkes tarafından anlaşılan katı ve iyi tanımlanmış ilkelerle desteklenmelidir. Temel bir iletişim aracı olarak belgelere güvenen ve teknik bilgiyi koruyan kuruluşlar bu yaklaşım için çok uygundur. Yalnızca dahili olarak yazılmış belgelerin nasıl yazılacağına ve tüketileceğine ilişkin hiçbir yönerge veya eğitim olmadığında - RAD veya Çevik metodolojileri kullanan genç kuruluşlarda sıklıkla olduğu gibi - bunların değeri şüpheli hale gelir.

Bir sistemdeki entropinin büyümesini azaltmanın iki yolu vardır: I'yi azaltmayı amaçlayan değişiklikleri yürütün veya C'yi azaltmaya yönelik değişiklikleri uygulayın.

İlki yeniden düzenlemeyi içerir. I'i azaltmayı amaçlayan eylemler, doğası gereği teknik olma eğilimindedir ve muhtemelen okuyucuya zaten aşinadır. Bir geliştirme yinelemesi gerçekleşmelidir. Bu yinelemenin entropi büyümesini azaltmayı amaçlayan kısmı, zaman ve kaynak tüketirken herhangi bir somut ticari fayda sağlamayacaktır . Bu gerçek, genellikle entropinin büyümesini azaltmayı herhangi bir organizasyon içinde zor bir satış haline getirir.

Etkisi daha uzun vadeli olduğu için C'nin değerini azaltmak daha güçlü bir stratejidir. Ek olarak, C, I'nin S'ye oranının büyümesi üzerinde önemli bir kontrol görevi görür. C'yi azaltmaya yönelik eylemler, insan davranışına ve düşüncesine odaklanma eğilimindedir. Bu eylemler başlı başına bir geliştirme yinelemesi gerektirmese de, katılımcılar yeni prosedürleri kabul edip bunlara uyum sağladıkça sonraki yinelemeleri yavaşlatacaktır. Görünüşte basit olan hangi iyileştirmelerin yapılması gerektiği üzerinde anlaşmaya varmak, proje katılımcılarının ve paydaşlarının farklı hedefleri aniden ortaya çıktıkça, kendi tehlikeleriyle dolu bir yoldur.

Toplama

Yazılım entropisi, mevcut yazılımı değiştirmenin beklenmeyen sorunlara, karşılanmayan hedeflere veya her ikisine birden yol açması riskidir.

Yazılım ilk oluşturulduğunda ihmal edilebilir olsa da, yazılım entropisi her geliştirme yinelemesinde artar. Kontrolsüz devam etmesine izin verilirse, yazılım entropisi sonunda daha fazla gelişmeyi durduracaktır.

Ancak, her proje yazılım entropisinin etkilerini hesaba katmamalıdır. Entropi gözle görülür ve zararlı etkiler ortaya koymadan önce birçok sistem üretimden kaldırılacaktır. Yaşamları entropi inandırıcı bir risk oluşturacak kadar uzun olanlar için, bunun için bir farkındalık yaratmak ve kapsamını ölçmek, hala düşük olsa da, gelişimin erken kesilmemesini sağlamak için bir araç sağlar.

Bir sistem yazılım entropisinin etkileriyle tamamen boğulduğunda, artık hiçbir değişiklik yapılamaz ve geliştirme esasen sona ermiştir.