Hangi hataların en büyük maliyet avantajını sağlayacağını çözmek [kapalı]

Hataları çözmenin ne kadar kolay olduğuna ve bana ne kadar fayda sağlayacağına göre kategorize etmek hakkında bir fikir edinmek istedim. örneğin, bir günü (bir kaç dosya kapanması vb.) çözecek bir hata varsa, bir gün süren başka bir çözüme karşı (segmentasyon hatası). Ama ilk hatayı çözmek çok önemli değilse, muhtemelen ikincisi üzerinde çalışacağım.

Hataları maliyet-fayda ya da benzer metriğe göre sınıflandıran araştırma makaleleri var mı?

Hataları, güvenlik açığı, bellek hatası, mantık hatası vb. Gibi hata özelliklerine göre sınıflandırmanın mümkün olduğunu varsayalım. Diğer boyutta zorluk (kolay, orta, zor) gibi parametreler olabilir. Aramam gereken başka boyutlar var mı? Bir şeyi basitleştirmek için iki şeyi varsayabilirim:

1. Takımdaki her programcı herhangi bir hatayı çözebilir
2. Son tarih yok

Tipik hata izleme sistemi, hata maliyeti fayda oranını tanımlayan iki, belki üç alana sahiptir:

1. Öncelik (işletme sahibi tarafından atanır)
2. Önem derecesi (hatanın sınıflandırılması - kritik önemden düşük seviyeye)
3. Tahmini saatler (ne kadar süreceğini tahmin)

Belirttiğiniz gibi, bu, hangi hatanın üzerinde çalışılması gerektiğini belirler.

PEF / REV'de ortaya konan sistem : Çok Boyutlu bir hata izleme metriği , maliyet avantajı sağlamak için işletme ve geliştirici bileşenleri hakkında daha fazla bilgi ekler.

Tüm değerler 1 .. N ölçeğindedir (her biri için aynı üst değer).

PEF işletme tarafından tanımlanır:

• P ain - Böcek ne kadar acı verici
• E ffort - Böcek etrafında çalışmak için ne kadar çaba gerekiyor
• F gereksinimi - Hata ne sıklıkta görülür?

REV geliştiriciden geliyor:

• R isk - Sistemin çözümü ne kadar riskli
• E ffort - Hatayı düzeltmek için ne kadar çaba var
• V erifiability - Hata düzeltmesini doğrulamak ne kadar kolay

Örneğin, kolayca çözülebilen (otomatik kaydetmeyi aç) nadiren gerçekleşen bir çöküşünüz varsa, bu 7,1,1'lik bir PEF olabilir (puan 9). Sabitleme sırasında bir çekirdek modülde bir değişiklik içerebilir ve REV değeri 9,3,2 (skor 14) olabilir.

Öte yandan, her zaman var olan (3,3,9 - skor 15), önemsiz bir düzeltmeye sahip olan (1,1,3 - skor 5) bir sıkıntı olabilir.

Bu örnekte, rahatsızlık üzerinde çalışmak için daha iyi bir maliyet / fayda şeyidir.

Tanımladığınız sorun çok yaygındır ve en iyi yanıt "bağırsak duygularınızı kullanın" olabilir.

Genellikle hataları üç kategoriye ayırırım: Çökme, Sinir bozucu, Kozmetik (1, 2, 3 olarak adlandırılabilirler - bu gerçekten önemli değil) ve daha sonra her hatayı düzeltmek için gereken süreye genel bir tahmin koydu (tüm hatalar kabaca güncellenmiş bir tahmininiz varsa).

Hataları çözerken Çöküyor> Sinir bozucu> Kozmetik ve daha sonra mümkün olduğunca ilk verimi almak için "önce en kısa iş" i yapıyorum.

Çok sıkı bir şekilde ödenen ücretli bir iş olmadığı sürece, herhangi bir hatayı çözmekten herhangi bir doğrudan finansal fayda hesaplamak ÇOK zor buluyorum.

Gereksinim duyabileceğiniz bir not, Joel Testinde beşinci noktaya kadar yaşamanız gerektiğidir - bu, takım boyutundan ve diğer çeşitli "yerel" konular arasındaki dağılımdan etkilenebilir - ancak genellikle iyi uygulamanın bir işaretidir.

Başka bir husus, hatanın etkisini ve maliyetini belirlemeye ve düzeltmeye çalışırken hatayı ortaya çıkaran test veya test organizasyonu türü olabilir. Ünite veya fonksiyonel testler, tasarımda değiştirilmesi gereken bir şeye işaret edebilir ve bu nedenle erken düzeltme, daha sonradan daha kolay ve daha az maliyetli olacaktır. Sistem veya entegrasyon testi, çok çeşitli müşterileri etkileyen bir şeye işaret edebilir. Ve Standartlar testi, genellikle büyük bir müşteri alt kümesi için kritik olmayan bir şey olsa da, düzeltilmezse sertifika kaybına yol açabilir ve iş üzerinde olumsuz bir etkiye neden olabilir.

Bununla birlikte, belirli bir test kuruluşunun test başarısızlığı olması, bir hatanın otomatik olarak "kritik" hale getirilmemesi gerektiğini söyledi. Örneğin, "tüm sistem testlerinin gönderilmeden önce geçmesi gerekir, bu nedenle otomatik olarak başarısız olan herhangi bir sistem testi kritik / yüksek önem derecesine sahip bir hata ile sonuçlanır." Umarım hiçbir kuruluş bu açıklamayı yapmaz (iyi test çıkış ölçütleri farklı bir tartışmadır), ama asıl nokta, hatanın “ciddiyetinin”, nerede, ne zaman yerine müşteri, ürün veya şirket imajı üzerindeki etkisi konusunda yargılanması gerektiğidir. ortaya çıkar.

Bunu ele almanın olası bir yolu, "ciddiyet" ile "aciliyet" arasında bir ayrım yapmaktır. Örneğin, çıkış tarihi yaklaştıkça, görünürde daha düşük bir önem derecesine sahip bir hatanın büyük bir müşteri alt kümesini etkileyip etkilemediğini belirlemek için zaman baskısı olabilir, bu hataya daha büyük bir "aciliyet" verir ve bu hata üzerinde (bazı) diğerlerinde en azından bu karar verilinceye kadar. İkisi arasındaki uygun denge, deneyim ve iyi muhakeme ile birlikte, zaman ve çaba harcanan yeri yönlendirmeye yardımcı olacaktır.

Diğerlerinin hataların sınıflandırılması hakkında söylediklerine ek olarak, belirli bir hatanın temsil edebileceği kritiklik seviyesini belirlemek için Afferent Coupling'e (Ca) bakmayı da düşünün. Yüksek Ca sayısına sahip bir modülde bir hata varsa, sistemdeki diğer bileşenlere fayda sağlayabileceğinden önce bunu düzeltmeye bakıyordum. Ca, sorumluluk düzeyini belirlemenize yardımcı olur ve içinde hata bulunan sorumlu modüller tüm uygulamaya zarar verir (Ca hakkında daha fazla bilgiyi buradan edinebilirsiniz: http://www.ibm.com/developerworks/java/library/j-cq04256/index.html ).

Bunu göz önünde bulundurarak, hataları kategorilere ayırma ve müşteri üzerindeki etkilerine göre önceliğe yerleştirme eğilimindeyiz. Müşteriniz değişecektir, ancak tartışmaya katılmalarını sağlamak nihayetinde başkalarının üzerinde hangi hataların düzeltilmesi gerektiğini yönlendirecektir. Gerçek bilimsel değil, ama bütün bir takım olarak hataların önceliği ve sınıflandırılması konusunda fikir birliğine varma eğilimindeyiz, herkes "büyük olanlar" (tüm paydaşlar girdi verebilir) girdisine sahiptir ve oradan istiflenip rafa kaldırılır.

Tüm hataların gerçek maliyetini belirleyemezsiniz. Bazıları, çoğu için nicelemek çok zor. Örneğin, düğmelerdeki metnin biraz yanlış hizalanmasına neden olan bir hatanız olduğunu varsayalım. 1.0 ürününüzün biraz özensiz görünmesini sağlar. Bu, programınızın kilitlenmesine veya kullanıcılarınızın veri kaybetmesine neden olmaz. Muhtemelen oldukça ucuz bir böcek, değil mi?

Şimdi, her müşteriniz bu sorunu fark ederse ve her gözden geçiren, ürününüzün incelemelerinde bundan bahsediyorsa. Ve eğer bu hata 1.0'dan 1.1 ve 1.2'ye kadar devam ederse. Şirketinizin artık kalite kontrolünde biraz özensiz olma şöhreti olabilir. Bu basit hata, gelecekteki ürünler için şirketiniz için potansiyel satış kayıpları açısından ne kadar pahalı olabilir? Veya bu, ürününüzün aldığı bir incelemeyi nasıl etkileyebilir - ürününüz müşterilerinizin ihtiyaçlarını mükemmel bir şekilde karşılayabilir, ancak biraz özensiz göründüğü için sadece 10 üzerinden 9 alır.

Bu nedenle, belirli bir hatanın maliyetini düzeltmenin maliyeti ve kullanıcı üzerindeki doğrudan etkisi açısından değil, aynı zamanda ürününüzün algısını nasıl etkilediği konusunda daha geniş bağlamda düşünmeniz gerekir. ve bu algının gelecekteki satışları nasıl etkilediğini

Bu çok zor gibi görünebilir ama değil. Bunu yazarken, Apple'ın takvim simgesini "1" i bir veya iki piksel üzerinde nasıl taşıdığı hakkında bir makalesi olan web üzerindeki başka bir siteye gidebilirsiniz. Bir arama yaparsanız, bu küçük küçük hata hakkında birkaç olumsuz makale görürsünüz. Tabii ki, bu Apple'ın alt çizgisini doğrudan etkilemedi, ancak kendilerini iyi tasarımın zirvesi olarak tanıttılar, bu nedenle bir tasarım hatası olması, bu algıyı sadece biraz da olsa etkiler.