Yazılım test metodolojisi hatalı verilere dayanıyor mu?

Yazılım mühendisliğinde bilinen ve bilinen bir gerçektir, bir hatayı düzeltme maliyetinin daha sonra bu hatanın keşfedilmesi halinde katlanarak artması. Bu, Kod Tamamlama'da yayınlanan ve diğer birçok yayına adapte edilmiş verilerle desteklenir .

Ancak, bu verilerin hiçbir zaman var olmadığı ortaya çıktı . Code Complete tarafından belirtilen veriler görünüşte böyle bir maliyet / gelişme zamanı korelasyonu göstermez ve yayınlanmış benzer tablolar sadece bazı özel durumlarda korelasyonu ve diğerlerinde düz bir eğri gösterir (yani maliyette artış olmaz).

Bunu onaylayacak ya da çürütecek bağımsız veriler var mı?

Ve eğer doğruysa (yani, geç keşfedilen böcekler için bu üssel olarak daha yüksek maliyeti destekleyen hiçbir veri yoksa ), bu yazılım geliştirme metodolojisini nasıl etkiler?

Yazılım test metodolojisi hatalı verilere dayanıyor mu?

Evet, görünüşte. Çevik Değişim Maliyeti Eğrisini incelemek, Kent Beck’in XP’deki çalışmalarının bir kısmının (motivasyonunun ya da gerekçesinin bir parçası olup olmadığından emin değilim) bilgisine dayanarak “maliyetlerin eğrisini” düzeltmek olduğunu gösteriyor Üstel "Code Complete tablosunun arkasında yatan eğri. Bu yüzden evet, en azından bir yöntem üzerinde çalışın - test-ilk gelişimini yaygınlaştırmak için en iyisini yapan - en azından kısmen hatalı verilere dayanıyor.

Bunu onaylayacak ya da çürütecek bağımsız veriler var mı?

Evet, kesinlikle arayabileceğiniz başka veriler var - farkında olduğum en büyük çalışma, CMM değerlendirme programlarının bir parçası olarak Hughes Uçağında yapılan hataların analizi . Oradaki rapor, kusur maliyetlerinin onlar için nasıl bir aşamaya bağlı olduğunu gösterir : bu rapordaki veriler farklılıklar içermemesine rağmen, “bu şey o şeyden daha pahalı” sonuçlarına varmaktan kaçınmanız gerekir. Ayrıca, metodolojiden bağımsız olarak, 1980'lerle bugün arasında bu verilerin önemini sorgulayan araçlar ve tekniklerde değişiklikler olduğunu fark etmelisiniz.

Öyleyse, bu rakamları haklı çıkarmaya devam ettiğimizi varsayalım:

Bu, yazılım geliştirme metodolojisini nasıl etkiler?

Doğrulanamayan sayılara güvenmemiz gerçeği, insanların anekdotlar ve deneyimlere dayanarak ilerleme kaydetmelerini engellemedi: aynı şekilde birçok usta-çırak esnafının öğrenildiği şekilde. Orta çağda Kanıt Temelli Bir Duvarcılık olduğunu sanmıyorum , ancak yine de büyük, etkileyici ve uzun ömürlü binaların bir kısmı gözle görülür bir başarı ile inşa edildi. Bunun anlamı, esas olarak pratiğimizi “benim için neyin ya da tanıştığım insanlara çalıştığımız”; kötü bir şey değil, ama belki de şu anki teknolojik çağın temel taşını oluşturan milyonlarca insanı geliştirmek için en etkili yol değil.

Sözde bir mühendislik disiplininin ampirizmde daha iyi bir temeli olmadığını hayal kırıklığına uğrattığımı ve tekniklerimizi ve metodolojilerimizi iyileştirme konusunda daha iyi ve net ilerleme sağlayabileceğimizi (açıkça kanıtlayamamamdan şüpheleniyorum) Bu vakıf yerinde - tıpkı klinik tıp tıpının kanıta dayalı uygulamalarla dönüştürüldüğü gibi. Bu da bazı büyük varsayımlara dayanıyor:

• çoğu yazılım mühendisliği uygulamasının tescilli niteliğinin, yeterince faydalı ve ilgili verilerin toplanmasını engellemediğini;
• bu verilerden çıkarılan sonuçların genel olarak uygulanabilir olduğu (yazılım mühendisliği yetenekli bir meslektir, çünkü deneyim, yetenek ve zevkteki kişisel farklılıklar bu uygulanabilirliği etkileyebilir);
• "sahadaki" yazılım mühendislerinin bu şekilde elde edilen sonuçlardan yararlanmaya istekli ve motive olduklarını; ve
• Aslında ilk başta hangi soruları sormamız gerektiğini biliyoruz. Açıkçası buradaki en büyük nokta şudur: yazılım mühendisliğini geliştirmek hakkında konuştuğumuzda , geliştirmek istediğimiz şey nedir? Ölçüm nedir? Bu ölçümü geliştirmek sonucu gerçekten iyileştiriyor mu, yoksa sistemi mi oynuyor? Örnek olarak, şirketimdeki yönetimin gerçek proje maliyeti ile öngörülen proje maliyeti arasındaki oranı düşüreceğimize karar verdiğini varsayalım. Tüm maliyet tahminlerimi geçiştirici bir faktörle çarpmaya başlayabilirim ve bu "hedefe" ulaşırdım. Tüm tahminleri almak için standart endüstri uygulaması olmalı mı?

Benim açımdan "Bu, yazılım geliştirme metodolojisini nasıl etkiliyor?" Cevabı "fazla değil".

Geliştirici veya son kullanıcı tarafından yakalanıp yakalanmadığı, kullanıcı tarafından yakalandıktan sonra onu düzeltmek için daha fazla para harcarsa da, bir hatanın sistemde bulunduğu gerçeği devam etmektedir. Geliştirici tarafından yakalandıysa, umarım hızlı bir çözümdür. Aynı umut, kullanıcı tarafından yakalanan hatalar için de geçerlidir.

Son kullanıcı tarafından yakalanan bir hatayı düzeltmek için gerçek geliştirici-saat maliyetine bakılmaksızın, kodlayıcıların yaptıklarını emdikleri stereotipi korumanın maddi olmayan maliyeti vardır. Bir kullanıcı bir hata bulduğunda, geliştiricinin hatasıdır. Bu nedenle, son kullanıcının bulduğu her hata kullanıcının sisteme olan güvenini azaltır. Satın almak istediğiniz bir evi gezmek ve evin bir köşesinde tavandan geçen bir su lekesi görmek gibidir. Bu, kendi başına kolay bir düzeltmedir, ancak neden buna neyin sebep olduğunu ve bu kök nedenin başka neleri etkilediğini merak ediyorsunuz. İç huzurunun değeri nedir? Duvarları saplamalardan aşağıya doğru yırtıp lekenin sabitlenmiş izole bir olaydan geldiğinden emin olmak için her şeyi görsel olarak incelemeniz gerekebilir. Bunun bir olasılık olabileceğini bilmek seni eve çok güvenmiyor. Benzer şekilde,

Bu maddi olmayan maliyetler, TDD tarzı metodolojilerin belirtilen amacı olan böcek yakalanır yakalanmaz önlenir. Bir geliştirici veya ortak tarafından, bir derleme sırasında veya bir birim / entegrasyon testine (TDD tarafından eklenen katman) yakalanan biri, TDD'nin eklediği katman) yazarken yakalanan bir hata, kullanıcının asla bilmemesi gereken bir hatadır. Proje yöneticisi asla özür dilemek zorunda kalmaz ve bu hafta içinde ne yaptığınızdan, çekiciyi geride bıraktığınızı düşündüğünüz bir sistemde arıza tespit moduna geçirmek için ne yapmanız gerektiğinden çekinmeniz gerekmez. önce.

Bu konunun çoğunu 1970'lerden ve 1980'lerin başlarından geldiği gerçeğiyle ortaya çıkaracağım. Bu süre zarfında, sıralı işlem modelleri, yinelemeli ve / veya artımlı yaklaşımlardan (Spiral model veya çevik yöntemler) çok daha yaygındı. Bu çalışmanın çoğu bu ardışık modeller üzerine kuruludur. Bununla birlikte, ilişkinin zarar verdiğini sanmıyorum, ancak yinelemeli / artımlı yaklaşımların faydalarından biri, bağımlılıklar enjekte edilmeden ve her bir fazın karmaşıklığından önce, özellikleri (bir uygulamanın dikey bir dilimi) serbest bırakmak ve bunun içindeki sorunları düzeltmektir. yüksektir.

Sadece benim kopyasını çıkardı Yazılım Mühendisliği İktisadi ve O ME Fagan (tarafından "Tasarım ve Kod Denetimler Programı Geliştirmede Hataları Azaltmak İçin" değinir 4. Bölümde bu grafikle arkasında verilere başvuru buldum IEEE , UMD PDF ), EB Daly'nin "Yazılım Mühendisliği Yönetimi", WE Stephenson'ın "Koruma Sistem Yazılımı Geliştirmede Kullanılan Kaynakların Bir Analizi" ( ACM ) ve "birkaç TRW projesi".

... düzeltmelerin veya değişikliklerin yapıldığı fazın bir fonksiyonu olarak yazılım hatalarını düzeltme maliyetinin (veya başka yazılım değişikliklerinin yapılmasının). Bir yazılım gereksinimleri hatası planlar ve gereksinimler aşamasında algılanır ve düzeltilirse, düzeltilmesi gereksinim belirtiminin güncellenmesi nispeten basit bir konudur. Aynı hata, bakım aşamasına kadar düzeltilmezse, düzeltme çok daha büyük bir spesifikasyon envanteri, kod, kullanıcı ve bakım kılavuzları ve eğitim materyali içerir.

Ayrıca, geç düzeltmeler, çok daha resmi bir değişiklik onayı ve kontrol sürecini ve düzeltmeyi yeniden doğrulamak için çok daha kapsamlı bir faaliyet içerir. Bu faktörler, hatayı büyük projelerdeki bakım safhasında düzeltmek için gereksinim safhasına göre genellikle 100 kat daha pahalı yapmak için bir araya gelir.

Bohem ayrıca iki küçük, daha az resmi projeye baktı ve maliyeti artırdı, ancak daha büyük projelerde belirlenen 100 kattan çok daha az önemliydi. Grafik göz önüne alındığında, sistem operasyonel olduktan sonra bir şartlar arızasını gidermek için farklar 4 kat daha büyük görünmektedir. Bunu, projeyi oluşturan daha küçük ürün envanterine ve daha basit bir şekilde daha hızlı sabitleme yeteneğine yol açan düşük formaliteye bağladı.

Yazılım Mühendisliği Ekonomisindeki Boehm'e göre, Kod Tamamlama'daki tablo oldukça şişirilmiş (aralıkların düşük ucu genellikle çok yüksek). Aşama dahilinde herhangi bir değişiklik yapmanın bedeli aslında 1. Yazılım Mühendisliği Ekonomisinde Şekil 4-2'den yapılan ekstrapolasyonda, gereksinim değişikliği mimaride 1,5-2,5 kat, kodlamada 2,5-10, testte 4-20 ve 4 olmalıdır. 100 bakımda. Miktar, projenin boyutuna ve karmaşıklığına ve kullanılan sürecin formalitesine bağlıdır.

Barry Boehm ve Richard Turner'ın Dengeleme Çevikliği ve Disiplini'nin Ek E bölümünde değişimin maliyeti ile ilgili ampirik bulgular hakkında küçük bir bölüm bulunmaktadır.

Açılış paragrafları, Beck'in alıntı yaptığı Kent Beck'in Extreme Programming Explained'a atıfta bulundu. Değişikliklerin maliyeti zaman içinde yavaşça artarsa, kararların mümkün olduğunca geç alınacağını ve sadece ihtiyaç duyulanın uygulanacağını söylüyor. Bu "düz eğri" olarak bilinir ve Extreme Programming'i yönlendiren şeydir. Bununla birlikte, önceki literatürün bulduğu şey "dik eğri" idi, 5: 1 değişikliğe sahip küçük sistemler (<5 KSLOC) ve 100: 1 değişikliğe sahip büyük sistemler.

Bu bölüm, Maryland Üniversitesi'nin (Ulusal Bilim Vakfı sponsorluğunda) Ampirik Tabanlı Yazılım Mühendisliği Merkezi'ni içermektedir. Elde edilebilir bir literatür taraması yaptılar ve sonuçların 100: 1 oranını onaylama eğiliminde olduklarını ve bazı sonuçların 70: 1 ila 125: 1 arasında olduğunu gösterdi. Ne yazık ki, bunlar tipik olarak "büyük tasarım ön" projelerdi ve sıralı bir şekilde yönetiliyorlardı.

Extreme Programming kullanılarak çalıştırılan "küçük ticari Java projeleri" örnekleri var. Her Öykü için, hata düzeltme, yeni tasarım ve yeniden düzenleme çalışmalarındaki çaba izlendi. Veriler, sistem geliştikçe (daha fazla kullanıcı öyküsü uygulandığında), ortalama çabanın önemsiz bir oranda artma eğiliminde olduğunu göstermektedir. Yeniden yapılanmadaki çaba yaklaşık% 5 artar ve çaba sağlama çabaları yaklaşık% 4 artar.

Öğrendiğim şey, sistem karmaşıklığının gereken çaba miktarında büyük bir rol oynadığı. Sistemin içine dikey dilimler oluşturarak, eğri hızını yığınlara eklemek yerine yavaşça karmaşıklık ekleyerek yavaşlatırsınız. İhtiyaçların kitlesel karmaşıklığı ile uğraşmak yerine, ardından son derece karmaşık bir mimari izler, ardından son derece karmaşık bir uygulama izler, vb. Çok basit bir şekilde başlar ve eklersiniz.

Bunun onarım maliyeti üzerindeki etkisi nedir? Sonunda, belki fazla değil. Bununla birlikte, karmaşıklık üzerinde daha fazla kontrole izin verme avantajları vardır (teknik borç yönetimi yoluyla). Buna ek olarak, genellikle çeviklikle ilişkili sık teslimler, projenin daha erken biteceği anlamına gelir - "sistemi" teslim etmek yerine, iş ihtiyaçları tatmin olana veya yeni bir sistemin (ve dolayısıyla yeni bir projenin) ciddi şekilde değişmesine kadar parçalar teslim edilir. gereklidir.

Stephen Kan'ın Yazılım Kalitesi Mühendisliğindeki Metrikleri ve Modelleri, Bölüm 6'da faz hatası gideriminin maliyet etkinliği ile ilgili bir bölüme sahiptir.

Yüksek seviye tasarım (sistem mimarisi), düşük seviye tasarım (ayrıntılı tasarım) ve uygulamanın 10 ila 100 kat daha ucuz olabileceğini belirtmek için Fagan'ın 1976 makalesini (Yazılım Mühendisliği Ekonomisi'nde de bahsedilmiştir) atıfta bulunarak başladı. bileşen ve sistem seviyesi testi sırasında yapılan çalışmalardan daha fazla.

Ayrıca Freedman ve Weinberg tarafından büyük sistemleri tartışan 1982 ve 1984'ten iki yayına da yer veriyor. Birincisi "Gözden Geçmeler, İncelemeler ve Teknik İncelemeler El Kitabı" ve ikincisi "Gözden Geçirme, Yürütmeler ve İncelemeler" dır. Gözden geçirme sürecinin başlarında incelemelerin uygulanması, test aşamasına ulaşan hata sayısını 10'luk bir faktörle azaltabilir. Hata sayısındaki bu azalma, test maliyetlerinin% 50 ila% 80 oranında azalmasına neden olur. Çalışmaları daha ayrıntılı okumak zorunda kalacağım, ancak maliyetin kusurları bulma ve çözmeyi de içerdiği anlaşılıyor.

1982'de Remus tarafından yapılan "İnceleme / İnceleme Açısından Bütünleşik Yazılım Doğrulama" adlı bir araştırma, IBM'in Kaliforniya'daki Santa Teresa Laboratuarı'ndan gelen verileri kullanarak, özellikle farklı aşamalardaki kusurları gidermenin maliyetini araştırdı. Alıntılanan sonuçlar, 1:20:82 maliyet oranını göstermektedir. Diğer bir deyişle, tasarım veya kod denetimlerinde bulunan bir kusurun değiştirme maliyeti 1'dir. Aynı kusur testten kaçarsa, 20 kat daha pahalı olur. Bir kullanıcıya tamamen çıkarsa, düzeltilmesi gereken maliyeti 82'ye kadar katlar. Kan, IBM'in Rochester, Minnessota tesisindeki örnek verileri kullanarak, AS / 400 projesinin kusur giderim maliyetinin benzer olduğunu buldu. 1:13:92 Bununla birlikte, maliyetteki artışın bir kusur bulma zorluğundan kaynaklanabileceğini de belirtti.

Yazılım incelemesine ilişkin Gilb'in 1993 ( "Yazılım Denetimi" ) ve 1999 ("Yazılım Mühendisliği Şartnamesi ve Kalite Kontrol Süreçlerini Optimize Etme") yayınlarında diğer çalışmaları onaylamak için bahsedilmiştir.

Construx'un Arıza Maliyet Artışı hakkındaki sayfasında, onarım onarım maliyetindeki artışla ilgili bir takım referanslar sağlayan ek bilgiler bulunabilir . Code Complete'in yazarı Steve McConnell'in Construx için kurduğu ve çalıştığı unutulmamalıdır.

Geçenlerde , 2010'da Lone Star Ruby Konferansında Glenn Vanderburg tarafından verilen Real Software Engineering (Gerçek Yazılım Mühendisliği) adlı bir konuşmayı dinledim. Aynı konuşmayı 2011'de Scottish Ruby Konferansı ve Erubycon , 2012'de QCon San Francisco ve O'Reilly Yazılım Mimarisi Konferansı'nda verdi. 2015 yılında . Sadece Lone Star Ruby Konferansı'nı dinledim, ancak fikirleri rafine edildiğinde konuşma zaman içinde gelişti.

Venderburg, tüm bu tarihsel verilerin hepsinin, bir proje aşamalarında ilerledikçe, zaman içerisinde ilerledikçe hataları düzeltme maliyetini gösterdiğini öne sürüyor. Daha önce belirtilen kağıtlarda ve kitaplarda incelenen projelerin çoğu, faz ve zamanın birlikte hareket ettiği sıralı "şelale" projeleriydi. Bununla birlikte, benzer bir örnek yinelemeli ve artımlı projelerde ortaya çıkar - bir yinelemeye bir kusur enjekte edildiyse, bu yinelemede düzeltmek nispeten ucuz olacaktır. Bununla birlikte, yinelemeler ilerledikçe, birçok şey olur - yazılım daha karmaşık hale gelir, insanlar belirli modüllerde veya kodun bazı bölümlerinde çalışma ile ilgili bazı küçük ayrıntıları unuturlar, gereksinimler değişir. Bunların hepsi, arızayı düzeltme maliyetini artıracak.

Bunun muhtemelen gerçeğe daha yakın olduğunu düşünüyorum. Bir şelale projesinde, yukarı havza problemi nedeniyle düzeltilmesi gereken yapay eserlerin miktarı nedeniyle maliyet artar. Yinelemeli ve artımlı projelerde, yazılımdaki karmaşıklığın artması nedeniyle maliyet artar.

Sadece basit bir mantık.

Spesifikasyonda hata tespit edildi.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Daha sonra görebildiğiniz gibi, hata tespit edildiğinde, daha fazla insan katılıyor, daha fazla iş yeniden yapılmalı ve herhangi bir "normal" ortamda, kağıt işi ve bürokrasi, UAT'ye çarptığınızda katlanarak artar.

Bunların hepsi, bir üretim yazılımındaki bir hata nedeniyle bir işletmenin yapabileceği maliyetleri içermez (satışların azalması, siparişlerin verilmesi, müşterilerin hacklenmesi vb.).

Hiç kimsenin, üretimde hiç hata yapmayan, önemsiz olmayan bir sistem yazmayı başarabileceğini sanmıyorum, ancak böcekleri erken yakalamak için yapabileceğiniz herhangi bir şey, uzun vadede zamandan ve emekten tasarruf etmenizi sağlayacaktır. Spesifikasyon incelemeleri, kod incelemeleri, kapsamlı birim testleri, testleri yazmak için farklı kodlayıcılar vb. Kullanılması, tüm hataları erken yakalamak için kanıtlanmış yöntemlerdir.

Bunun risk yönetimi ve ekonomi ile ilgili olduğuna ve her zaman olduğuna inanıyorum. Gelecekteki kusurların etkisinin bugünkü değeri ile kusur sayısını azaltmanın maliyeti nedir. Angry Birds'te sarı kuşun yörüngesinin hafifçe kapalı olması, Tomahawk seyir füzesinin yörüngesinin kapalı olması ile aynı değildir. Her iki projedeki yazılım geliştiriciler bu tabloya dayanarak karar veremezler. Bu bakımdan hiçbir şey değişmez.

Bunun çalışma eğiliminde olduğunu düşünüyorum, geri bildirim yoluyla, sahadaki pahalı böcekler, şirketlerin kalite süreçlerini sıkılaştırmasına neden olurken, sahadan gelen hiçbir şikayet firmaların rahatlamasını sağlamıyor. Bu yüzden zamanla yazılım geliştirme şirketleri kendileri için uygun bir şey etrafında birleşme veya salınım yapma eğiliminde olacaktır (+/-). Kod Tamamlama bazı başlangıç ​​değerlerini etkileyebilir veya şirketleri bir şekilde veya başka bir yere çekebilir. Çok fazla çaba harcayan bir şirketi, kimsenin farketmeyeceği kusurlarını muhtemelen daha iyi bir yaklaşıma sahip olan bir rakiple iş kaybedecek. Öte yandan, buggy ürünlerini piyasaya süren bir şirket de işsiz kalacak.

Hızlı bir aramayla ilgili bazı makaleler (makalelerin tamamını okuyun, daha fazla araştırma yapın ve kendi fikrinizi oluşturun):

Yazılım Kalitesi Maliyet Araştırmalarında Sistematik Bir Edebiyat İncelemesi (2011)

“Topluluk böylece araştırma alanının yapısı hakkında sağlam bir anlayış geliştirmiş olsa da, ampirik validasyon genellikle yoksundur. Yeni bulgular üretmek için nicel verilere kuvvetli bir şekilde dayanmaktadır. Bu nedenle, kaliteli maliyet verilerini toplamak için yeni yaklaşımların yanı sıra, bu verileri elde etmek için endüstri ile araştırma arasında daha güçlü bir işbirliğine ihtiyaç duyulmaktadır. ”

Yazılım Kalitesi Maliyetini Değerlendirme (1998)

"Son olarak, yazılım uygunluğunu ve uygunsuzluk maliyetlerini izlemenin önemli olduğunu gördük, böylece uygunluk politikaları yazılım kalitesinin toplam maliyetini azaltmak için ayarlanabildi."

Yazılım kusurlarının maliyet davranışı (2004)

Özet ... "Mevcut araştırma, kusurların nasıl giderildiği ve düzeltilme masraflarının (veya alternatif olarak onları düzeltilmeden bırakma) hakkındaki bilgilerimizi güncellemeye çalışmaktadır. çözülmediği her aşamada "

Test Kapsamı ve Doğrulama Sonrası Kusurlar: Çoklu Bir Vaka Çalışması (2009)

"Ayrıca, test çalışmalarının test kapsamı ile katlanarak arttığını, ancak saha sorunlarındaki azalmanın test kapsamı ile doğrusal olarak arttığını tespit ettik. Bu, çoğu proje için en iyi kapsam seviyelerinin% 100'ün çok altında olabileceğini gösteriyor."

Yazılım Test Süreci ve İş Değeri Arasındaki Boşluğu Kaldır: Bir Vaka Çalışması (2009)

Kontrol etmediğim için sorunun ilk kısmına cevap veremem. Ancak, ikinci sorunuza bir cevap oluşturabilir ve belki de ilkine olası bir cevaba işaret edebilirim.

Bir hatayı düzeltme, geliştirme araçlarını kullanmanın zorluğunu engellemenin maliyetindeki bazı önemli faktörlerin, ürünün kendine özgü karmaşıklığı olduğunu ve kullanıcının bu ürünü ne kadar iyi anlayabileceğini söylemeden geçmelidir.

Bir an için koda odaklanarak, kodun tipik olarak (tamamen doğru olmayabilir ve kendi tartışmasını hakedebilecek olan) kodlarının içsel karmaşıklıkları ile başa çıkabilen geliştiriciler tarafından yazıldığını ve muhafaza edildiğini varsayarsak, bakımda ve dolayısıyla hataları gidermede kritik öneme sahipler, söz konusu kodu anlama yeteneğidir .

Kodu anlama yeteneği, ne yazık ki, çoğunlukla yetersiz veya yanlış kullanılan, kanıtlanmış yazılım mühendisliği araçlarının kullanımıyla büyük ölçüde geliştirilmiştir. Doğru soyutlama seviyesini kullanmak, modülerlik, modül uyumunu arttırmak ve modül kuplajını azaltmak, uygun kullanım gerektiren karmaşıklıkla başa çıkmada kritik araçlardır. Arayüzlere kodlama veya OOP'de, bileşime göre kalıtımın aşırı kullanımından kaçınılması, özelliğe göre ambalajlanması, kodlamada genellikle yetersiz dikkat verilen tekniklerden bazılarıdır.

Endüstride rekabetin gerçekliğinin, yazılım geliştirme konusunda kaliteyi artırıcı yöntemlerin kullanılmasına olumsuz bir etki getirdiğine ve devam eden başarının bir ölçüsü olarak yazılımın gerçek kalitesini düşürdüğüne inanıyorum.

Sonuç olarak, sektörde, yazılımın büyüdükçe hata onarım maliyetlerinden daha fazla acı çekme eğiliminde olduğuna inanıyorum. Bu tür ürünlerde, zamanla sabitlemesi zorlaşır, çünkü sistem büyüdükçe anlaşılması zorlaşır. Her özelliğin getirdiği endişeler diğer endişelerle fazlasıyla bağlantılıdır ve anlaşılabilirliği zorlaştırır. Veya, doğru soyutlama seviyesi kullanılmamıştır, bu da bakımcının sisteme uygun bir model ve bunun nedenini oluşturmasını zorlaştırmaktadır. Belge eksikliği kesinlikle yardımcı olmuyor.

İstisnalar var. Eminim Google, yıldız geliştiricileri tarafından onaylanan bazı katı uygulamalar olmadan kendi hızında çalışmadığından eminim. Ve diğerleri aynı durumda muhtemeldir. Veri Ama eğer yazılımın büyük bir kısmı için, ben sürpriz olmaz did iddiası gerçeği ortaya konan Kod tamamlamak .

Başka bir Cevap! Bu başlık, "Morhtodoligy'nin hatalı verilere dayandığını gösterir" başlıklı soruyu ele almaktadır.

Asıl cevap "veri yok". Orada olduğu gibi, yazılım projeleri hakkındaki güvenilir veri kütlelerinin olmadığı gibi, kusurlu, pazara girme zamanı vb.

Bu tür verileri toplamak için yapılan tüm girişimler yetersiz finanse edildi, istatistiksel olarak kusurlu veya özel bir projeye özgü olduğu için genel sonuç çıkarmanız mümkün değil.

Ayrıca, asla olacağını sanmıyorum, yazılım geliştirme süreci çok öznel ve katı bir ölçüm için kaygan. Bu tür verileri toplamak için en iyi yerleştirilen kuruluşlar (büyük yazılım evleri ve sistem entegratörleri) yüreklerinde performanslarından toplanan rakamların çok utanç verici olacağını biliyor.

Yazılım projelerinin maliyeti ve başarısı ile ilgili sayıları yayınlayan tek kuruluşlar
devlet daireleridir ve ancak o zaman mecbur oldukları için, ve evet, bu sayılar rakamlara ne kadar masaj yapsalar da çok utanç vericidir.

Sonuç olarak, tüm yazılım çalışmaları tamamen özneldir çünkü nesnel bir sonuca dayandırılacak gerçek bir veri yoktur.